OptimallyAxel Now I understand; yes, see my October 10th reply above in this thread. I listed four different ways the traditional raster engine can display datasets in relation to terrain. I know for a fact the traditional flat-sphere/2D rendering, with adjustable vertical offset, is a requirement, as well as having 3D heightmapped abilities for 3D radar/satellite (that is, the height values come from the dataset itself, not from terrain).
The additional category that I do not know about yet, as I haven't done the research and development, is a raster engine capability to "drape" datasets directly over the terrain. I do informally hope to have capability like this. This is different from terrain-shading a 2D raster dataset; from far-out zooms and top-down views, they are the same. Hard to explain but it's possible to render the raster data to flat sphere underneath the geometry of the terrain, but only colorize the terrain with transparent hillshading, so you would see the dataset underneath. This is commonly seen on TV when they show, say, a temperature color fill, but you can see the terrain shading through the colors. We will absolutely have something like that at normal regional, global, and top-down views.
Current experimental work is being done on the fullest manifestation of that though, wherein color raster datasets are rendered directly in, with, and through the terrain geometry just like the color imagery base map data. I am building a generic tile composition infrastructure to accomplish this for the mapping data, but I definitely have had in the back of my mind that that system will be the way I try to accomplish terrain-projection of actual raster data. This is valuable for fields that are defined by a fixed height above ground.
Idea: while the terrain-draped raster display involves corrupting the original projection of data (such as Lambert grids which define HRRR datasets, etc) to project it to the lat/lon rectangular tiles, an efficient zoom-level-based switchover could be implemented for this which falls-over to traditional flat sphere rendering of raster data at far zooms, and only performs the terrain projection at close zooms. This would maintain performance and simplicity of original incorrupt projection at far zooms, while maintaining terrain-projected raster data display at close zooms.
These concepts are all related to a clear vision, understanding, and intuition I had after a long walk through Boston on November 7th, that the terrain engine and raster engine really should be the same thing. They've always been completely separate aspects of WSV3, but the terrain engine is really just Layer #1 of the generic raster engine. The only difference between the elevation/imagery data and the eventual weather raster datasets is the fact that it's static data (doesn't update). The computer doesn't know this - that's a very thin abstraction. Obviously the other big difference is the temporal/timeseries/animated loop aspect of weather raster data whereas terrain/imagery data is single-frame. That's fine - the terrain can be a "static" raster layer. Really trying to implement things generically and professionally like that, to make assumptions about data, and to orthogonalize/preprocess data into efficient chunks to be consumed by the renderer, with less polymorphic code behavior on the client-side. The philosophy is to convert the data into the structure needed for optimal rendering, as opposed to making complicated and inefficient rendering that can operate on a needlessly diverse set of inputs. The latter was very much the philosophy of the first-generation product and is not a tactical-grade design. The new product will be categorized by a decrease in complexity between systems where a smaller number of very powerful engines drive the program's graphics, as opposed to redundant and fractured separate systems for limited specific assets/data layers.
These direct questions I will be experimenting, researching, and developing around right through this winter as I also build the vector mapping components.
It will likely be until summer until I start bringing-in actual weather data for the raster display engine, but I might be able to do some experiments with 3D-terrain-projecting arbitrary raster data before then. After all, that is exactly what it's already doing with the color imagery and terrain elevation datasets.
