Locus Map - forum

Support => Wishlist => Implemented => Topic started by: joeloc on December 05, 2011, 20:43:11

Title: mapItems folder in general
Post by: joeloc on December 05, 2011, 20:43:11
I very much like the idea of a folder that holds typical "overlay" data. We can put stuff like hiking trail networks there without cluttering our main databases.

Tracks from a file in mapItems/trailnetwork.gpx display nicely, except the missing name. I can also click them and edit their data. But how about an option to "copy" the selected track over to the main database?

A word about speed: Locus seems to slow down quite a bit when displaying multiple tracks. Have you considered creating "stripped down" track data while preparing a track for display? Like reducing point count by 50% a few times? Depending on current zoom level and track coverage area, you could then use one of those reduced point lists for display. No need to loop through a thousand points when they translate to only twenty pixels on screen.
Title: Re: mapItems folder in general
Post by: Menion on December 05, 2011, 21:27:56
good point joe. thanks to your topic here viewtopic.php?f=13&t=1379 (http://forum.asamm.cz/viewtopic.php?f=13&t=1379), I was playing for a long time with track display system and new speed is around 20% faster then before. Anyway main problem is drawing path with a lot of points and this solution should help a lot. I'll try to implement this in some way .. so nice tip, thanks ...
Title: Re: mapItems folder in general
Post by: joeloc on December 05, 2011, 22:50:22
Did you experiment with R-Trees (http://http://en.wikipedia.org/wiki/R-tree) as well? They're quite a funky way to store geospatial data. Might be worth a read.

Maybe not so useful for single track rendering, but good for organizing a few hundred tracks and tens of thousands of waypoints. Even with that many items, you could find out what is on screen in just a few processor cycles.
Title: Re: mapItems folder in general
Post by: Menion on December 06, 2011, 21:46:47
thanks Joe, I'll look at. Good inspiration, but for this, I firstly need to add support for OpenGL. Main current limit is draw speed of icons so this is not yet needed ...