Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

XML access to the traces #146

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 3 comments
Closed

XML access to the traces #146

openstreetmap-trac opened this issue Jul 23, 2021 · 3 comments
Assignees
@openstreetmap-trac
Labels
Component: rails_port Priority: major Resolution: fixed Type: enhancement

Comments

@openstreetmap-trac
Copy link

Reporter: immanuel.scholz[at]gmx.de
[Submitted to the original trac issue database at 4.50pm, Wednesday, 22nd March 2006]

The new .../traces/ urls are awesome!

I REALLY like to have an xml based access within the API to them. They are much more usefull for drawing stuff than the .../trackpoint - api, since you see all the metadata (the comments, who made them etc) and most important: you see the tags! ;)

As example, the following URL's could be accessible via .../api/0.x/... (all requests return XML):

All URL's start with www.openstreetmap.org/api/0.x/traces/

||Access|| URL || Comment ||
||GET||user ||list of all usernames that have public gpxses||
||GET||user/ ||list of all ids of public gpx files for this user||
||GET||user/ ||get the specific trace file (as raw file, not preparsed)||
||PUT||user/0?name=...||new public track (have to specify the url format)||
||PUT||user/?... ||update the track properties||
||GET||tag ||list of all tags used so far||
||GET||tag/ ||get all traces that have this tag||
||...

I think the way with the additional URL parameter to specify the metadata for GPX traces on upload is easier to implement than some cool XML embedding or even session-like stuff. But if something implements it, I am fine with this too ;-)

Imi.
@openstreetmap-trac openstreetmap-trac self-assigned this Jul 23, 2021
@openstreetmap-trac
Copy link
Author

Author: immanuel.scholz[at]gmx.de
[Added to the original trac issue at 6.32pm, Saturday, 25th March 2006]

While I was thinking about this...

why not just use a subversion archive to store the GPX files from users? NO, really.. think about it...

  • hirarchical ordered

  • access can be maintained easily by the subversion's operating system. Readonly access as well as read-write

  • Any metadata can be handled by the subversion property system. Metadata to directories could be interpreted as "stand for all things containing in here"

  • There are many web frontends..

  • Nothing is lost, history is saved.

  • subversion is already coded. Libraries exist.

@openstreetmap-trac
Copy link
Author

Author: immanuel.scholz[at]gmx.de
[Added to the original trac issue at 12.30pm, Sunday, 26th March 2006]

After discussing with Steve, the following pre/contra arrive from subversion vs. own api:

Subversion pro:

  • has cache "built in"
  • easy to implement simple stuff
  • meta-data is easy through subversion's property engine
  • libraries everywhere

Subversion contra:

  • no out of the house indexing services known to me. This requires home-made scripts.
  • access control would need file system access control. This mean one system user account for every OSM account. AND they need to be synced.
  • Users are tempt to download just everything, which will instantly kill the server.
  • The versioning feature is not that usefull for traces.

Regarding this, an own API would probably be better ;-)

Imi.

@openstreetmap-trac
Copy link
Author

Author: steve[at]fractalus.com
[Added to the original trac issue at 6.46pm, Saturday, 7th April 2007]

done

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@openstreetmap-trac openstreetmap-trac

Labels
Component: rails_port Priority: major Resolution: fixed Type: enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openstreetmap-trac