I rewrote the proposal significantly based on this feedback: Proposal:Mark bus lines that form the backbone of a public transport in a city with backbone=yes/limited/no - OpenStreetMap Wiki
Can I ask @ManuelB701 @Kovoschiz @Nielkrokodil @Minh_Nguyen @ZeLonewolf to look at it ifyou think it is a move in a good direction?
Aha, and there I thought atrolleybus need to run on electricity and have sticks on its roof feeding from electrical wires above. :-).
Still donât understand whether it should be about function , or physical standards. =limited would only apply to physical standards. Functions should be a val somehow (unfortunately difficult to choose as eg importance= has different use) , and there are many words to consider =backbone , =main , =spine , =trunk , =arterial (note the term âarterialâ has been used for some Not-BRT systems), etc.
I feel like BRT is too much of a marketing term. It can be hard to translate to other systems. For example in the Netherlands we call higher standard bus routes HOV.
edit:
I see you changed it to backbone=yes/no/limited
Sounds like a better term to me.
This big rewrite surprises me. I dont think the old version had many problems. I think apart from the consensus, that a simple yes/no is not enough there were no clear objections which created a need for this rewrite.
I think the title is now misleading. This proposal wants to highlight high performance bus routes (brt and similar). These routes are of high importance, but also a route only going once a day could be of high importance (where it is the only public transport an people dont have cars).
I dont like the key âbackboneâ. My first idea about backbone is a human body part. Also it refers to the context of other bones (regular bus routes) but those are almost not to be considered for tagging.
Itâs not clear to me why we need tagging to express the âimportanceâ of bus routes, or how one might determine, on the ground, which bus routes are more important than others.
Perhaps a clearly-stated statement of the problem would help.
@ZeLonewolf Did you read the rewritten wiki? I included screenshots. Is that not clear? Well, a system like BRT is quite visible on the ground. I would for example expect local public transport maps to highlight them.
@Nielkrokodil It seems to me my initial approach has been met with a lot of resistance, especially to use âBRTâ as either a key or value, so I changed it (even if I personally think it would have been fine). I renamed the proposal again. I am not particular about backbone, would arterial=* be better? Transporation is full of bodily metaphoresâŠ
Function, but you cannot really separate it from physical standards, they enable the function (without separate infrastructure, the function is impossible). =limited is only about function, not physical standards,actually. Am I to understand you want more than three values for the scale? What should be the key? Frankly I find your post a bit difficult to parse.
I have read the rewrite, but perhaps you glossed over my comments. There is no clear, bright line that distinguishes a âBRTâ bus line from an âordinaryâ bus line. Itâs all shades of gray, and to some extent, a marketing term. I gave a specific example above to point out why this is a hard problem.
I was reacting to this. Is that rationale in the wiki unclear?
As for the Boston line, I think it would be either limited or no from reading wikipedia, hard to say without ever having been to Boston. Wikipedia suggests the sore points (like paying to the driver) are being addressed over time.
However, the current OSM view shows all buses in the same style. When you compare it to a map provided by the organization running Boston public transit, you can see they distinguish between different bus lines (not even showing some of them here). The OSM rendering shows some buslines thicker, but that os only because they use a roads separated by a narrow park so they get rendered in both directions, misleadingly suggesting greater importance.
I read you as saying:
Distinguishing bus lines according to importance is meaningless.I disagree with that as per above. Do you insist that the goal I tried to express is nonsense?
Distinguishing bus lines according to importance is impossible. I understand that better, though I also disagree with that. You seem to suggest that even more values instead of two (or three) would not help and instead would like to just map details. That would however made the goal as per 1) impossible to implement.
Edit:
I proposed a checklist of five properties, with two being especially important. Why is that unworkable? From what I understand, it is an accepted fact that anything in OSM is a bit fuzzy when it comes to classification.
If the goal is to produce network maps, like the one shown on the right, that is already possible by proper network tagging and/or the use of wikidata links.
I think if youâre inventing heuristics to categorize things, then thatâs something that just doesnât belong in OSM and we should stick to the on-the-ground reality.
For example: the Silver Line is a bus line that partially routes over bus-only roads and is part of the MBTA system. That is all mappable with no need to invent new categories.
So, just to make it clear, you also oppose things like sac_scale horse_scale etc.?
How? Key:network - OpenStreetMap Wiki only sets the organization running the route and item for the silverline is here: Silver Line - Wikidata
How would you produce a workable transit map out of that???
Another thing, what harm would there be from this tag? People who find it useful could use it, but as it is on a relation, ti does not really bring new entities into OSM. Ingeneral I understand caution when adding new primary tags but with secondary ones, what is really the harm?
I think the problem is, that different bus lines are different important, depending on who you ask. It could be
This list could go on endless. Importance is so unclear it should not be used as it will (and already does) lead to confusion.
sac_scale comes from an established outside standard, itâs not one invented by an OSM mapper, as is proposed here. I oppose inventing unnatural classifications for geographic features unless it can be established that there is a problem that cannot be solved by tagging the featureâs extant reality.
You could traverse the wikidata properties to draw the routes that are part of the MBTA system. Many OSM-based systems (including ones I develop) feature a blend of OSM and wikidata in order to compose maps or applications that display particular subsets of data that people care about.
Also, if someone wishes to make a truly bespoke transit map, thatâs a rendering problem and not a tagging one.
None, and you and anyone else are free to use it. However, I will oppose efforts to formalize new tagging that doesnât describe a single objective reality. In other words, two mappers must be able to look at the same real-world feature and draw the same conclusion about how to tag it. If it doesnât meet that standard, it doesnât belong in OSM. In my humble opinion, this proposal doesnât meet that standard, either in the original formulation or in this one.
So you would be ok with a brt=gold/silver/bronze/brt_certified as that is an outside standard?
I personally would not shy away from theproposal being closer to BRTs, but it seemed to me there was a lot of opposition to it (including from you).
Rendering and tagging is intertwinned. You can only render what is tagged (or you can also rendersomething where you pull the data from elsewhere). How again could you make a map with OSM and wikidata that would show BRTâs or other backbone busroutes more prominently?
I would be fine with using a tag to indicate some kind of outside standard or certification. It should probably not be such a generic key in that case, instead it should be a key that references the standards organization in some way. In those cases, you are simply tagging the fact of some organizationâs categorization and not inventing your own. Also, standards organizations change over time, so the key space would need to have the flexibility to evolve with that.
Backbone is a term that youâve invented here. So, I dispute the premise that itâs OSMâs job to install tagging in order that someone might replicate a bespoke map. Ultimately transit agencies make maps that suit their goals as an organization. The fact that the MBTA has chosen to draw their silver and purple lines in certain ways does not mean that OSM needs to have tagging that matches the way the MBTA draws maps.
OSM is about documenting objective reality in geodata so that data consumers can make their own judgements and inferences about how to use that data.
I think the suggestion is to tag each individual route with its own unique ref=* and wikidata=* tags. There seems to be a concerted effort in some countries to ensure that every route=train has a corresponding Wikidata item, even in cases where Wikipedia doesnât consider the route notable. A bespoke renderer, like the Cincinnati Transit Map I linked earlier, could implement custom heuristics or hard-coded lists of Wikidata QIDs or route numbers. A broader-scale map that covers many networks might need to generalize about these routes to minimize the number of distinct colors or line weights. But that generalization may differ from map to map based on its use case and audience.
If the tagâs definition ends up being based on the subjective judgment of the mapper, then there is a risk of edit wars and endless, fruitless discussions. We already see plenty of that with highway classification and place classification discussions, at least in countries where these classifications arenât strictly tied to an official system. On the other hand, if we outsource the classifications to an authority or third party, we take responsibility to keep the data in sync and accept the occasional nonsensical classification.
I am just pointing out that those two statements are contradictory.
It is not about replicating their design but the meaning. Clearly not all bus routes are created equal.
I think you are making a conceptual mistake byt insisting only discrete little things can be mapped, but holistic higher level classifications cannot. BRT is a thing, it exists on a scale. Like a lot of things in OSM (I invented backbone because there was opposition to useing brt).
Frankly that does not sound scalable at all. I would like a general renderer to have a decent public transport display without having to use a per city customization.
That is what checklists and definitions are for. The world is not discrete (ignoring quantum physics), it is continuous, and as OSM is a mirror of the world, it will necessarily reflect this continuity with grey areas. It seems to me it works just fine (as this continuum is widespread in OSM anyway).
But anyway, I give up, I do not think there can be a solution given the very opposing views expressed here. Which is a pity as BRTs is something that clearly exists (so it has very easy ground verifiability).
Itâs a classic tradeoff between scalability and some notion of precision. It sounds like your idea of a âdecentâ presentation relies on the user being able to make certain inferences about the serviceâs operation based on a certain line treatment. I think this is still possible as long as the map communicates a certain fuzziness to the user.
When I developed a legend for OSM Americana, I had to come up with a label for expressway=yes. Expressway is an infamously poorly defined term, yet transportation maps conventionally distinguish it as a separate class on the legend, with a curt explanation of what to expect as a motorist. Thatâs what we did too:
| Tag | Label |
|---|---|
highway=motorway |
Freeway (controlled access, divided) |
expressway=yes |
Expressway (limited access, divided) |
Not every stretch of freeway has fully controlled access and not every stretch is divided. Not every stretch of expressway has limited access and many are undivided. We tag highway=motorway and expressway=yes based on weighing various factors that require a long wiki page to explain. Yet Americana includes these curt generalizations, figuring that theyâre good enough for most users. This is only possible because the tagsâ definitions are not arbitrary decisions by a mapping committee, but rather a distillation of common traffic engineering definitions.
So I donât think subjectivity or inconsistency is fatal to your idea. It just means we need to manage expectations about consistency and decide how much leeway to give mappers.
Itâs up to you, but I donât think this is totally hopeless. We could embrace the lack of objectivity and just tag whether the operator identifies the route as BRT. A global renderer may not be able to make a confident statement about the specific reasons why a particular route is highlighted more prominently, but it will be consistent with other map depictions of that route.
Dunno, using the key BRT or just taking over a classification from an external organization is opposed by about half of the people in the thread (namely @Kovoschiz, I would say you here, @ZeLonewolf here and also @Tjuro).
I see it that there are two classes of opinions:
The groups to me seem roughly even in size and incompatible.
Also there is not much concrete proposals how to make some sort of tagging this easier (that arenot overengineerd in my eyes - and anywya those are very scetchy too). And there is even no agreement there is a problem to be solved (which to me seems obvious, but it is far from it in general).
Oh, please, not again that argument âthere arenât bright lines how to categorize so we shouldnât attempt to categorize at allâ.
We heavily rely on heuristics and mappersâ judgment how to categorize tertiary vs. unclassified vs. residential vs. service in areas where no legal signage exists. The system works, the world did not collapse, and I havenât seen any major edit wars in recategorizing those.
Edit wars on highway classification are, unfortunately, painful and frequent. You can ask the Australian community about this. In the #highway-classification channel on OSM US Slack, there are frequent discussions about and reverts of unilateral highway classifications. If you arenât seeing edit wars on highway classifications, you simply havenât been paying attention.
Unfortunately, the classification of highways is a core necessity until someone might come up with a workable heuristic for rule-based low-zoom maps of the road network.
Where I reject the premise, is the idea that there must be a tagging scheme that allows someone to recreate, for example, the MBTAâs subway map:
In creating this map, MBTA made an arbitrary choice in promoting the Silver Line busses to the same cartographic treatment that subway lines receive on the cityâs subway map. I reject the idea that just because someone made a map that highlighted certain elements more strongly that this is evidence of a special category of importance.
Indeed, on that same agencyâs list of bus routes, we see that the Silver Line busses are listed right alongside every other bus line.
Here is a bus transit map from a nearby area. On this map, the parts of the network with more frequent service are thicker and other routes are thinner. In this map of Hartford, CT, all bus routes are drawn with a single thickness. And, lest you think Iâm cherry-picking small cities, here is the bus map of Manhattan, where all bus lines are drawn identically.
So I would conclude that the makers of maps of a bus system are simply making arbitrary choices in what they wish to communicate to the public regarding their public transit system. Bostonâs transit agency chose to display a few bus lines like a subway line, in order to promote subway riders taking their direct bus rather than a more circuitous route that involved three subway lines to get from a major transit hub to the airport.
These are a lot of words to say that the makers of transit system maps will make bespoke maps to meet each agencyâs visual communication goals to the public. OSM should not be attempting to encode bespoke map design choices into the database.
It has already been pointed out that there is a 3rd party organization that numerically scores bus systems on their âBRTnessâ. Why not just invent a tag to capture that?
