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.

[kolgza]

Because none of the busways are distinguishable at zoom-level 13, I decided to include an additional photo of the West Busway at zoom-level 16. Unlike the East Busway and South Busway, this one does not run alongside any railways.

If you are having trouble finding it, look for the bus-stop icons.

[pnorman]

highway=service, access=no, and bus=designated

This combination of tags is also used for short service roads which bus only and doesn't let us distinguish them from busways.

I don't think we can do this until these features have a distinct tag in OSM and it has wide-spread usage.

[jeisenbe]

The tagging is currently being discussed on the mailing list (See this thread: https://lists.openstreetmap.org/pipermail/tagging/2020-October/055747.html).

There was a new draft proposal to use highway=busway (https://wiki.openstreetmap.org/wiki/Tag:highway=busway), and this led to the current tag service=busway being documented for the first time: https://wiki.openstreetmap.org/wiki/Tag:service%3Dbusway (thanks, @matkoniecz).

We could use service=busway to make a special rendering if this method of tagging achieved consensus, since it has been used for over 2200 ways (twice as many as highway=bus_guideway, which is already rendered and has a similar function), but the community needs to reach consensus first.

[jeisenbe]

I’m closing this for now because there is still no established way to tag these features. Once either service=busway or highway=busway (or some other tag) becomes established as the clear consensus of most mappers, we can reopen this issue.

@kolgza if you wish to help clarify the situation, consider using the Proposal process to get one of the tags discussed by the community.

[matkoniecz]

@pnorman

This combination of tags is also used for short service roads which bus only and doesn't let us distinguish them from busways.

Is it theoretical example? Or something actually happening?

Are there any service roads where access is restricted to buses, but are not busways?

Triggered by https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tag:highway%3Dbusway#service_roads_where_access_is_restricted_to_buses (answering at wiki would be likely preferable if possible)

[kolgza]

I believe that it would now be appropriate to reopen this issue.

[imagico]

Reopening to encourage a renewed discussion based on the concrete tag highway=busway if and how to render this.

Observations from my side:

• The tag seems to be almost exclusively used in the Americas (where it seems to be used with diligence) but not in Europe, Africa and Asia. Not sure if that is due to different tagging practice and different paradigms in public transport.
• The tag seems to lack a culture independent positive and verifiable definition, current definition seems to be tied to English/Spanish/Portuguese naming customs and beyond that use vague, non-verifiable terms ("high level of importance") as well as a negative definition (list of things that the tag is not to be used for). That might to some extent explain the previous point.
• The documentation of the tag also seems to be sparse in details how situations of road infrastructure shared between the busway and the public road system is to be handled (like at junctions etc.) That might be of significant importance for considering what would be a suitable method of rendering.

[kolgza]

• The tag seems to be almost exclusively used in the Americas (where it seems to be used with diligence) but not in Europe, Africa and Asia. Not sure if that is due to different tagging practice and different paradigms in public transport.

This was all my doing. It was incredibly ill-advised, and I'm currently working to revert some of the more-careless changesets I've submitted. I must sincerely apologize.

• The tag seems to lack a culture independent positive and verifiable definition, current definition seems to be tied to English/Spanish/Portuguese naming customs and beyond that use vague, non-verifiable terms ("high level of importance") as well as a negative definition (list of things that the tag is not to be used for). That might to some extent explain the previous point.

• The documentation of the tag also seems to be sparse in details how situations of road infrastructure shared between the busway and the public road system is to be handled (like at junctions etc.) That might be of significant importance for considering what would be a suitable method of rendering.

I should have finished migrating all the information from the proposal page to the Wiki page before declaring my work in that aspect to be finished.

[jleedev]

Here's a mockup based upon the highway=service+access=private rendering, with colored dashes instead of gray:

It could do with being wider and appearing at a lower zoom level, but it gets the point across. The existing highway=bus_guideway is more railway-like, and busway ought to look like a road.

[kolgza]

Here's a mockup I made based on what @jleedev did, but using the colors from the rendering of highway=bus_guideway.

[ZeLonewolf]

It seems to me that busways are more similar to roads and bus guideways are more similar to train tracks. Thus I would expect bus guideways to render in the "railway" family and busways to render in the "highway" family.

[ftrebien]

@ZeLonewolf That's what I think too.

In addition, the electric blue of bus guideways can be confused with water by the users of the map. One may consider purple, violet or magenta instead. Perhaps purple can be a good choice in combination with landuse=railway or any future landuse=* value for rail-like systems such as bus guideways and BRTs.

[nighto]

IMHO it could render as something, at the first moment even the same as highway=service, because as highway=busway is not rendered at all, many users (myself included) would not be compelled to make the change, and changing all BRT systems worldwide from highway=service (plus other tags such as access=no + bus=designated etc.) to highway=busway would right now make them become invisible and therefore could even be perceived as vandalism. So it's a little bit of a chicken-and-egg problem.

An interesting discussion is going on over the tag's talk page.

[jdhoek]

highway=busway now exceeds 1000 uses and it is an approved proposal. Is there a minimum amount of tagged instances that would make this eligible for rendering?

Would it be possible to render them at least the same as highway=service with access=no and bus=designated in the interim until a definitive style has been developed?

On the Dutch forum the Catch-22 nature of supporting this new tag has popped up as well. If there is a clear minimum number of tagged instances to work towards, mappers can more easily decide if using it is acceptable with rendering forthcoming, or that it would mean years of having a gap on the map.

[A67-A67]

A busway under construction, highway=construction construction=busway, also seems to lack rendering.

Example

[andrepoiy]

Is there any progress here? I'm reluctant to convert the busways in my area to a new tag, and some of the ones that were converted by another user were reverted since they thought it was vandalism. Why must something have "widespread usage" before it is rendered? It seems to me that it should be the opposite; that you render it immediately (and also add a preset on iD), so users would have the knowledge that such a tag exists, and therefore have an incentive to actually map it.

[A67-A67]

Currently this tag has over 4200 uses. The tag highway=bus_guideway, that has been used for comparison in this issue, only has 900. I don't really understand how many uses we need until this approved tag will be rendered.

It really lowers the quality of this map and therefore the Openstreetmap website, when really prominent features like this busway are rendered as an empty space.

I also see people changing busways to highway=service, because highway=busway doesn't render in OSM Carto. Therefore idea that this tag wouldn't be accepted is actually a circle reasoning. Some people don't accept it, because this issue isn't solved.

[andrepoiy]

I completely agree with the above. I find it very sad that there has been pretty much no activity with regards to this issue since April.

[IIVQ]

The same. A widely used tag is not being rendered. Other renderers, such as OSMand, already support this tag and render it.

[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:

• Consensus based decision making #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 #4226 (comment), 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 #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?

[ftrebien]

Considering the high and increasing number highway=busway compared to service=bus and highway=bus_guideway, it would make more sense to render highway=busway using the style of highway=bus_guideway and stop rendering highway=bus_guideway or render both with same style.

[felagund]

https://www.openstreetmap.org/way/550918947 https://www.openstreetmap.org/way/665050603 https://www.openstreetmap.org/way/887580855 https://www.openstreetmap.org/way/568682767 https://www.openstreetmap.org/way/280027618 https://www.openstreetmap.org/way/463630676 https://www.openstreetmap.org/way/392511405 https://www.openstreetmap.org/way/912392738 https://www.openstreetmap.org/way/69986916

This is not a very dominant use of the tag as is but it is clear that there is a lot of confusion among mappers in those parts of the world where there is no 1:1 equivalent to the English language concept of BRT (and probably even in English speaking countries where public transport planners have not adopted this concept directly but varied it - there are all kinds of express bus routes all over the world and if they use - for part of their route - bus only roads, does that qualify them as highway=busway?).

For anybody trying to make sense of of the disagreement: The links above with disputed usage in countries outside of the Netherlands were at some point fixed (by different people) to follow the wiki (the cases in Spain and Poland were I think in agreement with the wiki). One could then assume the only country diverging from the wiki is the Netherlands; however that is not the case. (maybe they were changed because they were linked from here?) I looked at about 15 random uses of the tag on all continents: https://overpass-turbo.eu/s/1Rt2 and only one or two were not falling under the first three rows of the table here: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbusway#Similar_infrastructure

Now I have no stake in the argument whether or how highway=busway should be rendered, I just wanted to point out that @imagico is right the discrepancy exists. And at least in northern Spain (overpass would not support bigger query), highway=service, access=no, bus=yes is a lot more common then highway=busway.

[syntex1]

I would like to point out that currently according to TagInfo the tag highway=bus_guideway TagInfo highway=bus_guideway has only 660 uses worldwide (Is this one of the least popular rendered tags?), while highway=busway TagInfo higway=busway has 25 316.

[mvl22]

European example:

https://www.openstreetmap.org/#map=17/51.458850/0.224512&layers=CN

I was extremely surprised to see that a basic bus-only road is not rendered.

The same issue affects OpenCycleMap, incidentally.
https://www.openstreetmap.org/#map=17/51.458850/0.223171&layers=CN
Very oddly, its cycleway on a network does have the network outline shown in red but not the infrastructure itself.

[dch0ph]

Merging of #5057 has reduced most of the technical obstacles to implementing a holistic design to highway=busway and highway=bus_guideway (there is general agreement that the bus_guideway rendering needs replacing as it resembles a railway).

It would also be worth thinking about rendering bus exclusive roads at the same time. A suitable rendering has previously been demonstrated here. This would "just" require a suitable colour to be shown instead of the normal "access grey".

Addressing both issues would reduce the risk of biasing tagging between highway=busway vs. highway=service + access=no + bus=yes. This risk of biasing tagging has been a significant complicating factor.

[Squizie3]

I see some interesting developments! Does that mean the technical issues that arose to render highway=busway in the correct Z order are now pre-emptively fixed? Are there any other really technical issues left, or is it just finding a good rendering style and finding consensus on actually rendering it now that's left?

On that last note, I have some interesting statistic from overpass (takes a while to run). Until now, everyone looked at the number of tag uses. But in fact, length is actually more important as that's what users see on the map. Turns out, the total length of unrendered highway=busway on the map almost matches the total length of highway=service + access=no + bus/psv=yes/designated by now:

Tag	Count	Length
highway=service + access=no + bus/psv=yes/designated	67 104	5582 km
highway=busway	27 153	5060 km
highway=bus_guideway	654	252 km

Something to keep track of, which really makes it clear why some kind of rendering is needed. The total number of tag uses is an under-representation of the issue. Also, the longer average length probably signifies the tags are used on longer stretches of bus exclusive roads instead of short slip lanes and what not, which is exactly what this tag was meant for. I see no reason to not implement a rendering style any more, as long as it is coherent with the map style.

[dch0ph]

Does that mean the technical issues that arose to render highway=busway in the correct Z order are now pre-emptively fixed?

Yes. This had been planned for some while, as part of moving to flex osm2pgsql import, which will require a database reload, and so is a good time to add pre-emptively a slot in the z-ordering for highway=busway.

But moving highway=bus_guideway into the roads layers was also a pre-condition to an effective solution.

Are there any other really technical issues left, or is it just finding a good rendering style and finding consensus on actually rendering it now that's left?

I don't believe there are any substantive technical issues left. That said, achieving consensus on design will require some determination / persistence.

Also, the longer average length probably signifies the tags are used on longer stretches of bus exclusive roads instead of short slip lanes and what not, which is exactly what this tag was meant for.

Thanks for the interesting stats. There's a nice example of that here:

Where a "bus-only slip lane" leads into a bus_guideway. This is a good illustration of why a coherent design is needed. The current rendering is confusing.