[Tagging] Making public transit tagging orthogonal across the map

Paul Johnson baloo at ursamundi.org
Fri Jan 1 07:26:18 UTC 2021

On Thu, Dec 31, 2020 at 3:28 PM Minh Nguyen <minh at nguyen.cincinnati.oh.us>

> In other words, the name tag is supposed to contradict what's on the
> ground, and the format must be maintained manually in a freeform key
> rather than structured keys. This is "tagging for the editor" that may
> have been necessary at one point for practical reasons, but now it's
> simply a glaring exception to the definition of the most important
> non-feature key in OSM. Mappers and data consumers have raised
> objections to this convention numerous times in the past. [3-10]
> I think it's time we deprecate this format in favor of only tagging
> "name" when there's a verifiable name. If any editors still lack support
> for the "ref", "from", and "to" tags, fixing that issue seems like a
> necessary step so that data consumers can regain confidence in the name
> tag on route relations.

Please, lets.  It seems the current "name" tag for bus routes makes no
sense.  I think interchangeability with GTFS should be considered a
maintainability forethought, and based on that, I'm going to make a lot of
Trimet based assumptions, since GTFS is a direct product and essentially
the 2.0 of Trimet's proprietary format developed for their trip planning
kiosks in the 1980s.  One of these assumptions is that headsigns have the
same pattern:  Ref and destination or Ref and name followed by ref and
destination.  Or for rollsigns, the background color indicates the route
ref and the foreground color contrasts and lists a destination station
specifically or a city or landmark name for full-length runs, and *never* a
'from' sign (in contrast to some systems, like Tulsa Transit).  For
example, some memorable 1990s ones (for me):

57 Portland
(these two lines alternate, and indicates that the bus is going to its very
last stop in Portland; this sign is a suburban example from the 1990s, so
in this case it means Portland Union Station in downtown)

20 Ruby Junction
(same as above, but naming a station in the middle of a line, not the end
of the line, in this case, Ruby Junction MAX station, now known as Ruby
Junction/E 197th Ave).

Blue Elmonica/170th
(Rollsign example, blue background indicating the route ref, foreground
color is white but only for contrast, indicating the train is terminating
at Elmonica/170th Avenue station, instead of continuing to the end of the
line, often because the train is leaving service or changing routes
mid-line, I'm retconning this to the 90s like Trimet did with what was the
only route as the Blue Line for the sake of consistency (I think it
appeared as in place of 97 in the schedules and had driver numbers starting
with 97 in the 90s but you really had to be a transit geek to read the
driver numbers to tell for sure back then since there was only one train
line at the time)

58X Forest Grove
(same as the 57 but on a differing path that goes nonstop all but the
outermost stops using Sunset Highawy between Shute Road and what is now
called Goose Hollow, following the 57 line above west of Shute Road and
east of Goose Hollow)

Sure, old examples but all newer ones follow the same pattern.

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.

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.

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.

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".

route=* where * is a mode.  In all examples above, route=bus, except for
the blue line which would be route=light_rail (following the example of
London's Docklands Light Railway).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210101/8181153d/attachment-0001.htm>

More information about the Tagging mailing list