[Geoserver-devel] Make WMTS service INSPIRE compliant

Hi,

The goal here is to make the WMTS service compliant with the INSPIRE directive. The needed changes
are related with the result of the GetCapabilities operation.

The INSPIRE technical guidance for the view services (which includes WMS and WTMS) is available here:
http://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.11.pdf

I submitted the current output of WMTS GetCapabilities operation to the INSPIRE validator:
http://inspire-geoportal.ec.europa.eu/resources/sandbox/INSPIRE-c725a726-2f0e-11e6-bc3d-52540023a883_20160610-152519/services/1/resourceReport/

After reading the technical guidance, I come to the conclusion that three mandatory elements are missing:

  • Metadata about supported languages and response languages (inspire_vs:ExtendedCapabilities).
  • Metadata for each layer (ows:Metadata), this is optional in WMTS standard.
  • Styles legend URL this, is optional in WMTS standard.

There is also the harmonized layer names requirement … going through the GeoServer UI and INSPIRE module
documentation I could not found if this is supported or not (basically we need to drop the work space prefix
which can lead to layer names collisions this is why I’m wondering if this is supported or not).

INSPIRE also brings this two mandatory constraints:

  • The output format should be either PNG or GIF format. (without LZW compression)

  • It is mandatory to use geographical coordinate system based on ETRS89 in continental Europe and ITRS outside continental Europe.

A service admin page will be created for WMTS, we need this to provide a specific URL metedata that will
describe the service itself.

Ideally all the needed changes will be contributed to the INSPIRE extension module. But first, we need a way to extend
the WMTS service GetCapabilities operation result. I could not found any existing extension points that will
allow me to do this. In this thread
http://osgeo-org.1560.x6.nabble.com/Adding-a-multidimensional-extension-to-WMTS-as-a-GeoServer-community-module-with-integrations-with-G-td5268826.html

Andrea Aime proposes the WMTSExtension interface … this could be a solutions for this.

One more thing, the INSPIRE validator complains that MinTileRow, MaxTileRow, MinTileCol and MaxTileCol values are out of range, I still
don’t understand why he is complaining about those values.

This is all the information I gathered until now, feedback on this will be appreciated :slight_smile:

Regards,

-- 
==
GeoServer Professional Services from the experts! 
Visit http://goo.gl/it488V for more information.
==
Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:   +39 0584 1660272
mob:   +39  333 8128928

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono
da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate
nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e
-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo
anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of
the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree
June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying,
distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender does not give any warranty or accept liability as the content,
accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which
arise as a result of e-mail transmission, viruses, etc.

After reading the technical guidance, I come to the conclusion that three
mandatory elements are missing:

* Metadata about supported languages and response languages
(inspire_vs:ExtendedCapabilities).
* Metadata for each layer (ows:Metadata), this is optional in WMTS
standard.
* Styles legend URL this, is optional in WMTS standard.

There is also the harmonized layer names requirement ... going through the
GeoServer UI and INSPIRE module
documentation I could not found if this is supported or not (basically we
need to drop the work space prefix
which can lead to layer names collisions this is why I'm wondering if this
is supported or not).

What is the "harmonized layer name requirement"?
- Do the names need to be consistent within the service - if so including
the namespace prefix consistently everywhere would be fine?
- If not consider that only virtual WMS and WMTS services could be
compliant (not the global service).

What part of the prefix is throwing off the standard - do they enforce a
naming convention beyond the WMS spec?

INSPIRE also brings this two mandatory constraints:

* The output format should be either PNG or GIF format. (without LZW
compression)

* It is mandatory to use geographical coordinate system based on ETRS89 in
continental Europe and ITRS outside continental Europe.

A service admin page will be created for WMTS, we need this to provide a
specific URL metedata that will
describe the service itself.

You may need to pursue this in partnership with the GeoWebCache codebase,
since WMTS protocol is implemented there (and we embed the resulting
application).

Ideally all the needed changes will be contributed to the INSPIRE extension

module. But first, we need a way to extend
the WMTS service GetCapabilities operation result. I could not found any
existing extension points that will
allow me to do this. In this thread

http://osgeo-org.1560.x6.nabble.com/Adding-a-multidimensional-extension-to-WMTS-as-a-GeoServer-community-module-with-integrations-with-G-td5268826.html

Andrea Aime proposes the WMTSExtension interface ... this could be a
solutions for this.

I do not know enough about the GeoWebCache codebase, perhaps join that
developer list and sort out an approach. You can also make a proposal when
ready to outline the approach you wish to take.

One more thing, the INSPIRE validator complains that

