tag change dates/flags

[simonpoole]

This is briefly touched on in the study in 3.14.2. Going forward the workload in updating existing OSM data and checking that it is in detail still correct will increase, if not be the major source of changes.

Currently it is impossible to determine if a specific tag was confirmed/re-surveyed/etc. during a specific edit of the object if its value didn't change. There are a few hacks around this by either adding a tag that indicates a last checked date for the whole object or doing this on a per tag basis. This is quite unsatisfactory for a number of reasons, including multiple different keys in use for this meta data, unclear semantics and creating a lot of noise, potentially one meta-tag for every "proper" tag on the object.

It would seem that this could be resolved by supporting a timestamp attribute per tag that could be set by editing apps, or even simpler just a flag indicating that the tag was current as per the object version. This could potentially even be added in a backwards compatible fashion.

The increase in data volume for current data should be manageable regardless of soution tag counts per object type (thanks to Tom)

• Nodes 739'739'524
• Ways 2'082'204'380
• Relations 41'637'194

There are a couple of annoyances/issues that need to be considered,:

• tag time stamps could be set without creating new object versions, however this is obviously ugly from a data modeling pov
• if time stamps were used there would be no history associated with changes, but then that is probably not needed
• a "checked" flag would still require generating a new object version and wouldn't be substantially different in that respect than using a meta tag

[HolgerJeromin]

It would be nice to be able to filter for that information via for example overpass-api.
So as far as I understood its architecture the last-checked "needs" to be published in diffs.

[simonpoole]

My main question would be: what is the target audience for this information? Are downstream data consumers interested in this information? Read: do we need to include this information in minutely diffs and planet files?

Probably yes, actually the whole "concept" goes back to a discussion with a data consumer 2-3 years ago.

If that's not the case we could think about a "last checked" service, where users can leverage a new endpoint to query and update the last check information for a set of (object type, object id, object version, tag) tuples. Of course this needs to be properly integrated in the editing app UI. We would add some kind of overlay layer to the existing API, thereby avoiding any changes to the API itself (which is always my preferred option, as you can imagine).

Obviously both of us could argue both ways :-)

I'm wondering if mappers are willing to maintain such information on a large scale. An overlay service could be good starting point for experiments, and to see if the concept works in real life. But again, this all highly depends on the requirements.

The main question is less directly a technical, it is more how do we drive adoption by the editor developers. There are cases for which no further action by the user are necessary, that is tag creation, deletion and value change. The user in my thinking right now only needs to be involved during editing if there are some unchanged tags on the object and the edit wasn't just a geometry change, the rest could be simply in a QA workflow, like Vespucci has had with highlighting out of date objects since many years.

Reverting data is also ugly, and needs a bit of thought.

Supporting reverting properly boils down to creating versions one way or the other, which makes the whole thing very expensive, as a tendency it is something I could live with not working (aka the information is lost).

[mnalis]

Related discussion in https://community.openstreetmap.org/t/streetcomplete-setzt-check-date-surface/96687 seems to indicate preference for such metadata like check_date:= to be stored with other history metadata, and not mixed with other regular tags.