KMZ/KML POI improvements

[Ferretty]

I just played for a few days with the free version of Locus and, amongst others, also imported some POIs from KML/KMZ files. Though that's great stuff, I'd suggest some improvements for this:

Map sources to POIs
As it is now, one imports a KML/KMZ into a category. Multiple sources (i.e. KML/KMZ files in this context) can be imported into one category this way. But if one finds a better source for parts of them, or want to get rid of some for some other reason,, it is "all or nothing": One can either delete all POIs of a category, or none. Or one has to delete each POI separately, which can be quite annoying.

Now, if the source would be stored along (and here I mean the file name), one could remove all POIs of a given filename.

Multiple files in one KMZ
KMZ files are not simply a "zipped KML file". Sure, they can be this -- but they can be much more: One could include icons and images this way. And as Locus supports an offline mode, those additional files could be used along. For example, not only a textual description for a POI (using the KML <description> tag), but, say, a photo of the location, contained in the description using a relative path with an <IMG> tag. And for sure one could use specific icons.

With that, I could provide some of my KMZ files for the POI sources here. If an example KMZ file is needed, just let me know and I will provide it.

[Menion]

Hi,
  I'm not sure if I understand first part. If you import any KML file that contain more points (which can be separated by own styles), you can then in "Point screen", filter, select and delete simply only points you don't want to have ...

  about extended support for KMZ files, some sample file should be welcome (best on email mailto:locus@asamm.cz">locus@asamm.cz), thanks

[Ferretty]

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   )

[Menion]

I don't see any advantage in creating some tool on your first part. Why should I delete these points, when I can fix the file and import and overwrite wrong points? Or I can delete whole category and import only valid data again (it's question of minute). I don't just see anything useful on adding "something that allow delete data based on source of import" ---

thanks, mail receive, I'll look at it during week

[Ferretty]

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  

[estein]

Hi, I'm also very interessted in the "second part" !!!

I'm just planing the vacation with collecting and preparing maps and POIs and so on for offline usage.  
The support of KMZ with integrated images would be a great help!
E.g. campgrounds with text description and a picture copied from the web or "must see places" with description and image as appetizer ...

At the moment a KMZ ist displayed as text but the included image is just an empty border ...  :-(

best regards, estein

[Menion]

hmm I'm just curious, how to handle with image data. Copy then to cache folder or import them directly into database? Hmm ... what would you suggest?

[Ferretty]

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.

[estein]

I would also suggest to import the whole KMZ into the database.
In my understanding a cache is a temporal thing. If I import a KMZ (or POI) into Locus, I would expect the whole data to be safe there.

[Ferretty]

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.

[Menion]

uf, it was much worst then I expect ... testing version is here viewtopic.php?f=25&t=782

system is "easy" if you want to know. I take KMZ file, all images copy into Locus/data/import folder. All kml files are then imported into database. Icons in Style and StyleMap tag are now correctly added to POIs and are taken directly from data/import folder. Same with images included in description in HTML code. I tested it all on file from Ferrentty, so please try any other and let me know how this works. Also count that all images remain in data/import directory even after you delete POI's and in this way it probably remain.

[Ferretty]

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).

[Menion]

it's little bit different to handle these images

there are two types. One are used in Style (Href) tag, so they are needed for poi icons. There is not much problem with them. Just small images (in your case only one small image). I can do something with url to store them. Maybe put them into cache/images directory as other small images.

Second are much worst. Url to some big images is inside "description" tag of every POI and I cannot work with this. System itself determine url from which load images. If url starts with http, that sure (downloading from web - same with geocaching listing), anyway when there is some relative url, it try to load image from local storage. And I define this storage as Locus/data/import folder. And that's all. So to sumarize it - I have no influence on images that are attached in description of POI. I can only place images on place where can be found when needed. And for now it seems for me almost impossible to check for every deleted poi, if there is not some link to relative local storage and some image there, etc.

  Hope you understand. Anyway my suggestion is to simply delete data/import directory sometime. I'm also thinking if not to place this directory into Locus/cache directory but these data are not as temporary as rest of cache directory, so it will rather stay in data folder (to be more permanent)

[Ferretty]

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)...

[Menion]

hmm, main question for me is if the work on this worth it. Actual solution works fine and have only one disadvantage. When you'll do a lot of KMZ (with images) import, you'll have many images in Locus/data/import folder. Question is whether this is really a big disadvantage. I don't think so. Every at least a little experienced user, can delete this directory. Also when I import any data that I worth it, I keep them save for later.

Storing data into database isn't good idea. When you'll have more images in few points, I'll save some data twice. Also url to image is in some description so I'll have to parse description of every point if there isn't any relative path to image ... ehm ... terrible. And this will also affect speed of import.

No sorry, I think that best will be to leave it as is now if all works fine. After few weeks of usage, we'll see if there is need for some improvements and if stored images are really a big problem, posssible?