Missing meta data / context in wheelchair quest

[HolgerJeromin]

https://www.openstreetmap.org/node/1423239695

entrance : yes
shop : estate_agent

SC v48.0-alpha1

[westnordost]

This is because shop=estate_agent is not recognized by the iD presets. The iD presets support the much more widely used office=estate_agent instead.

It is mentioned here, too: openstreetmap/id-tagging-schema#529

Currently, iD presets do not know shop=estate_agent at all. There is also no deprecation rule that would suggest to users to "upgrade" to office=estate_agent, probably because shop=estate_agent is not deprecated. I don't know if it is possible to add synonyms to the id presets without promoting its usage and without deprecating them. Maybe with searchable=false?

In any case, this is an upstream issue.

[HolgerJeromin]

If SC knows nothing we should perhaps present the raw (main) tag so the user get a clue that the quest is not for drachenpoint (in the screenshot).
At least for shop=/office= elements.

[westnordost]

No, not making exceptions to not confronting the users with the tags. Drachenpoint is shown as a separate node.

[HolgerJeromin]

Hide the quest because: How should the user be able to answer the quest?

[westnordost]

In #4241 (@Helium314 ) it was changed that this quest is also asked for nameless properties. I guess this was done under the assumption that for every feature asked, a feature name can be found through the id editor presets.

A few quests, like the opening hours quest, explicitly check for whether the object can be named and only show it if that is the case

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/opening_hours/AddOpeningHours.kt

Lines 176 to 182 in 4a8f743

	private fun hasName(tags: Map<String, String>) = hasProperName(tags) || hasFeatureName(tags)
	private fun hasProperName(tags: Map<String, String>): Boolean =
	tags.containsKey("name") || tags.containsKey("brand")
	private fun hasFeatureName(tags: Map<String, String>): Boolean =
	featureDictionaryFuture.get().byTags(tags).isSuggestion(false).find().isNotEmpty()

...but to do that for every (shop-POI) quest would be somewhat expensive to do I think - not to mention the code duplication.

So while the current situation is not favourable (because inconsistent), i.e. some quests are shown even if the feature cannot be referred to by name and some have these checks, the better long term solution is to "simply" improve the id presets to cover more shop types rather than dealing with it in the way as cited above.
Maybe we should (just) return to checking name or brand or name:signed=no for all shop-type quests (and trusting that name:signed=no is only set if it has a feature name as the AddPlaceName quest checks for that and name:signed=no is usually only set by that quest?)

@FloEdelmann @matkoniecz

[matkoniecz]

Maybe we should (just) return to checking name or brand or name:signed=no for all shop-type quests (and trusting that name:signed=no is only set if it has a feature name as the AddPlaceName quest checks for that and name:signed=no is usually only set by that quest?)

That makes sense to me.

For nameless objects answering this quest requires identifying specific objects anyway, so it means that user can answer AddPlaceName

If user failed to answer AddPlaceName and name or brand or name:signed=no is missing it means that either happened:

• no supporting iD presets so skipping it is a good idea to prevent problem like here (and per popular unsupported values of major keys openstreetmap/id-tagging-schema#529 this problem is relatively rare)
• user was unable to answer name quest (so skipping is a good idea)
• user disabled name quest (so not asking complicated questions requiring identifying feature is fine, I guess)

[FloEdelmann]

Checking name or brand or name:signed=no for all shop-type quests (except AddPlaceName, where we check for a iD feature name instead) sounds like a good mitigation to me.

[westnordost]

I'll reopen this ticket so this does not get lost as long as noone created a PR for this yet