Support KMZ directly as map format, not just as map item.
Locus can already render ground overlay KMZs reasonably well as "map item" on top of existing maps. That works with "foreign" KMZs (eg from Global Mapper) as well as for Locus own creations (form the builtin calibration tool). Problem with this approach is that performance suffers quite a lot with these things, even scrolling gets very slow and jumpy with reasonably sized overlays. I suppose this is because Locus fumbles around with every single included image coordinate during every scroll? That can be quite a lot for a properly set up ground overlay pyramid... at least 50-100 for a typical use case (standard sized topo map sheet in 8000x8000 resolution, pyramided as 1024x1024).
My suggestion is to also support KMZ files directly as a map format, not just as "map item overlay". All the code is already inside Locus somewhere... only the actual loading needs to be tweaked a little... like distribute the ground overlay image pyramid into something that resembles your internal sqlite map structure.
As a result, we
a) could use locus-made maps from the integrated calibration engine directly without major performance loss.
b) have a reasonable interchange format to the professional GIS world that also works for huge maps. Most pro tools (eg GlobalMapper) export KMZ nicely and hassle free.
Obviously, an even more suitable pro format would be ECW of GeoTIFF, but thats another story :-).
I like this idea 
I use Geomixer TilingTools to make .mbtiles from GeoTiff for satellite images. SPOT 6/7 data for example.
But its a good idea about KMZ may be
I use Geomixer TilingTools to make .mbtiles from GeoTiff for satellite images. SPOT 6/7 data for example.
But its a good idea about KMZ may be
+1 because a "map" should be a "map"
...but is Locus able to know the difference between *.kmz item and *.kmz "map"?
+1 because a "map" should be a "map"
...but is Locus able to know the difference between *.kmz item and *.kmz "map"?
Sure... there are tools to convert nearly any map to nearly any other map... globalmapper... gdal... mapc2mapc... etcpp. It would just be nice to have a more common ground somehow. KMZ is quite widespread, also in pro tools. And the code is already present in Locus... it just needs a little "tweaking".
As for kmz-tracks-&-points vs kmz-map, the kmz map loading code would simply ignore anything besides groundoverlays with embedded images.
The difference in performance is flabbergasting: A 16000x8000 kmz (with 1024x1024 pyramid tiles) as map item in Locus is barely usable, even scrolling is super slow and jumpy. But when you convert it to sqlite or rmap beforehand it's nice & fast, just as any other offline map.
Sure... there are tools to convert nearly any map to nearly any other map... globalmapper... gdal... mapc2mapc... etcpp. It would just be nice to have a more common ground somehow. KMZ is quite widespread, also in pro tools. And the code is already present in Locus... it just needs a little "tweaking".
As for kmz-tracks-&-points vs kmz-map, the kmz map loading code would simply ignore anything besides groundoverlays with embedded images.
The difference in performance is flabbergasting: A 16000x8000 kmz (with 1024x1024 pyramid tiles) as map item in Locus is barely usable, even scrolling is super slow and jumpy. But when you convert it to sqlite or rmap beforehand it's nice & fast, just as any other offline map.
Hello guys,
I'm worried I cannot help here. Slowness of KMZ maps is not because of too much code/tasks that needs to be done on background. Almost all processor time consume rendering of images that needs to be calibrated on current background map and current map scale.
Joeloc wrote that all code is already there, but which code? Code that grab tiles from SQLite maps (where are always same tiles 256x256 on exactly defined place)? Code that handle basic maps has nothing to do with more complicated system for KMZ maps.
In next beta version will be one "small" change that maybe helps here a lot, so let me know. Otherwise suggest to use many of mentioned applications and convert maps to any of support map formats.
Hello guys,
I'm worried I cannot help here. Slowness of KMZ maps is not because of too much code/tasks that needs to be done on background. Almost all processor time consume rendering of images that needs to be calibrated on current background map and current map scale.
Joeloc wrote that all code is already there, but which code? Code that grab tiles from SQLite maps (where are always same tiles 256x256 on exactly defined place)? Code that handle basic maps has nothing to do with more complicated system for KMZ maps.
In next beta version will be one "small" change that maybe helps here a lot, so let me know. Otherwise suggest to use many of mentioned applications and convert maps to any of support map formats.
Well... empty base map... kmz file as map item... bingo... map renders nicely, esp with latest betas. So it really is quite obvious that "the code is already there". It's just a matter of some internal bits and bobs and rearranging to support kmz directly as map format. Maybe Locus code us not modular enough?
Because a map is always a map... as somebody else mentioned here. Sure I can convert everything to everything with a PC, but that's besides the point. Locus should really focus more on working standalone, without "real computers" at home. The time will come when nobody bothers with a Windows machine any longer... and that's not too far in the future.
Well... empty base map... kmz file as map item... bingo... map renders nicely, esp with latest betas. So it really is quite obvious that "the code is already there". It's just a matter of some internal bits and bobs and rearranging to support kmz directly as map format. Maybe Locus code us not modular enough?
Because a map is always a map... as somebody else mentioned here. Sure I can convert everything to everything with a PC, but that's besides the point. Locus should really focus more on working standalone, without "real computers" at home. The time will come when nobody bothers with a Windows machine any longer... and that's not too far in the future.
Replies have been locked on this page!