Force Globe to "re-tile" an ImageryLayer without hiding/showing the layer?

[Nathan Schulte]

I'm working with a SingleTileImageProvider to render an image within a
specified Rectangle, and I'd like to have the Scene update the rendering
if the Rectangle changes.

At the moment, I see I can effect this by toggling the ImageryLayer's
show property, which as far as I can tell is only causing the
ImageryLayerCollection's layerShownOrHidden Event to be raised.
Subsequently, the GlobeSurfaceTileProvider (private class of Globe, used
in conjunction with the QuadtreePrimitive for rendering by the engine)
is listening to this event and either removes or adds tiles accordingly.

Manually raising the layerShownOrHidden Event for the layer in question
doesn't quite work; it appears the Globe (GlobeSurfaceTileProvider)
expects a layer's visibility to always toggle from this event (not stay
the same) and produces strange behavior otherwise.

Manually raising the Event twice (toggling forth and then back) does
work, and is the solution I'm moving forward with for the time being.
I've attached a Sandcastle export of a simple demo of this (forgive any
Knockout abuse; I'm not familiar with the framework specifics) if anyone
wants to play.

Is this approach kosher (manually raising these events at "random"
during a render loop)? Further, does it make sense for an
ImageryProvider to be "dynamic" in this sense (its content)? I see no
API supporting this idea, which makes me believe it's going "against the
grain" so to speak. The idea seems reasonable for the
SingleTileImageryProvider (where the entire provider is "defined by the
client"); thinking about e.g. WMS/ArcGIS ImageryProviders (or other
providers that adapt a web/remote service), this may make sense if they
support HTTP caching headers. I'm unsure of a good approach to signal
this automatically without much network overhead. Maybe a periodic
level 0 request, depending on what type of HTTP caching support is in use?

Thoughts?

Thanks!

--
Nate

[Hannah Pinkos]

Hello Nate,

I think it would be better for you to use a Rectangle entity instead of a tile imagery provider for what you're trying to accomplish.  This will automatically update the coordinates by using a CallbackProperty.  Here is an example on how to do this:

var viewer = new Cesium.Viewer('cesiumContainer');

var imageryLayers = viewer.imageryLayers;

var viewModel = {

    west: -115,

    south: 38,

    east: -107,

    north: 40,

    show: true

};

Cesium.knockout.track(viewModel);

var toolbar = document.getElementById('toolbar');

Cesium.knockout.applyBindings(viewModel, toolbar);

function rectangleCoordinates(){

    return  Cesium.Rectangle.fromDegrees(viewModel.west, viewModel.south, viewModel.east, viewModel.north);

}

var rectangle = viewer.entities.add({

    rectangle : {

        coordinates : new Cesium.CallbackProperty(rectangleCoordinates, false),

        material : new Cesium.ImageMaterialProperty({

            image: '../images/Cesium_Logo_overlay.png'

        })

    }

});

Right now this will crash if the north value is less than the south, but you could add an if statement in the callback function to swap the values if they're flipped.

Hope this helps,

-Hannah 

[Nathan Schulte]

On 07/17/2015 01:12 PM, Hannah Pinkos wrote:
> Hello Nate,
>

> I think it would be better for you to use a Rectangle.

Hi Hannah,

Using the Primitive API (or Entity API) is another solution I'm
evaluating, so thanks for the example. I decided to try the
ImageryLayer approach mainly due to the accuracy it provides with
respect to rendering the Globe with perturbed terrain (that is, a
non-uniform/non-zero TerrainProvider: anything but the default
EllipsoidTerrainProvider with the same ellipsoid as the Globe). As
well, the ability to change how this object is visualized with respect
to other layers is a win.

