Refactor ElevationMap and Dem to separate elevation data from calculation data

[watkipet]

Presently, Dem holds data, mask, and signal. Only data contains elevation data. mask and signal are the results of calculations or loading place markers, etc. Likewise, ElevationMap isn't just concerned with elevation--that's where all the calculations take place.

I propose the following:

1. Rename ElevationMap to Workspace
2. Pull mask and signal out into separate layers
3. Make MapComputation and PathComputation abstract base classes. Concrete subclasses of these can operate in the Workspace and output to a layer.

I'm hoping this will accomplish a few things:

1. Decouple the results of the computation from the elevation data
2. Allow for adding new computations
3. Prevent one computation from overwriting data from another (unless desired)

Something I still need to think about is that there are multiple Dems per Workspace (see sr.maxpages). All the Dems have the same resolution (see sr.ippd). This is fine. Likewise, there should still be a 1:1 correspondence between Dems and pieces of output layer data. However, a Computation doesn't care about pages. All it cares about is latitude, longitude, and its output layer.

So I'm thinking that a Workspace defines the number of pages, and the resolution of each. Then layers can be added to the Workspace so long as each layer exposes the appropriate number of data pages each with the appropriate resolution.

It would be nice if SDF, SRTMGL, etc. were also just layers which provide elevation data. That would fulfill a desire I saw elsewhere to support loading elevation data from more than one source (i.e. high resolution data from one source, and low resolution data from another). If the elevation data sources are in layers, the Workspace can get data from whatever the top layer is. If there are holes in the top layer, the Workspace can get data from the next layer down. If a layer isn't at the appropriate resolution, it's responsible for interpolating. The bottom layer is always present, and it's sea-level.

By retaining the use of pages, each layer can perform sparse operations. If the Workspace asks an SDF layer for page 4, it can load it from the disk and cache it in memory on the fly. If the Workspace asks an SRTGML layer for page 5, it can load that page from an HTTP source if so configured and cache it on disk, in memory, or both.

Likewise, if a computation wants to write to a certain latitude and longitude, the Layer can determine which page that is, and create only a single page of output data rather than allocating all the pages of output data at runtime for all the layers (like we do now).

[der-stefan]

That's a good concept, @watkipet. I'm not completely happy with the naming "Workspace". Perhaps "geolayer" or "geospatial" is more suitable? In the future I would like to include some landuse data (residential, forest etc.) for more advanced propagation models. Similarly, the "signal" object could have an additional layer depicting if each pixel has a line-of-sight to the TX site or not. This information is relevant for selecting the respective probability distribution (Rice/Rayleigh).

[watkipet]

I imagine landuse data would be an input layer (as are elevation layers). signal would likely be its own output layer as would LOS. However, in their case, they would each be the result of running different Computation objects. The LRPathLoss Computation object would output a signal layer while the LOS Computation object would output an LOS layer.

Here's how I came up with the workspace name:

Imagine a draftsman doing this job manually. He would lay out pages of elevation data (perhaps topo maps) on his workspace and tape them together making one large elevation data layer. Then he would tape pages of gridded vellum paper or transparencies on top of that. He would either compute the path loss from the transmitter to the grid square in question for a single path (for a report) or he would do so for all the grid squares to make an LR path loss map. Those taped-together sheets of vellum paper are an output layer. So the workspace contains both the input and output layers and it's where the draftsman performs his calculations.

I'm not stuck on "Workspace" per-se. Is there a particular reason you dislike it (too vague, perhaps?) Any noun which conveys such a meaning would be fine. "geolayer" implies a specific layer whereas a workspace contains layers but isn't a layer itself. "geospatial" might be OK except that it's an adjective instead of a noun--and the workspace is a thing which contains other things.

[dBitech]

I think workspace, workbook, or maybe easel or canvas are all suitable describers for holding a collection of objects some of which are read-only, and some are writable. But agree this is just a "name" and can likely be changed later via a simple search and replace if a more suitable descriptor is thought of.

[hoche]

I think the main reason the data, mask, and signal were all in the Dem object was because the object also holds information on the bounds of the Dem, which allows you to quickly find the right Dem given a set of coords. I like the idea of pulling mask and signal out into separate layers (and making it so we can add new kinds of computations later), but we should preserve that quick-lookup ability. Maybe that's a matter of keeping a master record with the Dem's bounds in it and pointers off to the actual elev(s), mask, signal, and future-element pages?

I'm lousy at naming stuff so I'm fine with workspace or canvas or whatever. Maybe not anything with the word "map" in it as to me that makes me think of some sort of associative array.

[watkipet]

I was thinking the Workspace (for lack of a better name) would keep track of the number of pages and each page's bounds. Then one could ask each Dem, Mask, or Signal layer, "Give me your data for page 3", and it would yield up that set of data. So the general process would be:

1. Ask the Workspace which page number contains a given lat and lon.
2. Ask the layer you want data from for the data in the page number above.

We can also have convenience interfaces that perform both steps for you. One thing I need to do is determine which computation loops execute the most. I need to make sure the interfaces I make don't slow these down.