Highway=busway on non-BRTs

[willkmis]

@ZeLonewolf

I think that’s a fair question, and it’s also fair to ask what exactly is wrong with the Dutch approach beyond the fact that it disagrees with the wiki.

Totally! I tend to agree with what @ezekielf said above, that these short roads fit the meaning of highway=service quite well: they are for local access to a specific single location, or to bypass a single road. In other words, they’re essentially driveways for buses, whereas a longer, BRT-style busway is for long-haul through (bus) traffic, sort of more like a highway=trunk (well, certainly something higher than service) for them.

Moreover, I think that busways are a whole separate class of infrastructure from these and other service roads. My understanding of the whole reason the tag was invented is that a BRT-style, long bus line is typically a significant piece of infrastructure that is an important part of the transit network and thus the local landscape in its area, which necessitates a specialized tagging (and yes, perhaps even a specialized, fairly prominent rendering). This difference is not sufficiently captured as a service road with special attributes. In some ways a BRT is more like a rail line than a road. Certainly a BRT-like busway is quite similar to a bus guideway, which does have its own highway tag; if I were starting a tagging scheme from scratch, guideway would probably be a subclass of highway=busway. I then think applying the ‘any road only a bus is allowed to use’ definition lessens the importance/prominence that tagging a ‘real’ busway implies in the places where it makes up a key part of the transit infrastructure (for example, in my city, Los Angeles, they call the BRTs Metro lines, and they’re shown virtually the same on the Metro map as the rail lines).

I get the counter-argument that it’s hard to exactly define a line where one becomes the other, but I do think that the difference between a BRT and a short offramp that serves one stop is important enough to try to make a distinction. But I’m open to being convinced that an ‘any bus road’ approach works better, either conceptually or practically!

[ZeLonewolf (Brian M Sperlongano)]

@willkmis

I’m open to being convinced that an ‘any bus road’ approach works better, either conceptually or practically!

Works better to do… exactly what?

I think a clearly-stated data consumer or cartographic argument is needed here to demonstrate the specific problem associated with one or the other approach. I think that maybe you are trying to say something like “displaying minor bus-only service roads as BRT on a map would give wrong information to a user.”

And let’s not confuse things by bringing up bus guideways, those are completely different physical infrastructure.

[Willem1]

I think there is a difference between countries at play here, that would be interesting to explore.

The Dutch equivalent of BRT would be what’s called HOV (Hoogwaardig Openbaar Vervoer = “high-quality public transport”, confusingly not this!). The Dutch Wikipedia on HOV notes:

As rail-based HOV is often called lightrail instead, HOV is gradually taking on the meaning of high-quality bus transport.

My city (Eindhoven) has a HOV network, with several bus lines. These lines have separate infrastructure, and not all bus lines run over the HOV network. I believe this is similar to a BRT and would 100% fall under any reasonable definition of highway=busway.

However, the HOV lines all start at a large bus stop near the train station; this is the same bus stop that also the “normal” bus lines use. So this is where the confusion starts to me. If we are to distinguish between highway=service for “normal” bus lines, and highway=busway for HOV here, then which parts of the bus stop get mapped with which?

Another issue I see: Dutch infrastructure is highly regulated and standardized across the country. This means that the infrastructure for a bus stop will look quite identical, no matter if it’s HOV or a “normal” bus. So let’s say some city council decides that a “normal” bus needs a bus stop with a bus bay like the one mentioned above, then it will just look like this, whatever the type. I looked at the aerial pictures at this location, and from these I have no idea if this is supposed to be HOV or not. This makes the distinction quite unclear; I guess I’d have to take into account which buses stop there.

---

On the other hand, I do also get your point that it is useful to reserve the highway=busway tag for large-scale systems, to avoid cluttering a map of bus systems with minor bus bays and such. I see a possible alternative that I think would achieve that, but not suffer from the same problems: we could put a BRT-specific tag on the route relation that describes the bus line. (Maybe something like type=route; route=bus_rapid_transit?) I see two main advantages:

• If a stretch of BRT infrastructure happens to be used also by “normal” buses, then we can still accurately mark which of these bus lines belong to the BRT and which ones don’t.
• If a BRT bus uses a “normal” road for a short stretch (like here), we could still mark that piece of “normal” road as part of the BRT, and a transport-oriented map could still mark the BRT line as one uninterrupted whole, even if it doesn’t go over a highway=busway.

[ManuelB701 (Manuel B.)]

Personal semi-off-topic opinion here: I “dislike” BRTs and part of that is the distinctions between regular busses which are mixed-traffic only and “special” busses which must only exist on their own lanes which sometimes make sense if the busses depend on the BRT infra (e.g. if high-floor busses are used which require high platforms for step-free access) but often times doesn’t and your post highlights my issue with it.

@Willem1

However, the HOV lines all start at a large bus stop near the train station; this is the same bus stop that also the “normal” bus lines use. So this is where the confusion starts to me. If we are to distinguish between highway=service for “normal” bus lines, and highway=busway for HOV here, then which parts of the bus stop get mapped with which?

IMO I’d tag them as highway=service regardless on which system is using them under the basis that bus bay and terminal ways are similar to the ways of a parking lot, though it’s also a matter of pedestrian access (i.e. the more limited the pedestrian access is, the more I tend towards highway=busway), though at that point, it becomes fairly subjective and one should simply chose what’s the most fitting option here.

@Willem1

On the other hand, I do also get your point that it is useful to reserve the highway=busway tag for large-scale systems, to avoid cluttering a map of bus systems with minor bus bays and such. I see a possible alternative that I think would achieve that, but not suffer from the same problems: we could put a BRT-specific tag on the route relation that describes the bus line. (Maybe something like type=route; route=bus_rapid_transit?)

That’s what makes sense to me as well. I’ve sometimes thought (particularly after reading the Wiki of highway=busway) that denoting BRTs is much better by relation than by infrastructure, especially because they don’t always involve bus-only carriageways (in that they sometimes drive over bus-only lanes) and conversely, a busway isn’t always used by a system which (intentionally) tries to be a BRT.
It’s similar to the distinctions of some railway lines suchas between a route=tramway and a route=light_rail which may share tracks like in Karlsruhe: It’s famous for its tram-trains and the general consensus for mapping its tramway routes is route=tram for any regular tramway (i.e. the trams only drive over way=tram) and route=light_rail for a tram-train line (i.e. if trams also drive over railway=rail).

[willkmis]

@ZeLonewolf

I think a clearly-stated data consumer or cartographic argument is needed here to demonstrate the specific problem associated with one or the other approach. I think that maybe you are trying to say something like “displaying minor bus-only service roads as BRT on a map would give wrong information to a user.”

Yeah, pretty much. To take three concrete examples in my local area for illustration: Los Angeles’s aforementioned Metro G line runs on an exclusive right of way for 18 miles/29 km and is currently tagged highway=busway. Meanwhile, a short bus-only road exits Wilshire Boulevard (highway=primary) for about 150 m to serve the bus stop for a hospital. It is tagged highway=service + access=no + bus=yes. Lastly, the terminal loop at the Culver City Transit Center is a bus terminal at a mall, accessed by the buses via the mall service roads. It is tagged highway=service + service=driveway + access=no + bus=yes + psv=yes.

The G line busway is an important piece of physical infrastructure in the city, both for the large number of people navigating to the busway itself, and for general wayfinding. A general purpose renderer might thus choose to display it prominently. This is what OSM Americana does: highway=busway renders at z11, the same place tertiary roads start rendering (the G line busway is the purple east-west road with a curve in the middle of the screenshot). You could imagine different renderers choosing different starting points depending on how much they wanted to emphasize transit vs the road network, but I think this is pretty appropriate for a BRT-style busway. (And, by the way, I brought up bus guideways in part because some renderers, like Americana, render them the same, and I think they are roughly the same functionally to the typical end user, even if the infrastructure is different)

