[Openstreetmap-dev] Transport mechanism progress?

Immanuel Scholz immanuel.scholz at gmx.de
Thu Sep 29 09:22:17 BST 2005


Hi,

I want to boost the discussion about the transport mechanism used between
server and applications (means: The structure of the data received via the
REST API). This is because my application I am writing is at the point
where I want to import/export data. So I want to code it in the beginning
the way, it is probably usable in future ;)


Current status of the online REST Api:
- Server delivering GPX only
- no id, but the <name> as number
- no other tags but the required and <name>
- no support for two things share the same nodes, except by comparing the
lat/lon
- I did not test it, but I expect the server to strip all tags except
<name> and the required when importing.


Planned status for GPX:
- All dataTypes supporting a <number> tag use this as id. These are: trk
and rte. (Do we need rte alias routes?)
- All other support ids over extensions in export and import. If missing
in import, an id is auto-generated for the object.
- known properties, that are some listed in a defined place are encoded as
their GPX-tag counterparts (and read during import). As example,
"name=Baker Street" will be encoded as <name>Baker Street</name> if the
object support <name> - tag.
- unknown properties are encoded as <extensions><property key="foo"
value="bar" /></extensions>
- for import, even known properties may be transfered in <extensions>
- Still, real shared data are not supported by GPX. Maybe the server does
some auto-sharing if it detects double lat/lon values (but this is
dangerous, as example for bridges, where two different nodes with the same
lat/lon exist)


Planned status for XML:
- May be implemented as alternative to GPX for applications which want
simple to parse and good machine readible gis-data.
- Proposed in http://www.openstreetmap.org/wiki/index.php/XML_Schema
- awaiting futher comments (in mailing list or in wiki) ;-)


Am I correct? :)


Ciao, Imi.






More information about the dev mailing list