Network KML: relative hrefs and bounding boxes

atomic dryad shared this problem 10 years ago
Known

When attempting to load

http://mw2.google.com/mw-earth-vectordb/gallery_layers/network_links/google_earth_community/google_earth_community_en.kml, or

http://earthobservatory.nasa.gov/Feeds/GoogleEarth/eo.kml, or

http://mw2.google.com/mw-earth-vectordb/dynamic/everytrail/en/root.kmz

There are two critical issues;


* Locus's kml implementation doesn't seem to apply the parent KML's base href to relative URLs loaded via network links. The above KML has a network link to

http://mw1.google.com:80/mw-earth-vectordb/gecommunity/14/root.kmz

This document in turn which has network links to: <href>03.kmz</href>, <href>02.kmz</href>, etc, which should be interpreted as

http://mw1.google.com:80/mw-earth-vectordb/gecommunity/14/03.kmz, etc.

However, it uses the temporary directory as a base:

E/UtilsHttp(16755): java.lang.IllegalArgumentException: URI is not absolute: /mnt/sdcard/Locus/data/import/b267fcb509kmz/03.kmz


Should the above be corrected:

* Please add implementation for regional bounding boxes (<Region><LatLonAltBox>...) for <NetworkLink>. As is, locus will pull all networklinks.

E/UtilsHttp(16755): java.lang.IllegalArgumentException: URI is not absolute: /mnt/sdcard/Locus/data/import/b267fcb509kmz/03.kmz

E/UtilsHttp(16755): java.lang.IllegalArgumentException: URI is not absolute: /mnt/sdcard/Locus/data/import/b267fcb509kmz/02.kmz

E/UtilsHttp(16755): java.lang.IllegalArgumentException: URI is not absolute: /mnt/sdcard/Locus/data/import/b267fcb509kmz/01.kmz

E/UtilsHttp(16755): java.lang.IllegalArgumentException: URI is not absolute: /mnt/sdcard/Locus/data/import/b267fcb509kmz/00.kmz


This is critical; root.kmz is the base of a global quadtree, which involves recursive loading of networklinks. For some of these kmls there's literally millions of child .kmz's, but only the correct quad needs to be fetched. For example (a ~2km wide zoom to Rabaul):

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/03.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/032.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/0322.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/03221.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/032212.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/0322122.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/03221220.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/032212200.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/0322122001.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/03221220011.kmz

http://mw1.google.com/mw-earth-vectordb/gecommunity/14/032212200112.kmz

Replies (2)

photo
1

Good day,


I may confirm both issues. I was trying to fix at least first one, but unfortunately due to system I use in Locus it's currently not so simple. Locus during import convert all KML objects into separate objects and do not keep whole hierarchy in memory. So it's not possible to get information about parents.


I spend on it almost two hours, but it's just no possible now. It require complete rewrite of handling of KML content in memory. Which is partially planned on June due to some requirements.


So for now, I have to leave this issue un-fixed, sorry

photo
1

Glad to hear improvements are planned in this area!


One idea (I've not looked at the underlying code mind you); perhaps you could avoid a total rewrite, and the need to cache in memory if the function that saves unpacked/network .kml rewrote the links before writing to /sdcard/Locus/cache? (similar to wget's -k option)


I've fitzed with libkml when writing a superoverlay downloader...it handles everything in memory and that becomes a problem even on desktops. There's alot of network .kml trees that will lead to OOM

Leave a Comment
 
Attach a file