[Tagging] Making public transit tagging orthogonal across the map

[Minh Nguyen]

Vào lúc 23:26 2020-12-31, Paul Johnson đã viết:
> These shifts from name=* should happen, and will convey the same 
> information ultimately in a way that's easier to tell in existing data 
> consumers (such as Osmand and OpenTripPlanner) what to expect to see on 
> an approaching transit vehicle in reality with minimal changes, if any, 
> to existing major data consumers.

The public transit scheme shares a lot of keys with other kinds of 
routes, like road routes, so we should keep those use cases in mind when 
imposing constraints on what the keys can contain. Continuing this 
discussion on the wiki will make the key sharing more apparent because 
pages are organized around keys and tags rather than entire tagging schemes.

> official_name=* shifts to name=*, which should (IETF definition) match 
> the route name on the headsign, preferably mixed case even if it appears 
> ALLCAPS on the headsign.  So for the examples above, this would be 
> "Forest Grove", "Burnside", noname=yes, and "Sunset Highway" in these 
> examples.
> 
> ref=* or colour=* should exactly match the alphanumeric or color 
> reference for the route, with colour accepting the existing color 
> descriptions.  So like ref=57, ref=20, colour=blue and ref=58X from the 
> above examples.  Both are optional if the ground truth lacks these features.

Some wiki pages have recommended sticking to the commonly designated 
color instead of the precise visual color. However, I don't think that's 
the case in practice -- seems like mappers couldn't resist geeking out 
about RGB colors. Hopefully those are routes where the color isn't the 
primary means of identification. [1][2]

> to=* is optional and should exactly match what is on the full route 
> headsign to the destination, mandatory if there is no from=* or 
> direction=*  For example, if the blue train above continued to Hatfield 
> Government Center (the end of the line), and the headsign says 
> "Hillsboro", then to=Hillsboro is the correct tag.  This is not the same 
> as Hillsboro Transit Center, one stop east, which would be headsigned as 
> "Hillsboro TC" instead, and would therefore get to=Hillsboro TC instead 
> if the train terminates there instead of going the extra two blocks to 
> Hatfield Government Center (aka Hillsboro).
> 
> from=* is optional and should exactly match what is on the full route 
> headsign to the destination, mandatory if there is no to=* or 
> direction=*.  This would only come up in transit systems that expect you 
> to know the routes in advance instead of being able to infer based on 
> where they're going to.  For example, Tulsa Transit's 114 Sand Springs 
> line.  Trimet would sign this as "114 SAND SPRINGS / 114 Sand Springs 
> Walmart" but Tulsa Transit signs this on three lines as "114 CHARLES 
> PAGE BLVD / 114 From Downtown / 🚌 114 🚌" for reasons beyond 
> comprehension.  In this case, this would get ref=114, name=Charles Page 
> Boulevard, from=Downtown.  Therefore, from=* would be somewhat uncommon.

I'm not confident that from=* would be uncommon. Plenty of commuter rail 
routes start at a different station at different times of day, making 
the origin a pretty important piece of information, if not on headsigns 
then on timetables. I'm not saying from=* should be mandatory, but we 
should expect editors to support it just as well as to=*, so that data 
consumers can choose whether to display them depending on the context.

There's also a via=* key for routes that are signposted with that 
information, though this key doesn't enjoy as much editor support yet. [3]

> direction=* is optional and (likely) mutually exclusive to both to=* and 
> from=*, largely applicable to straight-line and circular routes.  For 
> example, Bartlesville, Oklahoma has one transit route, a city bus line 
> that runs 1 bus, always counterclockwise and the former Tulsa Transit 
> 605 The Loop and 222 41st Street/Pine Street routes which also did 4 
> buses, 2 in each direction, headsigned as CCW and CW.  Keeping 
> consistent with existing direction values, I would suggest validators 
> question values that are not any of "north", "south", "east", "west", 
> "anticlockwise" (keeping consistent with British English being the 
> official language of OSM when unambiguous) or "clockwise".

In other contexts, direction=* can be set to other values like "N", 
"forward", and "180". However, as far as I can tell, it's usually set to 
north/south/east/west for route relations. There are some 
nord/sud/est/oest roles on road route relations in Québec, which could 
in principle be replaced by direction=* tags at some point -- but that's 
probably a tagging error, since routers expect both the roles and 
direction=* to have keyword-style values rather than freeform, localized 
text. It's the responsibility of the data consumer to format the 
direction=* value for display, including localizing it if necessary.

By the way, some bus and light rail systems use "inbound" and "outbound" 
instead of cardinal directions. direction=inbound/outbound are currently 
tagged on route relations in the southern U.S. and Myanmar. San 
Francisco Muni Metro also uses inbound and outbound directions, but the 
route relations haven't been tagged that way yet. [4]

 > So far out of the cities I've lived in or been to and used public
 > transport, all should be able to fit into the above in some way.  I
 > welcome to hear about routes that don't, in order to shake out this
 > proposal before we get into some really entrenched problems like lanes=*
 > not literally meaning the actual number of lanes on the road, as is
 > intuitive.

At a glance, I think your suggestions are pretty reasonable. Apart from 
the name format and the lane count thing, have any of the other points 
been controversial in the past?

[1] 
https://wiki.openstreetmap.org/wiki/SPARQL_examples#Public_transportation_route_colors
[2] https://commons.wikimedia.org/wiki/File:Look_Both_Ways.pdf?page=15
[3] https://github.com/openstreetmap/id-tagging-schema/issues/104
[4] https://www.openstreetmap.org/relation/2007934

-- 
minh at nguyen.cincinnati.oh.us