Posts Tagged ‘view service’

INSPIRE Harmonized Layer Names in GeoServer

In 2011 GeoServer made significant steps forward to support INSPIRE View Services based on WMS 1.3.0. For those of you not familiar, INSPIRE is the European Spatial Data Infrastructure. At the end of this effort there was still a missing piece — supporting harmonized layer names.

What’s a harmonized layer name? Simply put it means that the WMS needs to advertise its layer according to a pre-defined name which is listed  in the INSPIRE data specifications. If you were to look at table 19 of the data specification for transport networks you’d see that there is a layer which should be named “TN.CommonTransportElements.TransportNode”. Historically you were never able to achieve a harmonized layer name because GeoServer outputs the namespace prefix in front of the user defined name.

To remedy this OpenGeo utilized work done on GeoServer virtual services. The namespace prefix on a virtual service does not make layer names unique and was dropped. For technical details see  JIRA issue 5016 and please note that this work is only available in the GeoServer 2.2 release.

Our thanks to our client Ordnance Survey for supporting this enhancement, and to Juan Marin and Justin Deoliveira for the development work.

INSPIRE View Service and GeoServer

GeoServer has come a long way towards INSPIRE compliance in the past year. It has added support for Web Map Service (WMS) 1.3, enhancements towards Symbology Encoding (SE) 1.1, and there’s an upcoming implementation of Web Feature Service (WFS) 2.0.

Interested in helping GeoServer achieve full INSPIRE compliance through funding or development? Please contact us at inquiry@opengeo.org.

In March of this year, the European Commission published version 3.0 of the Technical Guidance document for INSPIRE View Services (based on ISO19128 / WMS 1.3). This mandates that countries within the European Union must implement the Initial Operating Capacity by May 9 and Quality of Service requirements by November 9.

There are two scenarios defined for implementation:

  1. The GetCapabilities document is extended with a link to a Catalogue Service for the Web (CS-W) for the ISO19119 Service Metadata
  2. Extra elements are embedded into the GetCapabilities document itself

The current implementation with GeoServer focuses on implementing only the first scenario and, although INSPIRE does not require multilingual support, is currently limited to only serving up in one language.

I recently investigated which issues remain for GeoServer to meet all of the requirements of the INSPIRE View Service 3.0 specification. I have listed the relevant issues here, along with links back to the GeoServer issue tracker:

  • While GeoServer does support adding keywords to the WMS GetCapabilities response, it does not yet support the optional vocabulary attribute, in which one can specify the thesaurus used. (#4658)
  • For each Coordinate Reference Systems (CRS) advertised for a layer, GeoServer must provide a corresponding BoundingBox element. (#4659)
  • AuthorityURL and Identifier are not yet supported but are required to link to the gmd:MD_Identifier from the Metadata for datasets (ISO19115). (#4491)
  • MetadataURL type does not support the value of ISO19115:2003. (#4595)

And finally, there are two minor issues that will only affect those certain highly-specific use cases:

  • The advertized LegendURL does not include a STYLE parameter. This only affects those cases where a View Service is configured with more than just the inspire_common:DEFAULT Style. (#4661)
  • The Cascaded attribute is not used by GeoServer when cascading other WMS services. This attribute needs to reflect the number of times a layer was cascaded. (#4662)

We hope to fix these issues soon to make GeoServer truly INSPIRE-compliant with respect to the View Service 3.0 specification.