-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Label route relations with directions and waypoints #8276
Conversation
…g` is unavailable, such as when running tests (re: #8276)
Add utilFetchJson to get around some quirks of d3.json and use it for coreFileFetcher Load real general English locale strings at the beginning of code tests
Hey @1ec5, this PR has been really helpful! would you consider extending it to show It's quite a pain currently to edit bus routes with similar names, especially since in real life, the name is rarely used and the ref is more commonly used in conversations etc. |
That’s a good idea. Can you open a separate issue to track making this change? It could be helpful for other kinds of routes too, not just bus routes. I think we’ll want to consider whether to also include the network for consistency with other formats that include the ref, or whether that would unnecessarily crowd out the name. |
opened #8559 |
This feature made it into v2.20.0 by the way. |
Extended the display name functionality so that route relations are distinguished by their directions and/or waypoints in addition to their networks and reference numbers.
Rationale
By convention, the
name
key of many public transportation route relations is set to a rigid format that indicates the route’s waypoints, which does not necessarily reflect the actual name used on the ground. For example, a route relation might be named “Downtown Jobs Express” in reality but5X: Newtown => Downtown
in OSM.This convention is primarily intended to disambiguate similar route relations in a list of relations, to avoid mistakes when adding members to a route relation, since it’s very common for there to be multiple routes with the same number in the same area. However, the standard is also to add the structured tags
from
,to
, andvia
, making thename
convention redundant and counterproductive (as it obscures the structured data that consumers are more likely to use). Better editor support for the structured data will mitigate the pain that mappers might experience from deprecating the naming convention.Along for the ride, this PR also extends the display name for road routes in countries that conform to the MUTCD. In these countries, a route’s two directions are distinguished by cardinal directions, which are either tagged as the member ways’ roles or as a
direction
tag on child relations joined by a superrelation.Caveats
This PR does not pretty-print or localize the
direction
values. That would be worth doing later once the infrastructure is in place for more general localization of tag values.Ideally, the additional detail in these names would only appear when there’s ambiguity between two relations in the relation list, similar to how iD automatically appends the relation ID to two relations with identical display names. However, that optimization would be a bit more invasive.
Example
The following screenshot shows the “Choose a parent relation” dropdown after having loaded six relations, including two superrelations:
type=route
route=road
network=US:US
ref=66
type=route
route=road
network=US:US
ref=66
direction=east
type=route
route=road
network=US:US
ref=66
direction=west
type=route_master
route_master=bus
network=RTA
ref=5
type=route
route=bus
network=RTA
ref=5
from=Downtown
to=County Line
type=route
route=bus
network=RTA
ref=5
from=County Line
to=Downtown