lg_ros_nodes icon indicating copy to clipboard operation
lg_ros_nodes copied to clipboard

Network link support

Open jandro-air opened this issue 5 years ago • 1 comments

Overview: Tori from CBRE Atlanta was interested in the following use case:

Just an idea to streamline how we update our data, so that it never goes stale. Here’s an example of an ideal scenario

- We create a KML file of new office developments in Atlanta
- We create a network link for that file
- We tell an LG scene to use that network link
- We updated the new office developments on our local computer as needed
- LG scene auto updates

This might be far fetched – but was just wondering if there’s a way to leverage GE network link capability with LG.

We know this is not entirely far fetched as Google Earth does allow for remote assets, and whether or not this asset is stored on someone local computer. However, previous testing with @eggyknap using Geoserver showed us that the ability to update network links did not work quite as expected:

Another possibility might be to depend less on WMS. The problem with geoserver and viewysnc slaves was that the slaves are supposed to query geoserver for a specific geographic subset of a layer, which allowed geoserver to change styling or levels of detail as you zoomed in and out. If instead we simply returned the entire data layer every query, and ignored some of the WMS query parameters that the slaves are failing to support, perhaps that would work...

the issue was that the slaves did not query for updates after the initial scene loaded, we had to manually prod the slaves to update. Once they did, they queried the data fine for that instant...

I think if the server ignored the bits of the query that limited the result set to some geographic region, and instead sent back the whole data set at once, then the slaves would be fine. But if we could make it actually work the way it's supposed to, either with cesium or hacked Earth or magic mushrooms or whatever, it would be awesome.

Of course, and this is more of a CMS issue:

So it sounds like Tori's scenario would work fine, though perhaps our better bet would be to make it easy to update the KML normally, so they aren't looking for a way around having to do it.

Either way, if we can decide that there is a definitive way to improve this behavior then I think we should work towards it. For example, I can see a case of live updating KML layers via processing thru Geoserver rather than certain sites loading data with too much metadata and bogging down Earth's performance.

jandro-air avatar Jun 11 '19 18:06 jandro-air