[josm-dev] GPX upload?

Sebastian Klein bastikln at googlemail.com
Sat Nov 6 22:57:06 GMT 2010


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:
> 
>   List<String> descHistory = new LinkedList<String>(...);
>   // 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



More information about the josm-dev mailing list