I’ve been going through and fixing some of the bus lines in New York City, in part with the help of PTNA - US-NY-MTA and I’ve come to the conclusion that the current wiki instructions for creating bus routes, particularly name= tag make the data less usable.
PTv2 states that the name= tag for bus routes should consist of bus line names combined with values of to= and from= tags, which are first and last stop names.
I think, at least in NYC, we should divert from those instructions and instead use proper names for routes, such as what you can see on https://bustime.mta.info, paper/pdf maps and in GTFS feeds. Most often they are neighborhood names or occasionally prominent locations.
My logic for this is when looking at these bus routes it’s much easier to understand where they are going based on the neighborhoods rather than names of some streets.
For example, in Brooklyn for B6 line it’s much easier to understand: East New York -> Bath Beach
I find this argument persuasive. @Teddych, the author of the successful PTv2 proposal, apparently didn’t intend the to and from tags to always specifically name the first and last stations in every case. If the B6 line is known as “Bath Beach – East New York” in reality, those neighborhood names should be the from and to values, not the stop names.
As far as I can tell, the proposal recommended but did not mandate the rigid name formula. Somehow this format took on a life of its own, probably because it was so easy for validator developers to write a rule enforcing it. But as far as I can tell, the format only exists in order to have something in name that JOSM and Potlatch can label relations by, rather than forcing mappers to juggle relation IDs. The specific punctuation in the format was entirely arbitrary. These days, JOSM and iD are both capable of generating relation labels from keys such as from and to, with iD doing this by default, so I’m not even sure that name=Bath Beach – East New York is truly necessary.
What you describe is essentially the method I settled on for bus routes I’ve recently converted to PTv2 in my area, like Metro 180. In the from= and to= I put the destinations that would most likely be on the bus itself, the schedules, and/or the signs (in this case, from=Pasadena City College and to=Hollywood/Vine). I even got even more succinct and just put Pasadena => Hollywood in the name, since it’s not used for much beyond quickly identifying the route in a list. An interested data consumer could pull out that e.g. the first stop is actually Colorado & Hill from the route relation anyways, so putting the more descriptive destinations in the from and to tags and/or the name adds strictly more information than repeating the stops.
All that to say, I agree with your suggestion and @Minh_Nguyen’s comment.
From a QA perspective, like PTNA, it seems fine to have clear rules for an evaluation.
But, we’re not mapping for renderers, routers, … and QA tools if that does not make sense.
I have no stress relaxing the QA rules here even more.
PTNA allows not checking name= at all
--check-name does a strict check where from= and to= must match exactly in name=
--check-name-relaxed expects the from and to in name= be part/sub-string of from= and to=