Add rendering for `highway=busway`.

[kolgza]

BRT (Bus Rapid Transit) systems is a form of public transportation that is extremely common in the America's (especially in Latin America). A notable feature of these systems are bus-only roadways. Sometimes, these roadways are refereed to as busways (not to be confused with bus-lanes on public access roads) or fixed guideways (not to be confused with guided busways).

The tagging scheme for this type of roadway is a combination of highway=service, acces=no, and bus=designated, although a proposal for highway=busway is in the draft stage.

These roadways are often incredibly important pieces of infrastructure. However, they have extremely low visibility in carto.

---

The image displays how the busways in the city of Pittsburgh are shown in carto at zoom-level 13.

The following is an image of one of the busways—the East Busway—after a user incorrectly tagged it as a guided busway. The East Busway is the most important piece of transit infrastructure in Pittsburgh (carrying more passengers than the light rail lines), and so this user tagged for the renderer in order to highlight this. Who knows how often this happens?

The following is the official transit map for the city of Pittsburgh. Notice how it depicts the busways with the same level of importance as the light rail lines. Notice how the first image does not reflect this level of importance.

[nighto]

Since those last posts I decided to migrate Rio de Janeiro's 4 BRT corridors (Transoeste, Transcarioca, Transolímpica and Transoceânica) to highway=busway. With this effort we now have 1542km of busways mapped with the new tag.

[nighto]

Another month went by. The Brazillian community migrated all BRT corridors in the country to the new tagging scheme and with that we currently have 1798km and over 11k ways.

https://taginfo.openstreetmap.org/tags/highway%3Dbusway#chronology

[jdhoek]

@nighto

and over 11k ways.

When I looked today there where exactly 11.111 highway=busway. :nerd_face:

I've updated #4456 with unpaved styling (along with a general rebase) to stay consistent with the other highways.

Not that I expect there to be many unpaved highway=busway, but if there are, that PR has it covered (top half of sample):

