European Commission logo
INSPIRE Community Forum

Issues related to the setup of WFS 2.0 fully conformant to INSPIRE Technical Guidelines for Download Services: Revision

Starting from the INSPIRE glossary definition of what a ‘dataset’ is, this page aims at collecting implementation issues related to the setup of WFS 2.0 services for INSPIRE datasets reported through TC discussions.

Addressed question is: Is it possible to setup WFS services fully conformant to INSPIRE Technical Guidelines for Download Services or there are software issues hindering the fulfillment of one or more requirements in the TG?

This page is read-only, should you have any news on the status of reported issues, or should you want to report a new issue/ add any news, please post a relevant discussion on the Cluster.

I will update this page accordingly when relevant. 

What is an INSPIRE dataset?

The definition of "dataset" in INSPIRE is taken from ISO 19115, and defines a dataset as an “identifiable collection of data”.

Hence, generally speaking, an INSPIRE dataset is not necessarily linked to an individual application schema, but ,conversely, can contain a variety of feature types from more than one application schema - e.g. Protected Sites and relevant Administrative Units and Geographical Names.

(find more details in TC discussion

Considering that an INSPIRE dataset can be composed of features coming from different application schemas is important to understand what is described below and regards the setup of WFS for INSPIRE datasets.

According to the Technical Guidelines for Download Services, ”A separate WFS endpoint shall be provided for each INSPIRE dataset thus providing one dataset per GetCapabilities response.” (Requirement 52)

This requirement implies, among others, that

  • One single endpoint should be able to provide multiple features from different INSPIRE schemas
  • Different datasets for the same application schema (e.g. one PS dataset containing only CDDA sites and one PS dataset containing only Natura2000) should be provided by means of different endpoints.

Are current software tools for the setup of web services able to satisfy Req 52 and fully conform to INSPIRE TG?

A very interesting TC discussion on this topic can be found at

At your convenience, you may find there very detailed descriptions. Hereinafter find a brief summary of topics contained therein:

Update 8 September 2016:  Snowflake GoPublisher WFS seems able to fulfil Req. 52

Update 9 May 2018: 


For those data providers that need to serve feature types from one application schema at one endpoint Deegree is fulfiling the Req 52. Deegree is able to serve two different datasets for the same application schema at different endpoints (e.g. CDDA and Natura2000 asking for typeNames=ps:ProtectedSites in both cases).

Under investigation whether new release 3.4-RC5 is able to serve several features from different application schemas through a single endpoint.

You might be interested in having a look at the  “Improved support on INSPIRE” issue (” containing a list of deegree issues related to INSPIRE and the changes introduced in latest deegree versions in order to provide better support to INSPIRE implementers.


1. In a Geoserver instance it is possible to serve the same featureType at different endpoints only if changing its prefix -i.e. XML namespace- even if using isolated workspaces and virtual services endpoints available in latest 2.13 release.

For example, it is possible to serve a Protected Sites feature type at different endpoints only using different prefix (e.g. cdda:ProtectedSite and natura2000:ProtectedSite). This because the namespace prefix is inherited from the name of the workspace. This breaks INSPIRE requirements identifying the xml prefix as the one from the application schema (for protected sites is ps:ProtectedSites)

2. In a Geoserver instance is not possible to serve more than once the feature based on the same xsd. This means that e.g. it is possible to serve a dataset composed by ps:ProtectedSites features and their corresponding gn:GeosgraphicalNames features at a certain endpoint, but it is not possible at another endpoint in the same instance to serve as well a dataset composed of au:AdministrativeUnits and their corresponding gn:GeograpficalNames features (because the gn:GeograpficalNames is already served in the PS dataset)

Biodiversity & Area Management

Biodiversity & Area Management

If themes like Protected Sites, Area Management/Restriction/Regulation Zones and Reporting Units, Habitats and Biotopes, Species Distribution, Bio-geographical Regions matters to you, join these groups!