Streetcomplete: show new quests immediately after completing one

[andrewharvey]

Use case
When set to manually upload, after completing a quest (eg adding a building number) it should immediately popup the new quest (eg building levels) so that it can be completed while still on site.

Currently after completing the quest no new ones will appear until you upload.

[matkoniecz]

Currently after completing the quest no new ones will appear until you upload.

To be more specific: some quest are downloaded (not all of them).

See https://github.com/westnordost/StreetComplete/issues/1874 would allow to change this

Some additional limitations also apply (addr:housenumber, addr:street, quests requiring other quests to be completed are a bit special)

So it sounds like it is covered by #1874 (though in this case it was REALLY hard to find it, title is not obvious at all)

[andrewharvey]

Looks like #1874 could fix this. I thought at the moment it will run overpass queries for each quest type and generate the quests shown to the user, right now that only shows me "what's the street address" but it should have also found in the background "how many stories is this building", so I would have though that internally street complete knows there are two questions for this location, but is only showing the first one, until it's uploaded. So even without #1874 it seems like this could be improved.

If you want to close it due to #1874 that's fine, was just passing along some feedback here.

[matkoniecz]

it should have also found in the background "how many stories is this building", so I would have though that internally street complete knows there are two questions for this location

Currently StreetComplete scans for quests (circular loading bar around quest icon appears a the bottom during doing this). It happens once there is not enough of valid quests around current location (or in case of a manual scan).

So sometimes such background scan will be run, sometimes not - depends on how many "more important" quests will be found. Also, after solving and uploading answers new quests may be generated for a given object (after upload not after solving is currently happening for technical reasons).

[westnordost]

1874 would not fix this.

Currently after completing the quest no new ones will appear until you upload.

This is not entirely correct. New quests that depend on the quest you solved don't appear before you uploaded your answer. The reason for that has been mentioned in a number of issues, but I'll repeat it here:

In a nutshell: If new quests that depend on another quest are unlocked on solving, not on uploading, this means that StreetComplete needs to retain the downloaded OSM elements in some kind of versioning system. This is probably too complex to implement.

Long version: Quests are generated from applicability to OSM elements. OSM elements in local store however are only created/upated on download and on upload. On solving a quest, the answer is simply stored as a diff and not actually applied to the OSM element until upload. This allows easy automatic conflict solving. (A conflict in OSM occurs if the version number of an element one wants to upload is different from the version number on the OSM server. A conflict can easily be solved automatically if the tags changed do not conflict with the new version of the element.)

If StreetComplete would now start to update the OSM element already on solving the quest in order to generate the unlocked quest(s) on it, this would mean that StreetComplete then holds a prospective version of the OSM element. So, this is just an assumption, that the next version of the OSM element will look like this (the assumption is true if there are no conflicts). But then you solve another quest and another, so we have generated a chain of prospected versions of this OSM element.

So, on upload, we are confronted with the real OSM element again. If the OSM element does not look like we expect it to be, the trouble begins. If the conflict occurs earlier in the chain of prospected versions of an OSM element, this would mean that all following quests that were answered later on that chain are potentially invalid and should be disregarded/dropped if they are. Potentially, because quests that are not actually dependent on a quest solved before on the same element can be applied as normal after the conflict is solved. So, the app would need to detect that somehow.
(Also, think of splitting the way: If someone else split the way, or you split the way, but on upload it turns out that conflicting changes has been made)

Also, as the local OSM element is updated on upload, this would have to be changed somehow because the local element is potentially even newer (because it is a prospected version).
There is also probably more to it that I don't see right now.

