Should StreetComplete expand its use of check_date?

General talk Tagging general discussion
1

TLDR: I suggested that StreetComplete should add and update check_date more often; @westnordost is happy to do this provided there is community buy-in.

Current app behaviour:
If a poi has not been modified for a given amount of time (it varies by poi type, I believe a shop is 2 years) it will prompt a quest asking ‘Is this still here?’ - this will add check_date=today’s date if the user answers yes. This tag is added only when no other tags are modified, as there is no way to bump the last modified date of a node without moving it or updating the tags.

Example applications of this tag:
CoMaps has recently started surfacing this tag, displaying “Existence confirmed X weeks ago” in relevant poi info panels (see CoMaps now supports check_date and check_date:opening_hours). This can help reassure CoMaps users that the poi they are navigating to still existed at a certain point in time. The tag can also be used to indicate areas where shop data has become stale, and could do with a survey.

The problem:
As per the original consensus from 2020 (discussed here on the mailing list The Tagging July 2020 Archive by thread), StreetComplete only adds check_date when an ‘Is this still here?’ quest is answered. It does not add a check_date when a poi is created via an overlay, or any other quest about a poi is answered. This means that there are many scenarios where StreetComplete modifies a poi but does not update check_date, despite the source of the change being a survey. Consequently, data consumers such as CoMaps do not know when such features were last confirmed existing. They could use the last modified date as an indication, this is often not useful as pois often get edited from aerial imagery or simply have tags correct, neither of which confirm the continued existence of that poi. Furthermore, StreetComplete cannot offer an ‘Is this still here?’ quest for pois that were recently modified as part of automated fixes (but have not been surveyed in many years), as it looks at the last modification date when generating this quest.

Example problematic scenarios:

  • A shop=hairdresser node has not been modified for 10 years. The user is prompted the question “Which customers visit this hairdresser?”. They answer ‘male only’ so male=yes is added (or whatever the exact tag is). No check_date is added or updated, so data consumers like CoMaps do not know if the last modified date was a result of a survey or not. If StreetComplete added check_date when adding male=yes, no assumptions would have to be made.
  • An amenity=pub node has not been modified for three years. Someone then adds a missing addr:city tag based on the pub’s location, bringing the last modified date to today. No ‘Is this still here?’ quest will be shown for the next two years now (depending on app settings), meaning data consumers can only assume when the pub was last confirmed to be open. If StreetComplete looked at check_date rather than last modified date, it could ask ‘Is this still here?’ tomorrow.

See also the github issue I opened suggesting this change (discussion is preferred here and not on github): add/update check_date when answering quests or adding new pois · Issue #6832 · streetcomplete/StreetComplete · GitHub

The proposal:
StreetComplete should add check_date to a poi when it is created, and should add or update check_date whenever any other quest is answered about a poi. It should use check_date to generate ‘Is this still here?’ quests, instead of the last modified date.

Please share any concerns you might have with an expansion of the use of check_date below, or if you have an alternate solution to the issues raised. If I have made any errors in describing app behaviour or quest rules please raise those also and I will correct them. I’m sure there may be some edge cases where check_date isn’t necessary to be updated, which would no doubt be accounted for should the community support an expansion in the use of check_date.

Poll for tracking consensus:

Expanding the use of check_date in StreetComplete
  • StreetComplete should add/update check_date when a poi is created AND when it is modified
  • StreetComplete should add check_date when a poi is created but NOT when it is modified
  • StreetComplete should add/update check_date when a poi is modified but NOT when it is created
  • StreetComplete should continue only adding check_date when a user answers an “Is this still here” quest
  • Another solution should be found
0 voters

Once again thanks to all for reading and happy StreetCompleting!
LGS

10 Likes
2

A follow up question:

Suppose the decision is made StreetComplete adds/updates check_date when a POI is created and/or when it is modified. Do you thing editors like iD, Josm, Vespucci should also do this?

  • Editors should only add check_date when the POI is added
  • Editors should add a check_date when the POI is added or modified
  • check_date should only be used by Apps that know you are close by.
0 voters
1 Like
3

This would seem to be tagging for … something…