Meanwhile, OSM Americana doesn’t render service roads until z15, and I would guess most renderers render service roads at much higher zoom than other roads. In the old scheme, where busways were tagged as service roads, that meant it was difficult to render them prominently without complex processing. But if the short service roads are tagged as busways, you get the opposite effect: these tiny stubs render very prominently, showing up at low zoom. This is despite them being quite minor in the perspective of the observable built environment, not much different than a driveway. In the Culver City Transit Center case, the bus loop would show up 4 zoom levels before the service roads that lead to it! You can see this in other places where the bus station access roads are in fact tagged as highway=busway, see Helmond, NL (OSM, Americana):

That funny purple blob is the bus bay roads, which render before the roads accessing them as well as the railway station they serve! I think this is misleading/confusing for a user, visually unappealing, and doesn’t reflect the real-world differences between these types of roads. It would be more sensible, IMO, to render these bus bays nearly identically to the public service roads and driveways they are quite similar to, in form, function, and importance.

In the Wilshire Blvd case, it would be less of a problem, since Wilshire will render prominently. But you could imagine a scenario where, say, you choose to render busways equal to highway=secondary, and a bus stop access road branches off a tertiary or residential, to give you the same rendering island artifact.

I’m using Americana as an example merely because it’s a renderer I’m familiar with that renders busways, but the problem is general: IMO it is desirable to be able to render longer-distance busways prominently without also rendering minor driveways to bus bays prominently, which can only be done through distinct tagging.

It’s also a problem if you want to track this sort of infrastructure: how do you query which cities have these sort of BRT dedicated rights-of-way if your search is muddled by the tiny service roads? But I think the rendering/processing problem is more salient.

Hopefully these examples illustrate why I think the ‘only long-distance dedicated rights-of-way are highway=busway’ approach is better than a ‘any way exclusively for buses’ from a tag usefulness standpoint.

Aside: note that the problem of how to map the busways themselves is separate from rendering the bus route that follows it: while I agree with some of the posters above that it’s currently hard to distinguish between routes that are BRT-esque and routes that are not for a transport rendering, it’s not really the same as how to render the infrastructure.

[willkmis]

@Willem1

My city (Eindhoven) has a HOV network, with several bus lines. These lines have separate infrastructure, and not all bus lines run over the HOV network. I believe this is similar to a BRT and would 100% fall under any reasonable definition of highway=busway.

However, the HOV lines all start at a large bus stop near the train station; this is the same bus stop that also the “normal” bus lines use. So this is where the confusion starts to me. If we are to distinguish between highway=service for “normal” bus lines, and highway=busway for HOV here, then which parts of the bus stop get mapped with which?

I agree that this is a somewhat ambiguous situation. I think I would lean toward how we tag roads: if the road is for through traffic, you would tag it highway=tertiary or greater, but if it were only to access one adjacent location (or like said above, the ways in a parking lot), you would tag it highway=service. So I would lean toward tagging the roads to the bus station as highway=busway but the driveways to the individual bays and bus break areas as highway=service. To me it’s not really about the route that a carriageway carries, but whether the way is for through traffic or direct local access.

[A67-A67]

@Willem1

However, the HOV lines all start at a large bus stop near the train station; this is the same bus stop that also the “normal” bus lines use. So this is where the confusion starts to me. If we are to distinguish between highway=service for “normal” bus lines, and highway=busway for HOV here, then which parts of the bus stop get mapped with which?

I’d say they are all busways. A service road is a road to a minor location, while this is the central node in the busway network.

When you compare it to a railway station, the rail also splits towards different platforms. All tracks will then be tagged similar as railway lines between cities. Tags like service=siding and service=spur are used for minor tracks, like highway=service on roads.

Therefore I’d only tag roads with bus traffic that are actually going off the main network, like to a depot, as highway=service. When they are part of the bus network, they cannot be a highway=service IMHO.

[ezekielf (Zeke Farwell)]

Lets all remember that the reason for the highway=busway proposal was to allow for better classification of bus only roads. Previously all bus only roads were tagged highway=service + access=no + bus=designated. This made sense for what @willkmis is calling bus driveways, but highway=service wasn’t feeling like an appropriate classification for bus thoroughfares. For general pupose roads we have a number of different classifications^[1], but we were lumping all bus roads into just one classification at the bottom end of the function/importance spectrum. The reason for busway to exist as a higher level of classification is the same as why we have higher classifications for general purpose roads. It allows renderers to show relevant subsets of the road network at various differrent zoom levels. Only the most important classification levels are shown at low zoom, and then lower classed roads are progressively added as you zoom in until all roads are shown.

