Slippy maps/Tiles slow Locus startup
Any operation on Locus that involves refreshing the offline maps takes a number of minutes for me, because I have lots of files in a tilesource folder.
Could Locus decide that a folder is a tilesource sooner and give up searching that folder for any other types of maps? I assume this is what the hold-up is?
Also, it would be helpful to know why Locus behaves differently on startup depending on which map was last used. If I exited with a tilesource/slippy map as the current map, Locus starts very quickly, but then has a very long delay when I click the map selection button (I presume this is refreshing the offline maps).
However, if the last map I used was a vector map, there is a very long delay each time I start Locus, but no delay at the map selection screen.
Cheers,
N
The same problem 
Good day Goosien,
sorry for a delay in response. Is Locus still slow when comes to display list of maps or a start of app? From what you wrote, it looks like main problem are vector maps. It takes a long time to start app when vector map should be loaded as base map, but no delay with other types of maps. Also access to map manager seems to depend on fact, that any vector map was already used (fast access) or not (vector maps needs to initialize, so slow access).
I did some changes in loading of vector maps in 3.16.+ version of Locus, so let me know if it's better now.
Btw. what device are you using? What vector maps are you using and you wrote "lots of files", so about how much maps we talk here? Even if this number should be close to 100 in case of vector maps, it should not take longer then around 1-2 secs to initialize them all.
Good day Goosien,
sorry for a delay in response. Is Locus still slow when comes to display list of maps or a start of app? From what you wrote, it looks like main problem are vector maps. It takes a long time to start app when vector map should be loaded as base map, but no delay with other types of maps. Also access to map manager seems to depend on fact, that any vector map was already used (fast access) or not (vector maps needs to initialize, so slow access).
I did some changes in loading of vector maps in 3.16.+ version of Locus, so let me know if it's better now.
Btw. what device are you using? What vector maps are you using and you wrote "lots of files", so about how much maps we talk here? Even if this number should be close to 100 in case of vector maps, it should not take longer then around 1-2 secs to initialize them all.
Thanks for looking at this.
Moto E 1st gen, droid 5.1
Just tried updating the vector map- Great Britain from Openandromaps- and this hasn't changed the problem.
I'm certain it is related to slippy maps, because when I rename the parent folder for the slippy map, so it can't be found, Locus starts instantly. When I rename it back, it behaves slowly as originally described.
However slowly the startup or map selection screen may be, all other use of the app, for either maps, remains pretty speedy.
I only have the one vector map, but the slippy map folder contains 83k files in 1k folders, totalling 4GB.
Cheers
On 20 April 2016 09:10:03 BST, Locus Map <locus.map@asamm.com> wrote:
Thanks for looking at this.
Moto E 1st gen, droid 5.1
Just tried updating the vector map- Great Britain from Openandromaps- and this hasn't changed the problem.
I'm certain it is related to slippy maps, because when I rename the parent folder for the slippy map, so it can't be found, Locus starts instantly. When I rename it back, it behaves slowly as originally described.
However slowly the startup or map selection screen may be, all other use of the app, for either maps, remains pretty speedy.
I only have the one vector map, but the slippy map folder contains 83k files in 1k folders, totalling 4GB.
Cheers
On 20 April 2016 09:10:03 BST, Locus Map <locus.map@asamm.com> wrote:
Hmm wait, I was probably stupid reading. We are here talking about simple image files in a directories - this is what you call "slippy maps". Now I've got it!
Well yes, it is quite possible that it works as you wrote. I never tested this type of maps with such huge number of tiles. Is it possible for you to pack this huge number of tiles into one zip file and share it for example over Dropbox or any other service? Because to precisely measure where is a problem and do some optimizations, I need to have exactly same problem on own device. Thank you
Hmm wait, I was probably stupid reading. We are here talking about simple image files in a directories - this is what you call "slippy maps". Now I've got it!
Well yes, it is quite possible that it works as you wrote. I never tested this type of maps with such huge number of tiles. Is it possible for you to pack this huge number of tiles into one zip file and share it for example over Dropbox or any other service? Because to precisely measure where is a problem and do some optimizations, I need to have exactly same problem on own device. Thank you
Sorry I haven't had chance to do this yet.
On 20 April 2016 at 20:55, Locus Map <locus.map@asamm.com> wrote:
Sorry I haven't had chance to do this yet.
On 20 April 2016 at 20:55, Locus Map <locus.map@asamm.com> wrote:
Good day Goosien,
as I'm not simply able to simulate this problem, I'm closing it for now. If something change, feel free to continue here.
Anyway I really suggest to use SQLite based maps of vector maps for a huge areas. These plain tiles (slippy maps) are really crazy system that simply has to be slow for a huge numbers of tiles. Thanks for understanding.
Good day Goosien,
as I'm not simply able to simulate this problem, I'm closing it for now. If something change, feel free to continue here.
Anyway I really suggest to use SQLite based maps of vector maps for a huge areas. These plain tiles (slippy maps) are really crazy system that simply has to be slow for a huge numbers of tiles. Thanks for understanding.
Replies have been locked on this page!