OGC Testbed 14 Demonstrator - CloudSat profiles
Welcome to the OGC Testbed 14 demonstrator showing CloudSat 2B-GEOPROF profiles via Web Coverage Service (WCS) and its Earth Observation application profile (EO-WCS) in a browser based highly interactive client.
In the following the demonstrated CloudSat Use Case is motivated, requirements derived, available standards reviewed, and updates and extensions proposed.
Use case CloudSat
In this use case we want to visualize CloudSat 2B- GEOPROF profiles in a web browser both on a globe or map as well as in an analytics, i.e., tabular view as shown in the screenshots below. The visualizations shall be highly interactive and provide the user with various options to adjust it. Just click on one of the three screenshots to try it yourself.
The OGC standardized Web Coverage Service (WCS) shall be used by the web browser to obtain the data to be displayed. The following sections motivate and derive the particular requirements for WCS, analyze existing versions and extensions for their suitability, and provide suggestions for updates and extensions where necessary. While for some use cases pre-rendered visualizations are sufficient in our use case real values are needed mainly for the analytics view.
Demonstration at launch
Values filtered and different style applied
The main functions to adjust the visualization are the subsetting of the data to be shown. Subsetting can be performed in time via the timeslider (selected time interval in bottom in screenshots above), spatially via globe or map view (left part), and in actual parameter values via analytics view (selection on histograms in lower part of analytics view on the right).
The timeslider is shown in the bottom of the above screenshots. It is highly interactive allowing to zoom and pan in time as well as to jump to particular dates via the picker (top right corner of timeslider). While navigating the timeslider it gives an indication about data availability (blue rectangles). Hovering over these indication shows the product id.
Once the time of interest is visible it allows to select the time interval for which data shall be visualized simply by click and hold on the timeslider. The current selection is highlighted with gray background and can be adjusted at the ends as needed. Alternatively the user can click on the availability indication for a quick selection.
Any change of the time selection triggers a refresh of the data visualizations and prior data download as necessary.
The globe view is shown in the left part of the first two screenshots above. It can be changed to a 2.5D map view which is shown in the third screenshot above. As on a standard map the data would only be visible as footprint curves the map view uses a 2.5D view. Both views are highly interactive allowing to zoom, pan, tilt, and rotate the globe or map.
All data available in the selected time interval is shown. The rendering itself like selected parameter, color-scale, or opacity is configured using the product settings accessibly via the Layers button in the top menu.
The analytics view also shows the currently selected parameter of the product like on the globe view. It is again highly interactive allowing to zoom and pan on both or individual axes.
The parameter histograms on the bottom allow subsetting in actual parameter values. The subsetting is applied to all views particularly globe and analytics view.
By default the axes are showing time horizontally and height vertically. This can be changed to show for example the parameter values horizontally.
While it is recommended to perform the time and spatial subsets by the data interface, i.e., on the server, the parameter value subset can be performed directly in the client.
The product settings allow to configure the rendering.
The first thing is to selected the parameter to visualize. In case of CloudSat 2B-GEOPROF this is either radar reflectivity, gaseous attenuation, or CPR cloud mask.
Second the color-scale and value range to use can be adjusted. A slider allows to configure the opacity.
In the globe view the Outline showing the footprint and direction of the curtain as well as the legend can be enabled or disabled.
The analytics view can be configured separately if needed using the cog icon.
The following requirements for WCS as the data or download service as well as the data format to be used are derived from the above visualization client description.
The service shall support …
- … retrieval of product metadata needed to fill the timeslider view and the map view
- … parameter subsetting, i.e., retrieving of individual parameters
- … product subsetting in time
- … spatial product subsetting, i.e., subsetting in latitude and longitude
- … retrieval of “overviews” for performance optimization
The data format shall be …
- … self-describing to specify for example if the data is encoded as pixel-in-center or pixel-in-corner
- … readable and interpretable in modern web browsers with existing libraries
Analysis of WCS
Retrieval of metadata
The standard WCS DescribeCoverage response contains all information needed to
satisfy requirement 1. However, there are two drawbacks. First, the
DomainSet will be quite huge or at least equal compared to the actual data
and second the
DescribeCoverage operation doesn’t support searching in time
The metadata needed by the client is ID, start, stop, and bounding box or
better footprint. Additionally often the envelope in physical dimensions will
not be sufficient and clients may need to know the grid size or size of the
mathematical dimensions of the
DomainSet. In case of a
information is present in the
To overcome the second point the
DescribeEOCoverageSet request of the Earth
Observation application profile of WCS can be used. All 2B-GEOPROF products
are grouped in a
DatasetSeries which is then used in
requests to get only the metadata to fill the currently visible time interval
and spatial extent.
There is currently no way to retrieve coverage metadata restricting the
DomainSet. Thus avoiding unnecessary big downloads, the
client would either need to query a synchronized catalog or a change of the
DescribeCoverage operation allowing to limit the response.
We propose to allow providing the
DomainSet axes information as coverages
themselves via OGC Web Services Context (OWC) mechanism. This way the
DomainSet stays as small as possible still providing the needed metadata.
Additionally by providing the axes information as coverages themselves allows
to directly subset the domain. This way clients really have a means to only
download the needed information at the cost of additional
requests to the
A discarded idea was to add a boolean parameter named
DescribeEOCoverageSet operations. Omitting this
new parameter or using a value of
False yields the current behavior whereas
a value of
True only returns the
GridLimits part of the
DomainSet omitting the remainder.
An additional idea, obsolete with the proposed solution, is to allow the same
subsetting parameters in the
DescribeCoverage operation than in the
GetCoverage one subsetting the
DomainSet itself. This would allow to
retrieve only relevant parts of the
DomainSet in the same way as the
Note that a general XPath extension to WCS has been discussed and proposed by the WCS.SWG. This extension would allow clients to retrieve any subset of XML responses according to XPath queries. However, this proposed extension is been held back by OAB as it is seen as potentially beneficial to more OGC services and should get a broader scope.
Requirement 2. is simply satisfied by the band subsetting extension of WCS.
Time and spatial subsetting
Trimming and slicing of any axis defined in the
DomainSet is standardized in
the core of WCS. The difficulty with the data at hand is to define a suitable
DomainSet that contains time and spatial axes in order to support
requirements 3. and 4.
The 2B-GEOPROF data provides the parameters in a 2D grid with size
nray is typically around 20.000. Each of the approximately
20.000 columns has latitude, longitude, and time values that are equal for the
whole column. On the other side, each grid point has its own height value,
i.e., there is no uniformity in the 125 height elements.
The challenge is to model the 2D data grid in the 4D CRS grid.
This is not possible using CIS 1.0, even including the ReferenceableGridCoverage extension, as there is no way to “get rid” of CRS axes in order to describe the 2D grid in the 4D CRS.
Using CIS 1.1 there is the
GeneralGrid together with
IrregularAxis. However, only the
DisplacementAxisNest supports to “get
rid” of axes but which would unnecessarily blow up the
as values for each individual 4D CRS grid element would have to explicitly be
provided. Or in other words, the conformity of the 2D columns cannot be
exploited and instead of providing latitude, longitude, and time each “only”
approximately 20.000 times this would blow up to multiplying this 125 times:
In order not to unnecessarily blow up the
element similar to
DisplacementAxisNest and allowing to exploit the
conformity of the columns is proposed as follows:
IrregularAxisNest extension would allow instead of
125 x 20753
P elements with 4
C elements each to have only
P with 3
125 x 20753
P with one
C elements, resulting in 2.656.384
instead of 10.376.500 elements or a reduction of almost 75%.
In combination with our proposal from the “Retrieval of metadata” chapter we
believe to have a really elegant solution available. The
DomainSet axes are
provided as coverages themselves via OWC mechanism. The contents of the
DisplacementAxisNest element are provided as an
Index2D coverage holding
all the height values and the
IrregularAxisNest element as three
coverages corresponding to latitude, longitude, and date. This way the
DomainSet stays small while supporting all required functionality
even subsetting in the domain.
Another potential option is to have only lat, long, and time in the
DomainSet as subsetting in height is not needed on the service level. That
would mean having a 1D data grid in a 3D CRS grid and height in the
RangeType. However, this would result in
125 x 4 elements in the
RangeType, 3 parameters and the height itself for 125 different heights, and
a need to specify how they relate to each other, i.e., which parameter values
correspond to which height value. This idea is discarded as impractical.
Requirement 5. targets performance optimization. A critical metric for performance is “First view” but also update after user interaction. Retrieving only overviews or lower resolution of the data reduces loading and rendering time. However, defining a general downsampling or downscaling algorithm suitable for any irregular grid is not a simple task. It seems easier to define an algorithm to map the irregular grid to a regular one and use the well-known scaling and interpolation extension on them.
The converted coverage has the number of axis from the data array or the mathematical dimensions, i.e., 2 in our case. The axes mapping from data array to CRS or physical dimensions needs to be defined in the
The coverage description needs to include these details:
- resolution in all CRS axes, i.e., the minimum distance needed on each axes to correctly represent the data - TODO review and propose where to provide this information
- size of data array - provided in
- bounding box or maxima in each CRS axis - provided in
- mapping from CRS to data array, i.e., how are the axes related - provided in axis elements like
GetCoverage operation needs to be extended by these parameters:
booleanto indicate type conversion
axesMapping- mapping for each axis, i.e.,
i:date,j:hthere should be a default specified
By default each axis will use its advertised resolution. This can be overwritten by using the mechanics of the scaling extension, e.g. via the
Via this type conversion still the original potentially interpolated values are retrieved. Another optimization is to ask for complete renderings from the server but this is out of scope here and left to the Web Map Service (WMS). An integration like this between WCS and WMS could be addressed in one of the next testbeds.
Example WCS requests and responses
Note that only one coverage is directly visible here, all others are only
listed in the advertised
GetCapabilities response -
- Height http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageId=_2017330010611_61600_CS_2B-GEOPROF_GRANULE_P_R04_E06_height&format=image/tiff
- Latitude http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageId=_2017330010611_61600_CS_2B-GEOPROF_GRANULE_P_R04_E06_latitude&format=text/csv
- Longitude http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageId=_2017330010611_61600_CS_2B-GEOPROF_GRANULE_P_R04_E06_longitude&format=text/csv
Pofile time http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageId=_2017330010611_61600_CS_2B-GEOPROF_GRANULE_P_R04_E06_profile_time&format=text/csv
Height subset http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageId=_2017330010611_61600_CS_2B-GEOPROF_GRANULE_P_R04_E06_height&subset=x(0,10)&subset=y(0,100)&format=image/tiff
A list of various
GetCoverage requests needed for the use case is provided below.
- Subset along y axis http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&subset=y(0,100)&format=image/tiff
- Subset along x and y axis http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&subset=x(0,10)&subset=y(0,100)&format=image/tiff
- Slice on the y axis http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&subset=y(100)&format=image/tiff
- Scale all axes equally 1 http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&scalefactor=0.1&format=image/tiff
- Scale all axes equally 2 http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&scaleaxes=x(0.1),y(0.1)&format=image/tiff
- Scale axes individually http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&scaleaxes=x(1),y(0.1)&format=image/tiff
- Scale axes to specific size http://ows.eox.at/testbed-14/eoxserver/ows?service=WCS&version=2.1.0&request=GetCoverage&coverageid=_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06&format=image/tiff&scalesize=x(100),y(2000)
Analysis of data formats
It seems any 2D raster data format would be suitable to transport the 2D data grid.
The first requirement of a self-describing format can be satisfied by
including the coverage description. Together with the coverage description
DomainSet clients need to interpret the data in order to
display it correctly, i.e., not using square pixels. An alternative is the
usage of HDF or NetCDF.
Thus the actual choice is mainly based on performance considerations like compression ratio or file size for minimal bandwidth needs as well as time and effort needed to encode and decode.
Suggestions for extensions
- Allow providing the
DomainSetaxes information as coverages themselves via OGC Web Services Context (OWC)
GeneralGridin CIS 1.1
- Add parameters to the
GetCoverageoperation to ask for a type conversion from referenceable to rectified coverage