On Tue, 21 Apr 2020 at 00:30, António Madeira <[email protected]> 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 [email protected] https://lists.openstreetmap.org/listinfo/tagging
