[Feature Request] Allow adjustment of concurrently visible trails on map

[janreppien]

In its current implementation there seems to be a fixed number of trails simultaneously visible on the map.
While there might be performance implications, it would be very helpful to be able to manually adjust the number visible tracks on a client by client basis.

Feel free to ignore the following section

To remedy the performance problems, one could use an approach similar to Komoot mobile app, which when zoomed out simplifies the track by lowering the “resolution” of the track depending on zoom level. They seem to have a number x tied to the zoom level and only each x's point of the track is used for displaying the track.

[Flomp]

Thanks for the suggestion. This has been on my roadmap indeed. I would like for it to group trails into a marker with a number on higher zoom levels and only show the actual trails once you zoom in more. Something like this:

[janreppien]

Thanks for your quick answer. I can see how this would eliminate the potential performance issues. I like to use wanderer to store all my previously finished trails and then use it to find places I haven't been to. Especially for longer bike rides upwards of 100 kilometers, this implementation might make it harder to use wanderer for this since only their stating point would be visible.

[jo-chemla]

The sota way to solve this seem to be relying on cloud-native geospatial standard for vector datasets, something like protomaps/pmtiles which is a single-file, vector tile compressed dataset, with js viewers and libraries available for eg leaflet, maplibre and loadersgl/deckgl. That last deckgl example shows how quick it is to load a massive vector polylines dataset based on that pmtiles vector tiles standard.

Building that pmtiles dataset can be done via tippecanoe or gdal ogr2ogr like shown on this protomaps doc. One tricky things to consider is that implementation has to decide whether pmtiles tilesets has to be produced (periodically or on track creation)

• for all public tracks, oen file
• for the user-owned tracks, one file per user
• and/or for every tracks a user has view-access to, one file per user, updated on track creation or view property update