[OSM-dev] multipolygons/areas - consistency vs scalability vs topology

Ben Supnik bsupnik at xsquawkbox.net
Fri Apr 15 03:16:29 BST 2011


Hi Y'all,

Josef's comments on relations reminded me that I was going to 
rant^H^H^H^H opine on areas/multipolygons.  In particular, this got my 
attention, from the comments on Josef's diary:

"Basically multipolygons-in-relations are a horrible hack. Hopefully API 
0.7 will move them into an area datatype, and let relations resume the 
'association' role alone"

I'm not particularly plugged into API/data model level 
developments...but the notion of having 'real' area primitives caused me 
to drool and stare at the wiki in a reverie for at least a few minutes.

When I work with planet exports, it seems like I can view an entire 1x1 
degree tile with no obvious road bugs, and yet there will always be a 
few multipolygons that are so munged that my exporter can't put them 
back together again.  My thought is that promoting multipolygons to 
syntax (via some kind of real area primitive) would be the first step to 
enforcing less broken-ness on polygonal areas.

It seems to me that some of the scalability/flexibility features of 
polygons (make polygons out of existing ways or multiple ways per 
perimeter ring) directly clash with having the simplest possible 
primitive, one that would be less likely to be broken.  So I figure I 
have to ask these questions, even if the answer is "no and that's a 
stupid question":

- Is there any chance of having an area primitive so scalable that it 
scales all the way up to the major continents?  Right now continents are 
sort of an exception - you need to go pull down the pre-processed 
coastline shape files because the data processing to build a continent 
or ocean is particularly non-trivial.

- Is there any chance that we could have an area primitive spec so 
simple that it _can't_ be broken.  (E.g. naively a list of list of 
nodes, which would be pretty hard to break unless a user intentionally 
wanted to trash it.)

- Is the gap between 'simple' and 'huge' polygons so large that one spec 
doesn't fit all?

Finally, one more random thought: I think one of the things that makes 
relation-based multipolygons more fragile than the rest of the map (from 
a geometric standpoint) is that the consistency of a multipolygon ring 
depends on the _contents_ of _referenced_ entities.  E.g. For my 
perimeter to be sane, way 1 and way 2 _have_ to share a common node. 
The editor of way 1 may have no way of knowing that (since way 1 is self 
consistent even if one of its end nodes is deleted, removing one line 
segment), but the multipolygon is now broken.

(This is a different case than deleting a node that is referenced in the 
way, where there might still be a way to guess what the way should look 
like.)

The implication might be that building polygons out of ways is what 
makes polygons fragile - it allows for clever topology-like features but 
without an API that _enforces_ topology-like rules, it's easy to break 
stuff.

Okay, I think I'm done now ... no real point here ... frankly I'd be 
happy with nearly any area-like feature in a future API revision.

cheers
Ben


-- 
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://www.x-plane.com/blog/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: x-plane-scenery at yahoogroups.com
Developer mailing list: x-plane-dev at yahoogroups.com



More information about the dev mailing list