User:ZeLonewolf/proposals/Boundary relation way members

From OpenStreetMap Wiki
Jump to navigation Jump to search
Boundary relation way members
Proposal status: Draft (under way)
Proposed by: ZeLonewolf
Tagging: boundary=*
Applies to: way
Definition: Ways that are members of boundary relations
Statistics:

Draft started: 2020-10-18

Proposal

This proposes that boundary relation member ways are no longer recommended to be tagged with boundary=* or its subordinate tags.

Current text

Boundary ways should have boundary=administrative and the admin_level=* for the highest border (when a country, state, county are on the same way the admin_level would be 2). source=* is always recommended.

Because boundaries can be rendered both from relations and individual ways, tagging the ways is, in the strictest sense optional. There was a render issue (see this Github discussion), but this was resolved.

Boundary relationships are useful for many tools, but not necessary for rendering purposes, which is why boundary lines should be tagged to allow for the renderer to use them again."
— OpenStreetMap Wiki, Relation:boundary#Way_tags

Proposed text

It is not required to tag boundary relation member ways with tagging that applies to the whole boundary, including type=boundary, boundary=* and all subordinate tags such as admin_level=*, protect_class=*, name=*, etc, as this information should be tagged on the parent boundary relation. It is recommended that member ways be tagged with source=* to indicate the data source of the individual way geometry. Avoid connecting boundary ways to physical features like woods or rivers, as these features change over time while boundaries usually remain fixed by legal definition. An exception is if the boundary is legally defined to be the physical feature.

It is acceptable and appropriate to tag boundary=administrative + name=* on member ways that are notable or significant in some way. In this case, the name=* indicates the name of the particular boundary section, rather than the name of the whole boundary. Examples of this type of tagging include:

History of Boundary Relation Tagging

In 2007 and earlier, boundaries were marked using a series of ways. Each way could be tagged with tagging such as name:right=*, name:left=*, region:right=*, nation:left=*, etc, to indicate what was on either side of the boundary. Renderers and data consumers at the time used boundary=* on ways to discern boundaries.

By 2008, the first variant of boundary relation was proposed, and by 2010 it achieved its current form, using Role inner and Role outer to indicate the parts of the multipolygon. By 2013, all former variants of boundary relations (such as the proposed roles Role enclave and Role exclave) were removed from the database. Since 2013, boundary relation tagging has been stable, maintaining the same scheme.

When the boundary relation was first created, no renderer or data consumer supported it, relying instead on member ways being tagged with boundary=* in addition to applying the same tags to the relation. This ensured that boundaries would continue to render and be supported by data consumers, giving the downstream tools time to support the new construct. In the ten years since boundary relations have achieved their current form, renders and downstream consumers have all converted to using relations, judging from the fact that that a significant percentage of the database has administrative boundary relations that lack boundary tagging on their member ways with no ill effect.

The fact that it is still a common practice to duplicate boundary tagging on member ways is simply a vestige of that 2008-2013 transition period during which both sets of tags were needed because not all data consumers had been updated to work with boundary relations.

Rationale

  1. The current recommendation that duplicate tagging should be done, while simultaneously declaring that it is unnecessary, is contradictory and confusing. This proposal clarifies this guidance by declaring that such duplication not required.
  2. The new recommendation leaves open the possibility for such duplicate tagging if needed for unusual circumstances, such as the need to apply a name or other attributes to a specific sub-section of a boundary.
  3. The mass duplication of relation tagging on individual member ways creates unnecessary database bloat because the information is already contained in the relation. Adopting this change allows this duplication to be safely removed when encountered, and provides guidelines to mappers of new boundary relations to avoid excess tagging.
  4. The optional tagging of boundary relation members with boundary-style tags conveys no additional information.
  5. In the case of simple boundaries, mappers may choose to map these with a simple closed way. However, this creates identical tagging to the case of boundary exclaves in which the mapper also tagged the exclave member ways. It would be impossible to tell whether a closed way tagged with boundary=* is intended to be a standalone boundary, exclave of a parent boundary relation, or both, without looking at additional tagging for clues on the mapper's intent. This creates a considerable challenge for boundary data consumers.
  6. This change makes the tagging of boundaries simpler.
  7. The original text is specifically describing administrative boundaries, however, there are other types of boundaries such as boundary=protected_area and boundary=aboriginal_lands, and guidelines for the boundary relation should be generic to all types of relations.
  8. Major data consumers use boundaries tagged as relation. ÖPNVKarte is a sole known data consumer not capable of using boundary relations.
  9. There are many examples globally where boundary tagging is omitted. The overpass query listed in the examples section demonstrates the massive number of boundary member ways tagged in this way, all with no apparent ill effect to the rendered map or to data consumers.

Taginfo Analysis

Taginfo for admin_level=*:

A taginfo examination reveals that 63% of the instances of admin_level=*, over 1 million objects, are applied to ways rather than relations. While some of these instances may be usages on closed ways which do not have a parent boundary relation, in general this is not the usual practice. As such, these numbers indicate a strong likelihood that there is a considerable amount of unnecessary, duplicitous tagging.

Examples

Examples where boundary relations and member ways have duplicate tagging:

Examples where all boundary tagging is done on the relation:

Visual Comparison

The two boundary segments below are both international borders, at the same zoom level. Both render identically, despite one having duplicate boundary-style tagging on each of its member ways. This is a simple demonstration of the redundancy of the extra tagging as shown by the OSM Carto rendering style.

This way way 533083055 on the US/CA border
has both relation and member way tags 		This way way 836134333 on the CM/GA border
only has relation tags

Overpass Query

The following Overpass query shows administrative boundary member ways that are not tagged with boundary=administrative + admin_level=*.

try it yourself in overpass-turbo
[timeout:360][out:json];
rel({{bbox}})["boundary"="administrative"]["admin_level"];
>;
way[!"boundary"][!"admin_level"]._;
(._;>;);
out skel qt;

Applies to

  • way Ways that are members of boundary relations.

Rendering

This guideline change in member way tagging does not affect rendering style.

All renderers that draw boundaries are still recommended to use boundary relations. After this proposal it is recommended to start ignoring boundary tagging on ways, though as usual data consumers are free to interpret data however they want.

Validator

Validators are recommended to warn a user when an unclosed member way and its parent boundary relation both have an identical boundary=* tag.

Features/Pages affected

Page Change
Relation:boundary#Way_tags Change the text in this section as described in the proposal
Each value of boundary=* Change the ValueTemplate on these pages so that "applies to" is set to onArea=no

External discussions

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User:ZeLonewolf/proposals/Boundary_relation_way_members&oldid=2132629"