The Future of Areas/Areas on Nodes or Ways
Combining the ideas of areas on nodes and areas on ways, a new area data type could also allow its rings to be built from either nodes or ways, like so:
<area> <outer> <way ref="1" /> <way ref="2" /> <way ref="3" /> </outer> </area> <area> <outer> <nd ref="1" /> <nd ref="2" /> <nd ref="3" /> </outer> </area>
or even mixed in the same object,
<area> <outer> <way ref="1" /> <way ref="2" /> <way ref="3" /> </outer> <inner> <nd ref="1" /> <nd ref="2" /> <nd ref="3" /> </inner> </area>
This model can be used for large and small polygons with little overhead. It allows a seamless upgrade from node-based to way-based polygons. Something can first be mapped as a list of nodes, and when it becomes more complex later, or part of the outline needs to be re-used by something else, the very same object can be modified to accomodate the new situation, giving a proper history trace. Were we to use two different object types for these situations, one would have to be deleted and the other created, breaking the history chain.
Harder to process for software.
Same risk of breakage as Areas on Ways and the current multipolygon relation scheme.
Variant: Two-Tier Approach
Areas could be represented in two distinct forms, described below.
In this case an area representation is very similar to an existing OSM way, but marked as a different type:
<area> <nd ref="1" /> <nd ref="2" /> <nd ref="3" /> </area>
Simple areas is intended for a single simple polygon, so there are no holes and no multiple outer polygons. Migration from existing OSM ways representing areas should be pretty easy - just change the geometry type and remove the last node reference.
Complex areas are intended for non-simple cases, like multipolygon relations, coastlines, riverbanks etc.
<area> <outer> <way ref="1" /> <way ref="2" /> <way ref="3" /> </outer> <outer> <way ref="58" /> </outer> <inner> <way ref="1" /> </inner> <inner> <way ref="5" /> <way ref="6" /> </inner> </area>
Complex areas consist of way references only (so you could not mix way and node references) - this is the difference between this variant and the base one described at the beginning of the page. This should reduce the complexity of processing such areas.
A large majority of OSM areas is currently represented efficiently using simple OSM ways. If any new area system is produced, it should retain this efficiency for simple cases. This variant does that by providing a simple area geometry.
Proposed by --Breki 17:19, 10 April 2011 (BST)