European Commission logo
INSPIRE Community Forum

The Association role ’Member’ in Land Cover and Land Use

Hi,

The Association role: ’Member’ exist in both Land Cover and Land Use data models/application schemas. The Member association role has however been modelled differently in Land Cover (weak aggregation) and in Land Use (<->), resulting in differences in the class diagrams (see the example figures in the attached document) and in the xml schemas (xsd).

Association role Member in LC and LU

With this discussion topic, I'd like to collect opinions on and possible experiences related to this from the LCLU community. Do you think there's a need for harmonisation between these neighbouring themes? If yes or no, please specify why and what kind of change you would propose, if any?

With best regards,

Lena

 

  • Julián DELGADO

    By Julián DELGADO

    Dear Lena,

    After some transformation experiencies working with LC & LU, I could say that the approach followed by LU theme is easy and useful for users.

    The aspects in the UML is quite the same, but then reproduced in a real datasets, the LC approach means to create a big GML <FeatureMember> for a LCDataset, filled with many LCUnits instances inside. I put below a real example of transformation of Spanish CORINE Land Cover in a WFS. The LCDataset request offers a very big GML, even the LCUnits instances have been simplified.

    http://www.ign.es/wfs-inspire/ocupacion-suelo?service=WFS&request=GetFeature&version=2.0.0&typename=lcv:LandCoverDataset&count=1

    Otherwise, LU enables to provide, in the same WFS request or GML, LU datasets and LU polygons independiently.

    Other benefit is the use of GML files in a GIS software. LU approach can be displayed without complications, but current LC approach cannot be easily recognized by GIS software.

    My best regards

  • Hrvoje Matijević

    By Hrvoje Matijević

    Hi all,

    I can agree with Julian that the aggregation approach is a bit clumbsy, since when one requests a single LandCoverDataset he or she always (or at least in case it's a CORINE dataset) ends up with a huge response. Decreasig the size of a LandCoverDataset by encoding xlinks only for the dataset members, renders it, in my opinion, unusable since the xlinks can hardly be resolved using the available technology.

    However, even more importantly, in case a LandCoverUnit WFS serves data from multiple CORINE year datasets (as is the case I'm currently working on), the request can not be filtered according to the units' dataset membership as there is no dataset info within the units. Thinking on the conceptual level, the units really are aggregated by the dataset, so changing the aggregation association to a simple bidirectional one could mean departing from the correct concept. I would think that only some kind of an info on the dataset membership on the unit's side (perhps an xlink to its parent dataset) could do the trick. On the other hand, perhaps it's just my odd case of a WFS serving units from mutiple CORINE yer datasets, I really don't know.

    Best regards

  • Lena Hallin-Pihlatie

    By Lena Hallin-Pihlatie

    Hi,

    I agree that conceptually both LC and LU data model seem correct.

    I have little experience with using WFS services myself. What would be the use case if you would ask for a dataset? In which cases would it not be sufficient only to instead make a request for units in a particular area?

    You write that "..some kind of an info on the dataset membership on the unit's side (perhps an xlink to its parent dataset) could do the trick...". This sounds interesting, but can you forsee what would it require in practise? A change in the xsd, a change in definition, etc?

    Kind regards,

    Lena

     

     

  • Hrvoje Matijević

    By Hrvoje Matijević

    Following the requirement that each dataset must be served using a separate service, and if each reference year of CLC is a separate dataset, this issue becomes irelevant. Even if there was no "one service per dataset" requirement, in case other OGC servers can serve multiple datasets of the same complex object type, again this is irelevant. Since the requirement exists, the only problem is the Geoserver not being capable to serve multiple datasets of the same complex object type via WFS (at least to the best of my knowledge). Now, if the solution for this is to be found, the conceptual data model and the XSD would need to be changed in order to support the filtering.

    Regards,
    Hrvoje

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