Open matkoniecz opened 4 years ago
RobJN
commented
4 years ago What on earth is a "reassurance marker"?! I've never heard this term used before. Perhaps just use "Road number not shown on signs". Could also use "displayed" instead of "shown".
matkoniecz
commented
4 years ago reassurance marker
I also never heard this term earlier, but meaning was obvious from context.
See https://en.wikipedia.org/wiki/Reassurance_marker
A reassurance marker or confirming marker is a type of traffic sign that confirms the identity of the route being traveled without providing information found on other types of road signs, such as distances traveled as is done by highway location markers, distances to other locations or upcoming intersections.
Note that sometimes unsigned_ref are posted but effectively invisible (in my area there are posted as small markers, with text about 3 cm high - utterly invisible to any driver, even cyclist would be unable to read it)
DujaOSM
commented
4 years ago Some people love adding officially assigned road numbers that are not signposted (or are marked with signs that are invisible to drivers).
This is not a good place for this discussion, but I must say I find the unsigned_ref key very... um, badly designed.
A reference number is a reference number, signposted or not. Nowhere in the ref documentation it is stated that it has to be signposted. (And indeed, low-ranked roads across Europe seldom are). If it is desirable to indicate whether reassurance markers exist, something like ref:signposted=yes could have been used, not inventing a whole different key. Plus, there's always the rendering issue -- I don't see why unmarked roads would be rendered differently from the marked roads.
matkoniecz
commented
4 years ago I would be happy to discuss it elsewhere (tagging mailing list, OSM Telegram channel, US Slack, Polish forum), but main use of this tag is to handle refs that are technically assigned but noone is actually using them, unlike widely used ref assigned to roads.
For example 1503L from https://www.openstreetmap.org/way/813282360 is utterly pointless and useless and exists only in some hidden documentation. It is fundamentally distinct from say ref=48 on https://www.openstreetmap.org/way/32280482 that is used, recognised and useful.
DujaOSM
commented
4 years ago Tagging quibbles aside, what do you expect from iD in this case? unsigned_ref is IMO not so frequently used to justify its addition into the default highway preset. If one adds it manually, it is correctly recognized and linked to the wiki page:
The only thing that does not work is finding it manually from the "Add field" drop-down, but even then one has to know in advance that it exists and what it means.
matkoniecz
commented
4 years ago what do you expect from iD in this case?
To display it as a field, not just in raw tag list - AFAIK iD is designed with expectation that normal user does not need to see raw tag values.
The only thing that does not work is finding it manually from the "Add field" drop-down
What is also not working is displaying this tag if tagged already. This would help to reduce needless adding it also as ref
rmikke
commented
4 years ago Maybe adding a checkbox like "Signposted" to the "Road number" field would work best.
matkoniecz
commented
3 years ago BTW, I finally captured "barely signed" case - image is at https://commons.wikimedia.org/wiki/File:Barely_signed_road_reference_code.jpg and used at https://wiki.openstreetmap.org/wiki/Key:unsigned_ref
On topic of key name - if that is what blocks wider acceptance I would be fine with making a proposal for that.
1ec5
commented
2 years ago I must say I find the
unsigned_refkey very... um, badly designed.
As far as I can tell, unsigned_ref has this confusing name because routes with obscure signage are colloquially called “unsigned” in the U.S., at least among roadgeeks and traffic engineers. It wasn’t possible to follow British English, per custom, because the UK doesn’t distinguish routes from roads in the first place: https://github.com/ZeLonewolf/openstreetmap-americana/issues/106#issuecomment-1023277432.
Tagging quibbles aside, what do you expect from iD in this case?
openstreetmap/iD#9180 openstreetmap/iD#8966 requests that iD use unsigned_ref to disambiguate between multiple unsigned routes in a list of relations – not unlike what highway departments use these numbers for. I think that could happen even without a field for the key, since it’s only surfacing data that already exists.
If we do add a field for unsigned_ref, it should be called something technical-sounding like “Route Inventory Number” or “Legislative Route Number” to avoid confusion with the main route number and the case where the route number is genuinely never signposted.
Maybe adding a checkbox like "Signposted" to the "Road number" field would work best.
That would be elegant, though I don’t think schema-builder has an affordance for a checkbox that alters the key of a separate field. It would have to be a custom field type implemented by each editor. At one point, some mappers used an alternative tag, unsigned=yes, but it never really caught on for routes and is ambiguous as to what’s unsigned, the route or just its number.
In a minority of cases, this approach would not hold up anyways:
ref) and obscure route number for inventory purposes (unsigned_ref). These are cases of a single route having two identities, as opposed to a road carrying two distinct routes concurrently.
Some people love adding officially assigned road numbers that are not signposted (or are marked with signs that are invisible to drivers).
We have https://wiki.openstreetmap.org/wiki/Key:unsigned_ref for that.
Sadly, some people add it using ref tag, even to roads already tagged with correct
unsigned_ref.I propose to add it as "Road number without reassurance marker" or "Road number not listed on traffic signs" or "Unsigned road number"
See https://www.openstreetmap.org/note/2390078 https://www.openstreetmap.org/changeset/92378423 for example of case where iD mapper added
reftag that now needs to be removed.