Label route relations with directions and waypoints#8276
Merged
quincylvania merged 1 commit intodevelopfrom Jan 8, 2021
Merged
Label route relations with directions and waypoints#8276quincylvania merged 1 commit intodevelopfrom
quincylvania merged 1 commit intodevelopfrom
Conversation
1ec5
commented
Jan 1, 2021
quincylvania
reviewed
Jan 6, 2021
quincylvania
added a commit
that referenced
this pull request
Feb 15, 2021
…g` is unavailable, such as when running tests (re: #8276)
quincylvania
added a commit
that referenced
this pull request
Feb 15, 2021
quincylvania
added a commit
that referenced
this pull request
Feb 23, 2021
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
Collaborator
|
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. |
Collaborator
Author
|
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. |
Collaborator
|
opened #8559 |
Collaborator
Author
|
This feature made it into v2.20.0 by the way. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

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
namekey 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 => Downtownin 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 thenameconvention 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
directiontag on child relations joined by a superrelation.Caveats
This PR does not pretty-print or localize the
directionvalues. 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=routeroute=roadnetwork=US:USref=66type=routeroute=roadnetwork=US:USref=66direction=easttype=routeroute=roadnetwork=US:USref=66direction=westtype=route_masterroute_master=busnetwork=RTAref=5type=routeroute=busnetwork=RTAref=5from=Downtownto=County Linetype=routeroute=busnetwork=RTAref=5from=County Lineto=Downtown