<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 5 août 2021 à 13:31, Mateusz Konieczny via talk <<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
<div><br></div><div><br></div><div>Aug 5, 2021, 10:38 by <a href="mailto:colin.smale@xs4all.nl" target="_blank">colin.smale@xs4all.nl</a>:<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><blockquote><div>On 08/05/2021 10:07 AM Mike Baggaley <<a href="mailto:mike@tvage.co.uk" target="_blank">mike@tvage.co.uk</a>> wrote:<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" target="_blank">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" target="_blank">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></div></blockquote><div><br></div><div>I don't get why ref=* can't always hold the value read on ground.</div><div><br></div><div>If we're able to criticise the validity of a reference, and then correct it in some situations, it's only regarding a precise rule that MUST be documented.</div><div>From this perspective, consolidated, validated, corrected, extended, whatever value may go in a specific ref:* key, not in ref=*</div><div><br></div><div>ref=* can't hold all rules, schemes, examples in the world, a dedicated ref:*=* for each situation can.</div><div>That's what we do with ref:FR:*</div><div><br></div><div>My 2 cts</div><div><br></div><div>François<br></div></div></div>