Particularly for newly created objects it would seem to be technically unnecessary (double tagging creates issues, but that is the same for check_date too). And, as I’ve suggested before (would have to dig out the reference, but somewhere on the tagging or general mailing list), it would be completely possible to add a timestamp to individual tags without causing any larger amount of backwards compatibility pain and solve the issue properly instead of layering hack upon hack upon hack.

6 Likes
4

Absolutely not, check_date should only be used for edits based on a physical survey, users can manually add check_date in iD or josm if they are working from survey notes.

I have also been informed that EveryDoor automatically adds check_date when it creates or modifies pois, as it assumes the user is always working from a survey. I haven’t used the app so if anyone is familiar with it please correct me. If EveryDoor does indeed do that, there would already be precedent for what I am proposing StreetComplete should do.

10 Likes
5

Agree. The UK has nearly 36,000 open notes and a lot of them are based on “is this here?” or “this is out of date and X is here”

having SC add the check date would make it so much easier for people reviewing notes to determine if the note needs addressing or is even out of date - sometimes businesses have come and gone by the time someone looks at half these old notes.

5 Likes
6

Can you expand on what you mean by this? Who would be creating those timestamps, the OSM servers, or would it be up to individual data consumers to work it out?

I was originally thinking this, but there are scenarios where the v1 creation date of an object does not represent a survey date. If someone mapped a poi as a node a long time ago, then another user moves all those tags onto a way (because of indoor mapping or something), that way will have a creation date significantly newer than the date the poi was actually surveyed. So, we can’t rely on creation date for that reason alone. Likewise if someone adds a bunch of pois in an import, they may be working from and older data source. Just because a poi was created yesterday, does not mean it was last surveyed yesterday. Relying on the existence of check_date would resolve these ambiguities.

2 Likes
7

I’d only support StreetComplete adding the check_date tag if it is reasonably certain that the edit was the result of survey that confirms the existence of the object. In this example, what if the hairdresser was called something like “High Street Gentleman’s Barbers”. Based on that, someone could ignore the warnings and use StreetComplete to answer the question without actually having checked anything on the ground. Could StreetComplete at least only add/update the tag when the GPS shows the user is really near the POI?

10 Likes
8

Yes, please … idk how close you’d need to be, given that sometimes gps drift or inaccuracies are a thing.
Also; it could very well be the case that someone travelled away from the quest position while answering it, so this check should include the entire path of where SC was open (it already shows that dashed blue line, so this is recorded).
Like if a passenger sees a poi out of the window, they can answer existence, or maybe another quest, but by the time they are done, a car might already be several houses/plots away. Or if you’re on a train, you can see many things, and can be travelling great (compared to by foot) distances in-between opening a quest and answering it too.

I do suspect at least some users to use SC as an editor from “at home”. For this case alone I think it’d be beneficial to have at least some kind of info on that. Maybe a changeset tag answering whether the gps was on at all, or some statistics on distance to quest objects while answering (median, max, min, avg, etc. as appropriate) to help in identifying these changes, and/or flagging them to further check again later on.

Looking at mapillary imagery and virtually travelling along a road to answer quests about anything visible in them is possible, but doesn’t guarantee something hasn’t changed OTG between the image being taken and now.
I did have the idea in the past that it would be possible to create a version of SC based on streetlevel imagery alone. This could then of course substitute the check_date for the time (in the past, however long ago) any image was actually taken.
This would then of course necessitate checks against “manually” reversing a change between that time and now. Which in turn would probably necessitate more specific check_dates.

2 Likes
9

This is true, but outside of changeset tags and those with lots of grains of salt, you are not going to get a complete sequence of what exactly the provenance of the tagging is in any case at best a rough approximation (and then there’s the rabbit hole of per tag check_date tags). And then there’s this small issue that check_date doesn’t necessarily imply an on the ground survey to start with, so you are really inferring too much in any case.

10

Regarding option 3 in the poll:

StreetComplete should add/update check_date when a poi is modified but NOT when it is created

In practice, there’d not be a real difference to option 1, as users are usually asked further quests on newly created POIs right away. And if the mapper doesn’t answer these, the check_date would be set by the next SC-mapper.

2 Likes
11

