Publication Date: 2019-02-07
Approval Date: 2018-12-13
Submission Date: 2018-11-08
Reference number of this document: OGC 18-047r3
Reference URL for this document: http://www.opengis.net/doc/PER/t14-D007
Category: Public Engineering Report
Editor: Eugene Genong Yu, Liping Di
Title: OGC Testbed-14: Swath Coverage Engineering Report
COPYRIGHT
Copyright (c) 2019 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Summary
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Swath Coverage
- 6. Swath Coverage Models with Climate Forecast Conventions
- 7. Swath Coverage Models with OGC Coverage Implementation Schema
- 8. Swath Coverage Encoding
- 9. WCS Swath Coverage Profile
- 10. WCS REST API
- 10.1. Scope and Design Principle
- 10.2. Conformance
- 10.3. Main Paths
- 10.4. Service root path /
- 10.5. Service OpenAPI path /api
- 10.6. Service OpenAPI path /conformance
- 10.7. Service OpenAPI path /coverages
- 10.8. Service OpenAPI path /coverages/{coverageId}
- 10.9. Service OpenAPI path /coverages/{coverageId}/rangeSet
- 11. Swath Coverage Use Cases
- 12. Summary and Discussions
- Appendix A: Example Swath Coverage Services, their Requests and Responses
- Appendix B: WCS REST API Full Specification
- B.1. Scope
- B.2. Conformance
- B.3. References
- B.4. Terms and Definitions
- B.5. Conventions
- B.6. Core Requirement Class
- B.7. Range Subsetting Extension
- B.8. Earth Observation Extension
- B.8.1. Overview
- B.8.2. OpenAPI Object
- B.8.3. Service OpenAPI path /conformance
- B.8.4. Service OpenAPI path /eocoverages
- B.8.5. Service OpenAPI path /eocoverages/{eocoverageId}
- B.8.6. Service OpenAPI path /eocoverages/{eocoverageId}/rangeSet
- B.8.7. Service OpenAPI path /eocoverages/{eodataseriesId}
- B.8.8. Service OpenAPI path /eocoverages/{eodataseriesId}/{eodatasetId}
- B.8.9. Service OpenAPI path /eocoverages/{eodataseriesId}/{eodatasetId}/rangeSet
- B.9. Transaction Insertion Deletion
- B.10. Transaction Update
- B.11. GeoTiff Coverage
- B.12. NetCDF Coverage
- B.13. GeoPackage Coverage
- Appendix C: Revision History
- Appendix D: Bibliography
1. Summary
This Engineering Report (ER) presents a summary, description and findings of the Swath Coverage task conducted by the OGC Testbed-14 initiative.
1.1. Requirements & Research Motivation
The goal of the Swath Coverage task was to improve access to National Aeronautics and Space Administration (NASA) data in Swath structure, specifically for those Earth Observations in Level 1 and 2.
The objectives of the Swath Coverage task were as follows:
-
Modeling Swath data with Climate Forecast Convention
-
Encodings in GeoTiff, NetCDF, and GeoPackage
-
Serve typical swath data in WCS service
-
Demonstrate the use of swath data through clients
1.2. Prior-After Comparison
The Swath Coverage has not been modeled and supported with existing standards and specifications. This OGC Testbed-14 task provided solutions through adapting the data models and services to better support access and visualization of swath coverages.
Achievements of the Swath Coverage Task
| Items | Prior | After |
|---|---|---|
Swath Coverage Model |
Not modeled |
Modeled by (1) Climate Forecast Convention and (2) CS 1.1 |
Swath Coverage Encoding |
No standard encoding |
Encodings: GeoTiff-Swath, NetCDF-Swath, GeoPackage-Swath |
Swath Coverage Service |
No support by WCS |
WCS Swath Coverage Profile, WCS Swath Coverage REST API |
Swath Coverage Client |
Ad hoc |
Standard interaction with WCS for data access and visualization |
1.3. Recommendations for Future Work
The Swath Coverage is relevant to the standardization work of the Web Coverage Service (WCS) Standards Working Group (SWG). The task contributes to the development of open specifications on swath coverage as follows.
-
WCS Swath Coverage Profile to adapt and specialize WCS and EO-WCS to model swath coverages
-
Encoding of swath data in GeoTiff, NetCDF, and GeoPackage as supported formats under WCS Swath Coverage
-
WCS Representational State Transfer (REST) Application Programming Interface (API) (OpenAPI 3.0.1) to facilitate stub code automatic generation for server and client
The ER makes the following recommendations for future testbed work:
-
If the Geospatial Data Abstraction Library (GDAL) is still considered as the library to work on different swath coverage, the GPKG driver of GDAL needs to be enhanced to support non-tiled data. This could be done within an OGC testbed and then provided to the GDAL developer community as open source.
-
Future testbeds could also look into how the Sensor Model Registry that was initiated in 2018 by the OGC Technical Committee could support the modeling of Swath Coverages. The Sensor Model Registry will be managed by the OGC Naming Authority.
1.4. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
| Name | Organization |
|---|---|
Eugene G. Yu |
George Mason University |
Liping Di |
George Mason University |
Stephan Meissl |
EOX |
Sergio Ferraresi |
MEEO |
Sizhe Wang |
Arizona State University |
Wenwen Li |
Arizona State University |
Ingo Simonis |
OGC |
1.5. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
2. References
The following normative documents are referenced in this document.
-
OGC: OGC 17-089r1, OGC® Web Coverage Service (WCS) Interface Standard - Core, version 2.1
-
OGC: OGC 09-110r4, OGC® WCS 2.0 Interface Standard - Core, version 2.0.1
-
OGC: OGC 12-039, OGC® WCS Interface Standard – CRS Extension, version 1.0.0
-
OGC: OGC 09-147r3, OGC® WCS Interface Standard - KVP Protocol Binding Extension, version 1.0.1
-
OGC: OGC 10-140r2, OGC® WCS Interface Standard - Earth Observation Application Profile, version 1.1
-
OGC: OGC 12-100r1, OGC® GML Application Schema - Coverages - GeoTIFF Coverage Encoding Profile
-
OGC: OGC 14-100r2, CF-netCDF 3.0 encoding using GML Coverage Application Schema
3. Terms and definitions
For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.
-
swath coverage
unreferenced Earth Observation data that has the following characteristics of being time-ordered, having geolocation files with longitude and latitude at least, and having definite mapping relationship between geolocations and data fields.
-
scanline|across-track axis
one of the two axes that a swath data has. In general, it is across the track of sensor movement.
-
track|along-track axis
one of the two axes that a swath data has. In general, it is along the track of sensor movement.
-
time
one of the dimensions often occurred in swath coverage. The common units are expressed in seconds, microseconds, or nanoseconds for sensor recordings. It can be explicitly expressed in Coordinated Universal Time (abbreviated to UTC) and International Atomic Time (TAI). UTC and TAI are different because UTC has leap seconds while TAI is continuous. UTC is based on Gregorian Calendar, the most commonly used calendar. In this context, if "gregorian" is the calendar, the time should be in UTC which has leap second. In computer, Unix epoch (or Unix time or POSIX time or Unix timestamp) may often be used which is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z). Proper library should be used to convert them into UTC or TAI.
3.1. Abbreviated terms
-
CALIOP Cloud-Aerosol Lidar with Orthogonal Polarization
-
CALIPSO Cloud-Aerosol Lidar and Infrared Pathfinder Satellite Observations
-
CIS Coverage Implementation Schema
-
COM Component Object Model
-
CORBA Common Object Request Broker Architecture
-
COTS Commercial Off The Shelf
-
DCE Distributed Computing Environment
-
DCOM Distributed Component Object Model
-
GDAL Geospatial Data Abstraction Library
-
GIS Geographic Information System
-
GMT Greenwich Mean Time
-
IDL Interface Definition Language
-
ISO International Organization for Standardization
-
MODIS Moderate Resolution Imaging Spectroradiometer
-
NASA National Aeronautics and Space Administration
-
NOAA National Oceanic and Atmospheric Administration
-
OGC Open Geospatial Consortium
-
POSIX Portable Operating System Interface
-
TAI International Atomic Time
-
UTC Coordinated Universal Time
-
VIIRS Visible Infrared Imaging Radiometer Suite
4. Overview
|
Note
|
Highlights
This Chapter gives an overview of the complete document that helps the reader to better understand the various sections of the ER. |
Section 5 introduces the problem of swath coverage access. It describes the situation prior to the testbed and discusses the requirements set by the sponsors.
Section 6 discusses the model using Climate Forecast Conventions. It provides recommendations on modeling typical types of swath coverages.
Section 7 discusses the model using OGC Coverage Implementation Schema. It provides recommendations on modeling typical types of swath coverages.
Section 8 presents other encodings or data models for Swath Coverage developed in this testbed in addition to netCDF and GML coverage.
Section 9 presents the Swath Coverage Profile under WCS. The Swath Coverage Profile is developed on CIS-1.1, WCS 1.1, and EO-WCS 1.1.
Section 10 presents the WCS REST API for Swath Coverage Profile. The version for OpenAPI is 3.0.1. The automatic generation of service and client stubs is supported with the full development of swath coverages under OpenAPI. The section only covers the design principles and major paths. Full details are included Appendix B.
Section 11 presents example implementations of Swath Coverage WCS services and clients, and typical use cases of Swath Coverages.
Section 12 provides a summary of the main findings and discusses links to other tasks such as WFS 3.0.
Annex A provides code snippets and examples that illustrate the functionality of the WCS Swath Coverage Service in requests and responses.
Annex B includes the complete draft specification for WCS REST API that follows OpenAPI 3.0.1. This is full document that is briefed in Section 10.
5. Swath Coverage
|
Note
|
Highlights
This section explains some basic concepts for swath and swath coverage. Typical swath data are also described. General requirements are reviewed with the functional expectation of visualization and analytics. |
5.1. Swath Coverage
In this context, a swath coverage is generally defined as the Earth Observation data that has the following characteristics [1] [2] [3]:
-
They are time-ordered.
-
There are geolocation files with longitude and latitude at least.
-
There are definite mapping relationships between geolocations and data fields.
5.2. Typical Types of Swath Coverages
Swath coverages can be classified into different categories depending on the criteria. Based on the data fields, they may be grouped into two categories: radiometric swath data (Level 1) and geophysical swath data (Level 2) [4]. Based on observing geometry, they may be grouped into three categories: scanning (scan line), profiling (vertical), and scanning-profiling (curtain-like) [1], [4]. Depending on the mapping relationship between data fields and geolocations, they can be grouped into three: swath with time/Location, swath with Analytic fit, and swath with Attitude/Ephemeris data for spacecraft or airborne platforms [1].
5.2.1. Scanning Swath Coverage
A typical scanline swath coverage would look like the simplified sketch as shown in Figure 1.
In this testbed, the Level 1 and Level 2 products from the Visible Infrared Imaging Radiometer Suite (VIIRS) instrument are examples of scanning swath coverage datasets. The products of VIIRS are radiance at Level 1 and reflectance at Level 2 data. The product number is VNP09 for Suomi-NPP VIIRS produced by the Land Processes Distributed Active Archive Center (LP DAAC) of NASA. This is a typical scanline swath data. For the three I-Bands, the cross-track scan is expanded to 6400. For the M-Bands, the cross-track scan is expanded to 3200. The sensor has a constant scanning angular resolution while the footprint on the target Earth ground shows a "bow-tie" effect. To save the bandwidth in sending back the sensed data, certain tracks are skipped towards the tails along scanlines. Geolocation products are numbered VNP03 where VNP03IMGLL for I-Bands and VNP03MODLL for M-Bands. Three geolocation attributes are calculated for each pixel. They are latitude, longitude, and height. The mapping between the geolocation fields and data fields are one-to-one, i.e. each pixel has a unique geolocation value.
The operational products served at National Oceanic and Atmospheric Administration (NOAA) are numbered as SVI and SVM respectively. Each file has both radiance and reflectance data in one file. Geolocation files contain solar position (solar azimuth and solar zenith) and satellite position (satellite azimuth, satellite zenith, and satellite range) in addition to geometrical locations of latitude, longitude, and height. These parameters are useful in geometrical rectification and radiometric correction.
5.2.2. Profiling Swath Coverage
A typical profiling swath would look like these, as simply depicted in Figure 2
The Level 1B and Level 2 backscatter products of Cloud-Aerosol LiDAR and Infrared Pathfinder Satellite Observations (CALIPSO) and the backscatter products of CloudSat are typical profiling swath coverages. The Level 1B of CALIOP (Cloud-Aerosol Lidar with Orthogonal Polarization) - the sensor of CALIPSO is a profiling swath coverage. The aggregation and averaging algorithm on board of the satellite convert the raw measurements into uniformly 583 elements vertically at each point. There is no across-track scan. The resolution along the vertical direction varies from height to height due to the averaging scheme. The spatial resolution at each point is different from pixel to pixel due to its location at different record element (or altitude).
The level 1B and Level 2 product of CloudSat are also primarily backscatters of Radar and derived Cloud Geometric Profile respectively. They are also typical profiling swath coverage. At each point along the track, CloudSat has uniformly 125 bins which represents 240-meter vertical resolution. Each pixel has different spatial resolution due to their difference along vertical direction.
5.2.3. Scanning-profiling Swath Coverage
The scanning-profiling swath has both scan expansion with vertical profiles. To be general, this category of swath data includes those point clouds. It captures a volumetric description of the features.
A scanning-profiling product is the atmospheric profiling product from Moderate Resolution Imaging Spectroradiometer (MODIS). The product numbers are MOD07 and MYD07 for data collected on Terra and Aqua respectively. The MODIS Atmospheric Profile product consists of several parameters: they are total-ozone burden, atmospheric stability, temperature and moisture profiles, and atmospheric water vapor. All of these parameters are produced day and night for Level 2 at 5x5 1-km pixel resolution when at least 9 FOVs are cloud free. The MODIS Atmosphere Profile data product files are typical of scanning-profiling swath which profile data at different altitudes.
The MODIS total-ozone burden is an estimate of the total-column tropospheric and stratospheric ozone content. The MODIS atmospheric stability consists of three daily Level 2 atmospheric stability indices. The Total Totals (TT), the Lifted Index (LI), and the K index (K) are each computed using the infrared temperature- and moisture-profile data, also derived as part of MOD07.
The MODIS temperature and moisture profiles are produced at 20 vertical levels. A clear sky synthetic regression retrieval algorithm is used, where regression coefficients are derived by using a fast-radiative transfer model with atmospheric characteristics taken from a dataset of global (radiosonde and model) profiles. The MODIS atmospheric water-vapor product is an estimate of the total column water vapor made from integrated MODIS infrared retrievals of atmospheric moisture profiles in clear scenes.
5.3. Functional Requirements of Swath Coverage
The goal of this testbed effort was to better serve the swath coverage through a standard Web service that helps in extensively using swath data. To achieve the goal, the specific tasks included (1) modeling Swath data with Climate Forecast Convention, (2) encodings in GeoTiff, NetCDF, and GeoPackage, (3) serving typical swath data through a WCS service, and (4) demonstrating typical use cases of swath data through clients.
Two important aspects of using swath data are visualization and analytics. Visualization of the swath coverage in common GIS software packages allows visual exploration from different viewpoints or together with other features and properties in aligned geographical reference systems. Analytics include the use of actual data which puts a specific requirement on accessing the raw data as well as geospatially mapping to other properties and features.
5.3.1. Visualization
The visualization of the swath coverage may include a general 2D view, time series view, 3D view on a globe, or an analytical view.
5.3.2. General 2D views
The view of the swath coverage in 2D view may be shown by itself from different viewports or projections to a geographical reference system along with other geographical features. The view may be the result of sub-setting or slicing on a time dimension or (vertical) profile. Example views of CloudSat 2B-GEOPROF Level 2 (Swath) data are shown in Figure 3. The top shows the top view of the swath data over geographical regions in georeferenced projections. The lower view is a 2D view with axes of time and height (profile) along the track. The latter may not be projected in a standard spatial reference system, but the sensor coordinate system. Another example of a 2D profile view in a time-height coordinate system is shown in Figure 4.
5.3.3. Time series views
A swath coverage is a time-ordered observation of the ground sampled by satellite sensors. One of the requirements is to visualize the data with time series. This can be interactively controlled using a timeline or a timebar. One example time slider is shown in Figure 5 where the timeline is used to control the view of time series. In general, the timeline control allows the user to interactively 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, the interface provides an indication of data availability (blue rectangles). Hovering over these indications shows the product id.
Once the time of interest is visible the time slider allows the selection of the time interval for which data shall be visualized simply by clicking and holding on the timeslider. The current selection is highlighted with a 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.
Animation over a period with a given interval step may often be required to see the change. The timeline may support the selection of periods to be animated over.
5.3.4. Globe 2.5D/3D view
An example globe view is shown in Figure 6. The view can also be changed to a map view. As on a standard map, the data would only be visible as footprint curves because the map view uses a 2.5D view. Both views are highly interactive allowing the user to zoom, pan, tilt, and rotate the globe or map.
The globe view may also be used as the basemap to select an area of interest for data access or detailed visual exploration of the data.
5.3.5. Analytical view
An analytical view may be required to show aggregated features of the coverage. The features may be the statistical distribution (e.g. histogram) or summation (e.g. statistic sum, mean, minimum, and maximum). The visuals may be rendered as maps or charts (e.g. bar charts for histogram). It is again highly interactive allowing a user to zoom and pan on both or individual axes. Linked views (connecting multiple views of the coverage) may be supported.
5.3.6. Analytics
The raw data may be required by users for further analysis and processing. In this context, the access of the swath data shall support the minimum content requirement for georeferencing as defined in standard [1].
The requirements to access the raw data of swath coverage imposes the following constraints on delivered data:
-
Data should not be changed. Resampling should not happen.
-
Integrity on the mapping relationship between data fields and geolocation fields should be maintained. The mapping is not just limited to just associate latitude/longitude/height to each pixel, but also extended to relate to other location info (e.g. solar azimuth, solar zenith, satellite range, satellite azimuth, satellite zenith).
In general, swath data contains information: data fields, geolocation fields, and mapping between data and geolocation. The mapping between geolocation and data fields may be defined with Time/Location, Analytic fit, or Attitude/Ephemeris. Time is an important dimension in defining the mapping relationship between geolocation fields and data fields since a swath coverage is un-georeferenced or in the coordinate system of sensors. The time dimension may need to be distributed along with the swath coverage. This may be essential to maintain the integral correlation between geolocation fields and data fields when the swath coverage is subset spatially.
6. Swath Coverage Models with Climate Forecast Conventions
|
Note
|
Highlights
This section describes the modeling of swath coverage using Climate Forecast (CF) conventions. The encoding of swath coverage in netCDF is the target. |
6.2. Swath Coverage CF Coverage Models
The general decision tree as shown in the following is used to determine the CF models to be used to model swath coverage.
6.2.1. VIIRS Swath Coverage
The data to be modeled is the Surface Reflectance (L2 Daily Swath product). These data are released as 6-minute swath data with two spatial resolutions of 750 m and 375 m at nadir [7] [8].
The decision flow on determining the model is shown in Figure 8. Model "multiband" may be used to all the bands of VIIRS.
The I-Bands of VNP09 Surface Reflectance can be modeled as follows.
dimensions:
time = 6496 ;
scan = 6400 ;
band = 3 ;
variables:
float band(band) ;
band:standard_name = "sensor_band_central_radiation_wavelength" ;
band:units = "μm" ;
float lat(time, scan) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(time, scan) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
double time(time) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float height(time, scan) ;
height:standard_name = “height" ;
height:units = “meters" ;
float swath_data(time, scan, band) ;
swath_data:coordinates = "lon lat" ;The M-Bands of VNP09 Surface Reflectance can be modeled as follows.
dimensions:
time = 3248 ;
scan = 3200 ;
band = 3 ;
variables:
float band(band) ;
band:standard_name = "sensor_band_central_radiation_wavelength" ;
band:units = "μm" ;
float lat(time, scan) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(time, scan) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
double time(time) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float height(time, scan) ;
height:standard_name = “height" ;
height:units = “meters" ;
float swath_data(time, scan, band) ;
swath_data:coordinates = "lon lat" ;The operational release of daily VIIRS radiance and surface reflectance is released by NOAA. The release of VIIRS radiance and surface reflectance is archived band by band. The decision tree result for modeling the product is as shown in Figure 9.
The SVI Bands of VIIRS (Radiance and Surface Reflectance) can be modeled as follows.
dimensions:
time = 6144 ;
scan = 6400 ;
variables:
float lat(time, scan) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(time, scan) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
double time(time) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float height(time, scan) ;
height:standard_name = “height" ;
height:units = “meters" ;
float saza(time, scan) ;
saza:standard_name = “SatelliteZenithAngle" ;
saza:units = “degrees" ;
float saaa(time, scan) ;
saaa:standard_name = “SatelliteAzimuthAngle" ;
saaa:units = “degrees" ;
float soza(time, scan) ;
soza:standard_name = “SolarZenithAngle" ;
soza:units = “degrees" ;
float soaa(time, scan) ;
soaa:standard_name = “SolarAzimuthAngle" ;
soaa:units = “degrees" ;
float sar(time, scan) ;
sar:standard_name = “SatelliteRange" ;
sar:units = “meters" ;
float swath_data(time, scan, band) ;
swath_data:coordinates = "lon lat" ;The SVM Bands of VIIRS (Radiance and Surface Reflectance) can be modeled as follows.
dimensions:
time = 3072 ;
scan = 3200 ;
variables:
float lat(time, scan) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(time, scan) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
double time(time) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float height(time, scan) ;
height:standard_name = “height" ;
height:units = “meters" ;
float saza(time, scan) ;
saza:standard_name = “SatelliteZenithAngle" ;
saza:units = “degrees" ;
float saaa(time, scan) ;
saaa:standard_name = “SatelliteAzimuthAngle" ;
saaa:units = “degrees" ;
float soza(time, scan) ;
soza:standard_name = “SolarZenithAngle" ;
soza:units = “degrees" ;
float soaa(time, scan) ;
soaa:standard_name = “SolarAzimuthAngle" ;
soaa:units = “degrees" ;
float sar(time, scan) ;
sar:standard_name = “SatelliteRange" ;
sar:units = “meters" ;
float swath_data(time, scan, band) ;
swath_data:coordinates = "lon lat" ;6.2.2. CloudSat Swath Coverage
Following through the decision tree, the model type is Profile, as shown in the section 2.5.3 in [4].
dimensions:
atrack = 20678;
xtrack = 125;
variables:
double time(atrack) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float lat(atrack) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(atrack) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
float swath_data(atrack, xtrack) ;
swath_data:coordinates = "time lon lat" ;6.2.3. MODIS Swath Coverage
The modeling decision results in "Multiband Image" as described in section 2.4.2 [4].
dimensions:
time = 1;
nrows = 2330;
ncols = 2030;
band = 16;
variables:
float band(band);
band:standard_name = "Retrieved_Temperature_Profile";
band:units = "K";
float lat(time, nrows, ncols);
lat:standard_name = "Geodetic Latitude";
lat:units = "degrees_north";
float lon(time, nrows, ncols);
lon:standard_name = "Geodetic Longitude";
lon:units = "degrees_east";
double time(time);
time:standard_name = "International Atomic Time at Start of Scan replicated ascross the Swath";
time:units = "s since 1 January 1993 00:00:00";
time:calendar = "gregorian";
float swath_data(time, nrows, ncols, band);
swath_data:coordinates = "lon lat";6.2.4. CALIPSO Swath Coverage
Following through the decision tree, the model type for CALIOP LIDAR swath coverage is Multiband Profile as shown in the section 2.5.3 in [4]. The decision tree result for modeling the product is as shown in Figure 10.
dimensions:
atrack = 63330;
z = 583
variables:
float Altitude(z) ;
alt:standard_name = “altitude”;
alt:long_name = "height above mean sea level" ;
alt:units = "km" ;
alt:positive = "up" ;
alt:axis = "Z" ;
double Profile_time(atrack) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float Latitude(atrack) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float Longitude(atrack) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
float Total_Attenuated_Backscatter_532(atrack, z) ;
swath_data:coordinates = "lon lat alt" ;
float Perpendicular_Attenuated_Backscatter_532(atrack, z) ;
swath_data:coordinates = "lon lat alt" ;
float Attenuated_Backscatter_1064(atrack, z) ;
swath_data:coordinates = "lon lat alt" ;7. Swath Coverage Models with OGC Coverage Implementation Schema
|
Note
|
Highlights
This section describes the modeling of swath coverage using Coverage Implementation Schema (CIS). The encoding of swath coverage in GML coverage is the target. |
7.1. Coverage Implementation Schema (CIS)
There are currently two versions of CIS, namely CIS version 1.0.1 and CIS version 1.1. In Testbed-14, CIS 1.1 was used to model the swath coverages. The reason for choosing version 1.1 is that it has more comprehensive capabilities in describing different coverages than version 1.0.1.
7.2. Swath Coverage Models
Two approaches were attempted to model swath coverages using CIS 1.1. One is based on extending the CIS definition of the Irregular grid class to support profiling swath. Another is use of the regular grid class, but leaving the geolocation attributes (including latitude/longitude/height/solar relative positions/satellite relative positions) to be mapped in rangeset fields.
In the subsequent subsections, different data types were attempted using both models. Example model results are provided. The pros and cons of the modeling approaches for different swath data types are discussed. In general, the following table summarizes the pros and cons of the two approaches. Method 1 (spatial domain) is the first model that directly model geographic coordinates as domain. Method 2 (spatial range) is the second model that model geographic reference coordinates in rangeset while the domain uses the coordinates of sensors.
| Pros | Cons | |
|---|---|---|
Method 1 (spatial domain) |
|
|
Method 2 (spatial range) |
|
|
7.3. CIS Modeling with Irregular Grid
The irregular grid model directly uses longitude/latitude as the domain to be modeled as irregular grids in CIS.
7.3.1. MODIS MOD07 Swath Coverage
|
Note
|
MODIS MOD07 Swath regular grids on spatial coordinates while the irregular resolution along the altitude axis. The number of pressure levels along the altitude axis is limited. The use of Method 1 (spatial domain) works well. |
Domainset
The following example shows a CIS modeling result.
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979%262=http://www.opengis.net/def/crs/OGC/0/AnsiDate" axisLabels="Lat Long h date">
<RegularAxis axisLabel="Lat" uomLabel="deg" lowerBound="24.785248" upperBound="27.685248" resolution="0.05"/>
<RegularAxis axisLabel="Long" uomLabel="deg" lowerBound="0.673578" upperBound="1.273578" resolution="0.05"/>
<IrregularAxis axisLabel="t" uomLabel="s">
<C>1514800500</C>
<C>1514800500</C>
</IrregularAxis>
<IrregularAxis axisLabel="Pressure" uomLabel="hPa">
<C>5.000000</C>
<C>10.000000</C>
<C>20.000000</C>
<C>30.000000</C>
<C>50.000000</C>
<C>70.000000</C>
<C>100.000000</C>
<C>150.000000</C>
<C>200.000000</C>
<C>250.000000</C>
<C>300.000000</C>
<C>400.000000</C>
<C>500.000000</C>
<C>620.000000</C>
<C>700.000000</C>
<C>780.000000</C>
<C>850.000000</C>
<C>920.000000</C>
<C>950.000000</C>
<C>1000.000000</C>
</IrregularAxis>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index4D" axisLabels="i j k l">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="11"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="57"/>
<IndexAxis axisLabel="k" lowerBound="0" upperBound="0"/>
<IndexAxis axisLabel="l" lowerBound="0" upperBound="1"/>
</GridLimits>
</GeneralGrid>
</DomainSet>RangeType
The following example shows a CIS modeling result.
<RangeSet>
<DataBlock>
<V><tuple_list_5_hpa></V>
<V>...</V>
<V><tuple_list_1000_hpa></V>
</DataBlock>
</RangeSet>
<RangeType>
<swe:DataRecord>
<swe:field name="panchromatic">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/unsignedInt">
<swe:uom code="10^0"/>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>7.3.2. VIIRS Swath Coverage
Domainset
|
Note
|
VIIRS Swath data are not geo-referenced. The spatial resolution for each pixel is irregular due to the aggregation measures used in the production of swath data. Each coordinate needs a pair of longitude and latitude to identify its location. The use of Method 1 (spatial domain) resulted in a domainset with large amount of geolocation data. |
The following example shows a CIS modeling result.
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long h">
<DisplacementAxisNest axisLabels="Lat Long Timescan" uomLabels="deg deg sec">
<P><C>-56.145405</C><C>69.62633</C><C>2018059113600000000</C></P> <P><C>-56.15058</C><C>69.61555</C><C>2018059113600000001</C></P> <P><C>-56.155754</C><C>69.60478</C><C>2018059113600000002</C></P>
<P><C>-56.13966</C><C>69.61745</C><C>2018059113600010000</C></P> <P><C>-56.14484</C><C>69.606674</C><C>2018059113600010001</C></P> <P><C>-56.150017</C><C>69.59592</C><C>2018059113600010002</C></P>
<P><C>-56.13392</C><C>69.608574</C><C>2018059113600020000</C></P> <P><C>-56.1391</C><C>69.59781</C><C>2018059113600020001</C></P> <P><C>-56.14427</C><C>69.58705</C><C>2018059113600020002</C></P>
</DisplacementAxisNest>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index1D" axisLabels="i">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="9"/>
</GridLimits>
</GeneralGrid>
</DomainSet>RangeType
The following example shows a CIS modeling result.
<RangeType>
<swe:DataRecord>
<swe:field name="BandI1">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/signedInt">
<swe:uom code="Reflectance/10000"/>
</swe:Quantity>
</swe:field>
<swe:field name="BandI2">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/signedInt">
<swe:uom code="Reflectance/10000"/>
</swe:Quantity>
</swe:field>
<swe:field name="BandI3">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/signedInt">
<swe:uom code="Reflectance/10000"/>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>7.3.3. CloudSat Swath Coverage
|
Note
|
CloudSat Swath data are not geo-referenced profiles. Each pixel has unique values along all axes of longitude, latitude, and altitude. The use of Method 1 (spatial domain) resulted in a domainset with large amount of geolocation data. |
Domainset
The following example shows a CIS modeling result.
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979&2=http://www.opengis.net/def/crs/OGC/0/AnsiDate" axisLabels="Lat Long h date">
<IrregularAxisNest axisLabels="Lat Long date" uomLabels="deg deg d">
<P><C>-69.35112</C><C>171.2182</C><C>46293.594+0.0</C></P>
<P><C>-69.35994</C><C>171.20651</C><C>46293.594+0.15999997</C></P>
... 20753 <P> elements with 3 <C> elements each in total
</IrregularAxisNest>
<DisplacementAxisNest axisLabels="h" uomLabels="m">
<P><C>24927</C></P>
<P><C>24687</C></P>
... 125 x 20753 <P> elements with 1 <C> element each in total
</DisplacementAxisNest>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="20752"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="124"/>
</GridLimits>
</GeneralGrid>
</DomainSet>RangeType
The following example shows a CIS modeling result.
<RangeType>
<swe:DataRecord>
<swe:field name="Radar_Reflectivity">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">15360</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="dBZe"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-32768 32767</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
<swe:field name="Gaseous_Attenuation">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">15360</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="dBZe"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-32768 32767</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
<swe:field name="CPR_Cloud_mask">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">-99</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="various"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-128 127</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>7.4. CIS Modeling with Regular Grid
The regular grid approach uses native along-track (normally time) and cross-track (normally scan) coordinates to define a grid while all geolocation fields are managed as rangeset fields.
7.4.1. VIIRS Swath Coverage
|
Note
|
VIIRS Swath data has a special rule for aggregation that resulted in different spatial resolution. The use of Method 2 (spatial range) needs specially predefined reference system that identify and reference the sensor coordinate systems with georeference systems. |
Domainset
The following example shows a CIS modeling result.
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/eo/VIIRS" axisLabels="Time Scan">
<RegularAxis axisLabel="Time" lowerBound="201805911360000" upperBound="201805911360007" uomLabel="YYYYDDDHHMMSSSS" resolution="1"/>
<RegularAxis axisLabel="Scan" lowerBound="0" upperBound="2" uomLabel="mgrad/sample" resolution="0.156"/>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="2"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="7"/>
</GridLimits>
</GeneralGrid>
</DomainSet>RangeType
The following example shows a CIS modeling result.
<RangeType>
<swe:DataRecord>
<swe:field name="Latitude">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/float">
<swe:uom code="deg"/>
</swe:Quantity>
</swe:field>
<swe:field name="Longitude">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/float">
<swe:uom code="deg"/>
</swe:Quantity>
</swe:field>
<swe:field name="Height">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/float">
<swe:uom code="m"/>
</swe:Quantity>
</swe:field>
<swe:field name="BandI1">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/signedInt">
<swe:uom code="Reflectance/10000"/>
</swe:Quantity>
</swe:field>
<swe:field name="BandI2">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/signedInt">
<swe:uom code="Reflectance/10000"/>
</swe:Quantity>
</swe:field>
<swe:field name="BandI3">
<swe:Quantity definition="http://www.opengis.net/def/dataType/OGC/0/signedInt">
<swe:uom code="Reflectance/10000"/>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>7.4.2. CloudSat Swath Coverage
|
Note
|
CloudSat Swath data are profiles. The use of Method 2 (spatial range) controls the size of domain dataset. However, the spatial operations of sub-setting can be demanding. Unique profile reference system for CloudSat needs to be defined for users to effectively use the service. |
Domainset
The following example shows a CIS modeling result.
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D"
axisLabels="atrack xtrack">
<RegularAxis axisLabel="atrack" lowerBound="0"
upperBound="20677" uomLabel="scan" resolution="1" />
<RegularAxis axisLabel="xtrack" lowerBound="0"
upperBound="124" uomLabel="scan" resolution="1" />
</GeneralGrid>
</DomainSet>RangeType
The following example shows a CIS modeling result.
<RangeType>
<swe:DataRecord>
<swe:field name="Timestamp">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="second" />
</swe:Quantity>
</swe:field>
<swe:field name="Latitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="degree" />
</swe:Quantity>
</swe:field>
<swe:field name="Longitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="degree" />
</swe:Quantity>
</swe:field>
<swe:field name="SwathData">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="some_unit" />
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>7.4.3. CALIPSO Swath Coverage
|
Note
|
CALIOP, the data from CALIPSO satellite, is a profile swath. Its modeling with Method 2 (spatial range) is similar to that for CloudSat. The further complexity for georeferencing and spatial sub-setting is resulted from the irregular coordinates due to the onboard aggregation scheme. |
The following example shows a CIS modeling result.
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D"
axisLabels="atrack xtrack">
<RegularAxis axisLabel="atrack" lowerBound="0"
upperBound="63329" uomLabel="scan" resolution="1" />
<RegularAxis axisLabel="z" lowerBound="0"
upperBound="582" uomLabel="scan" resolution="1" />
</GeneralGrid>
</DomainSet>RangeType
The following example shows a CIS modeling result.
<RangeType>
<swe:DataRecord>
<swe:field name="Profile_time">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="second" />
</swe:Quantity>
</swe:field>
<swe:field name="Latitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/float32">
<swe:uom code="degree" />
</swe:Quantity>
</swe:field>
<swe:field name="Longitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/float32">
<swe:uom code="degree" />
</swe:Quantity>
</swe:field>
<swe:field name="Altitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/float32">
<swe:uom code="km" />
</swe:Quantity>
</swe:field>
<swe:field name="Total_Attenuated_Backscatter_532">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="per kilometer per steradian" />
</swe:Quantity>
</swe:field>
<swe:field name="Perpendicular_Attenuated_Backscatter_532">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="per kilometer per steradian" />
</swe:Quantity>
</swe:field>
<swe:field name="Attenuated_Backscatter_1064">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="per kilometer per steradian" />
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>8. Swath Coverage Encoding
|
Note
|
Highlights
This section describes the encoding of a Swath Coverage in encodings other than CF and GML. The encoding formats include GeoTIFF, classic NetCDF, and GeoPackage. |
8.1. Overview
The previous two sections describe encodings of swath coverage in CF and GML coverages. This section describes the following additional encodings of swath coverage experimented in Testbed 14. They are as follows.
-
GeoTIFF
-
GeoPackage
In the testbed, the participants also attempted to fully utilize the available formats in the well-known GDAL library to encode swath coverage. These included using its HDF4Image driver and NetCDF driver. The experience on encoding swath coverage is also discussed in this section.
8.2. GeoTIFF Encoding
In most cases, a swath coverage contains the following data or layers:
-
Geolocation layers, such as latitude, longitude, height, sensor angular position (e.g. satellite zenith angle, satellite azimuth, range to the satellite), and relative positions of radiance sources to be measured (e.g. solar zenith angle, solar azimuth, or (for night-time passive remote sensing) lunar zenith angle, lunar azimuth, and lunar phase);
-
Measurement layers or sensed digital numbers;
-
Mapping relationships between geolocations and measurements that relate the geolocations to each measurement.
These three reasons lead to using separate files to encode geolocations and measurements. Geolocations can be recorded in float or any other decimal numbers while measurement is recorded as digital numbers in integers (such as short integer). The data type for geolocation is generally different from that for measurements. Besides, geolocation layers may not have the same dimension as measurement layers. The most complex relationship between geolocations and measurements may need to have one-to-one mapping at the level of individual pixels. In other cases, one dimension of latitude and one dimension of longitude may be enough to form the axes to be mapped to two dimensions of measurement data. In addition, existing software packages may have limitations on the data layers. For example, GDAL, the commonly used raster data library, does support mixed types of layers in GeoTIFF files.
The following gives an example of encoding swath coverages for VIIRS Level 2 data where two files are generated to keep track. Listing 1 shows the encoding for its geolocations. Listing 2 shows the encoding for its data. A simple one-to-one mapping relationship is assumed to relate geolocations to measurements. To facilitate the cross-reference of relative locations of the pixels towards its nadir in subsets of a data granule, the offset of each axis to the full scene origin is recorded and added as metadata.
river: GTiff/GeoTIFF
Files: VNP09.IBands.A2018115.1612.001_loc.tif
Size is 6400, 6464
Coordinate System is `'
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 6464.0)
Upper Right ( 6400.0, 0.0)
Lower Right ( 6400.0, 6464.0)
Center ( 3200.0, 3232.0)
Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
Description = Latitude
Metadata:
LineOffset=0
ScanOffset=0
TimeOffset=0
Band 2 Block=256x256 Type=Float32, ColorInterp=Undefined
Description = Longitude
Metadata:
LineOffset=0
ScanOffset=0
TimeOffset=0
Band 3 Block=256x256 Type=Float32, ColorInterp=Undefined
Description = Height
Metadata:
LineOffset=0
ScanOffset=0
TimeOffset=0Driver: GTiff/GeoTIFF
Files: VNP09.IBands.A2018115.1612.001_data.tif
Size is 6400, 6464
Coordinate System is `'
Image Structure Metadata:
COMPRESSION=LZW
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 6464.0)
Upper Right ( 6400.0, 0.0)
Lower Right ( 6400.0, 6464.0)
Center ( 3200.0, 3232.0)
Band 1 Block=256x256 Type=Int16, ColorInterp=Gray
Description = 375m Surface Reflectance Band I1
Offset: 0, Scale:0.00100000004749745
Metadata:
LineOffset=0
ScanOffset=0
TimeOffset=0
Band 2 Block=256x256 Type=Int16, ColorInterp=Undefined
Description = 375m Surface Reflectance Band I2
Offset: 0, Scale:0.00100000004749745
Metadata:
LineOffset=0
ScanOffset=0
TimeOffset=0
Band 3 Block=256x256 Type=Int16, ColorInterp=Undefined
Description = 375m Surface Reflectance Band I3
Offset: 0, Scale:0.00100000004749745
Metadata:
LineOffset=0
ScanOffset=0
TimeOffset=08.3. GeoPackage Encoding
Similarly, with the same consideration as those for GeoTIFF, different GeoPackages are used to manage different layers. Furthermore, being limited by the current support of GDAL on encoding non-integer data to one layer, the testbed participants experimented with the encoding of swath coverage with one layer in one GeoPackage file. Listing 3 shows the encoding for the geolocations associated with the data layer. Listing 4 shows the encoding for its data. However, the GDAL driver does not write out the metadata as programmed. An auxiliary file is needed to support the metadata. Besides, the GeoPackage driver defaults to creating tiled raster image. The un-georeferenced swath data is not supported for tiling. Further studies on encoding swath coverages are needed. If GDAL is still considered as the library to work on different swath coverage, the GPKG driver of GDAL needs to be enhanced to support non-tiled data; for example, through support for the OGC GeoPackage Extension for Tiled Gridded Coverage Data (17-066r1). The encoding with GeoPackage needs to be further studied as well, to properly manage swath data for both visualization and data access.
Driver: GPKG/GeoPackage
Files: VNP09.IBands.A2018115.1612.001_loc.gpkg.latitude.gpkg
Size is 6400, 6464
Coordinate System is `'
Origin = (0.000000000000000,6464.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
IDENTIFIER=VNP09.IBands.A2018115.1612.001_loc.gpkg.latitude
ZOOM_LEVEL=5
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.000, 6464.000)
Lower Left ( 0.0000000, 0.0000000)
Upper Right ( 6400.000, 6464.000)
Lower Right ( 6400.000, 0.000)
Center ( 3200.000, 3232.000)
Band 1 Block=256x256 Type=Float32, ColorInterp=UndefinedDriver: GPKG/GeoPackage
Files: VNP09.IBands.A2018115.1612.001_data.gpkg.band1.gpkg
Size is 6400, 6464
Coordinate System is `'
Origin = (0.000000000000000,6464.000000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
IDENTIFIER=VNP09.IBands.A2018115.1612.001_data.gpkg.band1
ZOOM_LEVEL=5
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.000, 6464.000)
Lower Left ( 0.0000000, 0.0000000)
Upper Right ( 6400.000, 6464.000)
Lower Right ( 6400.000, 0.000)
Center ( 3200.000, 3232.000)
Band 1 Block=256x256 Type=Int16, ColorInterp=Undefined8.4. Encodings with GDAL drivers
Encoding Swath Coverage with GDAL HDF4Image Driver
HDFEOS2 and HDFEOS5 natively support the encoding of swath data since it has a special data type as swath in addition to grid and point [9] [10] [11] [12]. However, the data are encoded differently for different sensors and datasets. In this testbed, GDAL was used as the primary library to support data input and output. For writing out, GDAL currently only has an HDF4Image driver which does not have the full operation to encode swath coverage. This leads to this section on encoding swath coverage in HDF4.
Using the same three reasons as those stated for GeoTIFF - data type difference, dimension difference, and existing software support - the encoding of geolocation and measurements are stored in separate files. Similarly, metadata for keeping track of the offsets in each dimension for sub-setting are encoded and stored. Listing 5 shows the encoding for its geolocations. Listing 6 shows the encoding for its data. With the GDAL library used in the testbed, the metadata are not directly added to each layer, but saved as an auxiliary xml file, as shown as one example in Listing 7.
Driver: HDF4Image/HDF4 Dataset
Files: VNP09.IBands.A2018115.1612.001_loc.hdf
VNP09.IBands.A2018115.1612.001_loc.hdf.aux.xml
Size is 6400, 6464
Coordinate System is `'
Origin = (0.000000000000000,0.000000000000000)
Pixel Size = (1.000000000000000,1.000000000000000)
Metadata:
BandDesc1=Latitude
BandDesc2=Longitude
BandDesc3=Height
Signature=Created with GDAL (http://www.remotesensing.org/gdal/)
TransformationMatrix=0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Corner Coordinates:
Upper Left ( 0.0000000, 0.0000000)
Lower Left ( 0.000, 6464.000)
Upper Right ( 6400.000, 0.000)
Lower Right ( 6400.000, 6464.000)
Center ( 3200.000, 3232.000)
Band 1 Block=6400x156 Type=Float32, ColorInterp=Gray
Description = Latitude
Band 2 Block=6400x156 Type=Float32, ColorInterp=Gray
Description = Longitude
Band 3 Block=6400x156 Type=Float32, ColorInterp=Gray
Description = HeightDriver: HDF4Image/HDF4 Dataset
Files: VNP09.IBands.A2018115.1612.001_data.hdf
VNP09.IBands.A2018115.1612.001_data.hdf.aux.xml
Size is 6400, 6464
Coordinate System is `'
Origin = (0.000000000000000,0.000000000000000)
Pixel Size = (1.000000000000000,1.000000000000000)
Metadata:
BandDesc1=375m Surface Reflectance Band I1
BandDesc2=375m Surface Reflectance Band I2
BandDesc3=375m Surface Reflectance Band I3
Signature=Created with GDAL (http://www.remotesensing.org/gdal/)
TransformationMatrix=0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
Corner Coordinates:
Upper Left ( 0.0000000, 0.0000000)
Lower Left ( 0.000, 6464.000)
Upper Right ( 6400.000, 0.000)
Lower Right ( 6400.000, 6464.000)
Center ( 3200.000, 3232.000)
Band 1 Block=6400x156 Type=Int16, ColorInterp=Gray
Description = 375m Surface Reflectance Band I1
Band 2 Block=6400x156 Type=Int16, ColorInterp=Gray
Description = 375m Surface Reflectance Band I2
Band 3 Block=6400x156 Type=Int16, ColorInterp=Gray
Description = 375m Surface Reflectance Band I3<PAMDataset>
<PAMRasterBand band="1">
<Description>375m Surface Reflectance Band I1</Description>
<Scale>0.001000000047497451</Scale>
<Metadata>
<MDI key="LineOffset">0</MDI>
<MDI key="ScanOffset">0</MDI>
<MDI key="TimeOffset">0</MDI>
</Metadata>
</PAMRasterBand>
<PAMRasterBand band="2">
<Description>375m Surface Reflectance Band I2</Description>
<Scale>0.001000000047497451</Scale>
<Metadata>
<MDI key="LineOffset">0</MDI>
<MDI key="ScanOffset">0</MDI>
<MDI key="TimeOffset">0</MDI>
</Metadata>
</PAMRasterBand>
<PAMRasterBand band="3">
<Description>375m Surface Reflectance Band I3</Description>
<Scale>0.001000000047497451</Scale>
<Metadata>
<MDI key="LineOffset">0</MDI>
<MDI key="ScanOffset">0</MDI>
<MDI key="TimeOffset">0</MDI>
</Metadata>
</PAMRasterBand>
</PAMDataset>Encoding Swath Coverage with GDAL netCDF Driver
The GDAL (version 2.3 used in the testbed) has an old netCDF driver. It supports CF 1.5. The writer of the driver has limited capabilities similar to HDF4Image driver.The output model of NetCDF is "classic", or commonly labeled as "NetCDF-3". The testbed participants experimented with encoding the swath coverage data using the driver by generating separate geolocation file and data file. Listing 8 shows the encoding for its geolocations. Listing 9 shows the encoding for its data. The metadata were also programmed to be written out. However, examining the output of netCDF file, the additional metadata are not written out. The metadata may be appended as separate files to be packed into one package to support the extra metadata.
Driver: netCDF/Network Common Data Format
Files: VNP09.IBands.A2018115.1612.001_loc.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#Conventions=CF-1.5
NC_GLOBAL#GDAL=GDAL 2.3.2, released 2018/09/21
NC_GLOBAL#history=Tue Oct 09 15:31:42 2018: GDAL Create( /home/eugene/ogcwksp/wksp/GMUWCS21/temp/VNP09.IBands.A2018115.1612.001_loc.nc, ... )
Subdatasets:
SUBDATASET_1_NAME=NETCDF:"VNP09.IBands.A2018115.1612.001_loc.nc":Band1
SUBDATASET_1_DESC=[6464x6400] Band1 (32-bit floating-point)
SUBDATASET_2_NAME=NETCDF:"VNP09.IBands.A2018115.1612.001_loc.nc":Band2
SUBDATASET_2_DESC=[6464x6400] Band2 (32-bit floating-point)
SUBDATASET_3_NAME=NETCDF:"VNP09.IBands.A2018115.1612.001_loc.nc":Band3
SUBDATASET_3_DESC=[6464x6400] Band3 (32-bit floating-point)Driver: netCDF/Network Common Data Format
Files: VNP09.IBands.A2018115.1612.001_data.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#Conventions=CF-1.5
NC_GLOBAL#GDAL=GDAL 2.3.2, released 2018/09/21
NC_GLOBAL#history=Tue Oct 09 15:31:25 2018: GDAL Create( /home/eugene/ogcwksp/wksp/GMUWCS21/temp/VNP09.IBands.A2018115.1612.001_data.nc, ... )
Subdatasets:
SUBDATASET_1_NAME=NETCDF:"VNP09.IBands.A2018115.1612.001_data.nc":Band1
SUBDATASET_1_DESC=[6464x6400] Band1 (16-bit integer)
SUBDATASET_2_NAME=NETCDF:"VNP09.IBands.A2018115.1612.001_data.nc":Band2
SUBDATASET_2_DESC=[6464x6400] Band2 (16-bit integer)
SUBDATASET_3_NAME=NETCDF:"VNP09.IBands.A2018115.1612.001_data.nc":Band3
SUBDATASET_3_DESC=[6464x6400] Band3 (16-bit integer)9. WCS Swath Coverage Profile
|
Note
|
Highlights
This section captures the special profiles needed for WCS to server Swath Coverage. |
9.1. Scope
This section provides recommendations in implementing a Swath Coverage as a Profile (with extensions) to WCS to easily access Swath Coverages, based on the requirements, experiments, and tests in this OGC testbed.
These profiles and extensions were defined in reference to WCS 2.0.1 and CIS 1.1.
9.2. Conformance
The following are the conformance classes defined in this specification.
-
Swath Coverage Extension
-
Swath GeoTiff Coverage Conformance Class
-
Swath NetCDF Coverage Conformance Class
-
Swath GeoPackage Coverage Conformance Class
9.3. Swath Coverage Extension
Requirement SCE1 - Support of time dimension
| Requirement | SCE1 |
|---|---|
Requirement Name |
/req/core/sce1 |
Description |
Swath coverage is often along the time axis. The support of sub-setting against time is required. The request imposes the explicit use of time as a bounding dimension in describing the coverage. |
Requirement SCE2 - Encoding of Swath coverage
| Requirement | SCE2 |
|---|---|
Requirement Name |
/req/core/sce2 |
Description |
The encoding of swath coverage should assure the correct cross-referencing among time, cross-track scan, and relative positions among sensors, ground targets, and suns (or the primary source of radiance). |
9.4. Swath GeoTiff Coverage
| Requirement | SEEG1 |
|---|---|
Requirement Name |
/req/ext/geotiff/seeg1 |
Description |
The encoding of swath coverage in geotiff is supported with this extension. Considering the difference of data types in geolocation layers and reflectance layers, two geotiff files may be used to encode them separately. By default, the one-to-one relationship between pixel from geolocation layers and that from reflectance layers should be supported unless an explicit mapping relationship is defined. |
9.5. Swath NetCDF Coverage
| Requirement | SEEN1 |
|---|---|
Requirement Name |
/req/ext/netcdf/seen1 |
Description |
The encoding of swath coverage in netCDF is supported with this extension. Considering the difference of data types in geolocation layers and reflectance layers and readily available support from existing software packages, two NetCDF files may be used to encode them separately. By default, the one-to-one relationship between pixel from geolocation layers and that from reflectance layers should be supported unless an explicit mapping relationship is defined. The CF 1.8 along with the developing extension for swath coverage may be used to encode the coverage as a swath. If the swath coverage extension for CF is used, a single file would be sufficient to manage both geolocation properties and measurement properties. |
9.6. Swath GeoPackage Coverage
| Requirement | SEEGPKG1 |
|---|---|
Requirement Name |
/req/ext/geopackage/seegpkg1 |
Description |
The encoding of swath coverage in geopackage is supported with this extension. Considering the difference of data types in geolocation layers and reflectance layers and readily available support of open-source program (such as GDAL), each layer may be encoded in different geopackage files. By default, the one-to-one relationship between pixel from all layers - either geolocation layers and data layers - should be supported. |
10. WCS REST API
|
Note
|
Highlights
This section brief describes the principles for designing the WCS REST API and the major paths. Full details can be found in Appendix B. |
10.1. Scope and Design Principle
The following specification provides recommendations for implementing a RESTful API as an alternative interface service to a Web Coverage Service. The RESTful API is designed and documented following the OpenAPI 3.0.1 specification. The core resource is on coverage.
The REST API is based on OpenAPI version 3.0.1 (URL: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md ). This leads to the following fixed value of the OpenAPI document. OpenAPI documents can be defined in either JSON or YAML (Version 1.2).
The WFS 3.0 development team introduced their experience in developing RESTful API for WFS. This work formed the base for the development of the draft specification of a WCS REST API. The API is designed with modules and extensions. The API core defines the basic paths while all the other requirements are set as extensions or conformance classes. If the service claims to conform to certain modular class, the requirements of that compliant conformance class should be met by the service. The requirements are grouped into levels of conformance that the implementation of the service claims to conform to.
10.2. Conformance
The following mentions all the conformance classes to be defined in this specification.
-
Core Conformance Class: This standard defines six requirements / conformance classes.
-
Range Sub-setting Extension Conformance Class.
-
Earth Observation Extension Conformance Class.
-
Transaction Insertion Deletion Conformance Class.
-
Transaction Update Conformance Class.
-
GeoTiff Coverage Conformance Class.
-
NetCDF Coverage Conformance Class.
-
GeoPackage Coverage Conformance Class.
10.3. Main Paths
The resources managed by the draft WCS REST API are mainly grouped into two categories. One category is metadata that is more or less corresponding to that described in the WCS operations GetCapabilities and DescribeCoverage. Another category is the data itself. This is related to the current WCS operation GetCoverage. The following table lists the major paths and their primary purpose.
| PATH | METHOD | DESCRIPTION |
|---|---|---|
/ |
GET |
Gets the landing page in the requested representation |
/api |
GET |
Gets the API description (i.e. OpenAPI document) |
/conformance |
GET |
Gets conformance classes that server implements |
/coverages |
GET |
Gets the description/metadata of all the coverages offered by the system |
/coverages/{coverageId} |
GET |
Gets the description/metadata of the specific coverage |
/coverages/{coverageId}/rangeSet |
GET |
Gets the coverage or a subset thereof |
In the context of the WCS REST API design experiment, the resources are identified by paths. Each path uniquely identifies a resource. For example, the root path / identifies the entry point which returns a document containing links to other resources - i.e. specifications identified by "/api", conformance declaration (identified by "/conformance"), and list of coverages (identified by "/coverages"). The coverage description of each coverage is identified as "/coverages/{coverageId}" while the actual data of a coverage is identified as "/coverages/{coverageId}/rangeSet". The paths are unique identifiers for different resources.
The resources can be traversed through following the hyperlinks in the content from the root endpoint (root path). For example, the response from the root path would contain links to hyperlinks to API specification document, conformance, and list of coverages. Once transferred to the resource that lists coverages, its content provides hyperlinks allowing users to traverse and find resources for coverage descriptions and coverage data. When coverage descriptions are in media types other than HTML, users need to use the schema to follow through the resources.
10.4. Service root path /
10.4.1. Get Operation
| Requirement | C1 |
|---|---|
Requirement Name |
/req/core/rootpath-get |
Path |
/ |
Headers |
Accept: application/json |
Accept: text/html |
|
Accept: application/xml |
|
Description |
The server SHALL support the HTTP GET operation at the path /. Three media types may be supported: application/json, application/xml, and text/html. |
10.6. Service OpenAPI path /conformance
10.6.1. Get Operation
| Requirement | C3 |
|---|---|
Requirement Name |
/req/core/conformancepath-get |
Path |
/conformance |
Headers |
Accept: application/json |
Accept: text/html |
|
Accept: application/xml |
|
Description |
The server SHALL support the HTTP GET operation at the path /conformance. The response shall list http://www.opengis.net/spec/wcs-2/3.0/req/core as the conformance class when the core class is implemented, where wcs-2 identifies the version of WCS and 3.0 identifies the version of OpenAPI. |
10.7. Service OpenAPI path /coverages
10.7.1. Get Operation
| Requirement | C4 |
|---|---|
Requirement Name |
/req/core/coveragespath-get |
Path |
/coverages |
Headers |
Accept: application/json |
Accept: text/html |
|
Accept: application/xml |
|
Parameters |
q – in query, string, keywords search |
bbox – in path, comma-separated bounding box defined by { west, south, min. height, east, north, max. height} |
|
time – in path, comma-separated time bounded with earliest and latest. |
|
startIndex – in query, integer, the start index for returned coverages. |
|
count – in query, integer, number of coverages to be returned counting start from startIndex |
|
Description |
The server SHALL support the HTTP GET operation at the path /coverages. The default number of items is 10. If there are less than 10 coverages served in the WCS, the actual number of items are listed. |
10.8. Service OpenAPI path /coverages/{coverageId}
10.8.1. Get Operation
| Requirement | C4 |
|---|---|
Requirement Name |
/req/core/coverages/coverageidpath-get |
Path |
/coverages/{coverageId} |
Parameters |
coverageId – in path, string, identifier of the coverage. |
Description |
The server SHALL support the HTTP GET operation at the path /coverages/{coverageId}. It returns the metadata for the coverage identified by {coverageId}. |
10.9. Service OpenAPI path /coverages/{coverageId}/rangeSet
10.9.1. Get Operation
| Requirement | C4 |
|---|---|
Requirement Name |
/req/core/coverages/coverageidpath/rangeSet-get |
Path |
/coverages/{coverageId}/rangeSet |
Headers |
Accept: application/gml+xml |
Parameters |
coverageId – in path, string, identifier of the coverage. |
subset – in path, in the format of dimension(trimlow,trimhigh) or dimension(slicepoint) |
|
Description |
The server SHALL support the HTTP GET operation at the path /coverages/{coverageId}/rangeSet. It returns the metadata for the coverage identified by {coverageId}. |
11. Swath Coverage Use Cases
|
Note
|
Highlights
This section describes the example implementations of Swath WCS and clients. Typical use cases will be covered here. |
11.1. Implementations of Swath WCS
Several teams are engaged in implementing the draft WCS Swath Coverage Profile. The implementation environment and basic system take different forms.
11.1.1. CloudSat Level 2 Profile Swath Data
Data Processing Levels
EOSDIS data products are processed at various levels ranging from Level 0 to Level 4. Level 0 products are raw data at full instrument resolution. At higher levels, the data are converted into more useful parameters and formats. All EOS instruments must have Level 1 products. Most have products at Levels 2 and 3, and many have products at Level 4.
Level 2 data derived geophysical variables at the same resolution and location as Level 1 source data.
2B-GEOPROF Data
The testbed participants investigated a level 2 profile data named 2B GEOPROF. The 2B GEOPROF product identifies those levels in the vertical column sampled by CloudSat that contain significant radar echo from hydrometeors (rather than noise or radar clutter) and provides an estimate of the radar reflectivity factor for each of these volumes. Also included in the GEOPROF product is an estimate of the expected gaseous absorption loss for the observed reflectivity (which depends on water vapor fields from ECMWF), the MODIS cloud fraction (from MOD35) associated with the radar surface foot print, and several other flags the indicates the homogeneity of the MODIS data, and quality of the CloudSat data. The data fields are listed in the tables below:
Data Fields
| Popup | Type | Dimensions | Units | Range | Missing | |
|---|---|---|---|---|---|---|
--------------------------- |
--------- |
------------ |
-------- |
--------------- |
--------- |
|
Clutter_reduction_flag |
INT(1) |
nray |
||||
CPR_Cloud_mask |
INT(1) |
nbin,nray |
-9 |
|||
CPR_Echo_Top |
INT(1) |
nray |
-9 |
|||
Data_quality |
UINT(1) |
nray |
— |
0 to 127 |
||
Data_status |
UINT(1) |
nray |
— |
0 to 127 |
||
Data_targetID |
UINT(1) |
nray |
— |
0 to 81 |
||
Gaseous_Attenuation |
INT(2) |
nbin,nray |
dBZe |
-99.99 |
||
MODIS_cloud_flag |
INT(1) |
nray |
None |
99 |
||
MODIS_Cloud_Fraction |
INT(1) |
nray |
-99 |
|||
MODIS_scene_char |
INT(1) |
nray |
-9 |
|||
MODIS_scene_var |
INT(1) |
nray |
-9 |
|||
Navigation_land_sea_flag |
UINT(1) |
nray |
— |
1 to 3 |
||
Radar_Reflectivity |
INT(2) |
nbin,nray |
dBZe |
-40 to 50 |
-88.88 |
|
sem_NoiseFloor |
REAL(4) |
nray |
0 |
|||
sem_NoiseFloorVar |
REAL(4) |
nray |
0 |
|||
sem_NoiseGate |
INT(1) |
nray |
0 |
|||
Sigma-Zero |
INT(2) |
nray |
dB*100 |
-1000 to 4000 |
-9999 |
|
SurfaceHeightBin |
INT(1) |
nray |
1 to 125 |
-1 |
||
SurfaceHeightBin_fraction |
REAL(4) |
nray |
none |
0 |
Geolocation Fields
| Popup | Type | Dimensions | Units | Range | Missing | |
|---|---|---|---|---|---|---|
-------------------- |
--------- |
------------ |
--------- |
---------------- |
--------- |
|
DEM_elevation |
INT(2) |
nray |
meters |
-9999 to 8850 |
9999 |
|
Height |
INT(2) |
nbin,nray |
m |
-5000 to 30000 |
-9999 |
|
Latitude |
REAL(4) |
nray |
degrees |
-90 to 90 |
||
Longitude |
REAL(4) |
nray |
degrees |
-180 to 180 |
||
Pitch_offset |
REAL(4) |
<scalar> |
degrees |
-90 to 90 |
||
Profile_time |
REAL(4) |
nray |
seconds |
0 to 6000 |
||
Range_to_intercept |
REAL(4) |
nray |
km |
600 to 800 |
||
Roll_offset |
REAL(4) |
<scalar> |
degrees |
-90 to 90 |
||
TAI_start1 |
REAL(8) |
<scalar> |
seconds |
0 to 6e+008 |
||
UTC_start2 |
REAL(4) |
<scalar> |
seconds |
0 to 86400 |
||
Vertical_binsize |
REAL(4) |
<scalar> |
m |
to |
-9999 |
-
TAI_Start: The TAI timestamp for the first profile in the data file. TAI is International Atomic Time: seconds since 00:00:00 Jan 1 1993.
-
UTC_Start: The UTC seconds since 00:00 Z of the first profile in the data file.
For instance, a visualization for variable “Radar Reflectivity” of CloudSat 2B-GEOPROF is demonstrated in Figure 11.
11.1.2. Modeling with CF Convention
Climate and Forecast (CF) convention document is available at: https://github.com/Unidata/EC-netCDF-CF/blob/master/swath/swath.adoc#image-profile
According to section 2.5.3. Profile, this data is modeled as follows:
dimensions:
atrack = 20678;
xtrack = 125;
variables:
double time(atrack) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float lat(atrack) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(atrack) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
float swath_data(atrack, xtrack) ;
swath_data:coordinates = "time lon lat" ;11.1.3. CloudSat Swath WCS Implementation I
This section describes the implementation done by EOX. They identified the following requirements for implementing the swath WCS to serve CloudSat data:
-
Service requirements - The service shall support:
-
retrieval of product metadata needed for visualization components, such as 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 ),
-
and, retrieval of "overviews" for performance optimization.
-
-
Format requirements - The data format shall be:
-
self-describing to specify for example if the data is encoded as pixel-in-center or pixel-in-corner,
-
and, readable and interpretable in modern web browsers with existing libraries.
-
Modeling the CloudSat Swath Data Service using CIS 1.1
Retrieval of metadata
The standard WCS DescribeCoverage response contains all information needed to satisfy the requirement on metadata retrieval. 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 and space.
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 GeneralGrid this information is present in the GridLimits element.
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 DescribeEOCoverageSet 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 potentially huge DomainSet. To avoid unnecessary large downloads, the client would either need to query a synchronized catalog or a change of the DescribeCoverage operation allowing limits to the response.
We propose providing the DomainSet axes information as coverages themselves via OGC Web Services Context (OWC) encoding. This way the DomainSet stays as small as possible while still providing the needed metadata. Additionally, by providing the axes information as coverages themselves allows direct subsetting of the domain. Thus, clients have a means to only download the needed information at the cost of additional GetCoverage requests to the DomainSet coverages.
A discarded idea was to add a boolean parameter named restrictDomainSet to the DescribeCoverage and 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 GeneralGrid of the DomainSet omitting the remainder.
An additional idea, not used in 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 retrieving only the relevant parts of the DomainSet in the same way as the RangeSet.
Note that a general XPath extension to WCS was 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 being held back by the OGC Architecture Board as the proposal is seen as potentially beneficial to more OGC services and should get a broader scope.
Parameter subsetting
The requirement of parameter subsetting is simply satisfied by the band subsetting extension of WCS.
Temporal and spatial subsetting
Trimming and slicing of any axis defined in the DomainSet is standardized in the WCS core. The difficulty with the data at hand is to define a suitable DomainSet that contains time and spatial axes in order to support both temporal and spatial subsetting requirements.
The 2B-GEOPROF data provides the parameters in a 2D grid with size 125 x nray where nray is typically around 20.000. Each of the ~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 DisplacementAxisNest and IrregularAxis. However, only the DisplacementAxisNest supports to "get rid" of axes but which would unnecessarily 'blow up' (i.e. increasing the size to the point of being unmanagable) the DomainSet description 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" ~20.000 times this would blow up to multiplying this 125 times:
DomainSet using DisplacementAxisNest<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979&2=http://www.opengis.net/def/crs/OGC/0/AnsiDate" axisLabels="Lat Long h date">
<DisplacementAxisNest axisLabels="Lat Long date h" uomLabels="deg deg d m">
<P><C>-69.35112</C><C>171.2182</C><C>46293.594+0.0</C><C>24927</C></P>
<P><C>-69.35112</C><C>171.2182</C><C>46293.594+0.0</C><C>24687</C></P>
...
<P><C>-69.35112</C><C>171.2182</C><C>46293.594+0.0</C><C>-4812</C></P>
<P><C>-69.35994</C><C>171.20651</C><C>46293.594+0.15999997</C><C>24929</C></P>
<P><C>-69.35994</C><C>171.20651</C><C>46293.594+0.15999997</C><C>24689</C></P>
...
<P><C>-69.35994</C><C>171.20651</C><C>46293.594+0.15999997</C><C>-4810</C></P>
... 125 x 20753 <P> elements with 4 <C> elements each in total
</DisplacementAxisNest>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="20752"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="124"/>
</GridLimits>
</GeneralGrid>
</DomainSet>In order not to unnecessarily blow up the DomainSet an IrregularAxisNest element similar to DisplacementAxisNest and allowing to exploit the conformity of the columns is proposed as follows:
DomainSet using IrregularAxisNest extension<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979&2=http://www.opengis.net/def/crs/OGC/0/AnsiDate" axisLabels="Lat Long h date">
<IrregularAxisNest axisLabels="Lat Long date" uomLabels="deg deg d">
<P><C>-69.35112</C><C>171.2182</C><C>46293.594+0.0</C></P>
<P><C>-69.35994</C><C>171.20651</C><C>46293.594+0.15999997</C></P>
... 20753 <P> elements with 3 <C> elements each in total
</IrregularAxisNest>
<DisplacementAxisNest axisLabels="h" uomLabels="m">
<P><C>24927</C></P>
<P><C>24687</C></P>
... 125 x 20753 <P> elements with 1 <C> element each in total
</DisplacementAxisNest>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="20752"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="124"/>
</GridLimits>
</GeneralGrid>
</DomainSet>Using this IrregularAxisNest extension would allow instead of 125 x 20753 P elements with 4 C elements each to have only 20753 P with 3 C elements and 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" using OWC, the resulted service achieved 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 Index1D coverages corresponding to latitude, longitude, and date. This way the reported DomainSet stays small while supporting all required functionality even subsetting in the domain.
DomainSet using IrregularAxisNest and "axes as coverages via OWC" extension<DomainSet>
<GeneralGrid axisLabels="Lat Long h date" srsName="http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979&amp;2=http://www.opengis.net/def/crs/OGC/0/AnsiDate">
<DisplacementAxisNest axisLabels="h" uomLabels="m">
<owc:offering>
<owc:operation code="GetCoverage" href="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_height&format=image/tiff" method="GET" type="image/tiff"/>
</owc:offering>
</DisplacementAxisNest>
<IrregularAxisNest axisLabels="Lat Long date" uomLabels="deg deg d">
<owc:offering>
<owc:operation code="GetCoverage" href="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_latitude&format=text/csv" method="GET" type="text/csv"/>
</owc:offering>
<owc:offering>
<owc:operation code="GetCoverage" href="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_longitude&format=text/csv" method="GET" type="text/csv"/>
</owc:offering>
<owc:offering>
<owc:operation code="GetCoverage" href="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_profile_time&format=text/csv" method="GET" type="text/csv"/>
</owc:offering>
</IrregularAxisNest>
<GridLimits axisLabels="i j" srsName="http://www.opengis.net/def/crs/OGC/0/Index2D">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="124"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="20752"/>
</GridLimits>
</GeneralGrid>
</DomainSet>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.
The adjusted schema to support the IrregularAxisNest extension can be found in Appendix A.
Overviews
The requirement on providing overviews 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 axes 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 GetCoverage operation.
The coverage description needs to include these details:
-
resolution in all CRS axes, i.e., the minimum distance needed on each axis to correctly represent the data
-
size of data array - provided in `GridLimits`element
-
bounding box or maxima in each CRS axis - provided in
Envelopeelement -
mapping from CRS to data array, i.e., how are the axes related - provided in axis elements like
IrregularAxisNestorDisplacementAxisNestinGeneralGrid
The GetCoverage operation needs to be extended by these parameters:
-
changeType-booleanto indicate type conversion -
axesMapping- mapping for each axis, i.e.,iorxshall betimeorlatorlongandjoryshall beheight, e.g.,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 size or resolution parameters.
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.
11.1.4. CloudSat Swath WCS Implementation II
This section describes the implementation of CloudSat Swath WCS done by the team from Arizona State University.
Modeling CloudSat Swath Coverage with CIS 1.1
The CloudSat Swath Coverage can be further encoded in GML for publishing as follows, referring to version 3.2.1 of the OpenGIS Geography Markup Language (GML) Encoding Standard:
<CloudSatSwathProfile xmlns="http://www.opengis.net/app"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/app ./CoverageExamples.xsd">
<gml:domainSet>
<gml:Grid dimension="2">
<gml:limits>
<gml:GridEnvelope>
<gml:low>0 0</gml:low>
<gml:high>20678 125</gml:high>
</gml:GridEnvelope>
</gml:limits>
<gml:axisLabels>atrack xtrack</gml:axisLabels>
</gml:Grid>
</gml:domainSet>
<gml:rangeSet>
<gml:DataBlock>
<gml:rangeParameters>
<gml:CompositeValue>
<gml:valueComponents>
<Timestamp uom="urn:x-si:v1999:uom:seconds">template</Timestamp>
<Longitude uom="urn:x-si:v1999:uom:degrees">template</Longitude>
<Latitude uom="urn:x-si:v1999:uom:degrees">template</Latitude>
<SwathData>template</SwathData>
</gml:valueComponents>
</gml:CompositeValue>
</gml:rangeParameters>
<gml:tupleList>
0.000000,167.553329,-69.744614,-2474.000000
0.160000,167.541229,-69.753403,-8888.000000
... ...
3308.320068,-106.911194,81.586121,16953.000000
</gml:tupleList>
</gml:DataBlock>
</gml:rangeSet>
</CloudSatSwathProfile>Or encoded in GML for publishing as follows, referring to version 1.1 of the CIS (Coverage Implementation Schema) encoding standard:
<GeneralGridCoverage
xmlns="http://www.opengis.net/cis/1.1/gml"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:swe="http://www.opengis.net/swe/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/cis/1.1/gml ../cisAll.xsd">
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D"
axisLabels="atrack xtrack">
<RegularAxis axisLabel="atrack" lowerBound="0"
upperBound="20677" uomLabel="scan" resolution="1" />
<RegularAxis axisLabel="xtrack" lowerBound="0"
upperBound="124" uomLabel="scan" resolution="1" />
</GeneralGrid>
</DomainSet>
<RangeSet>
<DataBlock>
<CV>
<V>0.000000</V>
<V>-69.744614</V>
<V>167.553329</V>
<V>-2474.000000</V>
</CV>
... ...
</DataBlock>
</RangeSet>
<RangeType>
<swe:DataRecord>
<swe:field name="Timestamp">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="second" />
</swe:Quantity>
</swe:field>
<swe:field name="Latitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="degree" />
</swe:Quantity>
</swe:field>
<swe:field name="Longitude">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="degree" />
</swe:Quantity>
</swe:field>
<swe:field name="SwathData">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="some_unit" />
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>
</GeneralGridCoverage>Following the CIS 1.1 example http://schemas.opengis.net/cis/1.1/gml/examples-1.1/45_2D_distorted.xml,, we can encode the swath coverage data as follows:
<GeneralGridCoverage xmlns="http://www.opengis.net/cis/1.1/gml"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:swe="http://www.opengis.net/swe/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/cis/1.1/gml ../cisAll.xsd">
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D"
axisLabels="Time xTrack Lat Long">
<DisplacementAxisNest axisLabels="Time xTrack Lat Long"
uomLabels="second unit deg deg">
<P>
<C>0.0000</C>
<C>0</C>
<C>-69.744614</C>
<C>167.553329</C>
</P>
<P>
<C>0.1600</C>
<C>0</C>
<C>-69.744614</C>
<C>167.553329</C>
</P>
... ...
<P>
<C>3308.0000</C>
<C>124</C>
<C>-69.744614</C>
<C>167.553329</C>
</P>
</DisplacementAxisNest>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D"
axisLabels="i j">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="20677" />
<IndexAxis axisLabel="j" lowerBound="0" upperBound="124" />
</GridLimits>
</GeneralGrid>
</DomainSet>
<RangeSet>
<DataBlock>
<CV>
<V>1234.000000</V>
<V>-2474.000000</V>
</CV>
... ...
</DataBlock>
</RangeSet>
<RangeType>
<swe:DataRecord>
<swe:field name="Height">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="m" />
</swe:Quantity>
</swe:field>
<swe:field name="SwathData">
<swe:Quantity
definition="http://www.opengis.net/def/dataType/OGC/0/double">
<swe:uom code="some_unit" />
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>
</GeneralGridCoverage>Inspired by Stephan Meißl, below is a proposed version of data provision that reduces the redundancy of DomainSet in comparison to above versions, and provides all the needed information for visualization in one coverage/request.
<?xml version="1.0" encoding="UTF-8"?>
<wcs21:CoverageDescriptions
xmlns:wcs21='http://www.opengis.net/wcs/2.1/gml'
xmlns:wcs20='http://www.opengis.net/wcs/2.0'
xmlns='http://www.opengis.net/cis/1.1/gml'
xmlns:gml='http://www.opengis.net/gml/3.2'
xmlns:swe='http://www.opengis.net/swe/2.0'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:schemaLocation='http://www.opengis.net/swe/2.0 http://schemas.opengis.net/sweCommon/2.0/swe.xsd
http://www.opengis.net/wcs/2.1/gml http://schemas.opengis.net/wcs/2.1/gml/wcsAll.xsd
http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsAll.xsd'>
<wcs21:CoverageDescription gml:id="_2017339123204_61738_CS_2B-GEOPROF_GRANULE_P_R04_E06">
<Envelope srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="Lat Long date xtrack" srsDimension="4">
<AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-81.820435" upperBound="81.82048"/>
<AxisExtent axisLabel="Long" uomLabel="deg" lowerBound="-105.84433" upperBound="171.2182"/>
<AxisExtent axisLabel="date" uomLabel="d" lowerBound="46293.594" upperBound="49613.914"/>
<AxisExtent axisLabel="xtrack" uomLabel="" lowerBound="0" upperBound="124"/>
</Envelope>
<DomainSet>
<GeneralGrid srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="Lat Long date xtrack">
<IrregularAxisNest axisLabels="Lat Long date" uomLabels="deg deg d">
<P><C/><C/><C/></P>
</IrregularAxisNest>
<DisplacementAxisNest axisLabels="xtrack" uomLabels="">
<P><C/></P>
</DisplacementAxisNest>
<GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index2D" axisLabels="i j">
<IndexAxis axisLabel="i" lowerBound="0" upperBound="20752"/>
<IndexAxis axisLabel="j" lowerBound="0" upperBound="124"/>
</GridLimits>
</GeneralGrid>
</DomainSet>
<RangeType>
<swe:DataRecord>
<swe:field name="Height">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">-8888</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="dBZe"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-32768 32767</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
<swe:field name="Radar_Reflectivity">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">15360</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="dBZe"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-32768 32767</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
<swe:field name="Gaseous_Attenuation">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">15360</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="dBZe"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-32768 32767</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
<swe:field name="CPR_Cloud_mask">
<swe:Quantity definition="TBD">
<swe:description>TBD</swe:description>
<swe:nilValues>
<swe:NilValues>
<swe:nilValue reason="fill value">-99</swe:nilValue>
</swe:NilValues>
</swe:nilValues>
<swe:uom code="various"/>
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-128 127</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</RangeType>
<wcs20:ServiceParameters>
<wcs20:CoverageSubtype>GeneralGridCoverage</wcs20:CoverageSubtype>
<wcs20:nativeFormat>application/x-hdf</wcs20:nativeFormat>
</wcs20:ServiceParameters>
</wcs21:CoverageDescription>
</wcs21:CoverageDescriptions>Operation of Subsetting
For example, the testbed participants investigated the 2B-GEOPROF data starting at 12:44:29 pm, Jan 1, 2017 (UTC), and lasting for 3308.320068 seconds.
Subsetting along atrack:
Figure 12 is a visualization of locations of data bins (atrack):
From the visualization, the locations of the profile were found to be consistent with timestamps. So, by providing the start time and end time, the data can be easily subset. However, since the locations present a sine-function-like pattern, subsetting by specifying the minimum and maximum longitude and/or latitude may split the original grid into multiple ones. This may require some additional handling. One method to solve the problem is to sort the subset grids by time stamp and merge them sequentially along horizontal (atrack) direction, because they still share the same xtrack-dimension.
Subsetting along xtrack:
The easiest way to subset xtrack is to provide a range of xtrack number. However, it might not be meaningful for real applications. A better choice could be to assign a range of height of profile. Whereas, the heights in different data bins that share the same xtrack can vary. A visualization of top height of data bins along atrack is presented in Figure 13.
Since data points are not neatly aligned in the same xtrack, subsetting by height may result in irregular grids. The solution is described by the following steps:
-
Keep the size of the original grid
-
Fill the filtered data points by missing value
-
Remove the top and bottom xtracks that only consist of missing value.
CloudSat Profile WCS
Data Provision (Version 1)
CloudSat Profile GEOPROF-2B is published, based on the coverage model based on the CF convention proposed earlier:
dimensions:
atrack = 20678;
xtrack = 125;
variables:
double time(atrack) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float lat(atrack) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(atrack) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east" ;
float swath_data(atrack, xtrack) ;
swath_data:coordinates = "time lon lat” ;This Data is published by WCS 2.0.1 whose GetCapabilities request is available at http://cici.lab.asu.edu:8080/geoserver/ows?service=WCS&version=2.0.1&request=GetCapabilities. The XML snippet below shows the EOCoverageSet information of the published data:
<wcseo:DatasetSeriesSummary>
<ows:WGS84BoundingBox>
<ows:LowerCorner>-106.91119384765625 -81.81893920898438</ows:LowerCorner>
<ows:UpperCorner>168.80332946777344 81.82908416748047</ows:UpperCorner>
</ows:WGS84BoundingBox>
<wcseo:DatasetSeriesId>swath__cs_2b_geoprof_dss</wcseo:DatasetSeriesId>
<gml:TimePeriod gml:id="swath__cs_2b_geoprof_dss__timeperiod">
<gml:beginPosition>2017-01-01T13:04:14.558Z</gml:beginPosition>
<gml:endPosition>2017-01-01T13:59:22.878Z</gml:endPosition>
</gml:TimePeriod>
</wcseo:DatasetSeriesSummary>Since the data is indexed by atrack. It has been split into 20678 granules. The information of each granule is described in DescribeEOCoverageSet XML document. Its DescribeEOCoverageSet request goes as follows http://cici.lab.asu.edu:8080/geoserver/ows?service=WCS&version=2.0.1&request=DescribeEOCoverageSet&eoId=swath__cs_2b_geoprof_dss. In the beginning part of each granule (see the XML snippet below), latitude and longitude is contained in label <gml:lowerCorner> respectively, and time is contained in label <gml:beginPosition>. The swath data (Radar_Reflectivity for this showcase) can be obtained by setting the CoverageId contained in label <wcs:CoverageId> and sending GetCoverage request accordingly. In CoverageId, the number right after the dot/period indicates the value of atrack.
<gml:boundedBy>
<gml:EnvelopeWithTimePeriod
srsName="http://www.opengis.net/def/crs/EPSG/0/4326" axisLabels="Lat Long time"
uomLabels="Deg Deg s" srsDimension="2">
<gml:lowerCorner>-69.89391326904297 167.34603881835938</gml:lowerCorner>
<gml:upperCorner>-69.88391326904296 168.59603881835938</gml:upperCorner>
<gml:beginPosition>2017-01-01T13:04:17.278Z</gml:beginPosition>
<gml:endPosition>2017-01-01T13:04:17.278Z</gml:endPosition>
</gml:EnvelopeWithTimePeriod>
</gml:boundedBy>
<wcs:CoverageId>swath__cs_2b_geoprof_1K_granule_cs_2b_geoprof_1K.1</wcs:CoverageId>Here is an example of GetCoverage request to obtain the swath data in GML format (GeoTIFF by default) with atack being 20678: http://cici.lab.asu.edu:8080/geoserver/ows?service=WCS&version=2.0.1&request=GetCoverage&CoverageId=swath__cs_2b_geoprof_granule_cs_2b_geoprof.20678&format=gml, which contains 125 values following the xtrack. The values can be found in label <gml:DataBlock>.
While it takes a lot of processing time to describe all the information of 20678 scans in a single DescribeEOCoverageSet XML document, it could be very slow to use your browser to view the request directly. There is a subsampling version of the original dataset for quick inspection purpose with 1,000 scans (dimension of atrack = 1000). Its DescribeEOCoverageSet and GetCoverage requests are listed as follows:
Data Provision (Version 2)
The strategy of publishing the CloudSat coverage model has been changed. Instead of publishing the data in many granules, they are provided as a whole piece this time. This greatly improved the performance of data transferring and processing in both back-end and front-end.
It follows the CF convention as well:
dimensions:
atrack = 20678;
xtrack = 125;
variables:
double time(atrack) ;
time:standard_name = "time" ;
time:units = "<units> since <datetime string>" ;
time:calendar = "gregorian" ;
float lat(atrack) ;
lat:standard_name = "latitude" ;
lat:units = "degrees_north" ;
float lon(atrack) ;
lon:standard_name = "longitude" ;
lon:units = "degrees_east” ;
float height(atrack, xtrack) ;
time:standard_name = “height" ;
time:units = “m" ;
float swath_data(atrack, xtrack) ;
swath_data:coordinates = "time lon lat” ;This Data is published by a WCS 2.0.1 with a GetCapabilities request that is available at http://cici.lab.asu.edu/swathserver/?service=wcs&version=2.0.1&request=GetCapabilities. The XML snippet below shows one of the variable information of the published data:
<wcs:CoverageSummary>
<wcs:CoverageId>cs_2b_geoprof:CPR_Cloud_mask</wcs:CoverageId>
<wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>
<ows:WGS84BoundingBox>
<ows:LowerCorner>-106.91119384765625 -81.81893920898438</ows:LowerCorner>
<ows:UpperCorner>167.55332946777344 81.81908416748047</ows:UpperCorner>
</ows:WGS84BoundingBox>
<ows:BoundingBox crs="http://www.opengis.net/def/crs/OGC/0/Index2D">
<ows:LowerCorner>0 0</ows:LowerCorner>
<ows:UpperCorner>20677 124</ows:UpperCorner>
</ows:BoundingBox>
<gml:TimePeriod gml:id="cs_2b_geoprof:CPR_Cloud_mask__timeperiod">
<gml:beginPosition>2017-01-01T13:04:14.558</gml:beginPosition>
<gml:endPosition>2017-01-01T13:59:22.878068359</gml:endPosition>
</gml:TimePeriod>
</wcs:CoverageSummary>The coverageId (<wcs:CoverageId>), WGS84 bounding box (<ows:WGS84BoundingBox>), data grid bounding box (<ows:BoundingBox>), and time coverage period (<gml:TimePeriod>) are present in the GetCapabilities document. CoverageId is constructed by the dataset name and the variable name, connected with a colon. The WGS84 bounding box is only to help people identify the coverage of the satellite scanning trail on the Earth’s surface. The data grid itself, a vertical profile, could not correctly project onto the Earth. Therefore the data grid coverage/size is directly recorded in the <ows:BoundingBox> tag. <gml:TimePeriod> contains the time information of first scanned and last scanned columns of the dataset.
Using the coverageId, the DescribeCoverage document of cs_2b_geoprof:CPR_Cloud_mask can be retrieved by http://cici.lab.asu.edu/swathserver/?service=wcs&version=2.0.1&request=DescribeCoverage&coverageId=cs_2b_geoprof:CPR_Cloud_mask, in which more data grid information is contained. Beside the data range, data unit, and missing value are declared in the document too, presenting in the following XML snippet:
<gml:rangeType>
<swe:DataRecord>
<swe:field name="CPR_Cloud_mask">
<swe:Quantity>
<swe:description>CPR_Cloud_mask</swe:description>
<swe:nilValues>
<swe:nilValue reason="http://www.opengis.net/def/nil/OGC/0/unknown">-99</swe:nilValue>
</swe:nilValues>
<swe:uom code="" />
<swe:constraint>
<swe:AllowedValues>
<swe:interval>-128 127</swe:interval>
</swe:AllowedValues>
</swe:constraint>
</swe:Quantity>
</swe:field>
</swe:DataRecord>
</gml:rangeType>Missing value is contained in <swe:nilValue>, data unit is contained in code attribute of tag <swe:uom> (missing for this variable), while data range can be found in <swe:interval>.
Finally, the data can be retrieved through the GetCoverage request as http://cici.lab.asu.edu/swathserver/?service=wcs&version=2.0.1&request=getCoverage&coverageId=cs_2b_geoprof:CPR_Cloud_mask. It is available as GML 3.2, following the CIS 1.1 standard. The values can be found in tag <gml:DataBlock>.
One more thing that needs to be mentioned is that not all the auxiliary/geographic information, like height, time, latitude, and longitude, has been provided along with the swath variable in a single GetCoverage request. Instead, they are available as different variables that are listed in GetCapabilities document. For example, the XML snippet below shows the Height information:
<wcs:CoverageSummary>
<wcs:CoverageId>cs_2b_geoprof:Height</wcs:CoverageId>
<wcs:CoverageSubtype>RectifiedGridCoverage</wcs:CoverageSubtype>
<ows:WGS84BoundingBox>
<ows:LowerCorner>-106.91119384765625 -81.81893920898438</ows:LowerCorner>
<ows:UpperCorner>167.55332946777344 81.81908416748047</ows:UpperCorner>
</ows:WGS84BoundingBox>
<ows:BoundingBox crs="http://www.opengis.net/def/crs/OGC/0/Index2D">
<ows:LowerCorner>0 0</ows:LowerCorner>
<ows:UpperCorner>20677 124</ows:UpperCorner>
</ows:BoundingBox>
<gml:TimePeriod gml:id="cs_2b_geoprof:Height__timeperiod">
<gml:beginPosition>2017-01-01T13:04:14.558</gml:beginPosition>
<gml:endPosition>2017-01-01T13:59:22.878068359</gml:endPosition>
</gml:TimePeriod>
</wcs:CoverageSummary>Data Subsetting
Data subsetting is implemented based on the original data axes. Users can find the names of axes and corresponding ranges by sending the DescribeCoverage request. For example, below is presented an XML snippet from <http://cici.lab.asu.edu/swathserver/?service=wcs&version=2.0.1&request=DescribeCoverage&coverageId=cs_2b_geoprof:CPR_Cloud_mask>:
<gml:EnvelopeWithTimePeriod axisLabels="nray nbin" srsDimension="2"
srsName="http://www.opengis.net/def/crs/OGC/0/Index2D">
<gml:lowerCorner>0 0</gml:lowerCorner>
<gml:upperCorner>20677 124</gml:upperCorner>
<gml:beginPosition>2017-01-01T13:04:14.558</gml:beginPosition>
<gml:endPosition>2017-01-01T13:59:22.878068359</gml:endPosition>
</gml:EnvelopeWithTimePeriod>The axes names contained in the attribute axisLabels of tag gml:EnvelopeWithTimePeriod, and corresponding lower bound and upper bound can be found in tag <gml:lowerCorner> and <gml:upperCorner>. The <gml:beginPosition> and <gml:endPosition> elements define the time span of the scans in this dataset.
According to [OGC® Web Coverage Service 2.0 Interface Standard - KVP Protocol Binding Extension](https://portal.opengeospatial.org/files/09-147r1), the subsetting request is made by adding Key-Value Pairs (KVPs) in GetCoverage request. For each axis that needs to be subset, add a KVP like subset=axisLabel(lowerBound, upperBound). For example, to get the subset from 50 to 100 in nray and from 10 to 20 in nbin, the request will be as follows: http://cici.lab.asu.edu/swathserver/?service=wcs&version=2.0.1&request=getCoverage&coverageId=cs_2b_geoprof:CPR_Cloud_mask&subset=nray(50,100)&subset=nbin(10,20)
The XML snippet below shows the new spatial and temporal bounds of retrieved dataset:
<gml:EnvelopeWithTimePeriod axisLabels="nray nbin" srsDimension="2"
srsName="http://www.opengis.net/def/crs/OGC/0/Index2D">
<gml:lowerCorner>50 10</gml:lowerCorner>
<gml:upperCorner>100 20</gml:upperCorner>
<gml:beginPosition>2017-01-01T13:04:22.558</gml:beginPosition>
<gml:endPosition>2017-01-01T13:04:30.558</gml:endPosition>
</gml:EnvelopeWithTimePeriod>Notes: the lowerBound and upperBound in the KVP are both inclusive.
11.1.5. VIIRS Swath Coverages and their Web Coverage Services
Both an extended WCS 2.1 and a WCS REST service for serving Visible Infrared Imaging Radiometer (VIIRS) swath data were implemented by the team from George Mason University.
Data
The surface reflectance (VNP09) of VIIRS was chosen for experiments on serving swath coverages. The VNP09 data are produced by NASA and distributed by the Land Processes Distributed Active Archive Center (LP DAAC). The surface reflectance data in swath structure are separately stored from its associated geolocation data. The VNP09 collection has a granule of 6-minute swath coverage. The data are available from January 2012 to present.
WCS 2.1 Service
The swath data was modeled in CIS 1.1 with a regular grid of the sensor-reference system. It allows subsetting along different dimensions, including spatial and temporal dimensions. Full details and examples can be found in Appendix A.
WCS REST Service
The RESTful WCS service was implemented following the draft specification developed in the testbed with the assistance from the WFS 3 standards team. The WCS REST service allows subsetting along different dimensions, including spatial and temporal dimensions. The responses are in the similar contents as those from WCS 2.1. Full details and examples can be found in Appendix A.
11.2. Implementations of Swath WCS Clients
Several implementations of clients to access WCS Swath Coverages are made available.
11.2.1. CloudSat Profile Visualization
The draft implementation of the EO-WCS Swath client for CloudSat data relies on the Implementation 1 of the CloudSat WCS server. The table with pros and cons of the two available WCS implementations for CloudSat as follows.
| WCS Implementation | Pros | Cons | |
|---|---|---|---|
Implementation #1 |
|
|
|
Implementation #2 |
|
|
The client supports discovery and GetCoverage to access the implemented CloudSat services. The first step is about discovery and selection of the EO Swath coverages of interest from the EO Swath products catalogue. The search interface is shown in Figure 14.