Force re-survey of Quest for certain element in Things/Places overlay

[mnalis]

Use case Often, the data in the OSM is stale, but the StreetComplete's resurvey interval has not yet kicked in. I also often have local knowledge about it, and would like to provide freshly updated information about those elements now (instead of waiting years for SC to re-ask).

Most often that is opening_hours changes, but others things change also (e.g. bicycle parking got extended, or that bus stop got a tactile paving freshly installed, or that restaurant added vegan choices due to customer requests, or those steps finally got a ramp etc).

If the values were to be resurveyed soon, reducing resurvey frequency to "ask more often" sometimes helps; but much more often it does not.

Currently, only option is to leave a Note or use other app (like EveryDoor).

Having this feature would allow SC mapper to update the values in well-known and simple StreetComplete Quest UI (only re-asked "now" when you know it has changed, instead of at some indefinite time in the future when SC predicts it might've changed)

---

Proposed Solution

Ideally, I would propose adding an option "Force resurvey of Quests here" in ⋮ menu of Places (and Things) Overlay.

If selected (and optionally confirmed?) it would force re-survey of all Quests for that element, i.e. just like that elements was last edited say 20 years ago. [^1]

It would help with things like https://github.com/streetcomplete/StreetComplete/issues/534, https://github.com/streetcomplete/StreetComplete/issues/3918, https://github.com/streetcomplete/StreetComplete/issues/4516, https://github.com/streetcomplete/StreetComplete/discussions/6275, https://github.com/streetcomplete/StreetComplete/issues/6400, https://github.com/Helium314/SCEE/issues/695, etc...

un-preferred alternatives

• Alternatively, if that is too complex/problematic, at least add an option option "Update opening hours" in ⋮ menu of Places Overlay which would trigger re-asking of opening hours, regardless of when it was lastly updated (opening_hours is by far the thing that changes very often and most erratically so can't really be predicted). - but that one was rejected in https://github.com/streetcomplete/StreetComplete/issues/6400

• Even more alternatively: Create specialized "opening hours Overlay" which is just like "Places overlay" but asks for opening_hours instead for name (I know, it sounds like it would be too specialized to me too; but at least it fits the SC model)

[^1]: I lack enough knowledge about SC internals to have any idea how it might be done, but something that would create new quests (to be presented to the user) on that element like e.g. older today -4 years in elementFilter returned true -- regardless of what date it is today actually.

[westnordost]

That would be difficult to implement. StreetComplete could for a bounding box re-check all the quests and assume the date today is 100 years in the future, or somehow always return true for any "is older" checks or manipulate the last edit date of all elements in the given bbox to something well in the past, but that wouldn't be enough. StreetComplete would need to persist for which bounding boxes a resurvey has been forced because after all, the quests should vanish again after a new (auto-)download and also not after solving a quest (which re-checks all quests on that element for eligibility). But when we persist this, how to tell "it's okay, I just answered the quest already"? I.e. any newly re-surveyed quests would then also still pop up as "to be resurveyed". So, maybe there is a solution to these, but right now, I can not think of any that wouldn't have a massive rat tail attached.

[mnalis]

the quests should vanish again after a new (auto-)download

It seems fine to me if that works either way - i.e. it seems fine that manual download would "forget" such quest in the area; and auto-download should not be happening anyway all that often (as the area is downloaded already (or one wouldn't be able to select element from Overlay otherwise). But it is also fine if quest remain until users solves them even if new downloads happen.

What you mention next is however the main problem (IMHO):

and also not after solving a quest (which re-checks all quests on that element for eligibility).

Good point. (Taking into account that I don't know how stuff works internally), would something like this work / be possible to implement in reasonable (not too rodent-y) way?

• all "normally" downloaded Quests get flag shouldFakeDate = false when
• when one chooses "Force resurvey of Quests here" in Things/Places Overlay, Quests are created matching that element get shouldFakeDate = true flag, and are handled as if older today -4 years statements always returned true
• when any quest is answered, that just-solved-quest gets shouldFakeDate = false. Re-check for all quests eligibility (that gets triggered by solving any quest immediately after) takes into account status of shouldFakeDate boolean, and fakes (or not) date on some Quest depending on status of that flag. That should take care so force-resurvey-quest won't pop back up immediately after it was solved, but allows other force-resurvey-quests to remain available
• depending how we want to handle first paragraph; we also either:
  • do not update shouldFakeData on existing quests (so force-resurvey-quests remain until user has solved them all)
  • update shouldFakeDate = false on existing quests only if manual download, but do not update it for auto-download (so manual download "forgets" force-resurvey-quests - probably makes the most sense to me)
  • update shouldFakeDate = false on both manual and automatic downloads (so force-resurvey-quests are really temporary)

[peternewman]

So, maybe there is a solution to these, but right now, I can not think of any that wouldn't have a massive rat tail attached.

As @mnalis sort of suggested, in terms of the data storage, isn't this similar to the hide quest option, another property attached locally to the quest you can set and reset in various ways. Making it independent of the normal resurvey calculations might help too.

[westnordost]

Hm, actually, using the

manipulate the last edit date of all elements in the given bbox to something well in the past

solution, i.e. then persisting this edited data back into the database, it will be retained until the next download is triggered. This does not require any new database tables to keep track of for which elements / bboxes a resurvey-invalidation has been invoked.

So, that would work.

But where to put this in the UI? It is somewhat of an advanced feature. Not sure if placing it just under the download/upload buttons wouldn't be somewhat confusing - "what resurvey? invalidate what? Is this like downloading?" - I could very well imagine that users then routinely click that button thinking that's how to "properly" download an area and then get fed up with this app because there are too many quests.

[mnalis]

But where to put this in the UI? It is somewhat of an advanced feature. Not sure if placing it just under the download/upload buttons wouldn't be somewhat confusing

My original idea was to add a new menu entry in that "three-vertical-dots menu" in Places and Things overlays named "Force resurvey of Quests for this (Place/Thing)", which would create very small bbox matching only that one element (on which it was clicked).

I think that way:

• it would not be confusing to users (as it would be clear that it applies only to that one element, and would not be in-your-face for users just using the app regularly)
• it would only match that one shop/whatever that actually changed (without creating dozens of quests for things visible on the screen, as would happen if one would use bbox the size of the screen)

[westnordost]

Ah, only one thing, hm. But this would have two caveats:

• What if there is no quest currently open for the element for which one wants to force re-survey with all quests?

• If it is e.g. a road, and one answers (again) for surface, then one isn't asked again anymore for e.g. smoothness (unless check_date:smoothness is set) because due to the first update, the last edit date then already has been set to now(). Now, this issue exists also if not limited to just one element, but for one element specifically, the issue is more apparent.

[mnalis]

• What if there is no quest currently open for the element for which one wants to force re-survey with all quests?

You mean, because if there isn't quest being displayed, there is no Uh... menu on the Quest that could be clicked?

That's why I suggested adding the menu entry in three-dots-menu on Overlay, and not on Quest (although it wouldn't hurt to additionally have it in Uh... Quest menu, but it is not required if it is in a Overlay already).

Or did I misunderstood the question?

• If it is e.g. a road, and one answers (again) for surface, then one isn't asked again anymore for e.g. smoothness (unless check_date:smoothness is set) because due to the first update, the last edit date then already has been set to now(). Now, this issue exists also if not limited to just one element, but for one element specifically, the issue is more apparent.

BTW, does that this problem already exist in current codebase for elements that are really (i.e. not faked) old currently?

E.g. if someone really added road a with surface[^1] and smoothness in 2005 (20 years ago), and both quests should be re-asked, would it work with current code? Or would answering surface quest re-survey prevent smoothness quest re-survey? (and does it differ if user has auto-upload disabled or not?)

If that problem already exists, perhaps it should be solved generally, regardless of this enhancement request?

Anyway, for this particular enhancement request: while I'm note sure about how internals work, my idea was to somehow "pretend" like there is check_date:surface=1970-01-01, check_data:smoothness=1970-01-01 etc. for each tag, or have some similar per-quest indication that it needs to be resurveyed.

That way, solving surface would not affect smoothness quest, as it would still be considered for re-survey (as i.e. only check_date:surface=2025-08-26 would be updated to new date, and check_date:smoothness would still be considered "too old"); would it not?

[^1]: note that my idea was primarily about re-survey of nodes (Things/Places), I fully support that it should be supported for ways (e.g. surface/smoothness) and polygons (e.g. buildings). It is just that those seemed more complex (As bbox needs to catch at least two nodes to select a way?), so I did not want to ask for too much. But the issues you mention apply equally to Things/Places.

[westnordost]

That's why I suggested adding the menu entry in three-dots-menu on Overlay

OK, I see.

E.g. if someone really added road a with surface1 and smoothness in 2005 (20 years ago), and both quests should be re-asked, would it work with current code? Or would answering surface quest re-survey prevent smoothness quest re-survey?

Yes, the latter. Not sure if it differs if auto-upload is off. If it differs, it only differs because of some hack.

[westnordost]

Anyway, for this particular enhancement request: while I'm note sure about how internals work, my idea was to somehow "pretend" like there is check_date:surface=1970-01-01, check_data:smoothness=1970-01-01 etc. for each tag, or have some similar per-quest indication that it needs to be resurveyed.

Well, no, that's not possible with the envisioned solution.

---

Also, if there is neither a quest open nor an overlay with which one specifically can edit the element(s) where one suspects the data is outdated, the "Uh..." / ⋮ solution doesn't cut it.

So, what is your use case exactly? Why would you suspect certain data is outdated? What data?

[peternewman]

I'd personally go for more of a "blast radius" type approach, maybe that's a fixed distance around a press and hold on screen, or just the whole visible screen or something.

So, what is your use case exactly? Why would you suspect certain data is outdated? What data?

For example where you can clearly see some data is stale/outdated, e.g. you can see construction work has finished or just personal/local knowledge that an area has been refreshed recently. Or some more concrete examples I've seen recently:

• (back to my kerbs again) you're being asked for say tactile on a "Raised kerb" that clearly isn't
• being asked for sidewalk surfaces when you can see they're also mapped individually
• seeing an ATM has changed brand (again either knowledge or follow on quests e.g. deposit cash)

Some of that you can do in the various layers, but that's a lot of switching through each one to correct things if it looks like a broader change, whereas forcing a resurvey (and then potentially hiding some quests you think have been unnecessarily included) would be better. Other bits, I'm having to raise a note for currently to fix.

In an ideal world it might pre-select the current state too (like a few quests already do) to simplify the processes, but maybe that's a "stretch goal".

[mnalis]

Also, if there is neither a quest open nor an overlay with which one specifically can edit the element(s) where one suspects the data is outdated, the "Uh..." / ⋮ solution doesn't cut it.

While that is true, I do not think it matters much. In between them Places, Things, and Surface Overlays alone cover vast majority of the cases I can even think of - like probably 95%+ of them. For few that are not covered, there is always leaving notes...

So, what is your use case exactly?

From original post: "Most often that is opening_hours changes, but others things change also (e.g. bicycle parking got extended, or that bus stop got a tactile paving freshly installed, or that restaurant added vegan choices due to customer requests, or those steps finally got a ramp etc)."

I'd say opening_hours alone is about 70-80% of my use cases, so even solving just that one would be huge win for me (as opening_hours is rather volatile tag, and current SC resurvey methods do not work well for it[^1]). But if it is possible to use same solution to cover other quite similar cases that would be great.

Why would you suspect certain data is outdated? What data?

For opening_hours, primarily I would suspect it is outdated by two methods:

• I tried to visit a shop/fast food/bank/pharmacy/amenity/etc. that was supposed to be open (usually in area I do not visit), but when I arrived there it was closed. Thus, I know that existing opening hours are incorrect.
• It is an area frequented by me, and I noticed they changed opening hours (because, they are different from what I remember, or they state explicitly that those are effective from xx/yy/zzzz).

The latter method would also apply to other data (e.g. I know that cafe didn't allow smoking and now it does, or that it didn't have AC and now it does etc).

Also, for some data, I might notice it is very new or just being installed -- e.g. new tactile paving or zebra markings or very fresh asphalt (i.e. smoothness quest) usually stand out quite a lot (esp. if under a month or two old). Or I can see that there are fresh new bicycle stands near ones that are obviously older (by their shine/scratches/damages), so it is quite probable they got upgraded (especially with out new pro-bicycle mayor and new campaign for bicycle parkings).

I'd personally go for more of a "blast radius" type approach, maybe that's a fixed distance around a press and hold on screen, or just the whole visible screen or something.

Well, now that we have ability to zoom-in quite a lot that suggestion by @peternewman (make all quests visible on the screen as immediately eligible for re-survey) would likely work for me too (as I could make "blast radius" cover just that one shop, without doing much collateral "damage"). I'd say it's somewhat less ergonomic, but as it does cover additional use cases, it might end up being more functional overall.

[^1]: I guess one might make opening_hours resurvey very short (e.g. every two weeks) to try to make it more up-to-date without extra code, but confirming that they are the same majority of the time would likely become extremely spammy / annoying. Thus the need for changing them user-initiated on-demand (e.g. via three-vertial-dots menu in Places Overlay) instead of regular on-schedule resurvey quests.