Note that the current behavior is that if any check_date:<key> is updated or added, check_date will also be updated to that date, if it is present. So, it’s not possible to end up in a situation where the following is tagged:

shop=antiques
opening_hours=Mo-Fr 08:00-18:00
check_date:opening_hours=2026-05-06
check_date=2021-01-01

check_date will always be the latest date if any other check_date:<key> is present.

I remarked earlier (in the linked ticket) that data consumers that want to display the latest date at which the existence of a POI has been checked, could look at the latest date of all check_date:.* (and synonyms) tags. Sure, check_date:.* doesn’t imply survey on foot, someone could have checked the website which turned out to be still up for a place that doesn’t exist anymore, but neither does check_date imply that it was checked on a survey (It’s just only very likely).

4 Likes
12

Re: creating objects and check_date

I sometimes add objects based on either my own records of a place or according to street level images. I try to tag a check_date set to the image creation date when I do so. This naturally results in objects with a check_date older than the creation date of the object.

6 Likes
13

I think the current situation is already ideal. We don’t have to flood the OSM servers with check_date tags.

Instead, the “is this still here?” quest should actually incentivize detecting closed shops rather than mass-tagging all OSM objects with timestamps. Reward users for detecting shops that still exist in the OSM database but no longer exist in real life. Do not reward users for adding a “last seen” timestamp to shops that both exist in the OSM database and are still operating in real life. By using this approach, the map data could become more useful without putting too much strain on the server and database.

14

these, as far as I know, are not real limitations or reasons to avoid that

it is more about what other mappers would prefer, as extra tags may be potentially annoying/confusing/whatever

It is not clear to me what you propose here

5 Likes
15

Well and there are questions like how far should you integrate the tag in your fav editor workflow. For example if a check_date tag is present should you popup a modal offering to update the date when the user changes tags or not (could be very very annoying).

1 Like
16

That is correct. I used it while on holidays recently, adding ~500 check_datess. You can “confirm” a PoI without having to edit it from the “main screen”. ED will also add it to new objects: e.g. a v1 gift shop with a check_date from EveryDoor

4 Likes
17

Example problematic scenarios:

Another one that occurred to me recently while I was happily check_'ing things on holiday: How much do you have to check?

If I see a cafe with the correct name, I confirmed it, adding/updating the check_date. But what if the OSM object has payment tags? or opening_hours? or …. I haven’t check those are the same.

Should I check all the tags before confirming it? Should data consumers presume it’s only the name & shop/amenity/… tag which has been confirmed? What does check_date mean here?

9 Likes
19

from its wiki:

  • to document the date when the existence of an object was last checked.

I.e. you’d need to use check_date:opening_hours if you wanted to explicitly specify that you’ve checked opening hours and that they still apply. (StreetComplete already does that if opening_hours is confirmed on resurvey quest to be the same as previously recorded value).

(That being said, if you’re there and using EveryDoor [or StreetComplete], it is best if you could update all the data.)

5 Likes
20

It looks like somewhat of a consensus is being reached. So far, check_date is only updated if it exists or if another check_date:.* is updated, for any element. @LordGarySugar’s suggestion now introduces a distinction between POIs and “other types of elements”, such as roads, buildings, etc..

So, it would have to be implemented that check_date is only added on POIs and not other elements.

Fair enough, but considering…

… I was hoping for a consensus when to add check_date:.* on elements. Currently, it is only added when nothing else is changed. E.g. only if the opening_hours didn’t change since last survey, check_date:opening_hours is added. Now, I understand that this thread has been orthogonal to this matter, right?

The issue with the described logic, is, that even if a quest is set to be re-asked every year or so, there is absolutely no guarantee that it will (ever) be re-asked without a check_date:.* being present, because if absent, the last edit date of the whole element is looked at to determine if a quest should be re-asked. Now, that element could have changed for any number of reasons - someone corrected the geometry, typo in name, added some additional tags, changed some tags, etc…

What is suggested here will not change anything in this regard.

Or, in other words, the last check date for opening hours as shown in CoMaps will not be set automatically by StreetComplete when opening hours have been entered, but only after those opening hours were confirmed to still be the same after one year or so

21

Maybe Comaps should therefore not exclusively rely on the check date tag and also, like SC, on last modified date?