On 24/03/18 00:09, Volker Schmidt wrote:
The automatic "source=wetap" is not correct. If you check with the app
that a fountain is working, and that sets source=wetap, this is
factually wrong. Also the concept of source=whateverapp is not
correct, when whateeverapp is a tool to enter data which come from the
user of the app. So in most cases, where there is no pre-existent
source tag, you could think of manually inserting a source=survey tag.
"source=survey, entry by wetap" would be more descriptive. I have no
problem with documenting the entry by an app - it is hardly spam as it
is not rendered.
In the specific case of drinking fountains, this seems to be the
attempt to insert something that indicates that on the date of the
change the fountain was working, but that needs to be a different tag.
And this raises the obvious question: Do we have any way of tagging
"tag value verified by survey today" ? This would be helpful in many
situations. I am thinking about the repeated discussions about
explicily tagging default values in order to underline that the value
has been checked.
On 23 March 2018 at 13:32, Martin Koppenhoefer <[email protected]
<mailto:[email protected]>> wrote:
I noticed that the wetap app sets tags in a "wetap" name space for
properties for which we already have established tags. Here's an
example:
https://www.openstreetmap.org/node/304151931/history
<https://www.openstreetmap.org/node/304151931/history>
Specifically, it sets the tag
wetap:status=working (IMHO for an amenity this is implied,
otherwise it is disused:amenity if the drinking fountain is not
running but still there).
wetap:photo (we use the image tag)
it also sets a "source=wetap" tag on every object that was touched
(e.g. if you confirm an existing object as wetap:status=working,
it will put a source=wetap tag on the object).
But then if you look at the history the past sources can be found.
I think this change to the source could be a good thing as it documents
the source of the present tags.. provided all the tags were changed.
The tags are not documented AFAIK.
What is your opinion for this, shall we tolerate alternative
tagging to be introduced systematically by third party apps, when
there is already an established tag with supposedly (undocumented)
the same meaning?
Matter of moving the current app over to the documented/accepted tags so
future entries 'fit'.
Changing past entries? I have not thought of.
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
