After reading through all replies I want to say thank you for the fruitful discussion. I see some disagreement, and maybe it is too big to reach the 75% mark to reach a consensus. But maybe it is not.
I think the frequency of a bus line can be mapped with interval.
What does not — to my knowledge — have a tagging in OSM is the speed of the vehicles (buses)**. I dont mean maxspeed, but average speed including (scheduled) stops, stops at traffic signals and stops/slower movement due to other traffic (mainly cars).
If regular stops are short (few seconds) and traffic lights and (car) traffic do not slow down, then the bus has a special quality which I would like to be able to map.
I am not sure, how this quality shall be named. Maybe the native speakers can help. My ideas are
undisturbed_vehicle_flow=yes
independent_vehicle_flow=yes
stopping_only_at_bus_stops=yes
no_stopping_between_bus_stops=yes
**Bus only ways or lanes give a hint about it, but I know many buses with such lanes still being slow because they wait at red lights all the time. On the other hand, when a street has almost no car traffic, or car traffic is kept out of the buses’ way through intelligent traffic signals, a bus only way is not needed at some places to reach the quality.
Which might be wishful thinking is even possible. My hypothesis is there is too many tags for road for cars and not enough of paths for people.
You are misunderstanding. The goal is not to recreate what MBTA did because MBTA did it. The goal is to be able to create a map where BRT/important/better quality buslines are highlighted. The choice by MBTA is probably not arbitrary but seeks to convey some information based on some characteristcs of the bus lines in question. However, this is just one example. There are many other cities, also outside of USA, which use (proper) BRTs where it is even less arbitrary.
The goal is to allow people using OSM data to make their own choices how to display something. But they cannot when it is not tagged.
Because that list is not really up-to date (assessment is done once, and most scores are ten-year old now).
They published the 2024 standard already. The scores are being updated. But what’s the problem? At least you know it’s up to some standard. For new systems, I suppose they will still be added quickly?
As what’s mentioned by @Minh_Nguyen , I have asked about one possibility above, for whether it is advertised as “BRT”. You said no.
What I think is the meaning needs to be clearly indicated and distinguished. Advertised claim that it’s “BRT”, our own internal assessment of the overall physical standard, an external third-party standard, or the trunk functionality. brt= appears vague, and prone to misunderstanding or mistakes.
You can already divide the length of highway= roads without roles in the route= (or start adding more distance= ), by the official duration= , to obtain the schedule speed. That’s the average speed used as the standard of comparison. It could be further improved, eg if different times are published for peak vs non-peak.
Traffic volume is usually considered out-scope. Progression through signal is not exactly the same as absolute or relative bus priority signals. Buses could travel somewhat smoothly through signals by considering how it needs to make stops, if the corridor is coordinated properly, has suitable progression speed, and uses short enough cycle length.
For what can be done, among what exists elsewhere, personally I don’t like traffic_signals=*_priority . At least according to Key:traffic_signals - OpenStreetMap Wiki , we can’t distinguish whether the priority signal is normal-off, =blink_mode , or always-on standard 3-lamp traffic lights with bus actuation. This also collides with =pedestrian_crossing for mid-block crosswalks, for related issues . I wonder whether transit signals without priority would be mistakenly tagged as them too.
Anyway for the topic here, traffic_signals= isn’t nice to be used on route=bus either. For both route=bus and highway=traffic_signals , I might suggest eg traffic_signals:priority= , by expanding upon priority= . Then simply traffic_signals:priority==yes , =no , =main , =partial , =limited , etc, can be used on the route=bus . However, absolute and relative signal priority is best further distinguished.
out of 136 rankins, only twelve were done in the last seven years.
Some people have expressed reservations and I assumed it would be a non-starter. Personally I could live with brt_standard=gold/silver/bronze/brtcertified. I am not sure what the legal situation is - can it be used like that even?
If I remember cirrectly, multiple people expressed doubts that everything that is self-called BRT is a BRT - I share that concern.
That would sound the best way for me but as you can see,it gets a lot of pushback. I understand the meaning needs to be clear, but I do not see any consensus of what a meaningful meaning would be :-(.
Yes, that is true. I’m afraid those data would be quite misleading, because a rural bus route will almost all the time be faster than an urban one (longer distances between stops, higher maxspeed). Routes partly in urban / partly in rural environments will show an average mean value which does represent neither of those two.
The idea behind my suggested key is “is this bus route fast (or better: the fastest possible) in regard of its route and environment”? And this one is far more difficult to calculate. I dont even know if it could be calculated at all.
@Kovoschiz what do you think of my suggested keys? Apart from the wording (feedback also welcome), is it something you could go with?
Not sure why you answer here, but you might have misunderstood what I wrote. That thread is about a further differentiation of highway=path. There is a fundamental difference to the classifications you mentioned. The separation of highway=primary down to highway=service is mainly about the relative importance. For sure this is fuzzy. The idea mentioned in the linked thread is not about introducing no additional level of importance. A hiking trail is in general not more or less important than a mtb track or a bridleway or a sidewalk. That depends completely on the user.
I don’t categorically oppose it. BRT is a real concept, for better or worse. I figure that we basically have two viable options:
Record the fact that the route self-identifies as BRT. Embrace a relativistic definition of BRT: whatever they call BRT locally.
Don’t model BRT per se, but give data consumers the tools to guess that it might be BRT or an equivalent generic “trunk” network.
These solutions optimize for different use cases, hence my original question to you about your goals. But I don’t really see us being able to establish our own definition of BRT and stick to it.
Heh, signal priority is the very first thing my city watered down about its BRT line after it launched.
Speaking of intelligent signal systems, the MUTCD pages have a big question mark on the sign for a green wave. The following sign doesn’t indicate a speed limit; rather, it indicates that the signals are timed for a certain speed, incentivizing you to drive under the speed limit to benefit from that optimization.
This was similar to what I was thinking, and I don’t think recording one or the other is mutually exclusive.
bus:branding=BRT, BRT:advertised=yes or similar to describe if the route is called BRT by the transit agency
grade:ITDP=gold/silver/bronze/basic/no to denote the grade according to BRT standard.
In addition, I agree we should improve our tagging of other bus infrastructure. (I don’t belive there is a scheme to record a bus traffic light like this for example)
The closest analogue that comes to mind is LEED certification, which has occasionally been tagged as leed=*leed:versionleed:typeleed:start_date. However, I’m pretty sure the only reason for that usage is that mappers noticed LEED plaques during surveys.
Data consumers who actually care about that information can probably get a lot more coverage by looking up the linked Wikidata item’s has certification (P10611) property. I’m sure Wikidata would be open to a proposal for a new property about the ITDP scores and a bulk edit to tag them comprehensively.
Do we consider it a trolleybus or a bus, a BRT or not a BRT? It greatly depends on the section of the line. Tagging should imho, consider these edge cases, and maybe assigning a whole line the definition of BRT is more controversial than it seems (how much % of segregated infrastructure do we consider for it to be classified as brt=yes?).
In addition to mapping the advertising / branding, and the official grade from the ITDP, I also think it’s totally fine to come up with a new tag to indicate the “BRT-ness quality” of the bus service. This could IMHO be done perfectly well using the five criteria that @supsup has formulated in the proposal:
Faster than personal cars travelling alongside during rush hour
Frequent service (context dependent, but definitely in minutes)
Dedicated infrastructure (bus only ways)
No payment ticket to the driver (off-board payment or selfpayment in multiple machines of the bus)
Preference at intersections (no car traffic can block buses by turning left in countries driving on the right and vice versa, preferential green signalling)
Of course there will be disagreements when a service is an edge case, but these kind of discussions are really unavoidable in OSM. It’s still good to have this extra tag, which can be updated by the local mappers much faster than apparently the official list of the ITDP.
There’s no harm done if there are explicit tags on route relations which allow quick understanding of the “BRTness” or “express-ness” or “service importance” quality. It may be possible to get the same classification, or even a more exact one, by using information like route length and numbers of stops and duration etc. But this will need quite a bit of calculations, so why shouldn’t we offer a “shortcut” that’s just good enough for interested data consumers?
I have no strong opinion on what the actual key / tags should be. backbone=no might look like an insult to some brt is short and sweet, but needs explanation. How about rapid_transit=*? This could be used for other things than buses, too, if that’s ever needed.
I don’t think we need to reinvent the wheel. A mapper is free to use the ITDP’s BRT Scorecard and store that value somewhere (maybe OSM or Wikidata with a qualifier) if a system is not graded yet.
I half agree, and half disagree. First of all it should be asked, what is meant by using the ITDP BRT standard?
The ITDP Scorecard includes much more than the bus system itself. There are scores for subjective appeal, the sociopolitical implication, and the whole transit system.
Stations and Buses (23 points maximum)
Pavement Quality (2 points)
Customer-friendly Stations (3 points)
Greening Measures and Resiliency (1 point)
Access and Integration (16 points maximum)
Integration with Other Public Transport (2 points)
Pedestrian Access and Safety (4 points)
Secure Bicycle Parking (1 point)
Bicycle Lanes (2 points)
Bikeshare Integration (1 point)
Personal Security and Gender-based Violence (3 points)
To help explain the delay in rating, " Certifying a BRT corridor as Gold, Silver, Bronze, or Basic sets an internationally recognized standard for the current best practices for BRT and can only be done with the full score (Design + Operational Deductions) six months after opening to allow usage and operations to be more representative of longer-term patterns.". Again, they include unverifiable parameters inappropriate for OSM.
Operational deductions (-77 total): *Point deductions are assessed for corridors already in operation. Proper maintenance and quality operations are critical to attracting and retaining riders. They are as important as the design, but easier to change and improve. These metrics are designed to discourage significant planning, management, or operational errors that are not readily observable during the design phase.
Poorly Maintained Infrastructure (-14 points)
Overcrowding (-10 points)
Lack of Enforcement of Right-of-Way (-7 points)
Bus Bunching / Reliability (-6 points)
Buses Running Parallel to BRT Corridor (-4 points)
Low Peak Passengers (-3 points)
Pedestrians and Cyclist Fatalities along Corridor (-2 points)
0: curb-aligned busway on a two-way road (right-hand kerb-side bus lanes get zero)
Off-board Fare Collection
4: “onboard fare validation—all doors” (compared to “selfpayment in multiple machines of the bus”)
0: Other inferior;
Platform-level Boarding
Intersection treatments
0: “< 20% of turns prohibited across busway”
0: “< 30% of intersections have signal priority”
Basic BRT: a minimum of 20 points total from all elements in the BRT Basics category (maximum 35 points)
The proposer’s definition would only guarantee at most 8pts (4 if not all-doors boarding and paying), less than half required to pass. It needs 12 more points, which can only be achieved by a combination
5 level-boarding + 7 intersection treatment
>80% of turns prohibited across the busway
% of buses or stations where horizontal gap is always 10 cm or less through the use of fixed position device (e.g. electronic guidance system, physical guidance system, alignment channels, etc.)"
7 level-boarding + 5 intersection treatment
60~70%
gap always zero through use of boarding bridge or other such device (platform gap fillers? basically impractical in most for many reasons)
It’s quite a standard. Will exclude much of the proposer’s definition.
Be off-topic
As you said dual-mode trolleybuses, I have a question that if we still need the tag route=trolleybus?
All of trolleybus around here only use small parts of trolleybus wire. even 80% parts of route has no trolleybus wire. Some of trolleybus can also be used in other common bus route with no any wire on road. I think there is no difference between EV-buses and dual-mode trolleybuses (It’s just one more way to charge.).
I think route=trolleybus should be merged into route=bus one day.
