[OSM-dev] Area support

[Dave Stubbs]

2008/7/9 Stefan Keller <sfkeller at gmail.com>:
> 2008/7/9 Jochen Topf wrote:
>> Having "real" areas would make the handling quite a bit more practical.
> Agreed. An area (or polygon) simply is a basic geometry type; it's a fact in
> practice and computational geometry.
>
> The actual XML encoding of ways never really was according to best practices
> and will not scale. This is because even for ways we have to read in all
> nodes until the end of the stream/file before any way can be created. Now,
> when we misuse (application oriented) relations to encode areas, processors
> are again forced to read in *all* relation instances before any area can be
> instantiated... Can't we do that better? (the crazyness would be complete
> when one would 'consequently' encode areas *and* ways as partially ordered
> relation instances which would point to nodes).


The XML encoding of ways is according to the actual data model. I'm
not sure which best practices you're referring to. It would make
processing a lot less memory intensive with embedded nodes, so I
assume that's what you mean.

>
> I would take this discussion as a chance to enhance the OSM/XML encoding:
> Ways should be encoded with nodes (coordinates) embedded, and areas
> (polygons) ought to be encoded with one way as outer boundary and zero or
> more inner ways (boundaries) - embedded. I would even differentiate areas
> which overlap and areas which don't (but this is more on the conceptional
> and application modelling level and makes no difference in the encoding).
> Look on the simplicity and usability of such an XML encoding below...

How are you handling nodes shared by multiple ways? Embedding them N
times, or outputting them first and referencing them?
Same for ways referenced by areas (if that was the intention)?

It should be relatively easy (but memory intensive) to write a
converter from the current format.
The planet dump code and the API would be complicated though.. you'd
need to check each node wasn't part of a way before you could output
it -- performance of these components is a big concern.
There's also the diff format to think about and how this would mesh
(ie: how you'd stream an update).

Dave