Skip to content

GSIP 162

Emanuele Tajariol edited this page Aug 22, 2017 · 10 revisions

GSIP 162 - WMTS cascading

Overview

Add the ability to create WMS layers backed by remote WMTS layers.

Share the same rationale as WMS Cascading.

Proposed By

Emanuele Tajariol

Assigned to Release

This proposal is for GeoServer 2.12-beta.

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

WMTS cascading allows for proxying a remote WMTS server and merging the results with locally rendered data. This can be useful for a number of reasons:

  • printing
  • reprojecting
  • watermarking and decoration in general
  • proxying a secured remote WMTS into an intranet available server

(Same as WMS cascading).

Proposal

  • Create a WMTS Store class: it's bound to a remote WMTS server, which esposes the various layers.
  • Create a WMTS Layer class: it's bound to a remote WMTS layer, and proxies the various info, such as CRS, bounding box and custom dimensions.
  • Extend the REST API to handle the WMTS stores and WMTS layers.

Implementation

(Reflects closely WMS cascading).

A note about the authors: Implementation has initially been done by Ian Turton, and then continued by Emanuele Tajariol.

Catalog level

The catalog sees two new CatalogInfo subclasses, WMTSStoreInfo and WMTSLayerInfo.

WMTSStoreInfo, a StoreInfo subinterface, describes a WTMS server connection such as the capabilities link, and could contain other information such as authentication credentials and http timeout. A couple of attributes, "HTTP header name" and "HTTP header value", have been added since an initial use case required a special authentication using HTTP headers.

WMTSLayerInfo, which extends ResourceInfo contains the layer name and eventually will be be place to host eventual vendor parameter to be used during the cascading.

The ResourcePool has been modified to cache the WebMapTileServer object used during the cascading operations so that the capabilities request gets cached as a result.

The persistence subsystem (XStream, loader and persister) have been modified to store the new objects following the same conventions as the other stores and resources, the main difference being that the store is described in a wmtsstore.xml file whilst the the cascaded WMTS layer is described in a wmtslayer.xml file.

Example XML file contents for WMTS stores:

<wmtsStore>
    <id>WMTSStoreInfoImpl--79041489:15cf3fa500d:-7fff</id>
    <name>WMTS_NASA_REST</name>
    <type>WMTS</type>
    <enabled>true</enabled>
    <workspace>
        <id>WorkspaceInfoImpl--570ae188:124761b8d78:-7ff3</id>
    </workspace>
    <metadata>
        <entry key="useConnectionPooling">true</entry>
    </metadata>
    <__default>false</__default>
    <capabilitiesURL>https://gibs.earthdata.nasa.gov/wmts/epsg4326/best/wmts.cgi?SERVICE=WMTS&amp;request=GetCapabilities</capabilitiesURL>
    <maxConnections>6</maxConnections>
    <readTimeout>60</readTimeout>
    <connectTimeout>30</connectTimeout>
</wmtsStore>

and for a WTMS layer:

<wmtsLayer>
    <id>WMTSLayerInfoImpl-37c0eec1:15cf454e2d3:-7fff</id>
    <name>WMTS_AIRS_CO_Total_Column_Day</name>
    <nativeName>AIRS_CO_Total_Column_Day</nativeName>
    <namespace>
        <id>NamespaceInfoImpl--570ae188:124761b8d78:-7ff4</id>
    </namespace>
    <title>Carbon Monoxide (Total Column, Day, AIRS, Aqua)</title>
    <nativeCRS>GEOGCS[&quot;WGS 84&quot;, 
        DATUM[&quot;World Geodetic System 1984&quot;, 
            SPHEROID[&quot;WGS 84&quot;, 6378137.0, 298.257223563, AUTHORITY[&quot;EPSG&quot;,&quot;7030&quot;]], 
            AUTHORITY[&quot;EPSG&quot;,&quot;6326&quot;]], 
        PRIMEM[&quot;Greenwich&quot;, 0.0, AUTHORITY[&quot;EPSG&quot;,&quot;8901&quot;]], 
        UNIT[&quot;degree&quot;, 0.017453292519943295],
        AXIS[&quot;Geodetic longitude&quot;, EAST],
        AXIS[&quot;Geodetic latitude&quot;, NORTH],
        AUTHORITY[&quot;EPSG&quot;,&quot;4326&quot;]]</nativeCRS>
    <srs>EPSG:4326</srs>
    <nativeBoundingBox>
        <minx>-180.0</minx>
        <maxx>180.0</maxx>
        <miny>-90.0</miny>
        <maxy>90.0</maxy>
        <crs>EPSG:4326</crs>
    </nativeBoundingBox>
    <latLonBoundingBox>
        <minx>-180.0</minx>
        <maxx>180.0</maxx>
        <miny>-90.0</miny>
        <maxy>90.0</maxy>
        <crs>EPSG:4326</crs>
    </latLonBoundingBox>
    <projectionPolicy>FORCE_DECLARED</projectionPolicy>
    <enabled>true</enabled>
    <store class="wmtsStore">
        <id>WMTSStoreInfoImpl--79041489:15cf3fa500d:-7fff</id>
    </store>
</wmtsLayer>

The CatalogBuilder has been extended to deal with the new objects, as a bonus the builder feeds all reusable metadata coming from the WMTS server capabilities document into the WMTSLayerInfo ones.

User interface

The usual store -> layer workflow has been maintained adding a new custom page to configure the WMTS store.

Icons to identify a WMTS store, layer and type have been copied from the WMS ones.

Add a new store

New store

Edit a WMTS store

Edit store

Stores list

Store list

Create layer: choose store

Choose store for layer

Publish WMTS layer

Publish layer

WMTS module

Cascading has been implemented by using the GeoTools tile-client, and in particular the WMTSMapLayer class, a MapLayer that makes most of the work making the renderer think it’s dealing with a coverage.

Supported features:

  • Standard cascading
  • Reprojected cascading, including the ability to pass the SRS down to the remote server should the SRS be included among the remote server supported list, otherwise the request is passed down in a supported SRS, adjusting the image ratio accordingly, and reprojecting client side (this part needs fixing)

REST configuration

The PR adds new paths to represent a WMTS store and a WMTS layer. The follow the same patters as data stores and feature types, but use different locations:

/workspaces/{workspace}/wmtsstores/{wmtsstore}.{format}
/workspaces/{workspace}/wmtsstores/{wmtsstore}
/workspaces/{workspace}/wmtsstores.{format}
/workspaces/{workspace}/wmtsstores
/workspaces/{workspace}/wmtsstores/{wmtsstore}/layers/{wmtslayer}.{format}
/workspaces/{workspace}/wmtsstores/{wmtsstore}/layers/{wmtslayer}
/workspaces/{workspace}/wmtsstores/{wmtsstore}/layers.{format}
/workspaces/{workspace}/wmtsstores/{wmtsstore}/layers
/workspaces/{workspace}/wmtslayers/{wmtslayer}.{format}
/workspaces/{workspace}/wmtslayers/{wmtslayer}
/workspaces/{workspace}/wmtslayers.{format}
/workspaces/{workspace}/wmtslayers

Besides the path the behavior to the various kind of HTTP methods is exactly the same as with data stores and resources, meaning they both can be listed, shown, created by POST, updated by PUT, removed by DELETE. It’s also possible to list the available, but still unpublished, wms layers in a given store (to be checked).

Missing features

  • getFeatureInfo not implemented (the WMS GetCapabilities will return queryable="0" for all WMTS layers)

Backwards Compatibility

There are no backwards compatibility issues.

Feedback

Voting

Project Steering Committee:

  • Alessio Fabiani: +1
  • Andrea Aime: +1
  • Ben Caradoc-Davies:
  • Brad Hards:
  • Christian Mueller:
  • Ian Turton:
  • Jody Garnett: +1
  • Jukka Rahkonen:
  • Kevin Smith:
  • Simone Giannecchini: +1

Links

Clone this wiki locally