Testbed-12 WMS/WMTS Enhanced Engineering Report

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).

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:

The following time-query semantics are proposed as the extension of WMTS to better support time-varying layer query.

The following extended ncWMS GetMap parameters were proposed and introduced to support additional map render options in WMS.

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:

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:

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:

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.

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.

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.

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.

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.

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:

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.)

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.

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.

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.

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:

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:

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).

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”.

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:

https://website.org?SERVICE=WMTS&REQUEST=GetTile&VERSION=1.0&LAYER=my_layer&STYLE=my_style&TILEMATRIXSET=smerc&TILEMATRIX=4&TILEROW=3&TILECOL=6&FORMAT=image/PNG&QTime=series:2007-06-04/P1D

Note that key-value parameter names are case-insensitive in OGC requests.

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:

URI example:

https://website.org/wmts/my_layer/my_style/series:2007-06-04-P1D/smerc/4/3/6.png

The special characters in the REST URI may be escaped with the “%xx” hexadecimal notation. This is compatible with character-for-character encoding.

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.

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.

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.

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.

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.

Besides standard GetMap parameters, the following additional parameters from ncWMS are introduced as the extension parameters of WMS GetMap operation.

The supported render parameters improve the flexibilities and effects of map rendering through WMS GetMap. The improvements are illustrated through the following examples.

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.

The latest official version of WMTS (Web Map Tile Service) is 1.0.0 [WMTS 1.0.0]. It includes a limited mechanism for dimension based queries.

Specific values must be explicitly enumerated, implying the practical usage is limited to small domains, and the dimension is opaque to the client, which is going to use the dimension values as-is in requests, without any understanding of them.

The latest official version of WMS (Web Map Service) is 1.3.0 [WMS 1.3.0]. It has a more-sophisticated dimension support than WMTS. An example declaration section might describe regular domains in a compact way by providing a start, end, and resolution:

This allows regular domains to be described in a compact notation, however one that still fails to address discovery of the relationships between the domains. For example, in the above example a 3 days weather forecast is run periodically to generate temperature values at various heights in the atmosphere: it’s thus clear to the reader there is a tight relationship between time and run-time, while a single time is related to multiple run-times, the run-time values related to a time T are to be found in the interval [T - 3d,T].

A client unaware of such relationship will thus generate requests that match no actual data in the dataset.

It is to be noted that, while the two dimensional space does not appear as an explicit Dimension element in the capabilities document, it is nevertheless an important element of discovery, especially for scattered domains populated by satellite or aerial sources (as opposed to models, which instead tend to always consider the same area).

Each domain resource/operation will then accept a target range of values for each dimension (space included), and will return the restricted domain/values of the others as described below.

Specifically for WMTS, the representation of space is normally provided as a TopLeftCorner in the tile matrix set CRS, a resolution and number of tiles. For the sake of simplicity, the extension will use a bounding box using the same syntax and semantics as the BBOX parameter in WMS 1.3 [WMS 1.3] instead. This won’t make WMTS clients and servers more complex, as on both sides there is already a need to convert between tile coordinates and world coordinates.

A new operation/resource is added to the WMTS protocol describing all the dimension domains in a compact document, along with the restricted bounding box of the two dimensional space intercepted by the request.

The domain description is delivered by a new DescribeDomains operation in procedure oriented architectural style, and a Domains resource in resource oriented architectural style.

The DescribeDomains operation accepts the following parameters:

The following is a sample request assuming a Dimension definition with an ows:Identifier value of time:

http://server.com/ows?Service=WMTS&Request=DescribeDomains&Version=1.0.0&Layer=Imagery&TileMatrixSet=CRS84&BBOX=0,0,90,180&time=2008-01-15T00:00:00.000Z/2008-11-01T00:00:00.000Z

The Domains resource is described by a URL template at the Layer level and works in a similar fashion, using -- as the interval separator in requests

The following are a sample template and a request assuming a Dimension definition with an ows:Identifier value of time:

http://server.com/ows/wmts/1.0.0/layer/default/CRS84/-30,10,20,40/2008-01-15T00:00:00.000Z—​2008-11-01T00:00:00.000Z.xml

The response contains the residual space and domain of various dimensions. To accommodate competing needs of clarity and compactness, the residual domain can be expressed as a comma separate list of:

A few examples:

A compact dimension domain description contains the following elements.

The following document declares the dimension domains for an unrestricted request:

A request restricting on the -30,10,20,40 bounding box might result in an elevation domain compact enough to be expressed in enumerated mode:

A further restriction on the same bbox and an elevation value outside of the previous list would result in:

Given a scattered domain description, a client might want to provide users a notion of the data distribution between the minimum and maximum value. The histogram divides the interval in regular buckets, and provides an item count for each bucket.

The distribution histogram is delivered by a new GetHistogram operation in procedure oriented architectural style, and a Histogram resource in resource oriented architectural style. The client is allowed to suggest a desired resolution for the buckets, the server can accept and use the suggested value, or return a histogram with a lower resolution in the suggested value would result in an exceedingly large response.

The GetHistogram operation builds on top of the DescribeDomain structure, adding parameters to identify the histogram dimension, and the desired histogram resolution:

The following is a sample request assuming the Capabilities document contains a Dimension definition with an ows:Identifier value of time:

http://server.com/ows?Service=WMTS&Request=GetHistogram&Version=1.0.0&Layer=Imagery&TileMatrixSet=CRS84&BBOX=0,0,90,180&time=2008-01-15T00:00:00.000Z/2008-11-01T00:00:00.000Z&histogram=time&resolution=P1D

The Histogram resource is described by a URL template at the Layer level and works in a similar fashion, using -- as the interval separator in requests.

