<div dir="ltr">In my experience of mapping heritage stuff (mainly in Belgium), i never found any case where i would need to re-use the scheme <b>ref:<operator>=* </b>(where the "<operator>" is the group of letter given by the other tag <b>heritage:operator=<operator></b>) for another thing (and it was always comprehensible, as all other subtag of the heritage around here are based on this "<operator>" value). <div><br></div><div>And seeing heritage:ref:operator seems less logical to me as it would not directly indicate that it is a "ref" value in that tag (as the ref is not the first word). But it may just be subjective. ^_^</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 21 avr. 2020 à 01:58, Paul Allen <<a href="mailto:pla16021@gmail.com">pla16021@gmail.com</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 dir="ltr"><div dir="ltr">On Tue, 21 Apr 2020 at 00:30, António Madeira <<a href="mailto:antoniomadeira@gmx.com" target="_blank">antoniomadeira@gmx.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    As I already wrote before in this thread, lutz already agreed with
    and supported my proposal. <br></div></blockquote><div><br></div><div>Then you don't have to worry about it being rendered.  That's one of your</div><div>questions dealt with.<br></div><div> <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>
    My problem with the actual ref tag is that there are many ref tags
    for other schemes and elements, but I don't know if this concern is
    pointless or not.<br>
    I would like to see this scheme more organized and not so ambiguous
    data wise, but I don't know if that's technically better or if there
    are actual problems with ref tag being "all over the place".<br></div></blockquote><div><br></div><div>As it stands, there is a possibility for namespace collision. That is theoretically</div><div>a problem.  An object might have two references, but we've made heritage</div><div>references take the form ref:xxx=* so if the other ref is of the form ref=*</div><div>there won't be a collision.  But it's also possible that both schemes want</div><div>to use ref:xxx.  So adding heritage to the ref key fixes that remote</div><div>possibility.</div><div><br></div><div>As it stands, overpass queries would not be able to distinguish the right ref</div><div>if an object has a heritage ref:xxx=yyy and a non-heritage ref:aaa=bbb.  A</div><div>remote possibility.  Adding heritage to the ref key fixes it.</div><div><br></div><div>One downside is lutz having to support two different ways of tagging</div><div>heritage refs, probably in perpetuity as I doubt they'll all be upgraded.</div><div>But he's agreed to your scheme so he doesn't see it as a significant</div><div>problem.<br></div><div><br></div><div>Another downside is that some people dislike long keys.  Even if</div><div>they're keys they never use and never will use.</div><div><br></div><div>-- <br></div><div>Paul</div><br></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>