Re: [josm-dev] JMapViewerTiles folder in my Temp folder
On Mon, Aug 27, 2012 at 4:31 PM, Toby Murray wrote: > You can clear the cache by right > clicking in the map and using the "Flush tile cache" option in the > context menu. If I might suggest an improvement, the command should be available in the layer context menu as well (I would even suggest to move the whole context menu from the map itself since it is very annoying as it appears by accident many times during edition but that's another story). Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Please do not change long established shortcuts
On Mon, Apr 30, 2012 at 7:41 PM, David Earl wrote: > Absolutely - hugely better, thank you! The problem was it was right next to > the S key so you ended up deleting stuff instead of selecting it. I don't know how small are you keyboard keys (or fat your fingers) but I never had this problem. As pointed by others, when you really edit/draw with this tool, the mode switch on one hand and the mouse on the other hand was very practical.Fortunately, it is still allowed to customize the shortcuts.Unfortunatelly, preferences are too often reset by versions upgrades. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Please do not change long established shortcuts
On Mon, Apr 30, 2012 at 4:13 PM, Maarten Deen wrote: > In principle, it is not a good idea to change long established customs. This has been decided a looong time ago due to a russian forum complain: http://lists.openstreetmap.org/pipermail/josm-dev/2012-February/006033.html Our opinion and long established customs does not count very much on josm dev. Btw, you should update your JOSM more frequently. Then you don't have time to acquire habits. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Shortcuts
On Fri, Feb 17, 2012 at 1:50 PM, Paul Hartmann wrote: > If we reserve a small pool, this won't be enough, so who decides which > plugin is more important? That's the idea. It can be enough because nobody installs all plugins but only a few of them. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Shortcuts
On Thu, Feb 16, 2012 at 6:41 PM, Paul Hartmann wrote: > > As plugin developer, you can basically do what you like, also claim a > shortcut like "I" for Utilsplugin2/IntersectedWaysAction. But you > shouldn't be surprised if we need "I" for JOSM core someday. > If you read my OP, I'm not asking very much and could satisfy everybody: - keep one Function key and two or three main keys for plugins. - let plugins ask the user if he wants to keep the current shortcuts or use the old ones in case of conflicts. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Shortcuts
On Wed, Feb 15, 2012 at 6:12 PM, Dirk Stöcker wrote: > If the default would be to keep everything as is, we copy all these troubles > a long time into the future. So we have one break now and later on wikis and > forums on docs refer to one setup and not to a user specific setup. Fixing current conflicts is one point. Saying "at any time in the future, the josm core can take over existing plugins shortcuts because we find it so cute and plugins will have to accept it" (1) is another one. This is a kind of arrongance and disrespect of JOSM plugins users and devs. Pieren (1) "when core needs a key, then plugins will be second in line and have to move." ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Shortcuts
On Wed, Feb 15, 2012 at 9:24 AM, Dirk Stöcker wrote: > Please help to fix these conflicts and deprecations. For conflicts, the core > should remain and plugins be changed. As a plugin maintainer, I would like to see from the JOSM core the following points: - reserve some shortcuts for plugins 'forever'. It is unfair to allow plugins shortcuts and once users have their habits, force them to change just because core is suddenly using it. Of course, it does not solve conflicts between plugins but devs can manage that. - allow the plugin to overwrite the core shortcut with a pop-up dialog explaining the 'why' (and leaving the user to accept or refuse). This is a way to keep long-term users with their habits and show to new comers the shortcut issue e.g. with the documentation (after all, it can be redefined manually later in the prefs). Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Changed presets, "contact"
> so by no means should we blindly take for gospel what the Wiki says. > but the JOSM presets, yes... Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugin for Karlsruhe schema
On Tue, Oct 25, 2011 at 5:25 AM, Werner Horsch wrote: > I was thinking in how to aid the entry of numbering to osm, and it shouldnt > be very difficult. > The logic should be something like this for addr interpolation... I don't think it is a good idea. As the relation is called, all addresses between start and end are just ... interpolation. They should stay as such in the database. It is the responsibility of the data consumer to speculate on the right position for all intermediate numbers in the street, not a script working into the database. If contributors are not satisfied by the interpolation, they should reduce the size of it or put single node addresses. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Dynamic buttons in side menus
2011/10/15 Dirk Stöcker : I wrote a diary because I don't think it has to go to Trac. UI is always a question of personnal taste. Now JOSM looks like a Flash game. The only missing feature is to get 50 points each time you click fast enough on appearing objects or new cursor effect. All these things make finally a strange impression of not very serious interface. Fine, as soon as I can disable them. But I understand. I'm a dev myself and when you work on a mature projects, it is always difficult to find the good moment to say 'no'. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Fwd: Filter Google from Imagery?
+1 for the blacklist (for the reasons explained by Richard) -1 for tagging the changeset (privacy and who is going to watch the tag and contact people ?) -1 for comparing. I know already two web sites displaying gm and OSM mashups. I don't see the advantage of comparing within an editor excepted to adjust the data. my 2 cents, Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Relation editor usability
On Thu, Dec 9, 2010 at 7:02 PM, colliar wrote: > > Your are right there is already a ticket filled about it: > http://josm.openstreetmap.de/ticket/5683 > > If you use the two below buttons it works ! > > Cheers colliar > > Oops, sorry. I though it was something wished, not a bug. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS requiring an EULA acceptance
On Thu, Aug 12, 2010 at 6:20 PM, Sebastian Klein wrote: > I would imagine it like this: > * You open josm preference and select the entry from the defaults. > * A message box pops up, informing you that it is necessary to accept an > EULA for using the service. > * If you click "OK", it would download the EULA text from an external > website (possibly translated) and present it in another dialog. > * Save in the preferences that EULA has been accepted. > > Sounds reasonable for me. If nobody is against this proposal, I will look to implement it in the plugin. Thank you for your support, Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS requiring an EULA acceptance
On Thu, Aug 12, 2010 at 5:56 PM, Bodo Meissner wrote: > Matthias is right. You cannot rely on the client program. It is easy to > change the user agent. see > http://chrispederick.com/work/user-agent-switcher/ > > Again, the idea is not to build up a fortress. It is well known that if someone really want to catch the images, he will be able to do so anyway. The request to show and accept the uela is coming from the jurists, I cannot change that. What I would like to know is if it is possible and how I could do it in JOSM/WMS plugin without disturbing the main stream. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
On Sat, Apr 3, 2010 at 3:46 PM, Dirk Stöcker wrote: > Hello, > > time for next release is reached. Any objections against releasing current > latest as tested and move on with JAVA6 from now on? > > Ciao > > I have submitted a patch 5 weeks ago for a change in the french cadastre projections: https://josm.openstreetmap.de/ticket/4641 If someone could apply it before another 5 weeks, thank you. regards, Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugins not working with 3094 and Linux ?
On Wed, Mar 10, 2010 at 11:46 AM, Dirk Stöcker wrote: > Don't ask me. I'm no Java guru :-) Maybe you already use JAVA6 stuff in > your plugin? E.g. isEmpty() in strings? > > Or we have such thing in JOSM core and didn't recognice it? > > > No, no, it was the same jar file which worked on previous tested JOSM. The only difference was the new JOSM-tested core (and again, it's only happening of Linux). The solution is probably to compile the plugins in the same way as the core (Java6 compiled for 5). Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugins not working with 3094 and Linux ?
On Wed, Mar 10, 2010 at 10:40 AM, Dirk Stöcker wrote: > > JOSM core is already compiled using JAVA6, but still using JAVA5 as > target. > > Is it the reason why the plugins compiled with Java5 raises this exception on some platforms ? Exception is : java.lang. UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) Anyway, I recompiled my plugin with java6 and it seems to work now. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On Sat, Mar 6, 2010 at 9:19 AM, Paul Johnson wrote: > > If you go the absurdist route, maybe. If you want to map the > landuse of the right-of-way, how about landuse=highway? > > This has already been proposed. But until everyone is drawing a polygon for the road, we have to accept that the polyline "is" the road. So, gluing the adjacent landuse to the highway or leaving a space preparing the road polygone are both correct. The second is just more accurate than the first. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] self-intersecting ways
On Fri, Mar 5, 2010 at 12:11 PM, Teemu Koskinen wrote: > > Definitely not, IMO the warning should be elevated to an error, when > dealing with wide linear features (roads, rivers, etc.). > > If you go that way, drawing a road or a river with a polyline should be reported as an error. Or don't tag is as a highway but "the_white_line_in_the_middle_of_the_road" ;-) Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] location of elemstyles.xml and Eclipse
On Tue, Jan 26, 2010 at 7:11 AM, Matthias Julius wrote: I think you have to add the /data in your eclipse project classpath (included path). Is it not already done in the commited .classpath ? Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Need advice about a recent change in Mapview blocking the plugin cadastre-fr and its Lambert zone projections
On Wed, Nov 18, 2009 at 6:21 PM, Pieren wrote: > I cannot use a JOptionPane because it's called from MapView.paint() > and if I just convert the values silently, the projection is wrong and > the user is never informed even when he is really working outside the > box. To be more clear: I don't know how to ignore silently the values outsides the box coming from the change in MapView but still warn the user when he is really working outside the box. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Need advice about a recent change in Mapview blocking the plugin cadastre-fr and its Lambert zone projections
On Tue, Nov 17, 2009 at 9:10 AM, Dirk Stöcker wrote: > Implement preferences into Lambert and drop the autodetection. This is > anyway a necessary step. > > Instead of auto-detection you can then implement a "suggest projection > switch" requester when user tries to initialy use cadastre-fr in an > outside region. > I'm trying to implement to subprojection and manual configuration of the Lambert zone but I still have the problem with the recent change in MapView.paint. When the projection is configured for a certain zone and MapView calls the projection for values outside the box in paint(), I cannot warn the user and I don't have to warn the user because those values are non-sens since they have nothing to do with the user and its current activities. The coordinates are not related to the OSM data or any geodata. They are just based on fancyfull values and I don't know what to do in latlon2eastNorth in such cases. I cannot use a JOptionPane because it's called from MapView.paint() and if I just convert the values silently, the projection is wrong and the user is never informed even when he is really working outside the box. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Need advice about a recent change in Mapview blocking the plugin cadastre-fr and its Lambert zone projections
On Tue, Nov 17, 2009 at 9:10 AM, Dirk Stöcker wrote: > Instead of auto-detection you can then implement a "suggest projection > switch" requester when user tries to initialy use cadastre-fr in an > outside region. > > Ciao I could do that but this will not help if MapView is always calling the projection with east-north values that are outside the region. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Need advice about a recent change in Mapview blocking the plugin cadastre-fr and its Lambert zone projections
Hi,
A recent change in Mapview.java (rev.2450) by "jttt" introduces a
problem with the Lambert projections and I don't know how it could be
fixed. That's why I'm calling here for some help/advice.
The change is the following in Mapview @Override public void paint(Graphics g) :
(before)
Graphics2D tempG = offscreenBuffer.createGraphics();
tempG.setColor(Main.pref.getColor("background", Color.BLACK));
tempG.fillRect(0, 0, getWidth(), getHeight());
for (Layer l: getVisibleLayersInZOrder()) {
l.paint(tempG, this);
}
for (MapViewPaintable mvp : temporaryLayers) {
mvp.paint(tempG, this);
}
(and after)
Graphics2D tempG = offscreenBuffer.createGraphics();
tempG.setColor(Main.pref.getColor("background", Color.BLACK));
tempG.fillRect(0, 0, getWidth(), getHeight());
Bounds box = getLatLonBounds(g.getClipBounds());
for (Layer l: getVisibleLayersInZOrder()) {
l.paint(tempG, this, box);
}
for (MapViewPaintable mvp : temporaryLayers) {
mvp.paint(tempG, this, box);
}
The problem is this new call of getLatLonBounds() with random east,
north values the first time a new layer is added. With the Lambert
zone projections, I use the first calls to the projection methods to
automagically determin the Lambert zone (in Lambert CC 9 zones, the
zone is 1 for north values around 1.000.000, the zone is 2 for north
values around 2.000.000, etc). It just ignores values outside the
projection (for instance, for the first latlon<->eastnorth convertions
called with the world bounds).
Now, the first call of EastNorth2latlon is done with east, north
values which looks "correct" but are in the wrong Lambert zone:
in MapView.getLatLonBounds(), we pass a
Rectangle[x=0,y=0,width=900,height=873] which gives
EastNorth[e=1245767.0463764844, n=1285470.7852088492].
Then the projection is switching to the Lambert zone 1 when the first
layer is opened. And I cannot ask the plugin cadastre-fr to change
again the projection zone once there is something present in a layer.
So, I don't know how this issue could be fixed.
Pieren
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New projection for JOSM
On Tue, Oct 20, 2009 at 11:52 AM, Pieren wrote: > Hi, > > Could someone from the core team apply the following patch: > https://josm.openstreetmap.de/ticket/3737 > (pop-up) Nobody to commit the 10.6 KB patch and allow the French contributors to use again the cadastre ? Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] New projection for JOSM
Hi, Could someone from the core team apply the following patch: https://josm.openstreetmap.de/ticket/3737 adding a new projection required by the cadastre-fr plugin. Since 10 days, the French cadastre WMS has changed the projection for two third of the municipalities from the old "Lambert 4 zones" to a new projection called "Lambert Concic Conform 9 Zones". This patch will allow me to publish a new version of the plugin to restore our access to the WMS. Thanks, Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] shocking - unsecure password sending!
On Wed, Oct 7, 2009 at 10:46 AM, Frederik Ramm > Even now someone could create an OSM account with the name > "Frederik_Ramm" and use this to vandalise. I agree with Frederik. The only risk of the plain password over the network is that you took the same user name and password as for your other applications which is something -I hope- nobody does. Securing your login will not secure your contributions. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Critical bug since 2204
On Tue, Oct 6, 2009 at 12:15 AM, Karl Guggisberg wrote: > It is still present in tested (2221) and users will certainly notice because > conflicts on ways are not detected > as expected. I tried on my build version and merging ways seems to work. Which type of conflicts are not detected ? Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Preset about roundabouts
JOSM presets is adding a oneway=yes tag for roundabouts. Could you remove this, please ? This is in contradiction with the wiki (linked in the dialog itself) which says clearly that oneway is implied: http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout and something about common sens since it is said since years in OSM that the direction of the way gives the oneway direction in roundabouts. And if it is not oneway, it is simply not a roundabout (excepted for the 3 or 4 magic roundabouts in the world). Otherwise we start to see complains about roundabouts tagged with oneway=-1 http://lists.openstreetmap.org/pipermail/newbies/2009-July/003279.html http://lists.openstreetmap.org/pipermail/josm-dev/2009-March/002731.html We also see some validation tools that report this as an error (osmose) Created as ticket for traceability : http://josm.openstreetmap.de/ticket/3578 Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Tested
On Fri, Aug 14, 2009 at 11:31 PM, Dirk Stöcker wrote: > Hello, > > It was a long time since last tested version. Are there (beside missing > translations) any reasons not to make the latest to tested in next days? > > Ciao Any chance to find a solution about #3181 before the release ? Since some weeks, the cadastre-fr plugin is strongly disturbed by the ProgressMonitor dialog always on top, even with the preference window-handling.option-pane-always-on-to set to false. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS not working lately?
On Tue, Aug 11, 2009 at 1:41 AM, Michael Kugelmann wrote: > But after deleting my old preferences and some minor tweaking We had a similar discussion on the french ML and this solution worked for me but worked only after a first restart (!) for another guy. A third user had simply the wrong projection. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM always on top
On Thu, Jul 30, 2009 at 2:00 AM, Martin Koppenhoefer wrote: > it is a feature. > > Martin Now, we have to minimize JOSM each time we want to see other windows ... Usually, applications with this behaviour have a good reason to be "always on top" or at least, they provide an option to disable it. My guess is that you will hear a lot of complains about this behaviour in the future. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM always on top
On Wed, Jul 29, 2009 at 10:22 PM, Michael Bemmerl wrote: > Karl Guggisberg schrieb: >> Are both you working with XP too? >> >> -- Karl > > At least I'm working with XP SP3, JOSM 1857 & Java 1.6.0_14. > I have the same issue with XP SP2, JOSM 1876 and Java 1.6.0_14 Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
I see just now that rev.1546 is integrating the commit message within the upload first dialog. And the previous commit message is provided as default. I think it is a good compromise. It will not avoid that some people will continue to write meaningless comments but this will make edition easier, especially for people working with small edit sessions in the same area. Thank you, Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
On Thu, Apr 23, 2009 at 3:09 PM, Dermot McNally I think that empty comments are better than innappropriate comments. "guessed" comments will be hard to implement and will most probably not help better than crappy comments. I would suggest the following : each time you start JOSM and first time you leave the comment field empty, pop-up a warning messagebox explaining how comments are important for collaboration, although not mandatory. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
On Thu, Apr 23, 2009 at 11:39 AM, Frederik Ramm > They will sooner or later find out > what this is about. On Wikipedia, newbie sees what helpful comments are by looking in the page history or the "recent changes" report which is one of the most popular page on any Mediawiki project. It is the same here and I think that's why the current OSM "Recent Changes" page will be very popular as well (might be a bit longer in my opinion). > And forcing them to enter *something* will make them think; Someone who just wants to fix small issues on his local home area and use an OSM editor one or two times in his live, may not want to think and learn what the purpose of changeset comment is. > Allowing them to simply hit enter will make > them ignore the topic and forget about it. Or make them: "Ok, they ask me for a comment. For this time, I may have or haven't a comment. But why not for next time". Just asking for comment is already making them thinking. To finish, I will quote some sentences from our JOSM key developers: Dirk Stöcker said: "Nah. I'm against restrictions, but warnings are fine." Frederik Ramm said (about wiki page smoothness): "I have tried to understand what this is about but failed. Obviously some guy named "ChrisCF" thinks he owns the place and writes things like "I will not allow this and that" - an attitude that will surely influence my own behaviour should I encounter him on the Wiki." Pieren, the childish thinking like the Wikipedia admins about empty comments btw, I also wrote a patch in ticket #2434 which allows empty comments, following the API documentation. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
On Wed, Apr 22, 2009 at 1:56 PM, Frederik Ramm wrote: > Yes, if the user so dislikes being communicative then let him put "fuck > you" there and be surprised why his edits get reverted more often than > others. > > Honestly, the commit comment is important and if someone who has made an > effort to map something cannot be bothered to spend 5 seconds of his > time (thus making things VERY much easier for everyone else) then I'd > politely ask him to find another crowdsourcing project to contribute to. > I cannot accept this argument. OSM lived for years without comments. It is a "nice to have" information but it is not so important as the geodata content. Wikipedia works since years with optional commit comments and making no comments does not mean that the edits are crap. If I have to choose, I prefere contributors making good quality editions with no comments than contributors making bad quality stuff with nice comments. JOSM seems to be the only one who tries to force comments. Myself, I like to describe my changes but not always. But when I see that "I have to" do it, it makes me so ungry that I write anything excepted what I could kindly write otherwise. Pieren and svn comment message can be empty, excepted if you want to force it. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Commit message not empty
On Wed, Apr 22, 2009 at 1:20 AM, Frederik Ramm wrote: > But honestly, what would you say from a user interface perspective; should > we try and keep changesets open? What JOSM currently does is open changeset What I would like to see is that JOSM works like a wiki : when I click on the upload button and it shows me it succeeded, then I know it is stored in the database. I want to be able to control the duration of my edit session. Look the wiki logs, some people save every minute their small changes and write only a comment at the last one. Others prefer to work offline for a long period and make a big upload with or without comments because they think that the upload content is self-descriptive. If the new API allows empty commit comments, I don't see why JOSM is forcing some content here. It is of course a good practice to write something and we can recommend people to do so and make advertising for it. But if contributors don't want to describe what they upload, you cannot and you will not be able to force them. Even if you find a way to request less frequently this comment. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] restrict mass-editing?
On Tue, Mar 31, 2009 at 4:31 PM, Jonathan Bennett wrote: > Shaun McDonald wrote: >> In 3 weeks time you'll put the source tag on the changeset rather than >> on the way, node or relation. > > Good point! > > -- > Jonathan (Jonobennett) I gave "source" tag as an example. It could be admin_level=10 or building=yes or natural_park=wow. I'm sure you understand what I mean. We read sometimes in the ML people using JOSM for such things because they don't want to write scripts. It's funny to see that OSM - as a principle - tries to be as flexible/open as possible but OSM editors would be more and more limited/closed in their usage. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] restrict mass-editing?
> Seriously though, can you think of a legitimate use for "Select All" in > JOSM? Yes. JOSM is also used to edit subset of data, either extracted and filtered from OSM by XAPI for instance or before importing bulk data into OSM (e.g. attach a tag "source=" to admin boundaries which are first simplified), etc... Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Moving 400km south with Lambert projection
Did you see the following message :
tr("The projection \"{0}\" is designed for\n"
+ "latitudes between 46.1° and 57° only.\n"
+ "Use another projection system if you are not using\n"
+ "a French WMS server.\n"
+ "Do not upload any data after this
message.", this.toString()));
?
If not, could you send me a message where you describe how you
proceed. Then I will try to reproduce it on my PC.
regards
Pieren
On Sun, Feb 1, 2009 at 3:36 PM, Thorsten Feles wrote:
> I switched to the Lambert projection to do some editing in Bastia,
> Corsica with a French WMS in the background. While in other places I had
> no problems, here every time I downloaded OSM data to JOSM they where
> moved 400 km to the south. Is that a problem with my installation only
> or can somebody confirm that problem ?
>
> Thanks
>
> Thorsten
>
> ___
> josm-dev mailing list
> josm-dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/josm-dev
>
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Recent changes in Relation editor dialog
Yesterday, I've updated JOSM to the latest version. And I noticed some changes in the relation editor behaviour which are making it less intuitive than earlier. I've updated one trac about what I have noticed (#2058) : - If you select several objects then open the relation editor with the "new relation" button, they are all deselected. - if you select one key/value in the relation editor, all objects listed in the roles are selected. - If you select one key/value and press the "delete" button, it is not deleting the key/value but one of the attached members of "roles". Actually, I found only one way to delete a key/value : go to and delete the text field in "value" and press "Enter". Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Fail
On 1/16/09, Sascha Silbe wrote: > On Fri, Jan 16, 2009 at 01:08:35PM +0100, Pieren wrote: > >>> +1 for making this harder to activate (separate mode, ctrl+drag, >>> whatever). It's pretty annoying when trying to select a region in a >>> densely mapped area. >> -1 >> I'm moving ways. I cannot say "every day" but I move ways when I: >> - improve roundabouts (position, circle) >> - draw dual carriageways (copy, paste, reverse, move) >> - draw areas like buildings or parks > How would e.g. having to press Ctrl in addition to dragging impact your > workflow? > I don't see why you're opposed to making it harder to _unintentionally_ > using it. > Where is the limit of making harder commands for _intentional_ actions just to prevent _unintentional_ actions ? It is very hard to find the right balance between newcomers and experimented users. I have no definitive answer on that. But for instance, I find sometimes a way and some of its nodes with the same tag (e.g. oneway=true). This was clearly _unintentional_ and we could also want JOSM to prevent adding tags on objects when nodes and ways are selected... except if you press Ctrl-alt-shift or whatever. But I could also imagine a preference flag making the commands much less flexible as it is today, "a la Potlatch" ;-) Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Fail
On 1/16/09, Sascha Silbe wrote: > On Fri, Jan 16, 2009 at 03:55:42AM +0100, Frederik Ramm wrote: > >> Maybe the moving of entire ways should be removed completely or at >> least moved out of the standard editing mode; in my time as a mapper >> the only use I ever had for it was nudging buildings. > +1 for making this harder to activate (separate mode, ctrl+drag, > whatever). It's pretty annoying when trying to select a region in a > densely mapped area. > -1 I'm moving ways. I cannot say "every day" but I move ways when I: - improve roundabouts (position, circle) - draw dual carriageways (copy, paste, reverse, move) - draw areas like buildings or parks Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Small patch for "Align nodes in circle" issue with other projections
Dear Josm-dev,
Could you please apply the following small patch fixing the issue of
the function "align nodes in circle" not working when the current
projection is Lambert (or any projection not supporting "new
LatLon(0,0)") ?
In class AlignInCircleAction.java,
replace this:
if (center == null) {
center = new Node(new LatLon(0, 0));
Node n0, n1, n2, prvni, druhy;
by:
if (center == null) {
center = new Node(new LatLon(0, 0));
center.eastNorth = new EastNorth(0, 0); // to be
independent of projection
Node n0, n1, n2;
Thank you to matthew-...@newtoncomputing.co.uk who suggested this
short solution some time ago.
Pieren
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Projections
Being the person who introduced "Lambert Zone France" in Josm, I can give my opinion about projections in plugin: Pro: - more flexible: we are not depending of the Josm developers to commit the source files although all my requests to commit newer versions of the sources have always been kindly and quickly done. But it's always difficult to depend on others. Con: - the new projection might be required in several plugins, thus we take the risk that the same stuff is developed several times or that the same projection is instanciated in Josm several times for different plugins. Perhaps the solution is to keep the original projections EPSG and Mercator in core and create a "projection" plugin collecting all projections. In this way, we use the osm subversion repository; we are sure that one projection is developed only once for all; many projections could share a common library of functions. Pieren On Thu, Dec 11, 2008 at 9:27 PM, Frederik Ramm wrote: ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator bug when fixing duplicate nodes
Since I did start digging in the Validator code last week for the Lambert projection issue, I can have a look on that as well. Just tell me two things: - is anybody allowed to assign a Josm Trac ticket to himself or anybody else ? - what about merge conflicts ? I could also have a look on another issue I noticed when I tried to quickly test the "Ignore" feature which tried to save the information into an inexisting file, thus raising an exception. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] EastNorth objects not serialized
Thanks ! On Thu, Nov 27, 2008 at 12:31 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote: > Done. > > Bye > Frederik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] EastNorth objects not serialized
It seems that since rev. 1004, the class Coordinate is not anymore serialized but derived from java.awt.geom.Point2D (which is not serialized as well). This has the effect that my plugin saving GeorefImages with EastNorth objects on disc raises an exception java.io.NotSerializableException. Would it be possible to re-implement the serializable interface in Coordinate or EastNorth ? Otherwise I could also encapsulate EastNorth objects into my own serialized class. Sorry if my question is totally wrong. Maybe I missed something since nobody complains about this change done 2 months ago. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Accuracy is important - not!
and it should be written that Yahoo imagery might be less accurate than GPS tracks. So, improving the accuracy is important. Don't give the impression that downgrading accuracy of existing data is not important. Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Small patch for Lambert projection
oops, sorry about that.
Thank you for the great support.
Pieren
On Sun, Aug 24, 2008 at 11:11 PM, Dirk Stöcker
<[EMAIL PROTECTED]> wrote:
> On Sun, 24 Aug 2008, Pieren wrote:
>
>> I created a patch to fix this issue.
>> First, it will not raise an exception anymore if the nodes are outside
>> the Lambert zones.
>> Second, it will display once an error message if someone tries to use
>> this Lambert projection beyond the latitudes it was designed for.
>> Third, I renamed the projection as "Lambert Zone (France)" to show
>> that this projection has limited coverage and is not for the whole
>> planet (I hope the new name is more clear).
>>
>> If would be nice if someone with a write access could apply the patch
>> to the source Lambert.java.
>
> One note regarding translations (to you also Frederik! :-):
>
> - Translations must be unmodifyable strings:
> tr("Text" + variable + "text") does never work.
> Use tr("Text{0}text", variable)
>
> - EVERY user visible string should be translatable.
>
> I'm going through JOSM code for some time now and fixed such stuff in so
> many places, don't make my life harder by introducing new problems of that
> style.
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
>
> ___
> josm-dev mailing list
> josm-dev@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/josm-dev
>
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Small patch for Lambert projection
I created a patch to fix this issue.
First, it will not raise an exception anymore if the nodes are outside
the Lambert zones.
Second, it will display once an error message if someone tries to use
this Lambert projection beyond the latitudes it was designed for.
Third, I renamed the projection as "Lambert Zone (France)" to show
that this projection has limited coverage and is not for the whole
planet (I hope the new name is more clear).
If would be nice if someone with a write access could apply the patch
to the source Lambert.java.
I attach the patch with the extension .txt in this email but the patch
is also attached in the related Trac ticket 1441 :
http://josm.openstreetmap.de/ticket/1441
Thank you in advance,
Pieren
On Thu, Aug 21, 2008 at 10:07 PM, Dirk Stöcker
<[EMAIL PROTECTED]> wrote:
>> Probably you introduced a new bug with this:
>
> http://josm.openstreetmap.de/ticket/1441
>
> Ciao
> --
> http://www.dstoecker.eu/ (PGP key available)
Index: Lambert.java
===
--- Lambert.java(revision 815)
+++ Lambert.java(working copy)
@@ -65,6 +65,10 @@
public static int layoutZone = -1;
+ private static int currentZone = 0;
+
+ private static boolean dontDisplayErrors = false;
+
/**
* @param p WGS84 lat/lon (ellipsoid GRS80) (in degree)
* @return eastnorth projection in Lambert Zone (ellipsoid Clark)
@@ -76,7 +80,7 @@
double lg = geo.lon();
// check if longitude and latitude are inside the french
Lambert zones
- int currentZone = 0;
+ currentZone = 0;
boolean outOfLambertZones = false;
if (lt >= zoneLimits[3] && lt <= cMaxLatZone1 && lg >=
cMinLonZones && lg <= cMaxLonZones) {
// zone I
@@ -99,23 +103,36 @@
currentZone = 3;
} else {
outOfLambertZones = true; // possible when MAX_LAT is
used
+ if (p.lat() != 0 && Math.abs(p.lat()) !=
Projection.MAX_LAT
+ && p.lon() != 0 && Math.abs(p.lon()) !=
Projection.MAX_LON
+ && dontDisplayErrors == false) {
+ JOptionPane.showMessageDialog(Main.parent,
+ tr("The projection \"" +
this.toString() + "\" is designed for\n"
+ + "latitudes between 46.1° and 57°
only.\n"
+ + "Use another projection system if you
are not using\n"
+ + "a french WMS server.\n"
+ + "Do not upload any data after this
message."));
+ dontDisplayErrors = true;
+ }
}
if (!outOfLambertZones) {
- if (layoutZone == -1)
+ if (layoutZone == -1) {
layoutZone = currentZone;
- else if (layoutZone != currentZone) {
+ dontDisplayErrors = false;
+ } else if (layoutZone != currentZone) {
if ((currentZone < layoutZone &&
Math.abs(zoneLimits[currentZone] - lt) > cMaxOverlappingZones)
|| (currentZone > layoutZone &&
Math.abs(zoneLimits[layoutZone] - lt) > cMaxOverlappingZones)) {
JOptionPane.showMessageDialog(Main.parent,
tr("IMPORTANT : data positionned far away from\n"
+ "the current Lambert zone limits.\n"
+
+ "Do not upload any data after this message.\n"
+ "Undo your last action, Save your work \n"
+ "and Start a new layer on the new zone."));
layoutZone = -1;
+ dontDisplayErrors = true;
} else {
- System.out.println("temporarily extends
Lambert zone "
- + layoutZone + "
projection at lat,lon:"
Re: [josm-dev] Strange compilation errors in Eclipse
Perhaps it's related to java 6. Josm development is based on Java 1.5... Pieren On Sat, Aug 23, 2008 at 3:10 PM, rainerr <[EMAIL PROTECTED]> wrote: > > gettext-commons-0.9.2.jar is already in my java build path. As I said before, > the compilation errors disappear, if I change the static imports to > non-static imports. Therefore, it doesn't look like a classpath issue to me. > > > Pieren Pieren wrote: >> >> Your problem should be solved if you add the gettext-commons-0.9.2.jar >> library in the project "java build path" settings. >> Pieren >> >> >> > > -- > View this message in context: > http://www.nabble.com/Strange-compilation-errors-in-Eclipse-tp19120862p19121449.html > Sent from the OpenStreetMap - JOSM Dev mailing list archive at Nabble.com. > > > ___ > josm-dev mailing list > josm-dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/josm-dev > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Strange compilation errors in Eclipse
Your problem should be solved if you add the gettext-commons-0.9.2.jar library in the project "java build path" settings. Pieren On Sat, Aug 23, 2008 at 1:47 PM, Rainer Rothkegel <[EMAIL PROTECTED]> wrote: > Hi, > > when I try to compile the josm sources in Eclipse, I get 3 strange error > messages related to static imports and the gettext-commons-0.9.2.jar: > > The method marktr(String) is undefined for the type AutoScaleAction > josm/src/org/openstreetmap/josm/actions AutoScaleAction.javaline 27 > > The method tr(String) is undefined for the type MainMenu > josm/src/org/openstreetmap/josm/gui MainMenu.java line 120 > > The method tr(String) is undefined for the type MainMenu > josm/src/org/openstreetmap/josm/gui MainMenu.java line 123 > > If I change the static imports to non-static imports, everything > compiles fine. Also, if I compile the (unchanged) sources with ant > outside of Eclipse, there are no errors. > > My java environment is based on the latest versions in the Kubuntu Hardy > stable repository: > ii sun-java6-jdk 6-07-3ubuntu2 > ii eclipse3.2.2-5ubuntu2 > ii ant1.7.0-3 > > > Does anyone have an idea what the problem is? > > Thanks, > Rainer > > > ___ > josm-dev mailing list > josm-dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/josm-dev > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Validator
I think the layer=-1 is a good trick in urban zones where you have many bridges. But is it necessary to add a layer -1 in the countryside even in sections where you have no crossing at all ? Anyway, is that the correct ML to discuss mapping rules ? Pieren On Wed, Aug 20, 2008 at 11:24 AM, Dermot McNally <[EMAIL PROTECTED]> wrote: > 2008/8/20 Gervase Markham <[EMAIL PROTECTED]>: > >> I think that both waterways and roads are layer 0, "the ground", and >> when one crosses another, the upper one should have layer=1 - because >> there's air between it and the actual surface of the earth. I would >> apply this to any ground-based physical features, not just roads and rivers. > > That articulates my view pretty well. Once again, consider that > "layer" isn't the same as "level". We don't care whether a bridge > rises up above the "level" of the road either side of it. The > important thing is that at the point where it crosses the river, the > road must be on a higher "layer" than the river. So along the length > of a way, it is acceptable (and unavoidable) to have "jumps" in layer > that may not reflect actual changes in elevation. Layers exist to > determine the drawing order of overlapping elements, nothing more. > > Dermot > > -- > -- > Iren sind menschlich > > ___ > josm-dev mailing list > josm-dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/josm-dev > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Small patch for Lambert projection
Dear Josm-dev,
Could one of the Josm developers having write access to the repository
submit the following small patch for the Lambert projection class ?
It's to avoid an unnecessery warning message when MAX_LAT / MAX_LON are used.
Note that this time, I renamed the patch with the extension .TXT
hoping that it will not be filterer by the ML. Maybe you will be able
to see it. In the case not, I also copy it below.
Thank you,
regards
Pieren
Index: Lambert.java
===
--- Lambert.java(revision 799)
+++ Lambert.java(working copy)
@@ -100,21 +100,24 @@
} else {
outOfLambertZones = true; // possible when MAX_LAT is used
}
-if (layoutZone == -1)
-layoutZone = currentZone;
-else if (layoutZone != currentZone && !outOfLambertZones) {
-if ((currentZone < layoutZone &&
Math.abs(zoneLimits[currentZone] - lt) > cMaxOverlappingZones)
-|| (currentZone > layoutZone &&
Math.abs(zoneLimits[layoutZone] - lt) > cMaxOverlappingZones)) {
-JOptionPane.showMessageDialog(Main.parent,
-tr("IMPORTANT : data positionned far away from\n"
-+"the current Lambert zone limits.\n"
-+"Undo your last action, Save your work \n"
-+"and Start a new layer on the new zone."));
-layoutZone = -1;
-} else {
-System.out.println("temporarily extends Lambert zone
" + layoutZone
-+ " projection at lat,lon:" + lt + "," + lg);
-}
+if (!outOfLambertZones) {
+ if (layoutZone == -1)
+ layoutZone = currentZone;
+ else if (layoutZone != currentZone) {
+ if ((currentZone < layoutZone &&
Math.abs(zoneLimits[currentZone]
- lt) > cMaxOverlappingZones)
+ || (currentZone > layoutZone &&
Math.abs(zoneLimits[layoutZone] - lt) > cMaxOverlappingZones)) {
+
JOptionPane.showMessageDialog(Main.parent,
+ tr("IMPORTANT : data
positionned far away from\n"
+ + "the current
Lambert zone limits.\n"
+ + "Undo your
last action, Save your work \n"
+ + "and Start a
new layer on the new zone."));
+ layoutZone = -1;
+ } else {
+ System.out.println("temporarily extends
Lambert zone "
+ + layoutZone + " projection at
lat,lon:" + lt + ","
+ + lg);
+ }
+ }
}
if (layoutZone == -1) {
return ConicProjection(lt, lg, Xs[currentZone],
Ys[currentZone], c[currentZone], n[currentZone]);
Index: Lambert.java
===
--- Lambert.java(revision 799)
+++ Lambert.java(working copy)
@@ -100,21 +100,24 @@
} else {
outOfLambertZones = true; // possible when MAX_LAT is used
}
-if (layoutZone == -1)
-layoutZone = currentZone;
-else if (layoutZone != currentZone && !outOfLambertZones) {
-if ((currentZone < layoutZone && Math.abs(zoneLimits[currentZone]
- lt) > cMaxOverlappingZones)
-|| (currentZone > layoutZone &&
Math.abs(zoneLimits[layoutZone] - lt) > cMaxOverlappingZones)) {
-JOptionPane.showMessageDialog(Main.parent,
-tr("IMPORTANT : data positionned far away from\n"
-+"the current Lambert zone limits.\n"
-+"Undo your last action, Save your work \n"
-+"and Start a new layer on the new zone."));
-layoutZone = -1;
-} else {
-System.out.println("temporarily extends Lambert zone " +
layoutZone
-+ " projection at lat,lon:" + lt + "," + lg);
-}
+if (!outOfLambertZones) {
+ if (layoutZone == -1)
+ layoutZone = currentZone;
+
Re: [josm-dev] JOSM, plugins and Eclipse (was: Patch for sorting members in the relation editor)
The problem is that Josm is loading the plugin jar's from the ~/josm/plugins folder and not from where it is compiled. What I did to fix this is create an export file descriptor (Eclipse->Export->jar->save to file) .jardesc in the plugin project which export the plugin jar file into the final location (right click on the jardesc file and click on 'create jar'): In "select the export destination", I gave: C:\Documents and Settings\\Application Data\JOSM\plugins\myplugin.jar regards Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM, plugins and Eclipse (was: Patch for sorting members in the relation editor)
The problem is that Josm is loading the plugin jar's from the ~/josm/plugins folder and not from where it is compiled. What I did to fix this is create an export file descriptor (Eclipse->Export->jar->save to file) .jardesc in the plugin project which export the plugin jar file into the final location (right click on the jardesc file and click on 'create jar'): In "select the export destination", I gave: C:\Documents and Settings\\Application Data\JOSM\plugins\myplugin.jar regards Pieren On Sun, Aug 17, 2008 at 12:37 AM, Bodo Meissner <[EMAIL PROTECTED]> wrote: > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Patch for sorting members in the relation editor
Great ! I confirm that it works again on Eclipse now. Thank you Dirk, I couldn't imagine working in Java without Eclipse. Pieren On Sat, Aug 16, 2008 at 10:46 PM, Dirk Stöcker <[EMAIL PROTECTED]> wrote: > On Sat, 16 Aug 2008, Robin Rattay wrote: > >>>> Unfortunatly one of the biggest weaknesses of Eclipse is the poor ant >>>> building and jar file integration. It can't use inforation from a build >>>> file to set things like class path and source directtories. >>> >>> And there is no other way to tell exclipse, what it needs to do? >> >> AFAIK no. But I'm no expert. > > Ok. Should work now. I moved the svn:externals directly into images. > > Ciao > -- > http://www.dstoecker.eu/ (PGP key available) > > ___ > josm-dev mailing list > josm-dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/josm-dev > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Small patch for "Zoom to selection" combined with projection Lambert
On Sat, Aug 16, 2008 at 6:33 PM, Dirk Stöcker <[EMAIL PROTECTED]>wrote: > Nothing attached. > Are you sure ? Because I see the attachement from my side... Nevertheless applied. > Anyway, thank you again. regards Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Small patch for "Zoom to selection" combined with projection Lambert
Dear Josm-dev, could someone with a write access to the Josm core repository commit the following (small) patch fixing an issue when Lambert projection is enabled. Again, the problem is that the code uses an initial value with LatLon(0,0) when we execute the "zoom to selection" menu action. I've attached the diff file as recommended but here is also the quick view of the change (in file org.openstreetmap.josm.actions.AutoScaleAction.java) : replace this line: EastNorth en = Main.proj.latlon2eastNorth(new LatLon(0.001, 0.001)); by this one: EastNorth en = new EastNorth(0,0); Thank you in advance, Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Bug-fixing
I can verify some of them. But you should explain how to proceed. Shall we add a comment in the tracker entry saying e.g. "Yes, I checked this and it is still an issue" ? Pieren On Wed, Aug 6, 2008 at 5:58 PM, Dirk Stöcker <[EMAIL PROTECTED]>wrote: > Hello, > > probably some of you have seen, that in the last month I tried to reduce > the entries in the bug-tracker. > > ATM there are 109 defect's left: > > > http://josm.openstreetmap.de/query?status=new&status=assigned&status=reopened&type=defect&order=id&desc=1 > > It would be nice, if others could check for some of these if they could be > verified in newer versions, check for duplicates, ask for additional > information on non-reproducable bugs, ... > It's a lot of work to check all the reports and verify if they still > apply. Sometimes also the descriptions aren't very helpful. > > Ciao > -- > http://www.dstoecker.eu/ (PGP key available) > > ___ > josm-dev mailing list > josm-dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/josm-dev > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Request to apply a small patch about the alignment in circle and rotate objects functions
Dear Josm-dev,
Could someone commit the following two changes regarding the features "align
nodes in circle" and "rotate objects" ?
As I said in a previous email, a node initialized with LatLon(0,0) may have
completely wrong EastNorth values (at least for the Lambert projection).
Here is the change in AlignInCircleAction.java (thank you Matthew):
Index: D:/
svn.openstreetmap.org/applications/editors/josm/core/src/org/openstreetmap/josm/actions/AlignInCircleAction.java
===
--- D:/
svn.openstreetmap.org/applications/editors/josm/core/src/org/openstreetmap/josm/actions/AlignInCircleAction.java
(revision 746)
+++ D:/
svn.openstreetmap.org/applications/editors/josm/core/src/org/openstreetmap/josm/actions/AlignInCircleAction.java
(working copy)
@@ -53,9 +53,9 @@
// Get average position of all nodes
Node avn = new Node(new LatLon(0,0));
+avn.eastNorth = new EastNorth(0,0); // to be independent of the
projection system
for (Node n : nodes) {
avn.eastNorth = new
EastNorth(avn.eastNorth.east()+n.eastNorth.east(),
avn.eastNorth.north()+n.eastNorth.north());
-avn.coor = Main.proj.eastNorth2latlon(avn.eastNorth);
}
avn.eastNorth = new EastNorth(avn.eastNorth.east()/nodes.size(),
avn.eastNorth.north()/nodes.size());
avn.coor = Main.proj.eastNorth2latlon(avn.eastNorth);
And here is the change in RotateCommand.java (same cause with the same side
effect) :
Index: D:/
svn.openstreetmap.org/applications/editors/josm/core/src/org/openstreetmap/josm/command/RotateCommand.java
===
--- D:/
svn.openstreetmap.org/applications/editors/josm/core/src/org/openstreetmap/josm/command/RotateCommand.java
(revision 746)
+++ D:/
svn.openstreetmap.org/applications/editors/josm/core/src/org/openstreetmap/josm/command/RotateCommand.java
(working copy)
@@ -62,7 +62,7 @@
this.objects = AllNodesVisitor.getAllNodes(objects);
pivot = new Node(new LatLon(0,0));
-
+pivot.eastNorth = new EastNorth(0,0); // to be independent of the
projection system
for (Node n : this.objects) {
MoveCommand.OldState os = new MoveCommand.OldState();
os.eastNorth = n.eastNorth;
@@ -70,7 +70,6 @@
os.modified = n.modified;
oldState.put(n, os);
pivot.eastNorth = new
EastNorth(pivot.eastNorth.east()+os.eastNorth.east(),
pivot.eastNorth.north()+os.eastNorth.north());
-pivot.coor = Main.proj.eastNorth2latlon(pivot.eastNorth);
}
pivot.eastNorth = new
EastNorth(pivot.eastNorth.east()/this.objects.size(),
pivot.eastNorth.north()/this.objects.size());
pivot.coor = Main.proj.eastNorth2latlon(pivot.eastNorth);
Thanks,
Pieren
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] josm and other projection systems questions
no, your solution is the shortest ;-) (I created an iterator to replace the "for each" loop). Someone reported another feature non compatible with the projection Lambert. I will show here my code changes proposal on this ML later, when I will have a solution with the other issue. Thanks in the mean time, Pieren On Sun, Aug 3, 2008 at 1:32 AM, <[EMAIL PROTECTED]> wrote: > Hi Pieren, > > On Sat, Aug 02, 2008 at 12:19:56PM +0200, Pieren wrote: > > - a problem with the tool "align nodes in circle" which is calculating > the > > average position of the selected nodes. Unfortunately, this average is > done > > with a first value initialized like this: > > new Node(new LatLon(0,0)); > > but this is not workign with the Lambert projection (the east/north are > high > > negativ values). I made a fix avoiding this kind of initial node but > rather > > use the first "real" node as initial value. Is that the correct way to > > proceed (in which case I could submit the change) ? > > I wrote that code. > > That sounds fine - the only reason for the new LatLon(0,0) is to > get the initial node to have EastNorth coordinates of 0,0. This > was to allow an easy "for (Node n : nodes)" rather than doing a > loop that missed the first node. > > A quick guess is that the easiest way to fix is probably to add: > > avn.eastNorth = new EastNorth(0, 0); > > after that line, but maybe your code is shorter? > > Cheers, > > -- > Matthew > ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] josm and other projection systems questions
Dear josm-dev, I recently introduced the Lambert projection in Josm and I have two questions about that: - a problem with the tool "align nodes in circle" which is calculating the average position of the selected nodes. Unfortunately, this average is done with a first value initialized like this: new Node(new LatLon(0,0)); but this is not workign with the Lambert projection (the east/north are high negativ values). I made a fix avoiding this kind of initial node but rather use the first "real" node as initial value. Is that the correct way to proceed (in which case I could submit the change) ? or all projection systems should be specially coded to support this special value LatLon(0,0) ? - a received a request from belgian contributors who would like an implementation of another Lambert system for their local wms server (Lambert 72). This projection is closed to the french Lambert zone system and it would be easy to create a new projection derived from the one I developed. My question is more general : does it make sense to add more and more projection systems or would it be better to make these country specific projections available through the plugin mechanism ? regards Pieren ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
[josm-dev] New projection required for a new plugin
Dear all, I'm currently developing a JOSM plugin to access a french WMS which will be a very useful source of data for OSM (it's the french land register called 'cadastre'). I'll not talk about the legal aspects here (ref.[1]) but the license clearly allows the derived works for free like we will do with JOSM (using the images as a back layer). My idea is to create a plugin which will extend the existing WMSplugin because we need to start the session in a special way and the wms delivers only one commune (town/city/village) images per request (city code embedded in url). My current problem is more technical and concern the projection : the WMS returns images projected with the french Lambert zone system (ref.[2]) only. This is the traditional projection system used here in France. It's called "Zone" because the country is divided in 3 zones plus one for Corsica. Now, I would like to know your opinion about the best way to proceed: - either keep the current available projections, retrieve the images and re-project them under the current existing projection. But I have the feeling that it is not so easy to do (not only stretching the lines). But I saw a proof-on-concept example on your ML archives (ref.[3]). - the other possibility is to implement the Lambert zone projection, which is something I've already successfully tried. But I was not able to do it without changing the josm class Projection which contains the allProjections() method. Do you have any plan in the future to make extra projections possible from plugins without changing the josm core files ? Or shall I implement the Lambert zone project in the standard available projections of JOSM (but that could raise more questions/problems from the users and the list is potentially increasing a lot) ? Thanks for your help. Pieren [1] License of cadastre ( http://www.cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html) (in french) [2] Lambert conformal conic projection ( http://en.wikipedia.org/wiki/Lambert_conformal_conic_projection) [3] 2007-Novemeber : Change JOSM default projection from EPSG:4326 to Mercartor? ( http://lists.openstreetmap.org/pipermail/josm-dev/2007-November/000428.html) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
