Re: [josm-dev] New GPX implementation
Hi. Just for the reference: my TCX-support plugin was based on JAXB from the start and includes the necessary JABX libs for java 1.5. So far nobody complained about the large download size or anything... but I guess I'm the only one who uses it ;) Anyway, JAXB is quite solid. I'm using it for every XML parsing where I can get an XSD schema file. It also works with the OSM XML files, but at the moment I don't have a schema file for the 0.6 API. Does any one know if there is a schema file available for the new API? Regards, Adrian. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
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. 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. We have. Plugin dependecy is e.g. used fo surveyor plugin which depends on livegps. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@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
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. Yes. But in this future we're sure it is necessary. Now we are not. :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Frederik Ramm wrote: But while we're at it, give us some reasons why we need to remain 1.5 compatible. I'm not in a hurry to switch to 1.6 but we'll do it at *some* point and I am interested in finding out what that point is going to be. 1.6 isn't available for PowerPC Macs, FWIW. Apple haven't made a PPC Mac since 2006. I still use PPC for both my main machines (but then I'm not a JOSM user so that may be moot). cheers Richard -- View this message in context: http://www.nabble.com/New-GPX-implementation-tp23330999p23400671.html Sent from the OpenStreetMap - JOSM Dev mailing list archive at Nabble.com. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Ľubomír Varga schrieb: I like system not reinventing wheel. If josm will more rely on third party code, it will gain better maintability, stability and less code. Only drawback is in relying on third party code. Well, there are drawbacks like bugs in third party code that you can't easily fix, different versions used in the wild with different behaviour, making it less easy to set up a development environment, ... Regards, ULFL ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
compatible. I'm not in a hurry to switch to 1.6 but we'll do it at *some* point and I am interested in finding out what that point is going to be. Mac OS Tiger, Leopard 32bit have no 1.6 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
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. That is realy big think to bundle with josm. I hope Iam wrong... PS: Iam not using primary java because of portability. It is useles on windows mobile based devices (no I/O posibility, no GPS, no access to BT...) I like java because of realy big framework which is bundled with its executive environment. On Wednesday 06 May 2009 02:10:31 Russ Nelson wrote: Ľubomír Varga writes: I like system not reinventing wheel. If josm will more rely on third party code, it will gain better maintability, stability and less code. Only drawback is in relying on third party code. There's nothing *wrong* with third party code. The problem is having a package that runs everywhere. If portability is unimportant to you, why write in Java? -- Odborník na všetko je zlý odborník. Ja sa snažím byť výnimkou potvrdzujúcou pravidlo. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
1.6 isn't available for PowerPC Macs, FWIW. Apple haven't made a PPC Mac since 2006. I still use PPC for both my main machines (but then I'm not a JOSM user so that may be moot). This is in my view a sufficient reason to insist that everything work with 1.5. But, if someone just has to download a jar and add it to a command line, that doesn't seem like a big deal, even if it is 7 MB. pgpTzKx2D6aIn.pgp Description: PGP signature ___ 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
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 -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Frederik Ramm writes: I don't, however, see a pressing need to support any and all extended GPX features. Actually, JOSM makes a fine GPX editor. Great for removing those birds nests when you stopped for lunch. -- --my blog is athttp://blog.russnelson.com Cloudmade supports http://openstreetmap.org/ 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ josm-dev mailing list josm-dev@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
Henrik Niehaus writes: No one interested? Is JAXB a separate library? How does this extra code affect the portability? -- --my blog is athttp://blog.russnelson.com Cloudmade supports http://openstreetmap.org/ 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Henrik Niehaus henrik.nieh...@gmx.de writes: 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? I believe that I am bit on the fringe so didn't reply the first time. It sounds cool to have better XML support. But, I have trouble running JOSM on my normal computer because java isn't portable (Sun doesn't release a JDK for NetBSD, one needs a recent JDK due to language changs, and openjdk is in practice not quite there yet), and therefore I have a negative reaction to adding dependencies. But, I suspect that the real issue is with the JDK and additional libraries is not a big deal. All that said, I use GPX in JOSM to read in tracks and display them, and that works fine - I haven't wanted to write GPX. pgpFMdwtE8igY.pgp Description: PGP signature ___ 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
Re: [josm-dev] New GPX implementation
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. 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, 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. -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Henrik Niehaus writes: 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. Sounds like this patch would cause JOSM to not work under Java 1.5. I suggest that we not use it, sorry. -- --my blog is athttp://blog.russnelson.com Cloudmade supports http://openstreetmap.org/ 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Hi, Russ Nelson wrote: 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. Sounds like this patch would cause JOSM to not work under Java 1.5. I suggest that we not use it, sorry. You misread. It will work under 1.5 but only if we package an additional MB of libraries. Apart from a slightly higher download time and memory footprint you wouldn't notice. But while we're at it, give us some reasons why we need to remain 1.5 compatible. I'm not in a hurry to switch to 1.6 but we'll do it at *some* point and I am interested in finding out what that point is going to be. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] New GPX implementation
Frederik Ramm wrote: 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, 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. I know it's none of my concern, but if introducing yet another dependency is a factor then JAXB does have a fair bit going for it. It is the official standard for java to xml binding, very well supported, and not going away any time soon. It's the foundation on which many other standards are based such as JAX-WS (java's web service standard). You should be able to eliminate most manual xml serialisation/deserialisation code by using it. In terms of programming it seems well thought out and isn't onerous to use. There are lots of other competing libraries/frameworks/standards that have their advantages and disadvantages (eg. JIBX for pure speed) but JAXB should be the default choice unless there's a good reason to choose otherwise. If you get to more fully support a standard such as GPX without too much effort then it sounds like a win. http://en.wikipedia.org/wiki/JAXB But supporting java 1.5 is a pain and using the latest cool library isn't always good for the project as a whole so I'll get back on the fence :-) ___ 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
