[OSM-dev] Area support (was: 0.6 API Status)

Frederik Ramm frederik at remote.org
Wed Jul 9 11:21:22 BST 2008


Hi,

> eg. we've also decided to add area 
> support ;-)?

Independent of whether or not 0.6 has area support (it's not planned to 
the best of my knowledge) - how would you model areas (a) in the SQL 
structure and (b) in XML?

It seems obvious that areas, like ways, need to be based on a sequence 
of nodes. (If you were to base them on ways, then that would be nothing 
different from today's relations, would it?)

An area with no holes inside would trivially have the exact same 
structure as a way, perhaps using <area> instead of <way>. It would also 
omit the last <nd ref="..."> which, for circular ways, is identical to 
the first, because for an area it is obvious that the boundary must be 
closed.

<area id="1234" />
    <tag k="landuse" v="industrial" />
    <nd ref="1" />
    <nd ref="2" />
    <nd ref="3" />
</area>

Now if the area has holes - and I assume that the area type needs to 
take care of that - how would these be modelled? We'd have a number of 
"node groups", one of which is the outer boundary, the others would be 
inner boundaries.

One possible XML representation would be to say that the node groups are 
numbered, with the outer always carrying the number 0:

<area id="1234" />
    <tag k="landuse" v="industrial" />
    <nodegroup id="1234-0">
    <nd ref="1" />
    <nd ref="2" />
    <nd ref="3" />
    </nodegroup>
    <nodegroup id="1234-1">
    <nd ref="4" />
    <nd ref="5" />
    <nd ref="6" />
    </nodegroup>
    ...
</area>

This structure could be mirrored in the SQL tables, with the 
"area_nodes" table having an extra "nodegroup" column.

Areas could be introduced slowly, by simply allowing them in the API and 
not converting anything at first, instead counting on people doing the 
conversion with scripts in the time after the switch. Alternatively, 
areas could be populated from existing area-ways and multipolygon 
relations when they are introduced, but such operations tend to 
complicate the deployment of a new API.

Bye
Frederik





More information about the dev mailing list