As it turns out, the ImageryLayer approach won't work for my needs as
I'd like to be parameterize the rotation of the image, and supporting
this via the SingleTimeImageProvider (or really, any of the
ImageryProviders, as they're all based around the tiled abstraction)
would be an uphill battle. It's simply not meant for this.

Beyond supporting my needs, I'm still curious what anyone makes of the
ideas proposed regarding the static nature of
ImageryProvider/ImageryLayer. Further, given my comments above, I'm
curious about non-tiled ImageryProvider adaptations and how far down the
rendering stack the ImageryProviders-are-tiled assumption is baked.

I'd like to keep this thread focused on those two ideas, but I do have a
question about the Primitive API and zero-altitude primitives. I know
that the current implementation doesn't support perturbed terrain very
well / at all, but what about uniform/zero terrain? From my
experiments, even this visualization breaks down when you get up close.
Is this due to e.g. Globe.maximumScreenSpaceError configurations or
multiple frustum rendering (where the engine is intentionally being
inaccurate, due to cognizant trade-offs, configurable or otherwise)?

I know Dan Bagnell and others on the team are currently working on the
`ground-primitive` branch, but I believe that is more to support the
case where terrain is perturbed, not uniform/zero. I find it
interesting that this will be provided by an entirely separate
primitive, but I haven't been involved in the development and understand
that it's a work in progress. As well, I may have the wrong
understanding of what this is supporting entirely. From the sounds of
it, the hard part is applicable both to "zero altitude primitive/terrain
rendering" and the ability to play with 2D zero-altitude geometry as a
"vector layer."

The whole height vs altitude vs elevation issue given Cesiums data model
(Globe: datum == altitude, perturbed by TerrianProvider (geoid), with
Geometry referenced against the Globe/Ellipsoid) is a complex one. I
think I'm making heads/tails of it, but it's hard to keep straight at
times. Thanks to everyone for supporting this, both past and future.

--
Nate

[Matthew Amato]

Nathan, I know it's been a while since you posted this, but just to respond to a few of your comments/questions

1. We definitely plan on supporting dynamic imagery (and maybe even dynamic terrain) in the future, but it's on the long-term roadmap and not something we are actively working on (though we have hacked up some proof of concepts in very old version of Cesium but they are no longer relevant).

2. We may also add rotation to SingleTileImagery provider in the future, but that's also a long-term issue.

3. The idea of tiling is completely baked into the imagery/terrain rendering and has to be because of the nature of the problem.  I'm not sure what you meant by "un-tiled" imagery (perhaps GeoTIFF and JP2?) The nature of WebGL and JavaScript makes supporting these formats directly almost impossible (until JavaScript/WebGL/bandwidth improve) and server-side pre-processing is the only solution (though maybe you were talking about something else?)

4. Accurate polygon on terrain rendering (with proper texture coordinate/imagery handling) is something that's really close to happening at the primitive and entity level.  It's been a long uphill battle because of both the limitations of WebGL as well as the fact that many techniques for doing it are patent encumbered.  I expect everything you want to be handled in the next 2-3 months.

5. I'm not sure what you mean by "even this visualization breaks down when you get up close" can you explain this in more detail and/or provide a sample polygon?

6. It's also possible to use video materials in Cesium, though we don't have brain-dead out of of the box support yet (though there is an out of date `video` branch that has 99% of the work done).  In the short term, if you have dynamic imagery you want on a polygon on terrain, a video material is probably the most efficient route.

Hope that helps fill in some of the blanks.  If you are still running into problems or have any questions, just let us know.

--
Nate

--
You received this message because you are subscribed to the Google Groups "cesium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cesium-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jesse...@gmail.com]

I have some interest in this thread as well and in particular question #1. I've been poking around the API docs to see if there's any sort of "tile invalidation" or "rect invalidation" to interact with internal caching infrastructure. Assuming that I have control over the tile map back end and would like to update a small area of the map say twice a second, what kind of options do I have?
I'm not afraid to implement either an alternate backend or a new imagery provider implementation/decorator that handles tile/rect invalidation updates from the tile server through an alternate back channel. If something like this opens up new options, that sounds easier to me than video materials.
From another angle, I'm a little worried that http cache header invalidation may not be consistent/robust enough across browser implementations to be reliable (but I'm assuming that's an option here?).

Am I missing anything in the API that addresses tile updates?

[chadspe...@gmail.com]

Interested in #1 as well. In my case, I need to clear an existing tile set for an ImageryProvider and make requests for new tiles whenever a user clicks a refresh button. I do not have control over the tile server or any server-side caching mechanisms.

Should I consider writing a custom TileDiscardPolicy, or are there other options to consider?

Thanks,
Chad