If highway=busway is to be used for all bus roads regardless of function or importance, then the situation will not have changed from when we were using highway=service + access=no + bus=designated. The result of the past few years of highway=busway development will just be that bus roads can now be specified with one tag instead of three. A new subkey could be developed to distinguish different kinds of bus roads, but that would just be a repeat of what highway=busway was intended to do. If we stick to the original intent of the proposal, but expand the meaning of highway=busway to include other types of bus thoroughfares besides BRT roads, then we’ll have two classifcation levels to use. service for bus service roads (bus driveways, bus bays, etc), and busway for bus throroughfares (BRT or otherwise).

@Willem1

I’m actually not so sure what to do with these very short segments like this one you posted above . I currently gravitate towards applying highway=busway for them too, just because if you don’t, it becomes hard to draw the line.

Where to draw the line is a general difficulty with highway classification. Which roads exactly should be tertiary vs secondary comes with some level of subjectivity and guidelines developed by the local community in each area of the world. Short road segments serving bus stops and stations off more major thoroughfares seem similar to rest areas (service areas) on motorways which are tagged highway=service (example). It seems reasonable to me that similar bus service roads would use the same highway classification, just with different access tags.

---

1. motorway, trunk, primary, secondary, tertiary, unclassified, residential, service ↩︎

[Tjuro (Mart)]

For bus depots i think that highway=service is fine, but for platforms i think that highway=busway makes more sense. For example at this location the busway flows into the platforms and the road next to the platform is wide enough for busses to pass other busses.

https://www.openstreetmap.org/#map=19/52.50517/6.08927

[ManuelB701 (Manuel B.)]

The way the station is built allows busses not only to depart but also to pass through and some of them (like Bus 641) indeed do this. On top of that, it looks like the access of the platforms is restricted for non-busses (including pedestrians) and you have to enter the platforms like the railway platforms of the nearby railway station through a subway. The bus bay part of these is implied (i.e. not-rendered) due to being part of the same carriageway, though they could be tagged with bus_bay=*, of course.

To get to the analogy of A67-A67 with railways: Bus bays are equivalent to passing loops with a side platform (as common on high-speed lines) and these passing loops, despite being of a significance for passengers, are nonetheless mapped as service=siding which is equivalent to a highway=service which is why it’s appropriate to map them as such and leave highway=busway for the actual throughfares.

In contrast, the bus platforms of Eindhoven Centraal Station (see Willem1’s post) lack a throughfare function and thus is more appropriate to tag it as highway=service outside of the main throughfare in my eyes. That being said, I won’t bat an eye on this if it stays highway=busway, I’m more opposed to tagging bus bays of a simple stop as highway=busway.
Can’t comment on the access as a pedestrian, though.

[A67-A67]

The tag is highway=busway, not highway=brt. So I think the tag can also be used to tag other busways than BRT corridors. There was also a need to have a good tag for busways in general, just as cycleway and footway exist. The past three years have shown highway=busway has filled this gap. The workaround tagging of highway=service with varying access-tagging (bus/psv=yes/designated) has been made obsolete.

If there is a need to clarify the difference between types of busway, a subtag can be useful. For example:

• highway=busway, busway=brt: BRT corridor
• highway=busway, busway=station: busways in a station
• etc.

[Squizie3]

Hi, wanted to join in here. First of all, hope y’all had a good popcorn watching the Carto Github discussion, as some mentioned. So given that, I think I probably need to explain a little on my stance here.

