Flexible handling for KML network resources

[thw0rted]

I asked about this in #873 and was told to start a new issue, so: I'm trying to improve our Google Earth compatibility. We have users on Google Earth Pro 7.1 and 7.3, and both have an infuriating feature -- the default Placemark icon set uses links like http://maps.google.com/mapfiles/kml/shapes/placemark_circle.png. That would be fine, except if the machine is not on the internet... Google Earth Pro still happily fills in the correct image! They must have an internal pre-fetched representation of the default icons and silently use those instead of looking for the actual file online.

What does this have to do with Cesium? Well, there are a number of compatibility / interoperability features on the roadmap that specifically cater to the Google "flavor" of KML. Ideally, this "feature" (ugh) of Google Earth could also be replicated, so that our Cesium-based viewer can open KML/KMZ exported from GE. I haven't looked into how licensing would work with the Google-provided images, but they might map nicely to pre-existing pins in the default set Cesium already has.

More generally, maybe we could pass a function (or Proxy?) to the KMLDataSource that is allowed to rewrite resource URIs before they're requested from the network? This would be more work -- for the above use case, we'd have to grab and host copies of the default icon set somewhere on our server -- but it would also be helpful in other situations, for example, we have internal services that provide the "base" KML file over HTTPS but include NetworkLinks over HTTP, which quietly fails in modern browsers.

I realize this is sort of two related requests, but I wanted feedback on which solution (overriding specific image paths to emulate Google Earth Client behavior, versus a generic API for rewriting network resource requests) would be preferred by the team.

[tfili]

@thw0rted thanks for writing the issue.

The generic solution of providing a callback to rewrite external url before a request would probably be the best solution here. This solution has been discussed as a good way to imlement KML models as well. Since KMLs contain COLLADA and Cesium doesn't natively support that format, you could replace it with a gltf url before the request.

I don't currently have any bandwidth to work on this, but PRs are encouraged if you want to take a stab at it.

[thw0rted]

I think the big Resource overhaul in the last version may have accidentally solved this issue. It's wrong in the docs (might have been fixed in one of the recent updates you made last week?) but KmlDataSource.load takes a sourceUri option that can be a Resource (not just a string), which is used as context for loading additional content. If I provide a Resource with a blank string for the url and a proxy property that conditionally rewrites request targets, that's basically the callback in question.

I've only played with it for a few minutes just now, but it's a good lead and I think it'll be a flexible tool for solving this issue. I don't think Resource was intended to be used with a blank URL like this, so it's a bit of a hack -- you'd probably know better than I if it's going to have unforeseen consequences. I started out playing with passing the top level data argument as a custom Resource subclass that overrides getDerivedResource, since that gets copied to sourceUri if none is specified. I gave up when I realized that if I'm loading KML from a blob or Document I wouldn't have that opportunity, since I'm not passing a Resource to the data argument at all. If you have any feedback on how to approach this, it would be most welcome.

[thw0rted]

Circling back to this almost exactly 3 years later. I found a really great reference with the built-in icons for the Google Earth client and a description of how they work. I don't know if it would be desirable to implement this level of special-case handling in Cesium itself, but we'll probably try to add at least some amount of magic in our own application.