[Tagging] Refining heritage tag

Paul Allen pla16021 at gmail.com
Mon Apr 20 23:57:06 UTC 2020


On Tue, 21 Apr 2020 at 00:30, António Madeira <antoniomadeira at gmx.com>
wrote:

> As I already wrote before in this thread, lutz already agreed with and
> supported my proposal.
>

Then you don't have to worry about it being rendered.  That's one of your
questions dealt with.

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.
> 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".
>

As it stands, there is a possibility for namespace collision. That is
theoretically
a problem.  An object might have two references, but we've made heritage
references take the form ref:xxx=* so if the other ref is of the form ref=*
there won't be a collision.  But it's also possible that both schemes want
to use ref:xxx.  So adding heritage to the ref key fixes that remote
possibility.

As it stands, overpass queries would not be able to distinguish the right
ref
if an object has a heritage ref:xxx=yyy and a non-heritage ref:aaa=bbb.  A
remote possibility.  Adding heritage to the ref key fixes it.

One downside is lutz having to support two different ways of tagging
heritage refs, probably in perpetuity as I doubt they'll all be upgraded.
But he's agreed to your scheme so he doesn't see it as a significant
problem.

Another downside is that some people dislike long keys.  Even if
they're keys they never use and never will use.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200421/e03f01ba/attachment-0001.htm>


More information about the Tagging mailing list