As I see it, there are two problems regarding the busways. One is the lack of rendering on the main map style, that makes correct usage of the tag unjustly discouraged. A second one is the current definition of busways on the OSM wiki, that doesn’t seem to match current usage all that well, and feels too restrictive and sometimes even arbitrary to me. I see both as equally important to solve, and in fact, the logical step to me seemed to first get “something” rendered, and once that’s cleared, get a discussion on OSM about the usage of the tag itself. So I tried to get involved in the rendering discussion, that seemed to have stalled without any solution in sight. Well, turned out someone there isn’t really that cooperative even if I tried to break it down into smaller solvable steps. But what I did notice was that quite a lot of the arguments given by multiple people came down to a lack of consistency in the tag usage. Which could possibly be solved by re-evaluating the meaning of the current busway tag itself on OSM, something that I already saw as the other important issue with the busway tag. So instead of getting it rendered and then opening a discussion on tag usage, doing it the other way around might kill two birds with one stone, possibly. And as people must have noticed that discussion, they already opened the discussion here, which is great and shows there’s a good reason to do so.

Before I go into the details of the tag usage itself, I feel it is important to mention: I saw this as an issue before opening the discussion on the carto rendering, so this is NOT an attempt to please a single person that happens to have the power to block rendering the busways. I do agree that is not a good reason to change anything on OSM. But there are legitimate reasons why I’d wanted to see a discussion happen on the busway tag itself, so the need to have this discussion seems to align by chance.

So as I see it, there are multiple issues with the current definition and usage of the busway tag on OSM. Almost all of them come down to verifiability and consistency. Some are more important than others.

The most major one is the BRT-requirement according to the wiki.
For one, part of the justification of why a separate tag was needed, was that busways are in fact not at all service roads. Well, this is also true for non-BRT-busways just as well. And indeed, basically all explanations on the wiki page are true for normal busways as well, apart from the first three sentences that specifically talk about BRT. And yes, even the tag itself points to it being valid for all busways, otherwise it should have been highway=brt or something similar.
Second, there’s the fact that BRT isn’t a universal concept around the world. It doesn’t literally translate into a lot of languages, for example the French “BHNS - bus à haut niveau de service” and Dutch “HOV - hoogwaardig openbaar vervoer” translate to “high quality bus service”, not necessarily “bus rapid transit”. That difference matters, as the requirements to qualify as BHNS/HOV are usually quite a bit lower than what is widely regarded as BRT. But that doesn’t mean they aren’t worthy of being on the map in the same way as BRT, as they do serve a very similar purpose in their respective cities’ public perception and are almost equally as visible on the ground. But even then, say you could include regional variations/translations of BRT to the tag definition, this still doesn’t solve the issue, it just moves the cut-off point a bit further. The BRT requirement, even if expanded a little, just lacks a good verifiable and around-the-world-usable definition. Some systems might not meet the criteria but might call themselves so, other systems might not call themselves anything special but might make use of infrastructure that very much resembles actual BRT-busways. Sometimes there might even be very high quality busways that meet everything except they just have almost no service run on them, and hence aren’t BRT or anything else.
Which is actually the real issue: we’re trying to define physical infrastructure by the services that are run on it. But those services, that’s where route relations are for. Instead, we need to go back to the basic principles on OSM. What’s verifiable? What’s physically on the ground? If you do the duck test, it is clear that the amount and quality of services aren’t the thing that defines a busway. Instead, it is, wait for it… a “bus way”, in other words “a way for buses”. If this concept is applied, everything becomes much more verifiable and consistent, regardless of language, country, required service levels etc. A BRT-busway really doesn’t differ all that much from a BHNS-busway or a normal serparated busway: they all are physically separated bus roadways that can carry tons or just a few buses an hour. The main difference between normal busways and BRT-like busways isn’t in the busway itself, it’s in the services and possibly the bus stop/station amenities, but all of those are mapped with different features. But the lanes do look exactly the same, and thus following the verifiability principle “map what’s on the ground” really implies that is the correct way of defining this tag. This way, all those significantly visible bus right of ways in countries that don’t necessarily have a habit of installing true BRT will also be included, which doesn’t even compromise the original idea to highlight BRT infrastructure, it just widens it so it can be used more equally around the world. Which it already does in certain countries, but without getting acknowledged on the wiki.

