The Future of Areas/Areas on Nodes

Traditional GIS ("Simple Features") area data types (polygons) are based on coordinate sequences. This would mean that we'd be using something much like a way, except that it can have multiple inner/outer rings, like so:

<area id="1">
  <ring role="outer">   (or just <outer>)
    <nd ref="1" />
    <nd ref="2" />
    <nd ref="3" />
    <nd ref="4" />
  </ring>  
  <ring role="inner">
    <nd ref="5" />
    <nd ref="6" />
    <nd ref="7" />
    <nd ref="8" />
  </ring>
  <tag k="..." v="..." />
</area>

Advantages

This data type is similar to the area data type that existed in API 0.3; it is not much different from today's way data type except that it allows several rings. A simple building would be only marginally more complex than today:

today	with area on nodes
<way id="1"> <node ref="1" /> <node ref="2" /> <node ref="3" /> <node ref="4" /> <node ref="1" /> <tag k="building" v="yes" /> </way>	<area id="1"> <outer> <node ref="1" /> <node ref="2" /> <node ref="3" /> <node ref="4" /> </outer> <tag k="building" v="yes" /> </area>

(note how the area can omit the second mention of node #1; knowing that it is an area makes that obsolete.)

Areas made of nodes may be less fragile than the current multipolygon relations we have now. Since no ways are referenced, changes to the nodes in the child ways can't break the chain of a single ring. If a node is deleted but still referenced, the remaining rings still define a loop (as long as three non-deleted nodes exist).

Disadvantages

For a very large polygon, say Lake Geneva, all nodes would have to be included in the area. This could lead to objects with 10.000 points and more, which would be impractical.

With such a data type we would lose the ability to re-use the edge of an area. A bit of the national border might be a county border and a city border at the same time; currently we can create one way for that border and reference it from the country, country, and city boundary multipolygon. For this, the above style is unsuitable (much like in traditional non-topological GIS systems, we would create a ton of polygons that just "happen to have coincidental edges" but if you move one, the others remain unchanged).

Note - in theory the nodes of the edge could be recycled even though the ways were not, which would create topology-like editing. But differences in the sequencing between two adjacent areas could be a maintenance problem.

Variations

Possible variations on this theme include:

• to make it more similar to the ways, the last node reference could be the same as the first node reference adding a little overhead
• allow tags on rings rather than on the whole polygon only (for the "lake in forest" scenario - structure would then translate to serveral "Simple Features" polygons)
• make the "inner" ring a child (in XML DOM parlance) of the "outer", which would make the inner/outer declaration implicit and unnecessary; allow rings inside inner rings:

<area>
  <ring>
     <nd ref="..." />
     ...
     <ring>
        <nd ref="..." />
        ...
     </ring>
  </ring>
</area>