Cluster tap behavior is a bit unexpected:

* Google Maps version - at higher zoom levels, tapping a cluster will zoom to a bounding box containing the items in that cluster. Allowing the user to drill down. Only at the lowest zoom levels, and/or if nodes are broadcasting the same level of precision will a dialog/list of the nodes be shown.

* maplibre version - at all zoom levels, tapping a cluster will display a dialog/list/web of the nodes contained within

Due to the smaller location dots, it would be nice if clustering would stay off when selected as such and between page changes.

The introduction of an indication of role is a good idea and I'm open to exploring how to expose it, however for the sake of identifiable consistincy we should be coloring the pins as the nodeColor.

Also a bit conflicted about showing the nodeid as the identifier/label on the pin, in other places the node is identified by color and shortname (the node chip).

yes, short name would be better. I do like colour coded roles but it is inconsistent withe previous layout so makes sense to use the proper node derived colour.

Heatmap.. did not seem functional (or I do not have enough heat 🥶 )...

Heat map works for me but i personally dont think its needed. If it stays though, that's fine.

Is there a way to know/restrict the min zoomlevel for tilesets? I'd like to prevent this if we can. I was using the satellite Map Style in the below instance.

Yes there is, I can do this pretty easily. Will add to todo list.

Cluster tap behavior is a bit unexpected:

* Google Maps version - at higher zoom levels, tapping a cluster will zoom to a bounding box containing the items in that cluster. Allowing the user to drill down. Only at the lowest zoom levels, and/or if nodes are broadcasting the same level of precision will a dialog/list of the nodes be shown.

* maplibre version - at all zoom levels, tapping a cluster will display a dialog/list/web of the nodes contained within

Will do this as well

The introduction of an indication of role is a good idea and I'm open to exploring how to expose it, however for the sake of identifiable consistincy we should be coloring the pins as the nodeColor.

I agree that role colors diverge from present UI, however on a node map I do feel like the ability to differentiate role types at a quick glance is very useful. I could add a toggle to cycle between nodeColor and role colors?

Also a bit conflicted about showing the nodeid as the identifier/label on the pin, in other places the node is identified by color and shortname (the node chip).

As discussed in discord, this is only for emojis and is unfortunately a constraint of MapLibre. I have found a blog post with a potential solution that I can try to implement. If after a few iterations on this and potentially other solutions, I could fall back to node long name instead of hex ID. Would that suffice?

Regarding heatmap - very much a WIP that I can remove. It's definitely broken as it lies

LOVE THIS!! I was looking for a fork of code that doesn't use any google services! Was looking into using OSM instead but maplibre looks great from the screenshots you've posted!

LOVE THIS!! I was looking for a fork of code that doesn't use any google services! Was looking into using OSM instead but maplibre looks great from the screenshots you've posted!

There already exists the Fdroid flavor which contains OSM and no Play services/analytics etc. You can get it on fdroid, izzydroid, obtanium, the github release, etc.

This would be to replace the deprecated/archived osmdroid sdk as it will no longer be updated.

Oh lmao

Heyo, theres a lot of issues this PR would resolve. Whats the state of this? Is it mostly ready to merge, only needing to be synced with the main branch, or are there must-have changes left which need to happen before its ready to merge?

Heyo, theres a lot of issues this PR would resolve. Whats the state of this? Is it mostly ready to merge, only needing to be synced with the main branch, or are there must-have changes left which need to happen before its ready to merge?

Heyo, this is way out of date and would probably be better off re-written, the app architecture has shifted quite a bit. The current author seems to have moved on from the project, and this is lower on the priority list.

Feel free to pick it up and dust it off 👍

outdated, stale.

Huh, allright.

In that case, could you please re-open every issue that was pre-emptively closed because it would be solved with this PR? A lot of issues with map display are now marked as solved/wontfix, and would need to be recreated to showcase the need for a new map renderer.

Huh, allright.

In that case, could you please re-open every issue that was pre-emptively closed because it would be solved with this PR? A lot of issues with map display are now marked as solved/wontfix, and would need to be recreated to showcase the need for a new map renderer.

nah we're good - this shows the history fine.