[Openstreetmap-dev] Proposal for an own xml format

Immanuel Scholz immanuel.scholz at gmx.de
Fri Sep 23 19:00:38 BST 2005


Hi,

namespace = osm

<dataset>
  <nodes>
    <node id="12345" lat="42.0" lon="23.0" />
    <node id="15" lat="17.01234" lon="33.6" />
    <node id="5478" lat="-2.0" lon="123.0" />
    ...
  </nodes>
  <segments>
    <segment id="565" start="12345" end="15" />
    <segment id="53123" start="15" end="12345" />
    ...
  </segment>
  <tracks>
    <track id="678">
      <segment id=565" />
      <segment id=53123" />
    </track>
    ...
  </tracks>
  <nodes>
    <node id="5523" lat="123.12" lon="-0.112" />
  </nodes>
  <areas>
    <area id="688">
      <node id="12345" />
      <node id="5523" />
      <node id="5478" />
    </area>
    ...
  </areas>
  <properties>
    <property id="111" object="678" key="name" value="Baker Street" />
    <property id="155" object="15" key="pub" value="cheap beer" />
    ...
  </properties>
</dataset>


Explanation:
- nodes consist of latitude and longitude.

- Points of Interests are nodes

- segments have only two nodes: a start and an end. As an alternative,
we could let segment's have a list of nodes, like the tracks:
<segment id="565">
  <node id="12345" />
  <node id="15" />
  <node id="5478" />
</segment>

- tracks have a list of segments.

- bus routes are tracks. Streets are tracks.

- areas are the polygon of at least 3 nodes that spans the area defined
by connecting every node with its successor and the last node to the
first. The area is to the right of the track you draw this way (means,
you have to draw clockwise around an area).

- Every node with an attribute "id" is an object.

- The properties object-attribute is the id of the object, this property
is for.

- As you can see, properties can have properties.

- latitude and longitude only appears in the node-tag. Every other
reference must point to an object in the nodes list.

- The tags are NOT in any order. The following restrictions occour:
  - There must be no reference to an id, which has not been transfered
yet.
  - the grouping tags as <nodes>, <segments>, <areas> etc.. can appear
more than once.
  - <properties> - tag should be the last tag



Discussion:
- The difference between "Point of Interest", "Waypoint" and "Node" can
be expressed through properties. I don't see the need of different data
structures. Beside, Point of interests can be parts of the street
landscape, as in bus stops, train stations, parking lots etc.

- Same is for streets, bus routes, wander routes etc.

- In theory, you could express an area as a track (since in the end,
tracks are a list of nodes), but I consider this misguided, since areas
are really a different thing than tracks, even in the world out there.

- The scheme of defining areas is common in computer graphic. If there
is a better way common in GIS, we should use the better one ;)

- The scheme makes it possible for the server to start the xml-data with
the most important data and continue with lesser important data. The
client could display only as much data as he wants and then closes the
connection and skip the unimportant stuff (as example because the user
already clicked on a scroll button).

- I expect the most raised eyebrowns at the fact, that I suggest a
seperate list of properties instead of including a tag <properties> in
every other object tag. This has several reasons:
  - Properties to other properties will look much cleaner this way.
  - Someone who isn't interested in properties can stop transfering data
when he reached the properties - tag. Or a parser could start displaying
the data, even when he has not finished receiving the whole dataset.
Integrating the properties within the data would make it necessary to
transfer all properties to one object together with it.

- I think, the structure is very simple to parse. The tag's depth is
static, the tag names are static. And the whole structure is very strict
defined (optional tags makes SAX-parser much harder to write).


Remember, that the performance points (the order of the tags and the
"closing the stream before all is transfered") are optional. A client
unwilling to implement this, is free to get the whole data and then
start parsing it.


Ok, gimme your flames! :-)

Ciao, Imi.






More information about the dev mailing list