Route /traces

[vgeorge]

Endpoint for GPX traces related actions. I believe we need to validate the schema at #4 before detailing this.

[vgeorge]

Actions for traces:

• GET: Returns trace as GeoJSON, with meta included in properties. In order to allow opening the trace in JOSM, this method should also accept an optional format=osm query parameter to allow passing a OSM XML URL to import command of JOSM Remote Control
• POST: Creates a new trace from a GeoJSON feature
• PUT: Probably not supported, if there will be no label or other properties for traces (see Data schema #4)
• DELETE: Remove trace

[batpad]

POST: Creates a new trace from a valid GPX file

I'm more inclined to have the POST format to match the default GET GeoJSON format - it seems a bit more straightforward on the client and probably easier to parse. Then we export either osm or gpx formats only when requested as such, but stick to the GeoJSON format as the default interchange? @geohacker @vgeorge do you have strong feelings either way about this?

[geohacker]

Yeah I agree to keep POST and GET requests consistent with the format. We would have a geojson on the clientside as we want to show the trace on mapbox gl so posting that directly makes sense to me and we can convert them to gpx / osm on the API?

[vgeorge]

Ok, I've changed the POST method to accept a GeoJSON feature. Should we adopt tracejson for that?

[batpad]

Should we adopt tracejson for that?

I am in favour of using the tracejson format, yes.

[geohacker]

TraceJSON sounds good to me!

[vgeorge]

Implemented by #16.