...
- Other than BEAM, SNAP's product data model should be able to deal with products that have bands of different image sizes and geo-codingsA product shall however still provide a scene image resolution and scene geo-coding which result from a spatial collocation of all the band's image
- geometries.There shall be one model coordinate reference system for the whole product.
- Users of the API shall be able to access both, raster data in native resolution/geo-coding and raster data in scene resolution/geo-codinguse all SNAP functionality for both single-size and multi-size products.
Findings of meeting from October 1st, 2015
This meeting took place after we ran into several problems resulting from the implemented changes described below. We found that the approach using SceneRasterTransforms was misguided, as it existed alongside the already present transformations between reference systems within SNAP.
We identified a need to exactly define the meanings of the various coordinate reference systems in SNAP. This becomes the more important as this concept needs to be adapted to consider bands of different sizes within the same product. At the core, it stands that there needs to be a single model crs for a product. Images provide imageToModelTransforms which transform from the respective image crs' onto the model crs'. Also, all vector data is saved within model coordinates. What is the model crs depends on the used geocoding. If a CrsGeocoding is used, there is a map crs which will be the model crs. In other Geocodings, there is no map crs (or, strictly, the geo crs will fill that role) and the model crs should be the image crs. In multi-size products, as there are multiple images it is not clear what is the image crs which shall constitute as the model crs.
Also, as there are multiple images, it makes less sense for a product to provide such things as a scenerastersize or a geocoding, as these are not necessarily valid for the whole product anymore. However, for single-size products, these values can still be provided as they still make sense.
There are a lot of places within the SNAP code where the scenerastersize or the product's geocoding are requested. In these cases, the product can return the common rastersizes. If these are null, either the operation shall not be performed or the band- / rasterdatanode-specific sizes or geocodings should be used.
A major obstacle here is that there are numerous places where a careful code revision is required. Also, unexpected problems might still occur.
The big remaining question is whether the adaption of the existing image crs/geo crs/model crs - concept to multi-size images along with band-oriented raster sizes and geocodings is feasible.
Background and strategic fit
...