This object is in archive! 

Display of many tracks - improvements

Tapio shared this idea 14 months ago


can you put some thought into enabling Locus to display a big amount of tracks? If you display 1000s...

Use case: I have a complete movement profile of myself from the last 4 years. If I display all of them (>3000 tracks), Locus gets unresponsive and/or crashes. Usually it CTDs.

Ideas for solution.

a) Maybe there is something that can be done, like just displaying them, then unloading? Some simplification... They do not need to be operable. No need to be touchable or track details come up.

Special formatting like arrows can be left out.

b) Embedded waypoints, start and endpoints: They should not be displayed in such a scenario!

I think, b) is something we can profit from in a "where have I already been" scenario, where we e. g. display all our hiking tours. Say, 100 tracks. If just the tracks would be displayed without any WP, we could perfectly plan new routes between those.

To sum it up: A great option would be "Simplify track display, if more than <n> tracks are displayed" (with n user definable)

Happy new year to ASAMM staff

Replies (3)


I also have folders with over 4000 tracks. But they are only trail sections with max. 1 to 2 km length.
If I display the whole folder it also takes a few minutes (although it goes much faster since a few weeks).
A crash I have never had.
Currently I use the sorting by distance and let me display only the first 100 or 100.


Start and end points would be quite good. I also need a special formatting.

With me it's mostly KML and contains a link to trailforks. The name I would also like to see when tapping. Therefore a usability is necessary with me.


Hi guys,

this is quite unique problem I believe. It should not be too often to display such a huge amount of tracks. What device do you have? Because most probably there will be a problem with the memory so it may be device-specific.

To display the track on the map, I need to load the full geometry. Loading only simplified version, require saving such simplified version in the database as well, so quite a lot of work.

This is generally quite a complex task that simply requires major rework and testing. I hope this won't be necessary to do, cause more important tasks lay ahead. If more people will be interested in improved loading of such a huge amount of tracks, let me know here and I may spend on it some time. At least check where a major slowdown is. Thanks for understanding.


I understand that - Menion may you consider at least to give b) a priority? Which is not about super many tracks or performance, but track visibility and clutter when e.g. we display like 100 tracks in one area.

What? -> Don't display the embedded waypoints and start/endpoints
Why? -> Many tracks are displayed - one may just want to see the tracks to plan around ("Where have I already been") - WPs and start/endpoints are distracting.

Use case: Planning new tracks while being able to check where I've already been. All those dots are distracting (especially when tracks have many embedded WP)


Display of start/end waypoints may be set in the app settings > Track start/end icons. Other waypoints will be unaffected, right.

Replies have been locked on this page!