[Tagging] Refining heritage tag

[Lionel Giard]

In my experience of mapping heritage stuff (mainly in Belgium), i never
found any case where i would need to re-use the scheme
*ref:<operator>=* *(where
the "<operator>" is the group of letter given by the other tag
*heritage:operator=<operator>*) for another thing (and it was always
comprehensible, as all other subtag of the heritage around here are based
on this "<operator>" value).

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. ^_^

Le mar. 21 avr. 2020 à 01:58, Paul Allen <pla16021 at gmail.com> a écrit :

> 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
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200421/0a8b8c98/attachment.htm>