maplibre: start grouping at a lower zoom level

[vfosnar]

trafficstars

Use case Note: This is probably an upstream SC thing but I used the SCEE pre release so I will post it here for now.

Quests start to group too early and it doesn't feel right. Especially in smaller villages and places with small amount of quests.

SCEE pre release:

SC latest:

*it's possible this behaviour is cased by SCEE having more quests than SC in this case, but the visual comparison still applies for this issue

Proposed Solution Lower the level at which quests start to group.

[mnalis]

• see related https://github.com/streetcomplete/StreetComplete/issues/5835

I'd personally prefer that clustering starts smoothly (i.e. intermixed with regular pins, starting to cluster when several pins are close to each other on that part of the screen, while at the same time on other part of the screen pins remain separate (non-clustered) if they are far apart.

IOW, only cluster on places where needed (as most clustering maps do it AFAICT - e.g. OpenAEDmap or CoinATMradar or whatever)

However, it seems it was at some point decided (for so-far unrecalled reasons) to go with "switch to clustering at fixed zoom level".

And problem with "fixed zoom level" is that it obviously cannot work well for both quest-dense area and for low-quest-density areas.

[Helium314]

I also don't really like the early clustering, at least in areas with low quest density...

@mnalis you could play a little and maybe do a PR to achieve where needed. The relevant code is in https://github.com/Helium314/SCEE/blob/modified/app/src/main/java/de/westnordost/streetcomplete/screens/main/map/components/PinsMapComponent.kt Finding the right places to change zoom levels should be very simple.

[vfosnar]

I currently don't have much time and when I do I work on atpsync, but if I find some time later I can play around with it. In the mean time others can feel free to fix it.

[Helium314]

I'm considering just changing the cluster max zoom for testing, but there are probably a few more alphas available for doing this...

[mnalis]

@mnalis you could play a little and maybe do a PR to achieve where needed.

Thanks for the pointer to the file @Helium314 , but while I could change the trivial fixed constants when it triggers, actually implementing the dynamic clustering (what I meant there: i.e. actually clustering only on one the part of the screen and not on the other) seems like way above my capabilities :man_shrugging: [^1]

For others interested, note that upstream SC maintainer stated that:

I don't recall exactly the reason(s) why we ended up with this, whether there were technical difficulties or whether it just didn't feel right mixing clusters with pins, but rest assured we tested it out already and compared different alternatives. I am not willing to change this for the time being. (Which is why I am closing this issue as WNF)

so unless @Helium314 or someone can recall / find out why it was decided that way, and find persuasive counterarguments, it could be problematic even if there is someone willing to do the programming.

[^1]: I don't even have a clear idea on how object oriented programing languages work in reality, much less know how to actually program in Kotlin... my programming is mostly all functional programming, with most advanced language I can fluently program in being perl5, from back when it was still most popular scripting language. So all my Kotlin has been copy/paste, replacing strings, interpreting error messages, some guessing, and hoping for the best :smile:

[westnordost]

I'm considering just changing the cluster max zoom for testing, but there are probably a few more alphas available for doing this...

If this test turns out to feel better, could go into SC, too.

[mcliquid]

I've changed the CLUSTER_MAX_ZOOM value from 14 to 16 and it works really well for me.

[vfosnar]

at least in areas with low quest density...

after trying the pre-release for 2 days in my city this feels unusable even in high density areas :)

[mnalis]

I was wondering, how does clustering work for people in recent release (SCEE 60.1)? Is it better now, or do you still think it needs improving? @vfosnar ?

I can add a user-settable preference so people can change CLUSTER_MAX_ZOOM to some other values if people think it would help (e.g. like @mcliquid indicated 16 fits them better) ?

[vfosnar]

It's fine for me now, but 16 may be even better

[rusty-snake]

For me it is fine. If you're going to change it, I would recommended to make it the same value as overlay display.

[mnalis]

OK, as it seems to work fine for you guys now with recent versions; I'll close this issue as solved then.

While SCEE is not so preference-averse as upstream StreetComplete, I hope I won't be amiss to say it still prefers less code differences to maintain; so unless some preference would really bring benefit to at least some subset of SCEE users, it should IMHO not really be added just so "it might be nice to have it there". (it creates both the clutter and increases the maintainability effort, so those disadvantages should be weighted against the benefits it brings)

If you guys have a need in the future for such tunable option, issue can be reopened, of course!