On Wed, 3 Apr 2019 at 22:06, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> > haven’t we written somewhere in our terms that the information isn’t > reliable? I’m quite sure we have. Some people have to be told that coffee > is hot, kittens must not be dried in the microwave and map data may contain > errors. > Sadly, yes, some people do have to be told these things. Or, to state it more precisely, many companies find it necessary to place warnings of such things on their products to avoid being sued in court. AGAIN. That's why we have so many warning labels in our daily lives, telling us not to do things that the vast majority of us would never think of doing. We may state that the information isn't reliable, but I don't see that as an excuse to map things incorrectly. It's an admission that we make mistakes, not a licence to deliberately mis-map. One person in this thread claimed, incorrectly, that there are no access restrictions to religious structures and that it is not possible to determine if somebody meets the restrictions he said don't exist. Such restrictions do exist and the penalties for contravening them can be harsh. Very harsh. I see no reason to disallow something like access=adherents and every reason to adopt it. Even if you think it completely unnecessary, it's not doing any harm if it represents the actual situation on the ground better than having access=yes, access=private or no access tag at all. It doesn't conflict with any other tagging, and doesn't break the semantics of the access=* tag. I can understand (just) people arguing about whether it should be access=adherents or access=adherent, whether it should be adherents or customers, or something like that. But arguing about whether or not we should tag the access restriction at all seems silly. What harm does it do if somebody does add access=adherent (assuming that to be the case)? -- Paul
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
