House Type quest: also allow caching "residential" and other more generic types

[mnalis]

Use case

User wants to solve important house address quests, but is blocked by first having to solve less important building type quest (see #2464 for background).

However, precise solving of building type quest can be time consuming (eg. is it house / detached / semi-detached / apartments / ... - see #3558 (reply in thread)). Some users are also quite allergic to giving potentially wrong answers (myself included). Thus, such user would choose easy way out and select easier, more generic answer like residential (or commercial etc). This works, and user can then happily proceed to solve house address quests (which is the thing that s/he wanted to do in the first place).

However, when such more generic answer as residential is selected, the result is not cached in recent answers (as it is for more precise answers like detached), so for each next building user again has to repeat more complex multi-step-process of selecting residential, instead of just selecting it from the recents list. This gets annoying very fast, which is unwanted, and a heavy price to pay for such a small difference between marking building as residential vs. semi-detached.

Proposed Solution
Allow residential and other more-generic building types to also be cached. Thus, users who use it would not get penalized. @smichel17 volunteered to do it, if that would be accepted.

(Alternatively, problem could be avoided by allowing users that manually turn off building type quest to solve house address quests; but that has already been discussed at #2464)

[westnordost]

Hm, I guess that'd be okay. Though, there still needs to be the warning that if possible you should select a more specific value every time one selects that generic value.

Also, if this is about the housenumber quest, soon(ish) there will be a special view with which you can contribute housenumbers more efficiently.

[smichel17]

@mnalis Do you want to wait until the new house number view is available and see if that alleviates your concerns? Or would you still want this, regardless?

[mnalis]

@smichel17 Yes, this would still be useful whenever solving building type quest.

The new address quest view, if successful, would only allow me to choose when to solve building type quest (e.g. solve it only when I am bored / in area which is mostly solved otherwise; and skip it when I'm in "only have time for really useful stuff" mode). But when choosing to solving them, all the issues mentioned above remain, so it would be great if more-generic building types could be cached too.

[smichel17]

Well, I must admit, that did not work the way I expected 😆

The simple fix does indeed make 'Residential' appear in the recent items… but still as an expandable category!

I could try to fix this. However, that would involve mucking with the layout. At that point, I wonder if it would be a better use of time to just implement #3387. @mnalis If #3387 were implemented, would this feature still be (as) useful?

[mnalis]

Oh well, I though that would be simpler, as I seem to recall it worked that way some time ago... It likely changed too much in the meantime.

I liked that #3387 (comment) idea too.

If #3387 were implemented, would this feature still be (as) useful?

If the residential were normally cached (eg. same as detached) there: yes, that would be even better solution @smichel17!

[westnordost]

I also gave it a shot. To solve that the residential building is shown as a category in the top items, I added .map { Item2(it.value, it.image, it.title, it.description) } to getInitialItems() in order to remove the sub-items from that item so that it is not displayed as a group. This however means that StreetComplete of course no longer recognizes this as a group and thus does not display the "warning that if possible you should select a more specific value".

So, given that the other ticket mentioned was already implemented, I do no think it is worth investing (more) time and complexity into somehow marking items as a "category but not really a category right here".

[mnalis]

Interesting, that would work for me just fine (but not globally for everyone, of course), but I'm unable to find right place to put that .map { Item2(it.value, it.image, it.title, it.description) } inside getInitialItems()... 😢
Do you still have a branch you worked on, or could give a hint?

[westnordost]

No, don't have a branch. After mostCommonWithin.