I do have some other smaller points I’d like to discuss (some of the exceptions listed in Similar infrastructure which have already partly been in discussion here), but given this is already a lengthy post, I’ll leave them for a little later. For now, I’d like to hear, do you agree on the basic principle to go for a better verifiable definition that simply maps what’s actually on the ground, thus ditching the BRT requirement and just requiring it to be a separate road exclusively for buses? On the wiki, this basically just requires rewriting the first three sentences.

[Minh_Nguyen (Minh Nguyễn)]

@Squizie3

Which is actually the real issue: we’re trying to define physical infrastructure by the services that are run on it.

What I’ve heard so far in this discussion is about infrastructure designed to be used exclusively by a particular kind of service or vehicle. This isn’t such a novel concept when we consider other highway values such as bus_guideway, cycleway, and raceway, and indeed most of the railway values.

@Squizie3

The BRT requirement, even if expanded a little, just lacks a good verifiable and around-the-world-usable definition.

Have proponents of a definition limited to more substantial thoroughfares really belabored the point that a busway needs to be served by a line formally classified as BRT? That hasn’t been my impression; let’s be careful not to introduce strawman arguments into this discussion.

@Squizie3

On the wiki, this basically just requires rewriting the first three sentences.

Yes, if the wiki page is causing confusion by leading off with this definition, then perhaps the end of the first section can be moved to the top. But I don’t think this is the root cause of any disagreement among the mappers here.

[Squizie3]

@Minh_Nguyen

What I’ve heard so far in this discussion is about infrastructure designed to be used exclusively by a particular kind of service or vehicle. This isn’t such a novel concept when we consider other highway values such as bus_guideway, cycleway, and raceway, and indeed most of the railway values.

Uhm, yes I agree, but you didn’t get the point that these roads are designed for buses, not necessarily BRT. Both a busway for BRT and for just normal buses look basically the exact same. A verifiable way to tag busways, would indeed be the exact same as it is for cycleways, railways etc, namely, if it is designed for buses, then it’s a busway. Instead of “it is designed for this particular service of buses”, which opens up a whole can of worms of which bus service qualifies and which doesn’t, all while the physical infrastructure is exactly the same.

@Minh_Nguyen

Have proponents of a definition limited to more substantial thoroughfares really belabored the point that a busway needs to be served by a line formally classified as BRT? That hasn’t been my impression; let’s be careful not to introduce strawman arguments into this discussion.

Uhm, no? I did not react to anyone in fact, I just joined the discussion, and I’m reacting to the current state of the wiki page which in fact really does state it should be BRT. I merely presented my arguments on that specific change I’d like to see, with arguments that might not have been made yet.

@Minh_Nguyen

Yes, if the wiki page is causing confusion by leading off with this definition, then perhaps the end of the first section can be moved to the top. But I don’t think this is the root cause of any disagreement among the mappers here.

Well, making such change can only happen if people agree here, and I just put in my reasons why I think this change needs to happen. As did others before me in the same discussion. What makes you think I’m trying to go against what people said before? I just provide some extra arguments, I think you should read my post again but not see it as a reaction against people in this discussion, but as a reaction in favour of clarifying and broadening the definition that’s currently on the wiki page.
And I did go back to this part of the discussion on the BRT requirement because I feel this is the most fundamental change, going back to the basics of good tagging practice on OSM. I would like to see clear support of that, so we know this change can be made, because this can’t be made lightly. Just because it seems there isn’t that much disagreement on that front isn’t enough, there has to be a clear GO for that change to be made and I haven’t seen that yet. Which is why I’m asking for verification that everyone also sees it that way.

[Minh_Nguyen (Minh Nguyễn)]

@Squizie3

I just provide some extra arguments, I think you should read my post again but not see it as a reaction against people in this discussion, but as a reaction in favour of clarifying and broadening the definition that’s currently on the wiki page.

OK, that’s fair. I also hit Reply too soon on accident and had to rush to make my response a bit less pointed, hehe.

@Squizie3

I’m reacting to the current state of the wiki page which in fact really does state it should be BRT.

I guess I don’t see how it explicitly requires that, but I do see how it would leave someone with that impression. Leading off with a definition of BRT, as if it’s a one-for-one match with the tag, is problematic. But I think it is a useful point of reference for distinguishing the tag from the concept of bus=designated more generally.

