Adding support for View Services (WMS & WMTS) ETS

[carlospzurita]

ETF Improvement Proposal (EIP)

Background and Motivation:

In the development of new ATS and ETS for the Technical Guidelines 2.0 of INSPIRE, the ETF has been found in need of some components for the View Services validations in the SOAP UI integration, as discussed in https://github.com/etf-validator/etf-webapp/issues/149 .

Proposed change

To be able to develop the ETS for WMS and WMTS, the following classes need to be included in the de.interactive_instruments.xtf.wms package in the etf-sui-owsgtl library.

• GetMapRequest
• GetCapabilitiesRequest
• Service
• ContactInformation
• ContactAddress
• Capability
• CapabilityRequest
• CapabilityException
• CapabilityLayer
• EX_GeographicBoundingBox
• BoundingBox
• Layer
• Style
• LegendURL

Also the correspondant classes for WMTS package.

Alternatives

The steps taken so far in the analysis of this issues have been:

1. Analysis of the etf-sui-owsgtl library
2. Analysis of the Download services implementation
3. Definition of required classes for the WMS & WMTS protocols, following the Technical Guidelines and replicating the model of Download Services
4. Implementation of said classes, using stubs methods and datatypes where needed

Currently, we are following an iterative process to detect problems, pindown the needed changes and adding the missing features running ETSs against these implementations; streamlining in each iteration the process, to finally have a reproducible workflow for new protocols or INSPIRE themes.

Funding

This development is funded by JRC

[jonherrmann]

Could you please describe a bit more detailed why the following classes would be required and what there responsibilities would be:

• GetMapRequest ( please describe why a SoapUI Http Request Test Step cannot be used, like in the WFS tests)
• GetCapabilitiesRequest (same here)
• Service (sounds like an abstract object, responsibilities, etc. are unclear for me)
• ContactInformation (is this a really an object with functionalities or just a data holder. How many times are the information used during a test?)
• ContactAddress (same here)
• Capability (same like Service. Does this reflect a single Capability in a Capabilities document? Could you give an example)
• CapabilityRequest (what is a Capability Request? Do you mean the / structure in the Capabilities document?)
• EX_GeographicBoundingBox (what is the difference between the EX_GeographicBoundingBox, a BoundingBox and this existing BBox element?)
• Layer (what is the difference to this class?)

Also the correspondant classes for WMTS package.

Can you already foresee what new classes for a WMTS would be required that could not be used from the WMS?

[carlospzurita]

Hi Jon, thanks for your comments. Here are some clarifications:

• We are developing the GetMapRequest class extending HttpRequest, in the same manner that is done on the WFS package, for example GetFeatureRequest
• The same principle is applied here
• Service is a metadata holder for storing GetCapabilitiesRequest's service tag
• This is a data holder. How many times it will be used, will depend on the developed tests, we can't predict this number
• Contact address is the same case as ContactInformation
• Capability is used for storing the information in the Capability tag, for a GetCapabilitiesRequest. The contents would be the ones on this example, from http://www.ign.es/wms-inspire/mapa-raster?request=GetCapabilities&service=WMS
• CapabilityRequest is a class used on the previous Capability object, holding the information on the Request tag
• EX_geographicbox has the same purpose as BoundingBox, as you have pointed out. So it shouldn't be developed
• We are extending this class tha it was already present for holding the Layer tag in GetCapabilities

For WMTS, data holders and request would be different from wms, because it has another format response and another parameters. therefore, new classes and methods should developed. We are still in the process of analyzing what the classes, methods and attributes should be needed, but the classes

• Service
• ContactInformation
• ContactAddress
• BoundingBox

could be reused for this service.

If you have any additional comments, or like further clarifications, please let us know.

[jonherrmann]

Hi Carlos, thanks for the information.

I was expecting that the classes have any other function than just holding data. Several years ago, we implemented some simple WMS tests in another project and extended the library for that. All that was needed was the layer class. I think it is not necessary to create objects for functionalities that can be accessed directly in SoapUI as the ContactInformation. But this aspect is not that important to me.

We are developing the GetMapRequest class extending HttpRequest, in the same manner that is done on the WFS package, for example GetFeatureRequest

OK, but the INSPIRE tests do not use the GetFeatureRequest object.

[jenriquesoriano]

To do: Analyze the WFS behaviour Analyze the WMS ETS from https://github.com/Geonovum/etf-test-projects-inspire/tree/master/src

[carlospzurita]

We checked the provided code from Geonovum, where everything is encapsulated in a single SoapUI project. Although it seems good to run a test this way, we think that for the sake of code maintainability and clarity, the code should be more modular, as other components of the ETF.

OK, but the INSPIRE tests do not use the GetFeatureRequest object.

We are aware that this method is not used by the INSPIRE tests, is just an auxiliary method for handling HttpRequest to a WFS. We are just replicating the work methodology for WMS.

[jonherrmann]

https://github.com/etf-validator/etf-sui-ae/pull/4

[jonherrmann]

Implemented in Version 2.1.0