[Tagging] Making public transit tagging orthogonal across the map

[Paul Johnson]

On Fri, Jan 1, 2021 at 3:51 AM Minh Nguyen <minh at nguyen.cincinnati.oh.us>
wrote:

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

Well, route numbers are not names, and even the road route scheme moved
away from reproducing the ref in the name field.  This is A Good Thing.


> > 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]
>

RGB colors are in the GTFS spec so I'm unsurprised by this.


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

What I'm saying is one of the three is mandatory, since routes tend to be
signed with one of the three.


>  > 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?
>

I'm not even sure the name format is particularly controversial given that
it's been long understood that the name is only the name, and name is not
ref.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210101/f5dc5f84/attachment.htm>