<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 1, 2021 at 3:51 AM Minh Nguyen <<a href="mailto:minh@nguyen.cincinnati.oh.us">minh@nguyen.cincinnati.oh.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Vào lúc 23:26 2020-12-31, Paul Johnson đã viết:<br>
> These shifts from name=* should happen, and will convey the same <br>
> information ultimately in a way that's easier to tell in existing data <br>
> consumers (such as Osmand and OpenTripPlanner) what to expect to see on <br>
> an approaching transit vehicle in reality with minimal changes, if any, <br>
> to existing major data consumers.<br>
<br>
The public transit scheme shares a lot of keys with other kinds of <br>
routes, like road routes, so we should keep those use cases in mind when <br>
imposing constraints on what the keys can contain. Continuing this <br>
discussion on the wiki will make the key sharing more apparent because <br>
pages are organized around keys and tags rather than entire tagging schemes.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> official_name=* shifts to name=*, which should (IETF definition) match <br>
> the route name on the headsign, preferably mixed case even if it appears <br>
> ALLCAPS on the headsign.  So for the examples above, this would be <br>
> "Forest Grove", "Burnside", noname=yes, and "Sunset Highway" in these <br>
> examples.<br>
> <br>
> ref=* or colour=* should exactly match the alphanumeric or color <br>
> reference for the route, with colour accepting the existing color <br>
> descriptions.  So like ref=57, ref=20, colour=blue and ref=58X from the <br>
> above examples.  Both are optional if the ground truth lacks these features.<br>
<br>
Some wiki pages have recommended sticking to the commonly designated <br>
color instead of the precise visual color. However, I don't think that's <br>
the case in practice -- seems like mappers couldn't resist geeking out <br>
about RGB colors. Hopefully those are routes where the color isn't the <br>
primary means of identification. [1][2]<br></blockquote><div><br></div><div>RGB colors are in the GTFS spec so I'm unsurprised by this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> to=* is optional and should exactly match what is on the full route <br>
> headsign to the destination, mandatory if there is no from=* or <br>
> direction=*  For example, if the blue train above continued to Hatfield <br>
> Government Center (the end of the line), and the headsign says <br>
> "Hillsboro", then to=Hillsboro is the correct tag.  This is not the same <br>
> as Hillsboro Transit Center, one stop east, which would be headsigned as <br>
> "Hillsboro TC" instead, and would therefore get to=Hillsboro TC instead <br>
> if the train terminates there instead of going the extra two blocks to <br>
> Hatfield Government Center (aka Hillsboro).<br>
> <br>
> from=* is optional and should exactly match what is on the full route <br>
> headsign to the destination, mandatory if there is no to=* or <br>
> direction=*.  This would only come up in transit systems that expect you <br>
> to know the routes in advance instead of being able to infer based on <br>
> where they're going to.  For example, Tulsa Transit's 114 Sand Springs <br>
> line.  Trimet would sign this as "114 SAND SPRINGS / 114 Sand Springs <br>
> Walmart" but Tulsa Transit signs this on three lines as "114 CHARLES <br>
> PAGE BLVD / 114 From Downtown / 🚌 114 🚌" for reasons beyond <br>
> comprehension.  In this case, this would get ref=114, name=Charles Page <br>
> Boulevard, from=Downtown.  Therefore, from=* would be somewhat uncommon.<br>
<br>
I'm not confident that from=* would be uncommon. Plenty of commuter rail <br>
routes start at a different station at different times of day, making <br>
the origin a pretty important piece of information, if not on headsigns <br>
then on timetables. I'm not saying from=* should be mandatory, but we <br>
should expect editors to support it just as well as to=*, so that data <br>
consumers can choose whether to display them depending on the context.<br></blockquote><div><br></div><div>What I'm saying is one of the three is mandatory, since routes tend to be signed with one of the three.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 > So far out of the cities I've lived in or been to and used public<br>
 > transport, all should be able to fit into the above in some way.  I<br>
 > welcome to hear about routes that don't, in order to shake out this<br>
 > proposal before we get into some really entrenched problems like lanes=*<br>
 > not literally meaning the actual number of lanes on the road, as is<br>
 > intuitive.<br>
<br>
At a glance, I think your suggestions are pretty reasonable. Apart from <br>
the name format and the lane count thing, have any of the other points <br>
been controversial in the past?<br></blockquote><div><br></div><div>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. </div></div></div>