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

Show most (recently) used POI types by default in Things overlay #5622

Open
FloEdelmann opened this issue May 7, 2024 · 11 comments
Open

Show most (recently) used POI types by default in Things overlay #5622

FloEdelmann opened this issue May 7, 2024 · 11 comments

Comments

@FloEdelmann
Copy link
Member

Note: This is partly related to #5621, which suggests other improvements to the POI type selection dialog.

Use case
I often map street cabinets, which are not in the top 9 POI types displayed by default when adding a new POI in the Things overlay. Thus, I always have to search for the feature explicitly, which is cumbersome.

I know that not everyone is interested in street cabinets though (but some might be into guideposts, memorials, etc.), so there is no selection that fits everyone.

Proposed Solution
The POI types that I have most recently selected should be displayed above the top 9 POI types shown by default. We already have the LastPickedValuesStore's mostCommonWithin util for this; the parameters can be tweaked. Without having it tried out yet, I'd suggest target = 3, historyCount = 15, first = 1.

@mnalis
Copy link
Member

mnalis commented May 8, 2024

👍 - I was actually assuming that was the case (but I use mostly SCEE and that list definitely seems to be changing depending on the usage there)

@Helium314

This comment was marked as off-topic.

@westnordost
Copy link
Member

This is a deliberate omission.

Having most recently selected surfaces at the top makes sense, because if one path has a rock surface, it is very much more likely that the adjacent path will also have a rock surface, etc.

Having most recently selected building levels and roof shapes easily selectable makes sense, because the building heights in one area tend to be similar.

Having the most recently selected cycleway situation easily selectable makes sense because if for a stretch of road, a particular cycleway infrastructure situation exists, it is very likely that the same exists for the adjacent sections.


For POIs, especially the "things", it is arguably the other way round. When the user just mapped a hydrant or a street cabinet, it somewhat reduces the chance for another POI of this type to be in the immediate vicinity.
So, it does not appear to me to be a useful mechanism to put whatever at the top of the list that the user just selected. I recognize the use case of users wanting to specifically always add certain things that are not mapped (at all) yet in his area, but the lastPicketValuesStore seems to be the wrong instrument for that.

@matkoniecz
Copy link
Member

For POIs, especially the "things", it is arguably the other way round. When the user just mapped a hydrant or a street cabinet, it somewhat reduces the chance for another POI of this type to be in the immediate vicinity.

Maybe it would be applicable if many mappers map some narrow subset of all things? So for example someone mapping only advertising features* would end with such features for easy selection.

*I know about such person though they do not use SC, they later check which are legal and report illegal for removal

@FloEdelmann
Copy link
Member Author

FloEdelmann commented May 10, 2024

In already well-mapped areas, most POI types will either already be well-mapped, or not at all. E.g. nearly all benches are already mapped in my vicinity, but street cabinets were almost completely missing before I started mapping them.

@matkoniecz
Copy link
Member

Also, in some cases I actually map the same thing in row. For example if I map needleleaved tree it is actually fairly likely that next one will be the same object type.

@westnordost
Copy link
Member

Yeah, but often it is not. So, the last picked values store is not the suitable mechanism for that.

One mechanism that comes to mind would be the (TBD) ability to manually pin certain presets to the top. But I am not sure how an obvious and intuitive UI for that would need to look like. (I.e. that both makes it clear to the user that this is possible but also does not clutter the view with a lot of pin-buttons)

@westnordost
Copy link
Member

westnordost commented May 15, 2024

Maybe show an outlined clickable pin icon to the end of the feature. (Either within the box or outside the box as illustrated. Not sure what would be more clear)

imagen

and when tapping on it, it becomes filled and will be shown at the top of the default things. This would avoid this clickable pin icon to be shown on every list item in the search.

@mnalis
Copy link
Member

mnalis commented May 22, 2024

(Either within the box or outside the box as illustrated. Not sure what would be more clear)

That might work!

On the outside seems more reasonable to me; I do not like the practice of overloading dropdown list with extra clickable elements inside it (I expect that I will get dropdown no matter where I click inside it, and consider anything inside it just a description/decoration, not as different actionable UI elements).

@hmartink
Copy link

Just as a data point: I would appreciate either mechanism as well. I'm often mapping with another mapper and we look for different things and as matkoniecz said we notice different missing things in a certain area, e.g. I look for fire hydrants and raised hides (which I know the other mapper is not looking for), while the other mapper checks all benches and waste bins. Having the most recent ones or pinning some would be helpful.

@RubenKelevra
Copy link
Contributor

I tend to use this feature a lot in SCEE actually. So just a couple of items is usually enough to cover my usage. I think I got 5-6 items I often add.

So a MRU list would be appreciated.

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

7 participants