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

["Marc Schütz"]

> 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.

Are areas-with-holes really necessary (as primitives)? After all, we don't have multi-ways or ways-with-gaps either...

Regards, Marc

-- 
Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03