[josm-dev] New GPX implementation

[Henrik Niehaus]

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