Tag last modified date on existing tags when modifying

[RubenKelevra]

In #2883 a user describes an issue where the splitting of a way would make a quest disappear.

This is due the inability to determine how long certain tags haven't been modified (without parsing the whole history of the element).

So SC assumes that the informations has been confirmed on the last edit of this element.

This is a good assumption, but SC breaks it itself since it modifies tags on objects without verification of the other informations tagged.

Which means we won't resurvey the surface tag ever as long as a user of SC keeps adding additional information to a road every few years.

Proposed Solution
When doing any modification to any element SC should search for all tags it understands for resurvey quests and tag the last modified timestamp as 'check_date' to them.

This avoids moving the modified timestamp forwards on each edit of other tags or simple way splits.

[westnordost]

Do I understand that right, any tag StreetComplete tags should be accompanied by a check_date:[any tag]?

[HolgerJeromin]

I think this "global" approach would be rejected by the osm community.

[Atrate]

I'd be for that — except for the case of "tag spam" I don't see a good reason to reject check_date:*

[RubenKelevra]

I don't see a different solution for this problem.

Say a street hasn't changed in 5 years in the database and has a bicycle tag.

If a user would now tag, that it got streetlamps would lead to the bicycle reconfirmation be pushed like additional 2 years in the future, since there's no check_date tag for it.

If StreetComplete would add a check_date tag to the bicycle-info, it could be shown to the next user instantly.

I mean, we would add a check_date-tag anyway if we would confirm the info, in this case we would just mark the data as unconfirmed since the last modification.

[westnordost]

I agree. But that I do agree is not that relevant.

[smichel17]

I am not sure if it manifests in practice yet, but also the current approach prevents resurveying multiple different properties for the same element. Ex: If we wanted to resurvey speed limits every 5 years and cycleway existence every 10, the cycleway resurvey quest would never appear, since the speed limit confirmation would bump the element's edit date.

I don't see a different solution for this problem.

I agree, in StreetComplete. The alternative is taking the issue upstream, to get metadata included in the osm api. It seems like the necessary data (modification date for individual tags) is available, just in an inconvenient form (changesets). So it should be possible to create a service which parses this data upon request and returns the result in a friendlier form (similar to the StreetComplete stars synchronization counter, albeit much more resource-heavy). But this is much higher-effort.

[RubenKelevra]

@smichel17 well, StreetComplete use subtags for each tag to identify the date of the last verification per tag.

So maxspeed=xy would get a check_date:maxspeed=2021-05-31 tag if you verify it today.

The issue is, if there's no check_date:maxspeed-tag, the last modified timestamp of the object gets used.

So if you add lit=yes the database's modified timestamp will be set to today. So even if the maxspeed-info is 10 years old, StreetComplete would assume it to be verified today.

My proposal is to add the check_date:maxspeed-tag and set it to the last-modified timestamp if we edit an object, to avoid that we loose this information.

The only other solution would be to access the history of every single element which has no check_date tag for a resurvey-quest and find out when it has been changed the last time. I doubt that this is very server-friendly to do and would require quite a lot development time for StreetComplete as well to implement.

If OSM is implementing a check_date natively in the data-structure in the future it would be pretty easy for them to just convert the already exiting check_date tags anyway. So not much to loose here. 🤷‍♂️

[westnordost]

Ehm, you are repeating yourself. Yes. I agree. But note that the fact that I agree is not that relevant. It is not I (or the people on this issue tracker) you need to convince but the community at large.

[westnordost]

I asked on the mailing list which behavior was preferred when I first implemented the resurvey quests and most participants then seemed to lean towards "use as much check_date:* as necessary but as little as possible" (including @matkoniecz if I remember right). Though at the same time, there was noone, again IIRC, who was strongly opposed one way or the other.

So if the topic is brought up again, and with the reasoning you have done here in this ticket, mayb3 there will be more people who'll say "oh yeah, that makes sense" or at least "well I don't mind it if (people/StreetComplete) does it" now.

[matkoniecz]

if I remember right

Yes.