[Tagging] Making public transit tagging orthogonal across the map
baloo at ursamundi.org
Fri Jan 1 18:44:18 UTC 2021
On Fri, Jan 1, 2021 at 3:51 AM Minh Nguyen <minh at nguyen.cincinnati.oh.us>
> 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
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
> 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. 
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging