-
Notifications
You must be signed in to change notification settings - Fork 4
GSIP 115 CoverageView
Allow configuring a CoverageView built on top of different coverages from a store. Original coverages will be exposed as different bands of the same new Coverage View
[Daniele Romagnoli]
2.6
Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred
Aim of this improvement is providing a capability to define a Coverage View made of different bands originally available inside coverages (either bands of the same coverage or different coverages) of the same store.
Some examples of usage of this capability:
- Right now, physical entities for some metoc models are exposed as different coverages. As an instance, if you think about a NetCDF dataset storing meteo model, you may have an U coverage for the U component of the Wind and a V coverage for the V component of the Wind. However it’s often useful, if not mandatory, to expose a Wind coverage with 2 bands (U and V) or a single Wind coverage made of 2 bands (Speed and Direction).
- Some Meteosat datasets are made of N different channels (as an instance, 12 channels exposed as 12 different coverages, in some cases) on top of which we would like to define a “Vegetation” coverage made of channels #3,#2,#1.
For vectorial data, you may configure an SQL View starting from a DataStore. This will allow configuring a new Layer which is an SQL view of an existing store. We will do similar thing for raster data: once a coverageStore is selected, you will see a new link to create a Coverage View. A new Panel will be presented to the user in order to select which input coverages from the store should be used to define the new coverage.
At a preliminar stage, the offered capabilities will be very simple: just selecting the input coverages to be merged into a coverage view.
A set of constraints will be checked before merging different coverages:
- same CRS
- same resolution
- same bbox
- same data type
- same dimensions (same number of dimension, same type, and same name)
A new CoverageViewPage page will be defined to define the coverage view configuration (to select input coverages for that store).
A CoverageView (similar to GeoTools JDBC VirtualTable) class will be added containing information defining the CoverageView composition (name, input coverages, bands).
Such object will be put as element of a MetadataMap to be attached to the related CoverageInfo similarly to what is done with VirtualTable for SQL views on FeatureTypeInfo objects.
A GeoServer CoverageViewReader will be implemented to override read operations (in order to do the band merge between the original coverages), dimensionInfo listing (in order to merge the input coverage bands as different bands of the new CoverageView).
The ResourcePool object will support an additional getGridCoverageReader method accepting CoverageInfo argument. This will allow to look for Metadata objects associated to that info object, in order to retrieve the CoverageView definition. This will be similar to what is available for Feature sources where the ResourcePool looks for a VirtualTable definition as part of the FeatureTypeInfo metadata object.
Future improvements would relax some constraints (as an instance, the ones about same resolution, bbox, and datatype).
Moreover, it would be nice to offer the capability to add some kind of raster processing/calculation/scripting support to get bands from one or more coverages and combine them using some math. The development will be made to make that addition easy. As an instance, an RGB CoverageView may be defined as
- R = Channel1 + Channel2,
- G = SQRT (Channel3 ^ 2 + Channel4 ^ 2),
- B = Channel5 - 1/2 Channel6
This section should contain feedback provided by PSC members who may have a problem with the proposal.
- The initial proposal was referring to VirtualCoverage. After some discussions, the name has been changed to CoverageView (similarly to SQLView for vector data) in order to avoid confusion with the GDAL VirtualRaster support integration.
A new capability will be added. No backwards compatibility issues.
- Alessio Fabiani: +1
- Andrea Aime: +1
- Ben Caradoc Davies:
- Christian Mueller:
- Gabriel Roldan:
- Jody Garnett:
- Jukka Rahkonen: +1
- Justin Deoliveira:
- Phil Scadden: +1
- Simone Giannecchini: +1
JIRA Task Email Discussion Wiki Page