The Future of Areas/Tagging Outlines

Intro

Before relations were used for marking borders (or the area of countries, states, etc.) some people used ways for the border and tagged them with the country level and name to the left and to the right of the way. This had many problems, but it was quite "intuitive". We still do the same thing for coastlines: We do not map the land area or the sea area, instead we map the coastline and make sure to define on which side the land is and on which side the sea. The following proposal is build on that idea. It is very different from the other proposals that introduce an area object.

Proposal

Ways already have a set of tags. For this proposal, each way will get two additional sets of tags. We will call the original set of tags the main tags and the two additional sets the left tags and the right tags. Left and right tags are both also called area tags. All sets of tags are independent. A way can have no, one, or more tags in each set.

The main tags will stay the same, they still describe the attributs of the way object. The left and right tags describe the area to the left and to the right of the way, respectively. Left and right are defined in accordance with the orientation of the way, so if a way is turned around, you probably want to switch the tag sets.

If a way is closed the left and right tags can be seen as inner tags and outer tags. Which one is which depends on the orientation of the way.

Here is how it would look in XML:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <nd ref="3"/>
   <nd ref="4"/>
   <tag k="some" v="tag" />
   <left>
     <tag k="a left tag" v="foo" />
   </left>
   <right>
     <tag k="a right tag" v="foo" />
   </right>
 </way>

(There could be other ways of coding this, but we'll stick with this for the time being.)

Lets look at a few cases:

Case 1: Simple closed way

Lets say you have a building with a simple closed way:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <nd ref="3"/>
   <nd ref="4"/>
   <nd ref="1"/>
   <tag k="building" v="yes" />
 </way>

This would become this:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <nd ref="3"/>
   <nd ref="4"/>
   <nd ref="1"/>
   <left>
     <tag k="building" v="yes" />
   </left>
 </way>

So the tag moved making it clear that this is a way that is to be understood as an area.

Because we have different tag sets we can have one way that describes the border as well as the area. It is possible for instance to have tags describing a fence in the main tag set and tags describing the fenced in property in one of the area tag sets.

Case 2: Coastline

A part of the coastline could be tagged like this:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <nd ref="3"/>
   <nd ref="4"/>
   <tag k="natural" v="coastline" />
   <left>
     <tag k="natural" v="sea" />
   </left>
   <right>
     <tag k="natural" v="land" />
   </right>
 </way>

The orientation of the coastline is not important any more, which makes this case more consistent with others.

Non-closed Ways

If a way is not closed but still has area tags it is part of a larger object. But we would have to check the whole database to find matching inner rings etc. Thats clearly too difficult. So we need a way to connect ways into larger objects.

With a Relation or Area Object

One option would be to have a relation or an area object that has all ways as members, but this has many of the problems of the current situation with multipolygons as relations.

With a Multipolygon Number

We can add multipolygon numbers for the multipolygon on the left and right to each way like this:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <left ref="17"/>
     <tag k="building" v="yes" />
   </left>
 </way>

Because we have the tags for the multipolygons already on the ways, we do not need any tags on the multipolygon object. In fact there is no multipolygon object. The number just makes sure we can tie the ways together. This makes some operations much simpler. To draw a multipolygon for instance you only have to find all ways in your bounding box, not another relation of area object. It is clear from the set of tags used and the existence or non-existence of the multipolygon number, whether this is a normal way, a simple closed polygon or part of a multipolygon.

There is one big drawback here: The set of area tags on those ways have to be the same. If they are not, you don't know what this is supposed to be.

A variant differentiates between inner and outer rings:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <left>
     <outer ref="17"/>
     <inner ref="99"/>
     <tag k="building" v="yes" />
   </left>
 </way>

So this way is part of an outer ring of multipolygon 17 and part of the inner ring of multipolygon 99. It remains to be seen whether this makes sense.

Using Previous and Next

To help with maintaining a closed ring of ways, we could add next and previous pointers to ways like this:

 <way id="1">
   <nd ref="1"/>
   <nd ref="2"/>
   <left next="2" prev="15">
     <tag k="building" v="yes" />
   </left>
 </way>

This would allow us to walk through the chain of ways all around the ring.

Advantages

• Many operations (such as drawing a map for a specified bounding box) only need to get the ways in that bounding box to do their job. No huge object tying those ways together needs to be retrieved or stored.

Disadvantages

• Tags must be duplicated and kept in sync on all ways belonging to the same multipolygon.
• It is not possible to use the same way in several multipolygons (such as when there is a country border that is a state border at the same time)
• Perhaps harder for software to process when ways self-intersect.