Allow seeing all POI types in Things overlay

[FloEdelmann]

Use case As mentioned in https://github.com/streetcomplete/StreetComplete/issues/5614#issuecomment-2094577913 by @Tex2002ans and also by someone I know in person, it is helpful to know all the things you can map with the Things overlay, or at least more than the few top ones. This is especially the case if you are not that deep into OSM yet.

Currently, when adding a new POI via the Things overlay, only the top 9 POI types are shown by default in the search features dialog. When entering a single letter, only the first few POI types starting with that letter are shown, sorted by usage count(?).

Proposed Solution Might be a combination of these:

1. Show more than the top 9 POI types by default.
2. Add a "view all" button below the default top 9 POI types. The list would then become scrollable. Maybe there are too many POI types though.
3. When entering a single letter, show all POI types starting with that letter, not just the first few ones.
4. When entering a search query, show results containing the search query below the results starting with the search query, so more results are shown.

Note: There might be technical/performance limitations of showing more POI types that I am not aware of.

[mnalis]

I agree. SCEE already seems to do that (via scrollable list), and I don't see a disadvantage (if the user doesn't decide to scroll, it looks mostly the same as it does currently in SC).

Cutting the list as some arbitrary point seems counterintuitive to me and might confuse users (who might think that there are no other matches). Unless there are some significant performance issues, I don't see the issue with displaying the full list.

[westnordost]

Hm, not sure why it is limited. Of course, the more types you show by default, self-evidently the less useful this list is going to be. So, there must be a limit defined somewhere.

Anyway, you did not explain what's the use case for wanting to know all the things you can map with the overlay, and why it would be a good thing.

sorted by usage count(?)

It's more complex than that. Usage count is actually not taken into account (could be a useful sort order criteria later as a tie-breaker), but how well it matches by the input term.

[matkoniecz]

Anyway, you did not explain what's the use case for wanting to know all the things you can map with the overlay, and why it would be a good thing.

It may educate people about what is possible to be mapped

[Tex2002ans]

It may educate people about what is possible to be mapped

Yes, exactly! :)

Being able to scan through a list of labels/categories (or more easily search) should help discoverability.

---

One example, I was scanning the map on OpenStreetMap.org and saw someone marked flags.

Sure enough, when I was in StreetComplete's Things and typed in:

• Flag

the actual "Flagpole" item showed up as a Thing I could add!

(I have since added a handful as I spot them. Usually find them in front of a fire department or government building.)

---

Similar with the different types of playground equipment.

They currently appear as:

OSM Tag	StreetComplete's "Thing" Menu
playground=slide	Slide
playground=seesaw	Seesaw
playground=swing	Swing
playground=springy	Spring Rider
playground=playhouse	Play House
playground=bridge	Play Bridge
playground=tunnel_tube	Play Tunnel
playground=sandpit	Play Sandbox
playground=structure	Play Structure
playground=roundabout	Play Roundabout
playground=splash_pad	Play Splash Pad
playground=balancebeam	Play Balance Beam
playground=sledding	Play Sledding Hill
playground=climbingwall	Play Climbing Wall
playground=activitypanel	Play Activity Panel
playground=climbingframe	Play Climbing Frame
playground=horizontal_bar	Play Horizontal Bar
playground=archimedes_screw	Play Water Pump/Screw

---

Note 1: In US English, the “Play Roundabout” should be labeled:

• Merry-go-round

Note 2: For ease-of-search, instead of "Play", maybe these can be labeled:

• Playground: Horizontal Bar
• Playground: Balance Beam

so if a user typed in:

• Play or Playground

a list of all these possible objects would all appear together.

---

Complete Side Note: It reminds me a lot of Skyrim mods that consistently rename all item labels so they sort/categorize+alphabetize properly. Like one example:

• Skyrim Nexus: "Valdacil's Item Sorting"

They took the default list of item names like:

• Arrows
• Bask
• Bolts
• Fire Arrows
• Fireball
• Inferno
• Lost Legends
• Thief of Virtue

and converted into:

• [Ammo] Arrows
• [Ammo] Bolts
• [Ammo] Fire Arrows
• [Book] Thief of Virtue
• [Spell] Bask
• [Spell] Fireball
• [Spell] Inferno
• [Quest] Lost Legends

They labeled the category in brackets so all the Ammo/Armors/Books/Spells/Weapons would all stick together.

(Of course, this type of thing should be "baked into" the game's built-in categorization... but localizers/modders had to work within the game's limitations!)

StreetComplete's UI can handle these categories much cleaner... Perhaps if a subcategory like "Playground" exists, make it a nice colored label next to the name or something like that. :)

[matkoniecz]

We are taking names and matching them to tags from https://github.com/openstreetmap/id-tagging-schema (including translations)

This type of sorting would be beyond what is intended but note 1 would be applicable if that term is outright wrong.

[Tex2002ans]

[...] but note 1 would be applicable if that term is outright wrong.

In the US, we call these things "merry-go-rounds".

