Re: [josm-dev] Loading JOSM+plugins into Eclipse for the first time.
Ray Foulkes schrieb: Hi Jan, thankyou, I do not know what I was doing wrong the first time around. I did as you suggested and created a java project using the sources in core - it all worked and runs the main program OK. I can navigate the Java e.g. find declarations, references and run the main application. etc. BUT, I was trying to debug plugins... When I tried to do the same thing after downloading http://svn.openstreetmap.org/applications/editors/josm/ (which includes all the plugins) and added the directory josm as a project, there are many errors including some Java errors in the plugins which are Eclipse internal errors. Also, I then cannot run the core application. I think it is because of the directory in which the application is started does not contain all the necessary files. I do not know how to tell Eclipse to default the startup directory to another directory. My problem is that I am trying to learn Eclipse at the same time as learning the code of Josm. I discovered that I can add plugins individually i.e. create a new project and link it to core and at least compile the plugin even if I cannot run it. Anyway, thankyou for your response. I have at least been able to start investigating the codes of JOSM. Ray Jan Peter Stotz wrote: Ray Foulkes schrieb: If I use an svn client to download to a directory then point Eclipse to construct a java project itself, there are hundreds of Java errors which I have not fully investigated but look nasty. Not surprising since the build scripts I don't think are being used in that case. The Eclipse relevant part of JOSM is the core directory. Check-out the path you mentioned outside of Eclipse and then add the core directory as Project with external sources into Eclipse. This should work for JOSM itself. Plugins are a different matter. Jan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev Hi Ray, I did some screen captures some time ago for another user who wanted to get in touch with josm development. Have a look at these two videos (both divx in avi, no sound): http://hampelratte.org/zeugs/checkout_josm.avi http://hampelratte.org/zeugs/checkout_openstreetbugs.avi Cheers, Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Frederik Ramm schrieb: Hi, Henrik Niehaus wrote: The use case of supporting the GPX standard is equal to the use case of supporting GPX, in my opinion. Do it right or leave it be. I was asking because it seemed to me that supporting a tiny subset of the GPX standard is, in my eyes, sufficient for JOSM - load a file and display it. I've tried GPXes from a lot of different sources and never had a problem. If someone out there has a GPX file that cannot be displayed in JOSM and still conforms to the standard, then we should fix JOSM. I don't, however, see a pressing need to support any and all extended GPX features. And neither do you, it seems. So here's my suggestion, much like what Petr has said: 1. Since writing GPX files is broken beyond easy repair (if I understand you correctly), and since it is not part of the core JOSM functionality, let's remove that functionality from JOSM. 2. You build a plugin based on your code (let it be called Advanced JOSM GPX Manager or something), which completely replaces JOSM's native GPX handling, including reading and writing files, and probably also editing GPX traces (or if you don't want to do that, at least provide a solid foundation for doing such editing). Cross-check with the DirectUpload plugin whether the two should perhaps be merged. Many users would probably like a function that uploads only a part of the currently displayed GPX traces to the server, and things like that. You include the required Java 1.5 libraries in the plugin JAR file. 3. Once your plugin is used by many people and stress tested, and maybe at the time we switch to Java 1.6, we can throw out all the existing GPX code in JOSM and merge your plugin into the core. Does that sound like a plan that works for everybody? Bye Frederik I understand your point of view of being cautious with big code changes, and the idea to extract the gpx functionality into a plugin sounds good, too, but 1. If we take all three steps you suggested, we have the same situation as today. There will be many spots in JOSM, which will change, because the old code has to be removed and the new merged into JOSM 1.1 Meanwhile we have to extract the current code and put it into a plugin, which could be quite laborious. 2. Plugins depending on the GPX code have to be adapted to the new plugin, which would be the same work, as adapting them now to the new implementation. 2.1 We would have plugins, which depend on each other and afaik the plugin mechanism doesn't support dependency management, yet. So, it's not my intention to integrate a GPX editor into JOSM core, but to fix the current GPX handling. Nothing more. Things going further may be implemented as a plugin. But in my opinion, the plain GPX support (reading and writing) should stay in the core. The only advantage of your 3 step program would be a better tested GPX implementation, which would be merged into JOSM. But since I mainly replaced only the parser and some entity classes without any logix in it, it should be as stable as the old implementation, after some testing. Best Henrik ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Dirk Stöcker schrieb: On Thu, 7 May 2009, Henrik Niehaus wrote: 1. If we take all three steps you suggested, we have the same situation as today. There will be many spots in JOSM, which will change, because the old code has to be removed and the new merged into JOSM No. We would not remove old code now. Would be same situation as for image handling where agpifoj is the current solution and probably should replace the internal code one day. Not now, but some time later, when we merge the new implementation. The work stays the same. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Ľubomír Varga schrieb: It will run everywhere. Only problem with portability is that, that on java 1.5 systems is some aditional lib (packable into josm.jar) needed. afaik. But I see it like handicap, because if Iam not wrong, that lib has about 7 MB. It's only 1 MB and can be packaged into josm.jar. The user will not experience any changes, but the increased file size. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Frederik Ramm schrieb: Henrik, No one interested? I read your post and I didn't like it, but did not want to spoil your fun. First of all, JOSM is not a playground for trying out new technologies. If there's a good reason for introducing something new (and the increased complexity that comes with it) then fine. But the problems you mentioned were: 1. The GpxWriter doesn't respect the order of xml elements and can create invalid files I had not heard about this problem and I'm sure it can be fixed easily if it really is a problem. At the moment JOSM puts most of the GPX elements into a map like (tag_name, value). If the user decides to write the file back to disk the order of the elements is random. So there is a good chance that you get an invalid file. In my opinion, if JOSM wants to support GPX import/export, than it should be done correctly and respect the GPX standard. 2. It is not type safe and has problems with element types other than String. See ticket #2359. This bug should also be easy to fix, instead of rewriting the whole GPX handling. 3. JOSM is able to read any valid GPX 1.0/1.1 and write it back as GPX 1.1 JOSM is not a GPX editor. I don't see much use in writing GPX at all, and even if we do write GPX, I don't see why JOSM should convert between 1.0 and 1.1. 4. Many of the GPX features are not implemented yet and have to be implemented manually, if they are needed in the future, while the JAXB implementation comes with full support for all elements We don't normally develop stuff for future use because in 90% of cases it gets never used and just bloats the code. I'm not into GPX a lot; I load traces into JOSM and that's it. So if those who use GPX more than I do all say hooray, we've been waiting for these changes, finally we can read our GPX 1.0 files and save them as GPX 1.1 or whatever, then fine. But at least to *me* it sounds as if the concrete issues - namely the ordering of elements and the type problem - could have been fixed in a few lines of code, and you instead decided to overthrow the whole GPX stuff, I decided to rewrite the GPX code, because I had a look at the old one and tried to solve some tickets from trac. The effort to make the old code compatible with the GPX standard is very high and you will probably end up with messy code. In my opinion, the current code is not suitable for the GPX standard. That's why I decided to give the GPX handling a solid base and introduced JAXB. I think the biggest advantage of JAXB over the current implementation is, that it guarantees, that a file can be read, if it is valid and that it can be exported again and the result will be valid. introducing a host of potential problems and incompatibilities with plugins for little apparent gain. I'm not convinced that the positive sides outweigh the negative consequences but I'm willing to let others decide. Maybe I am really underestimating the advantages of JAXB, whatever that is. Bye Frederik PS: Whether or not we should switch to Java 1.6 is another matter. I think that Dirk recently said that we have very little Java 1.5 users. ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Henrik Niehaus schrieb: Hi JOSM coders, I came across several problems and feature requests for GPX files while looking at the bug tracker and reading this list. So I decided to learn a new technology and gave JAXB a try. The result is a JOSM, which fully supports GPX 1.0 and 1.1, because JAXB uses the xml schemas to generate entity classes. I have replaced the old entities with the new ones, so this patch touches many files of the core and probably some of the plugins will brake, but I think it's worth the switch to this implementation, because of these points: 1. The GpxWriter doesn't respect the order of xml elements and can create invalid files 2. It is not type safe and has problems with element types other than String. See ticket #2359. 3. JOSM is able to read any valid GPX 1.0/1.1 and write it back as GPX 1.1 4. Many of the GPX features are not implemented yet and have to be implemented manually, if they are needed in the future, while the JAXB implementation comes with full support for all elements Cons: 1. JOSM depends on JAXB - 5 jars with a total size of 1MiB (for JDK 1.5. JDK 1.6 comes with JAXB) 2. It's a big patch and might need some time to get everything (including plugins) back to work 3. New bugs, which made their way in the new implementation So, what do you think about this patch? Best Henrik No one interested? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Russ Nelson schrieb: Henrik Niehaus writes: No one interested? Is JAXB a separate library? How does this extra code affect the portability? If you use Java = 1.5, JAXB is a separate library. Java 1.6 includes a JAXB implementation. Portability in terms of runnable on Win, Mac, Linux? JAXB is pure Java and depends on Java 1.5, so it should run on any platform, which supports Java 1.5 or better. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] New GPX implementation
Hi JOSM coders, I came across several problems and feature requests for GPX files while looking at the bug tracker and reading this list. So I decided to learn a new technology and gave JAXB a try. The result is a JOSM, which fully supports GPX 1.0 and 1.1, because JAXB uses the xml schemas to generate entity classes. I have replaced the old entities with the new ones, so this patch touches many files of the core and probably some of the plugins will brake, but I think it's worth the switch to this implementation, because of these points: 1. The GpxWriter doesn't respect the order of xml elements and can create invalid files 2. It is not type safe and has problems with element types other than String. See ticket #2359. 3. JOSM is able to read any valid GPX 1.0/1.1 and write it back as GPX 1.1 4. Many of the GPX features are not implemented yet and have to be implemented manually, if they are needed in the future, while the JAXB implementation comes with full support for all elements Cons: 1. JOSM depends on JAXB - 5 jars with a total size of 1MiB (for JDK 1.5. JDK 1.6 comes with JAXB) 2. It's a big patch and might need some time to get everything (including plugins) back to work 3. New bugs, which made their way in the new implementation So, what do you think about this patch? Best Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localize new strings in my plugin
Dirk Stöcker schrieb: On Sat, 11 Apr 2009, Henrik Niehaus wrote: I have a question concerning my openstreetbugs plugin. I have added new strings and want to translate them. What do I have to do? The gettext support for my plugin has been added by Dirk, I think, and I don't have a clue how this works. This is done automatically when translations are synced next time. I had holidays last weeks, so sorry for late answer :-) Ciao Hi Dirk, could you give small summary how this tanslation system works? Does the system extract untranslated strings from the code and add them in launchpad? If this is the case, when is this done and when will translated strings be merged back to josm? Thx Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] connected nodes in blue
Ulf Lamping schrieb: I thought a bit about it, but I have no idea how to implement it in a good way. I had a look at the DataSet class and I would suggest to extend it with DataSetChanged listeners. Fortunately the class uses the interface Collection, so that the LinkedLists containing nodes, ways and relations could be replaced by implementations which support the detection of changes. Then we could have some kind of analyzer, which analyses the nodes after changes and sets some properties in the Node class. If there are performance problems, the events have to be as granular as possible, so that the analyzer does not have to process the whole dataset, but only changed elements. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] connected nodes in blue
Jonas Krückel schrieb: Hi, at the moment all the normal nodes (if they don´t have a special tag) in ways are displayed in a red color (at least in my JOSM from today) Especially for debugging of osm data the following feature would be very useful: all nodes which are connected to another way are displayed blue. At the moment i have to move the node away to see if it is really connected to the way and then press undo. If you think this feature would be helpful i will open a trac ticket (i have no java skills to implement this feature). Jonas I think this is a good idea. I'm using the same workaround to see, if ways are connected. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Localize new strings in my plugin
Dirk Stöcker schrieb: On Sat, 11 Apr 2009, Henrik Niehaus wrote: I have a question concerning my openstreetbugs plugin. I have added new strings and want to translate them. What do I have to do? The gettext support for my plugin has been added by Dirk, I think, and I don't have a clue how this works. This is done automatically when translations are synced next time. I had holidays last weeks, so sorry for late answer :-) Ciao No problem, so if I want to provide translations on my own, I have to do that via launchpad? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Plugins that depend on external libraries..
Mattias Dalkvist schrieb: Hi I'm trying to make a plugin of my geotiff code, but I can't get the dependencies to work. The plugin it self works fine, that is when josm is launched from eclipse, and the dependencies are added to the eclipse projects classpath. Do anyone have any experience of external .jar dependencies for plugins? Or anyone with pointers generally? The libraries are mostly from the geotools library, including the jai libraries. it is the later that gives me a error that I can't find a way to fix, googeling gives that the error is connected to the classpath and when the libraries are loaded. Error output: java.lang.IllegalArgumentException: ImageRead: No OperationDescriptor is registered in the current operation registry under this name. at javax.media.jai.JAI.createNS(JAI.java:1070) at javax.media.jai.JAI.create(JAI.java:973) at org.geotools.gce.geotiff.GeoTiffReader.read(GeoTiffReader.java:426) ... If the licenses of the used libs allow it, you can unzip them and include them in the plugin jar. You can do that with an ant task. Otherwise you could write a custom classloader, which loads the libs. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Localize new strings in my plugin
Hi, I have a question concerning my openstreetbugs plugin. I have added new strings and want to translate them. What do I have to do? The gettext support for my plugin has been added by Dirk, I think, and I don't have a clue how this works. Cheers Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] WMS-Plugin: timeout too fast?
Tobias Wendorff schrieb: Dear Dirk, it seems like the WMS-Plugins doesn't wait long enough to get tiles from slow WMS-servers. Since many WMS-servers need a lot of time to transform images to WGS84, the timeout should be higher. Is there a hidden setting or tweak? Best regards, Tobias I have added timeouts with a timeout of 30 seconds for both connect and read operations. They can be configured on the Einstein-Tab in the settings wmsplugin.timeout.. Values should be the timeout in seconds. The changes are checked in the cvs and should be available with the next release. BR Henrik ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Validator: Node near landuse - no warning
Hi, I have noticed that the validator shows warnings, if an endnode of a way is near a landuse way, which is ok in most cases. For example: http://img140.imageshack.us/my.php?image=waynearlandusewn5.png (white area is landuse=residential, way is highway=residential). So I patched UnconnectedWays.java to ignore such cases (landuse, leisure and building. Maybe there are more cases, which I forgot). Maybe one could also use way.osClosed() ?!? What do you think about this patch? Regards Henrik dont_include_areas.diff.gz Description: application/gzip ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] compile plugin
Jorge Luis Chamorro schrieb: 1 - sorry for my newbie question 2 - sorry for my English , I speak Spanish I live in a country (Argentina) with many cities with very regular design mostly of them not in openstreet (no mapping at all) . And we have a lot of work to do. I learn Java and inspect JOSM sources . Then I wrote a code createGrid.java , put in actions directory and make an entry in menu . It work sucesfully and its very usefull for our mapping proyect . This code create a grid of many streets from only two . I need to transform it into a plugin but I don't known how to compile a plugin . I read http://josm.openstreetmap.de/wiki/DevelopingPlugins and follow their instructions but i'm a newbie , I dont work with ANT. I get the complete osm - trunk with svn co http://svn.openstreetmap.org osm then I try cd osm/applications/editors/josm/plugins/ I Try with cd waypoints for example and put export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.16 ; ant then I obtain a lot of errors like : [javac] /home/chamorro/josm-plugin-develop/osm/applications/editors/josm/plugins/waypoints/src/WaypointOpenAction.java:21: package org.openstreetmap.josm.gui.layer does not exist [javac] import org.openstreetmap.josm.gui.layer.OsmDataLayer; I don't have a clue for what can I do next How can I tell to ant where I put the sources of JOSM ?. Can any of you tell me how can I compile a plugin for a dumb like me ? Saludos , Jorge Hi Jorge, I have a made two screencasts of how to set up eclipse to compile josm and a josm plugin for another user some time ago. Maybe it's useful for you, too. In the video the openstreetbugs plugin is used, but you could use this as a starting point and change the whole plugin code to fit your needs. http://hampelratte.org/zeugs/checkout_josm.avi http://hampelratte.org/zeugs/checkout_openstreetbugs.avi ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] OpenStreetBugs plugin
I have uploaded version 0.5 http://hampelratte.org/zeugs/openstreetbugs-0.5.tar.gz This version supports the creation of new bugs. Furthermore I have added some icons and improved the code here and there ;) Cheers Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] OpenStreetBugs plugin
There is a compiled version in the build directory of the archive. Tobias Wendorff schrieb: Henrik Niehaus schrieb: I have uploaded version 0.5 http://hampelratte.org/zeugs/openstreetbugs-0.5.tar.gz This version supports the creation of new bugs. Furthermore I have added some icons and improved the code here and there ;) Could you please compile it (for Win32)? ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] OpenStreetBugs plugin
I have just uploaded version 0.4 to http://hampelratte.org/zeugs/openstreetbugs.tar.gz This version supports automatic downloading of data. If the dialog is visible, the plugin will download data, if the map has not been moved or zoomed for one second. To disable the download, just close the dialog with the toolbar button. If you don't want automatic download at all, you can set the property osb.auto_download to false in the Einstein-Tab of the settings dialog. Henrik Jan Peter Stotz schrieb: Jan Peter Stotz schrieb: org.openstreetmap.josm.gui.layer is completely missing. Forget what I said, this was just a build problem The mentioned package comes with JOSM. Jan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] OpenStreetBugs plugin
Hi all, I have created a plugin, which loads the issues from OpenStreetBugs into JOSM. You can find a compiled version and the complete eclipse project here: http://hampelratte.org/zeugs/openstreetbugs.tar.gz Comments appreciated. Cheers Henrik ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] wmsplugin improvements
Petr Dlouhý schrieb: Hello, you didn't change YAHOOGrabber to adjust your changes, is it? If no, I will change it myself. That's right. You have to change YAHOOGrabber, too, so that it can be executed byte the ExeceutorService. I had synchronized (layer) { //download only one tile in one moment in the code, so only one tile was downloaded at same time. That was, because I didn't know about thread pool, so I think, it could be removed now, is it? If you added that to avoid too many threads, you can savely remove it. As I wrote in the other mail, a pool size of 3 worked best for me (with the server I am using). On Fri, 12 Sep 2008 16:10:08 +0200, Henrik Niehaus [EMAIL PROTECTED] wrote: That's no problem for me. It's only a small patch; nothing to speak of. Petr Dlouhý schrieb: On Fri, 12 Sep 2008 15:32:38 +0200, Henrik Niehaus [EMAIL PROTECTED] wrote: I will take more detailed look at the patch today. Do you really want me to commit your patch? I have no problem with that, but it will be commited under my name. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petr Dlouhý schrieb: I did some more research and the wms server I am using, seems to allow only a few connections from one client. I achieved the best reliability with a thread pool size of 3, so that only 3 connections exist at a time. With this configuration I could scroll around like a berserk and all tiles loaded on the first attempt. So, if you want to apply my patch to the plugin you should consider to set the pool size to 3. It might be slower with servers, which accept more connections, but it increases the speed at crappy servers, because tiles are loaded immediately and don't need 5 or more http requests. Did you have a look at the patch? Greetings Henrik - -- Mein öffentlicher PGP Schlüssel und Fingerabdruck: http://hampelratte.org/pgp/ ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] wmsplugin improvements
Hi, yesterday I was using a WMS-Server, which randomly returned HTTP 500 (Internal Server Error). Unfortunately the wmsplugin failed quietly, so I couldn't see, what was happening. So I made some improvements: 1. The wms grabber tries to download the image 5 times. If it fails the 5th time, a dummy image will be generated and rendered in the layer. It's red with the black string IOException occured, so that the user knows, that this tile failed to load and will not show up. 2. Check the Content-Type of the server response. If it isn't an image, there must have been an exception. In this case the plugin prints the response body to sysout. This happens after the 5th failed attempt to download the image. 3. The grabbers are executed by an ExecutorService (FixedThreadPool with size of 10), so that the number of running threads is limited. What do you think of these improvements? Cheers Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM charset
Dirk Stöcker schrieb: Hello, now that I found a charset conflict in measurement plugin: Is there any definition in which charset the jar files are? Could we agree to use UTF-8 here or only plain ASCII? Ciao I would strongly recommend UTF-8 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] JOSM Fon hotspot import
Hi, someone added fon hotspots to my village and because I wanted to have a look at the JOSM code, that inspired me to write a small plugin, which imports Fon hotspots from their KML-exports, which can be downloaded from http://maps.fon.com/ I don't know the legal aspect of importing their data (nothing mentioned on that page), but at least for personal, it should be ok. Anyone interested? Cheers Henrik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev