<div dir="ltr"><div dir="ltr">On Thu, Dec 31, 2020 at 3:28 PM Minh Nguyen <<a href="mailto:minh@nguyen.cincinnati.oh.us">minh@nguyen.cincinnati.oh.us</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
In other words, the name tag is supposed to contradict what's on the <br>
ground, and the format must be maintained manually in a freeform key <br>
rather than structured keys. This is "tagging for the editor" that may <br>
have been necessary at one point for practical reasons, but now it's <br>
simply a glaring exception to the definition of the most important <br>
non-feature key in OSM. Mappers and data consumers have raised <br>
objections to this convention numerous times in the past. [3-10]<br>
<br>
I think it's time we deprecate this format in favor of only tagging <br>
"name" when there's a verifiable name. If any editors still lack support <br>
for the "ref", "from", and "to" tags, fixing that issue seems like a <br>
necessary step so that data consumers can regain confidence in the name <br>
tag on route relations.<br></blockquote><div><br></div><div>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):<br></div><div><br></div><div>57 FOREST GROVE</div><div>57 Portland</div><div>(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)</div><div><br></div><div>20 BURNSIDE</div><div>20 Ruby Junction</div><div>(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).</div><div><br></div><div>Blue Elmonica/170th</div><div>(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)</div><div><br></div><div>58X SUNSET HIGHWAY</div><div>58X Forest Grove</div><div>(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)</div><div><br></div><div>Sure, old examples but all newer ones follow the same pattern.<br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><div>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).</div><div><br></div><div>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.</div></div></div>