Allow reordering of Cesium layers

[robyngit]

A note reordering imagery layers

Commit 252d5f07d5948658f03577d058f1503a599105af added a sortImagery method.

https://github.com/NCEAS/metacatui/blob/252d5f07d5948658f03577d058f1503a599105af/src/js/views/maps/CesiumWidgetView.js#L936-L969

The CesiumWidgetView could simply call sortImagery when there is a change in the order of imagery in the layers collection.

Then the UI for reordering imagery layers only needs to update the order in the collection (and not in Cesium directly)

[robyngit]

Here's a mockup of a click-and-drag method we could use to re-order layers (based on the original mockups)

[yvonnesjy]

We discussed the support of this (in a world with layer categories) with Doug and Anna in a meeting this week. The thought was that this won't generate high return as a feature because:

• The order of categories make sense, no use case of reordering categories
• Reordering within a category has low return value given that users won't have too many layers visible at the same time

@mbjones @robyngit thoughts?

Mock: https://docs.google.com/presentation/d/1xBSUGLq6fPV4RukzFMYqVszUMISeLpvgqTNRcQHaOLg/edit?resourcekey=0-SfzZXnxAwtnOTg1KSPvLqg#slide=id.SLIDES_API710498576_0

[mbjones]

Well, it means that we'd likely not be able to meaningfully show multiple layers at once beyond a base layer and one other, at least as the number of layers grows. But yes, I think the ordering is indeterminate when grouped by categories. Typically, within GIS systems, layer order determines z-order in the visualization stack, and we've used that many times to show multiple layers in PDG (e.g., the base Bing layer, below the permafrost zones, below IWP, below the Communities labels. In other orders, some layers will not be visible. Right now we try to have a sensible order, but as the number of layers increases that will be more and more impossible without reordering. I still think it is a highly valuable feature, even though it has some design challenges with grouping.

[robyngit]

Cesium, designed to represent data in "3D", has some inherent limitations in how layers can be ordered as opposed to a tradition 2D map. In short, we can't sort imagery layers ABOVE data layers.

Imagery layers are draped over the terrain or the globe's surface. These layers are essentially 2D data that conform to the 3D shape of the earth below them. Because they are rendered directly on the terrain, they act as a base upon which other elements are overlaid.

Data layers, on the other hand, generally have a defined location in the 3D space (though I think you can "drape" some simple geometries). So even though our IWP layer comprises flat polygons, the 3D model still defines that those polygons exist above the surface of the Earth. For that reason, we can't place the draped imagery ABOVE the 3D tiles.

[mbjones]

the 3D model still defines that those polygons exist above the surface of the Earth

Just to clarify, it really means that the polygons exist in 3D space independently of the surface of the earth, and any plane of the polygon that is below the surface of the earth will be obscured by the surface layer rendering. Cesium does support visualizing 3D objects below the surface of the earth, and their 3D Base layers can even make it so you can look from inside the earth out. See: https://cesium.com/blog/2020/06/16/visualizing-underground/

So, for our case, we want our flat polygons to be displayed just above (or on) the ground surface, even when the ground is not flat -- for example, if we make each point in a polygon 1cm above the DEM elevation at that point.

[mbjones]

Here's 60% surface transparency, showing a vector object jutting through the surface. With 100% surface transparency, you can only see the above-ground part.

From: https://sandcastle.cesium.com/index.html?src=Globe%20Translucency.html