meshtastic
WIP: feat: maplibre
MapLibre has near feature parity with Google Maps and actually has some advantages:
MapLibre Exclusive Features:
- Heatmap mode - Density visualization
- Role legend - Shows node role colors
- Offline tile caching - Ambient cache management
- Clustering toggle - Can be disabled
- Clustering actions - radial overlay of nodes for cluster of size <= 8
- Role-based filtering - Filter by device roles
Google Maps Exclusive Features
- Richer info windows - Full NodeChip display with details
- Track point info windows - Position details on track points
Things that I'm shelving for later (in no particular order):
- heatmap will need some touch up
- Reposition node type legend
- Consider moving location button above zoom in/out buttons
- Gut osmdroid
- Gut gmaps after successful fdroid userbase testing
- raster maps
- unsure if precision bits are working as intended. Doesn't smell right
- Node trackpoints enhancements to get parity w/ gmaps
- Lifecycle management improvements
- Better label hiding logic
Will address the missing features in separate PRs. This PR is already way too big, sorry guys
Codecov Report
:x: Patch coverage is 0% with 2219 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 0.51%. Comparing base (f9575a2) to head (7231f7d).
:warning: Report is 3 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #3785 +/- ##
========================================
- Coverage 0.56% 0.51% -0.06%
========================================
Files 381 398 +17
Lines 21733 23919 +2186
Branches 2684 3069 +385
========================================
Hits 122 122
- Misses 21591 23777 +2186
Partials 20 20
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.
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
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).
Also as brought up in conversation - we'll need to better understand the demo tileserver usage or if we need to roll our own, etc.
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
roleis 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 thenodeColor.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 Stylein 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
roleis 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 thenodeColor.
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