Hi all,
I’m planning a mechanical edit to fix the tagging on bus stops in Long Beach, repairing a four-year old import. Proposal here: Mechanical Edits/willkmis/Long Beach Transit tag upgrades - OpenStreetMap Wiki. Comments welcome! I’m also cross-posting on OSMUS Slack. If there are no objections in the next week or two, I’ll go ahead with it.
5 Likes
After receiving no objections here or anywhere else, I went ahead with this edit, which is now complete! See Mechanical Edits/willkmis/Long Beach Transit tag upgrades - OpenStreetMap Wiki for description of the implementation and changeset links
1 Like
I only saw this recently but I’m glad this was addressed, thank you. I noticed that nonstandard tagging scheme when I was doing the OCTA bus stop import.
On the topic of the mechanical fix, I noticed that in the process several OCTA and LBT stops were merged into one with delimited network, network:wikidata, and ref. This seems to cause issues with not knowing what information relates to which, especially for the ref and operator, and I am not sure if its correct to have multiple NSI presets for one object.
Example: Node: Del Amo-Norwalk (6356006283) | OpenStreetMap
I’m not sure which way is ideal, but the approach I had taken was to keep them separate but next to each other and grouped with a transit area relation to prevent any conflict.
Examples: Relation: 15574018 | OpenStreetMap and Relation: 15574074 | OpenStreetMap
Is this something that should be changed one way or the other?
Hey, thanks for bringing this up! I agree that this is an ambiguous situation, and I merged them into one stop during this import simply because that’s what I usually do when mapping bus stops in Los Angeles, where multiple operators serving one stop is very common due to the balkanized nature of public transit here. I don’t think there’s anything obviously wrong with either approach and that both have pros and cons.
I tend to map them all as one point because to me these are usually one conceptual “bus stop feature”, with multiple operators happening to serve them. This is especially true to me if all the operators share the same infrastructure, like shelters and whatnot. I don’t think there’s anything clearly wrong with having multiple semicolon-delimited operator tags, since OSM does that for lots of other tags as well. I agree with you that it starts to get messy if you want to add operator-specific information like ref, or even worse, if each operator has a slightly different name for the stop. What I’ve been doing is ordering the ref in the same order as the networks, but that gets complicated quickly. I then honestly just pick a name: usually the biggest difference is the delimiter between the intersecting streets (&, /, at, @, etc.), and I find that at least around LA, most of the bus operators aren’t even very internally self-consistent about those from stop to stop. If one operator named the stop after a landmark or something I’ll put it in alt_name. If different operators clearly stop in different places (or even different lines of the same operator), I usually make multiple nodes.
I think your multiple, grouped stop approach works OK if there are a couple of operators, but I’ve seen some real behemoths, like Node: Westwood & Weyburn (2076446552) | OpenStreetMap and Node: Figueroa Street & 7th Street (1376454268) | OpenStreetMap. I’m not really sure mapping these as 6-8 separate highway=bus_stop nodes stacked right next to each other is a clearly better description of what’s on the ground than one stop with 6-8 operators, since the buses all stop at the same place. But I also see how doing so would make parsing things like ref simpler.
The wiki is mostly silent on the issue: it looks like someone did bring it up in the bus_stop Talk page once, and the response favored mapping them as one node: Talk:Tag:highway=bus stop - OpenStreetMap Wiki. But that doesn’t say much more than that one other person favored this approach.
So to sum up, I don’t think the way you’ve mapped your examples is wrong per se, but I think both styles have pros and cons. It might be worth getting input on the issue from a broader audience, since LA isn’t the only area where this happens. But if you’d like to change some of the ones I changed in the import back to the other style, I don’t object or anything.
1 Like
The primary question is: What is on the ground?
- Is it one platform with different names by operators or two platforms each with an individual name?
- What is the name written on the sign/pole?
- Is there a sign/pole for each name?
If it is only one stop with different names and refs per operator you could use suffixes like the values of operator:short (usually the abbreviation) for name:*=* or ref:*=* and leave name=* and ref=* for the ground truth. Maybe reg_name and the, just lately, approved GTFS tags are interesting for you.
Using type=public_transport stop_area or stop_area_group relations is certainly the correct way to group them but the most important rule for OSM is ground truth and verifiability.
Unfortunately I don’t think the realities on the ground will clarify this question much. American bus operators don’t usually sign the actual name of a stop at the stop itself. For a concrete example, here’s one of the stops I merged during the import: Node: South-Gridley (6356011334) | OpenStreetMap. This is what it looks like on the ground (Bing Maps - Directions, trip planning, traffic cameras & more):
It’s a little blurry on Bing (you can see it a bit more clearly on Google StreetView). All of the operators have attached their signs to a pole (although in other places in the area I’ve seen a couple of different poles right next to each other). The signs only say the operator and the route number, maybe the destination. I would call this all one platform (a passenger would wait on the same bench to catch any of the Long Beach Transit, OC Bus, Metro, or Cerritos on Wheels buses that stop here). Each operator internally (as in, on the onboard announcements or their website) probably calls the stop some slightly different variation of the two cross-streets, South and Gridley, like South-Gridley, South / Gridley, South Street & Gridley Road, etc., conforming with typical American bus stop naming conventions. But this won’t be signed anywhere on the ground. The ref each operator has for the stop may or may not be signed somewhere.
I think tagging ref:Metro, ref:LBT, etc. could be useful, although it makes querying for/rendering the refs across the whole system harder. It’s not obvious to me in that case how to decide which “main” one would go in the overall name and ref. When I add new bus stops, I’ve just been picking one format that I like the best and had the most usage in my area when I started mapping (where the streets are separated by an &), but I recognize that this isn’t a particularly persuasive line of reasoning. So I don’t usually change the delimiter if someone else had already mapped it differently.