<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div><br></div><div><br></div><div><br></div><div>Aug 5, 2021, 10:38 by colin.smale@xs4all.nl:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><blockquote><div>On 08/05/2021 10:07 AM Mike Baggaley <mike@tvage.co.uk> wrote:<br></div><div><br></div><div> <br></div><div>>If you have a road which is signed (for example) "A12" for almost its<br></div><div>entire length, but somewhere there is a one-off sign that says "A21", do we<br></div><div>tag that bit of >road as "A21"? Over what length? Or do we map following our<br></div><div>cognitive processes, and assume that the sign is erroneous?<br></div><div>><br></div><div>>If you have a road that in fact used to be the B2009 but was declassified<br></div><div>years ago, but somewhere along its length there is a rusty fingerpost in the<br></div><div>hedge that >has the old number on it, does that road magically regain its<br></div><div>number from 30 years ago?<br></div><div>><br></div><div>>If we are not going to let many decades of data modelling experience get in<br></div><div>the way of our tagging schema, we accept that there is only one "ref" for a<br></div><div>road. How >we judge which one to choose is what we are discussing here. Most<br></div><div>arguments seem to revolve around a use case whereby a car driver is<br></div><div>navigating, looking at >signs to help decide which way to go. The human<br></div><div>brain is good at glossing over mistakes that appear obvious, but that's no<br></div><div>reason to propagate them.<br></div><div><br></div><div>I suggest using name:signed and ref:signed to hold incorrectly signed<br></div><div>values. You can then have name:signed=yes, name:signed=no and<br></div><div>name:signed=<signed name>. I would suggest that if used to hold a value<br></div><div>other than yes/no, then source:name and/or source:ref ought to also be<br></div><div>specified so that it is clear why the name/ref is not the same as the sign.<br></div></blockquote><div><br></div><div>Problem solved, then. Thanks for the clear and pragmatic solution. ref and name carry the official, proper values, and if a sign disagrees, put that in name:signed or ref:signed together with information about the sources.<br></div><div><br></div><div>What's not to like?<br></div><div><br></div><div>This allows two different renderings to be derived from the same data - one using the official values, and one using the "as-signed" values. The consumer can choose, according to their specific use case. We provide the data for both.<br></div></blockquote><div dir="auto">Note that we have also <a href="https://wiki.openstreetmap.org/wiki/Key:unsigned_ref">https://wiki.openstreetmap.org/wiki/Key:unsigned_ref</a> for cases<br></div><div dir="auto">where ref is assigned but never signed with a clearly visible reassurance marker.<br></div><div dir="auto"><br></div><div dir="auto">(for some reason local road authority may post some barely visible signs, but they are<br></div><div dir="auto">unreadable even while cycling and invisible when driving and noone uses them to<br></div><div dir="auto">identify roads, such codes are appearing only in the official documentation<br></div><div dir="auto">See <a href="https://wiki.openstreetmap.org/wiki/File:Barely_signed_road_reference_code.jpg">https://wiki.openstreetmap.org/wiki/File:Barely_signed_road_reference_code.jpg</a><br></div><div dir="auto">where unsigned_ref is fitting<br></div><div dir="auto">Though I admit that unsigned_ref is a poor name for one that can be actually signed<br></div><div dir="auto">by some weird road authority officials... But noone really expected that.<br></div><div dir="auto">)<br></div> </body>
</html>