Render highway=busway as highway=service + access=no

[nighto]

Fixes #4226

Changes proposed in this pull request:

• Renders highway=busway as highway=service + access=no

Rational:
Before highway=busway introduction, busways and BRT systems have been mapped as highway=service + access=no + bus=designated. There is a two year old discussion on how to map busways and a one year old open PR with a proposal to map busways in a certain way, that unfortunately got stuck. With this PR, I intend to start with a very conservative approach: Render busways just like they used to be render with the previously accepted tag.

Test rendering with links to the example places:

(Please ignore the small highway=traffic_signals differences on the renders, my PBF is a couple of days old)

Before has OSM logo, After has Kosmtik logo. Test area is in Eindhoven, Netherlands, zooming towards WoensXL/ZH Catharina bus terminal

Z14

Z15

Z16

Z17

Z18

Z19

Also please note that this proposed rendering is exactly like the previous accepted BRT tag schema, for example BRT Transoeste in Rio de Janeiro, Brazil (which has not been migrated to highway=busway and therefore is still visible on the default rendering):

highway=service + access=no on Z18: https://www.openstreetmap.org/#map=18/-23.00709/-43.31254

[nighto]

One thing I couldn't get it done (sorry, first PR to the project) are the one-way arrows. I tried adding it on L4061 and L4095, but it still didn't work. (Is there some sort of pre-processing needed for it to show?)

Also, as is evident on the above screenshot, it is rendering on top of other highways (i.e. highway=secondary), we could also change that as well. Nevertheless I wanted it to be a starting point (or perhaps a re-start to the discussion, which stalled).

[nighto]

@imagico Could you have a look at this PR? It might be a solution for #4226, at least for now.

[imagico]

This competes with #4456.

Both PRs communicate different ideas of how highway=busway should be used - #4456 for - as explained in #4226 (comment) - a certain subset of bus only roads, this PR for any kind of bus only road. The problem is that neither of these ideas represent current tag use. Merging this would communicate to the mapper that any kind of bus only road can either be tagged as highway=busway or highway=* + access=no + bus=yes. Since the latter is far more commonly tagged i would be reluctant to introduce support for a less widely used tagging as a synonym.

I looked again at the use of highway=busway to see if there is any kind of trend visible in its application in either direction - but that does not appear to be the case. Even in the Netherlands, where 4.3k of the 5.9k uses of highway=busway exist, the tag is widely used for mapping dedicated bus exclusive route networks and small and isolated bypass/service roads exclusive to buses (which - on a global scale - is much more widely tagged with highway=service + access=no + bus=yes).

What can be seen is an increasing use of highway=busway in combination with bicycle=yes or similar and use of highway=busway + access=no without a bus=* tag - with unclear semantics.

If there is consensus in the mapper community that highway=busway is to generally replace use of other highway=* + access=no + bus=yes as the universal tagging for bus only roads i would be fine with this change. If there is a clear consensus about a different, more limited meaning of highway=busway i would be equally fine with rendering that in a distinct fashion - though then we should also show highway=* + access=no + bus=yes distinctly to avoid incentivizing mapping based on subjective preferences.

[nighto]

Hello @imagico, first of all thanks for your reply and your detailed opinions into the matter.

I personally see the tags as synonyms and would be happy with either PR being accepted. I honestly think that there are bus corridors (and specially BRT corridors) still tagged as service purely because of the lack of rendering, as it generates an "egg-and-chicken" problem. Obviously one should not tag for the renderer but I'm sure you can understand that the removal from the rendering of a correctly (or "more correctly") mapped feature could be seen by some as a form of vandalism. IMHO at this present moment there's no incentive to migrate BRT corridors with old, still correct service tagging to the busway tagging (for example, BRT Transoeste in Rio). I am sure that when there is some sort of rendering (either as it is currently rendered when tagged as service, or differently as proposed by the other PR) mappers will migrate "their" bus corridors to the new tag (i.e. organically, checking one by one, not as a mass migration, to be clear).

I don't think highway=busway is necessarily a synonym to BRT corridors (otherwise it would probably be highway=brt_corridor or something like that), as the name implies (and the discussing on tagging list and the wiki page for proposal with voting discussion) it is a bus corridor, meaning a separated way (i.e. not a painted line) which buses (and usually emergency vehicles while on emergency) are allowed to use, with at least some sort of physical separation (even if small traffic separators / bump / dip, not just paint, i.e. the same criteria we have to split ways).

I also think we can make clear use of the busway tag (i.e. not in combination of bicycle=yes) by making it clearer with more examples of "dos" and "don'ts" on the wiki page.

[nighto]

Just to expand a bit further on the "dos" and "don'ts" I mentioned in the previous comment, with some examples from Eindhoven, Netherlands (an example not from Latin America on purpose):

Bus corridor as a way completely separated from other traffic (link to OSM)

