European Commission logo
INSPIRE Community Forum

INSPIRE ID optional?

Dear colleagues,

I hope I am not hitting an old discussion.

I just discovered when comparing some data spec details that in some data specs in the biodiv area (in particular SD, HB or BR) the INSPIRE Identifier is not mandatory but optional! I was just wondering if there is a special reason for these exceptions because the spatial object identifier should imho always be mandatory for the spatial object. 

Thanks for clarification!


  • Michael LUTZ

    Dear Christian,

    requirements and recommendations on identifiers are discussed in section 14.1 of the Generic Conceptual Model. The general line is that all spatial objects that may be referenced by other spatial objects should have identifiers. The requirements are stronger for Annex I and II than for Annex III themes. 


  • Lars Erik STORGAARD

    By Lars Erik STORGAARD

    Dear Chris, all.

    I think it is a good question and I will bring this input into the further discussion here.

    The Directive article 8 says:

    "In the case of spatial data sets corresponding to one or more of the themes listed in Annex I or II, the implementing rules provided for in Article 7(1) shall meet the conditions laid down in paragraphs 2, 3 and 4 of this Article.

    Paragraph 2: The implementing rules shall address the following aspects of spatial data:

    (a) a common framework for the unique identification of spatial objects, to which identifiers under national systems can be mapped in order to ensure interoperability between them;"

    So I will say that the three annex 3 themes (SD, HB and BR) and their application schemes has been developed correct according to article 8 when it comes to defining the INSPIREID as optional. Article 8 only requires the INSPIREID as mandatory for the annex 1 and 2 themes. 

    BR Lars

  • Giacomo MARTIRANO

    By Giacomo MARTIRANO

    Dear all,

    I think that we all should take benefit from discussions like this to emphasize once more the need to evangelize INSPIRE implementers to pursue data usability beyond formal conformance!

    So, let's go beyond the formal possibility of article "y" to skip the INSPIRE ID for Annex "x" data themes and let's all make an effort to provide it smiley

    Kind regards


  • Iurie MAXIM

    Dear all,

    Even if INSPIRE ID is optional the GML ID is not optional at all and the Technical Guidelines are not mentioning nothing about it (or at lesat I did not observed this). Actualy GML ID can be used instead of INSPIRE ID (withouth a proper use of version).

    For GML 3.2 the schema is mentioning:

    ”The attribute gml:id supports provision of a handle for the XML element representing a GML Object. Its use is mandatory for all GML objects. It is of XML type ID, so is constrained to be unique in the XML document within which it occurs.”

    The gml:id is very usefull especilay in order to retrieve the GML based on the GetFeatureById request. The GetFeatureById link request is very usefull as well especilay for referencing spatial objects between them.

    So, one question is if INSPIRE ID is realy necessary, as the gml:id has exactly the role for which the INSPIRE ID was designed.

    What we are doing actualy is the following:

    We are using the INSPIRE ID localId for the gml:id and we are using the GetFeatureBy Id request for both INSPIRE ID namespace and for the gml:identifier as you may see below:

    <ps:ProtectedSite gml:id="RONPA0123">
    <gml:MultiSurface srsName="urn:ogc:def:crs:EPSG::3035" gml:id="Geom.RO.ENV.PS.RONPA0123-2016-2-11">

    In this way the GetaFeatureById request can be used for referencing spatial objects,

    We are using the gml:id of the geometry in order to indicate the latest modification of the geometry (2016-2-11). As we modified some attributes the versionId of the INSPIE ID is different 2016-02-29.

    We are now analysing if for the gml:identifier codeSpace to put "; or, but this is a longer discustion about what a dataset can be in order to be exposed trough WFS 2.0 services. We have already some serious doubts that a dataset can actualy refer more data themes or  more XSD schemas (even from the same data theme) and not break some TG requirements.

    As well we are now working to shorthen theURLs, namely to shorten into;in order to get the feature at this address

    Best regards,

    Iurie Maxim

  • Michael LUTZ

    Dear all,

    the usage of the gml:id and its relation to the external object identifier (inspireId) is discussed in Annex C of the D2.7 Encoding Guidelines.

    C.3 Encoding of an external object identifier

    Recommendation 15 URIs of spatial objects should be persistent http URIs and include the namespace and the local identifier part of the INSPIRE identifier, if available.

    EXAMPLE 1 could be used to encode the external object identifier of an INSPIRE Address spatial object with the namespace ―00BH‖ and the local id ―123456789012‖ (example adapted from [Designing URI Sets for Location, 2011]).

    Recommendation 16 In a GML encoding, the external object identifier should be encoded in a gml:identifier property of the feature with the codeSpace attribute set to

    NOTE At, a web page is available that contains answers to frequently asked questions (FAQ) around the implementation of identifiers using URIs in INSPIRE. In the future, this page may be extended into a register of the URI schemes of the EU Member States and the European Commission.

    <gml:identifier codeSpace=""&gt;

    The information from the external object identifier may also be used for an XML ID attribute (gml:id in the GML encoding).

    While the XML 1.0 standard allows colons in XML ID, this is prohibited in the Namespaces in XML 1.0 standard. Since XML namespaces are used in INSPIRE XML documents, a different separator between the identifier parts has to be used.

    In addition, since XML ID values only have to be unique within a document, or in the case of an OGC Web Feature Service within the opaque data store of the service, the identifier namespace may be omitted if only spatial objects from a single identifier namespaces are provided by a download service.

    EXAMPLE 3 In this example, the identifier namespace from the identifier [namespace=‖00BH‖, local id=‖123456789012‖, version=‖2008-09-12T12:34:56Z‖] is dropped and since the naming system uses a fixed length for the local identifier the version is appended without separator:
    <ad:Address gml:id=‖12345678901220080912T123456Z‖>

    XML ID does not allow digits, points and dashes as start characters. In naming systems where this may occur this may be circumvented, for example, by adding a leading underscore character.

    NOTE 2 This will not occur in cases where the identifier namespace is included as it will always start with a letter or an underscore.

    EXAMPLE 4 With namespace (if the Web Feature Service hosts spatial objects from multiple namespaces) and a separator ―__‖ the spatial object from example 3 would be encoded as
    <ad:Address gml:id=‖00BH__123456789012__20080912T123456Z‖>

    C.4 Encoding of a reference to a spatial object

    Recommendation 17 To reference a spatial object or a specific version of a spatial object its persistent URI based on its INSPIRE identifier (see Recommendation 15) should be used. For spatial objects without an INSPIRE identifier a URI based on the gml:id of the GML representation of the spatial object should be used.

    EXAMPLE A reference to a cadastral parcel object with the identifier used in example 3 in C.3 could be encoded as (using a hypothetical URI scheme)
    <parcel xlink:href=""/&gt;

    This assumes that the reference is to the spatial object and not a specific version of the spatial object. In case of a reference to the specific version, the reference would be encoded as
    <parcel xlink:href=""/&gt;

    HTH, Michael

  • Christian ANSORGE

    By Christian ANSORGE


    Thanks for the answers.

    I am aware of Art. 8  of the Directive which explains the background to a degree. I am now wondering if there is a reason behind the decision to have the INSPIRE ID optional in certain Annex III themes, while it is still mandatory in all others. In terms of data management I would see it necessarily as mandatory (of course) across all annex themes. To have the INSPIRE ID consistently mandatory across all Annex III themes as well would simplify usage.

    I don't think that the GML ID is fully replacing the local identifier in the INSPIRE ID, at least they do not equal on conceptual level (universal unique vs. unique within a namespace). I see your point when using gml:identifier, but to my knowledge this element is just optional. But I agree that the whole topic around the INSPIRE Identifier deserves a further discussion and clarification.


  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi all,

    first off, think this discussion, as well as similar threads such as the one on inspire compliant WFS solutions ( show that in addition to the various thematic clusters, we'd need a cross-theme technical cluster, ideally closely linked with MIG-T

    While initially starting with the question of when the INSPIRE ID is mandatory, its now nicely widened into a wider discussion of the overall identifier dilemma in INSPIRE. Thus, while nicely pulling together many answers, its also brought up at least as many questions. Let me try to summarize:

    At present, we have 3 parallel identifier schemes in INSPIRE:

    • Inspire Id (triple)
    • gml:id (single string)
    • gml:identifier (single string)

    We have 2 related options for accessing objects with this ID:

    • direct WFS request
    • xlink resolution

    What seems to be missing (at least I can't find it!):

    • relationship between the 3 ids: while there are various recommendations in D2.7 , there seems to be no common agreement on what identifier parts are mirrored between which of these identifiers (clear guidance would be valuable here!)
    • WFS access via identifier: via featureId we can access inspire features via the gml:id (but there's only informal agreement that this contains the same value as the localId); I haven't yet found an agreed set of stored queries to cover standardized access via the INSPIRE Id or the gml:identifier
    • xlink resolution: this is where it really gets lost :( Its fairly clear (both from the D2.7 recommendations as well as the underlying W3C xlink standard) that the xlink should provide a persistent resolvable URI allowing access to the referenced resource. However, the only mechanism we have for resource resolution is the WFS. If we provide the entire WFS URI (with request encoding) within the xlink, while it is resolvable, I seriously doubt how long it will be persistent (when do we move to wfs2.1?). Providing "clean" URIs for xlinks as described in D2.7 is possible, but you need you web server configured for rewriting the "clean" URIs to the current WFS request for that feature

    I've been following this problem for years, and while its technically solvable, I believe without clear guidance how to solve it, we will:

    • cause many people in many MS to spend a great deal of time trying to understand this
    • trigger the creation of various conflicting and non-interoperable solutions

    The real answers are between the lines of the various documents; while one can eventually find them, at least I wasn't capable of convincing our national ministry to act on these non-explicit requirements; as to identifiers, while there seems to be tacit agreement to align the gml:id with the INSPIRE Id where possible, the gml:identifiers is still mostly off the radar.

    What can we do to enable the various MS to implement this in a sensible manner without breaking their brains?



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!