[josm-dev] GPX upload?

[Sebastian Klein]

Axel Kollmorgen wrote:
> On 2010-11-07 06:57, Sebastian Klein wrote:
>> 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 it had been easy, i would have done it :) i don't think it should go 
> directly into the OsmApi class, but into a specialized class. 
> suggestions are welcome.

I'd say it would fit in (only api relevant code), but do what you think 
is best.

>> If you like, you can fully integrate the plugin into JOSM core, this
>> is planned anyway.
> 
> i'll see what i can do.
>> 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?
> 
> no, it shouldn't be a problem then. if the api works. when i tested, 
> http://api06.dev.openstreetmap.org/oauth/... gave me constant 401 
> "Invalid OAuth Request" errors, so i had to test with the default url, 
> anyway.

Are you able to upload to the dev server using oauth?

It works, but you have to change the advanced oauth properties to the 
values in [1]. (Or register JOSM yourself, but it is supposed to be done 
only once per application)

For some reason "Fully Automatic" method does not work for me, but "Semi 
Automatic" is fine.

(And don't forget to create an account on the dev server, the 2 systems 
are completely separated.)

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

Currently, only the buttons at the bottom of the layer list react to 
selection changes in that list, so making other parts of the application 
selection aware is a major change in gui logic. I'm not saying it is bad 
per se, but has to be thought through.

>> 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.
> 
> it should be enabled when a gpx layer is selected (that's part of
>>> changed the way the gpx layer to be uploaded is selected among all
>>> open layers
> ). as i say above, this information is not accessible by plugins. what 
> happens now is that if no gpx layer is selected, the "upload trace" 
> dialog pops up, but says "no gpx layer selected" and doesnt let ypu 
> upload anything.
> 
> i just got an idea for how to clevery solve this: remove the "upload 
> traces" toolbar button and put it into the context menu of the gpx 
> layer. no is_enabled check needed anymore: if there is no layer, there 
> is no context menu. also no check to see which layer has to be uploaded. 
> it also seems more intuitive to me. what do you think?

Sounds good, the only complication is to educate users to find the new 
entry in the right click menu - let's see how it works out.

[1]
http://api06.dev.openstreetmap.org/ OAuth details for JOSM:
Consumer Key:
  RPbHKwlBnolU0N0z1WeAUg
Consumer Secret:
  wnDRp3v7S9Ub8KXQ1wmEuJj0oqq2PtsqnyUGiBtIMWQ
Request Token URL:
  http://api06.dev.openstreetmap.org/oauth/request_token
Access Token URL:
  http://api06.dev.openstreetmap.org/oauth/access_token
Authorise URL:
  http://api06.dev.openstreetmap.org/oauth/authorize


Sebastian