Talk:The Future of Areas/Tagging Outlines

This strikes me as a more problematic representation than most of the other proposals.

Most of the other proposals make an incremental change by promoting multipolygons to real OSM entities (rather than modeling a relation) - the implication is that a combination of known meaning to the syntax and perhaps cleaned up syntax could lead to better processing and fix a bunch of multi-polygon problems.

My concern about this proposal is that it is highly topological in nature, and I don't see a lot of existing infrastructure in OSM to make this kind of schema efficient or practical. Here are some specific concerns:

• It is impossible for inspecting software to know whether a non-closed way is broken (e.g. it should have been closed but there was an edit problem) or part of a larger set of ways.
• The construction of a multi-way ring requires previous and next pointers, which strikes me as fragile.
• Since a way can participate in multiple "layers" (the edge of the pond _is_ the edge of the park) a way might need multiple previous and next pointers.
• Similarly, since a way can define multiple features boundaries, the left and right properties must be arrays (as in the example, where it is both a park and a pond on the left).

Generally, it seems like there is a many:many relationship between ways and polygon edges, but collecting the ways in the polygon is more useful than vice versa (which is what this proposal does) - the ordering is maintained more easily and traversal is simpler.

If several ways all have "Lake Woebegone" on the left, which one contains the definitive info for the lake? The other proposals (which make an area a first class object) provide a more concrete way to tag. (One problem with current multipolygons is that the spec for where tags appear on the ways/relations is not particularly clear and leads to inconsistent mapping.)--Bsupnik 02:37, 11 April 2011 (BST)