[josm-dev] GPX upload?

Axel Kollmorgen akollmorgen at gmail.com
Wed Nov 3 15:02:29 GMT 2010


On 2010-09-02 01:04, Sebastian Klein wrote:
> Morten Kjeldgaard wrote:
>> GPX upload from within JOSM stopped working for me a good time
>> ago.
>
> That is correct, the direct upload plugin does not support oauth at
> the moment.
>
> Another option would be to fix the plugin. ;)

funny you say that, because i - without having read this conversation - 
did just that. besides adding oauth support, i also

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

[1] 
http://josm.openstreetmap.de/wiki/DevelopersGuide/DevelopingPlugins#TheJOSMAPI
[2] 
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ElevationProfile#Known_Bugs_and_Workarounds

* 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?

i would much appreciate feeback to the points above. maybe i'm just not 
seeing the forest for the trees :)

find attached the patch with my changes. i developed against r3627, and 
just updated to the latest r3648 without problems. i did some testing 
and found no problems - no guarantees though. hope it might be useful 
for others, too.

ax
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DirectUpload.patch
URL: <http://lists.openstreetmap.org/pipermail/josm-dev/attachments/20101103/cced497c/attachment-0001.ksh>


More information about the josm-dev mailing list