[OSM-dev] Alternate OSM file structure

Karl Newman siliconfiend at gmail.com
Tue May 6 23:56:16 BST 2008

I originally wrote this up as a response to the ongoing debate about polygon
primitives (a fight I started...), but it's too big for that thread. So,
here's another one. I'm pulling the pin and throwing it over the wall.

Since we're talking about API changes, let's look at the OSM file structure.
To borrow an idea from the Polish format (.mp) files, it would be easier to
deal with ways (polylines) if they included the coordinates inline instead
of referring to nodes in a separate location. Topology could be preserved by
just referencing node ids (routing nodes, as it were) at the junction
points. A sample would look like this (some elements stolen from the API 0.5
Wiki page):

<node id="156804" lat="61.8083953857422" lon="10.8497076034546"
visible="true" timestamp="2005-07-30T14:27:12+01:00"/>
<node id="156805" lat="61.8084115523982" lon="10.8497259103025"
visible="true" timestamp="2005-07-30T14:27:12+01:00"/>

<way id="35" visible="true" timestamp="2006-03-14T10:07:23+00:00" user="johnz">
  <nd lat="61.8083953857422" lon="10.8497076034546" ref="156804"/>
  <nd lat="61.8084092591305" lon="10.8497172051835"/>
  <nd lat="61.8084115523982" lon="10.8497259103025" ref="156805"/>
  <tag k="highway" v="secondary"/>

<way id="36" visible="true" timestamp="2006-03-14T10:07:23+00:00" user="johnz">
  <nd lat="61.8084115523982" lon="10.8497259103025" ref="156805"/>
  <nd lat="61.8083953857422" lon="10.8497076034546"/>
  <nd lat="61.8084092591305" lon="10.8497172051835"/>
  <tag k="highway" v="secondary"/>

(The end of Way 35 is connected to the beginning of Way 36. The point where
they connect is a routing node and has an ID of 156805.) Now the ways are
self-contained and can be filtered against an area without having to first
store all the nodes in the planet to look them up. Including the lat and lon
at the routing nodes has concerns about keeping the coordinates
synchronized, but maybe it could just included for convenience and the
<node/> element coordinates would be authoritative. Obviously this would
increase the size of the planet file due to duplicated coordinates, too.


P.S. This could be an alternative structure which is derived from
post-processing a planet file (or database...).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080506/d410f8bd/attachment.html>

More information about the dev mailing list