(Of course, if #4456 is still too controversial, #4714 is available too.)

[gbragaalves]

Is there any reason this fix has not yet been implemented?

[OttoROSM]

Can we make this happen? It is quite ridiculous that this is not being rendered.

[andrepoiy]

[bveldkamp]

Just adding my vote here. Can we please have any rendering for busways?

[fincentxyz]

Why are busways still not being rendered? It looks so strange that some roads seem to be missing while they're actually mapped.

[Geim66]

Yep, a vote from me too. Please render busways.

[marioxcc]

There are 2766 km of highway=busway. The OSM Carto maintainers continue to ignore the issue and thus have failed in their task. I propose we write to the OSM foundation directly.

[jdhoek]

There are 2766 km of highway=busway. The OSM Carto maintainers continue to ignore the issue and thus have failed in their task. I propose we write to the OSM foundation directly.

True, but this was done in May 2022 too: https://lists.openstreetmap.org/pipermail/talk/2022-May/087525.html

Nothing changed, unless you consider the current unfortunate stagnation of this project.

If you contact them, do reference that missive.

Unfortunately, the OSMF does not seem to consider the state of the default render layer on openstreetmap.org their responsibility, and with the exception of some lacklustre messaging cannot or will not address the disappointing omissions by the default layer on openstreetmap.org.

Of course Carto is an independent project, so its maintainers can do what they want with it; including acting as gatekeeper for tags they personally dislike.

Now, inevitably you will get a reply here from one of the maintainers which will come across as gatekeeping to some. My pre-emptive answer to that:

There are thousands of roads mapped using an established tag. These are not rendered on openstreetmap.org creating glaring holes in the road network and giving mappers and user alike misleading feedback. It doesn't matter that you consider some minor point unaddressed: just render something.

[marioxcc]

Tracestrack was recently added to the OSM web site and supports busways.

OSM Carto will slowly and inexorably fall into irrelevance as the maintainers refuse to do any software maintenance while OSM as a whole continues to develop.

Next time I suggest somebody to look into OSM, I will link to Tracestrack, not to OSM Carto.

[imagico]

Additional info: On #4902 @GJDillen posted a screenshot apparently from here:

https://wiki.openstreetmap.org/wiki/NL:Tagging_van_Nederlandse_wegen

which communicates highway=busway to be the universal tagging for bus only roads (i.e. a full synonym for what is otherwise tagged as highway=* + access=no + bus=yes/psv=yes). I don't know if this reflects mapping consensus in the Netherlands - but if it does this points towards a possible increasing regional differentiation in tag meaning.

The general trend in practical use of tags seems to be that highway=* + access=no + bus=yes and highway=busway are used interchangeably in many parts of the world without there being a semantic differentiation and that the basic premise of https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbusway - that highway=busway means something distinctly different from highway=* + access=no + bus=yes is often not reflected in actual mapping.

And the way iD frames tagging presets nudges mappers in a similar direction as well - if i search for bus in iD i get busway and other bus related primary tag, i don't get anything with explicitly tagged access restrictions.

However, so far we are pretty far away from highway=busway replacing highway=* + access=no + bus=yes as the consensus tagging for any and all bus only roads world wide. Hence my suggestion in https://github.com/gravitystorm/openstreetmap-carto/issues/4226#issuecomment-911479559 still applies - solving #214, and in context of that think about rendering highway=busway in a way that reflects a distinct meaning (which would likely be in analogy to highway=pedestrian). A possible design approach to this is shown in https://imagico.de/blog/en/rethinking-road-access-restrictions-rendering/

[IIVQ]

Additional info: On #4902 @GJDillen posted a screenshot apparently from here:

https://wiki.openstreetmap.org/wiki/NL:Tagging_van_Nederlandse_wegen

which communicates highway=busway to be the universal tagging for bus only roads (i.e. a full synonym for what is otherwise tagged as highway=* + access=no + bus=yes/psv=yes). I don't know if this reflects mapping consensus in the Netherlands - but if it does this points towards a possible increasing regional differentiation in tag meaning.

Basically, the Dutch community is divided between

• Use highway=busway as universal tagging for bus only roads
• Don't apply it too much because it doesn't render on the main openstreetmap view.

The latter has declined a lot now the new Tracestrack Topo layer is available, which renders highway=busway with a nice differentation from other road types (green stripes along the road center)

The general trend in practical use of tags seems to be that highway=* + access=no + bus=yes and highway=busway are used interchangeably in many parts of the world without there being a semantic differentiation and that the basic premise of https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbusway - that highway=busway means something distinctly different from highway=* + access=no + bus=yes is often not reflected in actual mapping.

In the Netherlands, there is no semantic difference between the two. This (completely grade-separate dual carriageway for buses with aquaduct under canal and later on suspension bridge over mayor highway) is a "Busbaan", this (very short section of road with a general no-access sign and "except buses" and "Lijn bus" written on the pavement) is too. They are covered under the same (relatively new and hence not yet universally used) traffic sign F13

The distinction between small-scale and large-scale "bus road" is not a hard cutoff but a very uniform distribution, hence why it's (in the Dutch situation) not easy to tell what roads should be highway=busway in the strict definition, and what roads shouldn't.

[Squizie3]

Following this (non-)progression for a few years now, I'm wondering what is currently holding back implementing the style change? Like specifically, what are the current barriers left, and what has to happen to clear them?

For the record: usage still kept increasing significantly so currently there is already about 3563 km of unrendered highway=busway and an additional 352 km of highway=bus_guideway that would be involved in the much needed design change. Which by now is more than there are highway=service + access=no + bus=yes

[imagico]

I'm wondering what is currently holding back implementing the style change? Like specifically, what are the current barriers left, and what has to happen to clear them?

From my side the barrier is the lack of a suitable design implementation. The requirements have been explained quite in depth in previous discussion here as well as in the two pull requests that have been made (#4456 and #4714).

Given the use of the tag seems to be heavily divided between (a) use specifically only for BRT route networks - as documented on the wiki and (b) use for any and all roads routinely used by buses but not allowed for normal cars, a rendering that is compatible with our goals here would IMO require solving #214.

Which by now is more than there are highway=service + access=no + bus=yes

That specific tag combination is not overly relevant for the discussion here. I explained the conflicting ideas on the use of the tag above in https://github.com/gravitystorm/openstreetmap-carto/issues/4226#issuecomment-1807069781. So far there is clearly no consensus that highway=busway is to replace highway=* + bus/psv=yes/designated + access=no/motor_vehicle=no. At the same time it is quite clear that there is also no consensus any more that highway=busway is limited to what is currently documented on the English wiki.

[Squizie3]

From my side the barrier is the lack of a suitable design implementation. The requirements have been explained quite in depth in previous discussion here as well as in the two pull requests that have been made (#4456 and #4714).

In #4456 I see no objections anymore after the access markings were dropped from the rendering. Without the access markings there is no violation of any general principle regarding the current implementation of access marking rendering anymore, correct?

Given the use of the tag seems to be heavily divided between (a) use specifically only for BRT route networks - as documented on the wiki and (b) use for any and all roads routinely used by buses but not allowed for normal cars, a rendering that is compatible with our goals here would IMO require solving #214.

Isn't there a way to decouple these issues? If I understand correctly, the fear is that a distinct rendering of highway=busway without a more specific rendering of access markings like your proposal would get people into mapping more busways than the current definition allows. But if the definition is made more clear and more widely agreed on, mappers would be able to point to the wiki definition stating it is mapping for the renderer (btw, mapping for the renderer now also happens a lot, but the other way around due to the non-rendering of busways). As I understand, this is an issue only because of the current vague implementation of the meaning of busway on OSM, that leaves too much room for personal interpretation. But if that definition can be sharpened (discussion to be held on OSM), the coupling with issue #214 isn't necessary anymore. Decoupling would mean faster implementation, the issue #214 is extremely old and not unique to busways.

Which by now is more than there are highway=service + access=no + bus=yes

That specific tag combination is not overly relevant for the discussion here. I explained the conflicting ideas on the use of the tag above in #4226 (comment). So far there is clearly no consensus that highway=busway is to replace highway=* + bus/psv=yes/designated + access=no/motor_vehicle=no. At the same time it is quite clear that there is also no consensus any more that highway=busway is limited to what is currently documented on the English wiki.

Ok, I think I understand that first the definition of what is to be mapped as busway needs to be made more precise, which is a discussion to be held on OSM itself. When there's a better definition (and it starts to be adopted that way on the map), this will be helpful to know in which direction the rendering itself needs to go. As I understand it, there are in general two possibilities, with different outcomes: 1) highway=busway becomes a more broadly defined almost full replacement of highway=* + bus/psv=yes/designated + access=no. I think if I read correctly, that both a temporary solution like #4714 and a more advanced implementation as #4456 would be ok to you, if this is the outcome? 2) highway=busway becomes more narrowly defined/confirmed as a BRT-style infrastructure (or whatever is the outcome of the discussion), with highway=* + bus/psv=yes/designated + access=no still being the preferred usage of other types of bus infrastructure. In this case, I think only a solution like #4456 is ok, but if this definition is supported by the mapping community and gets adopted on the map, there wouldn't be a barrier to implement it anymore?

So, in conclusion, I think the most pressing issue is the current ambiguous usage of highway=busway? If that can be solved by discussing it on OSM and adopting the outcome on the map, would it then be possible to merge one of the two current pull requests, based on the outcome?

[imagico]

Please keep in mind that we try to be supportive of existing consistent mapping practice while being agnostic as to where tagging develops.

The concern if we'd render highway=busway in a distinct fashion while not at the same time or before rendering access restriction on normal roads in a more comprehensive form (i.e. #214) is explained in https://github.com/gravitystorm/openstreetmap-carto/issues/4226#issuecomment-911479559. For OSM-Carto solving #214 is of much higher importance, it has been a point of concern for much longer and affects millions of features (bus/psv=yes/designated in combination with access=no alone is nearly 100k).

Even if you'd envison adding highway=busway before addressing #214 (other maintainers might be fine with that) you'd have to consider #214 when developing a design concept for the former. Map design - in constrast to software development - always requires a holistic view of the whole map. You cannot compartmentalize and implement features without taking the larger design strategy and the harmonic integration with other features into account.

1. highway=busway becomes a more broadly defined almost full replacement of highway=* + bus/psv=yes/designated + access=no. I think if I read correctly, that both a temporary solution like #4714 and a more advanced implementation as #4456 would be ok to you, if this is the outcome?

2. highway=busway becomes more narrowly defined/confirmed as a BRT-style infrastructure (or whatever is the outcome of the discussion), with highway=* + bus/psv=yes/designated + access=no still being the preferred usage of other types of bus infrastructure. In this case, I think only a solution like #4456 is ok, but if this definition is supported by the mapping community and gets adopted on the map, there wouldn't be a barrier to implement it anymore?

As said already - we try to be agnostic as to where tagging develops. But past experience indicates that (2) is a very unlikely scenario on a global scale - the meaning of tagging almost never narrows substantially in scope once a tag has gained wider use. At the moment the trend seems to go towards substantial regional differentiation, i.e. the de facto meaning of the tag significantly depends on where on the planet you look. See also https://github.com/gravitystorm/openstreetmap-carto/issues/4226#issuecomment-1807069781. This development IMO calls strongly for addressing #214 before or together with supporting highway=busway in some form.

[Squizie3]

Please keep in mind that we try to be supportive of existing consistent mapping practice while being agnostic as to where tagging develops.

The concern if we'd render highway=busway in a distinct fashion while not at the same time or before rendering access restriction on normal roads in a more comprehensive form (i.e. #214) is explained in #4226 (comment).

I understand your viewpoint of wanting to just support existing mapping practices. However, one way or another, the problem of how to render it seems to get stuck exactly on the existing vague definition and usage, and the implication of rendering it that would encourage even more personal interpretation of which tag to use. If that gets resolved by opening a new discussion on the practice on OSM to more clearly delineate the highway=busway tag, wouldn't that make life a lot easier here?

For OSM-Carto solving #214 is of much higher importance, it has been a point of concern for much longer and affects millions of features (bus/psv=yes/designated in combination with access=no alone is nearly 100k).

I understand, in the broader perspective this could definitely be the case. However, it seems no progress is being made on that front either. But if people are willing to put effort in getting busways rendered while having less interest in advancing the other issue, I don't see why that effort should be blocked, as long as it takes the possible implications of that design change into account, like you mention next. At this point, lots of people wanting to get the busways feature fixed and even want to put effort in it, seem to simply have lost faith in a solution due to the roadblocks that seem to get thrown in the way constantly, like other issues that are only partly related. In general, if you want to come to a solution, the way forward is to break things down in multiple steps that can be solved, not to tie everything together into one massive issue that throws everyone off. And that seems to be happening here. I'm trying to see if we can untangle it into a few concrete steps so people can start working on those again, as I'm sure there are people that have shown interest but now don't see a way out any more, would jump back in if there is perspective again.

P.S., length wise the difference between highway=*+bus/psv=yes/designated+access=no (8468 km) and highway=busway/bus_guideway (3922 km) is much less severe, just for the record.

Even if you'd envision adding highway=busway before addressing #214 (other maintainers might be fine with that) you'd have to consider #214 when developing a design concept for the former. Map design - in contrast to software development - always requires a holistic view of the whole map. You cannot compartmentalize and implement features without taking the larger design strategy and the harmonic integration with other features into account.

I completely understand that, any rendering proposal should consider a possible change in access rendering. As far as I understand, the most likely candidate is your well thought out proposal on that. A dash-less line with a distinct colour would be perfectly compatible with that I think, isn't it?

1. highway=busway becomes a more broadly defined almost full replacement of highway=* + bus/psv=yes/designated + access=no. I think if I read correctly, that both a temporary solution like #4714 and a more advanced implementation as #4456 would be ok to you, if this is the outcome?

2. highway=busway becomes more narrowly defined/confirmed as a BRT-style infrastructure (or whatever is the outcome of the discussion), with highway=* + bus/psv=yes/designated + access=no still being the preferred usage of other types of bus infrastructure. In this case, I think only a solution like #4456 is ok, but if this definition is supported by the mapping community and gets adopted on the map, there wouldn't be a barrier to implement it anymore?

As said already - we try to be agnostic as to where tagging develops. But past experience indicates that (2) is a very unlikely scenario on a global scale - the meaning of tagging almost never narrows substantially in scope once a tag has gained wider use.

Ok, valuable insight, and even more signifies that the discussion on the definition should be held (on OSM), as the scope widening is already ongoing.

At the moment the trend seems to go towards substantial regional differentiation, i.e. the de facto meaning of the tag significantly depends on where on the planet you look. See also #4226 (comment). This development IMO calls strongly for addressing #214 before or together with supporting highway=busway in some form.

To me, this rather seems an issue to solve on OSM first, as generally it is not intended for OSM tag usage to vary wildly per region. And I don't see why that would be calling for addressing #214 first, as solving it would not address different regional usage of tags. The way you frame the need for addressing #214 would in fact be to address a possible 'tagging for the renderer' issue you expect to happen. Something which currently also happens a lot in case of busways, even more strongly since the alternative is literally making it invisible on the map. A clearer and more widely supported definition what should and what shouldn't be tagged as busway would make these cases of tagging for the renderer better enforceable, so that concern can be taken away.

So to figure out next steps. Even if you're not the one encouraging it, would opening a discussion on OSM on the definition and implementation of the busway tag be able to pave a path forward in getting them rendered? This seems to be the first step to me that might need to be taken, so we better know what direction the rendering design should go, isn't it?

If the outcome is that almost everything should be tagged as busway, any rendering taking a future access marking implementation into account would then suffice. If the outcome is that both have clearly defined yet different meanings and should be used side by side, a new distinct busway rendering can be designed (still taking into account a future access marking overhaul), but then 'tagging for the renderer' shouldn't be a concern anymore, as that is just not allowed and the OSM community will be enforcing that. A future access marking overhaul could definitely help then, but I hope you understand the reasons why tying that together seems like a bad idea. And if the outcome is that regional variety is kept and supported, then we're back at square one, I think. But at least the two other outcomes could help going forward, isn't it?

[pnorman]

To me, this rather seems an issue to solve on OSM first, as generally it is not intended for OSM tag usage to vary wildly per region.

Yes - if there are issues with the tagging they need to be fixed in OSM before we add it to osm-carto. We never add features until they are established with a consistent definition.

Cartography chosen needs to work in all regions, so if regions are using it very differently we can't develop something that will work well everywhere. If such a cartography was possible I might be okay with it, but that part of the cartographic space is so crowded it's going to be hard enough to find something that works with one usage, let alone with both.

Even if you'd envison adding highway=busway before addressing #214 (other maintainers might be fine with that) you'd have to consider #214 when developing a design concept for the former

I'd be fine if someone came up with a busway rendering that fits with the current rendering of access restrictions. I think #214 makes this much more difficult but not impossible.

[GJDillen]

Just my 10 cents worth of comments on: “Cartography chosen needs to work in all regions, so if regions are using it very differently we can't develop something that will work well everywhere.”

What if diviations on the standardkey can be noted as country-ID: standardkey so the differences will then be applied for that country ? Then the standard is stil being mapped until there’s a governmental/country-region specific mapping rule difference being applied. E.g. highway = nl: busway This solution is already done for Wikipedia pages which are in a different language Wikipedia = nl: article resulting in displaying a dutch Wikipedia article…

Could this be an acceptable solution to solve the discussion?

edits being applied: either done to emphasise matters by using bold type or resolving plain typ-errors

[imagico]

Just a quick comment on the idea of regionally differentiating the style. This is a separate topic so if you want to discuss this in more depth please open a separate issue.

OSM-Carto has the aim to provide a map for a global audience with no special preference being given to the current de facto spatial distribution of either map users or mappers. This in our interpretation includes (a) as far as possible not regionally differentiating the style rules and (b) not interpreting tagging that is deliberately designed to be region specific.

For (a) we have essentially two exceptions: The Mercator projection itself - which is a variable scale projection, hence what the style shows at a specific scale depends on latitude. And the Antarctic ice sheet - which we render based on the established convention that all land south of -60 degrees latitude is ice covered unless mapped otherwise.

Point (b) does not mean that we do not render tags for features that exists primarily or exclusively in certain regions (think of things like coral reefs and glaciers but also places of worship of a certain regional religion) - or that we do not render tags that have not been used with global scope from the start. But it means that if a tagging is explicitly designed in a way that the same thing is meant to be tagged differently in different parts of the planet we are not going to support such tagging. This is part of our aim to support mappers in consistent mapping practice.

As said before - working on improving consensus among mappers regarding the use of tags is desirable, as is improving documentation of tagging practice. But inquiring here what hypothetical developments in tagging practice might lead to certain design decisions is not very productive. We will look at how mapping practice develops and will adjust our decisions accordingly. But we do not want to have any part in actively steering mappers - neither through our style changes nor through promises of future style changes based on hypothetical changes in tagging.

[Squizie3]

@pnorman

Yes - if there are issues with the tagging they need to be fixed in OSM before we add it to osm-carto. We never add features until they are established with a consistent definition.

Thanks for speaking clear language!

(...) but that part of the cartographic space is so crowded it's going to be hard enough to find something that works with one usage, let alone with both.

Could you elaborate a bit more about this? I don't entirely understand what you mean here.

@imagico

But it means that if a tagging is explicitly designed in a way that the same thing is meant to be tagged differently in different parts of the planet we are not going to support such tagging. This is part of our aim to support mappers in consistent mapping practice.

Same here, thanks for the clear language!

As said before - working on improving consensus among mappers regarding the use of tags is desirable, as is improving documentation of tagging practice.

Ok, in general we know what to do now.

But inquiring here what hypothetical developments in tagging practice might lead to certain design decisions is not very productive. We will look at how mapping practice develops and will adjust our decisions accordingly. But we do not want to have any part in actively steering mappers - neither through our style changes nor through promises of future style changes based on hypothetical changes in tagging.

I get that you don't want to steer that discussion in principle, because for you it is a different platform. But I completely disagree that this is not productive: if you were willing to answer those hypotheses instead, that would be productive, so please do. The current mapping practice is clearly not good enough to support rendering, it would be very helpful to know what would be instead. By not wanting to elaborate on that, we don't know what can help us go forward. Which sadly, seems to be the whole issue in this discussion, by not speaking clearly what concrete steps are needed for it to be supported, no one seems to see an outcome any more. I'm not asking you to pick which direction it needs to go, I'm just asking you a few hypothetical situations to know in advance what the outcome would likely be if that path were chosen. This would be really valuable information for a discussion on OSM, so we at least know what the implication of choices to be made will be. Maybe you don't see the point right now, but the more insight we have, the better and more productive the discussion on OSM can be held too. So could you please elaborate a bit more on the hypotheses I asked about in my previous post? I'm trying to break through this status quo that has been going on for years, but that can't be done by sticking to existing habits of staying unclear, because that clearly was even less productive. So please, can you elaborate on the hypotheses in my previous post?

[imagico]

Independent of my role as a maintainer here (in which my opinion how bus infrastructure should best be mapped is simply irrelevant) i personally simply have no qualified opinion on what tagging concepts are best for bus infrastructure. So even if i wanted to contribute to that discussion i don't feel qualified to do so.

As indicated already we try to support mappers in consistent mapping practice - no matter how that looks like. At the moment and from my point of view for bus specific road infrastructure this would primarily mean addressing #214.

As mappers you should work on consensus in tagging and documenting mapping practice in complete disregard of what map designers might or actually do communicate they desire. Having observed the development of tagging in OSM for more than a decade now i am convinced that the best recipe for a successful tagging scheme is to design it for the suitability for verifiable mapping and not for the perceived needs of data users.

I understand that for someone whose primary goal is to get a certain real world feature into the map this approach might seem convoluted and inefficient and the direct approach to negotiate the method of mapping with those in control of the map design seems attractive. But there are very good reasons why we do not take that route. That is why i said inquiries in that direction are not very productive.

And i reject the claim that i am not speaking clearly here - i have been very clear on what i consider the prerequisites of supporting an addition of highway=busway in this style. That these prerequisites are not a trivial todo-list to mechanically work through is something that comes with the territory of map design. But as i have indicated on many occasions - i would try to support anyone who is willing to work on steps to accomplish this (like #214) as much as i can.

[Squizie3]

Ok, I think I kind of understand. In the current implementation of the tag, you see #214 as a necessary step because otherwise you feel a rendering of busways will result in tagging for the renderer. But I don't understand why you don't understand that is already a big issue right now, just because it doesn't render. If I'm correctly, for example @pnorman did not see it as a prerequisite. Decoupling means faster solutions, perfect is the enemy of the good. Why can't a two step solution work, where first we get them rendered, and second the big access rendering update is rolled out? As long as the busway style takes this future addition into account, I don't see why it should be coupled. A bit of tagging for the renderer might still happen in the meantime, but less than what is currently the case because it doesn't yet render. You need to understand that because of the non-rendering, you're currently causing the polar opposite of the principle of encouraging correct mapping practices, and creating problems for OSM mappers by doing so. Which is why we need as soon of an implementation as possible. A good one, that can be perfected later on by solving #214 would be vastly more helpful to the mapping community than waiting years for a perfect solution. It is not that a solution for the busway problem rules out an implementation of that perfect solution later on.

But even if that's your hard stance and even regardless of the rendering issue, I agree it is best to have a discussion on OSM first to define the tag usage better so mapping practices can be aligned to it. A tagging scheme that is verifiable would indeed help a lot, both in mapping OSM itself, and in deciding on how to render it. Given a lot of the raised issues with implementing a rendering style seem to get stuck at regional variations and the possibility of getting 'tagging for the renderer', a broadly supported, verifiable definition and in turn adoption by OSM mappers would mitigate a lot of these concerns, am I correct? That way, depending on the outcome, getting it rendered might become a breeze.

[GJDillen]

My 10 cents clearly did not land well and/or was not understood very well. On my side there is no money left so I wil swallow the Carto imperfection (what ever season the base and/or root of the problem is) since there are many other maprender types which will support diviations… It is just a matter of not using Carto as standard map anymore what will solve the problem…

[imagico]

@Squizie3 - we all have different experiences in OpenStreetMap and as a result we see things differently. In the end all i can do to deal with that is to explain my view and the reasoning this is based on and listening to the reasoning others present for their views.

Regarding the influence not showing something in the map has on mappers - there is a qualitative difference between the influence of showing something (i.e. endorsing a certain way of mapping) and not showing something (i.e. not endorsing a certain way of mapping) and there is also (as already pointed out) a quantitative difference between the use of OpenStreetMap's system of differentiated mapping of access restrictions on roads and the implicit mapping of bus only restrictions via highway=busway.

@GJDillen - that is an approach i very much support. We need more diverse community map styles in OSM. And as counter-intuitive as this may sound - the OSM community being less dependent on OSM-Carto would actually be good for OSM-Carto.

But ultimately it all depends on the OSM community actually stepping up and developing more ambition in the design of maps. #214 has been open for more than 10 years now and other than my own demo i am not aware of any system of comprehensive visualization of access restrictions on roads in maps having been developed during that time. OTOH in the three years highway=busway has been around probably at least a dozen OSM map styles have started showing that in distinct form. If that is indicative of community map development over the next ten years it is not unlikely that we could see a complete fade-out of explicit access restriction mapping in favor of new primary highway tags defined by implicit access restrictions similar to how highway=busway is used in some areas now.

[Squizie3]

we all have different experiences in OpenStreetMap and as a result we see things differently. In the end all i can do to deal with that is to explain my view and the reasoning this is based on and listening to the reasoning others present for their views.

Ok, but I hope this is more than a discussion just to present viewpoints without doing something with it, and this also could serve to get to a solution... The discussion from past years has shown there's a lot of community feedback asking for a solution, and there were also a lot of people willing to put effort into it, but your answers manage people just to give up, instead of getting them to work on solutions. Being honest here, you should probably ask yourself why that is. If you want people to help improve, you will also need to be open for their input so we can work towards a solution. I'm being completely honest here, because I hope this might lead to some insights: you don't seem to be open to community feedback on this issue. You only seem to push your own priorities, which is the access restrictions overhaul, which for everyone else seems not necessarily tied together. That's how I and others who have contacted me by now perceive it currently. This might not be intentional and please don't see this as an insult, I'm just communicating the perceptions I and others get. I hope this is not intentional, and if you want, you can take steps to change that perception. Or if it was intentional, then not, but then please just say so. Then we at least know. Currently, I still want to work towards a solution, but you also need to be open for community feedback for that, or no solution is reachable ever. This could mean that you have to accept a good solution over a perfect one, for example. Please, take a step back and ask yourself, is it really needed to ty both issues together, or are there certain conditions under which it isn't any more and what are they? This way, we can work towards more simple goals in a step by step approach, that actually leads somewhere.

Regarding the influence not showing something in the map has on mappers - there is a qualitative difference between the influence of showing something (i.e. endorsing a certain way of mapping) and not showing something (i.e. not endorsing a certain way of mapping)

And I'm going to ask a brutally honest question here again: why do you think you have the legitimate power to decide for OSM users to not endorse mapping busways by not showing them?

But ultimately it all depends on the OSM community actually stepping up and developing more ambition in the design of maps. #214 has been open for more than 10 years now and other than my own demo i am not aware of any system of comprehensive visualization of access restrictions on roads in maps having been developed during that time. OTOH in the three years highway=busway has been around probably at least a dozen OSM map styles have started showing that in distinct form. If that is indicative of community map development over the next ten years it is not unlikely that we could see a complete fade-out of explicit access restriction mapping in favor of new primary highway tags defined by implicit access restrictions similar to how highway=busway is used in some areas now.

But why do you think people would be stepping up, if all they get is that they should strive for your personal perfect map style? You need to be open for feedback more, otherwise you're putting people off from investing time in it. You're always coming back to access restrictions rethinking, yet you seem to be alone in the vision that this should be tied together. All other major map styles have by now adopted highway=busway rendering, even in it's current form with ambiguous usage around the world. If this isn't a clear sign that this map style is getting out of touch with the community, then I don't know what will.

So I have now made a post that's a bit different than others, because I want you to know how this discussion is perceived. This is not meant as an attack on anyone, I just hope it can open some eyes. Sometimes this might be necessary to get out of a loop, which seems to be ongoing in this discussion for years now. I honestly hope you will read this in good faith and overthink it a bit, maybe even before reacting right away.

Apart from that, from the whole discussion, I conclude that whatever we do, the current ambiguous tagging practice leading to regional variation and tagging-for-the-renderer based on personal interpretation needs to be solved first. This discussion will need to be held on OSM, hopefully resulting in better, verifiable tagging practices on the OSM map, and thereby also clearing some of the roadblocks that prevent them being rendered.

[imagico]

While it is insightful to see how people perceive this project this has moved now almost completely outside the topic of this issue.

My impression is that you quite radically reject many of the basic premises of OSM-Carto - both the core values (some of which i have explained in previous comments) as well as the governance model (working through consensus among a diverse group of autonomous maintainers).

None of these premises is set in stone - you are welcome to discuss ideas for changes in those in a separate issue. But you will need to convince the maintainers with arguments and reasoning of the merit of the changes you suggest. And in contrast to design decisions where we have the practice of individual maintainers to try not to stand in the way of consensus building where possible (and i have stated this explicitly for this issue on multiple occasions) on governance matters broad consensus will be required.

However, my feeling is that your vision of community map design is so fundamentally different from what we try to do here in OSM-Carto that it might be advisable for you to consider initiating a separate project implementing that vision. You indicate you consider yourself speaking for a considerable group of people so there should be capacity to start something like that. I have made this suggestion before when people fundamentally oppose the ideas and values of OSM-Carto and like before i mean this seriously. Both OSM-Carto and the OSM community would profit a lot if there were other community projects with a global scope competing for providing a map for OpenStreetMap.

It is also possible though that your view is substantially shaped by incorrect assumptions made. You seem to base a lot of your ideas on assumptions regarding the motives and roles of people - assumptions that substantially contradict what has been said here. So it might be advisable for you to follow one of the oldest principles of OSM and assume good faith and take the explanations made on what motivates us to see things the way we do at face value and re-evaluate your reasoning under that premise.

Independent of that the matter of this issue remains - all maintainers (as far as they have voiced their opinion) are open to the possibility of rendering highway=busway. Design ideas for this, as well as for more differentiated rendering of access restrictions in general, or a combination of both, that accurately reflect mapping practice world wide, are welcome. As are pointers to changes in mapping practice if and when they happen.

[zekefarwell]

@Squizie3 and other frustrated busway rendering seekers, @imagico's suggestion to start a different (or contribute to another already existing) community map style project is a good one. It's well worth reading through this issue before deciding if this project is one you want put your energy into:

• 3951

[Squizie3]

While it is insightful to see how people perceive this project this has moved now almost completely outside the topic of this issue.

Yeah sorry for that, I'll try to get back on topic later this post! But I thought it might provide some insights. Maintaining a community driven project also involves people skills, apart from technical and design skills. So if something feels off, at least I think it could be valuable to let it be known, because one might not be aware of it.

My impression is that you quite radically reject many of the basic premises of OSM-Carto - both the core values (some of which i have explained in previous comments) as well as the governance model (working through consensus among a diverse group of autonomous maintainers).

Ok, then that's not entirely well communicated from my part, as in fact I don't question any of the core values itself. But I do have some issues with the implementation of it, yes. The governance model of working through consensus among a diverse group of autonomous maintainers is very good in principle. But the way it seems to be implemented here seems off: currently, you seem the only maintainer around here in this discussion that actively holds back the process by requesting #214 to be solved first. There's almost no interaction from other maintainers, and if there is, they don't even seem to support the same hard stance as yours. You have to understand, that from the communities' viewpoint, this doesn't feel very much as a consensus model, but rather a one man's vision. If a few other maintainers would step in and also figure out this was a hard requirement, ok, then it would feel more legitimate. But I don't see that consensus now.

However, my feeling is that your vision of community map design is so fundamentally different from what we try to do here in OSM-Carto that it might be advisable for you to consider initiating a separate project implementing that vision. You indicate you consider yourself speaking for a considerable group of people so there should be capacity to start something like that. I have made this suggestion before when people fundamentally oppose the ideas and values of OSM-Carto and like before i mean this seriously. Both OSM-Carto and the OSM community would profit a lot if there were other community projects with a global scope competing for providing a map for OpenStreetMap.

@Squizie3 and other frustrated busway rendering seekers, @imagico's suggestion to start a different (or contribute to another already existing) community map style project is a good one. It's well worth reading through this issue before deciding if this project is one you want put your energy into:

* [Consensus based decision making #3951](https://github.com/gravitystorm/openstreetmap-carto/issues/3951)

Sure, but you all know as well as me that there's a very big difference between being interested in map design, and maintaining a whole new map rendering. The former requires a completely different skill set than the latter. And you may have guessed, the vast majority of people in the OSM community who express their interest in e.g. rendering of busways are part of the former group.

It is also possible though that your view is substantially shaped by incorrect assumptions made. You seem to base a lot of your ideas on assumptions regarding the motives and roles of people - assumptions that substantially contradict what has been said here. So it might be advisable for you to follow one of the oldest principles of OSM and assume good faith and take the explanations made on what motivates us to see things the way we do at face value and re-evaluate your reasoning under that premise.

Ok, I'll take that one! I deliberately pushed it a bit because I was genuinely questioning the motives so I wanted to challenge that, so the contrary could be proven. I really do hope as you just stated, that this feeling was wrong, and I'll assume good faith.

Independent of that the matter of this issue remains - all maintainers (as far as they have voiced their opinion) are open to the possibility of rendering highway=busway. Design ideas for this, as well as for more differentiated rendering of access restrictions in general, or a combination of both, that accurately reflect mapping practice world wide, are welcome. As are pointers to changes in mapping practice if and when they happen.

Ok, to finally go back on topic. Could this stepped approach work:

Step 1: A discussion on OSM about the definition of highway=busway is to be held, as the current regional variations and open-to-personal-interpretation definition seems to be a barrier for rendering for multiple people (and is also just not in line with OSM's own stated goals). Either this leads to a confirmation of the current definition, or preferably leads to a more universal definition with better verifiability that in turn could solve the issue of personal interpretation and regional variability. Once that discussion has concluded it also needs adoption on the OSM map, which depending on the outcome might take a while.

Step 2: design work on one of the proposals needs to be resumed. If the outcome of step one is a well verifiable and well adopted definition of busways, a design that takes a future access marking overhaul into consideration may suffice. If the outcome is more or less a status quo, an access marking overhaul might be required first, if this is endorsed by multiple maintainers.

Does this seem a good approach? If so, we can finally starting to work on these steps and make meaningful steps towards a solution.

[imagico]

Since the matter of consensus based decision making has been put into the foreground i like to emphasize again that in contrast to many other matters in this style there is no lack of maintainer consensus on this issue. And even if there was disagreement on a concrete decision - i have stated many times now that from my side that would not stand in the way of merging a change implementing this and none of the other maintainers has indicated that this is a matter of fundamental importance for them either.

One of the reasons why many of the maintainers here have largely stopped participating in discussions is the demanding and disrespectful attitude that has become widespread among commenters here. Several current and former maintainers have made statements to that effect. In light of this trying to instrumentalize maintainers who have stayed silent in this discussion to allege a disagreement with my assessments is - to put it very mildly - not a very good idea.

Step 1: A discussion on OSM about the definition of highway=busway is to be held, as the current regional variations and open-to-personal-interpretation definition seems to be a barrier for rendering for multiple people (and is also just not in line with OSM's own stated goals). Either this leads to a confirmation of the current definition, or preferably leads to a more universal definition with better verifiability that in turn could solve the issue of personal interpretation and regional variability. Once that discussion has concluded it also needs adoption on the OSM map, which depending on the outcome might take a while.

Step 2: design work on one of the proposals needs to be resumed. If the outcome of step one is a well verifiable and well adopted definition of busways, a design that takes a future access marking overhaul into consideration may suffice. If the outcome is more or less a status quo, an access marking overhaul might be required first, if this is endorsed by multiple maintainers.

I'd advise against trying to follow a pre-defined checklist on matters of tagging development. Most mappers do not see it kindly if they are pushed around in pursuit of someone's pre-defined agenda. But as already said working on improving agreement among mapper on the use of tagging for bus-exclusive roads is a very good idea and would make it substantially easier to develop a suitable approach to rendering in maps - not only, but also here.

Like @pnorman i am not going to provide predictions on how i would view future design proposals for rendering such roads under changed conditions regarding the practical use of tags. As has been mentioned the conditions for this are challenging with the crowded design space in this style - but i also consider this to be doable in principle. And as i have pointed out several times already: There is nothing any of the maintainers here has against displaying bus exclusive roads if there is clear agreement among mappers on how to map those.

There are also things style developers can work on right now independent of bus exclusive road tagging that would make such work definitively easier - in particular the points the move to the flex backend and disentangling the use of blue and purple color in the style in #4901. The former would for example allow adjusting road rendering of roads based on route relation membership - which, as mentioned in https://github.com/gravitystorm/openstreetmap-carto/issues/4226#issuecomment-911479559, is one of the main ways of bus infrastructure mapping.

[Squizie3]

Since the matter of consensus based decision making has been put into the foreground i like to emphasize again that in contrast to many other matters in this style there is no lack of maintainer consensus on this issue. And even if there was disagreement on a concrete decision - i have stated many times now that from my side that would not stand in the way of merging a change implementing this and none of the other maintainers has indicated that this is a matter of fundamental importance for them either.

One of the reasons why many of the maintainers here have largely stopped participating in discussions is the demanding and disrespectful attitude that has become widespread among commenters here. Several current and former maintainers have made statements to that effect. In light of this trying to instrumentalize maintainers who have stayed silent in this discussion to allege a disagreement with my assessments is - to put it very mildly - not a very good idea.

Ok, I really thank you for this explanation, as it makes things clear. It is good to know that this in fact is something the others are also on broadly on board with, we can't know if it isn't mentioned and they don't say it themselves. My conclusion was drawn on this statement, which seems to imply a more relaxed stance on the access restriction issue:

I'd be fine if someone came up with a busway rendering that fits with the current rendering of access restrictions. I think https://github.com/gravitystorm/openstreetmap-carto/issues/214 makes this much more difficult but not impossible.

But apart from that, I conclude that in general there is consensus among maintainers, which is good to know. And if I've been too direct and perceived rude, my sincere apologies, because that's not how I want you to feel. This is an important and beautiful mapping renderer, which I think we all just want to see succeed. There's just a bit of an incongruence between the maintainers and wider community expectations, but I think we all acknowledge you guys do it with the best intentions, and probably with good reasons.

I'd advise against trying to follow a pre-defined checklist on matters of tagging development. Most mappers do not see it kindly if they are pushed around in pursuit of someone's pre-defined agenda. But as already said working on improving agreement among mapper on the use of tagging for bus-exclusive roads is a very good idea and would make it substantially easier to develop a suitable approach to rendering in maps - not only, but also here.

It's intended to know what actually can be done to move forward, nothing more, nothing less. A clear set of things that could be worked on was most likely the reason why no one was taking action for a while now. But it's good to know that there is clear consensus that improving the tagging practice would help moving forward. This can now be worked on.

Like @pnorman i am not going to provide predictions on how i would view future design proposals for rendering such roads under changed conditions regarding the practical use of tags. As has been mentioned the conditions for this are challenging with the crowded design space in this style - but i also consider this to be doable in principle. And as i have pointed out several times already: There is nothing any of the maintainers here has against displaying bus exclusive roads if there is clear agreement among mappers on how to map those.

Ok, I understand you don't want to anticipate on hypothetical outcomes in principle. No problem, we'll then just come back at it after possible developments in the tagging definitions and practices have taken place.

There are also things style developers can work on right now independent of bus exclusive road tagging that would make such work definitively easier - in particular the points the move to the flex backend and disentangling the use of blue and purple color in the style in #4901. The former would for example allow adjusting road rendering of roads based on route relation membership - which, as mentioned in #4226 (comment), is one of the main ways of bus infrastructure mapping.

Ok, good to know. If anyone can help out, please do so. Although, I'm personally not the right person to do so, I'm afraid.

General conclusion: time to work on the busway definition and mapping practices. After that, design work can be resumed based on the developments. Let's do it.

[IIVQ]

Great work Squizy3! Now for the follow-up: I saw you and others made some updates to https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dbusway&type=revision&diff=2680862&oldid=2599055 but is there any ongoing (community) discussion on the exact meaning and intended usage of highway=busway?

[eginhard]

Great work Squizy3! Now for the follow-up: I saw you and others made some updates to https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dbusway&type=revision&diff=2680862&oldid=2599055 but is there any ongoing (community) discussion on the exact meaning and intended usage of highway=busway?

The comment of the revision you shared points to this community thread: https://community.openstreetmap.org/t/highway-busway-on-non-brts/110578

[dan200]

This issue affects the non-guided sections of the Cambridgeshire Guided Busway, seen here: https://www.openstreetmap.org/way/464098914 (The guided sections are tagged highway=bus_guideway, and appear correctly)

Are we likely to see this implemented?

[tjur0]

I did some experimentation to render busways. I settled on normal width to indicate that it is not a service way, and modified the colour:

https://www.openstreetmap.org/#map=16/52.3810/5.2053

I also believe we should not be rendering any implicit access. As they can a do change.

[pnorman]

modified the colour:

I had to look at that a few times to realize that it was not a canal. This would be more obvious in most of the world, but makes me think the colors are too similar.

[dch0ph]

It would make sense to connect the colour with highway=bus_guideway, not least because they often join (as noted above):

https://www.openstreetmap.org/way/111495268#map=18/52.22907/0.15036

(The guideway stops where the the busway starts.)

The image shows the current problem with too many shades of blue (4 shown). Personally I don't care for the highway=bus_guideway rendering (and why is it in a different layer from roads/railways?), and it might be interesting to think about the two together.

[tjur0]

the colors are too similar.

Ok, ill see if it is possible to separate it more. I also attempted a more purple color however then it becomes the next color after the motorway color, and I thought that was confusing. But maybe it is better than being in the blue space.

With guided busway there would be a few options we could go. Some options could be to change the color to be the same as busway and leave the rest. Another option would be to render busway and guided_busway the same.

We could also render guided busway and busway the same but make the inner fill smaller to make the casing a bit wider, or do a hybrid highway/railway rendering.

Ill try some different options/colors to see what works.

[tjur0]

Would a lavender shade be a good option?

[HolgerJeromin]

quite heavy for a feature "no one" is allowed to use. access=no streets are dimmed and not highlighted since a many years.

[adamfranco]

quite heavy for a feature "no one" is allowed to use. access=no streets are dimmed and not highlighted since a many years.

Except that these are used by the general public heavily in a similar way to how the general public uses railroads. The material and construction of the surface is like a normal street, but the usage is more like light passenger rail, street cars, and trollies with regular public transit running on a defined infrastructure.

[tjur0]

@dan200

I have tested some diferent options on this location:

No change to guided busways:

Change the color to be the same:

Render busways and guided busways the same:

Render guided busways with narrower fill, resulting 2x casing width:

Render guided busways with more narrower fill, resulting 2.5x casing width:

Hybrid railway-highway rendering:

[pnorman]

I would be okay with rendering busways and guided busways the same. The current guided busway rendering is largely for historical reasons dating back to the start of the XML style. Of the options I find the same rendering or the hybrid railway-highway rendering the best.

The lavender shade looks too much like a border to me.

The pink color works in the sense that it's distinct from any other color on the style. It also is a shade I've never seen for transit features anywhere, which is not great. Is the transit blue too close to water? I haven't run the delta-E calculations but it might work.

[tjur0]

Is the transit blue too close to water?

I’m not sure to witch blue colour you are referring to. However I would say blue is problematic because of the many usages already.

And blue is used to indicate bicycle traffic. I think it would be best if we try to pick separate colours for different traffic types.

Do you have a suggestion of colours that you think would work best?

[Squizie3]

The pink color works in the sense that it's distinct from any other color on the style. It also is a shade I've never seen for transit features anywhere, which is not great. Is the transit blue too close to water? I haven't run the delta-E calculations but it might work.

I think the pink is a very good choice here as it is distinct, which is very rare to find. Just visually, the blue/green seems rather close to existing features as indeed water, bike lanes,... regardless of calculations. For the pink, I did not expect there to be any colour left that is distinct enough to not blend with backgrounds or to look too similar to existing features, and still not look as a continuation of the existing highway classification system (like purple would). I don't think not having seen it used for other transit features is an issue though. Transit is usually either displayed by their line colours or a base colour depending on the map style, but they vary wildly from map style to map style, if they are shown at all. With that additional requirement, there will simply be no colours on the colour wheel available that also do not blend with backgrounds or look to similar to existing features.

As for the styling options: I think the conclusion was that it needed to work with the existing access restriction implementation, so no rendering of implicit access restrictions indeed (as no other roadway types do that either currently). For the guided busway, it was clear in other threads that there was large support to redo that styling together with busways, as for the general public those de facto mean the same thing: a road for buses where you cannot drive with your personal vehicle. A rendering that is exactly that of normal busways would indeed work, although I like the idea of a small variation to set them apart for the viewer that wants more detailed information. The old styling (even with colour change) does not make any sense to me and gives the impression it is a sort of railway, which is further from the truth than it being a sort of busway, so it should follow that latter one's styling closely. I do like the narrower fill options a lot more than the 'railway dash' version though, for one specific reason: to me this looks like the access restriction for a closed road. And given the current access rendering scheme should also apply for the busways, you should probably test out a version with gray access markings as well (which would indicate the busway is closed entirely), and I am pretty sure that would clash resulting in a visually very ugly result. Could you try out a rendering with the access restrictions of the different options (not as default, but this should render when a tag "access=no" or "bus=no" is present, meaning busway closed)?

[geaquinto]

The pink color works in the sense that it's distinct from any other color on the style. It also is a shade I've never seen for transit features anywhere, which is not great. Is the transit blue too close to water? I haven't run the delta-E calculations but it might work.

I think the pink is a very good choice here as it is distinct, which is very rare to find. Just visually, the blue/green seems rather close to existing features as indeed water, bike lanes,... regardless of calculations. For the pink, I did not expect there to be any colour left that is distinct enough to not blend with backgrounds or to look too similar to existing features, and still not look as a continuation of the existing highway classification system (like purple would). I don't think not having seen it used for other transit features is an issue though. Transit is usually either displayed by their line colours or a base colour depending on the map style, but they vary wildly from map style to map style, if they are shown at all. With that additional requirement, there will simply be no colours on the colour wheel available that also do not blend with backgrounds or look to similar to existing features.

As for the styling options: I think the conclusion was that it needed to work with the existing access restriction implementation, so no rendering of implicit access restrictions indeed (as no other roadway types do that either currently). For the guided busway, it was clear in other threads that there was large support to redo that styling together with busways, as for the general public those de facto mean the same thing: a road for buses where you cannot drive with your personal vehicle. A rendering that is exactly that of normal busways would indeed work, although I like the idea of a small variation to set them apart for the viewer that wants more detailed information. The old styling (even with colour change) does not make any sense to me and gives the impression it is a sort of railway, which is further from the truth than it being a sort of busway, so it should follow that latter one's styling closely. I do like the narrower fill options a lot more than the 'railway dash' version though, for one specific reason: to me this looks like the access restriction for a closed road. And given the current access rendering scheme should also apply for the busways, you should probably test out a version with gray access markings as well (which would indicate the busway is closed entirely), and I am pretty sure that would clash resulting in a visually very ugly result. Could you try out a rendering with the access restrictions of the different options (not as default, but this should render when a tag "access=no" or "bus=no" is present, meaning busway closed)?

My two cents on the busway symbology, as being both a transport engineer specialised in public transport and a professional mapmaker myself (also, a long-time OSM contributor, right now mostly to the meta drama because of lack of time):

While I really liked the latest pink suggestion, I don't think it's necessary for it to have a whole new colour. It could be the same colour of a highway class on the higher side (such as the orange-ish highway=trunk, highway=primary etc.) but with a thinner width. That's because a busway is just a normal road with high priority for most people, including people who are not bus passengers (car drivers, pedestrians, cyclists etc.). Thus, it makes sense that its symbology should have a resemblance to a high priority road.

If I was to choose a specific symbology, it should have a highway=service width, as most people already use/think busways as an equivalent of service-tagged roads, but it could have a highway=trunk colour, as it can be ostentatiously segregated to the point of being hazards to pedestrians, but most times not as so as highway=motorway. Also in my opinion, its layer priority should be higher only to lower-class roads (highway=residential, service, unclassified etc.) but not to higher-class categories (tertiary, secondary, ... , you get it), so it can blend well with the environment when it's a dedicated lane by the median of an avenue -- but to be honest this last bit is driven by just aesthetics. The synergy with the access tag could work normally, just like any other class.

As for the meaning of a busway, as for any other highway, it is fuzzy. There is no way to have a full-fledged definition and most other classes don't have either (even motorways). What is being asked here, some kind of distinct and universal definition, is unreasonable because the definition of a road class is a wicked problem. Road classification for any class is as hard and diverse as it is for busways, because there are many different types of legislation worldwide (or utter lack of). I think classifying roads with the OSM scheme is an easy task only in the UK, because it is based on the British legal system. Nevertheless, one could still infer some loose definition of busways. It is indeed physically and legally the equivalent of highway=service + bus=designated + access=no, but institutionally and socially it can be something else (i.e. a functional infrastructure that is part of a larger system, for instance, the BRT system or the bus network). This optional "something else" was enough for most people to see a busway as a separate concept from other roads, and this is why the OSM community voted for it to be an official tag and actively mapped it in a relatively short period of time, and, most of all, this is why it's outrageous that it's not being rendered in the de facto standard OSM style just because some maintainer is sitting on pull requests. We shouldn't wait for a consensus stating that busways are a different class, the consensus is the OSM community vote.

I think what I said settles the argument of what busway is supposed to be (it doesn't mean anything, and never will, but at same time it does). But, if this is not enough, which is frustrating because I shouldn't be wasting my time on this, I suggest a makeshift solution: just render any highway-tagged way, even typos, with a generic line -- say the same symbology of a parking lot aisle or like golf=hole. After all, OpenStreetMap has street in its name and should have the street network fully rendered.

[dch0ph]

And given the current access rendering scheme should also apply for the busways, you should probably test out a version with gray access markings as well (which would indicate the busway is closed entirely), and I am pretty sure that would clash resulting in a visually very ugly result. Could you try out a rendering with the access restrictions of the different options (not as default, but this should render when a tag "access=no" or "bus=no" is present, meaning busway closed)?

I agree that it would make sense for the design to support an access=no restriction, and this is an argument for avoiding railway-style dashing. That said, there is a current exception: highway=pedestrian, which doesn't have access restriction marking.

Personally I like the 2.5 casing render for guided busway, as this suggests guides, but I wonder whether a guided busway should be narrower than a normal busway. This guided busway: is squeezed between a dual carriageway, and risks looking a mess if the width of the busway is increased dramatically.

Note that this example connects to the carriageways via short sections tagged highway=service, access=no, bus=designated, rather than highway=busway (just to complicate matters).

I assume that any PR would move guided busways into the main roads layer to avoid this effect:

?

[BertMule]

Yet another frustration of an object not being rendered.

I just replaced a service road by the appropriate busway. Just to find out it is not rendered at all. Even the wiki remarks it to be the case. And I found this issue, open since 2020.

Come on. Please?