Absolutely nobody here would ever know what the heck a "roundabout" even is.

(In US English, the term "roundabout" would potentially apply to the roadway going in a big circle. But definitely NOT the kid's playground equipment!)

We are taking names and matching them to tags from https://github.com/openstreetmap/id-tagging-schema (including translations)

Thanks for the info. Now I have even more reading to toss on the reading list. :)

[westnordost]

Anyway, you did not explain what's the use case for wanting to know all the things you can map with the overlay, and why it would be a good thing.

It may educate people about what is possible to be mapped

Being able to scan through a list of labels/categories (or more easily search) should help discoverability.

I am not sure if this is a good thing. People already do see what's around them. And if they spot something they themselves find worthwhile to record, they will search to add it in the overlay (and if it is not available, complain about it on the issue tracker, so that it may get added later as a preset).

If people are able to see all-the-things, they might feel compelled or at least encouraged to not leave anything out when mapping. OSM newbies who maybe would be interested in such a "complete list" may be quickly overwhelmed by it, not only in the sense that mapping all the things may result in too much to do and thus fatigue, but also in the sense that they begin to question the sense why certain things are apparently promoted to be recorded at all (*cough* *cough* manhole covers *cough* *cough*).

Unlike OSM regulars, newbies don't know that due to the ever-increasing possible detail (through continuous proposals and mapper ideas), there can't ever be a "complete" list or "complete" map because the scope keeps expanding. I.e. they did not internalize rule#1 of OSM (which, for me, arises from that thought process): Have fun, and map what you find important to have on the map.

So, for me, it should remain the individual choice of the mapper to choose what they deem worthwhile to record, i.e. the initiative to add these things should come from the mapper himself, rather than from looking at a list of what's all - currently - possible.

Apart from this general thought process, it would of course mean quite some implementation effort to show "all the things" properly - in a categorized fashion. I.e. mirror the behavior of the iD editor (the editor on osm.org website).

---

Now, @Tex2002ans , the source translation of the mentioned id-tagging-schema is actually American English. If the current American English name does not match your expectation as an American, then this should be corrected (by posting a PR at the linked repository). Note that as far as I remember, all those playground presets were added by a German, so as a non-native speaker, he may not have found the proper American English terms for all the things. It is also possible to add aliases (alternative names) and terms (keywords for search) to presets to make them better discoverable. So the merry-go-arounds could at least be added as alternative names.

[mnalis]

If people are able to see all-the-things, they might feel compelled or at least encouraged to not leave anything out when mapping

• I personally don't think so (at least not for majority of the users - hey it doesn't even affect me, and while I generally seem susceptible to such things, I haven't had an urge to map a single storm drain yet even I heard of its iD preset), but even if true, it would only address points 1. and 2. from the original proposal. Perhaps (if you still won't budge?) add a header "Top 9 popular things to map" to the top of the table clarify things to the user that we won't take their preferences/recent usage into consideration but just worldwide stats?

• regarding 3. I think having arbitrary cutoff there is just confusing. If it is intentional (i.e. we absolutely want to avoid scrolling list there), at least the list should end with "additional 67 result hidden" or some other indication to user of such cutoff. (as noted, I'd personally prefer the scrolling list, but just mention this as an alternative if that is unacceptable)

• regarding 4., I think if the user explicitly searches for hole they should be shown manhole (among other things), even if we don't see why the people would want to search for that. I've never seen so many strange hobbies until I've seen taginfo. But hey, that is what makes OSM great, it allows people to map what interests them, and not what "big brother Google" has decided is best for them. And that is the definition of fun/hobby. I mean, if people are explicitly searching for something valid, and SC knows about it but is intentionally trying to hide that thing from them "for their own good" would to me seem to promote frustration instead of fun.

it would of course mean quite some implementation effort to show "all the things" properly

I don't seem to have much need (nor does this issue seems to call for) such "proper" implementation. As I noted above, SCEE approach "just filter the flat list by the text user entered" works good enough.

So the merry-go-arounds could at least be added as alternative names.

id-tagging-schema already seem to be using merry-go-round as an alias, and for two different things (playground=roundabout and attraction=carousel), and SC does show them when searching (although it only shows main tag name, not the thing it matched the search for, which seems somewhat confusing - I've opened https://github.com/streetcomplete/StreetComplete/issues/5636 for that)

[westnordost]

Anyway, I'll close this as will not fix. Removing the arbitrary max-number-of-items display limit takes as little effort as removing the .take(50) in SearchFeaturesDialog.

I did remove it to test it out, but scrolling down an endless list when typing "a"... to find the preset one is searching for doesn't make sense to me. I.e. it is much faster and easier to just continue typing. (Feel free to test it out yourself.)

For the use case of using that search dialog as a list of all the presets, see my earlier comment.

[mnalis]

Would adding some text like "Top 9 popular things to map" at the top of that list or "(more results hidden)" at the bottom be sensible, though?

It should IMHO reduce user confusion at least (by not misleading them by omission that there are no more matching tags)