MinTileRow, MaxTileRow, MinTileCol and MaxTileCol values are out of range,
I still
don't understand why he is complaining about those values.

What are the values?

This is all the information I gathered until now, feedback on this will be
appreciated :slight_smile:

Thanks for sharing, look forward to hearing how this work goes :slight_smile:

Hi Jody,

Thanks for the feedback, please see my answers inline.

If we publish a layer that match a layer present in the INSPIRE data specifications we should use the pre-defined name:
http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/annex2and3_guidance_documents.zip

GeoServer appends the workspace as a prefix to the layer name, hence (unless I miss something) we are not able to use the pre-defined name.

The images formats constraint can be forced with an ows:Constraint element for each layer in the get capabilities result.
Being only able to query tiles in GIF or PNG is very restrictive, we may add the option to only include this constraints if we are in a strict INSPIRE compliance mode.

Using the correct geographical coordinate system is up to the user.

Yeah I will synchronize with GWC community.

The values are zero, after looking at the message error more carefully I found that this issue have already been reported.
This is an issue with the OGC schema: https://sourceforge.net/p/geowebcache/mailman/message/32424600/


<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

> After reading the technical guidance, I come to the conclusion that three mandatory elements are missing:
> 
> * Metadata about supported languages and response languages (inspire_vs:ExtendedCapabilities).
> * Metadata for each layer (ows:Metadata), this is optional in WMTS standard.
> * Styles legend URL this, is optional in WMTS standard.
> 
> There is also the harmonized layer names requirement ... going through the GeoServer UI and INSPIRE module
> documentation I could not found if this is supported or not (basically we need to drop the work space prefix
> which can lead to layer names collisions this is why I'm wondering if this is supported or not).

What is the "harmonized layer name requirement"?
- Do the names need to be consistent within the service - if so including the namespace prefix consistently everywhere would be fine?
- If not consider that only virtual WMS and WMTS services could be compliant (not the global service).

What part of the prefix is throwing off the standard - do they enforce a naming convention beyond the WMS spec?

> INSPIRE also brings this two mandatory constraints:
> 
> * The output format should be either PNG or GIF format. (without LZW compression)
> 
> * It is mandatory to use geographical coordinate system based on ETRS89 in continental Europe and ITRS outside continental Europe.
> 
> A service admin page will be created for WMTS, we need this to provide a specific URL metedata that will
> describe the service itself.

You may need to pursue this in partnership with the GeoWebCache codebase, since WMTS protocol is implemented there (and we embed the resulting application).

> Ideally all the needed changes will be contributed to the INSPIRE extension module. But first, we need a way to extend
> the WMTS service GetCapabilities operation result. I could not found any existing extension points that will
> allow me to do this. In this thread
> [http://osgeo-org.1560.x6.nabble.com/Adding-a-multidimensional-extension-to-WMTS-as-a-GeoServer-community-module-with-integrations-with-G-td5268826.html](http://osgeo-org.1560.x6.nabble.com/Adding-a-multidimensional-extension-to-WMTS-as-a-GeoServer-community-module-with-integrations-with-G-td5268826.html)
> 
> Andrea Aime proposes the WMTSExtension interface ... this could be a solutions for this.

I do not know enough about the GeoWebCache codebase, perhaps join that developer list and sort out an approach. You can also make a proposal when ready to outline the approach you wish to take.

> One more thing, the INSPIRE validator complains that MinTileRow, MaxTileRow, MinTileCol and MaxTileCol values are out of range, I still
> don't understand why he is complaining about those values.

What are the values?

> This is all the information I gathered until now, feedback on this will be appreciated :)

Thanks for sharing, look forward to hearing how this work goes :)

</details>

If we publish a layer that match a layer present in the INSPIRE data
specifications we should use the pre-defined name:

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/annex2and3_guidance_documents.zip

GeoServer appends the workspace as a prefix to the layer name, hence
(unless I miss something) we are not able to use the pre-defined name.

1. So use virtual web service end point and the prefix wont be listed /
required.
2. You could also publish these layers in the workspace nominated as the
default workspace, then the prefix would not be required. But I expect the
capabilities document would still list the prefix?

If you really need to suppress the prefix I expect you will need to follow
#2 and supress the prefix in the GetCapabilities document when publishing
the default workspace.

The images formats constraint can be forced with an ows:Constraint element

for each layer in the get capabilities result.
Being only able to query tiles in GIF or PNG is very restrictive, we may
add the option to only include this constraints if we are in a strict
INSPIRE compliance mode.

Surely that constraint is only addative in nature, listed formats that must
be required...

Good luck!