[Tagging] Making public transit tagging orthogonal across the map

[Phake Nick]

Speaking of route color, I wonder how one would tag routes that have their
color representation containg multiple different color elements, like color
stripes, or a color for text on top of another background color, or such.

在 2021年1月2日週六 02:47，Paul Johnson <baloo at ursamundi.org> 寫道：

>
>
> 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.
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210102/6b354a49/attachment-0001.htm>