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: [email protected]
Developer mailing list: [email protected]

_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev

Reply via email to