[Tjuro (Mart)]

Busways in the Netherlands are mostly mapped based on the signage like sign F13:

This is inline with other types of highway classifications that have a sign accompanying them like cycleways, living streets and trunk roads.

There are situations where a road without a specific sign would be classified as highway=service.
However because one of these indicating signs is present the service road gets classified as the specific type.

A while back we had the same situation with service roads that also are living streets. This kind of double possibilities leads to situations where mappers can’t agree on a classification.

With living streets the solution was to add living_street=yes to the service road. A similar solution could be implemented here with highway=service+busway=yes.

However I am starting to think that highway=service is flawed. And that it might be a better solution to come up with a subtab to specify the type of road hierarchy/access type.

[Kovoschiz]

“BRT” is an arbitrary branding. It’s not consistent around the world (I’m tempted to say unverifiable). The “BRT” in one location may be a simple “busway” , articulated bus route, or even standard bus service in another.
To add to the aforementioned European examples, Nagoya has a center-running “trunk bus” (already different from eg Korea) that’s only a weekday rush hour bus-only lane, and bus priority lane in other times. (“BRT” in Japan are mostly not anywhere “BRT”, another misnomer as “LRT” picked up to refer to “modern” buses and trams)
Actual individual physical characteristics should be used instead. Then anyone can choose their definition or level of BRT. Grade-separation, center-running or birectional one-side-running, signal priority, all doors, off-board payment, gatelined paid area station, etc.
Instead of “BRT”, “main” bus services can be identified. That’s more important for the transit functionality. This relates again to the fact that the standard of a “BRT” somewhere can be ordinary buses elsewhere.
busway=station is ambigious as to whether it is for all bus stations, or stations on busways. I don’t agree with expanding =busway to other stations and bus stops.

[emvee]

Following what @Kovoschiz wrote I had a look at List of bus rapid transit systems and learned there is a BRT Standard and bus rapid transit systems can be scored using this BRT standard.

That said I think the term “BRT” should be largely removed from the definition of highway=busway, it is too limiting and thereby causing confusion.

Most, or at least not all, busways are not BRT’s or “BRT certified” but on the other hand, BRT’s are always busways.

[Kovoschiz]

For that matter, busway=yes won’t be enough. That’s an unspecified positive overlapping with old busway=lane for the widespread bus:lanes= now. It’s not impossible to have a bus lane on an ordinary =service used by general traffic.

[Minh_Nguyen (Minh Nguyễn)]

@Tjuro

Busways in the Netherlands are mostly mapped based on the signage like sign F13:

This is inline with other types of highway classifications that have a sign accompanying them like cycleways, living streets and trunk roads.

If I were mapping in a region that posts these straightforward-looking signs, I’d certainly be tempted to map them one-for-one with highway values to the extent possible. With a task as nebulous as highway classification, anything objective like a sign sure makes mappers’ lives easier compared to subjective criteria like “BRT” in quotation marks.

That said, I’m not sure the signs are always the best approach given the available tags and the need for interoperability across regions. There have been plenty of debates between mappers in neighboring countries about whether the mandatory sign with a bicycle on it should be highway=cycleway or bicycle_road=yes or cyclestreet=yes. motorroad=yes basically encodes the mandatory sign with a car on it, but unfortunately the varying regional legal implications limit that tag’s uptake in software.

@emvee

That said I think the term “BRT” should be largely removed from the definition of highway=busway, it is too limiting and thereby causing confusion.

I agree that BRT shouldn’t be part of the definition of this tag. Mentioning it in a section somewhere lower on the page can still be useful for mappers from localities and regions that have BRT, but if this tag is to be used more broadly, then a definition decoupled from BRT would be more useful. The article already has a definition decoupled from BRT, further down, but perhaps the language isn’t as clear and direct as it should be:

The tag highway=busway should be applied to carriageways that maintain a high level of importance specifically for bus passengers , but are not meant to be used by motorists, pedestrians, or cyclists. In other words, this tag should only apply to roadways used for passenger transport.