Publication Date: 2017-06-14
Approval Date: 2017-03-23
Posted Date: 2016-11-14
Reference number of this document: OGC 16-042r1
Reference URL for this document: http://www.opengis.net/doc/PER/t12-NA005
Category: Public Engineering Report
Editor: Lingjun Kang, Liping Di, Eugene Yu
Title: Testbed-12 WMS/WMTS Enhanced Engineering Report
COPYRIGHT
Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is an OGC Public Engineering Report created as a deliverable of an initiative from the OGC Innovation Program (formerly OGC Interoperability Program). It is not an OGC standard and 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. Introduction
- 2. References
- 3. Terms and definitions
- 4. Conventions
- 5. Overview
- 6. Status Quo & New Requirements Statement
- 7. Solutions
- 7.1. Targeted Solutions
- 7.2. Recommendations
- 7.2.1. Recommendations for the time-varying layer access through WMTS
- 7.2.2. Recommendations for extending map render options on WMS GetMap operation
- 7.2.3. Recommendations for extending filtering options on WMS GetCapabilities operation
- 7.2.4. Recommendations for extending WMTS interface support efficient layer domain inspection/relationship discovery
- 8. WMTS for time-varying layers
- 9. WMS for NetCDF
- 10. Multidimensional WMTS domain discovery
- Appendix A: Revision History
- Appendix B: Bibliography
This Engineering Report (ER) describes requirements, challenges and solutions regarding improving multidimensional Earth Observation (EO) data access, discovery and visualization through Web Map Service (WMS), Web Map Tile Service (WMTS), and corresponding extensions. The ER will highlight solutions and recommendations of following main topics.
In this topic, the ER will cover the following proposed work items enhancing time-varying layer access and discovery. The ER will also discuss the discussions and proposals of extending current WMTS/WMS specifications for the enhancements.
-
New time-query semantic/encoding for time-varying layer query;
-
WMTS Capabilities extension for time-varying layer discovery; and
-
Improvements on avoiding empty tile request and better server-client communication (e.g., empty tiles).
In this topic, the ER will cover the following proposed work items to better support NetCDF-CF data visualization and exploration.
-
Extensions on WMS GetMap request parameters to enrich map render options (with non-standard ncWMS interfaces); and
-
Extensions on WMS GetCapabilities request parameter to improve discovery of WMS GetCapabilities document (with large number of layers being advertised).
In this topic, the ER will cover the following proposed work items to improve inspecting layer domain and discovery of the relationship between multidimensional layers.
-
Extensions on WMS GetMap request parameters to enrich map render options (with non-standard ncWMS interfaces); and
-
Extensions on WMS GetCapabilities request parameter to improve discovering WMS GetCapabilities document (with large number of layers being advertised).
This engineering report reviews the time-varying layer/NetCDF supports and limitations in current WMS/WMTS specifications. The engineering report also covers proposed enhancements and extensions on current WMS/WMTS specifications. The contents of this report will therefore improve the geospatial map service interoperability through:
-
Improved understandings of time-varying layer access supports in current standards and the possible space for extensions to achieve better time-varying access/discovery;
-
Improved time-varying layer access with proposed advanced time-query semantics;
-
Efficient multidimensional layer (including time layer) discovery through extensions on Capabilities document; and
-
Improved NetCDF access capabilities in extended WMS.
The importances of this ER to the WMS 1.4 Standards Working Group (SWG) are that the solutions and proposals present in this ER will serve as the references to extend existing WMS/WMTS standards for enhanced time-varying layer access/discovery and better NetCDF access support.
The WMS 1.4 SWG is dedicated in improving both web map service standards and the EO data access through the internet. The proposed extensions of WMS/WMTS in this ER will serve as the reference for WMS 1.4 SWG’s future endeavor in:
-
Improving the efficient access to time-varying layers;
-
Improving the web map rendering options and GetCapabilities filtering; and
-
Improving the map layer domain inspection/layer relationship discovery.
ogcdocs, testbed-12, engineering report, WMS, WMTS, NetCDF, time-varying layer, multidimensional layers, etc.
1. Introduction
This engineering report describes the requirements, challenges, solutions and recommendations regarding the access, discovery, and visualization of time-varying/multidimensional Earth Observations through WMS and WMTS with the proposed enhancements.
1.1. Scope
This OGC® Engineering Report reviews and evaluates the map service interoperability (i.e. time-varying layer access and NetCDF support) in the following specifications:
[WMS 1.3.0] OpenGIS Web Map Service (WMS) Implementation Specification, version 1.3.0, OGC document 06-042, 2006-03-15, http://portal.opengeospatial.org/files/?artifact_id=14416
[WMTS 1.0.0] OpenGIS Web Map Tile Service Implementation Standard, version 1.0.0, OGC document 07-057r7, 2010-04-06, http://portal.opengeospatial.org/files/?artifact_id=35326
[WFS 2.0.0] OGC® Web Feature Service 2.0 Interface Standard, version 2.0.2, OGC document 09-025r2, 20104-07-10, http://docs.opengeospatial.org/is/09-025r2/09-025r2.html
[ISO 8601] Data elements and interchange formats — Information interchange — Representation of dates and times, https://en.wikipedia.org/wiki/ISO_8601
1.2. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors.
Name | Organization |
---|---|
Lingjun Kang (editor) |
CSISS/GMU |
Liping Di (editor) |
CSISS/GMU |
Eugene Yu (editor) |
CSISS/GMU |
Maso Pau Joan |
Universitat Autònoma de Barcelona (CREAF) |
Satish Sankaran |
Esri |
Matthew Cechini |
Columbus Technologies & Services, Inc. |
Andrea Aime |
GeoSolutions S.A.S. |
Craig Bruce |
CubeWrex for Polar View |
Stephan Meißl |
EOX IT Services GmbH |
Perry Peterson |
PYXIS |
Lei Hu |
CSISS/GMU |
1.3. Future work
-
GML geometry representation for the spatial footprint of available WMTS tiles. Currently the spatial domain is represented as a bounding box, a polygon or a multi-polygon could be used to better represent scattered datasets.
-
As an alternative for clients unable to perform polygon intersections, a direct binary representation with regard to the availability of WMTS tile is expected. The direct representation of WMTS tile availability will free the client from complex math calculation in deriving the column/row number of available WMTS tiles.
1.4. 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 documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
-
OGC: OGC 06-121r9, OGC® Web Services Common Standard (2010)
-
OGC: OGC 06-042, OpenGIS Web Map Service (WMS) Implementation Specification, version 1.3.0 (2006)
-
OGC: OGC 07-057r7, OpenGIS Web Map Tile Service Implementation Standard 1.0.0 (2010)
-
OGC: OGC 09-025r2, OGC® Web Feature Service 2.0 Interface Standard, version 2.0.2 (2014)
-
ISO: ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and times (2004)
-
The University of Reading: ncWMS User Guide, https://reading-escience-centre.gitbooks.io/ncwms-user-guide/content/ (2010)
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], OpenGIS Web Map Service (WMS) Implementation Specification, version 1.3.0 [OGC 06-042], and in OpenGIS Web Map Tile Service Implementation Standard 1.0.0 [OGC 07-057r7] shall apply.
4. Conventions
4.1. Abbreviated terms
Most of the abbreviated terms listed in subclause 5.1 of the OWS Common Implementation Specification [OGC 06-121r9], OpenGIS Web Map Service (WMS) Implementation Specification, version 1.3.0 [OGC 06-042], and OpenGIS Web Map Tile Service Implementation Standard 1.0.0 [OGC 07-057r7] apply to this document.
4.2. UML notation
Most diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 06-121r9].
4.3. Used parts of other documents
This document uses significant parts of document [OGC 06-121r9]. To reduce the need to refer to that document, this document copies some of those parts with small modifications. To indicate those parts to readers of this document, the largely copied parts are shown with a light grey background (15%).
5. Overview
This engineering report describes the requirements, challenges, solutions and recommendations regarding the access, discovery and visualization of time-varying/multidimensional Earth Observations through WMS and WMTS with proposed enhancements.
6. Status Quo & New Requirements Statement
6.1. Status Quo
6.1.1. Earth observation data access through map service
With the advancements of earth observation and interoperability technologies, this era has witnessed the increasing availability of EO data with high temporal resolution and multiple dimensions. This leads to the need of enhancing current map services (i.e., WMS and WMTS) for better access and visualization of the EO data. On the other hand, the large volumes of EO data lead to the need of improving current map services' support on the standard EO data structure (i.e. NetCDF).
6.1.2. Time-varying/multi-dimension EO data access challenges
The EO data access has been greatly facilitated with the support of WMS and WMTS. However, the time-varying EO data with high temporal resolution and dimensions brings the following new challenges:
-
Support time-varying layer access through WMTS/WMS with proper and less ambiguous time-query semantic;
-
Support metadata content filter through the WMS/WMTS Capabilities document with the layers of large number;
-
Support rich map render options in WMS/WMTS;
-
Improve WMS/WMTS server-client communication to prevent empty tile requesting; and
-
Extend current WMS to better support NetCDF data access.
6.2. Requirements Statement
-
WMTS for time-varying layer
-
Extend WMTS time-query semantic/encoding to achieve accurate/efficient time-varying layer query.
-
Extend WMTS Capabilities to achieve better time-varying layer discovery in GetCapabilities document.
-
-
WMS for NetCDF
-
Extend WMS to better support NetCDF.
-
-
NetCDF-CF data visualization and exploration
-
Extend WMS with selected non-standard WMS operations from ncWMS.
-
Extend WMS Capabilities operation to achieve efficient capabilities content filtering/retrieval.
-
-
Multidimensional WMTS domain discovery
-
Extend WMTS interfaces to achieve efficient inspection on layer domain and discovery on multidimensional layer relationship.
-
-
WMS/WMTS client
-
Develop enhanced client-side communication to achieve efficient WMTS request (e.g., by avoiding unnecessary empty tile requests).
-
7. Solutions
7.1. Targeted Solutions
WMS/WMTS Enhancements aim at improving the following aspects related with WMS/WMTS map access/rendering.
-
WMTS enhancements for time-varying layer query/discovery.
-
WMS extensions for NetCDF.
-
Multidimensional WMTS domain discovery.
7.1.1. WMTS enhancements for time-varying layers query/discovery
WMTS time-query enhancements
A collection of time-query semantics/encoding were proposed as the enhancements on WMTS supports of temporal query. Additionally, WMTS Capabilities document was extended as a way to advertise proposed time-query semantics.
7.1.2. WMS extensions for NetCDF
Improvements on the WMS support of map rendering
A collection of extended GetMap parameters was introduced from ncWMS to improve WMS support of map rendering.
Improvements on the mechanisms of WMS metadata filtering
The extension was proposed for WMS GetCapabilities operation as a way to achieve better capabilities content filter/discovery.
Improvements on the WMS support for map querying
GetTimeSeries operation was introduced as the extension to retrieve the evolution of a phenomenon on a specific point over time or elevation, or at a fixed them and elevation, but along a path.
7.1.3. Multidimensional WMTS domain discovery
Extensions on WMTS interface to support efficient layer domain inspection/relationship discovery
The following three operations were proposed to support efficient inspecting layer domain and discovering the relationships among multidimensional layers:
-
DescribeDomains;
-
GetHistogram; and
-
GetFeature.
7.2. Recommendations
7.2.1. Recommendations for the time-varying layer access through WMTS
The following time-query semantics are proposed as the extension of WMTS to better support time-varying layer query.
Proposed time-query semantics | Description |
---|---|
at |
Selects a server-defined semantic for a single time instant |
asof |
Selects all times from negative infinity up to and including the given time instant. |
series |
Selects one frame from a fixed time series identified by the first time instant of the frame. |
interval |
Selects all times in a given arbitrary inclusive time interval. |
anim.at |
Selects an animation of “at” image frames. |
anim.asof |
Selects an animation “as-of” image frames. |
anim.series |
Selects an animation of fixed-time-series image frames. |
anim.interval |
Selects an animation of arbitrary-interval image frames with an arbitrary time resolution. |
WMTS Capabilities document extension
The proposed time-query semantics/encoding was recommended to be advertised through Capabilities document with the following extensions:
-
Extend Capabilities <Dimension> element for time-query declaration; and
-
Extend Capabilities <ResourceURL> element for time-query declaration in the RESTFul API.
7.2.2. Recommendations for extending map render options on WMS GetMap operation
The following extended ncWMS GetMap parameters were proposed and introduced to support additional map render options in WMS.
Extended WMS parameter | Description |
---|---|
COLORSCALERANGE |
Of the form min,max this is the scale range used for plotting the data (mapped to the COLORSCALERANGE_MIN and COLORSCALERANGE_MAX env vars) <<<<<<< HEAD |
NUMCOLORBANDS |
The number of discrete colors to plot the data. Must be between 2 and 250 (mapped to the NUMCOLORBANDS env variable) |
ABOVEMAXCOLOR |
The color to plot values which are above the maximum end of the scale range. Colors are of the form 0xRRGGBB or 0xAARRGGBB, and it also accepts “transparent” and “extend” |
BELOWMINCOLOR |
The color to plot values which are below the minimum end of the scale range. Colors are of d the form 0xRRGGBB or 0xAARRGGBB, and it also accepts “transparent” and “extend” |
LOGSCALE |
“true” or “false” - whether to plot data with a logarithmic scale |
OPACITY |
The percentage opacity of the final output image as a number between 0 and 100 (maps to OPACITY env var by translating it to a number between 0 and 1) |
ANIMATION |
“true” or “false” - whether to generate an animation. The ncWMS documentation states that TIME has to be of the form <tt class="docutils literal">starttime/endtime</tt>, but C:\work\ogc\ows12\work\LSA_NA005_ER\er_wms_wmts_OGC16-042\includes\images\redblue-default.png TIME needs to be a list of discrete times instead. Animation requires using the “image/gif” as the response format (as the only format supporting animation) |
7.2.3. Recommendations for extending filtering options on WMS GetCapabilities operation
Extended GetCapabilities parameter | Description |
---|---|
DATASET |
The parameter will be set with layer/dataset name. Once the parameter is provided in the request, only content regarding the layer/dataset will be returned. |
7.2.4. Recommendations for extending WMTS interface support efficient layer domain inspection/relationship discovery
Extended operation | Description |
---|---|
DescribeDomains |
The extended operation is used for compact domain inspection. |
GetHistogram |
The extended operation is used for inspecting domain distribution histogram. |
GetFeature |
The extended operation is used for detailed value combination inspection and description. |
8. WMTS for time-varying layers
8.1. Introduction
This proposal extends the existing WMTS 1.0.0 and WMS 1.3.0 time-query mechanisms to provide general time filtering for general “scattershot” source data in a tiled environment. Scattershot source data is not pre-composited or mosaicked but is available in discrete, randomly-overlapping scenes that are time-stamped as originally captured (though are normally orthorectified). General time filtering needs to support client-selected time intervals, not just time instants. Enabling fully-arbitrary time intervals fulfills the needs of general time filtering, but is impractical to use with WMTS services that are based on pre-generated tiles because of the combinatorial explosion of possible min and max times for an interval, so simpler semantics are also needed. Tiles can be used for efficient WMS-Map rendering as well.
Eight useful semantics for time-based access are defined: ‘at’ time instant (as already in existing WMS/WMTS), ‘as-of’ time instant, fixed time-series, arbitrary time interval, and animated versions of the previous four. The arbitrary-interval semantic includes the capabilities of the simpler semantics, but it is important to allow simple server instances to provide limited, optimized service.
The WMTS Capabilities document reports precisely what times are available by giving a list of time semantics and start/end time intervals and resolutions with continuousness, time-granularity, and interval-bound-inclusiveness taken care of. ISO 8601 time-value encoding is used and it is important that time values be character-for-character-precise for accessing static, pre-generated tiles through the WMTS REST interface.
8.2. Existing OWS time support
Time support exists in both the WMTS and WMS interfaces.
8.2.1. Existing WMTS time support
The latest official version of WMTS (Web Map Tile Service) is 1.0.0 [WMTS 1.0.0]. It includes a limited mechanism for dimensional queries including the dimension of time. An example XML Capabilities document might include:
<Dimension> <ows:Identifier>Time</ows:Identifier> <ows:UOM>ISO8601</ows:UOM> <ows:Title>Time</ows:Title> <ows:Abstract>Monthly datasets</ows:Abstract> <Default>null</Default> <Value>2007-05</Value> <Value>2007-06</Value> <Value>2007-07</Value> </Dimension>
Specific values must be explicitly enumerated, which is not a scalable approach. If data were available on a daily basis for 2000 through 2015, there would need to be 5,844 enumerated Value tags. Alternatively, if a time-interval notation with a resolution of one day were available, only a single Value would need to be given. Time values are opaque in that the client does not parse them but simply parrots them back to the server. This effectively makes the values format-independent, but also means that clients cannot reinterpret them into into specialized calendar-based GUI components, for instance.
With Key-value-pair requests, the named Dimension identifier and selected value are included along with the standard request parameters. REST tile requests are indicated in the Capabilities document using templates with substitution variables in curly braces, such as:
<ResourceURL format="image/png" resourceType="tile" template="https://website.org/wmts/mylayer/{Style}/{Time}/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.png"/>
8.2.2. Existing WMS time support
The latest official version of the WMS (Web Map Service) is 1.3.0 [WMS 1.3.0]. It has more-sophisticated time support than WMTS. An example declaration section might be:
<Dimension name="Time" units="ISO8601" default="null">1996-01-01/2003-10-17/P1D</Dimension>
Unlike with WMTS, the WMS declaration is stuffed into a single XML tag with attributes and uses time intervals with declared resolutions, making them much more scalable but also requiring viewer clients to parse the values and perform date calculations. For multiple intervals, WMS adds a syntax of using a comma separator (“,”) between allowed time ranges as opposed to the WMTS method of using multiple Value fields. Time-instant values are represented using ISO 8601 [ISO 8601] notation.
The WMS data model for time is clearly for pre-composited/mosaicked full-coverage source data that is neatly stacked by discrete if not regular time instants. The ‘nearestValue’ mechanism assumes that there is a single nearest time instant, as confirmed by its warning message in the HTTP header.
The ‘multipleValues’ attribute distinguishes whether a list of values or only a single value may be requested. It is not clear whether a time interval qualifies as a single value or as multiple values, but Example 2 in section C.3.6 implies that an interval is considered to be multiple values suitable for an animation response.
WMS appears to offer only one base time-filtering semantic, which can be called “at,” or a variant from using the ‘nearestValue’ attribute that can be called “nearest-to,” plus animated versions of the previous two using the ‘multipleValues’ attribute. Only one of “at” or “nearest-to” can be in force in a declaration and the selection of animation depends on at least one factor outside of the scope of the time declaration (the data format for the result map).
It is not clear what happens if an interval request is made when ‘multipleValues’ is not supported by a server. Also, an interval request requires a resolution according to Table C.2, implying a “multiple-at” semantic rather than a true interval. It is not clear if the resolution in a request is allowed to be “0” as described immediately after the table (though “0” is not a valid ISO-8601 period syntax; “PT0S” would be valid). Section C.3.2 gives the template “TIME=start_time/current,” but this is not a valid syntax according to Table C.2 which requires a resolution.
In summary, neither WMS nor WMTS provides adequate support for general time filtering of general source data. Also, the exact WMS time semantics are not explained clearly enough.
8.3. Time-query semantics and encodings
8.3.1. Data environment
The source-data environment envisioned is a fully general “scattershot” one where the source data is contained in “scenes” such as satellite or aerial images that can have various resolutions, locations, coordinate systems, acquisition times, and “color” types (e.g., RGB, Color Palette, RGBI, numeric), sample sizes, and data formats and can overlap each other in arbitrary ways and can have large gaps between coverage areas. Interfaces like WMTS hide the source-data semantics, though these semantics have implications for the exact tile content retrieved.
8.3.2. Timeless queries and overlapping-content ordering
A time-capable web service should respond intelligently to queries that do not filter by time. One method would be to return content with the data with the latest acquisition time on top, though other ordering methods might override time in cases where some source data has a significantly finer resolution that other data or has a higher user-assigned priority. In principle, time-based queries could also be rendered in some order other than latest-time-on-top where source scenes overlap, if suitable for a service.
There should be an obvious way to request data without special time filtering, such as requesting the default value for a time dimension, using a timeless REST template, or having the interface define special semantics for the time parameters.
8.3.3. Time-value encoding basis
The basis for representing time values and semantics here is ISO 8601 notation, as in WMS 1.3.0. ISO provides several different encodings for the same time instant, but for an interface like WMTS REST, it is important to specify exact, character-for-character encodings. One approach would be to allow servers to specify the encoding of all of the components of a time value using a formatting template in order to accommodate prepared static data that has a pre-determined format, but this would probably not be a worthwhile exercise. Clients would need to be significantly more complicated to recognize such formatting and compose proper time values. Prescribing a time format can complicate a server in that it may need to provide a mapping between internal and external time-value representations but allows the client to be statically programmed.
The prickly issues of time zones and time granularity must also be dealt with for both source data and open interfaces. If a source time value is merely “2015-03-17”, precisely what time is meant by that? Midnight? Noon? The whole day? In what time zone or zones? To avoid ambiguity and simplify coding, all time values passed in the enhanced WMTS interface shall be in the UTC time zone and the encoding shall include the explicit ISO designation character of “Z” (Zulu) where applicable according to the ISO-encoding rules to make this specific semantic extremely visible. Using arbitrary time zones would be an unnecessary complication and using an implicit time zone relative to the server is very awkward because of local Daylight Savings / Summer Time rules.
8.3.4. Time instant
A time instant shall have the ISO general form “YYYY-MM-DDThh:mm:ss.dddddddddZ”, where the time components are Year, Month, Day, Hour, Minute, Second, and sub-second Decimals, using as many components, decimals, and punctuation characters as needed to encode times to a selected granularity. The “-”, “T”, “:”, “.”, and “Z” characters are literal. The time value shall end with the ISO “Z” character whenever the Hour (or finer) time component is included. The ISO comma (“,”) character is disallowed for the decimal point since exact coding will be needed for the WMTS REST interface and there is already an incompatible use for the comma character in the WMS Capabilities document. ISO also provides a mechanism to use years outside the range of 0001 to 9999 that is compatible with the approach used here.
In principle, sub-second precision could extend indefinitely, but the finest practical accuracy even for synchronizing atomic clocks is around one nanosecond. Choosing a granularity limit of less than a nanosecond is generally a mistake, since systems far too often go through the evolutionary cycle of selecting seconds, then upgrading to milliseconds out of necessity, then microseconds, and finally nanoseconds (ns), because common computers can produce that amount of resolution (though not necessarily that amount of accuracy), though GPS synchronization can produce around 14 ns of accuracy in principle and 100 ns in practice. Just look at the evolution of the POSIX or SQL interfaces to see compatibility problems caused by choosing successively finer time granularities. The smartest move is just to start at ns resolution and be done with it. A ns within a second can be conveniently represented inside a system using a 32-bit integer.
8.3.5. Time granularity
The server shall identify the granularity of time values it will accept for character-for-character REST encodings with each specification of allowed time values using an integer to represent the number of time components and sub-second decimals. The following table gives the legal granularity values:
Granularity Integer | Time Granularity |
---|---|
0 |
Any legal granularity 1–15 (special wildcard) |
1 |
Year |
2 |
Month |
3 |
Day |
4 |
Hour |
5 |
Minute |
6 |
Second |
7 |
0.1 Second / Decisecond |
8 |
0.01 Second / Centisecond |
9 |
0.001 Second / Millisecond |
10 |
0.000 1 Second / Hectomicrosecond |
11 |
0.000 01 Second / Decamicrosecond |
12 |
0.000 001 Second / Microsecond |
13 |
0.000 000 1 Second / Hectonanosecond |
14 |
0.000 000 01 Second / Decananosecond |
15 |
0.000 000 001 Second / Nanosecond |
The server and client are free to produce time values encoded to any legal granularity except where exact encoding to the indicated granularity is required by a REST interface. If the server specifies the wildcard granularity (code 0), then the client is free to use any legal granularity in all requests including with all REST interfaces.
It is useful to have a specific limit to granularity precision so that inclusive and exclusive time boundaries can be expressed unambiguously. This limit shall be the nanosecond. For example, the last legal time instant before “2015-03-17T00:00:00.000000000Z” is “2015-03-16T23:59:59.999999999Z”, so this value can be used explicitly as an inclusive upper limit to express a time “less than” or excluding “2015-03-17T00:00:00.000000000Z”.
All time instants expressed to any granularity in the interface shall be interpreted internally by both client and server as representing the given value expanded to its first nanosecond. For example, “2015-03-17” would be interpreted as “2015-03-17T00:00:00.000000000Z”. Time instants re-expressed to a lesser granularity are always truncated instead of rounded. For example, “2015-03-16T23:59:59.999999999Z” re-expressed to Second granularity is “2015-03-17T23:59:59Z”. (One would not round up 10:45 to say that it is 11 o’clock.)
8.3.6. Time interval
A time interval is specified using the inclusive first time instant and the inclusive last time instant, later than or equal to the first time instant, separated by the slash (“/”) character. Both time instants are interpreted as being expanded to their first nanosecond. For example, “2013-01-01T17Z/2015-03-17T17Z” would be interpreted as the inclusive interval from “2013-01-01T17:00:00.000000000Z” to “2015-03-17T17:00:00.000000000Z”. The two given time instants can be expressed to different granularities except where precise encoding is required by a REST interface. Be careful to give the appropriate ending instant recognizing that it is inclusive. Also beware of unintentional overlap in a list of time intervals that are not meant to overlap.
ISO also allows either or both time instants to be empty strings corresponding to positive and negative infinity, but this notation is not needed here as explicit interval starting and ending times can always be given unless a layer has no time information available at all (perhaps because it is completely empty of content). In such a case, the server has various options, such as reporting a special null-value as an acceptable old-style time value that it knows how to interpret.
For comparisons, using the nanosecond granularity limit makes it possible to effectively indicate whether time boundaries are inclusive or exclusive. For example, if a time interval is to be specified from noon 2015-03-17 EDT to 2pm but excluding both bounds, a proper expression would be “2015-03-17T16:00:00.000000001Z/2015-03-17T17:59:59.999999999Z”. If the two bounds were inclusive, it could be expressed more compactly as “2015-03-17T16Z/2015-03-17T18Z”.
The slash (“/”) interval-separator character is very problematic for the WMTS REST interface because it is the folder separator used in most URI schemes and maps to the web-server file system, so using it would cause awkward interference with parsing pathnames. For this reason, in the WMTS REST-request URI only, two dash characters (“--”, U+002D U+002D) shall be used in place of the slash character when encoding interval time values and other time parameters like resolutions.
8.3.7. Time resolution
ISO provides an encoding for time repetitions, but it is needlessly awkward. WMS defines a simpler format for repeated time instants/resolutions/intervals: “first_instant/last_instant/period”, using an ISO period as the last component, which is used here.
The period component has the general format “P[yY][mM][dD]T[hH][mM][sS]”, where the square brackets indicate each optional component. The letter “P” is always present and means “Period”. The other components give the number of years, months, days, hours, minutes, and/or seconds, where each value can be any floating-point number. Note that different implementations are likely to interpret non-round results slightly differently. The letter “T” must always be used as a separator in the appropriate position if any time components to its right are used, as the letter “M” would otherwise be ambiguous. Examples are “P1D” for one day, “PT1H” for one hour, and “P1.5D” or “P1DT12H” for one-and-a-half days.
A time interval with a resolution identifies a series of discrete time instants defined by the starting time instant plus all whole-number multiples (0, 1, …) of the given resolution (period) earlier than or equal to the last time instant of the interval. (The “last” instant is a limit that is not necessarily included in the set of specified instants.) For example, “2010-01-05T17Z/2016-03-25T17Z/P14D” defines the first nanosecond of noon EST (disregarding Daylight Savings) of every second Tuesday in the time interval. The first time instant of the series is “2010-01-05T17Z”, the second, “2010-01-19T17Z”, and the last, “2016-03-22T17Z”. Note that precise time values in UTC do not necessarily align with time granularities, nor do resolutions.
If a time interval is given without a resolution to describe the times for which data is available, it means that any time instant (or interval) within the interval bounds can be requested (subject to any granularity restrictions).
It can also be useful to provide a resolution for a single time instant in order to distinguish it from data prepared for different time resolutions available at the same instant (e.g., daily, monthly, yearly relative to instant “2015-01-01”). The special notation “instant/resolution” is used where appropriate for this purpose.
8.3.8. Frames per second
For animations, an additional parameter can be appended to a time specification to request the number of frames per second to use for the animation. The format is “/Ffps”. The “fps” is a floating-point number. The default value is server-specific.
8.4. WMTS interface extensions
Time is added to the WMTS 1.0.0 interface using the existing Dimension metadata structure. The Capabilities document indicates precisely what times are available with a granularity indicator and a list of time semantics with start/end time intervals sometimes with time resolutions. ISO 8601 time-value encoding is used and it is important that time values be character-for-character-precise when used with static, pre-generated REST tiles. This allows a time-based WMTS to be implemented using only a plain web server with no special runtime component or by using a large-scale service like Amazon CloudFront to enable potentially millions of concurrent users.
8.4.1. Capabilities Dimension declaration
The structure of the WMTS 1.0.0 Dimension declaration is retained but with new values in the UOM and Value fields. This creates conflict between these field values which may necessitate a new version number for the WMTS to distinguish the semantics.
The UOM field (Unit Of Measure) shall identify and parameterize the granularity of a new time dimension and has the following format: “ISO8601/granularity”. The UOM “granularity” value is the numeric granularity level from 0 to 15 shown in the table in the “Time granularity” clause. It is important to explicitly express the time granularity to use with REST requests up front exactly one time in order to be clear and unambiguous. It is also useful to have a different UOM value from the WMTS 1.0.0 literal “ISO8601” to indicate for old clients that actually check that the enumerated values are to be handled differently from 1.0.0. Also, unless and until this specification is incorporated into the official WMTS standard, a different dimension name such as “QTime” (query time) should also be used to avoid compatibility problems with clients that are hard-wired to recognize the dimension name “Time” with the old encoding.
The time instants and time semantics available for querying are given in the Value fields of the Dimension. An example Dimension declaration is:
<Dimension> <ows:Identifier>QTime</ows:Identifier> <ows:UOM>ISO8601/3</ows:UOM> <ows:Title>Time</ows:Title> <ows:Abstract>blah blah blah</ows:Abstract> <Default>alltime</Default> <Value>at:2007-05-01/2007-07-31/P1D</Value> <Value>asof:2007-05-01/2007-07-31/P1D</Value> <Value>series:2007-05-01/2007-07-31/P1D</Value> <Value>interval:2007-05-01/2007-07-31</Value> <Value>anim.asof:2007-05-01/2007-07-31/P1D/F12</Value> <Value>anim.interval:2007-05-01/2007-07-31</Value> </Dimension>
Time values with the new semantics shall be identified by special short prefix strings. The WMTS 1.0.0 opaque-value semantics are maintained for all values that do not start with a new-time-semantic prefix. The new prefix shall be followed by an interval with a usually optional resolution which identifies precisely what time instants are legal for querying. If a resolution is given, it restricts legal query instants to only those that are integer multiples of the resolution from the starting time; otherwise, any time instant within the interval is legal. With time semantics that use a query interval in the client request, only legal time instants can be used for the starting and ending times of the interval. Animation semantics can also include an optional frames-per-second parameter if it is fixed by the server. Specifically, the Capabilities-declaration format is “prefix:first_instant/last_instant[/resolution].
The new time-semantic Value-prefix strings for single-frame still images are:
- at:
-
Selects a server-defined semantic for a single time instant. The WMTS 1.0.0 interface provides an interface to query tiles “at” specific server-defined time instants. The true meaning of the time instant is not clear, as it could be truly “at” a specific time instant, a time-series interval starting at or ending at the indicated time, data “as-of” a certain time, etc. Often, the precise semantic is unimportant or already known by the user. The server gives an accessible-time interval with an optional resolution; the client requests the sought time instant. The “at” client-query format is “at:instant”, for example, “at:2007-05-20”.
- asof:
-
Selects all times from the first time instant up to and including the given time instant. The “as-of” time-value semantic is probably the most useful for casual viewing. It can be used as a “time machine” to examine how the coverage area looked according to the most recently available data as of any time in the past. A GUI control might be a slider bar covering the time range of the available data. The server gives an accessible-time interval with an optional resolution; the client requests the ending time instant. The “as-of” client-query format is “asof:instant”, for example, “asof:2007-05-20”.
- series:
-
Selects one frame from a fixed time series identified by the first time instant of the frame. The resolution breaks the time interval into equal slices/frames (except perhaps for the last slice) and each slice includes its starting time and excludes the starting time of the next slice. The exact semantic of whether the time series defines instants or sub-intervals of time is server-dependent. Beware of the potential “fencepost problem” caused by the ending instant being inclusive. The server gives an accessible-time interval with a required resolution; the client requests a time instant plus the server-given resolution value (needed to disambiguate if multiple resolutions are available). In the case of a REST request, the resolution component shall be character-for-character exactly what the server gave. The time-series client-query format is “series:instant/resolution”, for example, “series:2007-05-20/P1D”. The implied query interval is from instant to instant + resolution − 1 nanosecond, modulo the data-availability interval.
- interval:
-
Selects all times in a given arbitrary inclusive time interval. Normally, all source data that overlaps the time interval is selected for processing. The server gives an accessible-time interval with an optional resolution; the client requests a time interval. The time-series client-query format is “interval:first_instant/last_instant”, for example, “interval:2007-05-20/2007-06-08”.
Each still-image/single-frame method has an animated counterpart with a prefix-prefix of “anim.”. An animation is an orthogonal concept that selects multiple sequential frames of the base semantic with a time interval and at a specified resolution. The resulting content will normally be generated into a format that can hold multiple frames of animation, such as an MPEG4 video file, and with an optional given frame rate. Specifically, the Capabilities-declaration format is “prefix:first_instant/last_instant/resolution[/frames_per_second]”. All of the different semantics have the same query format, with only the meaning of the content being different (at, as-of, interval).
- anim.at:
-
Selects an animation of “at” image frames. The server gives an accessible-time interval with a required resolution; the client requests a time interval with the same resolution. With a REST request, the resolution must character-for-character the same.
- anim.asof:
-
Selects an animation “as-of” image frames. The server gives an accessible-time interval with a required resolution; the client requests a time interval with the same resolution. With a REST request, the resolution must character-for-character the same. An example client query time might be “anim.asof:2007-05-11/2007-07-08/P1D/F12”.
- anim.series:
-
Selects an animation of fixed-time-series image frames. The server gives an accessible-time interval with a required resolution; the client requests a time interval with the same resolution. With a REST request, the resolution must character-for-character the same.
- anim.interval:
-
Selects an animation of arbitrary-interval image frames with an arbitrary time resolution. The server gives an accessible-time interval with an optional resolution; the client requests a time interval with an arbitrary client-chosen time resolution that need not have any relation to the server-advertised resolution if there was one. An example client query time might be “anim.interval:2007-05-06/2007-07-28/P7D/F2”.
The client can request any legal time defined by any Value field of a Dimension or by the Default field. The client and server are free to generate time values to any legal granularity except in the case of a WMTS REST request, where the client must use the time granularity indicated by the server unless the wildcard granularity (code 0) is indicated. The REST granularity, the granularities in Capabilities, the granularities in non-REST requests, and the time resolutions in different Value fields may all be different.
As an example, a WMTS may offer a static-REST “as-of” time Dimension Value that overlaps new imagery scenes every second Tuesday but maintains a history of previous data versions. It might advertise its valid times as “asof:2010-01-05T12Z/2016-03-23T12Z/P14D” with a granularity of Hours (code 4). The first valid request time instant would be “2010-01-05T12Z”, the second “2010-01-19T12Z”, and the most recent, “2016-03-22T12Z”.
To help with the forward-compatibility of old clients, the Default field could specify a special value to request “timeless” or all-time tiles. Servers could also accept the raw REST template-variable encoding as selecting the default value. E.g., a REST request might be for “https://…/mylayer/mystyle/{QTime}/smerc/…” or “…/%7BQtime%7D/…”. The server could recognize that a client does not understand Dimension usage and select the default time value. It could also recognize the client parroting back the literal time values specified in the Dimension declaration if invalid as meaning that an old client does not know how to parse new time values, and react accordingly. Faulty JavaScript clients may generate the value “undefined” when substituting the variable and the WMS specification seems to also allow the value “default”.
8.4.2. Key-value request interface
A key-value client shall request times for tiles by using the Dimension Identifier as the key, selecting an appropriate Dimension Value field, and computing a legal time value according to the time semantic. The request value shall include the same time-semantic prefix as the Dimension Value.
An example request might be:
Note that key-value parameter names are case-insensitive in OGC requests.
8.4.3. REST request interface
The REST method is specified in the Capabilities document using the ResourceURL template structure. The time key and value are computed similarly to key-value requests, and the value is substituted into the URI template variable with the same name as the key. For example, variable substring “{QTime}”.
There are three differences in generating the time values, however. The first difference is that the time instants shall be generated to the granularity indicated by the server in the UOM field. The second difference is that because of incompatibilities between REST URIs and the slash character used in ISO time intervals, etc., the slash character (“/”) in computed time values shall be substituted with two dash characters (“--”). The third difference is that with “series:”, “anim.at:”, “anim.asof:” and “anim.series:” time values, the time-resolution component shall be character-for-character exactly what the server indicated in the Dimension Value.
An example ResourceURL and REST-request URI are:
<ResourceURL format="image/png" resourceType="tile" template="https://website.org/wmts/my_layer/{Style}/{QTime}/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.png">
URI example:
The special characters in the REST URI may be escaped with the “%xx” hexadecimal notation. This is compatible with character-for-character encoding.
8.5. WMTS server implementation with enhanced time-varying layer support
For the Testbed-12 project, CubeWerx on behalf of Polar View, deployed a WMTS that serves tiles for arbitrary time intervals (trivially including the simpler semantics). As the tiles are necessarily generated on-the-fly, the “secret sauce” for such a server is its internal optimizations for dealing with a large volume of source data. Several such optimizations are planned. The time-based WMTS is accessed by a third-party viewer client to demonstrate interoperability for the project. CubeWerx also implemented a parallel WMS with time-query and animation capabilities.
We wanted to directly tackle the problem of handling arbitrarily selected time intervals so that we only need to go through the implementation effort once and it can be used for all of the time filtering needed. Specialized and limited time semantics like monthly time-series or monthly “as-of” tiles could have been pre-generated which would operate more efficiently, but we decided to focus on optimizing the general solution to perform adequate performance.
8.5.1. OWS Interfaces
The CubeWerx WMTS server implements the proposed time-query interface and uses wildcard time granularity (code 0) and supply “at:”, “asof:”, “series:”, and “interval:” time semantics through the REST and key-value-pair WMTS interfaces. The corresponding WMS interface offers the same single-frame semantics through a key-value-pair interface and also offers the animated versions of the semantics. Offering animations through the WMTS interface would make little sense since a viewer client would not be able to synchronize the multiple animated tiles on its display, even if it could process and position video files for playback.
8.5.2. Source data
The data used for the project is 16-bit single-band Advanced Synthetic Aperture Radar raster data that exists in small scenes at disconnected times near the north pole. The original source data has 37,939 TIFF images that occupy 6.7 TB of storage and cover two years of EnviSAT data from 2010-03-01 to 2012-02-29.
The original source data had a several problems: the timestamp values were encoded into the filenames instead of the TIFF headers; the no-data value was not explicit; the data contained a great deal of empty pixels and hence was needlessly bulky; the data was internally organized into scanlines rather than tiles, making access to zoomed-in portions of the images slower; it needed a great deal of contrast stretching to be visible; and the data was not corrected for sensor-intensity variations.
A script program was developed to repackage the source data so it could be used conveniently and efficiently. The timestamps were parsed out of the filenames and put into the Date/Time TIFF header; the no-data value was set explicitly using the GDAL No-Data tag; the pixel data was compressed within the TIFF format using the lossless Deflate compression method which reduced the data to about one-third of its original size; the new TIFF files were internally organized into 256×256 tiles for efficient access; and a suitable contrast-stretching method was developed. The source data now occupies 2.1 TB of storage. Corrected versions of data source scenes are still being sought.
8.5.3. Contrast enhancement
Contrast enhancement was an “unscheduled problem” in the project. The source data has a 16-bit pixel-sample range, or 0 to 65,535, but most of the actual data values are in the range of 400 to 2300, though a few samples in each image can go up to the 20,000 range or beyond. An ad-hoc method was needed to determine what range to use, how to record it in the images, and how to apply it at runtime.
Initially, a contrast enhancement specific to each individual source image was calculated by scanning the source samples and computing a histogram of the distribution of values and a percentile range was extracted. Samples from the 3rd to the 97th percentile produced a good contrast. A special value was written into the TIFF Description tag to record the contrast stretching that is needed on rendering the image and code was implemented to apply this stretching on-the-fly when reading the image, so that the original sample values remain intact in the source data.
After some experimentation it was decided to use a constant contrast stretch for all of the images in the collection. This helps to make the images have a more consistent appearance when selecting time same area at different times and when generating animations.
The source data itself, however, is ‘uncorrected’ in that the sensitivity of the sensor varies over the swath and between images in the same area, and this cannot be normalized by any simple means. The data provider is looking into providing corrected source data for us to use.
8.5.4. Dateline wrap-arounds
Handling dateline wrap-arounds was another “unscheduled problem” in the project. Since the source data is in the Polar Stereographic projection, EPSG code 3413, some scenes cross over the the antimeridian at ±180° longitude, which will call the “dateline”. This was not dealt with properly, so we needed improve our handling of time complication in many levels of our system. This took some time and effort. On the other hand, the source data does not touch the North Pole since the EnviSAT satellite does not pass close enough to the North Pole; there is an almost perfect empty circle around the North Pole when all of the data is plotted.
8.5.5. Performance and functionality enhancement
Numerous changes were needed to our existing system to handle time queries efficiently. The low-level spatial-database-access methods needed to be reorganized and then augmented with time functionality. Low-level methods were implemented to parse, generate, and compute time values for the new external representation.
A special optimization was added to the map/tile-rendering methods to make them use far less memory when source-data scenes are deeply stacked on top of each other, since the source data for this project can be stacked thousands of levels deep, and a related optimization was added to avoid retrieving and rendering earlier-timed source data that is completely hidden behind later source data that is plotted over top. The processing of reprojection distortions was improved to better handle strongly diverging resolutions, as between the Polar Stereographic and Spherical Mercator projections near the North Pole.
The WMTS and WMS Capabilities-document reporting and request parsing was updated for time queries, including time-series for Day, Week, Month, and Year recurrence periods. The WMS interface was also extended to handle animation requests that return an MPEG-4 video stream.
The general approach used is to render all of the source-data scenes that are selected by the spatial and time-interval constraints of a query, but this can result in too much work when zoomed way out to an area that covers too many source files. So, an optimization was added to partially pre-generate tile content in this case to drastically reduce the amount of work that needs to be done on-the-fly.
The result is that time-filtering WMTS queries normally take under one second with some taking about two seconds to execute. This is considered to be “good enough” for this project. Several additional optimizations were considered, all of which reduce the amount of processing that needs to be done on-the-fly to satisfy a request, but they are not needed for this project. Tile queries for all of time use fully pre-generated tiles when zoomed out so that all queries for the native tile-image format can be satisfied directly by the web server within a millisecond (excluding network-transfer time) and queries for non-native formats can be satisfied in under 50 milliseconds. The scalability of the server for concurrent users is around 10 users for time-filtering queries and hundreds of users for all-time queries.
8.6. AWST WMTS client implementation
For the Testbed-12 project, AWST on behalf of Polar View deployed a WMTS viewer client (http://80.120.183.78:3001/) that allows the user to select time constraints for viewing the data.
The client is based on the Cesium – WebGL Virtual Globe and Map Engine, the TerriaJS software developed by NICTA, Australia and the NationalMap software which was originally established to provide access to spatial data from Australian government agencies. All three are open source software projects. The client software is organized such that these individual open source components can independently be updated when new versions become available.
The source data on the server side is accessed via WMTS where the client automatically generates data queries when the user selects a data source in the client, navigates on the Virtual Globe 2D or 3D map or changes the zoom level. Queries are generated for all tiles covered by the currently visible area in the map.
The WMTS access is enhanced by time queries, where the user selects the desired query type for each data source. While all allowable query types are in principle supported, the asof: and series: time semantics are explicitly configured for user selection where series options are preconfigured for daily, weekly, monthly, and yearly series. The query time is selected in an interactive time slider in the client GUI with the selectable time range defined by the server providing the data. The following example shows the GUI design of AWST WMTS client. The supported time-query semantics are selectable under the dropdown box on the left side panel (1). The temporal value is selectable on the time slider bar on the bottom of the GUI. With the selected time-query semantic and temporal value, the AWST WMTS client generates the collection of WMTS requests with enhanced time-query semantics and requests the corresponding time-varying layers on the back-end WMTS server.
Data-animation options are implemented and tested for two different approaches. In the first animation approach, the time slider is enhanced by a “play button” feature to scan thought the available time period at different speeds. As the time advances the client automatically generates queries with the new time for the same geographic area in daily intervals. Faster scans through time quickly lead to performance issues if the server response arrives only after the next query has already been submitted. The user does not see a smooth animation in this case but rather gets incomplete images with only a few tiles, which seem to randomly change.
A number of improvements were implemented in order to achieve a better image-update performance. The server side performance improvements are described in the previous sections. The client was modified to pre-fetch the data in the sense that data for a new requested time slice is loaded while the previous image is still displayed. This has the effect that the user sees complete images in the client as long as data loading completes before the tile requests for the next time slice are submitted. Further, better parallelization of tile requests has been investigated. This aspect was found to depend on the specific web browser, which is used to launch the visualization client. While the number of parallel http queries in generically limited to a maximum of 6 in Google Chrome, this limit is configurable in the Firefox browser. Setting this limit to 32 essentially allows requesting all tiles at the same time, at which point the server performance becomes the next limiting factor. In summary this type of time scanning is useful for automatically updating images at limited speed but does not yield a movie-like animation experience for the user. Animation performance is more limited in 3D mode where the 3D re-projection is performed in the client.
In the second animation approach, the data source is accessed via WMS to use the MPEG-4 video stream provided by the server implementation. The user can select the data source via WMS and then request a video for the currently displayed area where start and end time of the period to be covered are selected in the client’s time slider element. The video query is submitted to the server upon user request, and the user can continue with other activities in the client while waiting for the server response. Once the video stream is received it is automatically opened in the default video player. As opposed to the first approach this is an asynchronous interaction where the user has to wait a while for the server to respond and the response time depends on the amount of data which is covered both geographically and by the requested time period. However, the client is not blocked while waiting for the response, hence the user can continue working with the client, and the received video stream yields a smooth animation experience, which does not depend on external performance limitations.
Following is a sample WMS request for a small video of ice moving in the Nares Strait (between Greenland and Canada) that is generated on-the-fly with a WMS request. The generated video is 2.9 MB in size. It takes about 31 seconds to generate, and returns an MPEG4 video file that should be playable in most browsers. The “PT12H” in the QTime parameter means that each frames covers 12 hours of data time and the “F4” means to generate four frames per second in the output video file.
In parallel to work on the data interface and performance improvements, the user interface of the client was enhanced with a focus on users who are primarily interested in the polar regions.
The client development work in this project provided insights into both technical performance and usability issues and yielded feasible approaches to tackle these issues. Future work may include further optimization of data pre-loading, improvements to performance of the viewer in 3D mode and further usability enhancements to the user interface focusing on specific use cases within larger scenarios.
9. WMS for NetCDF
9.1. Improvements on the WMS support of map rendering
With the rising demand from the diverse end-user communities for geospatial tools to handle multidimensional products, many geospatial applications now have new functionalities that enable the end user to store, access, analyze, and visualize these EO data sets. One such visualization approach of NetCDF files uses the ncWMS. In this section, the non-standard WMS parameters from ncWMS are introduced as the extension to the WMS to improve the map render and GetCapabilities content filtering.
9.1.1. Extensions on WMS GetMap operation to support additional map render options
Besides standard GetMap parameters, the following additional parameters from ncWMS are introduced as the extension parameters of WMS GetMap operation.
Extended WMS parameter | Description |
---|---|
COLORSCALERANGE |
Of the form min,max this is the scale range used for plotting the data (mapped to the COLORSCALERANGE_MIN and COLORSCALERANGE_MAX env vars) ] |
NUMCOLORBANDS |
The number of discrete colors to plot the data. Must be ]between 2 and 250 (mapped to the NUMCOLORBANDS env variable) |
ABOVEMAXCOLOR |
The color to plot values which are above the maximum end of the scale range. Colors are of the form 0xRRGGBB or 0xAARRGGBB, and it also accepts “transparent” and “extend” |
BELOWMINCOLOR |
The color to plot values which are below the minimum end of the scale range. Colors are of d the form 0xRRGGBB or 0xAARRGGBB, and it also accepts “transparent” and “extend” |
LOGSCALE |
“true” or “false” - whether to plot data with a logarithmic scale |
OPACITY |
The percentage opacity of the final output image as a number between 0 and 100 (maps to OPACITY env var by translating it to a number between 0 and 1) |
ANIMATION |
“true” or “false” - whether to generate an animation. The ncWMS documentation states that TIME has to be of the form <tt class="docutils literal">starttime/endtime</tt>, but C:\work\ogc\ows12\work\LSA_NA005_ER\er_wms_wmts_OGC16-042\includes\images\redblue-default.png TIME needs to be a list of discrete times instead. Animation requires using the “image/gif” as the response format (as the only format supporting animation) |
9.1.2. Examples
The supported render parameters improve the flexibilities and effects of map rendering through WMS GetMap. The improvements are illustrated through the following examples.
-
Render map with dynamic palette through WMS GetMap
-
Launch a viewer (GetMap with format=application/openlayer):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test:rain&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers
-
Retrieve an image (GetMap):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test:rain&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=image/jpeg
-
Retrieve the legend (GetLegend):
http://cloudsdi.geo-solutions.it/geoserver/ows?service=WMS&request=GetLegendGraphic&format=image/png&width=20&height=20&layer=test:rain
-
-
Render map with custom range/custom color number/above and below range colors through WMS GetMap
-
Launch a viewer (GetMap with format=application/openlayer):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test:rain&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers&colorscalerange=100,5000&numcolorbands=10&abovemaxcolor=0x000000&belowmincolor=0xFFFF00
-
Retrieve an image (GetMap):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test:rain&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=image/jpeg&colorscalerange=100,5000&numcolorbands=10&abovemaxcolor=0x000000&belowmincolor=0xFFFF00
-
Retrieve the legend (GetLegend):
http://cloudsdi.geo-solutions.it/geoserver/ows?service=WMS&request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=test%3Arain&colorscalerange=100,5000&numcolorbands=10&abovemaxcolor=0x000000&belowmincolor=0xFFFF00
-
-
Render map with log-scaling color schema through WMS GetMap
-
Launch a viewer (GetMap with format=application/openlayer):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test:rain&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers&colorscalerange=1,6000&logscale=true
-
Retrieve an image (GetMap):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test:rain&styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=image/jpeg&colorscalerange=1,6000&logscale=true
-
Retrieve the legend (GetLegend):
http://cloudsdi.geo-solutions.it/geoserver/ows?service=WMS&request=GetLegendGraphic&format=image%2Fpng&width=20&height=20&layer=test%3Arain&colorscalerange=1,6000&logscale=true
-
-
Customize layer opacity through WMS GetMap
-
Launch a viewer (GetMap with format=application/openlayer):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=countries,test:rain&styles=,&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=application/openlayers&opacity=50
-
Retrieve an image (GetMap):
http://cloudsdi.geo-solutions.it/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=countries,test:rain&styles=,&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&format=image/jpeg&opacity=50
-
-
Generate layer animation through WMS GetMap
-
Layer animation through time dimension (layer composite through the time interval between 2016-02-01 and 2016-03-01):
http://cloudsdi.geo-solutions.it/geoserver/wms?STYLES=,x-Sst&LAYERS=countries,flexpart&FORMAT=image%2Fgif&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-137,15,-110,42&WIDTH=600&HEIGHT=600&time=2016-02-01/2016-03-01&animation=true&bgcolor=0x0066CC
-
Layer animation on elevation dimension
http://cloudsdi.geo-solutions.it/geoserver/wms?STYLES=,x-Sst&LAYERS=countries,flexpart&FORMAT=image%2Fgif&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-137,15,-110,42&WIDTH=600&HEIGHT=600&elevation=0/2000&animation=true&bgcolor=0x0066CC
-
9.2. Improvements on the mechanisms of WMS metadata filtering
9.2.1. Limitation on current WMS GetCapabilities filtering
The WMS layer metadata is advertised in the GetCapabilities document. With the increasing number of layers being advertised through the GetCapabilities document, requesting the GetCapabilities document tends to consume significant bandwidth and internet resource. In this section, an additional GetCapabilities parameter (i.e., DATASET) is proposed as a way for the client to efficiently subset relevant GetCapabilities content based on the dataset/layer of interest.
The parameter still makes the server return a valid capabilities document that can be used by any application, it’s thus suited to be used from existing clients and linked from dedicated search pages (e.g., a CSW/OpenSearch search result).
This is unlike XPATH based approaches, that do not require an external search engine, allow actual text based searches into the capabilities document, returning all the matched elements (e.g., to get a full list of all layer names). This approach does however require a client that has been developed to leverage the search and handle its results.
9.2.2. Extensions on WMS GetCapabilities operation
Extension on GetCapabilities request parameter
Extended GetCapabilities parameter | Description |
---|---|
DATASET |
The parameter will be set with layer/dataset name. Once the parameter is provided in the request, only content regarding the layer/dataset will be returned. |
GetCapabilities response for specified layer
A schema-valid GetCapabilities response is returned with layer metadata being specified in the DATASET request parameter.
9.2.3. Examples
-
Retrieve the GetCapabilities document with the full set of layer metadata
-
Full capabilities document:
http://cloudsdi.geo-solutions.it/geoserver/ows?service=wms&request=GetCapabilities
-
-
Retrieve the GetCapabilities document based on a specific layer
-
The GetCapabilities for the flexpart layer:
http://cloudsdi.geo-solutions.it/geoserver/ows?service=wms&request=GetCapabilities&dataset=flexpart
-
The GetCapabilities for the rain layer:
http://cloudsdi.geo-solutions.it/geoserver/ows?service=wms&request=GetCapabilities&dataset=rain
-
9.3. Improvements on the WMS support for map querying
ncWMS extends the GetFeatureInfo with a few variants targeted to retrieve evolution of a phenomenon on a specific point over time or elevation, or at a fixed them and elevation, but along a path. In particular:
-
GetTimeSeries has the same structure as a GetFeatureInfo call, but requires a TIME parameter expressing a time range, and will generate either a dump of all values at the point of interest in the specified time interval, or generate a chart
-
GetVerticalProfile has the same structure as GetFeatureInfo, but requires an ELEVATION parameter expressing an elevation range, and will generate either a dump of all values at the point of interest in the specified elevation interval, or generate a chart
-
GetTransect has the same structure as a GetMap, but requires a LINESTRING parameter with a comma separated list of "x,y" values, and will extract a chart of the phenomenon evolution along the path. If the dataset contains an elevation, a parallel chart will be generated showing the elevation at the same points.
During the testbed a GetTimeSeries implementation has been included.
-
Retrieve the evolution of the "flexpart" phenomenon over time at point clicked on the map, in the 2016-02-23T03:00:00.000Z/2016-02-26T00:00:00.000Z time range:
http://cloudsdi.geo-solutions.it/geoserver/test/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetTimeSeries&FORMAT=image%2Fgif&TRANSPARENT=false&STYLES&LAYERS=test%3Aflexpart&SRS=EPSG%3A4326&WIDTH=600&HEIGHT=600&BBOX=-137.4169921875%2C20.56640625%2C-111.0498046875%2C46.93359375&time=2016-02-23T03:00:00.000Z/2016-02-26T00:00:00.000Z&QUERY_LAYERS=test%3Aflexpart&INFO_FORMAT=image/png&x=335&Y=217