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 <pla16...@gmail.com> a écrit : > On Tue, 21 Apr 2020 at 00:30, António Madeira <antoniomade...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
