European Commission logo
INSPIRE Community Forum

External code list values (Natura2000AndEmeraldBio-geographicalRegionClassificationValue)

In this discussion, Iurie MAXIM wrote:

In Data Specifications Guideline for Biogeographical Regions ( ) is stated at page 24 Natura2000AndEmeraldBio-geographicalRegionClassificationValue

Name: natura 2000 and emerald bio-geographical region classification value

Definition: Codes for the bio-geographic region classification.


Extensibility: open (My note: in the UML schema is writen "extensibility = none", meaning it is closed)


Values: The allowed values for this code list comprise the values specified in "COMMISSION IMPLEMENTING DECISION of 11 July 2011 concerning a site information format for Natura 2000 sites (notified under document C(2011) 4892) (2011/484/EU)" and additional values at any level defined by data providers.”

Based on the text in the Data Specification Guidelines my understanding is that the following links must exist in the INSPIRE registry:

They are published by EEA as well here:

The question is, why these values are not stored in the INSPIRE Registry ? By looking at other codelists that are “opened” I see that all these have no values. My understanding is that if a codelist is opened, it does not mean that it can be empty. It mean that it can be extended, but that it should have some values if the guidelines are providing information about their content.

As currently there are no values, how can somebody provide the Bio-geographical regions dataset according to 4.0 XSD schema ?


Stephania used in her example this link for the dictionary of Biogeographical Regions:

It should be noted that it exist as well the older one, valid as well:

To be mentioned that there exist as well a 2015 codelist, that is newer than 2011 used bt Stephania, the difference being in the way is written the Name/Label ("Alpine Bio-geographical Region" in 2015 vs. “Alpine” in 2011)

Hoever does not exist.

If looking how the EEA constructed the links of the “vocabularies”, always when a new dictionary will be released by EEA the link will change. Either the year will change at the end, either the number of version will be changed (“biogeographical-regions-europe-3”). My understanding is that this is not ok for the codelists and is not to clear for me that the links at EEA are codelists according to OGC GML standard.  As well these codelistsIds are not written in UpperCamelCase according to the recommendation 19 of the D2.7.

We will use this kind of link even if this link does not exist.

Whom must we ask to update the INSPIRE registries ?

Best regards,