Bus corridor on a lane separated by general traffic by something else than just paint, in this case a small dip / bump. Maybe this one shouldn't be tagged as highway=busway? (link to OSM)

Bus corridor on a contraflow lane on the same way opened to general public. In my opinion this one should not be tagged as highway=busway because we don't map separate lanes on the same way as separate OSM ways. So it should be something like oneway=yes + oneway:bus=no. (link to OSM)

[matheusgomesms]

From my understanding, this PR is more conservative, while the other one makes a much more distinction from service roads. The other one did not advance because (among other reasons) it may conflict with other Carto problems from 5-6 years ago.

I believe this one, which is way more conservative (given it does not change rendering from current tagging), is a good solution for now. If those other problems are fixed, maybe we can revisit #4456 later. This one does not introduce any problem on rendering and will help the transition from the old tagging to the (not so new) approved tag.

And as said before, the lack of rendering makes the tag not used as it should. With some type of rendering, we could allow the mappers into making the transition. I did the transition in April 2021 in my city, but I understand why @nighto did not change that in Rio.

(Yes, the wiki should be updated to make it clearer the distinction between highway=busway and highway=service + access=no + bus=yes, with more examples maybe. Even so, the current page already gives some good examples).

[nighto]

Any news on this? Sorry to be a pain but another month went by with no news on this PR acceptance.

[imagico]

I have commented on this extensively here and in #4226 (comment). Unfortunately not much discussion has happened based on this, neither here nor in the mapper community regarding better defining the delineation between different tagging approaches to bus exclusive roads.

Anyway, enough has been said about the strategic side of this matter by me already and i perfectly understand if pursuing this on such a strategic level is not what you feel like doing. I understand that for you highway=busway is a synonym for highway=* + access=no + bus=yes and under that premise this change makes sense if the ultimate goal is to replace the latter tagging with the former. Unfortunately the latter tagging is vastly more widespread than the former so far (30k vs. 6.6k uses). At the same time my analysis showed that highway=busway is not used with a higher level of consistency world wide than highway=* + access=no + bus=yes. And our goals explicitly mandate us to try to avoid supporting proliferation of tags. Also, there are many indicators that mappers mostly think there is a semantic difference between the two taggings (but unfortunately so far opinions vary a lot regarding what that semantic difference actually is).

In light of this i am currently not inclined to merge this change but i am not opposed if it finds consensus support from the other maintainers.

[mdejean]

Unfortunately the latter tagging is vastly more widespread than the former so far (30k vs. 6.6k uses).

It will remain so, because only some of the potential uses/meanings of highway=service + access=no + bus=yes are taken and the majority will remain. Perhaps there is not a bright line currently, and maybe there never will be, but if you believe this is a prerequisite the tag will never be widespread enough for you to support it.

[imagico]

Confirming my point that there is no consensus among mappers if highway=busway is a synonym for highway=* + access=no + bus=yes or not and if not what the delineation between those is.

[Blijbol]

And our goals explicitly mandate us to try to avoid supporting proliferation of tags.

Your goals explicitly mandate you to provide feedback "for mappers to validate their edits and helps to prevent unfavorable fragmentation of tag use". The fragmentation of tag use you are referring to has been judged as favorable by community approval of the highway=busway proposal. Until this or another PR is merged, this style is providing incorrect feedback that highway=busway is invalid.

This continued refusal to accept the result of a formal OSM community vote is also terrible for the goals of being "a major part of the public face of OpenStreetMap" and "an exemplar stylesheet for rendering OSM data".

[imagico]

As we have said many times in other contexts: The proposal process on the wiki is a means to allow mappers to evaluate their tagging ideas in discussion with a somewhat wider audience and possibly identify and address issues that they have not seen. It is not in any way authoritative to anyone - neither mappers nor data users. It can help increase the chance of a new tagging idea to be successful, it is not a guarantee for that. And it has no bearing on our decision if and how to render certain tags. We base that primarily on how tags are actually used.

Since apparently questionable statements have been made about OSM-Carto in other venues in context of this pull request i like to clearly point out again: No OSM-Carto maintainer has so far indicated that they are against rendering highway=busway in this style. On the contrary, the tag has been proactively included in the z-order definition of the data import rules in a re-design of those under development - see #4431 - in anticipation of the possibility that rendering of that might be added in some form.

Personally i have clearly stated in the discussions linked to above what for me are the conditions under which i'd support adding rendering of highway=busway in this style. Not only that, i also developed a demonstration how a design concept along these lines could look like here. And i have clearly stated - both here and on #4456 - that i would not oppose if other maintainers would support such an addition under different premises.

Anyway - this whole discussion is off topic on this pull request. Please limit comments here to matters relevant to the specific design concept suggested here. Discussion of the rendering of highway=busway in general belongs to #4226, for discussion of OSM-Carto map design guidelines please open separate issues.

[marioxcc]

You should already render highway=busway. It is approved and used in practice. Not rendering it makes the map incomplete. The current situation is like not rendering (for example) highway=track.