We're big fans of Google earth and KML and as a lot of our customers are field engineers and sales, they are too because they can work offline.
Unfortunately a recent Google earth update (>=7.3) appears to have broken offline KMZ functionality, possibly in the name of security, resulting in ugly big red crosses where there used to be beautiful RF coverage layers. This has frustrated lots of our customers so we've produced a workaround for the issue which means you get the full KMZ and not a half-baked KML which looks like KMZ.
Offline KMZ is working again!
Login to your Keyhole Radio KML layer as before only now you must click inside the pop-up balloon to open an external web form where you will get served your KMZ. If you associate this filetype with Google earth it will automatically open (Windows and MacOS). The Tx location in the browser will stay synchronised with Google earth so you can keep the browser open for your entire planning session. You can now save KMZ layers into folders and access them offline like you should be able to.
Broken KMZ files currently in your Google earth will need discarding and re-downloading from your CloudRF archive at https://cloudrf.com/API/archive
A KML is an XML file with hyperlinks to content which requires a network connection for remote content.
A KMZ is an XML file with local content inside a zip archive which works offline.
According to change logs here, the KMZ mangling is referenced in version 18.104.22.16836 ("Some files missing from saved KMZs.") and again in 7.3.0 ("Can't open KMZ files from a path with ".kmz" in it."). Reading between the lines it looks like the developers have made some changes for the worse in KMZ handling as a downloaded local KMZ from CloudRF now opens 'OK' initially but is later saved with remote paths which defeats the purpose of packaging up a portable KMZ.
The client is, surprisingly, re-constructing the paths to content within the KMZ archive with the source domain from where the file was opened in Google earth (eg. cloudrf.com). A KMZ file is supposed to be portable so has no source domain for paths as everything is 'local' within the folder. By doing this, KMZ files are effectively becoming linked KML files and local trusted content is getting ignored in favour of remote hosted content - which does not even exist. For example: cloudrf.com/my_big_offline_overlay.png would not work because the file lives in a users unique directory on the server (../users/1234/...) not in the server webroot.
If this is supposed to be a cross-origin-resource-sharing (CORS) security improvement it is backwards as remote dynamic content is now being loaded instead of trusted local content.
When a KMZ is opened from outside GE everything is ok. The issue occurs when a remote KMZ file is opened inside GE like we, and others, do with GE. In the screenshots below, a KMZ file containing a large ground overlay is opened inside GE. It is then saved as KMZ for offline use. When the KMZ is re-opened something is immediately wrong as the file is only 1.4KB in size. It contains no files - only hyperlinks. The KMZ has become a KML...with broken links. As much use as a chocolate teapot.
"TypeError: undefined is not a function (evaluating 'Math.log10(10)')"
Google earth appears to have suffered a flurry of security updates after a lengthy pause after they announced the Pro version was free in 2016. Hopefully this issue will be fixed soon although based on how long it took them to update to TLS 1.2 we won't hold our breath so have developed an interface outside of Google earth and are open to suggestions for alternative KMZ viewers.