Support many imagery layers with transformations and terrain

[shehzan10]

• Add the ability to apply a custom transform/projection to an imagery layer, and entities/primitives, including polygons, polylines, billboards, labels, and points. Support all standard (EPSG) coordinate systems.
• Add capability to load many (tens of thousands) of imagery layers in the same view, each with a transformation matrix.
• Drape transformed imagery over terrain.

[likangning93]

Add the ability to apply a custom transform/projection to an imagery layer, and entities/primitives, including polygons, polylines, billboards, labels, and points. Support all standard (EPSG) coordinate systems.

Based on offline discussions, this is starting to become "how to support other projections for 2D/CV in Cesium." To clarify, I don't think the intent was to allow reprojecting imagery served to Cesium in a local system like EPSG:2039 so it can be shown on the globe, or stranger, showing two imagery layers projected different ways in the same 2D/CV scene. In other words, allow something like a mollweide in Columbus View/2D, accept imagery that isn't already equirectangular or web mercator.

I've been playing with basic proj4js integration with the Primitive API here: https://github.com/AnalyticalGraphicsInc/cesium/tree/proj4-projections

Some questions to investigate, discuss, hopefully answer, probably with more to come:

• some projections and their inverses will fail for coordinates outside projection-specific bounds. @mramato proposes simply limiting the scene to these bounds, but what does this entail across terrain, primitives, imagery... everything?
  • see EPSG:2039
  • note that this information isn't built into proj4js, but it could be user-provided
  • how much onus is on the user to limit their application to the bounds?
• when projecting geometry (terrain tiles, primitives) what to do about discontinuities in the projection?
  • Cesium's current rectangular projections just use the IDL as a splitting plane, but that may not be applicable or even correct for some projections.
  • can we assume users won't give primitives that cross discontinuities in their custom projections?
  • can we discard terrain tiles that cross discontinuities?
• Cesium doesn't have 2D/CV vertex positions for terrain tiles, it currently generates 2D/CV terrain positions in the shader since WebMercator and Geographic are relatively simple
  • porting proj4js to glsl seems like a bad idea
  • terrain projection probably has to be a CPU precomputation, but where does the data go? On the existing 3D position attributes?
  • in that case, can we restrict custom projections on terrain to 2D/CV-only scenes?
• how/when to project imagery?
  • is vertex warping still ok for local-areas of local-area projections like EPSG:2039?
  • is just warping terrain positions good enough to show equirectangular imagery on non-equirectangular 2D/CV?
  • should we go proj -> equirectangular when 2D/CV is in proj?
  • should we rewrite some of the terrain shader code to include another texture coordinate path for that specific case?

[likangning93]

Mentioned this in the PR above and maybe other less accessible places, but here's what I'm currently trying for pixel-perfect reprojection of individual images:

• maintain a CPU side copy of the imagery texture on a web worker - note that this is only remotely practical for mosaics in Chrome 69, Firefox doesn't support Canvas 2D on workers yet
• on load, have the worker create a 1024 x 1024 placeholder texture covering the source image in geographic coordinates by projecting every pixel into the source image's coordinate system and performing a pixel lookup
• whenever the camera is still, compute a rectangle covering approximately the terrain tiles that are in-view. request a 1024 x 1024 texture covering this geographic area from the worker
• when this image is ready, drop in an imagery provider containing it over the placholder

The result is pixel-perfect - individual pixels will be skewed, but pixel-pixel distinctions will be preserved at view distances where this detail is visible.
This isn't fast, but it also isn't completely unusable on "decent" hardware as long as users manage their expectations. Maybe we can even add callback tie-ins so a little spinner can show in the corner while the worker is chugging away.

Hypothetically this will also allow us to support mosaics that would otherwise overwhelm GPU memory, but it remains to be seen just how slow this will be.

PR above adds the ability to cut out rectangles in imagery layers so we can inset. This way, we can continue to show the "low detail placeholder" along with the high-detail chunk and not have to worry about overlap if the source imagery has transparency.