frustration with running to the same places over and over again

[v4hn]

I recently started using this app and love the idea.
Thank you so much for your work on it!

As someone who is willing to report a lot in some detail about their local environment, I wanted to report my ongoing frustration with the (almost) fully automated decision which quests are available.

To be precise, multiple times by now, I walked down roads without internet access on the phone (and cached quests) and solved quests, e.g., opening hours.
Some minutes later, when I am quite far away from the place already, suddenly another quest pops up for the very same location, e.g., vegetarian meals?.

Sometimes I walk back to check for this too, sometimes I don't care.
But why didn't the app ask me about it when I was still standing there?

Is this a deliberate developer decision and users are supposed to fill in only some mappable information as they go?
I guess asking multiple questions almost ad infinitum for nodes really close to each other is quite frustrating too.
Would it make sense to let the user force more close-by quests if available, maybe through another option similar to "Scan for quests here"?

[matkoniecz]

Is this a deliberate developer decision and users are supposed to fill in only some mappable information as they go?

No, ideally it would be possible to do everything in one go. There are some existing issues, typically result of technical limitations. Some of them are hard to solve. Some impossible to solve (or, to be more specific, so hard to solve that are solvable only in theory).

---

I suspect that what happened here is that on upload new quests may be unlocked (it is done on upload for reasons described in #1352 (comment) ).

But maybe it would be possible to check whatever multiple quests apply on download. Reasons described in linked comment would not apply, as no quest would need to assume that other ones will apply without conflict.

So instead of

1. Downloading opening hours quest
2. Adding amenity=restaurant name=Foobar opening hours quest
3. User solving quest
4. App uploading quest solution (maybe later)
5. App discovering that vegetarian quest also applies after upload
6. App adding vegetarian quest

It would go like this

1. Downloading opening hours quest
2. Adding amenity=restaurant name=Foobar opening hours quest
3. Adding amenity=restaurant name=Foobar vegetarian quest, as it also fits
4. User solving quest
5. App immediately showing vegetarian quest
6. App uploading quest(s) solution(s) (maybe later)

So it sounds like something "requires multiple hours to test and implement", but not "requires weeks/months of work" level of complexity.

EDIT: note

however I have strong doubts about the performance effect it has when downloading elements for a quest type. It means to run the eligibility checks for every single element downloaded for every single active quest. I think that is too much.

in #1510 (comment)

---

frustration

Goal of this app is to be as easy to use as possible, so in case of something flustrating you may assume that it was not something intentionally evil.

[westnordost]

It is some of both - technical limitation and the way the app is designed. Though, mostly a technical limitation, actually.

The quests you see on the map are not downloaded from a third-party server. There is no third-party server. The quests are actually generated on your smartphone while the app analyses the OpenStreetMap data at your location.
Now, due to technical reasons, the app analyses the data quest type-by-quest type*. For example, first the opening hours, then some time later the vegetarian meals.
Generating all the quests for an area in one go is not possible, because it would take a long time, would consume a lot of traffic (MB transferred) and finally also store an unreasonable amount of data on the phone. Remember: The app does not download the quests, but the OpenStreetMap data, generates and stores locally the quests generated out of it, plus the data associated with the quests, so that the app can be used offline.
So this is why the app does only automatically download as many quest types until a certain quest density in your vicinity is reached.

The deliberate design decision part is that the app is actually designed to be used for casual contributors of the OpenStreetMap who want to contribute a bit while being on the go. So, for this use case, just having some quests to solve around is fine. There were previous complaints like yours about this behaviour and maybe the app should be more open to use cases of mappers who want to solve everything in one go. But while the technical limitation is there, it is not worth discussing about it. And this technical limitation is very unlikely to go, ever, for this app.

* If you are interested to know: StreetComplete uses the Overpass API to access OpenStreetMap data, an API that makes it possible to selectively download only certain features of the map (for example, all restaurants with no opening hours). The standard OpenStreetMap API only allows to download everything within a certain area, which would generate an unacceptable download volume for being on mobile data connection.

[matkoniecz]

which would generate an unacceptable download volume for being on mobile data connection.

And even in case of succesfull downloading (via WIFI or good mobile data) the phone would consume far too much of CPU time (draining battery) to process it. And it is likely that such processing would run into memory problems.

[v4hn]

Thank you for the awfully fast, detailed answers!

As discussed, there are at least two independent scenarios that both trigger the same frustrating end-user behavior:

1. Quests can trigger independently from one another for the same object (e.g., opening times? / vegetarian meals?)
2. Quests conditionally depend on other unevaluated answers (Levels? -> Roof Shape?)

Just to clear up some confusion on my side: I'm not perfectly sure, but seem to recall observing this behavior when offline. Doesn't this contradict your explanations?
What exactly does the cache consist of?

If the behavior only appears online, I do see all the arguments.
Assuming offline usage of the tool with cached quests is more of a side-effect due to the implementation than a target usage you wish to develop, everything is fine as-is.
As offline usage can be rather frustrating though, when you run through the same places over and over again adding one more detail on each run, it might be worth the trouble to look into ways to enhance support for multiple quests per location as proposed by @matkoniecz and also via locally-applied patches.

I don't know the code base, but fully understand that nobody has the enthusiasm to refine these when there are even additional constraints outside the app (typed quest queries).

[HolgerJeromin]

Right now every quest defines IIRC an own overpass query.
Perhaps we should rethink that:
Some quests needs the same objects. So query:
all restaurant with
no Opening hours
or no veggie
or no vegan
or...

All streets with
no lit
or no sidewalk
or no maxspeed
or...

And generate out of this data two times three quests on the device.

That way we could probably reduce the overpass calls and fill more quests with one call.

[matkoniecz]

but seem to recall observing this behavior when offline. Doesn't this contradict your explanations?

No, see #1352 (comment)

Some things like unlocking additional quests are done on upload. Offline means that uploads are not happening, so in this case unlocking is delayed until upload happens.

[rugk]

Right now every quest defines IIRC an own overpass query.
Perhaps we should rethink that

Theoretically I like the idea.
Though it is of course hard refactoring/would change many assumptions here, but could e.g. also drastically improve performance.
Another technical note: To do this effectively, maybe it should not be hardcoded, but you'd need a "middle layer" that takes the overpass queries of all elements and finds these best combinations/overlaps in data, then generates one new query locally, does it and locally generates the new quests out of this data.
Again, this is likely very hard, as some queries are complex, so effectively you would need something like the Overpass data selection/query processing system locally. (maybe there is a lib or so though? People often do offline OSM analysis AFAIK.)

[HolgerJeromin]

@westnordost Should we move this idea to another issue?

Another technical note: To do this effectively, maybe it should not be hardcoded, but you'd need a "middle layer" that takes the overpass queries of all elements and finds these best combinations/overlaps in data, then generates one new query locally, does it and locally generates the new quests out of this data.

Exactly. IMO this needs an own "description language" which describes the "needs" of every quest in an abstract way. As a JSON example

{
	"type": [
		"linear",
		"area",
		"node"
	],
	"target": [
		{
			"key": "highway",
			"values": [
				"service",
				"primary"
			]
		},
		{
			"key": "public_transport",
			"values": [
				"platform"
			]
		}
	],
	"conditions": [
		{
			"type": "not",
			"key": "lit"
		}
	]
}````

[westnordost]

No, it will not be done (like you propose) because it makes definition of new quest types too complex while the performance benefit is unknown: Note that any Overpass Query with an "or" is like two queries.

If it will be done, then like @matkoniecz suggested, which would be quite liw on effort technically, however I have strong doubts about the performance effect it has when downloading elements for a quest type. It means to run the eligibility checks for every single element downloaded for every single active quest. I think that is too much.

At the moment it makes much more sense to work on performance improvements when firing out the Overpass queries, so that the app does not reach the quota that quickly.

[v4hn]

I have strong doubts about the performance effect it has when downloading elements for a quest type. It means to run the eligibility checks for every single element downloaded for every single active quest. I think that is too much.

From the previous discussions and documentation it seems to me there is a clear partial ordering defined between different quest types which determines the order in which the quests are presented to the user - in some cases based on conditional answers (paved surface -> lit) (2.), in others based on quest priority (opening hours has a higher priority than vegetarian meals) (1.).
Aside from the required efforts to implement it, would it make sense to make this ordering explicit to factorize such required checks through this ordering?
This would avoid running unnecessary checks.
For example, I could imagine a simple representation

*opening hours* BEFORE *vegetarian meals*
*pavement* CONDITIONALLY BEFORE *street lit*
...

This would not be used for overpass queries, but could help to show all quests for a node in one go.

To make full use of such a representation it would of course be best to support incremental local patches, but this is quite out of scope here.

[westnordost]

I'm not sure what you mean, @v4hn. The quest priority decides what is shown in front of what and what is downloaded first, what later. You can change this order in the settings.

What could be done if it is implemented like @matkoniecz suggested, is, that quest applicability for each downloaded element is only checked for the current quest being downloaded + every quest with lower quest priority. So, downloading the whole quest type list is only n! * e instead of n² * e applicability checks (n = quest type count, e = average number of elements downloaded). (And currently it is n * e)

[matkoniecz]

To reduce performance issues at cost of additional complexity - maybe define groups of quests where element downloaded may also create other quests?

For example "list of quests for restaurants" that would include AddPlaceName, AddOpeningHours, AddVegetarian, AddVegan etc.

This way elements downloaded with AddOpeningHours would be checked for eligibility for AddVegetarian quest, but not for eligibility for AddBenchBackrest.

[v4hn]

only `n! * e` instead of `n² * e` (And currently it is `n * e`)

I was trying to make a similar argument, though even more fine-grained. (also I was not aware that quest types can be reordered locally) You were concerned about the quadratic computational runtime complexity. Of course this can be reduced by checking only later quests. If this suffices, that's the best solution and it would be great to see it upstream! As a downside of this approach, I guess, most usage might still end up with unnecessary computational overhead because the first few queries will still check *all* later categories and your `e` is biased towards the first checked categories. I though about reducing this even more by avoiding trivially independent checks altogether. After all there is no reason to check a restaurant building for being a bike stand. If quests would explicitly relate to each other, only modelled ordering relations would need to be evaluated when downloading for any quest type. In practice, afaics, you would end up with a small constant factor `c * n * e`, where `c` is the maximum number of quest types potentially applicable to any other quest candidate. My question was whether something along these lines would be useful or put too much additional complexity in there. (Of course, if you want to extract such relations *automatically*, you end up with a whole different level of complexity)

[westnordost]

reduce performance issues at cost of additional complexity

Preliminary performance optimization (at cost of additional complexity) is never a good idea.

As said, we already have a several places where we can start working on that the download of quests goes more smoothly - first and foremost, the overpass query generation. If we still have problems later, let's revaluate this.

Can we reach to this conclusion here? If yes, I would like @v4hn to close this issue and open another one, describing the discussed solution - for clarity, because this thread got quite long and will be time consuming to process what should actually be done when (if) the time comes that it is implemented.

[westnordost]

See #1514

[westnordost]

#1514 is done now, so the root of the problem reported here should be somewhat mitigated.

[v4hn]

#1514 is done now, so the root of the problem reported here should be somewhat mitigated.

As far as I can see the linked quest improved query response times quite a lot, that's awesome.
But the discussed solution for my original reported issue, that would also work with offline usage, was to check all downloaded objects for applicability with all active later quest types.

Should I create a new issue for such a mechanism?

[westnordost]

Yes, please do that. Or, you wait for v14 and see if this is really needed in your opinion. Cause, the suggested solution has an obvious downside - more complexity and most of all, more work for the cpu on the phone. Before it can be implemented, one would need to check how much of a performance impact it would actually be, and then decide if it is worth it. Am 29. August 2019 13:11:41 MESZ schrieb "Michael Görner" <notifications@github.com>:

…

> #1514 is done now, so the root of the problem reported here should be somewhat mitigated. As far as I can see the linked quest improved query response times quite a lot, that's awesome. But the discussed solution for my original reported issue, that would also work with offline usage, was to check all downloaded objects for applicability with all active later quest types. Should I create a new issue for such a mechanism?

[matkoniecz]

A different person opened #1550 that covers this.