[josm-dev] personal announcement
Hi, When joining the project two years ago, I had no great ambitions and decided to sign up with an alias. Later I had the unfortunate idea to choose a fictitious name for posting on the mailing lists. Meanwhile, as OSM in general and JOSM in particular became a major hobby of mine, this got more and more awkward, especially when exchanging private mail. I'd like to put an end to this and use my real name from now on; apologies for this kind of pretence. Hope to see you at a conference or another occasion, Paul-Fiete Hartmann (new email address: phaau...@googlemail.com; svn user name will remain) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Summer of Code 2011 Ideas
Ian Dees wrote: Hi all! As admin for OSM's application to Google's Summer of Code this year, I'd like to remind everyone that we're looking for some project ideas for students to work on here on the wiki page: http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2011. The application deadline is roughly 24 hours away and we only have 2 ideas listed so far. All OSM-related projects are welcome to add project ideas. Any editors, tools, or libraries related to OSM should feel free to throw their ideas on this page so we can have a well-rounded list. Google uses this ideas page as part of the application process, so we should show them the diverse set of ideas our community has. Please feel free to pass this on to other mailing lists! Anything wrong with copying the Improved conflict resolution in JOSM idea from last year? There wasn't much development in that area, so this would still be a nice project. Other stuff I can think of at the moment: * Work on gwtosm project, i.e. create a usable javascript editor based on the josm sources. * Continue signfinder [1] GSoC project from 2009, i.e. create a JOSM plugin that reads street names off photos * Create a scripting API for JOSM. The plugin by Karl already provides the infrastructure, so this project could focus on design and implementation of a easy to use and robust interface. [1] http://wiki.openstreetmap.org/wiki/Automatic_Street-Sign_Detection_and_Reading Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857
Tobias Wendorff wrote: Am 08.03.2011 14:53, schrieb Josh Doe: And as far as OSM putting both datums on the same level, I have to disagree. OSM itself explicitly says all coordinates are in WGS84. There may be certain applications which mix things up, but that's not the fault of OSM. Let me explain it in numbers, perhaps my English is too bad: WGS84 coordinates (LAT,LON): 51.0, 7.0 [1] projection to EPSG:3785 (x,y): 5677294.03, 781182.21 (sphere) [2] projection to EPSG:3857 (x,y): 5677294.03, 775978.50 (ellipsoid) When a software uses the spherical formular of mercator, the coordinates will be drawn at 5677294.03, 781182.21. If the inverse mercator formular is also the spherical one, more errors will be added... x/y-coords to geographical ones: [3] 5677294.03, 781182.21 = 51.00, 7.046703 Used parameters on cs2cs: [1] cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +a=6378137 \ +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m \ +nadgrids=@null +no_defs [2] cs2cs +proj=latlong +datum=WGS84 +to +proj=merc +datum=WGS84 \ +units=m +nadgrids=@null +no_defs [3] cs2cs +proj=merc +datum=WGS84 +units=m +nadgrids=@null +no_defs \ +to +proj=latlong +datum=WGS84 -f %.6f I'm not an expert, but this does not look right to me. The EPSG describes Popular Visualisation Pseudo Mercator projection (used by both EPSG:3785 and EPSG:3857) as: This method is utilised by some popular web mapping and visualisation applications. It applies standard Mercator (Spherical) formulas to ellipsoidal coordinates and the sphere radius is taken to be the semi-major axis of the ellipsoid. [...] Unlike either the spherical or ellipsoidal Mercator projection methods, this method is not conformal: scale factor varies as a function of azimuth, which creates angular distortion. For this to work, the (lat,lon) coordinates have to be in WGS84 in the first place. EPSG:3785 defines (lat, lon) to be spherical, so it is not useful for osm in any way. To sum it up: JOSM's use of EPSG:3857 is correct at the moment. [1] http://www.epsg.org/guides/G7-2.html Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857
Tobias Wendorff wrote: That's the spherical formular. When you draw a point in JOSM (x,y) it gets translated back to the *sphere*, not to the ellipsoid. This spherical information will be stored to the WGS84-database. Correct, but this is EPSG:3857 by definition. It would be EPSG:3785 if you would store it to a database of spherical coordinates. have a look at the spec again: http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3857reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3857 http://www.epsg-registry.org/report.htm?type=selectionentity=urn:ogc:def:crs:EPSG::3785reportDetail=shortstyle=urn:uuid:report-style:default-with-codestyle_name=OGP%20Default%20With%20Codetitle=EPSG:3785 In 3857 you start with WGS84 coordinates and blindly apply the spherical formula. This is exactly what we do. From a scientific viewpoint, the results are flawed, but it is done anyway because the calculation is simple. EPSG:3857 is called WGS 84 / Pseudo-Mercator because this is what you do, when you have WGS84 coordinates (e.g. from GPS) and you are too lazy to do proper reprojection. Instead you use the simples formula that produces somewhat usable results. In contrast to that, with 3785, you start with spherical coordinates and apply *the same* formula. But we don't have spherical coordinates, so we cannot use this method. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
Dirk Stöcker wrote: Hello, The 5th of March should be the next release of a josm tested. Wo hakt es denn? Bitte die Fristen nicht so unkommentiert verstreichen lassen... Was meinst du eigentlich mit 5.3 genau, die Version um 3 Uhr morgens oder die um 27 Uhr? Gruß, Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
Sebastian Klein wrote: Dirk Stöcker wrote: Hello, The 5th of March should be the next release of a josm tested. Wo hakt es denn? Bitte die Fristen nicht so unkommentiert verstreichen lassen... Was meinst du eigentlich mit 5.3 genau, die Version um 3 Uhr morgens oder die um 27 Uhr? Oops, was supposed to be private mail... :) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Applet
Dirk Stöcker wrote: On Thu, 3 Mar 2011, Frederik Ramm wrote: If we can get it to work properly then I'm sure it can be hosted on osm.org and be added to the Edit drop-down. Perfectly fine. But it must work on josm.openstreetmap.org, You mean josm.openstreetmap.de? as this is the place, where JOSM developers have influence. If the OSM-servers provide it as well we can help them, but development will be based on our sphere of influence. What is the difference to PL2? It is developed in openstreetmap.org svn repository and Tom Hughes updates the binary regularly for rails [1]. We should go all the way and even use the same authentication method. I don't know the details, but apparently an OAuth token is automatically issued for Potlatch 2 the first time it is used. Getting rid of 2 layers of authentication and replacing it by default login on openstreetmap.org is a huge usability improvement and in my opinion worth the trouble and loss of control. Sebastian [1] http://git.openstreetmap.org/rails.git/history/e34ce3cb4cb6e3b6a44ccf5027784e6d4e49adb1:/public/potlatch2/potlatch2.swf ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM Applet
Dirk Stöcker wrote: Hello, What is the difference to PL2? It is developed in openstreetmap.org svn repository and Tom Hughes updates the binary regularly for rails [1]. We should go all the way and even use the same authentication method. I don't know the details, but apparently an OAuth token is automatically issued for Potlatch 2 the first time it is used. Well, that does not solve the issue. When you use OAuth with JOSM applet you also need no OSM-login, but you need to login at JOSM server. This is the same for potlatch, where you need to login at Potlatch server. What are you talking about? You don't have to go to geowiki.com. Put yourself in the place of a user that is very inexperienced: * oh, there is this openstreetmap thing I heard about, let's check it out * go to www.openstreetmap.org and sign up - this is normal, every website has login nowadays * zoom the map, select PL2 from the edit tab list, add some POI, click save, enter changeset command, done! The OAuth thing happens completely behind the scenes, everything works smoothly with a single login. Now, for the josm applet, there are further hurdles: * You have go to another domain. (Understandable if you know the project better, but a little strange for a newcomer.) * You are supposed to enter another login, the JOSM wiki this time. Most users will have to sign up first and wonder why this is required. * In addition (even if you are sill logged in at the osm.org website) you have to enter the osm login again (at least once). (Or use OAuth which is more difficult at the moment.) Somewhen you need to login. The question is only whether you login at josm.openstreetmap.de or www.openstreetmap.org. Not such a big difference in my eyes. I think it would be cool to have something similar for the JOSM applet, but of course that would mean that whoever checks out the applet to osm.org would have to take some responsibility for it not being a security hole. Somehow I believe again (this time both of you) don't know JOSM's features. We already can do the server communication with additional authentication. When running on the OSM server, OAuth-request could also be handled automatically, as login is already done. But what we need in any case is an initial login. There is no way around it. Yes, but the openstreetmap account is needed anyway and you may log in for other reasons, e.g. check the settings or write a diary entry. Why should it be required to sign up and login on yet another site to simply start one of the osm editors? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] MapCSS
André Riedel wrote: 1. Are relative width values only be supported by JOSM or is it a main feature of MapCSS 0.1 or 0.2? No, it's not an official feature of MapCSS. I've suggested it on the MapCSS mailing list [1]. - relative values only be supported for a separate layer - no support for cascading relative values (see big_bridge) At the moment, declarations are static properties: You can repeat them as often as you like and nothing changes. +6 basically means to have a margin of 3 on both sides. What you propose would change this principle and move the language into an imperative direction - i'm not convinced this is a good idea. In the mean time, you can make it explicit and write width: eval(prop(width) - 2); - no support for negative relative values Will be fixed. 3. Why are there different definitions of casing-width? JOSMCSS [1]: absolute value - absolute width of the casing relative value - refers to width MapCSS 0.1 [2]: - absoulte width MapCSS 0.2 [3]: - relative width I took the liberty to suggest an improvement to the standard. :) When the MapCSS community finally decides on something else, I will accept that. But what is written in the wiki is not necessarily the community consensus. In fact it was changed by RichardF, but Potlatch 2 still seems to use absolute casing-width, so it is compatible at the moment... Also note that MapCSS 0.1 is final, but MapCSS 0.2 is still a draft. [1] http://lists.openstreetmap.org/pipermail/mapcss/2010-October/000124.html Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Netbeans // older josm code?
Werner Horsch wrote:
Thanks Marko and Sebastian your tips were very useful. I've been able to
clean the plugin from coding errors. I'm struggling with too many things
which are far away from my basic knowledge
I've tried
a) running JOSM out of the IDE doesn't allow me to see the plugin and got a
message JOSM strange version you should update
Does it work if you build josm from the command line?
In principle you can ignore this, it doesn't matter usually.
b) compiling the plugin to a jar from the comand line, no idea how to do
it from the IDE for just this piece, then copied it to the folder where the
rest of the plugins are. Opened my regualr installed version of JOSM, check
the plugin under preferences, but still didn't appear on the menu
I think the problem relies on:
super(I18n.tr(create node on intersections), intersectway,
I18n.tr(create nodes on every intersection),
Shortcut.registerShortcut(tools:Intersec way, I18n.tr(Tool: {0}, new
Object[] { I18n.tr(pr) }), 73, 3, 1), true);
Attached is the code of the plugin if someone wants to give some hint I will
appreciate it
How do you compile the plugin? Try the following strategy: Start with
some existing pluign, see if you are able to build and run it. Then
transform it step by step into what you like to have.
It is possible to develop plugins in the IDE. (Debugging and changing
code at runtime works as well.) Easiest way to do this in netbeans is to
create a Free Form project and use the existing build script. Add the
JOSM core project as a library.
The plugin ant files depend on the binary core/dist/josm-custom.jar, so
you might want to change that to core/netbeans/dist/josm.jar.
Your plugin has a wrong constructor and the Manifest file must have the
right form. (see other plugins)
Sebastian
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Mandatory login for JOSM wiki
Hi Frederik, Frederik Ramm wrote: with so many JOSM configuration details (list of imagery sources, list of map styles, and presets) now in the JOSM trac/wiki instead of in (either JOSM's or OSM's) SVN, I suggest that we disallow anonymous editing. There's now too much potential to wreak havoc and we wouldn't even know who did it. Either I don't understand your concerns at all or they are partially based on misunderstandings. If it is the latter, I would appreciate a summary of the issues you still see. It's completely un-traceable anonymous config changes making their ways onto the hard disks of JOSM users that I object to. [...] But not requiring login for publishing something to all JOSM users, without them even knowing, is something entirely different. [...] It's just about making sure that if config changes are made that affect JOSM users, these config changes should not come from anonymous users. [...] I find it unacceptable that someone can inject any imagery source or preset or map style into *every* JOSM instance without even having to log in. First of all, if you have a fresh JOSM install, there is no way anyone can inject anything into it. The worst that can happen is someone puts spam entries into one of the lists. I'm not aware, this ever happened, but it wouldn't do much harm. You'd only see it in the preference dialogue and not somewhere in the main menu. Each extension (preset, style, plugin, wms url, remote control) is explicitly activated by the user. Even if someone is smart enough to create a preset that causes josm to crash or execute malicious code, why would he want to attack the handful of people that download that preset just in the time frame when the change is not noticed by developers or users? Their nifty exploit would be useless after it has been spotted once. Imho there are much more attractive targets like remote control or plugins. In [3936] I changed plugin descriptions, so the user can spot plugins that come from an external source. What else can we do? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] single session authenticatoin
Mikel Maron wrote: Wondering about --D. I assume java is passing that into josm as an environment variable? Could the same be done with a blank login and password? If so, how would that look? No, doesn't work at the moment. But it is actually a nice idea to allow overriding arbitrary preference entries on the command line. I may look into that after next release. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
Frederik Ramm wrote: Hi, Dirk Stöcker wrote: Please note also, that this week a new server infrastructure has been established. JOSM mappaint styles, mapcss styles and JOSM presets can now be made in the JOSM Trac wiki pages. Assuming there was some catastrophic server failure, and further assuming that you are not personally available to fix things - 1. will anyone else in the world be able to re-create the trac setup that you have created? Are any of the core JOSM developers involved? I know that I'm not and to me it looks like quite a maze! How long would it take someone to create the required infrastructure? Is there documentation? (Don't say yes, in trac ;) Are there backups that include all the config files etc.? I don't think it is that bad. :) As Dirk said, the magic is contained in 2 single files: The cronjob and the trac plugin. 2. what parts of JOSM will not work as long as the server is down? JOSM runs just fine without the josm.openstreetmap.de server. Dirk listed most of the server dependent services, let me add that it can't update the list of available wms/tms urls and the bug report system won't be able to redirect to trac, obviously. All files loaded from a remote server are cached locally for 7 days. (But it keeps the old copy if update fails.) There are 3 exceptions to this rule: * plugin update is always on demand * list of users that agreed to the CT is cached only 2 hours * wiki help content (including message of the day) isn't cached at all So basically no functionality accesses the server, unless it is absolutely necessary. (Yes, we could distribute the wiki help, but this also means you get outdated information and the size of josm-*.jar increases.) In addition, everything can be done manually (plugin installation, adding presets, styles and imagery urls). Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Mandatory login for JOSM wiki
Dirk Stöcker wrote: The biggest and in my eyes only important issue is the possibility to have malicious plugins and we can't anyway do anything against this without preventing plugins. Yes we can: (1) Make clear whether a plugin is from openstreetmap svn or an external binary (e.g. move external plugins to a 2nd tab in the preferences or remove them from the public list altogether). (2) Introduce nightly builds for plugins and allow to ping the server for an intermediate build. I think measure (1) can be done in a weaker form right now (short note in the plugin description), but we should keep our environment as open as possible. Measure (2) isn't necessary for security reasons in my opinion, but would improve the plugin work flow in general. In fact, only 2 out of all 65 plugins are external at the moment. However, many svn plugins have been external in the past and got integrated later. I guess the main reason is, that josm changes too often and as plugin author it is hard to keep up with that. (Core developers care for plugins that are in svn.) It seems to me, there are two main reasons for authors to add external plugins: On the one hand some people are too shy to ask for a svn account and like to build in their own familiar environment. On the other hand there are developers that would be capable of adding their sources to svn, but prefer not to do so for some reason (e.g. git fetishists or control freaks). I guess we can live without the second kind but there is no reason to be unkind to beginners. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Netbeans
Werner Horsch wrote: Is it possible to use Netbeans to connect to the server for downloading packages and start trying some code for a future plugin? Im just a SW hobbiest with no experience at all in such big projects, I hear to recommendations fot a start up Check out the developers guide: http://josm.openstreetmap.de/wiki/DevelopersGuide There are project files for eclipse in the repository, so this should be the easiest way to get started. If you prefer netbeans, this works as well. But you have to choose the right options when setting up the project and there seems to be no guide on this. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] single session authenticatoin
Mikel Maron wrote: Hi In Kenya, we have people often sharing computers. With JOSM, this causes an issue, because people forget to change the saved authentication credential to their own. You can choose to not save credentials, but this then leads JOSM to ask for them on every single API call, which is basically unusable. JOSM remembers the credentials for one session, even if you choose not to save it permanently. Please report a bug (including used version) if this is not the case. Is there a solution to this? Ideally, login/password would only be stored for a single session. So you like to have an (advanced) option to not show the save user and password checkbox in the credentials dialog? Would be a great help to us in Kenya! There is another option: * Create links on the desktop, on for each user. * Change the link from java -jar .../josm-tested.jar to java -Djosm.home=.../josm-user1 -jar .../josm-tested.jar (Replace ... by the path to the preference folder for user1 and the path to josm-tested.jar respectively.) This will keep the preferences for each user in a separate folder. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] projection Mercator, set EPSG 3785 instead of EPSG 3857
Dirk Stöcker wrote: On Sun, 20 Feb 2011, Josh Doe wrote: What timing. I just created a wiki page on this very subject. [1] I've been meaning to submit a bug, but the Mercator projection in JOSM is NOT EPSG:3857 as it claims, I'm not sure what EPSG or ESRI code it corresponds to. Well, we can fix JOSM's internal Mercartor without side effects, as currently it is never exposed outside (for WMS it is silently [and slightly false] converted to EPSG:4326). It should be as simply as multiplying with 6378137.0. I did so in Revision 3922. It breaks imagery offsets. (But on the plus side fixes #5789 :) ) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New multiselect feature in the presets has serious problems ...
Ulf Lamping wrote: Hi! Just tried latest JOSM 3901 to try out the new multiselect feature of the presets. I've tried with the amenity=restaurant cuisine=xy preset. namely you cannot enter values not already existing in the list. That's why it's called preset. :) So compared to the previously used combobox, you cannot enter uncommon / new values. Unfortunately, I don't know a good solution for this problem ... Maybe put back the old combobox and when you select a value, another combobox pops up below? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How do I add a new projection, EPSG:2924?
Petr Nejedlý wrote: The more complex, but generally preferable (as it would solve many similar problems once for good) would be to code a delegating class loader that would try to fulfill the load request by trying each plugin's loader in sequence. This is already done in some way, to load Images from the main jar or any of the plugin jars. Is it possible in Java to list all available classes (specifically all subclasses of Projection)? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How do I add a new projection, EPSG:2924?
Sebastian Klein wrote: Petr Nejedlý wrote: The more complex, but generally preferable (as it would solve many similar problems once for good) would be to code a delegating class loader that would try to fulfill the load request by trying each plugin's loader in sequence. This is already done in some way, to load Images from the main jar or any of the plugin jars. Is it possible in Java to list all available classes (specifically all subclasses of Projection)? Never mind, google answers my question. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] change distribution of internal mappaint styles
Hi,
I'll change the build process (see patch below) in order to add more
default mappaint styles for default selection in future. Otherwise we'd
need to change the scripts (including server-side) for each new file.
The internal stuff can be moved to a new styles_nodist folder.
Sebastian
Index: build.xml
===
--- build.xml (revision 3856)
+++ build.xml (working copy)
@@ -82,9 +82,6 @@
copy file=README todir=build/
copy file=LICENSE todir=build/
- !-- styles --
- copy file=styles/standard/elemstyles.xml todir=build/data/
-
!-- create josm-custom.jar --
delete file=dist/josm-custom.jar/
jar destfile=dist/josm-custom.jar basedir=build
level=${clevel}
@@ -96,6 +93,7 @@
/manifest
zipfileset dir=images prefix=images /
zipfileset dir=data prefix=data /
+ zipfileset dir=styles prefix=styles /
zipfileset dir=src/org/openstreetmap/gui/jmapviewer/images
prefix=org/openstreetmap/gui/jmapviewer/images /
!-- All jar files necessary to run only JOSM (no tests)
--
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] pecision of mouseclick in josm - may be not jsom-specific
Marco Lechner - FOSSGIS e.V. wrote: hi, I' m wondering how precisely it is possible to click an specific point in josm. I mean, by clicking with the mouse at a specific point to generate a node, what are the factors influencing my precision besides the actual zoom scale and my parkinsonism? Are there any differences compared to flash-based potlach? I just want to know in theory. It's clear that you can set points worlds precisely enough by choosing an appropriate scale. As Frederik said, apart from a small rounding error, the only limiting factor is the pixel raster, so at a scale of 5m/100px (see scale bar in the upper left area) you have about 5cm precision. If you save the layer to file, it keeps the exact values. However, on upload the coordinates will be rounded to server precision, which is (IIRC, at least near the equator) worse than 5cm. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] pecision of mouseclick in josm - may be notjsom-specific
p...@nejedli.cz wrote: basti...@googlemail.com wrote: If you save the layer to file, it keeps the exact values. However, on upload the coordinates will be rounded to server precision, which is (IIRC, at least near the equator) worse than 5cm. Actually, the server precision is 1e-7 degree, which makes about 1.1cm on the equator and less elsewhere. Good to know... I think we could get this value down to 0.642cm if use the full 64 bit and don't skip the range from 180*10^7 to 2^31 (longitude) and from 85.1*10^7 to 2^31 (latitude). Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] [off-topic] pecision of mouseclick in josm - may be not jsom-specific
Frederik Ramm wrote: Hi, Sebastian Klein wrote: Good to know... I think we could get this value down to 0.642cm if use the full 64 bit and don't skip the range from 180*10^7 to 2^31 (longitude) and from 85.1*10^7 to 2^31 (latitude). But why stop there and allow ridiculous resolution at the poles? Given that the earth has a surface of 510,072,000 square kilometres, if you divide that surface in 2^64 almost-round shapes, then each of those only has an area of 0.2765 square centimetres, allowing you to address each place on the surface with 0.52cm precision! Right, but how is it done in practice? You could map the sphere to a disk, without area distortion (e.g.[1]). Then cut the disk into pieces and rearrange them on a square. Nice puzzle game... What's the minimum size of the square when you limit the number of straight cuts on the disk? Maybe it gets better if you allow arc shaped cuts, e.g. slice off crescents and shift them into a nice pattern... :) Sebastian [1] http://en.wikipedia.org/wiki/Lambert_azimuthal_equal-area_projection ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JUnit HTML report
Marcin Floryan wrote: Hi! I've been contributing to JOSM a couple of years ago and now found some more time to work on the project. I was thinking of looking into unit tests a little bit and extend the coverage. Are there any guidelines around unit testing, what's the general approach? Do people feel adding more test coverage will be valuable for the project? Yes, more tests would be good. Jiri has a Hudson/Jenkins job to check the tests regularly. (Not sure it is still running.) If you detect any bugs, let us know. Generally our user base is big enough to find serious problems in hot code, but complicated things like JoinArea, Conflict handling / Merge Layer would benefit from tests. For validator: If there are false positives, we will get bug reports very soon, but if a validation test is turned off by accident, it would be good to have a unit test raise an alarm. I also added HTML reports for Junit to the build (as an optional task as it may require some dependencies for ant) but since my old SVN password doesn't seem to work, I'm attaching it as a patch here. Applied it in [3829]. Finally, I've played with code coverage a little bit and have managed to generate a sample coverage report: http://mfloryan.statnet.pl/josm-test-coverage/ I don't think that coverage is important, but I would concentrate on the classes that would benefit the most from unit testing. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to select objects in an own Layer class?
Stefan Breitling wrote: Hi there! I am trying to develop a plugin for JOSM to represent own datastructures in an own layer (inherited from Layer). This works well but now I want to select objects in my layer with the mouse. Can anybody short explain how this works? In my layer there is no dataset-object and I think I should use the SelectionManager to get the selected rectangle with the coordinates. But how I get the SelectionManager? And there are listener I need to use? There are several options: If a simple click is enough, you could look how it is done in GeoImageLayer.java. If you prefer a rectangle selection, easiest would be to add your own mapmode, like it is done in editgpx plugin. If you really want to hook into normal rectangle selection in select mode, i guess you have to patch JOSM core a little. I don't think there is already a ready-to-use solution, but it should be possible to get there. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] gpx traces from saved gpx
Marco Lechner - FOSSGIS e.V. wrote: this ticket is exactly what i mean. Any chance to get it fixed? No, this is bait for new developers. :) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to update changes in dataSet ?
Dirk Stöcker wrote: On Tue, 4 Jan 2011, Flávio Henrique wrote: One question that could clarify many things for me: after calling Main.main.undoRedo.add(new SequenceCommand(tr(My job), cmds)), a new calling for method: nc.getCurrentDataSet().getWays() should return the combined ways (without the original ones)? I think so, yes. But I'm not sure. Maybe that is a parallel thread and thus asynchroneus. Some of these who had a deeper look into these structures lately (Jiri, Sebastion, Upliner) probably know better. From memory, I would say it happens all in one thread, so there cannot be an issue with parallel execution. Why do you think, nc.getCurrentDataSet().getWays() returns ways from the previous dataSet? This sounds strange, there is only one dataSet at a given time. (Yes, and some positional caching.) Note, that the method will also return ways that are deleted, so the number of returned ways does not change in this case. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] gpx traces from saved gpx
Marco Lechner - FOSSGIS e.V. wrote: Hi, if I download gps-traces from the api in josm, they look very well, but if I save this layer as gpx and reopen it, josm seems to ignore the multiple tracks and merges them all to one (what gives some sort of spaghetti-feeling) connecting one to the next. Is this a bug? More or less - see http://josm.openstreetmap.de/ticket/2900 Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] new tested version?
Hi, Happy new year to everyone! Version 3751 is set to tested; the stabilization phase was long enough, we can start with new development right now! I'm still a little enthusiastic about the fact we can use Bing imagery and that it's properly build into JOSM, now. :-) Thanks to everyone who made this possible, especially Upliner and Ian Dees and all former contributors. Cheers, Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] new tested version?
Hi, what about a new tested version this year? Most problems related to plugin integration should be solved and imagery seems to be stable. We could target the 30.-31. Dec. nightly build as release candidate. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to if a node is mergeable?
I'm not sure I understood correctly, but you can use NavigatableComponent.getNearestNodes() or something similar to get all nearby nodes. Then filter by distance and do the other checks. Sebastian 2010/12/27 Flávio Henrique yoshi...@gmail.com: Hi there. I have data from a city that I'm working to import, but need to do a lot of manual work before. I need to combine the various segments (ways) onto one way, but first I have to find out the nodes that should be merged and, then, combine the segments. I'm playing with MergeNodesAction.java class and the changes is almost done to do the work, but seems the code merge nodes that is not mergeable. I meant: when you select a node that could be referred by two or more ways, JOSM shows it like this: http://i52.tinypic.com/21km9t5.jpg. But when you select an alone-unmergeable node, JOSM shows it like this: http://i54.tinypic.com/29glv0k.jpg. How can I test if the node alone or not and call the actionPerformed method only for those mergeable ? Thank you! Flávio Henrique ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] jmapviewer images
Just do the necessary changes. For nightly builds, the build.xml is not used. We'll fix it manually. Sebastian On Wed, Dec 22, 2010 at 11:23 AM, Upliner upli...@gmail.com wrote: I noticed that recent JOSM builds doesn't contain jmapviewer images which are located at src/org/openstreetmap/gui/jmapviewer/images. When I build JOSM with Eclipse, it includes them and they appear the slippymap chooser. But when I build with ant, they disappear. I doubt how to fix it because I don't know how on-site build system works. Can I just add this path as zipfileset in build.xml? Alternative solution is to copy these images to /trunk/images and change jmapviewer to use absolute image paths(add leading slash to all image paths). -- Best regards, Upliner ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] multiline entry in template (was: sac_scale in JOSM - RFC for change of translation)
Sebastian Klein wrote: Fichtennadel wrote: On Tue, Nov 30, 2010 at 11:04 AM, Sebastian Klein wrote: Btw.: You can use html markup to create a multiline entry, e.g. htmliWanderweg/ibrnbsp;nbsp;ausgeglichene Steigung, Absturzgefahrbrnbsp;nbsp;nicht ausgeschlossen/html (The height of the sac_scale field in the preset dialog will grow accordingly, but I would fix this little flaw later.) I've tried that locally for one entry, but with somewhat mixed results, see http://img146.imageshack.us/img146/7209/josmtemplatesacscale.gif 1. after selecting the entry from the list, the raw html text shows up in the text item (see screenshot). How to prevent this? 2. the text is editable. So if the user changes the default text, this (usually invalid) text is put into the tag value. Is this behaviour intended? (3. as you've said, the height grows.) Ok, its not really usable like this. Please provide the texts and we can try to find a better integration into the preset dialog. Added the explanation to the drop down list (in v3726). It is translatable in launchpad [1], better wording for the English texts is also welcome. Sebastian [1] https://translations.launchpad.net/josm ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] multiline entry in template (was: sac_scale in JOSM - RFC for change of translation)
Fichtennadel wrote: On Tue, Nov 30, 2010 at 11:04 AM, Sebastian Klein wrote: Btw.: You can use html markup to create a multiline entry, e.g. htmliWanderweg/ibrnbsp;nbsp;ausgeglichene Steigung, Absturzgefahrbrnbsp;nbsp;nicht ausgeschlossen/html (The height of the sac_scale field in the preset dialog will grow accordingly, but I would fix this little flaw later.) I've tried that locally for one entry, but with somewhat mixed results, see http://img146.imageshack.us/img146/7209/josmtemplatesacscale.gif 1. after selecting the entry from the list, the raw html text shows up in the text item (see screenshot). How to prevent this? 2. the text is editable. So if the user changes the default text, this (usually invalid) text is put into the tag value. Is this behaviour intended? (3. as you've said, the height grows.) Ok, its not really usable like this. Please provide the texts and we can try to find a better integration into the preset dialog. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Sharpen imagery layer
Stephan Knauss wrote:
Hi,
as Potlatch2 provides the option to sharpen the image I thought this
should be possible in JOSM as well.
Unfortunately my 5 minute hack is not working. First I thought it might
be no BufferedImage, but it is one.
It throws an exception being unable to convolve the Image. It does not
tell why it's unable. Javadoc also does not tell.
As I'm no expert in this area I hope someone more experienced with
ConvolveOp can improve the imagery plugin.
Some sun bug reports suggest that you have to sanitize the image. This
is a poor solution, but if the sharpened image is cached, it could be
acceptable.
Index: src/org/openstreetmap/josm/plugins/imagery/tms/TMSLayer.java
===
--- src/org/openstreetmap/josm/plugins/imagery/tms/TMSLayer.java
(revision 24571)
+++ src/org/openstreetmap/josm/plugins/imagery/tms/TMSLayer.java
(working copy)
@@ -15,7 +15,11 @@
import java.awt.event.MouseEvent;
import java.awt.font.TextAttribute;
import java.awt.geom.Rectangle2D;
+import java.awt.image.BufferedImage;
+import java.awt.image.BufferedImageOp;
+import java.awt.image.ConvolveOp;
import java.awt.image.ImageObserver;
+import java.awt.image.Kernel;
import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
@@ -685,10 +689,31 @@
int img_x_end = img_x_offset + (int)(target.getWidth() *
imageXScaling);
int img_y_end = img_y_offset + (int)(target.getHeight() *
imageYScaling);
+boolean sharpen=true;
+Image myImg;
+if (sharpen sourceImg instanceof BufferedImage) {
+Kernel kernel = new Kernel(3, 3, new float[] { -1, -1, -1,
-1, 9, -1, -1, -1, -1});
+BufferedImageOp op = new ConvolveOp(kernel);
+
+int w = sourceImg.getWidth(null);
+int h = sourceImg.getHeight(null);
+BufferedImage tmp = new BufferedImage(w, h,
BufferedImage.TYPE_INT_RGB);
+
+for (int i=0; iw; i++) {
+for (int j = 0; j h; j++) {
+tmp.setRGB(i, j,
((BufferedImage)sourceImg).getRGB(i, j));
+}
+}
+myImg = op.filter(tmp, null);
+} else {
+myImg = sourceImg;
+out(can not sharpen +sourceImg.toString());
+}
+
if (debug) {
out(drawing image into target rect: + target);
}
-g.drawImage(sourceImg,
+g.drawImage(myImg,
target.x, target.y,
target.x + target.width, target.y + target.height,
img_x_offset, img_y_offset,
Sharpening could be an option in the context menu.
This is the patch to reproduce as well as the exception text.
Index: src/org/openstreetmap/josm/plugins/imagery/tms/TMSLayer.java
===
--- src/org/openstreetmap/josm/plugins/imagery/tms/TMSLayer.java
(revision 24542)
+++ src/org/openstreetmap/josm/plugins/imagery/tms/TMSLayer.java
(working copy)
@@ -15,7 +15,11 @@
import java.awt.event.MouseEvent;
import java.awt.font.TextAttribute;
import java.awt.geom.Rectangle2D;
+import java.awt.image.BufferedImage;
+import java.awt.image.BufferedImageOp;
+import java.awt.image.ConvolveOp;
import java.awt.image.ImageObserver;
+import java.awt.image.Kernel;
import java.io.IOException;
import java.net.URI;
import java.net.URISyntaxException;
@@ -672,10 +676,21 @@
int img_x_end = img_x_offset + (int)(target.getWidth() *
imageXScaling);
int img_y_end = img_y_offset + (int)(target.getHeight() *
imageYScaling);
+boolean sharpen=true;
+Image myImg;
+if (sharpen sourceImg instanceof BufferedImage) {
+Kernel kernel = new Kernel(3, 3, new float[] { -1, -1, -1,
-1, 9, -1, -1, -1, -1});
+BufferedImageOp op = new ConvolveOp(kernel);
+myImg = op.filter((BufferedImage)sourceImg, null);
+} else {
+myImg = sourceImg;
+out(can not sharpen +sourceImg.toString());
+}
+
if (debug) {
out(drawing image into target rect: + target);
}
-g.drawImage(sourceImg,
+g.drawImage(myImg,
target.x, target.y,
target.x + target.width, target.y + target.height,
img_x_offset, img_y_offset,
java.awt.image.ImagingOpException: Unable to convolve src image
at java.awt.image.ConvolveOp.filter(Unknown Source)
at
org.openstreetmap.josm.plugins.imagery.tms.TMSLayer.drawImageInside(T
MSLayer.java:684)
at
org.openstreetmap.josm.plugins.imagery.tms.TMSLayer.paintTileImages(T
MSLayer.java:735)
at
org.openstreetmap.josm.plugins.imagery.tms.TMSLayer.paint(TMSLayer.ja
va:993)
at org.openstreetmap.josm.gui.MapView.paint(MapView.java:516)
at
Re: [josm-dev] Sticky Tags Feature
Ian Dees wrote: Hi JOSM Devs, I'd like to implement a feature in JOSM that applies the tags from the clipboard to every new way or node created. I think this would be useful for creating powerlines (apply power=tower to every new node in the way) or for a set of buildings along a street (addr:street=* to every new building). Does anyone have any ideas for how the interface for this might work? Maybe a menu with toggles in it? We had one suggestion by a user that goes slightly in this direction: On the main map you would have a certain area (clipboard). You could copy or drag objects onto this area, the important idea is, that it stays fixed regardless how you scroll or zoom the map. In combination with Ctrl-C, Ctrl-Shift-V (paste tags) you would have easy access to often used tags and geometries. Maybe there would be a way to mark objects in the clipboard as auto apply, i.e. all it's tags are sticky tags. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Bing imagery now available in JOSM
Hi, thanks to fast development by Ian Dees, Bing imagery can now be used in JOSM. You'll need the latest version of josm (3688) ( http://josm.openstreetmap.de/download/josm-snapshot-3688.jar ) and an updated version of the slippy map plugin. Then go to Preferences (F12) Slippy map and choose Bing Aerial Maps as Tile Source. Have fun! Sebastian PS: In case you don't know, it's up and running in Potlatch 2 for some time already. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Bing imagery now available in JOSM
Upliner wrote: Hello all. I'm currently working on combination of wmsplugin and slippymap plugin. It would be called imagery plugin and I plan to publish the first version within next several hours. This is great news - hopefully we'll see even more improvements. :) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] sac_scale in JOSM - RFC for change of translation
Fichtennadel wrote: On Mon, Nov 29, 2010 at 5:59 PM, Dirk Stöcker openstreet...@dstoecker.dewrote: I had a look at the description and they are pretty straighforward. I see no problem to express each of the steps in 3 to 4 words. Why not simply doing so? That would fit perfectly in the selection box without needing too much changes. Here we go, these are my proposals for translation: German: hiking=Einfacher Spazier- oder Wanderweg mountain_hiking=Wanderweg demanding_mountain_hiking=schwieriger Wanderweg alpine_hiking=schwieriger alpiner Steig demanding_alpine_hiking=schwieriger alpiner Steig, Kletterstellen difficult_alpine_hiking=schwieriger, gefährlicher alpiner Steig, Kletterstellen Certainly better than the current translation. alpiner Steig sounds more serious than alpiner Wanderweg In T2 there can be already fall hazard and the picture for T4 in http://alpen.sac-cas.ch/html_d/archiv/2002/200204/ad_2002_04_18.pdf looks somewhat terrifying to me. :) Maybe this danger is already implied, I'm from the flatlands, so I don't know much about hiking. Btw.: You can use html markup to create a multiline entry, e.g. htmliWanderweg/ibrnbsp;nbsp;ausgeglichene Steigung, Absturzgefahrbrnbsp;nbsp;nicht ausgeschlossen/html (The height of the sac_scale field in the preset dialog will grow accordingly, but I would fix this little flaw later.) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] sac_scale in JOSM - RFC for change of translation
Dirk Stöcker wrote: Actually I oppose this solution, as it is against the basic idea of how OSM works. When some mappers (accidentally) spoil the work of many others, this is also not the way osm is supposed to work. Extending the description in the presets might be a solution, but I'm not sure how this should be done. Hey, the discussion was not about destroying work of others. He blamed that people enter ways with accordinging to his view wrong classification. For me that is the typical issue we also had for streets and everything else- People design a classification sheme and get angry when it is not used as was planned. But for OSM no experts are mapping, so you need to define a sheme which is understood by novice users as well. You can't expect from someone mapping tracks to be experts in the classification of hiking ways. As already mentioned, SAC scale is defined by the Swiss Alpine Club, so if you say the classification is not well suited for osm, this would mean to remove it from the presets and wait for someone to invent a better classification. No one actually wants that, so we are left with 2 choices: (a) Truncate description to official reference numbers T1-6, this way viewer people will use it, but at least no harm is done and (b) provide sufficient explanation in the preset dialog. Status quo is no solution and (b) requires someone to do the work, so it seems sensible to me to go with option (a) in the meantime. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Tools menu too long when plugins installed
Hi, it has been reported, that with many plugins installed, the tools menu grows such that some entries become invisible on a normal monitor. (See http://josm.openstreetmap.de/ticket/5638 for an example.) Any ideas how to fix this? We could move the simpler tools to a new top level menu, but how to call it? Or we could force the plugins into another menu, but i guess that would only delay the problem... Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] sac_scale in JOSM - RFC for change of translation
Dirk Stöcker wrote: On Thu, 25 Nov 2010, Fichtennadel wrote: I see your point, but if you look at the template it's not possible to put a long description in the list of values for sac_scale. And the current information is misleading, so the idea has been better none than wrong. There is already a link to the wiki at the bottom of the template window, which links to path and from there to sac_scale. If your descriptions are so misleading, then find others. OSM is no read the wiki and when you understood it start project. It is a start and work project. When your classification is misleading, so users use it wrong in your eyes, then classifications needs to be reworked. And we are already relying on the users to actively search for the meaning of tracktype = gradeN, so this seems to work ok and is feasible. No. The grades are translated as well and they have a easy definition. In usage of these is in no way accurate. Well, if you work with English language, you only see grade1-6, but in other languages you get additional explanation. The German translation isn't that accurate either: Grad 1 (Asphalt), Grad 2 (Schotter), Grad 3 (unbefestigt), Grad 4 (leicht bewachsen), Grad 5 (stark bewachsen) E.g. grade2 misses the or densely packed dirt/sand part and the main difference between grade3 and grade4 is (according to the wiki) not the vegetation but the composition of way material. Sometimes things simply cannot be described by 1 or 2 words. ;) I'm also not totally happy with this solution, but we didn't come to any better one during the discussion. Actually I oppose this solution, as it is against the basic idea of how OSM works. When some mappers (accidentally) spoil the work of many others, this is also not the way osm is supposed to work. Extending the description in the presets might be a solution, but I'm not sure how this should be done. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Improved multipolygon plugin
Viesturs Zarins wrote: Hi All, Just commited improvements to the multipolygon plugin. Changes: - Can now handle polygons consisting of several unclosed ways. - Supports multiple outer ways and deeper nesting. - Detects crossings. - Opens relation editor. It does not open the relation editor for me. I have not yet commited a new version to the dist folder. Could someone please try it out? And what is the policy of pushing new versions? Can I just commit a new version into the dist folder, or is there some review? I'm in the mood of adding plugins to JOSM core... :) Are you planning more improvements or is it ready so far? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How to scale / resize objects ?
M∡rtin Koppenhoefer wrote: 2010/11/20 Olivier Croquette m...@ocroquette.de: - modifier for X / Y scaling only This is often done in applications with dedicated buttons (x-button, y-button) to restrict/allow modification only in this direction or even more often with a selection bracket (surrounding rectangle with a total of 8 squares to grab and drag at corners and in the middle of the selection bracket's sides). IMHO those 2 solutions are both user friendly (the bracket-one maybe more, you find it in many applications and it could also be used to rotate if you drag slightly outside the corners. Usually [shift] is used to maintain proportions). +1 a selection rectangle with drag-able corners and sides would be very intuitive. There was an incident where an entire district of Bonn was accidentally rotated and uploaded by an inexperienced user. :) So it could be separated more clearly by having a dedicated mapmode for scale rotate. The selection mapmode (S) is quite overloaded with modifiers already. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Removing scale_max / scale_min from elemstyles.xml? / mapcss
Ulf Lamping wrote: Am 15.11.2010 23:48, schrieb Sebastian Klein: No objections. Maybe we can switch the default value of mappaint.zoomLevelDisplay from false to true afterwards. This way authors of external style sets can create fancy scale dependent styles and don't need to bother their users with advanced preferences configuration. Makes sense. To avoid any hassle, we may want to remove the scale entries first, wait one or two releases and then change the default value. Generally I don't see any problem since the xml style is distributed with the binary. But users who have loaded a modified copy of elemstyles.xml would be affected. Btw., I have mostly completed mapcss support (which offers zoom dependent markup, as well), but it will take some time to integrate into JOSM. A lot of existing code needs to be adapted and I don't want to break too much... E.g. the z-index property does not work well with the way multipolygons are drawn in the PaintVisitor. Do you keep an eye on the performance? Having a new rendering engine that is able to display a lot of fancy stuff but is also a lot slower might be the wrong direction ... ;-) Yes, I'm aware of this. Currently, the new PaintVisitor is slightly slower (basically due to z-level ordering) but not significantly ( 5% I think, but I will do careful benchmarking). All styles are cached, of course, so most time is not spend in JOSM code, but with actual rendering of areas and lines. Regards, ULFL P.S: I'm not a big fan of mapcss, as the XML we currently have makes it a lot easier for externals to automatically analyze the rendering (and preset) rules files (as e.g. Jochen is currently doing it for taginfo). Parsing the css alike syntax isn't impossible, but obviously harder compared to XML that a lot of people already know how to do - including myself ;-) Sure, it's not that easy to parse, but it's a matter of priority. E.g. you don't design a programming language such that compiler has an easy job to parse the source code, but from a user perspective. (Otherwise Lisp would be much more popular and Perl much less. :) ) Another reason for supporting this format is its use in potlatch 2, so we might get a second style in JOSM for free. Maintaining a single style must be a lot of work already, so why not join forces a little. I'm not about to remove the xml style support, though. It will still be available and you can even load style files with different formats at the same time. (But as I said, don't expect it before Christmas. :) ) Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] AddPrimitivesCommand constructor
Roman Byshko wrote: Hi guys, currently AddPrimitivesCommand does not have a constructor where OsmLayer can be give as a parameter. I'm developing a plugin right now and need this option. May I ask what the plugin if for? The patch in the attachment adds this functionality. Would you please commit it into the trunk? Done. (in [3660]) Regards, Roman p.s. sorry if the path in the patch is wrong... if so, how it should be? Had no problems with the path, but it is preferred to put patches in a Trac ticket with [PATCH] topic of the patch as title. This way we can discuss the patch without spamming the mailing list and, more importantly, we won't forget about it. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] TIFF support
Olivier Croquette wrote:
Hi !
When I call this code from JOSM :
String[] formats = ImageIO.getReaderFormatNames();
for (String f:formats) {
System.out.println(f);
}
It outputs tiff (lowercase, other variants like tif, TIF and TIFF are
missing).
When I run the same code a simple-hello-world-like program, it doesn't.
I tried the -verbose option of the Java VM, and it gives me :
[Loaded com.sun.imageio.plugins.tiff.TIFFImageReaderSpi from
/Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Classes/classes.jar]
The question is : what in JOSM causes the loading of this class ?
Google sais this class comes from Java Advanced Imaging (JAI) which is
loaded by the ImportImagePlugin. Hope this helps...
Sebastian
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] EastNorth immutable and cloning
Olivier Croquette wrote:
Hi all
While implementing my improvements for PicLayer, I came upon 2 issues in the
core code.
NB: while I know other languages quite well (in particular C++ and Perl), I am
a Java newbie. That may explains things ;-)
1) First, it's documented as a immutable class :
/**
* Northing, Easting of the projected coordinates.
*
* This class is immutable.
*
* @author Imi
*/
public class EastNorth extends Coordinate {
But Coordinate.setLocation(x,y) allows to modify the state of EastNorth
instances, so in my understanding, EastNorth is mutable, and therefore the doc
is wrong.
Another example is the hierarchy of classes CachedLatLon LatLon
Coordinate. Here LatLon is immutable, but Coordinate and CachedLatLon is
not. I guess it is immutable by contract so it is simply forbidden to
use setLocation() on a LatLon object (although it is not technically
enforced by the compiler).
Call it bad design, pragmatism or insufficiency of the OOP paradigm.
2) In NavigatableComponent :
/**
* @return Returns the center point. A copy is returned, so users cannot
* change the center by accessing the return value. Use zoomTo instead.
*/
public EastNorth getCenter() {
return center;
}
The doc is misleading. With the statement A copy is returned
I agree, doc should be updated.
Sebastian
___
josm-dev mailing list
josm-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Removing scale_max / scale_min from elemstyles.xml?
Ulf Lamping wrote: Hi! Quite a while ago, I've experimented with the map display to show/hide features only at a specific zoomlevel of the JOSM map display. At that time, the display was so slow that removing specific features from the map was an idea to speed up the map display. Since then I've spend quite some effort to increase the map speed, which made the whole scale tag thing obsolete IMHO. The two values of scale_max / scale_min that are currently spamming elemstyles.xml (the mappaint style file) are actually unused AFAIK. Are there any objections against removing the remaining traces of these experiments? No objections. Maybe we can switch the default value of mappaint.zoomLevelDisplay from false to true afterwards. This way authors of external style sets can create fancy scale dependent styles and don't need to bother their users with advanced preferences configuration. Btw., I have mostly completed mapcss support (which offers zoom dependent markup, as well), but it will take some time to integrate into JOSM. A lot of existing code needs to be adapted and I don't want to break too much... E.g. the z-index property does not work well with the way multipolygons are drawn in the PaintVisitor. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New tools plugin?
Done. http://trac.openstreetmap.org/changeset/24236/applications/editors/josm Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Process to commit a patch ?
Axel Kollmorgen wrote: On 2010-11-13 20:50, Dirk Stöcker wrote: For everything else we are much happier when you just do it instead of bothering us with Trac tickets ;-) hm - wasn't aware (or didn't think) of that. so if i had a svn account, could i just check in my gpx upload patch (which makes gpx upload work with oauth, among others)? this would indeed speed up things. Yes, it is also easier for us, because you would be completely responsible for what you commit. :) @ Sebastian / other committers: the refactoring of the core code for a cleaner patch for [2], as discussed here on the list, will take some time. would you mind looking at the patch that exists now and, if possible, commit it - so we have a working solution now? thanks! Sure, no problem: http://trac.openstreetmap.org/changeset/24239/applications/editors/josm Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Process to commit a patch ?
Olivier Croquette wrote: Hi ! I would like to commit the patch below to increase the precision of the PicLayer rotation and scaling. Since i have a SVN account, I can technically just do it, but what's the process to do so ? Just do it. :) Is there a review ? A defined process ? No, only things that should go without saying, e.g. * announce larger and potentially controversial changes on the mailing list * fix the bugs you have introduced. Some bugs are noticed right away, others only several months later. We assign categories to the reports, to make monitoring more easy: http://josm.openstreetmap.de/query?status=assignedstatus=needinfostatus=newstatus=reopenedcomponent=Plugin+piclayercol=idcol=summarycol=statuscol=ownercol=typecol=prioritycol=componentdesc=1order=id * read https://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins especially the part about updating the plugin * have fun Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] GPX upload?
Axel Kollmorgen wrote: On 2010-11-07 06:57, Sebastian Klein wrote: you are right, DirectUpload plugin could benefit a lot from the code in OsmApi. Actually I have the feeling it might be easier to add the gpx upload code directly to the OsmApi class. (Or is there an easy way to hook in?) if it had been easy, i would have done it :) i don't think it should go directly into the OsmApi class, but into a specialized class. suggestions are welcome. I'd say it would fit in (only api relevant code), but do what you think is best. If you like, you can fully integrate the plugin into JOSM core, this is planned anyway. i'll see what i can do. At the moment, the plugin doesn't seem to use the server url from the preferences. That's why i couldn't test with the development server (http://api06.dev.openstreetmap.org/api). But this shouldn't be a problem, when OsmApi is used, right? no, it shouldn't be a problem then. if the api works. when i tested, http://api06.dev.openstreetmap.org/oauth/... gave me constant 401 Invalid OAuth Request errors, so i had to test with the default url, anyway. Are you able to upload to the dev server using oauth? It works, but you have to change the advanced oauth properties to the values in [1]. (Or register JOSM yourself, but it is supposed to be done only once per application) For some reason Fully Automatic method does not work for me, but Semi Automatic is fine. (And don't forget to create an account on the dev server, the 2 systems are completely separated.) * the enabled state of the upload traces menu entry depends on the layer selection in `LayerListDialog`. but while `LayerListDialog` does handle list selection events, and while you can hook into added, removed, and renamed layers via `addLayerChangeListener()` [1], there is no way for outsiders to add a listener to layer *selection* change events. i know of at least one plugin that would need this functionality as well [2], so it seems to be a reasonable thing to add. Currently, only the buttons at the bottom of the layer list react to selection changes in that list, so making other parts of the application selection aware is a major change in gui logic. I'm not saying it is bad per se, but has to be thought through. It should be enabled, whenever a gpx layer is present. So i don't understand why you removed that code. Then, a selection combobox like for photo synchronization would be nice. (Or a list of all gpx layers with checkboxes in front?) Of course, the selected layer should be the default entry. In addition, i'd suggest an 'upload gpx' entry in the right click menu of the gpx layer. it should be enabled when a gpx layer is selected (that's part of changed the way the gpx layer to be uploaded is selected among all open layers ). as i say above, this information is not accessible by plugins. what happens now is that if no gpx layer is selected, the upload trace dialog pops up, but says no gpx layer selected and doesnt let ypu upload anything. i just got an idea for how to clevery solve this: remove the upload traces toolbar button and put it into the context menu of the gpx layer. no is_enabled check needed anymore: if there is no layer, there is no context menu. also no check to see which layer has to be uploaded. it also seems more intuitive to me. what do you think? Sounds good, the only complication is to educate users to find the new entry in the right click menu - let's see how it works out. [1] http://api06.dev.openstreetmap.org/ OAuth details for JOSM: Consumer Key: RPbHKwlBnolU0N0z1WeAUg Consumer Secret: wnDRp3v7S9Ub8KXQ1wmEuJj0oqq2PtsqnyUGiBtIMWQ Request Token URL: http://api06.dev.openstreetmap.org/oauth/request_token Access Token URL: http://api06.dev.openstreetmap.org/oauth/access_token Authorise URL: http://api06.dev.openstreetmap.org/oauth/authorize Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] New tools plugin?
Hi, there have been a couple of code submissions lately that add new entries to the tools menu: #5563 - Unglue relation (by Kalle Lampila) In a similar way that a single node is shared by 2 ways and you like to unglue it, there are sometimes 2 relations (e.g. multipolygon) that have the same object as member (e.g. the boundary way). This tool creates a private copy for each parent relation. (So in the example, the 2 multipolygon areas can be separated.) #5577 - Add nodes on intersections action (by Upliner) Used to create nodes at the intersections of the selected ways. This is already possible right now (double click on the intersection point) but this feature is kind of hidden and a side effect of snap to way. On top of that, it is inconvenient for a larger grid of ways. #5613 - Split Object Action (anonymous submission) Split a closed way, but close both way parts at once. This could be useful e.g. for creating terraced buildings, subdividing landuse areas, etc. We could add these directly to JOSM core, but (except for #5577) it may be hard to find a catchy name and a good icon such that even a newby user can understand what it does. My idea would be, to revive the tools plugin to provide these and similar specialized features for advanced use. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] GPX upload?
Hi Axel, you are right, DirectUpload plugin could benefit a lot from the code in OsmApi. Actually I have the feeling it might be easier to add the gpx upload code directly to the OsmApi class. (Or is there an easy way to hook in?) If you like, you can fully integrate the plugin into JOSM core, this is planned anyway. At the moment, the plugin doesn't seem to use the server url from the preferences. That's why i couldn't test with the development server (http://api06.dev.openstreetmap.org/api). But this shouldn't be a problem, when OsmApi is used, right? Axel Kollmorgen wrote: * added tag, description, and privacy history and autocomplete to the upload dialog, * changed the way the gpx layer to be uploaded is selected among all open layers (you don't have to activate the gpx layer anymore, but just select it), and * (hopefully) simplified some of the code it took me a while: partly, because i'm new to josm development, but partly also because josm seems to make it unnecessarily hard to plug into certain components. for example, * `OsmConnection::addAuth(HttpURLConnection connection)`, which, depending on user setting, adds basic or oauth authentication headers to `connection`, is protected, requiring subclassing `OsmConnection` to access it. this method can be useful for other plugins; also, it only works on `connection` and doesn't use internal state of `OsmConnection` (does it?). so why not making it public (and possibly static)? * for the actual trace upload, i would have liked to hook into `OsmApi::sendRequest()`, which does most of what is needed, incl. progress monitoring and error checking. however, this method is private even, and it does some specific stuff which clashes with gpx upload (eg. `setRequestProperty(Content-type, text/xml)` - for gpx upload, this would have to be multipart/form-data; boundary= + BOUNDARY). would it make sense to generalize this method so it is usable for both osm and gpx uploads? * the enabled state of the upload traces menu entry depends on the layer selection in `LayerListDialog`. but while `LayerListDialog` does handle list selection events, and while you can hook into added, removed, and renamed layers via `addLayerChangeListener()` [1], there is no way for outsiders to add a listener to layer *selection* change events. i know of at least one plugin that would need this functionality as well [2], so it seems to be a reasonable thing to add. It should be enabled, whenever a gpx layer is present. So i don't understand why you removed that code. Then, a selection combobox like for photo synchronization would be nice. (Or a list of all gpx layers with checkboxes in front?) Of course, the selected layer should be the default entry. In addition, i'd suggest an 'upload gpx' entry in the right click menu of the gpx layer. But the GUI is not the most important, if the authentication works like it should, this would already be a big step forward. * also, while doing the history comboboxes, i found many code snippets like this: ListString descHistory = new LinkedListString(...); // we have to reverse the history, because ComboBoxHistory // will reverse it again in addElement() Collections.reverse(descHistory); if we do it like that all over the place, wouldn't it make sense to do the reversion in ComboBoxHistory? Yes, could be done. But it's used in some plugins, so it's annoying to change all occurrences and for very little benefit. (You are welcome to do it, though. :) ) i would much appreciate feeback to the points above. maybe i'm just not seeing the forest for the trees :) Regards, Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] i18n update issue
Claudius wrote: There seems to be an issue with the i18n update from launchpad. Many strings that were translated into German in Launchpad have not made it through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: https://translations.launchpad.net/josm/trunk/+pots/josm/de/+translate?batch=10show=allsearch=vacuum+cleaner ...and bastiK did a i18n update in r3639 on 24th ( http://josm.openstreetmap.de/changeset/3639/josm ), but still in 3640's UI those strings show untranslated. Same applies for Greengrocer and several other strings. Claudius Thanks for reporting the issue. I cannot say what went wrong, but after another update [3644], the translations are in. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM session
Hi, can you show, what you have done so far? Then it might be easier to help. Sebastian Nakor wrote: Hello, I made good progress implementing ticket #4029 (JOSM sessions) but I am stuck at some point. To be able to reorder the layers correctly, set their visibilities and so on, I need to create those layers and get the resulting layer object. Since layers are created in the background I sometimes get null pointers instead of the actual layer or when I try to re-order them, they have not been added yet to the main view. How can I make sure that I get called AFTER the layer is created and added to the main view. Thanks, N. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Disallowing certain characters in tag keys
Hi, what is the problem with escaping problematic characters? There should be build in functions for most languages, like uri_escape in Perl and URLEncode.encode in Java. This proposal [1] moves values into the key to describe conditions. (Although you could argue, it should be done like that anyway...) [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags, Sebastian Jochen Topf wrote: Hi! I am currently fighting some issues where tags with strange characters in them need to be represented in a URL for Taginfo. Lots of other websites probably will have similar issues. Characters like /, ?, , etc. have special meaning in URLs so if they appear in tags I can't have those tags in URLs. Sometimes escaping characters as %XX helps, sometimes not. And those problems are not confined to web pages and URLs only. Special characters that need escaping are often a problem. We can't really do anything about that with regard to tag values, they must be allowed to contain all those characters. But it would help at least a little if we knew those characters can never appear in tag keys. And I can't really see a legitimate reason why we need those characters in keys. Looking at the database almost all cases where they appear in keys are obvious errors. Out of the about 2 different keys, there are only about 190 keys with problematic characters in them (another about 800 with whitespace). Really the only case that I can't immediately rule out as errors or see an alternative tagging are tag keys like maxspeed:weight7.5. And with those you can already see the problems: Some of them have gt; instead of the . So I'd like us to think about whether we can disallow a few characters from appearing in tag keys. Technically this would mean changing the API to check for those characters, removing any that are already in the database (can be done with normal manual edits because there are so few cases) and adding checks to the editors so that they can give meaningful error messages. Shouldn't be too hard. So, what characters am I talking about? I haven't drawn up a complete list and we certainly would need to discuss this further. Here is a preliminary list: Whitespace Should use '_' instead of whitespace in keys, whitespace are also very confusing for users, especially at beginning and end of a text. /+?#;%' Special characters in XML, HTML and/or URLs. \' Characters often used for quoting. =Because its used in many places as the separation character between tag key and tag value. If we disallow this, we can always treat one string like foo=bar as k:foo, v:bar without any ambiguities. This is a small list of special characters, all other characters should still be allowed. That means tag keys can still be in Chinese or whatever. We'd just disallow a few characters of which we know that they will make problems again and again. And to emphasize this again: I am only talking about tag keys. Tag values must be allowed to contain the full Unicode set of characters. Jochen ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] EPSG:31287 projection
Hi Georg, you did just the right thing, i.e. open a ticket and link the changes there. On the at-mailing list, there where reports about an offset of a view meters. Have the reasons been investigated? Could be a jmapproj bug or incorrect wms... Sebastian Fichtennadel wrote: Hello, I've created an EPSG:31287 projection module, using jhlabs Java Map Projection Library (which is doing all of the work actually). I would like to contribute this to JOSM, so here are my questions how to do this. First of all: how to submit code? I'm a little bit reluctant to commit directly to svn, as this is my first time. ;-) Furthermore I'm using this jhlabs library for the calculation, which is licensed under the Apache License, Version 2.0 (see http://www.jhlabs.com/java/maps/proj/). As far as I understand this should be compatible with JOSM's GPL license. Is it ok to use this library in JOSM? If yes, shall I include the jar file (which is what I'm doing in my local build) or shall I include the source in JOSM's source tree? I've alreay created ticket 5532 in trac, but I couldn't resist to try it myself ;-). kind regards, Georg ___ 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] My first plugin: DirectDownload (and some help needed)
Hi, For a relatively simple example, see http://trac.openstreetmap.org/browser/applications/editors/josm/plugins/photo_geotagging/src/org/openstreetmap/josm/plugins/photo_geotagging/GeotaggingAction.java#L161 Does that help? Sebastian Hartmut Holzgraefe wrote: Hi, i finally sat down over the weekend to create my first JOSM plugin to be able to download tracks i previously uploaded to osm.org directly into JOSM without having to do the download via browser first and then having to find and open the locally downloaded gpx file with JOSM. A few details and links to current source and a compiled .jar can be found on http://www.php-groupies.de/blogs/archives/34-My-first-JOSM-plugin-Direct-GPX-track-download.html Right now i'm doing synchronous download of the track list so the download dialog will only show up after the track list has been loaded completely. For rather obvious reasons i'd like to have a progress bar dialog show up during that operation, but looking at how these are implemented in JOSM i've lost track of what is where and how it all plays together. So i'm looking for a bit of help in this area from someone who has already done some work in that area and knows how the whole thing ticks ... ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Expanded functionality of Join Areas action
Hi, I wonder if the user would expect all these features from a Join Areas command. How would you call it then, Swiss Army Knife for Areas? Why not have one tool for joining areas and another tool for creating them? (Just in case you don't know already: There are Multipolygon creation plugins (with very limited functionality) and a class data.osm.visitor.paint.relations.Multipolygon to detect inner and outer rings.) The multipoly plugin will be included in JOSM core as soon as it has all features that you would expect from such a tool. (E.g. create multipolygon from several unclosed ways that together form a closed way.) So you can either get svn access (if you don't have already) and hack on the multipoly plugin or simply post the patch for josm core at the bug tracker. Sebastian Viesturs Zariņš wrote: Hi, I am new to this list, but not new to JOSM. I would like to propose expanded functionality of Join Areas command and would like to hear your comments. Let's make it into a multipolygon making tool. I propose two new use cases: - select outer and inner way that have no intersections. Joining them makes a multipolygon, transfers all relevant tags from outer way to the multipolygon. - select several unclosed ways that together form a closed way. Joining them makes a new multipolygon. Ultimately I see the Join areas as a tool to Make an area out of the selected ways, no matter what it takes and the tool will do all that is necessary to do so. I am willing to implement the change, and have sufficient experience on improving existing current implementation of Join Areas ( see bug #5179). Cheers, Viesturs ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Expanded functionality of Join Areas action
Viesturs Zariņš wrote: On 2010.10.07. 14:29, Sebastian Klein wrote: The multipoly plugin will be included in JOSM core as soon as it has all features that you would expect from such a tool. (E.g. create multipolygon from several unclosed ways that together form a closed way.) So you can either get svn access (if you don't have already) and hack on the multipoly plugin or simply post the patch for josm core at the bug tracker. I will take a look at the multipoly plugin. I expect to reuse much of code written for Join Areas and would not like to copy it around. That was the technical reason behind making a Swiss army knife. I don't have svn access, can you give me one to split the shared code out into a separate tools class ( GeometryAlgorithms )? Sorry I was not very clear (also i have no privileges to grant svn access): For the openstreetmap.org svn (including the plugins) see: http://wiki.openstreetmap.org/wiki/SVN#Getting_Commit_Access It shouldn't be problem to get an account there. Access to JOSM core repository is more restricted. (see http://josm.openstreetmap.de/wiki/DevelopersGuide/SVN_Account) After a few good patches, it should be much faster to get your changes committed, especially some refactoring like you suggest is no problem. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM map display bugs - I'm not related to this ...
Hi, are you referring to #4623? I'm sure it is absolutely coincidental and no one wants to talk down your contributions to josm. Please accept that within 2 years a view bugs in the painting code slip through, considering that the internal structure of josm has changed a lot. If you insist, we could add a new trac category Map Painting problems assigned to 'team', but I'm not sure it helps. Sebastian PS: Why not inspire us with your professionalism, by contributing more code ;) Ulf Lamping wrote: Hi! Some time ago, I've spend a significant amount of time to speedup JOSMs map display, and take extreme care that no map display bugs appear. All was well ... For quite a while now, JOSM map display shows a significant amount of (re-)rendering bugs and all kinds of corresponding problems. Sometimes, only if you click on a map area things fully appear ... So it seems that someone tried to improve the JOSM internals without taking extra care to prevent such display bugs to appear :-( What really bugs me: these display bugs now appear under my name in JOSM trac. For some time now I maintain (more or less) what's get's on display on the JOSM map. But I'm not willing to take care of bugs others introduce ... Please provide me with a solution that seperates me from this unprofessional behaviour or remove me from the list of JOSM trac maintainers completely ... Regards, ULFL ___ 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] ImportImagePlugin - contact authors?
Hi, ImportImagePlugin has been added to svn, recently. It would be great to have it published for all users, but there has been a problem to contact the authors (Christoph Beekmans, Fabian Kowitz, Anna Robaszkiewicz, Oliver Kuhn, Martin Ulitzny according to the build file). Fabian alias user123 created a trac ticket (#5447) but did not respond to later comments. I also emailed Oliver Kühn, but apparently he isn't the same as above Oliver Kuhn. Anyone knows anything about this project? (Google does not...) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Windows-Installer: default projection is WGS84
Ulf Lamping wrote: Am 05.08.2010 18:51, schrieb Sebastian Klein: Hi, I just tried the windows installer and it creates the following default preference file: projection=org.openstreetmap.josm.data.projection.Epsg4326 layerlist.visible=true selectionlist.visible=true commandstack.visible=true propertiesdialog.visible=true osm-server.url=http://www.openstreetmap.org/api laf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel plugins=openstreetbugs;remotecontrol;validator;wmsplugin Especially interesting is the first line, where it puts WGS84 as default projection. Why is that? Shall we change it to JOSM's default projection (Mercator - EPSG:3857)? I would trim this file to laf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel plugins=openstreetbugs;remotecontrol;validator;wmsplugin everything else takes a proper default value. (Which was not always the case, so I understand it used to be necessary in the past.) Puh, I've added those a long time ago ... IIRC, the projection thing was having round roundabouts vs. right WMS display - but this is really a long time ago and I really can't remember. The more I was surprised, there were so few complaints about egg shaped roundabouts... Only recently in the forum. The other things might be only historical and easily removed. Done. The current installer has only laf=... and plugins=... in the default preference file. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
M∡rtin Koppenhoefer wrote: 2010/9/8 Dirk Stöcker openstreet...@dstoecker.de: On Wed, 8 Sep 2010, André Riedel wrote: 1-2 days, but I don't expect serious bugs - we usually get these in latest already :-) A little but nasty bug. http://josm.openstreetmap.de/ticket/5397 This one has been closed as irreproducible. It can't be that bad. Actually I find JOSM a little bit buggy recently (I think it was introduced with autosave): on startup it always tells me that it wants to recover a autobackup because it thinks that JOSM crashed last time, which is not the case. I do discard but next time it asks me again, even if I did nothing except of restarting. When I do restore instead nothing happens either. This is news to me, would be best to have a trac ticket for it, but anyway: As a quick diagnosis you could observe the content of the autosave folder in the josm preferences directory (%APPDATA%\JOSM or ~/.josm). Does it delete any file when you click discard? Is it the same if you not load anything and just repeatedly start and close JOSM (each time discarding autosave)? What is your OS? The other issue is while closing: I always get the warning that I forgot to upload, even though I already uploaded. And indeed on upload attempt it says: nothing to upload. It also warns if the file is not saved. Are you sure the warning is about upload? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
Dirk Stöcker wrote: On Wed, 25 Aug 2010, Dirk Stöcker wrote: as we forgot the tested release in August, we now can schedule a new release in time for September. So please prepare everything for a new release in first week of September. Any objections against 3514 as tested? Ciao No. Do we wait for bug reports by users of the new tested and how long shall we wait before adding new stuff? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] GPX upload?
Morten Kjeldgaard wrote: Hi, GPX upload from within JOSM stopped working for me a good time ago. SInce then, I have not uploaded any tracks, which is a shame, since I normally think of tracks as documentation for new map features (in case someone postulates that features have been copied from somewhere else.) The error message I get when the upload fails is that the password is missing. But I have been using the oauth methond for quite a while now, and it occured to me, that the failure of GPX upload may have to do with that. That is correct, the direct upload plugin does not support oauth at the moment. So either you have to switch back to basic authentication or upload via web interface. Another option would be to fix the plugin. ;) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New Tested
Stephan Knauss wrote: M∡rtin Koppenhoefer wrote: I'm talking about plugins that redefine common standard keys. That is IMHO bad for the usability. Is this possible? I always thought that once a shortcut is defined it can only be changed by the user. First one wins... The problem is, plugins are loaded first, so they win. :) It is not hard to fix the plugins that try to grab a well known shortcut, but we have to know about it! Please create a ticket on trac, if you find such a case. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes and ways via remoteControl
Bodo Meissner wrote: Dirk Stöcker wrote: If you can automate it, it may work. this is impossible. I cannot automatically detect if there are incompatible changes in remotecontrol. Otherwise you will find, that updating the version tends to be forgotten more often than it is updated. We aren't talking about hot code that changes every now and then as you add new features. It is supposed to be a minimal, *stable*, interface that handles the registration of callbacks. The change of the protocol is only necessary, when there is a fundamentally new way of defining the callback. E.g. if remotecommand preferences need to be extended, you could simply subclass remotecontrol.PermissionPref.java and no change in version number would be necessary! You are right. If I go this way I can only add a comment that updating the API version is important, but I cannot make sure that I or future developers will never forget to update it. In my opinion, this should suffice. If some future developer should ignore the notice and forget to update the version number, it will be pretty obvious: * wmsplugin does not compile * every user that has installed wmsplugin and (most recent) remotecontrol plugin will get an exception on start. Fixing it will be relatively easy, so not much harm done. The only possible thing would be to automatically update the API version on every change. But in this case it does not provide any advantage over using the SVN revision. I think I will keep it simple: WMSPlugin will not only check for a minimum SVN revision of remotecontrol but also for a maximum revision. Whenever remotecontrol gets recompiled with a new SVN revision, wmsplugin has to be updated. I will replace console messages with a normal message window to inform the user about this incompatibility. What do you think about this solution? This breaks the link between wmsplugin and remotecontrol much more often than it is necessary. In addition, if there are new plugins that hook into remotecontrol, it is massive work for anyone who does even minimal changes to remotecontrol (e.g. spelling correction): Each time they have to update every plugin that registers remotecontrol and change version numbers in the code! Overall, I don't think this suggestion would be an improvement. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS and remote-control
Stephan Knauss wrote: Sebastian Klein wrote: So either the common protocol must be included in Josm core or another possible solution would be to use reflection. How about adding the basic functionality into core? Providing the listener and accepting commands. By default it will have no commands included. It provides a capabilities command that reports back the supported commands and their protocol version. Plugins can register new commands with the core similar than they would register other functionality (like shortcuts and such). So the core will know what commands are available and which plugin handles them. It can also reject registrations of commands that already exist. It can provide a single configuration dialog where the plugins can append their plugin-specific settings. Comments? I consider this is a viable solution. It fixes the problem of version dependency between wmsplugin and remotecontrol. The core part of remotecontrol would go into JOSM main, but it would not even listen to some network port, if no commands are registered. (This should satisfy the paranoid people.) remotecontrol plugin would then provide a basic set of commands and register them with JOSM core. Each time the protocol of the callback changes, developers have to update the Mainversion of all the remote-controlling plugins. (currently wmsplugin and remotecontrol) This would fit much better in the current framework. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes and ways via remoteControl
Bodo Meissner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.08.2010 22:40, schrieb Sebastian Klein: Bodo Meissner wrote: I added a getVersion method to remotecontrol. [...] On compatible extensions the minor version should be incremented, on incompatible changes the major version should be incremented and the minor version set to 0. What is the minor version good for? When I add a method to remotecontrol I will change the minor version only. An old version of wmsplugin can still use the new version of remotecontrol. A new version of wmsplugin that needs the new method will not accept older minor versions of remotecontrol. When I have to do incompatible changes I will change the major version. An older wmsplugin will never try to use a new major version of remotecontrol. That's why I implemented a == check for the major version and a = check for the minor version. The getVersion() method is only needed for upwards compatibility. Dependency on new features can be achieved by reading remotecontrol's svn version. But I guess it is more consistent the way you did it, so why not... Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes and ways via remoteControl
Bodo Meissner wrote: I added a getVersion method to remotecontrol. [...] On compatible extensions the minor version should be incremented, on incompatible changes the major version should be incremented and the minor version set to 0. What is the minor version good for? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes and ways via remoteControl
Bodo Meissner wrote: When I experimented with remotecontrol and wmsplugin I sometimes got NoSuchMethodException and JOSM suggested to disable the plugin, but sometimes JOSM simply hung. No console output? I will also implement a function to request the API version of the remotecontrol plugin. So in future wmsplugin will not use remotecontrol if it is too new. I should have implemented a getVersion method with my first change, but now it's too late. You can use reflection to check, if the method getVersion() exists. If not, this counts as version 0. My intention is that wmsplugin will use reflection to call the getVersion method. This will avoid any ClassNotFoundException when remotecontrol is not installed. Of course wmsplugin will call this method only if remotecontrol is loaded. When remotecontrol returns a compatible version, wmsplugin will register its remote request handler, otherwise it will display a message that it cannot use remotecontrol. Let me try to summarize: wmsplugin.WMSRemoteHandler includes (compiles against) classes from remotecontrol plugin, but does not ship these classes. It relies on remotecontrol plugin to provide them. So each time the source code of remotecontrol.PermissionPref, remotecontrol.RequestHandler or remotecontrol.RequestHandlerErrorException changes, getVersion must return a new version number. This way wmsplugin can abort the registration and avoid an instantiation that would lead to ClassNotFound error. This should be working... Anyone has a better idea? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Cancel while downloading relations
Maarten Deen wrote: I downloaded a relation which contains a lot of relations. So I selected them all and did download members. These were some 140 relations. The downloading went fast until all of a sudden it stopped. This was after about 84 relations. So I pressed cancel, expecting the downloaded relations to be in JOSM. Much to my surprise they weren't. Is there a technical reason for JOSM to discard already downloaded relations when you press cancel? I would think that there is no difference with getting them one at a time, it's only a faster way of downloading more relations. If there is no technical reason, then I'm going to enter this is a bug. Minor issues like this should be posted to the bug tracker directly. The mailing list is more for meta discussion and if you like to reach a wider audience. Anyway, thanks for reporting it. We rely on you power users to find the bugs. :) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Mailing list configuration - reply address
Hi, who is managing the mailing list? I would appreciate, if mails sent to the list would have Reply-To: josm-dev@openstreetmap.org in the header. This way you can answer more easily to the list. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Mailing list configuration - reply address
Bodo Meissner wrote: Am 19.08.2010 19:57, schrieb Simone Cortesi: a reply-to sent directly to the user is there just to prevent somebody sending a personal mail to the whole list. any sufficiently advanced mailer has a reply to all button. +1 Thunderbird has a Reply to list button. This is active when it finds some mailing list headers. A Reply-To: header makes it difficult to reply to the author. Especially the subscribers of a developers' mailing list should know how to use (and configure) their MUA. Mine hasn't. Maybe I should update... Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Mailing list configuration - reply address
Paul Johnson wrote: On Thu, 19 Aug 2010 19:52:38 +0200, Sebastian Klein wrote: Hi, who is managing the mailing list? I would appreciate, if mails sent to the list would have Reply-To: josm-dev@openstreetmap.org in the header. This way you can answer more easily to the list. Reply-To: is a human-only header, to indicate where replies to the author should go, not where replies to the list should go. Mailing lists are supposed to set List-Id to indicate the mailing list reply address, which this one does. Modern mailers (save for gmail, which Google would prefer you use Google Groups for such use) have Reply-to-List. All of OSM's lists are also carried on gmane.org as gmane.comp.gis.openstreetmap.* Not the ones I would be interested in: HOT, legal-general, osmf-talk, potlatch-dev, ... I suggest you investigate your options rather than expecting the lists to do something that doesn't comply with accepted best practices. Alright, I got it... How comes talk-de is configured like this when it is so absolutely dreadful? I think now I found the perfect solution: Ctrl-C, Ctrl-V. ;) Sorry for being a little off topic, Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Deploying third party libraries
Matthias Meißer wrote: Hi everybody, I'd like to know how the deployment system works for external libraries. I added them in Eclipse and build.xml as external .jar libs. So what can I do to make sure that they get installed to the users computer? Or does they already become part of my package? Hi, using Eclipse is fine, but you should also update the ant file so that other users can build the plugin as well. (Not everyone uses Eclipse...) The following plugins already deploy *.jar libs: dataimport, globalsat, routing, routes, openlayers, plastic_laf and toms. I guess you can do modifications to the ant file in a similar manner. If you finally publish the plugin, either use the ant script to build or check that the Manifest file created by Eclipse looks the same. Also http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins is worth reading. Best, Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS and remote-control
Bodo Meissner wrote: Hello Komяpa, I modified the plugins remotecontrol and wmsplugin. see http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl#other_commands and http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Remote_control I hope this is what you imagined. Please inform me about problems or suggestions. I think you broke wmsplugin (see #5348). You cannot add RemoteControl to the classpath for compiling and then not deploy the binaries needed to execute. At the moment, I'm not sure how to do this the right way, but please fix this as soon as possible, even if it is provisorily. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS and remote-control
Sebastian Klein wrote: Bodo Meissner wrote: Hello Komяpa, I modified the plugins remotecontrol and wmsplugin. see http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl#other_commands and http://wiki.openstreetmap.org/wiki/JOSM/Plugins/WMSPlugin#Remote_control I hope this is what you imagined. Please inform me about problems or suggestions. I think you broke wmsplugin (see #5348). You cannot add RemoteControl to the classpath for compiling and then not deploy the binaries needed to execute. At the moment, I'm not sure how to do this the right way, but please fix this as soon as possible, even if it is provisorily. There can be different conflicting versions of RemoteControl, wms and other pugins that will have support for Remote commands in the future. So either the common protocol must be included in Josm core or another possible solution would be to use reflection. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Announcing: Simple Map Editor (GSoC 2010)
Michael Daines wrote: Hello OSM, I'd like to announce my GSoC 2010 project which is nearing completion, [...] Questions, comments, and bug reports are much appreciated. Also, I plan to update the wiki page with more detailed and current information soon. I believe the editor can be production-ready with a bit more testing and polish. Let me know what you think! Great, looks really promising! Let me comment on the user interface: * It would be good to cancel the current operation if you click on the map or another object. * If you click an object far right, it is hidden by the dialog, which is kind of strange. * A highlighting on mouse-over would be very fancy. * Allow to click POIs that are part of a way. Another thing I noticed: It creates a new changeset for every operation. It should remember the changeset and add subsequent requests to it. I recommend you have a look at the JOSM presets. They are quite comprehensive have been actively maintained for a long time. Sebastian ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] questions about plugin loading
Bodo Meissner wrote: Does JOSM call a function of a plugin when all enabled plugins are loaded? This can be useful to override in Plugin class: mapFrameInitialized(MapFrame, MapFrame) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS and remote-control
Komяpa wrote: 2010/8/12 Sebastian Klein basti...@googlemail.com: Komяpa wrote: 1) Due to Landsat WMS being down and overloaded usually, we've set up a caching WMS proxy for it. JOSM URL is http://irs.gis-lab.info/?layers=landsat; Please consider updating JOSM defaults. Do you want it to show up in the list on the bottom, or make it installed by default instead of the standard landsat URL? Are you sure, you can handle the traffic? This server also provides IRS imagery for Russia for quite a long time. I'm sure it will be able to handle traffic. So, worth trying installing it by default. Done. Now, we need a convenient way to load that imagery into josm. An extenstion to josm-remote that will load specified WMS URL will be just fine. Hope somebody will write it, as I'm no java coder, unfortunately. There are some security issues when the browser has too much control over the client software. As far as I know, josm-remote has options that lets paranoid users disable some of its features if they dislike that. OK, the question is: Make it opt-in or opt-out? Let's wait till it's ready, then we can decide... Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Error messages in Josm
Jonas Stein wrote: i just had a problem with josm. A friend tried to reproduce the steps and got a different (translated) message. I suggest to add errorcodes and not to translate error messages as things get very improper. Errormessages could start with WW: warning II: information EE: error That could help to filter information. Fatal: seems to be not the best word to describe the situation. Example JOSM will not stop working for german users: Fatal: failed to locate image 'markers/Bus Station.png'. This is a serious configuration problem. JOSM will stop working. Fehler: Das Bild 'markers/Bus Station.png' konnte nicht geladen werden. Das ist ein schwerwiegendes Konfigurationsproblem. Sounds reasonable, but as there are hundreds of error messages, (some maybe not shown a single time, yet), it would be a significant burden for the developers to follow some rule here. Not the content of the rule would be a problem, but the fact that it has to enforced and explained to other people. You might think, he is just looking for an excuse, and you are right. ;) Currently, you have at least some differentiation: EE: error - this is always a coding error, please file a bug report-window pops up WW: warning - Message on the console starting with Warning or Error or Fatal II: information - everything else on the console Your particular case with a missing marker image is clearly a bug as the error is not fatal and JOSM will run just fine. But if there is e.g. a preset image missing, you *want* that message all over the screen, so it can be fixed asap! Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS requiring an EULA acceptance
Pieren wrote: Dear josm-devs, In my country, we have a commercial imagery supplier which is ready to open its images but only for the OSM project (licencing issues fixed). For that, they will set-up a WMS for a limited coverage during an experimental period and want to check that only allowed clients are accessing the data by checking the user-agent (on which only the OSM editors could be accepted and others rejected of course). The main concern is about a special handling of the WMS. They want that a contributor using the WMS the first time shall read and accept an EULA (End User License Agreement). Again this is just to inform people that they are only allowed to use the imagery for OSM and nothing else. Of course, the whole process can be bypassed by anyone who really want to access the WMS but this is a demand from the lawyers. The EULA would be available in two languages but could be extended later. Then I'm asking you to check if this demand is possible and how it could be solved. I don't want to fork the WMS plugin just for that, so my idea is that the plugin could be modified in a way that the special WMS URI could be identified as such in the Java code (hardcoded) and would raise the EULA acceptance dialog automatically the first time (stored somewhere is different languages). I could implement that myself but I would have your feedback first to see if this is the right way to go. Generally, it should be possible to include something like this in the main wms plugin. Hardcoding some URLs might also be acceptable (but I don't think it is needed). There are always older versions of the wms plugin out there in use. These older versions would not know about this blacklist and would simply ignore the EULA enforcement. You might want to demand a certain parameter in the URL (like ...user=openstreetmap) just to sort out the older clients. When reading the list of defaults [1], wms plugin ignores each line that has more than 2 semicolons in it. You can exploit this, to create your own custom format. E.g. the first string could be the name of the custom format EULA-1.0, followed by the necessary parameters. When extending the plugin, make it ignore lines with unknown format. 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. [1] http://svn.openstreetmap.org/applications/editors/josm/plugins/wmsplugin/sources.cfg Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS and remote-control
Komяpa wrote: Hi all, 1) Due to Landsat WMS being down and overloaded usually, we've set up a caching WMS proxy for it. JOSM URL is http://irs.gis-lab.info/?layers=landsat; Please consider updating JOSM defaults. Do you want it to show up in the list on the bottom, or make it installed by default instead of the standard landsat URL? Are you sure, you can handle the traffic? The list of wms services [1] can be edited and is loaded by each wms client on startup. However you cannot force people to delete an entry from their menu, once it has been added it to their bookmarks. [1] http://svn.openstreetmap.org/applications/editors/josm/plugins/wmsplugin/sources.cfg 2) fires.Kosmosnimki.ru have provided us access to their realtime satellite imagery. That imagery is not mosaiced, and consists of thousands of layers. We've made a WMS gateway to it. Now, we need a convenient way to load that imagery into josm. An extenstion to josm-remote that will load specified WMS URL will be just fine. Hope somebody will write it, as I'm no java coder, unfortunately. There are some security issues when the browser has too much control over the client software. If you extend josm-remote this way, I suggest you fork it. (No offence intended, might be useful for some.) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Revert request
25or6to4 wrote: Hi all, I have a revert request on http://www.openstreetmap.org/browse/changeset/5441813. For some reason JOSM cut out on me, and before checking, I reuploaded a section. Now I seem to have dupe ways and unlabeled points. Any thoughts on where I went wrong? You can revert it yourself using the JOSM reverter plugin! It is relatively easy to use: Just enter the changeset id and upload. The plugin will load the state of the changed objects *after* that changeset, then it will automatically apply the changes to your local layer that make it undone. (In your case delete the newly created objects.) Then you can upload normally. (To a new changeset that is the inverse / opposite of the previous one.) In case something has changed in the meantime, you will be notified and conflicts are created. Sebastian ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] JOSM and Java 6
Sebastian Klein wrote: I guess we also need a message box for Java 5 users trying to run JOSM = 3378. Currently it shows only the generic This is always a coding error-Box. Done. (In [3417]) The following classes need to be Java 5 compatible for this message box to show up: JOSM org.openstreetmap.josm.gui.Main org.openstreetmap.josm.gui.MainApplication org.openstreetmap.josm.tools.I18n. (@Override for interfaces implementations is OK.) All other classes shouldn't be a problem. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Windows-Installer: default projection is WGS84
Hi, I just tried the windows installer and it creates the following default preference file: projection=org.openstreetmap.josm.data.projection.Epsg4326 layerlist.visible=true selectionlist.visible=true commandstack.visible=true propertiesdialog.visible=true osm-server.url=http://www.openstreetmap.org/api laf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel plugins=openstreetbugs;remotecontrol;validator;wmsplugin Especially interesting is the first line, where it puts WGS84 as default projection. Why is that? Shall we change it to JOSM's default projection (Mercator - EPSG:3857)? I would trim this file to laf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel plugins=openstreetbugs;remotecontrol;validator;wmsplugin everything else takes a proper default value. (Which was not always the case, so I understand it used to be necessary in the past.) Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM and Java 6
Dirk Stöcker wrote: Hello, according to a Trac ticket JOSM now finally used Java 6 functions. Could the one who did these changes please document the specific revision in the Startup page. The autosave feature [3378] by Jiri introduced Java 6 functions. So https://josm.openstreetmap.de/download/josm-snapshot-3377.jar is the last nightly build that runs with jvm 5. I guess we also need a message box for Java 5 users trying to run JOSM = 3378. Currently it shows only the generic This is always a coding error-Box. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
Dirk Stöcker wrote: On Wed, 4 Aug 2010, Anthony wrote: And it is something that should be consistent across different editors. Actually this is nothing we need to worry about. JOSM is still settings the standards here. We have 50% of the market. Potlatch the remaining 50%. The other editors don't really count at all ATM. Ciao Don't forget Merkaartor! It has a fair amount of users and has improved a lot lately. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
Frederik Ramm wrote: Hi, ce-test, qualified testing bv - Gert Gremmen wrote: I suggest we try to JOSM add some comments by itself: Merkaartor did that, or perhaps does it still. These auto-generated comments are next to worthless. They cannot replace one human being telling another human being in a few words what has been done and why. Yes, it is pretty useless. However adding it as another changeset tag, e.g. auto_comment=* would not do any harm. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Change to changeset comment handling, RfD
Frederik Ramm wrote: Hi, I have changed the way JOSM treats changeset comments. This is a politically sensitive topic (see recent discussion on talk list), so I'd value your input. I'm willing to revert the change (applied in r3399) if people think it is for the worse. Tha vast majority of mappers agree that changeset comments are useful, and that it is good if they are used. Where there's disagreement, however, is in the question of whether edtiors should enforce changeset comments or not. Some people do not want to enter changeset comments, and thus are unhappy if their editor forces them to. Some people want to enter changeset comments and want everyone else to do it, but they fear that forcing people to enter something will only create bitterness, and people will start entering useless comments like some fixes, ... and the like. Some people think that the editor must not give people an excuse not to enter a changeset (but I didn't know it was required...) and thus want the editor to enforce that as far as possible (of course no editor can check whether what's entered makes sense). For a while now, JOSM has forced people to add a changeset comment that is at least three characters long, and refused to perform an upload otherwise. In addition, JOSM *always* loaded that last recently used changeset comment as a default, making it easy for people to erroneously continue using an old comment. I have now changed this in the following way: * The last recently used changeset description is only loaded as default if it was used less than 4 hours ago. Otherwise there is no default. * If you try to upload a changeset with a comment of less than 10 (!) characters, there's a dialog that explains the importance of changeset comments, and asks the user to reconsider. The user may refuse to reconsider, in which case JOSM will proceed with the upload, even if the changeset comment is empty. I think that this strikes the right balance between trying to educate the user and still giving him the freedom to say no. I do have an user interface problem however. The dialog I'm displaying is a bit funny. It has the buttons yes, reconsider and no, continue uploading (because I *want* people to reconsider - thus the fat green check mark with that option). But now if you see the dialog and press ESC, it proceeds with uploading, which is undesirable. I don't know how to solve this. Any ideas? As I said, if people think this makes things worse, we can always go back. It's a difficult thing. Nobody likes to be bossed around by software - but then again it's no good if the software makes it sound like everything is ok and later you get flamed on the mailing lists (by people like me) for not using changeset comments ;) Hi, Good idea. I modified it a little, because the buttons and their icons might be somewhat misleading. For me, the cancel icon is associated with Take me back, I don't want to break anything here! rather than Beware! Don't click this button!. Also added don't show this message again-checkbox. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] MapPaint Styles - combining line style and modifier
Hi, if I have the following style: rule condition k=highway v=motorway/ line width=15 realwidth=15 colour=00f496 priority=1000/ linemod mode=over width=+70 colour=00ff00 dashed=7/ /rule it ignores the over line modifier. This is because of l. 144 in ElemStyles.java: over.remove(linestring); (Where linestring is the condition key for the line style.) Is there a reason for this behaviour or can we remove the line? Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] MapPaint Styles - combining line style and modifier
Thanks for the example, should multi-condition rules have the same semantics? (E.g. rule condition k=highway v=motorway/ condition k=highway v=motorway/ line width=15 realwidth=15 colour=00f496 priority=1000/ linemod mode=over width=+70 colour=00ff00 dashed=7/ /rule behaves differently compared to the example with one condition.) Sebastian On 7/19/10, Dirk Stöcker openstreet...@dstoecker.de wrote: On Mon, 19 Jul 2010, Sebastian Klein wrote: rule condition k=highway v=motorway/ line width=15 realwidth=15 colour=00f496 priority=1000/ linemod mode=over width=+70 colour=00ff00 dashed=7/ /rule it ignores the over line modifier. This is because of l. 144 in ElemStyles.java: over.remove(linestring); (Where linestring is the condition key for the line style.) Is there a reason for this behaviour or can we remove the line? Yes, there is. Overlays are used to combine different styles. When there is a basic style of this type, then this should be used instead. Example: - When I have a street including tram, then I draw street with Tram as overlay. - When I have only a tram, then I draw a tram directly. Allowing overlays overlaying the same basic type would make things much harder to control. Overlays aren't meant to improve drawing style of single elements. This would be too costly during drawing. 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] JOSM Tested
Dirk Stöcker wrote: Hello, a new month means a new tested. There have been no new features, bot only minor improvements and bug fixes in the last time. It seems nothing prevents a new tested version now. Core translations of the major languages are also nearly complete. What about making JOSM tested e.g. next wednesday? Ciao OK, would be nice to get the majority of relation types and their roles in the presets. People tend to take the validator warnings rather serious and there were a couple of complaints already. Sebastian ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] problem in josm
davinder kumar wrote: hello everyone , this is davinder kumar my problem is that i am using josm -tested .jar version 3094 i have enable plugin columbus in it. which is used for open open .cvs files . but when i put my .cvs files in my hard disk, after browsing and uploading it does not play sound .but when i browse these files from my pendrive it works with sounds . can anybody help me regards davinder kumar www.davinderkumar.co.cc www.csegndec.co.cc Thanks for reporting the problem. Please post it here again: https://josm.openstreetmap.de/newticket (JOSM bug tracker) Regards, Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Problem with large changeset
Alan Mintz wrote: If I bring up the history dialog for this node, it says that v2 was edited in changeset 3504242, agreeing with the OSM file, but that it's coordinates were 33.80988, -117.40063. It says that v3 was edited in changeset 5131096 (the one in question) and the coordinates are 33.809994 -117.40062 (which is the rounded version of those above). This dialog should really show more decimal places. Probably this is what happened: You downloaded v2 of the node, then changed its position/tags. Then it was uploaded successfully, but the final server response got lost somehow. This final answer includes the new version, timestamp, uid, ... of the changed objects. If you abort the upload process (or load the saved file from before the upload), JOSM does not know, it is already on the server and sticks to the old info. (If you abort upload before the last byte was sent, the sever will roll back the entire change, obviously the last byte had already been send in your case.) The update of the data using the server response from the upload is relatively straight forward. However if that answer got lost, best you can do is download that area again to another file and compare. (As I said it is all or nothing!) Another option is 'update' which does a semantic comparison and tries to match your objects with the ones on the server. If the object from update is not semantically equal to your local copy of the object and that object has a lower version number *and* is modified, it produces a conflict. It seems there is a problem with rounding/precision somewhere so it produced a bogus conflict. (But you said something about way conflicts, have you analysed these as well?) All this is only true if you upload in a single request. In chunked mode, this applies for each chunk separately. If you have a problem in a later chunk, it is usually a good idea to save the file anyway because JOSM has already processed the server responses from the successful chunks and remembers what has been uploaded so far. Sebastian So, it seems that in this case, my local OSM file has the correct coordinates of the node for v3, but the wrong timestamp, uid, user, version, and changeset. It seems that, when retrieving the node for conflict resolution, the longitude (but not latitude) is getting rounded to 6 decimal places (instead of 7), which then fails the comparison with the local value. I don't know if this is the sole cause of its appearance in the conflict list, or if this is because the local version number was not updated with the new one after the upload. If I retrieve all of these nodes and then compare the coordinates with my local file, I should be able to confirm that they were correctly uploaded. I'll look at the ways after that. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
