Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support locking quests (changes made using StreetComplete sometimes should remove active quests) #746

Closed
matkoniecz opened this issue Jan 2, 2018 · 8 comments

Comments

@matkoniecz
Copy link
Member

Currently SC handles situation where solving a quest may unlock new ones ( https://github.com/westnordost/StreetComplete/blob/3f327ca1a70d2663c9363e4022bdfdad6d9ad5bc/app/src/main/java/de/westnordost/streetcomplete/data/osm/OsmQuestUnlocker.java )

Cases where solving one quests disables others are unhandled.

Such situation never happens with current quests but I noticed problem with my custom ones (I created boolean quest that asks whatever there is any bicycle infrastructure, after adding cycleway:both=no standard StreetComplete quest asking about cycleways still appears).

I am not sure is functionality supporting this is considered as desirable in StreetComplete (and that is assuming that somebody will make a PR) as currently it is not affecting any SC quests.

@westnordost
Copy link
Member

This would probably be problematic to implement because not all quests can determine whether an element now appliesTo it just by looking at that element - some more complex ones also need to look at other elements (with Overpass query) . The QuestUnlocker however works offline, not with Overpass. If a quest cannot determine whether it applies to an element (i.e. by the way, the cycleway quest), it returns false in appliesTo.
If that would lead to the quest being disabled, the cycleway quests wouldn't be displayed at all.

@matkoniecz
Copy link
Member Author

If that would lead to the quest being disabled, the cycleway quests wouldn't be displayed at all.

Yes, without some additional changes bikeway quest would be listed only if at time of quest download it was quest with the highest priority for a given element.

This probably may be solved by splitting querries into "tag filter" and "geometry filter". So in case of quest that always return false in appliesTo disable quest if tag filter started to fail as result of applying other quests.

But it is additional logic that currently would not be used.

It still would not be feasible to check offline whatever geometry filter started to fail.

@westnordost
Copy link
Member

It still would not be feasible to check offline whatever geometry filter started to fail.

The geometry is also not saved offline. I.e. the "use sidepath" cycleways are not saved for offline, only used once to filter out streets that have cycleways drawn on a separate path.

@westnordost
Copy link
Member

So, I do neither have a solution for this, nor have the necessity to implement something like that. I'll mark this as question and close this.

@westnordost
Copy link
Member

Due to the work done in 15d1e90, this should be easier now. But it will not work for "complex" quest types (that return null in isApplicableTo).

Care to implement it?

@matkoniecz
Copy link
Member Author

It would require making special function with separate query that would be capable of detecting that quest is now supposed to be disabled.

So for example bikeway quest would have both the current overpass query and a new separate query checking only tags (with code for querries at least partially shared to avoid duplication). Would it be OK?

@westnordost
Copy link
Member

No, that would not be ok. As I said, the "locking quests" feature would not work for quest types that return null in isApplicableTo.

matkoniecz added a commit to matkoniecz/Zazolc that referenced this issue Feb 3, 2018
@matkoniecz matkoniecz changed the title support locking quests support locking quests (changes made using StreetComplete sometimes should remove active quests) Jul 11, 2018
@westnordost
Copy link
Member

Closing this in favor of #1131

westnordost added a commit that referenced this issue Jul 25, 2018
after upload, remove unanswered quests that are no longer applicable (#1131, #746)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants