[OSM-talk] multipolygon (lake) not rendering

[Frederik Ramm]

Hi,

Anthony wrote:
> What would be the advantage of an area data type?  Would this be a
> separate table or just a type of relation?

Exactly what advantage(s) it has of course depends on how it is designed 
and implemented in the end.

The problem with our current approach is that we are mixing layers in 
our model in at least two places. One, completely apart from 
multipolygons, is the way we use a closed way to model a polygon - or 
not (closed way with natural=forest ==> polygon, closed way with 
junction=roundabout ==> linear ring). This means that it is impossible 
to "blindly" convert our data into, say, a shape file; you have to 
actually look at the tags and understand them to do this, even if you 
didn't actually want to meddle with tags.

This is as if you asked someone to transfer an old VHS tape to DVD and 
they say: But I can't to that without knowing what kind of film you have 
on there! (Well ok, lame comparison, but you get the drift.)

The other is multipolygons, where we (ab)use the relation object which 
is *normally* used to model a relation between several primitives, to 
actually construct a primitive in the first place. Constructing the 
geo-object and putting it in relation to other objects should really 
happen on separate layers.

I would also hope that along with a proper area data concept would come 
the ability of the API to return an area to the caller even if the area 
fully encompasses the queried bounding box.

All these are not big things and we have meddled our way through and 
around them, but I'm beginning to think that there are places where you 
can and should discard ancient wisdom because it only slows your 
progress - and others were, even if it is not clear to you from the 
outset, actually referring to that ancient wisdom makes things easier.

Computational geometry has worked with point, line, and polygon 
primitives for ever, and maybe computational geometry is one of the 
latter sorts of ancient wisdom.

Bye
Frederik