The following are a sample template and request assuming a Dimension definition with an ows:Identifier value of time:

http://server.com/ows/wmts/1.0.0/layer/default/CRS84/-30,10,20,40/2008-01-15T00:00:00.000Z—​2008-11-01T00:00:00.000Z/time/auto/histogram.xml

The response contains the distribution histogram for the specified dimension, under the specified restrictions.

A histogram description contains the following elements.

In the following request the client requires a hourly histogram over a space of 11 months, the server considers the request excessive and returns a monthly histogram instead:

Once the range of possible values has been suitably restricted, the client might need to enumerate the actual possible value combinations using a GetFeature operation, which in a similar way to WFS [WFS 2.0] GetFeature, returns a list of features along with dimension values using the same formats as the feature info operation. For this profile GML 3.1 shall be provided as a feature info format ("application/gml+xml; version=3.1") a similar GeoJSON output should be considered as an option.

Each dimension shall be represented as an attribute of the feature, while the space component is encoded as a polygon/multipolygon, which can be as simple as a bounding box, or a full fledged footprint of an EO feature.

The GetFeature operation accepts the following parameters.

The Features resource is described by a URL template at the Layer level and works in a similar fashion, using -- as the interval separator in requests.

The encoded GML result contains an indication of the footprints and other dimension values.

In this use case, the WMTS client interacts with WMTS server which implements the following three new WMTS operations:

The use case will demonstrate:

The WMTS client/server interactions are illustrated with the following sequence diagram. The detail workflow is also discussed in this sub section.

This example shows interaction for a forecast model having elevation, time and REFERENCE_TIME (the forecast execution time). The elevation domain is compact and independent of the other two dimensions. Time and REFERENCE_TIME depend on each other instead.

1. The WMTS client requests GetCapabilities document

The WMTS client retrieves the WMTS GetCapabilities document for the following information.

Available layers (XPath:/Capabilities/Contents/Layer/ows:Title)

Dimension info under each available layer (XPath:/Capabilities/Contents/Layer/Dimension)

Tile matrix configuration (XPath:/Capabilities/Contents/TileMatrixSet)

2. The WMTS client requests DescribeDomains for compact layer domain inspection

Request:

In the following response, the enumeration of domain values are returned for each dimension under the layer of test:flexpart_time_series.

Request:

In the following response, the domain values are only returned for the dimensions (i.e. elevation, time, REFERENCE_TIME) overlapping the elevation dimension between 0.0 and 1000.0 and REFERENCE_TIME 2016-02-25T00:00:00.000

Request:

In the following response, the domain values are only returned for the dimensions (i.e. elevation, time, REFERENCE_TIME) overlapping the elevation dimension between 0.0 and 1000.0 and the time dimension between 2016-02-23T03:00:00.000Z and 2016-02-23T12:00:00.000Z.

The client can use the SpaceDomain output to avoid requesting empty tiles. In this example the SpaceDomain does not change by the DescribeDomain request as the forecast model is operating over a fixed area.

3. The WMTS client requests GetHistogram for inspecting domain distribution histogram

The client is supposed to have two histogram bars in the UI, showing an elevation and time histogram:

Request:

In the following response, the domain value histogram is returned for the elevation dimension, which overlaps the time dimension between 2016-02-23T00:00:00.000Z and 2016-02-26T00:00:00.000Z. The histogram shows a growing number of samples over time as the overlap of predicted times between model runs increases.

This information, along with the DescribeDomain results, helps drive the user navigation in the dataset until a small enough dataset can be located.

4. The WMTS client requests GetFeature for detailed spatial footprint of each layer

Once the user drives the client in an area with few enough datasets, the client can issue a GetFeature and show the footprint of each dataset.

Request:

The follow snippet of GetFeature response advertises one available WMTS layer with the dimensions of 'elevation', 'time' and 'REFERENCE_TIME'. The response also advertises the spatial footprint of the WMTS layer in the element of wmts:footprint.

5. The WMTS client calculates the available map tiles (i.e., tile column/row)

The WMTS client calculates the tile indices (i.e., tile column and row index) from the bounding box (i.e., the spatial footprint of the available layer) by following the algorithm in [OGC 07-057r7] (Annex H, section H.1).

6. The WMTS client requests map tiles

With the calculated tile indices, the WMTS client requests the WMTS tiles with GetTile operation. Since the spatial footprint in the GetFeature response indicates the spatial area where map tiles are available, the calculated tile indices only include non-empty map tiles. This benefits the WMTS clients by preventing the client from accessing empty map tiles.

In this example the layer landsat8:B3 contains a dataset with a single time dimension, but scattered in space: given a certain area, the times available will be limited, and then given a certain time, the spatial domain will be restricted.

1. The client looks at the whole dataset

The client starts the interactions by issuing a DescribeDomains and a GetHistogram.

Request:

The client learns in which area data is actually available by inspecting the spatial domain, and will issue requests only in that area.

Request:

The client also issues a GetHistogram, setting the time resolution to one day given the long time span returned by DescribeDomain, and displays the satellite scene distribution over time in a histogram.

2. The user focuses on a specific time range

The user decides to focus on a specific day, e.g. "2016-10-19T00:00:00.000Z", the client thus repeats the DescribeDomain and GetHistogram for that specific day.

Request:

The client learns the area with available data is significantly smaller and adjusts the tile requests accordingly.

Request:

The client also issues a GetHistogram, discovering the are 3 images available for that time value (the time dimension actually being an acquisition date).

The user sees only 3 features are available, and asks the client do display the satellite scene footprints, the client issues a GetFeature request.

Request:

The client issues the request and display the footprints, along with their dimension values, on screen.