allow to relocate post box and correct collection times

[tommycrock]

Use case relocate postbox and correct collection times (or survey explicitly as okay.

Problem I noticed a post box had incorrect location and collection times in the 'are these collection times still correct' quest. I tried moving the post box; the collection times quest disappeared. I tried answering no, correcting the question time (changing the time but not completing) and then moving the location; upon moving the location the quest completed and did not commit the updated time. https://www.openstreetmap.org/changeset/142477588 (minor point, the changeset comment is a bit misleading when location not collection times were updated).

Proposed Solution Changing location should not mark the collection times quest as completed, whichever way it's accessed. It should function effectively as a separate quest (albeit not available to answer without the other). Changing location should be described as such in the changeset comment. Consider if this is a broader problem with changing location of objects (I didn't check and don't know how the code is structured).

Thanks 👍

[mnalis]

• Probably the same thing reported in https://github.com/streetcomplete/StreetComplete/issues/4746

(the workaround is to disable Uploads answers automatically in settings)

[tommycrock]

Thanks. I should have mentioned, I have automatic uploads disabled (I have to click the upload arrow).

[mnalis]

Thanks. I should have mentioned, I have automatic uploads disabled (I have to click the upload arrow).

Interesting. That workaround still works for me in StreetComplete 54.1 (on Android 10 / EMUI 12), provided the instructions from that issue are followed (i.e. first move the post box, then answer the quest). Which version are you using?

E.g. confirmed just now:

https://github.com/streetcomplete/StreetComplete/assets/156656/436f2cc6-41b4-4df4-94d5-c4923fa8fae4

But I agree that it would be best if the issue was properly fixed for all cases, but that seems not to be easy (see linked issue).

[tommycrock]

I'm also using 54.1. I don't think you were answering a resurvey question there?

[tommycrock]

But I agree that it would be best if the issue was properly fixed for all cases, but that seems not to be easy (see linked issue).

Although it would still be a bit of a workaround, I would expect that if I answered No, then selected It's also in the wrong position, I could change the position, then edit the times, and only then would it commit the answer (just like it allows you to add different times for different days before completing).

[westnordost]

In short, there is nothing we can do about it. (Other than always also setting the check_date:* when tagging resurveyable properties)

The two workarounds for you have been described by @mnalis.

If the particular post box has a check_date:collection_times=<a date> (or similar) tag key set, then it will always work, because then StreetComplete can look at the given date to see if a re-survey is due. If no such tag is set, StreetComplete will fallback to look for the last-edit date of the whole element - moving the element naturally sets the last-edit date to now.

[tommycrock]

Hi, thanks for responding.

The two workarounds for you have been described by @mnalis.

I only see one workaround described (disable uploads), which did not work in my experience and both example videos are of first setting of times not resurvey AFAICT.

If the particular post box has a check_date:collection_times=<a date> (or similar) tag key set, then it will always work, because then StreetComplete can look at the given date to see if a re-survey is due. If no such tag is set, StreetComplete will fallback to look for the last-edit date of the whole element - moving the element naturally sets the last-edit date to now.

I understand that's how it currently works, and can see it would take some effort to rework things only for resurvey, but I think it is possible (in a different way than I suggested in my opening comment). Basically the idea is to incorporate moving the object within the re-survey answer. Workflow is something like:

1. User clicks on resurvey quest.
2. SC asks user if the times are still right.
3. User answers 'No', the times are wrong.
4. SC shows edit times form with more options at the bottom.
5. User selects more options, it's also in the wrong location.
6. User provides the new location which SC retains locally.
7. SC returns to the edit times form.
8. If user completes the edit times form, SC commits times and location as a single change to OSM.

This was what I expected to happen second time around - I undid my change to location and then tried the above but it committed as soon as I entered the location.

[westnordost]

I only see one workaround described (disable uploads), which did not work in my experience and both example videos are of first setting of times not resurvey AFAICT.

The other workaround is to first move the... oh right, then you don't get the other question anymore. Never mind then.

---

From a UI perspective, your suggestion certainly makes sense. But from a technical viewpoint - how internally edits are treated, it is not feasible.

[tommycrock]

Okay, thanks.

[westnordost]

You know, I have long been thinking about doing this:

(Other than always also setting the check_date:* when tagging resurveyable properties)

which would somewhat solve the issue (over time). But I am not sure how this would be received by the community. (Back when I asked about how SC's behaviour should be on the mailinglist three years ago, even @matkoniecz, who otherwise pretty often shares the same opinion as me on many topics argued in favor of how it is now.)

[tommycrock]

Other ideas for a workaround. It seems undesirable that when user has answered no, they can then change the position and the quest disappears. Either this option shouldn't be available after answering no, or it could be changed so it would create a note describing the new location using the same interface. Obviously that's quite a fudge. Another approach would be to look through history for a change to the opening times tag, but presumably that's difficult otherwise you'd have done it to begin with. (edit: wrote this offline and didn't see reply above first).

[westnordost]

Another approach would be to look through history for a change to the opening times tag, but presumably that's difficult otherwise you'd have done it to begin with.

Jup, there is no API for that. I.e. it would require N API calls to fetch each version just for one element.

So anyway, I'll close this as will not fix then.

[tommycrock]

What if you used the date: parameter on overpass turbo and compare current and old opening times? That wouldn't require N API calls. If it happened that the times had changed and changed back again to the same in a short space of time then it would be reasonable to ask the quest and set a check date tag.

[westnordost]

The app does not use overpass to generate the quests. It downloads all data in the bbox and creates the quests locally.