Iurie Maxim

  • Michael LUTZ

    Dear Iurie,

    thanks for pointing out the issues related to the code list Natura2000AndEmeraldBio-geographicalRegionClassificationValue ( There are indeed a number of errors/inconsistencies, mainly in the data specifications document.

    The authoritative source is of course the legal act (Regulation 1089/2010), where the code list is defined in section 16.2.3 of Annex IV as follows:

    16.2.3. Region Classification (RegionClassificationValue)

    Codes used to define the various bio-geographical regions.

    The allowed values for this code list comprise the values of the following code lists or other code lists defined by data providers:

    — Environmental Stratification Classification (...)

    — Marine Strategy Framework Directive Classification (...)

    — Natura 2000 And Emerald Bio-geographical Region Classification (Natura2000AndEmeraldBio-geographicalRegionClassificationValue): Codes for the classification of bio-geographical regions, as specified in the Code List for Bio-geographical Regions, Europe 2011, published on the web site of the European Environment Agency.

    — Natural Vegetation Classification (...)

    This means the allowed values of the code list is not defined in INSPIRE, but are only references to an external code list, in this case the "Code List for Bio-geographical Regions, Europe 2011, published on the web site of the European Environment Agency".

    In the INSPIRE registry, for external code lists, only the reference for the external source is provided, but not the actual values. This is done, because the governance for the values lies outside INSPIRE. However, there are already plans to also publish (but purely for information) also the values that should be used in INSPIRE for such external code lists, i.e. in this case the ones you have listed (note that your URIs are lacking a "-" between "Bio" and "geographical".

    The data specification guidelines should be updated, however., in order to make it consistent with the IRs and registry. 

    • Since the definition in the IRs does not explicitly allow (as in other similar places) additional (narrower) values defined by data providers, it can be considered closed. The extensibility should therefore be changed consistently to "none" in the DS and also in the registry.
    • In section, the values should not include "and additional values at any level defined by data providers."
    • The tables in section 5.3.4 Externally governed code lists should be updated, in particular the instructions and examples for the identifiers.

    I am not sure why the EEA has updated the labels in the 2015 version of the code list. But I agree that the identifiers for the regions should not change because of this (if the semantics are still the same). In any case, INSPIRE explicitly refers to the 2011 version, so this version and the corresponding labels should be used.

    In summary, using Please note that, while this still returns a 404 error page, it also says:

    If you requested an item contained in the Natura 2000 And Emerald Bio-geographical Region Classification, please note that these items are governed externally and are not currently included in this registry.

    For more information on the item contained in the Natura 2000 And Emerald Bio-geographical Region Classification, please refer to the reference document Codes for the classification of bio-geographical regions, as specified in the Code List for Bio-geographical Regions, Europe 2011, published on the web site of the European Environment Agency.

    Hope that helps,


  • Iurie MAXIM

    Dear Michael,

    Thank you for indicating the fact that a minus is missing in the links (is from a copy and paste error, as if copying the text link from the Data Specification Guidelines and pasting it, the minus vanishes)

    If using the link that seems at least to me the obvious one to be used, the link from the error message please refer to the reference document Codes for the classification of bio-geographical regions, as specified in the Code List for Bio-geographical Regions, Europe 2011, published on the web site of the European Environment Agency” is not poining at all to the "reference document" that is mentioned in the text, but rather is pointing to that is not providing to much guidance, expect the fact that is mentioning the Commission Implementing Decision 2011/484/EU, that is listed as well in the Technical Guidelines for BR.

    Same information exist as well in the BR Data Specification Guidelines ( at page 24 under Natura2000AndEmeraldBio-geographicalRegionClassificationValue:

     ”The allowed values for this code list comprise the values specified in "COMMISSION IMPLEMENTING DECISION of 11 July 2011 concerning a site information format for Natura 2000 sites (notified under document C(2011) 4892) (2011/484/EU)" and additional values at any level defined by data providers.”

    According to the point 5 from the Appendix of the Commission Implementing Decision 2011/484/EU, ( the Biogeographical Regions in Europe are ”maintained by DG Environment & European Environmental Agency (EEA)”, and in the footnote at the end of the Annex it is mentioned as well that the reference is ”managed by DG Environment and the Habitats Committee” (where the Habitats Comitee is formed by MS representatives).

    Having these in mind the Natura2000AndEmeraldBio-geographicalRegion codelist cant be considered that is ”governed by an organisation outside of INSPIRE” as you mentioned, but rather it must be considered as a ”Code lists that is governed by INSPIRE”.

    In the Data Specification Guidelines ”World Meteorological Organization (WMO) or the World Health Organization (WHO)” are given as examples of organistations outside of INSPIRE, being hard to understand that DG Environment and EEA are falling under the same category of organisations outside INSPIRE.

    Therefore, to whom we must write in order to update the INSPIRE registry for BR (natura 2000 and Emerald) in order to deliver a harmonised dataset ?

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear Iurie,

    what is meant by "governed by an organisation outside of INSPIRE” is that it is not up to the INSPIRE governance structures (the MIG, INSPIRE Committee, ...) to decide about changes in the code list, but some other organisation or governance structure like in this case the Habitats Committee, as you point out. While it may be easier to liaise with this Committee from the INSPIRE governance structures than e.g. with WMO, it is ultimately the same situation.

    We have taken note of your request to include the externally governed values in the INSPIRE registry (for information) and will discuss with the registry development team, by when this change could be implemented. Obviously, we would want to do this for all externally governed code lists, not just this one, and some of them contain thousands of values, so the implementation might not be straightforward.

    In the meantime, please use the URIs you already proposed, with the local ids published by the EEA at So some example values would be:

    We will also try to update the information provided for the reference document with some more useful information.

    HTH, Michael


  • Iurie MAXIM

    Dear Michael,

    Clear it helps, thank you!

    Hope that will be helpful for other data providers as well and for completing the registries (even if for Natura 2000 species for example there are hundreeds of values).

    Hope that if using INSPIRE registries, INSPIRE will be helpfull for reporting as well.

    The WFS 2.0 service for natura 2000 and emerald biogeographical regions is available at:

    Just to remember that this thread was opened not for BR, but because we noticed the change in annex I data themes from XSD schemas version 3.0 to schema 4.0 is actually changes the way the codelists are encoded, changing "gml:CodeType" into "gml:ReferenceType”, based on the change from GML 3.2 to GML 3.3.

    To better understand this, the encoding in gml:CodeType would look like:

    <br:regionClassification codeSpace=">marineBlackSea</br:regionClassification&gt;

    As far as the link exist, the data is harmonized.

    The values, such as "alpine" or "marineBlackSea" can be taken from the Portrayal section of the Data Specification Technical Guidelines

    Encoding as gml:ReferenceType looks like:

    <br:regionClassification xlink:href="; xlink:title="Marine Black Sea"/>

    There are several problems to be addressed because of the use of the gml:ReferenceType encoding:

    1.       The GIS software need to be able to display the data stored as xlinks (in data served trough WFS). Thanks to Fabio, we now know that this can be done with ”WFS 2.0 Client” tool by configuring it from ”Web” menu. No other solution/software seems to exist yet and this is quite a chalange for INSPIRE in order to ensure the usability of the services provided within the INSPIRE Network.

    2.       The values must exist in the registries even if they are managed outside or inside INSPIRE and the data providers need to know exactly which are the values to be used in "xlink:href". Of course it is preferably that all the registries to be managed in INSPIRE registry even if they are internal or not. At least for European institutions like DG Environment or EEA I am sure that a technical solution exist in order to allow them to manage the codelists under their responsability. If the values of the registries are stored on other sites than INSPIRE, then the INSPIRE registry must point exactly to that location. However this is not a good solution as those links can change and values as well with no notice. Best solution is that a copy of those registries to be kept in INSPIRE registries together with the historical changes. To give just an example, even if IUCN ( is an external organization, the categories of protected areas according to the IUCN classification are stored in INSPIRE registry at

    The registries managed at MS level must be exposed and harvested at the INSPIRE Registries level, in a similar way as the metadata is harvested trough CSW services. I know that the Directive is not mentioning Registries, but data harmonisation cant be ensured in INSPIRE withouth registries.

    3.       The guidelines are not describing clearly what to write in ”xlink:title” and even they do not say that the ”xlink:title” is obligatory to be filled. However the values for ”xlink:title” need to be harmonized in order to be used at least for the Legend of the data. It is not clear if the ”xlink:title” must be in English or in the language of the dataset. It is not clear how to deal if the dataset will be in more than one language. Most probably the guidelines must state that the ”xlink:title” must be filled with the value of ”Label” from the registry either English (preffered) or in the (main) language of the dataset. For example for xlink:href="" the value of xlink:title="national park" (in English) or xlink:title="parc național" (in Romanian, but this value must exist in the registry.

    4.       Data Specifications Guidelines must be changed in order to reflect the changes from 3.0 to 4.0 schema versions.

    Related to point 3 for example, taking into consideration the BR Data Theme

    What to chose for xlink:title in order to ensure that the dataset is harmonized (I ordered based on my preference):

    a)   xlink:title="Marine Region Black Sea"

    if taking into consideration the “Name” of the biogeographical regions as stored in the 2011 EEA codelist_bio-geographical.xls available at and in the latest codelist (2015) from EEA

    b)   xlink:title="Regiunea Marină Marea Neagră"

    if taking into consideration the correct translation of "Marine Region Black Sea" in Romanian and if the language of the dataset will be declared as beiing Romanian.

    c)   xlink:title="Marine Black Sea"

    if taking into account the “preffered label” from vocabulary, not quite ok as it is missing the word ”Region” that is critical for the understanding of the label. Most probably this is the reason why EEA updated the codelist in 2015.

    d)   xlink:title="marineBlackSea"

     if taking into consideration the “id” or “Notation” from vocabulary, almost probably this is not the case, as the value is not human readable.


    Best regards,

    Iurie Maxim

  • Christian ANSORGE

    By Christian ANSORGE

    Dear colleagues,

    Thanks to Michael to point me on this particular discussion. I cannot add much which hasn't been already explained. Just to clarify again.

    The EEA operates a registry - similar to the INSPIRE registry - for EIONET and reporting related data flows, called Data Dictionary ( This is the space where EEA codelists are stored and maintained but it is oriented mainly towards environmental data flows. 

    We became aware that in several places across different INSPIRE data specifications links to EEA Data & Maps are used, which should instead point to the EEA Data Dictionary. EEA Data & Maps ( is our data portal but it isn't meant to as registry for codelists (despite is provides among others information about codelists).

    For BGR there are 2 codelists on the Data Dictionary, 2007 and 2011 ( The latest version of the BGR data set available on EEA Data & Maps ( is using the 2011 codelist version.

    I hope this clarifies a bit further.

    Best regards


  • Iurie MAXIM

    Dear Christian Ansorge,


    The problem is a litle more complex.  As you may see in this discution the data providers cant deliver the data according to Data Specifications Technical Guidelines with the codelists encoded as ”gml:ReferenceType” (as required for Annex II and Annex III data themes  and for Annex I Data themes according to version 4.0 XSDs). No problems exist only for Annex I data themes in 3.0 XSD version.

    The problem resides in the fact that the codelists are encoded as gml:ReferenceType that have xlink:href and xlink:title as attributes.

    To be more clear, for example in order to be able to serve a value from a code list, a data provider need to specify where the codelist resides on the internet and which is the value from the codelist.

    Therefore the encoding will look like:

    xlink:href=”http://anValidURL/anValidValue&rdquo; where http://anValidURL/anValidValue and http://anValidURL/ are a valid links, so if using a browser an user will not get an error if accessing those links .

    Unfortunately these links do not exist for many codelists (including the values), so the the data providers cant provide the datasets. Even in the Data Specifications Guidelines there are a lot of codelists that are provided as links to PDFs, Excel files, html pages, etc (all those beeing unusable for encoding as xlinks). DG Env is requiring MS to provide datasets and data providers are in the imposibility to provide the data as the registries do not exist in a form of http URL, or if they exist, there is no indication which one to use. Most of them do not exist at all (or do not have values).

    For example, if reading the Data Specifications Technical Guidelines for Biogeographical Regions, at page 26 it states in table that the codelist for ” Natura2000And EmeraldBiogeographicalRe gionClassificatio nValue” has as authoritative source ” Natura 2000 STANDARD DATA FORM, annex of document 2011/484/EU, Section 2.6. Natura2000AndEmeraldBiogeographicalRegionClassificationValue”. No http link was provided here in order for data providers to know where they can find the values to include in the ”xlink:href=”.

    The only official place for a data provider to consult codelists is actualy the INSPIRE Code List Registry, that unfortunately under ”” does not list any values. It just include in the description the following link Give it a try and it will say ”Data Table – expired” and is telling ”data-and-maps/data/biogeographical-regions-europe-2 was published”. Actualy the current version even is not ”2”, but ”3” and it can be found here ””. But, as you may see there is no registry here to be sued, namely, there are no http links for each biogeograhical region to be used.

    For data to be compliant, a data provide need to have functional URLs of this form for example:

    Of course, the data specifications guidelines, or at least the INSPIRE Codelist Registry need to tell to data providers where these links are mentained.

    As these links do not exist, a data provide is not able to provide the datasets.

    It is important to be noted that at the date when all the data Specifications Guidelines were drafted the encoding of codelists was not as ”gml:ReferenceType”, but as "gml:CodeType". This last one did not created so many issues because the data provide was able to encode a codelist value by indicating the codeSpace (this can be taken from the INSPIRE Codelist Registry) and the value. It was not necessary that all values to have the corresponding  URLs.

    For example, it was no problem to provide the biogeographical regions as gml:CodeType, because the link to the codelist exist:

    <br:BiogeographicalRegion codeSpace="">alpine</ br:BiogeographicalRegion>

    But it is not possible to provide the biogeographical regions as gml:ReferenceType as it is currently required, because the link to the codelist values do not exist:


    As the EEA is responsible for the maintanace of the majority of the codelists and as these do not exist in the form required for INSPIRE implementation, Member States are not able to provide the datasets required by the provisions of the Directive, including the IRs and the Technical Guidelines.

    I indicated as well that the EEA is not maintaing corectly the codelists as it is changing the http URLs when new versions apear instead of making the status for old values as ”invalid”. Withouth corectly maintaing the codelists, the data providers and the users will have real problems in providing/using those datasets in INSPIRE. Most probably for reporting obligations under CDR the data providers have no issues, but as EEA is requesting already MS to be prepared to report in INSPIRE format, at least EEA must understand how critical and important is that the registries to be mainained. The does not follows the rules that are necessary for the proper INSPIRE implementation as the URLs are changing while the versions are changing.

    Thank you for your clarification, but can yopu mention which of the codelists you mentioned is that one that the data providers need to use for INSPIRE? For sure it must be only one, not more. So, which one of this 4 codelists prepared by EEA is that codelist for Biogeographical Regions to be used for INSPIRE ?




    d) (according to the INSPIRE Registry)

    Strictly according to the INSPIRE Code List Registry the following link for the ”Alpine” bio-geographical regions” must exist, but of course de link does not exist.

    According to your email, most probably the is the code list, so for the Alpine biogeographical region the link must exist, but it does not exist.

    Personaly I hardly understand that DG Environement and EEA are falling under this kind of organisations and that EEA cant manage the INSPIRE Codelists for which it has responsabilities in the INSPIRE Codelist Registry:

    ”Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists). These code lists are managed by an organisation outside of INSPIRE, e.g. the World Meteorological Organization (WMO) or the World Health Organization (WHO). Change requests to these code lists follow the maintenance workflows defined by the maintaining organisations. Note that in some cases, no such workflows may be formally defined”

    while IUCN that is an international organization ( that is for sure an organization outside of INSPIRE is falling in the category of ”Code lists that are governed by INSPIRE (INSPIRE-governed code lists). These code lists will be managed centrally in the INSPIRE code list register. Change requests to these code lists (e.g. to add, deprecate or supersede values) are processed and decided upon using the INSPIRE code list register‘s maintenance workflows.” with its codelist

    Maybe a solution would be to name these externaly governed codelists as ”Code lists maintained outside of INSPIRE Registry”, and not to use ”organisation outside of INSPIRE”, but better would be if EEA and DG Environment and other European organisations such as Eurostat, etc to maintain the codelists in the INSPIRE Registry, or the INSPIRE Registry to have mechanisms simmilar to CSW for metadata to harvest the information from the registries maintained at the source. But this will take some time. Untill then we need to know which registries and values we need to use and those values must exist as http links.

    In any case, even if the biogeographical regions are falling under ”Code lists that are governed by an organisation outside of INSPIRE (externally governed code lists).” and EEA mentains them, at least this link ”” must point to the link where EEA expose either the codelist with all the values including those that are not anymore valid.

    The link must be something like Names like (with 2011) and then 2015 and so on are not ok at all.

    If known, please clarify which of the 4 EEA registries is the actual one to be used in INSPIRE. Personaly I think that none, but a combination between a) and c), namely codelist a) made in the form of codelist c) but that must exist at All previous, old values must be added as well and they must have ”invalid” as ”status”. The 2007, 2011, 2015 and all future versions can be kept as a snapshot in time of that registry, but it must exist a current registry that is including old invalid values and current valid values. That registry must always exist at a link that will not change anymore.

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear Iurie,

    unfortunately, it is not so easy to have all INSPIRE-relevant code lists managed in a single registry (the INSPIRE one), since (as Christian explained) they are usually not created for INSPIRE, but for some other community and purpose.

    Also, we cannot (easily) change the way code lists are being implemented in the legal acts - in some cases (mainly Annex I), code lists have been copied from externally governed code lists (e.g. IUCN), which is not a good idea, because things may be changed by the external organisation, and then we would be out of sync.

    The best we can do is mirror the externally governed values in the INSPIRE registry and provide the ids and titles to be used in the data encoding. As I wrote above, we are working on this, but it is not always straightforward.

    Again, in the meantime, please use the URIs you already proposed, with the local ids published by the EEA at So some example values would be:

    As titles, you can use either English titles or a title in the language used in the data set. If a client wants to support multi-lingual labels or legends, it can always retrieve the relevant translation (where available) from the registry.

    Best regards,

  • Iurie MAXIM

    Dear Michael,

    These are very good news indeed especialy if taking into account the 2017 deadline.

    In the we encoded the values as you recommended, taking the values and titles from here :

    <br:regionClassification xlink:href="" xlink:title="Alpine Bio-geographical Region"/>

    <br:regionClassification xlink:href="" xlink:title="Black Sea Bio-geographical Region"/>

    <br:regionClassification xlink:href="" xlink:title="Marine Region Black Sea"/>

    However, due to the fact that Geoserver is not compliant with TG Requirement 52 and to TG Recommandation 13 from  Technical Guidelines for Download Services when providing access to multiple harmonised datasets trough WFS 2.0 as described in this topic,  we are now switching to Snowflake GoPublisher WFS in order to provide services that are passing all validations curently implemented within the EC Geoportal Validator.

    Best regards,

    Iurie Maxim

  • Iurie MAXIM

    Dear Michael  and all,

    At page 51 of the D2.5 PDF (page 46 printed on header) is writen:

    << External code lists General rules

    Often, existing code lists exist that are well established and already used in a thematic community. The re-use of such code lists helps improve interoperability between INSPIRE and other (global and/or non-spatial) initiatives and systems and also eases the burden on data providers (who can use the existing code list values also when making data available under INSPIRE).

    EXAMPLE The four values of the AerodromeTypeValue code list in the Air Transport Network application schema was derived from AIXM 5.0.

    Recommendation 5 If for a specific property in an INSPIRE application schema, there is already an existing, well-established code list that is maintained by an international organisation, this code list should be referenced from the INSPIRE application schema.

    Ideally, an externally managed code list should meet the following requirements:

    1. It should be managed by a competent international organisation.

    2. It should be well maintained, i.e. all its values must remain available forever, even if they have been deprecated, retired or superseded.

    3. The code list and each of its values should be identifiable through a persistent URI6 in the „http‟ scheme.

    4. The code list should be available in HTML plus at least one of the following machine-readable representations:

    o GML dictionary

    o SKOS

    However, not all external code lists will meet these requirements. If an external code list is used in an INSPIRE application schema, but does not meet the requirements, the values will be made available through the common INSPIRE code list registry.

    NOTE This representation has to be maintained and updated if the reference in the INSPIRE application schema is updated to a new version of the external code list. A workflow for this should be defined as part of the terms of reference for maintenance and implementation. >>


    Therefore, can we asume than that all the codelists that are used to provide the values as xlink:href "will be made available trough common INSPIRE codelist registry" if the external codelists are not meeting requirements 1 - 4, or we should interpret that  these codelists are not "used in an INSPIRE application schema" ?

    Best regards,

    Iurie Maxim

  • Iurie MAXIM

    Maybe it should be taken into consideration what is writen in section G.7 from the Annex G (informative) of the same D2.5, at page 142

    <<G.7 Code lists and INSPIRE application schemas

    Code lists are referenced from spatial object properties in INSPIRE application schemas, but the code list itself is not specified nor managed as part of the application schema.

    For each such property, the code list to be used as well as their extensibility and obligation (IR or TG) needs to be specified. The code lists (including, for INSPIRE-governed code lists, their values) will be specified in the data specification and the INSPIRE registry.

    Code lists will be referenced from both the data specification documents and the application schema in the UML model.>>

    Are there any plans and deadlines to reference the codelists used to provide values as xlink:href in the application schema in the UML model and in the version 5 XSD schemas ?

    Having in mind that in the last sentence is stipulated that the "Code lists will be referenced from ... the application schema in the UML model", should we interpret having in mind the provions set in section that If an external code list does not meet the requirements, the values will be made available through the common INSPIRE code list registry ?

    On the other hand the text in bracket "(including, for INSPIRE-governed code lists, their values)" seems to explain why for the external codelists there are no values in the INSPIRE Registry. But should we interpret that the values must be there in the INSPIRE Registry if the external managed codelists are not meeting requirments 1-4 from section of the D2.5 ?


This discussion is closed.

This discussion is closed and is not accepting new comments.

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!