Talk:Key:survey:date

got this info from irc, would be cool if i get some feedback if i understood it well

Sven - 2013-07-14

Rather use a changeset tag?

Gileri wrote:

Used on objects, survey:date=* does not allow to specify which attribute have been surveyed, and can imply that all properties of the object have been surveyed (tags, position, area). On the contrary, when used on as changeset tags, only attests that the changes are from a specific survey date. Metadata tags like survey:date=* also run the risk to not be updated when another survey is done on the object.

For those reasons, alternatives such as using changeset tags should be considered before using survey:date=*.

Sorry, that is not an issue but an argument plus a statement of personal preference!

I agree that sometimes a changeset tag could be in order. But the changeset does not even tell which object has been surveyed, or all of the objects, and which attributes, or all of the attributes? Many changes are caused by a change of a different object, think collateral damage, which is a reason NOT to look at the changeset date if you want to know when the object was surveyed. This is especially common with big relations such as recreational route relations, which require constant surveillance.

survey:date as an object tag says the existence of the object has been verified by survey on that date, and its tagging updated as needed. That is an attribute of the object, not of a changeset. You can retrieve specific objects by survey:date, e.g. with an 'older than' clause in the query.

I would prefer this issue be discussed on this talk-page first, see if we can find a proper wording. It is certainly advisable to consider when to use the changeset date and when to set the date on the object itself. We could also add that survey:date is supposed to express that the object and all its tags were surveyed and correct on that day.

--Peter Elderson (talk) 21:18, 28 April 2021 (UTC)

>But the changeset does not even tell which object has been surveyed, or all of the objects, and which attributes

You can split a changeset into single changes if necessary. That's what I applied successfully to my changesets for a long time.

You can, but that is not what changesets are for. And again, the function is: when was this object last surveyed, not: when was it last changed. Many changes occur without survey of this specific object.

>is a reason NOT to look at the changeset date if you want to know when the object was surveyed. [...] You can retrieve objects by survey:date, e.g. with an 'older than' clause in the query.

I agree, that's why I wrote that adding survey:date on the changeset is a good idea.

?? You can't rely on changesets to find specific objects surveyed 3 years ago. E.g. hiking route relations. Maybe you can find instances where conditions are such that it could work, but as a general mechanism, no way.

>survey:date as an object tag says the existence of the object has been verified by survey on that date, and its tagging updated as needed

That is one interpretation. There are many tags that may not be surveyed each time, e.g. the owner/operator name, opening hours, internet access, wheelchair/toilet accessibility, phone number, various ref=*. Are you sure all contributors check all the tags every time they use survey:date=* on an object ? I don't.

Yes, that is the idea. Could be more clearly specified. You survey the object, that means you do a proper check and change what is necessary. As with everything mappers do, you have no guarantee. I think mappers who do not do the full monty, are also not likely to update the survey:date. Plus, I thnk objects with many extra details are less likely to use survey:date. Note that it's not put down as a generic change tracking mechanism. Ít's especially useful for objects where users benefit from knowing how recent the information is. Recreational routes suffer from degradation over the years, so users want to assess e.g. if the route on waymarkedtrails is newer or older than the booklet they bought second hand. Survey:date tells them that.

> I would prefer this issue be discussed on this talk-page first, see if we can find a proper wording

Most of the page come from this edit. I do not see a reference to a discussion for this edit, is there one ?

I was triggered specifically about the last edit to to issues section.

Please note that I did not substract any information, used conditionnals and did not mark it deprecated or similar. That allows readers to make their own opinion based on additional information. That is an improvement to the previous state, which doesn't inform of those potential issues. --Gileri (talk) 21:42, 28 April 2021 (UTC)

Sorry, you "issue" argues why survey:date as an object tag is wrong, and says changeset tag is to be preferred. I disagree. Both have their place. That is what should be in an issue: if no common opinion is found, you state the issue and both opinions. --Peter Elderson (talk) 22:17, 28 April 2021 (UTC)

You don't present arguments or examples disproving what I shared, so we can't move forward. Again, please note that I did not touch the rest of the article, I only provided insight on the issues coming from using change metadata on objects. Anyone is free to make its own opinion on the issue.

I'll add another data point : Every day I see objects being updated with another source than the one present on the object. Don't you think that undermines the value of metadata on the object if we can't use rely on it ? What's the point of adding it then ? --Gileri (talk) 11:55, 3 May 2021 (UTC)