Many route relations are tagged unsigned_ref instead of ref because the route number is signposted too obscurely for wayfinding purposes. These route relations get ambiguous labels in the relation and relation membership lists, making it tricky to choose from a list of such routes, because the labeling code only considers ref. Even though the route number is obscure, it still helps to disambiguate items in the list, so it should be a fallback in the absence of ref.
For example, the items in this dropdown menu should say “US:OH:HAM 298” and “US:OH:HAM 299”:
openstreetmap/id-tagging-schema#77 tracks adding a field for unsigned_ref, but I don’t think that’s a blocker for this enhancement. The current implementation incentivizes mappers to replace unsigned_ref with ref for convenience, but that would create confusion among users of renderers and routers. The omission of unsigned_ref in #8276 was simply an oversight on my part.
Many route relations are tagged
unsigned_refinstead ofrefbecause the route number is signposted too obscurely for wayfinding purposes. These route relations get ambiguous labels in the relation and relation membership lists, making it tricky to choose from a list of such routes, because the labeling code only considersref. Even though the route number is obscure, it still helps to disambiguate items in the list, so it should be a fallback in the absence ofref.For example, the items in this dropdown menu should say “US:OH:HAM 298” and “US:OH:HAM 299”:
openstreetmap/id-tagging-schema#77 tracks adding a field for
unsigned_ref, but I don’t think that’s a blocker for this enhancement. The current implementation incentivizes mappers to replaceunsigned_refwithreffor convenience, but that would create confusion among users of renderers and routers. The omission ofunsigned_refin #8276 was simply an oversight on my part.iD/modules/util/util.js
Line 191 in 6e30e61