European Commission logo
INSPIRE Community Forum

Attributes in PLU - voidable but not nillable in GML application schema


Hi all,

My colleague is trying to set up a WFS service for PLU data in GoPublisher. He has imported the schema ( and the data is stored in our data warehouse.

Our data can fit into the schema except a few attributes which in the UML diagram for PLU:SpatialPlan is marked as voidable, for instance backgroundMap. The schema specifies backgroundMap as a datatype containing the attributes backgroundMapDate (DateTime), backgroundMapReference (CharacterString) and backgroundMapURI (URI).

The problem is that we do not have data for these attributes in our national data set. And that should not be a problem because the attribute "backgroundMap" is voidable. We should then provide a reason for why we cannot provide data and that is fine - we will write "unpopulated" in the INSPIRE GML data. 

But the problem is that the schema does not allow such values! For instance, the schema validation fails when we write "unpopulated" in backgroundMapDate where only a date is allowed. So how can we provide a voidable-reason for attributes that is not nillable in the schema? Is that not a mistake in the schema? 

All the best,



  • Peter PARSLOW


    SpatialPlan.backgroundMap is correctly "nillable" in the schema. But "unpopulated" is not a valid "nilReason". I'm sure I've seen a discussion about which of the allowable nilReason values should be used where, but it's not in D2.7.

    Anyway, the allowable values are from GML: inapplicable, missing, template, unknown, withheld (and "other:" + your own text; or even any URI!). I suspect you need to choose between "missing", which GML defines as "the correct value is not readily available to the sender of this data. Furthermore, a correct value may not exist", and "unknown": "the correct value is not known to, and not computable by, the sender of this data. However, a correct value probably exists".

    Looking into this, I note that the UML model of BackgroundMapValue still contains a typo, which is therefore reflected in backgroudMapURI (without the 'n'). This was acknowledged by JRC in August 2018 ( - but not yet fixed: partly because it's spelt wrong in the regulation!

  • Lars Erik STORGAARD

    By Lars Erik STORGAARD

    Thanks for reply, Peter.

    Yes, I also noticed the typo in "backgroudMapURI". According to your answer that backgroundMap is correctly nillable - I am not an expert in to reading xsd, but I simply cannot see that in the schema. For me the "backgroudMapURI" has nillable = "true" but the two other attributes "backgroundMapReference" and "backgroundMapDate" has no nillable = "true" and is that not express of that a valid value has to be provided? See screen dump below.

    You are correct in regard of allowed values for nilReason - we use to write other:Unpopulated and this will also be the case for these data - sorry for my misinformation in my first post.



  • Peter PARSLOW

    The backgroundMap attribute of the SpatialPlan feature type is nillable:INSPIRE LU xsd extract(I'm not sure how you made your sample visible!)

    Same applies to the SupplementaryRegulation & ZoningElement.

    This should mean that a code fragment like:

        <plu:BackgroundMap gml:nilReason="missing"/>

    is valid. Or is it that you want to populate the other two attributes, and just don't have a URI?

  • Enrico Iredi

    Hello Lars,

    here is an etf valid gml example. That should answer your question ...


    GML Example PlannedLandUse (PLU)

  • Lars Erik STORGAARD

    By Lars Erik STORGAARD

    Thank you both, Peter and Enrico. Your explanation and the GML example was very useful to us.


This discussion is closed.

This discussion is closed and is not accepting new comments.

Land Cover & Use

Land Cover & Use

Join this group to share your knowledge, learn and collaborate in solving issues related to the Land Cover and Land Use themes