EndPointCorp / lg_ros_nodes

A ROS software stack for running Liquid Galaxy applications
https://liquidgalaxy.endpoint.com/
Apache License 2.0
19 stars 5 forks source link

Network link support #402

Open jandro-air opened 5 years ago

jandro-air commented 5 years ago

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.

eggyknap commented 5 years ago

Even if we made the CMS so it would automagically update things from a user's system, without any interaction or maintenance or worry on their part, it wouldn't change the fact that it would be very nice to be able to use something like Geoserver. There are certainly opportunities already out there to use data that's not easily constructed into static KML. WMS and the behavior NetworkLinks are supposed to exhibit is a very straightforward solution to problems of overly complex data, for instance, where regionation happens automatically.