Messages

Updated the KMZ -- now it uses only a single column. At least on my Droid² this looks much better. Comments welcome, of course. I leave the "old variant" (previous post) for comparision.

Sure! I just had to leave for work, and my test device has no SIM in it and thus no network, so I cannot continue on this before I'm back home. I will check the new KMZ this evening and, if it looks OK, attach it to the other thread (were I already placed the original one) for everybody to check. If people like it and want more, I'll go over my collection  

concerning the "How to create...": Sure, I can write something down. Question is: There are multiple ways to do that. Easiest ist of course using Google Earth (plus some HTML template for the description), which is what I do. Guess I'll use this way for the Howto (in the appropriate forum section, of course)?

Yepp -- didn't mean to hurry you up   Maybe that could go to some "cleanup" button later. Better think it thoroughly and wait a bit longer than to have to do it twice  :lol:

Thanx a lot! I love this. During the next days I'll play a bit with my KMZ files and see to make some "special Locus versions" out of them. Just reworked the sample I sent you, as it used a 2-column table with the image next to the description, which is not quite optimal to be displayed on a mobile phone (one has to scroll horizontally and vertically). Now I placed the image inside the desc. Need to check this later today...

100% agreed. I'll keep my mind busy to think of an easy approach. Would it e.g. be possible to search the descriptions for the existing images? Just using some pseudo-code here:

Code Select Expand

foreach (image in /data/import/*) {
  SQL(SELECT...WHERE description LIKE '%image%')
  IF no_data_found rm -f image
}
So user could run this routine for a cleanup. Not 100% exact -- but if the image is mentioned nowhere in the desc, the connected POI must have been deleted (but if it is mentioned, it is not sure to be the IMG ref -- except when the SQL is modified correspondingly to match on something like "SRC='%image%'"). Or I have missed some other point where it could have been stored, not sure. It's just a raw idea to maybe keep in mind for later  

I fully agreee as to the Icons: Just small stuff. As for the images: I understand the problem (as I wrote initially, I'm not sure this approach is 100% conform to the standards: It is not mentioned in the API reference. Obviously because it is not directly part of the KML data, but -- as you already pointed out -- the description).

That's why I suggested to save the KML name along. If there'd be a "marker", one had something to check against (e.g. use a "cleanup" button to check for unreferenced images, which is hard to do with the IMG tags from descriptions). So if your other idea (storing the images together with the POI in the database, so there is a direct connection between POI and image -- just for the big ones, of course, as the icons are set for the entire KML and not a single POI) would make things easier (as you don't need to remember the connection), it could be worth a try. But then you had the problem with where the relative URL points to, I guess... which could be solved by placing them into the cache additionally, and have a button somewhere to place them there again in case the cache was purged. Gnaa. Sounds like a huge overhead (at least in size, as this way you need to store the images twice)...

Did you check if any of those is capable of exporting the calibrated map for use with Locus? From the descriptions, it does not look like  

If somebody wants to take a look at the cool new KMZ support:



That's the Test-KMZ menion was writing about he used for testing. Works great. So I will see to convert some of my collections for Locus, as here even embedded images work great, as you can see in the second screenshot (no external links, the images are contained within the KMZ file -- so they are displayed even when offline!).

Thank you very much, menion! I will try that out ASAP.

So how do you suggest to clean up "old images" when POIs are deleted? Because with no such option, the folder may fill up with time proceeding (consider people just importing POIs for vacation, and dropping them lateron, importing new ones for new vacations, and so on).

Maybe the word "cache" is a bit misleading here. The pictures should be saved in the "file system", which does not necessarily mean "temporary" (the database file itself is stored in the file file system as well). Having them stored there instead of in the database may save some overhead (though I'm not sure how much that is), and has the side-effect that you can browse it (and thus the images) with every standard browser to view the images.

The latter. In combination with my first suggestion. So if the user selects to delete all data from the imported KMZ, connected images will be deleted along. Of course you could connect images also directly to each POI if using the database. But placing images into the database would add unnecessary size overhead IMHO.

But as for the connection (between POI/KMZ and images): It could also be that multiple POIs share an image (e.g. with styles for the icon that will probably be the regular case), and the user decides to only delete some POIs. So you will need a kind of "counter" for how often an image is used. If that counter goes to zero, the image is no longer in use and can be deleted.

And accidentally he locked them all and left none open -- that was not intended by menion. So right now, there should be one of them "unlocked" again, AFAIK (at least that's what I understood) -- this one it is: viewtopic.php?f=13&t=377

Now it's our turn to convince him about this feature, which he stated will not be an easy task...

Hm, well, it was just a suggestion. I could e.g. no longer have the file. Or do not want to/know how to edit it (I know how to, but other people might not). So if you are far from your PC, and no longer have the original KML/KMZ files on your device... I think e.g. of a "cleanup" half a year later, when you got everything overfilled and a bit messed up, got used to Locus, and think of better organizing your POIs. Would you remember which file you imported what POIs from after half a year? -- But as said, it's just a suggestion and you are the boss  8-)

As for the second part: Great! I'm looking forward to your next response on this  

Yepp, sorry for that. If you take a look at the time stamp, you see why. Could I know that ik8vwa (the one I quoted) would really go to register here and post his suggestion? Yeah, I recommended that. But usually people answer something like "don't want to register just for 1 question"  

But as you think it's a great idea (so do I) -- better have it mentioned twice than not at all, right?  :lol:

For the first part: Imagine you imported 1.250 POIs from 3 files into 1 category. Now it turns out the POIs of one of those files were crap, and you have to delete 375 POIs. Did I miss anything -- or is the only possibility currently to mark all 375 by picking them manually, and then remove the marked POIs? In that case, wouldn't it be much easier to say "Mark all POIs imported from crap.kml", and then delete them? Or maybe move them to a different category?

About the second (extended KMZ support), you should have mail in your inbox (or the Spam folder, not sure   )

I just picked up a really great idea over in the XDA-Developers Forum which I'd second:

it would be very very useful to have - included in Locus - a tool that allows to calibrate a map. This map could be a map photo taken at the entrance of a park or a .pdf file. Basically I'm asking to the author to introduce the features of another software called Mapcalibrator.
Imagine, you can't find that map online but you have it on paper: you can take a picture, you can scan, you can load the .pdf file or the .jpeg or.tiff and then calibrate it (e.g. eith three points) so to use it.

I'd say it would already be helpful just to support it as JPG, so one could use the built-in cam (maybe even from within Locus), take the picture, and Locus would process it. This would be especially useful in (national) parks and large outdoor museums like e.g. "Ancient City" (a miniatur Thailand built up in Bangkok). They often offer their special maps with special details...