[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