[josm-dev] New GPX implementation

Ľubomír Varga luvar at plaintext.sk
Tue May 5 23:13:30 BST 2009


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".

I suggest to make some prototyping done with that libraty, to get familiar 
with it and than decide if it is suitable, realible, performace enough, for 
josm.

PS: I like this idea, but I dont know anything abut that lib.


On Wednesday 06 May 2009 00:02:41 Henrik Niehaus wrote:
> 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-dev at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/josm-dev

-- 
Odborník na všetko je zlý odborník. Ja sa snažím byť výnimkou potvrdzujúcou 
pravidlo.




More information about the josm-dev mailing list