Hi,
First time I’m encounter this and TBH I’m surprised. Is it something we should keep like that?
at least it doesn’t hurt in the way that it’s not misusing tags for something else to get some rendered result, but I would really like to know to whom a line is “a physical structure which blocks or impedes movement”…
anyway, seems like it’s not that uncommon: barrier=line | Tags | OpenStreetMap Taginfo
2 Likes
This is absurd “mapping for the renderer” and completely unnecessary. A barrier tag is inappropriate as using it forces consumers to either : a) white list known barrier tag values & ignore others, which may be potentially valid; or b) treat all barriers as obstructions with bizarre side-effects. In practice (a) already occurs, but I don’t think it’s a good reason to abuse the tag.
5 Likes
The proposed lines:soccer=yes could be used, although that distorts the meaning between “pitch that has such lines” and “the lines themselves”. One example exists: Way History: 308187391 | OpenStreetMap
2 Likes
(at the risk of attempted grandparent education) any free tagging scheme requires that something like (a) happens when “a specific action is to be performed on a tag value” - with barriers, people can choose to ignore barriers they don’t recognise (as happens with most renderers) or default to something like “barrier=yes” (which some routers do). “barrier=line” isn’t a tag I’d have chosen, but it is in reasonably widespread use.
This is indeed mapping for the renderer. IIRC, the abuse of the barrier key for pitch markings gained traction at a time when osm-carto still showed all barrier=* ways as a visible line.
I also agree that it is unnecessary, as several renderers have demonstrated the ability to display standard pitch lines without the need to draw those as ways.
barrier=line contradicts the established meaning of the barrier key, which has several orders of magnitudes more uses. Number of uses is a decent metric for new tags that do not conflict with existing definitions, but I disagree that 4k uses do in any way justify the dilution of an existing, approved key used 20 million times.
And yes, it is already often necessary to resort to special treatment for individual values when working with OSM data, but maybe that should tell us that “free tagging to the max” isn’t actually good way to design a data model. A data consumer should be able to assume that all building=* areas represent buildings, for example, no matter the value. They should not need to maintain a list of 834 “known good” building values because someone decided to invent building=something_completely_different_I_want_to_see_on_the_map.
1 Like