there now seems to be a consensus of using the boundary key also on linear ways, with relations used to aggregate these ways if needed.
I believe this to be an incorrect statement. My understanding of the consensus is that member way boundary tagging (e.g. boundary=*, admin_level=*, etc), is redundant and potentially harmful and should removed. I have been routinely removing this tagging when I encounter it.
The only exception I’m aware of that folks have expressed is for tagging linear boundaries in this way is in the case where individual boundary lines have their own name separate from the area that it bounds, for example perhaps something like name=Mason-Dixon Line.
I would like to update this page to reflect that understanding if that is accurate.
IIRC I read about a use case at one point where the boundary is only partly known. e.g. because there is no open data or out of copyright source for the information, but there are occasional markers. In that case the boundary tag can be put on the way and an indication of what borders it is indicated using keys with the :left and :right suffix.
This page indicates that this is a “historical” practice, but if someone’s working locally and trying to slowly build up a picture of their area then I don’t see any reason why it couldn’t be used today.
Boundary relation member ways used to be tagged with boundary=* and some admin_level=* and name:left=* and name:right=*, but that was a long time ago, back in the days of old-style multipolygons. The documentation should be updated. If a boundary is only partially known, then the relation can be incomplete, and the members can have name:left and name:right, but this still doesn’t require the member ways to become boundary features.
This was discussed on the tagging mail list [Tagging] Tagging request: missing admin_level tags and is maybe the only time I’ve ever seen a consensus on a tagging question, which was to not duplicate the tagging on the boundary relation’s ways.
The One other exception is tagging which of the ways are maritime boundaries.
I remember the time when we used to tag boundary lines with
boundary=administrative and the highest admin_level it was used in. (I
never understood the “name:left” and “name:right” shenanigans.)
I think that these tags don’t serve much of a purpose now, however I
wouldn’t go so far as to delete them outright; a sole
boundary=administrative on the way would tell even the most careless
person (who doesn’t look at relations that may contain this way) that
this way is not just some untagged rubbish lying around.
I certainly do not think that such tags are harmful.
If you do edit the wiki page, I’d prefer if you chose a wording that
does not indicate any kind of “deprecation”. If you want, you wan write
that relations are now considered the primary source of boundary
information, and boundary=administrative tags on ways are only FYI.
(We should also be careful not to require relations for boundaries; as
far as I know, a closed way with boundary=administrative would be
totally fine?)
You now have, perhaps, from a data consumer perspective, the following:
A boundary relation for Chicago
A boundary defined as a closed way for Chicago Boundary and City of Chicago Boundary.
So where you intended to have just one boundary called “Chicago”, instead you have three boundaries with slightly different names. And worse, the inner one (called Chicago Boundary) actually surrounds an area that is not even in Chicago.
The database is absolutely littered with cases of this, and the only sane thing a data consumer can do is treat boundary relations as the sole source of city boundaries and ignore boundary tagging on member ways.
So I strongly disagree - all boundaries must be modeled as relations in order to distingush them from the massive amount of boundary tagging that is repeated on member ways and would be wrongly interpreted to be a boundary in all sorts of ways.
Further to the point, the genesis of this thread was a user that – we assume based on reading the wiki since we’ve not yet seen a response to recent changeset comments – was adding duplicate tagging back to member ways.
Boundary areas can be rendered both from relations and from individual closed ways. Relations also allow treating it as entire object in all cases allowing, for example, better labelling.
Boundary ways may have boundary=administrative and the admin_level=* of the highest border (when a country, state, county are on the same way the admin_level would be 2). source=* is always recommended. However, this tagging is optional, since data consumers can infer this information from the relations the way participates in; thus, boundary ways may be left completely untagged, as with multipolygons.[1]
Another exception would be maritime boundaries. As I understand it, a territorial water limit would be tagged maritime=yes in addition to the usual administrative boundary tagging, while some other kind of maritime limit associated with an administrative area would be boundary=maritime. I don’t know if maritime limits are considered for any other kind of boundary, such as protected_area or aboriginal_lands.
There aren’t too many indefinite boundaries left in the world, at least at the international level, but for OpenHistoricalMap, I’ve taken to tagging indefinite=yes on ways, similar to how we’d handle a disputed boundary. OSM is currently only using that tag to close peninsulas that are poorly defined on one end.