[OSM-dev] Area support

Jochen Topf jochen at remote.org
Wed Jul 9 16:53:56 BST 2008


On Wed, Jul 09, 2008 at 02:55:27PM +0200, Frederik Ramm wrote:
> > No, we could continue to use multipolygon relations for that.
> > 
> > I just wanted to point out that our existing primitives are "simple" ones: no compound objects, no holes, only one single coherent object. The new area primitive would be different from that (which of course is not necessarily an argument against it).
> 
> You are right, but proponents of a proper area type also rightly say 
> that it is slightly inelegant to use relations on an upper level 
> (combining ways into routes etc.) on one hand and on a very basic 
> geometry level (putting holes into areas) on the other hand.

Having "real" areas would make the handling quite a bit more practical.
At the moment you can't read the ways sequentially and just do something
with all the areas in there bit by bit. You always have to go through
all of the ways and then all of the relations just to find out that most
areas have no relation but are simple and you could have just used the
way.

Currently there are two ways of modelling an area, one for areas without
holes, one for areas with holes. This makes handling it always a bit more
difficult. Say you have a relation pointing to all parking lots belonging
to a soccer stadium. Some of the parking lots have holes, some don't. So
you have

relation(all parking lots) +--> some ways (amenity=parking) --> some nodes
                           +--> some relations (multipolygon) --> some ways (amenity=parking) --> some nodes

Also to decide whether a way is a linestring or an area you have to look
at the tags. If you have unknown tags, you can't decide what it is. If
you had a distinct area type you can, say render areas you don't
recognize in a default color or so.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298





More information about the dev mailing list