I initially wanted to close this issue as will not fix, but having put some thought into it now what would need to be looked at for implementation, I will leave it open. Not because I plan to implement it (because it still seems to introduce too much complexity and I don't have time), but because maybe others would like to put some brain cells into it.

Two thoughts:

• Maybe at the expense of maybe dropping too many quest answers on a conflict, a less complex version of this feature could be implemented
• If a conflict turns out be that another user answered the quest with the same answer, there is no need to trash the answers of the user that depend on this answer

[matkoniecz]

1874 would not fix this.

I think that it would solve some cases, like one mentioned in the report (building levels is not depending on house numbers). But for example solving building type would still not unlock building levels quest.

after completing a quest (eg adding a building number) it should immediately popup the new quest (eg building levels)

[andrewharvey]

Thanks for the response @westnordost, but also I have the same thoughts as @matkoniecz I didn't think building levels would be dependent on knowing the house number, for example.

[westnordost]

Building levels is dependent on the building type. House number is also dependent on the building type. Roof shape is dependent on the building levels.

[andrewharvey]

There's one advantage to the current design, it forces the user to get more exercise by going out to the same area multiple times for each new quest :wink: .

[smichel17]

Maybe at the expense of maybe dropping too many quest answers on a conflict, a less complex version of this feature could be implemented

I think this would make sense. For context, here's a scenario we already deal with:

• I open streetcomplete and scan for quests. It finds a building type quest.
• I don't do anything for 24 hours. In the meantime, @westnordost finds and answers the same quest.
• In offline mode or manual upload, I go and solve the quest, then try to upload it.

I think the way we handle this is by discarding my answer and invalidating my quest cache (⇒ re-scan for quests).

For an initial implementation, I think this would be good enough:

• Keep around a copy of the OSM data to generate follow-up quests offline.
  
  
  
  • Probably involves a data structure like class ModifiedElement(element: Element, pendingChanges: List<Diff>): Element to generate quests without throwing away the individual diffs.
  
  
• Store all answers as a list of diffs in chronological order
• On upload, download the latest OSM data.
• Try to apply each diff, in order. If it does not apply cleanly, discard it and any others that came after.

Later, we could store the diffs in a tree or other dependency graph, be smarter about checking whether conditional quests still apply, etc, but I think it's fine to leave that for later.

---

The main UX challenge I see is that currently, we silently discard answers that conflict. This works because, if an answer conflicts, it means someone else already answered it, so the quest won't show up again. If we allow multiple pending edits for the same element and have to throw away a later one, it becomes possible that we'll have to ask the same question twice. This would be unexpected without context, so we'd want to add a message when that happens to the effect of, "Some quests could not be uploaded because another mapper already answered a related quest. These quests may appear on the map again."

This message would only need to be shown when a quest will re-appear. That is, when:

• Some diffs are thrown away for reasons other than "someone already answered them"
• The quests that generated those diffs still apply to the latest OSM data (this can be determined at the end of uploading)

[westnordost]

On your technical suggestions:

• There is currently no fixed order in which the diffs are applied. Though, the date of solving is saved so it theoretically could
• Saving prospected versions of elements: I would think the easiest way would be to add a flag to the element table whether an element is a prospected version or the last known version from OSM

[rhhsm]

There's one advantage to the current design, it forces the user to get more exercise by going out to the same area multiple times for each new quest 😉 .

True! I'm a new user of Streetcomplete, and use it to get some exercise by walking and helping society at the same time. I do think it's a little frustrating that I have to survey the same area multiple times because not all quests for an area are available offline, such as having found the name of a shop, and coming home, finding a new quest for the opening hours of that shop. Or, finding the house numbers along one side of a street, and then having to go back to that street to find the house numbers on the opposite side of the same street...

[westnordost]

I've read through this issue again and I don't think it is realistic that I'll ever implement this. As said, it would be highly complex. I'll close it.
Of course, others may try to do it, but I think it is not worth it given the complexity and thus potential for possible bugs introduced when compared with the advantage here.

[peternewman]

@westnordost , is there not a simpler part of this that could be implemented with no additional risk, just a UI improvement.

As a user I currently scan for quests and go for a walk, I come across some stairs, currently I:

1. Tap to select the first quest (up direction with my ordering)
2. Answer this quest
3. Tap to select the next quest (handrail)
4. Answer
5. Tap to select the next quest (ramp)
6. Answer
7. Step count (possibly)
8. Answer

Now we've got even more (all?) known possible at one time loaded, can't it work as follows:

1. Tap to select the first quest (up direction with my ordering)
2. Answer this quest
3. Immediately get asked the next quest (handrail)
4. Answer
5. Immediately get asked the next quest (ramp)
6. Answer
7. Step count (possibly)
8. Answer

Etc. I can discard/cancel if I decide I don't want to count steps and it will have stored the other questions.

Being able to swipe sideways between quests on the same pin would be even better.

[westnordost]

This used to be the UI behavior in an earlier version. It didn't work out so well, so I removed it again.

[peternewman]

This used to be the UI behavior in an earlier version. It didn't work out so well, so I removed it again.

Ah, how so didn't it work out? Did people not like the endless stream of quests? Perhaps it could be reintroduced as an optional feature?