European Commission logo
INSPIRE Community Forum

Group activity

  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic Extent for ExistingLandUseDataset
    Dear Julian, I see what you mean, but that would need an update of all LU schemas, but the raster (gridded) LU schema, increasing the risk for inconsistencies for sure. Let's wait for input on this from others until the end... view reply
  • Julián DELGADO
    Julián DELGADO replied on the discussion topic Extent for ExistingLandUseDataset
    Dear Lena, thanks for your input From my side, the smarter solution could be to modify the data model changing the definition of ‘extent’ attribute to EX_extent, instead GM_MultiSurface. However this change would motivate the... view reply
  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic Extent for ExistingLandUseDataset
    Dear Julian, Thanks for bringing this issue to discussion. I skimmed through the INSPIRE data models to compare also with  the solutions of other vector application schemas. In addition to LC and LU I could only find an example in EF (a... view reply
  • Julián DELGADO
    Julián DELGADO replied on the discussion topic Discussion about amendmends for TG Land Cover and Land Use
    Dear Roland, I revised your proposals About AT-001, 002, 003, I agree, these changes would simplified the implementation of WFS and GMLs for Land Cover theme. About AT-004. As I understand, the reason to propose the change of multicity... view reply
  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic Atributes
    Hi Beatriz, Sorry for late reply. Usually data providers map their data to the relevant INSPIRE application schema and leave out attributes not required/supported. You can also extend the INSPIRE application schema to include all... view reply
  • Roland GRILLMAYER
    Roland GRILLMAYER added a new discussion topic Discussion about amendmends for TG Land Cover and Land Use
    Find attached a first proposal for for amendments to the TG for Land Cover and Land...
    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Dear Roland, Julian, all, 

      Many thanks for initiating this discussion.

      Regarding AT-001, 002, 003 I would have agreed with you a few months ago. However, at this point, I'd  actuallyprefer to be even more radical and suggest to drop the whole LandCoverDataset feature type as the same information can be derived from the LandcoverUnits or can be recommended to be put in the metadata. What do you think? Would that be too radical :)?

      Lena 

    • Katharina SCHLEIDT

      By Katharina SCHLEIDT

      Short note from back in the cheap seats - where would you provide the information on nomenclatureDocumentation?

      To my understanding, this is the only relevant bit of information added by the LandCoverDataset. At present, seems the only accepted codelist is Corine; however, if other nomenclatures are used, some information on the nomenclature should be provided somewhere (I'd recommend adding a reference to LandCoverNomenclature from LandCoverObservation, while making LandCoverNomenclature a featureType (otherwise cannot be referenced via OWS))

    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Kathi & all:

      Precisely, the nomenlatureDocumentation information is the most relevant, if not the only relevant. bit of information added by the LandCoverDataset and there is already a reference to the values of the nomenclatureCodelist from the LandCoverObservations in the LandCoverVector model. Assuming that the definitions of the code list values would be better in place that they are at the moment, I suppose this would meet most of the needs or do you disagree?

      You can extend this code list with any values. It's not only aimed for CLC: http://inspire.ec.europa.eu/codelist/LandCoverClassValue

      Examples of extensions by EEA and Eurostat can be found for example here if you search for 'land cover' or 'urban atlas': https://dd.eionet.europa.eu/vocabularies  .It would be great if these could somehow be linked to the INSPIRE Code list register, so that they could be more easily found for reuse.

      I actually had a thorough look at all the existing  LandCoverVector implementations on the INSPRIRE Geoportal and several of them haven't implemented the LandCoverDataset part at all, only the LandCoverUnit part. All of the examples I've looked into the nomenclareDocumentation is just pointing to an URL of a document (all actually not working..), which cannot be resolved by a machine anyway, I suppose. The alternative to provide nomenclatureDocumentation as an 'embeddedDescription' hasn't been used - and this option cannot be used without an update of the ISO LCML standard, which may take years. But also in this case perhaps its enough to have a separate XML with a link from the metadata.
       

      So in order to make implementation and use easier:

      1) the nomenclatureDocumentaion information could be put in the metadata (suggestion below) for easier implementation and maintenance, or

      2) go for the suggestion by Austria/Roland to "Change relationship between LandCoverDataset and LandCoverUnit from the specialized association type “aggregation” to a normal association link."

      etc.

      In option 1) one could put a link to the document describing the used nomenclature (PDF or XML) in the metadata for example here:

      /gmd:MD_Metadata/gmd:dataQualityInfo/gmd:DQ_DataQuality/gmd:report/gmd:DQ_DomainConsistency/gm d:result/gmd:specification

      What do you think?

      Lena

  • Julián DELGADO
    Julián DELGADO added a new discussion topic Extent for ExistingLandUseDataset
    Dear all Late days a previous commented topic have arose due to the last clarifications from the consultation issues IR-ISDSS process: ‘extent’ attribute on ExistingLandUsedataset and SampledExistingLandUsedataset. I remember...
    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Dear Julian,

      Thanks for bringing this issue to discussion.

      I skimmed through the INSPIRE data models to compare also with  the solutions of other vector application schemas. In addition to LC and LU I could only find an example in EF (a voidable attribute: boundingBox: GM_Boundary [0..1]). It was not a thorough analysis, but anyway it seems that the solution of LC and LU, having a separate dataset feature type, is rare, so there doesn't seem to be a Best practice example to re-use.

      I share your concern and think it would make sense to make the implementation smoother and the solutions of LU and LC to be more alike.

      1) One way to go forward would be to change the definition of the extent attribute and to rewrite the TG to  allow other ways to provide and create the extent (MultiSurface). If it isn't feasible to create an aggregation, then a bounding box or the approximate outline (country borders as polygons) could be used. I attended one TWG LU meeting in Helsinki in 2011, I think, where I suggested that to the TWG group and I still think this solution would in many cases be more feasible.

      2) If you go for a change in the data model (extent: GM_MultiSurface to extent:EX_Extent), one could add at least a TG recommendation on to use EX_BoudingPolygon (and if not possible then to use EX_GeographicBoundingBox, and not EX_GeographicDescription), or how would you go about? :https://geo-ide.noaa.gov/wiki/index.php?title=File:EX_Extent.png

      One could also argue that best practice is to provide the BoundedBy information, but that's another discussion :)

      In alternative 2, the already existing implementations (GMLs) would as I see it not be compatible, and therefore if I have to choose I'm in favour of nr 1). Or have I missed something? 

      What does the rest of you think?

      Lena

    • Julián DELGADO

      By Julián DELGADO

      Dear Lena, thanks for your input

      From my side, the smarter solution could be to modify the data model changing the definition of ‘extent’ attribute to EX_extent, instead GM_MultiSurface. However this change would motivate the generation of a new GML schema and could provoke inconsistences in existing implementations. At theoretically level seems feasible because EX_extent can be understood as complex aggregation of GM_MultiSurface, but in practical level many uncertainties appears.

      A possible solution can be extracted from Lena’s comment. Specifications could be modified textually with recommendation for appropriate use of ‘extent: GM_MultiSurface’ depending on the complexity of the dataset to be published. In case that the dataset allows the union/dissolve operations use the actual contour of the data including all border vertexes. In case that the dataset does not allow union/dissolve operations due to the higher number of vertexes, recommend to use at least and approximate geometry or a bounding box, but encoded like GM_MultiSurface to ensure current GML schemas.

      I do not know much examples of ExistingLandUseDataset implementations excepting ours. In our last modification of the INSPIRE LU WFS, we decided to make public the dataset ‘extent’ by and approximate geometry sufficient to involve inside the complete country. It is not a bounding box, and not correlates exactly vertex-by-vertex with the LU units, but solves the WFS implementation. You can see our geometry for Spain in the following link (save the WFS request as GML file and open with a GIS software) http://servicios.idee.es/wfs-inspire/ocupacion-suelo?SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAME=elu:ExistingLandUseDataSet

      Best

      Julián

    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Dear Julian,

      I see what you mean, but that would need an update of all LU schemas, but the raster (gridded) LU schema, increasing the risk for inconsistencies for sure.

      Let's wait for input on this from others until the end of the week and if others agree (don't disagree), then I will at some point investigate what kind of textual amendments this change would need in practice. And lets then see what the representatives of MIG says.

      In the end, the ETS won't be a test testing whether there is a union behind, but making these textual amendments would make the whole thing more clear and feasible.

      Thanks for sharing your example. Working examples are valuable.

      Lena

       

       

  • Beatriz Caro Gadea
    Beatriz Caro Gadea added a new discussion topic Atributes
    Hi all? Should I keep the original data (atributes) of my layer or should I upload only those that inspire requires? I´m a bit confuse about that and about lot of things really. Thank you in advance
    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Hi Beatriz,

      Sorry for late reply. Usually data providers map their data to the relevant INSPIRE application schema and leave out attributes not required/supported.

      You can also extend the INSPIRE application schema to include all information, but in this case you need to know how to do it (the extension methodology). 

      Let me know if you need some more help or examples.

      Kind regards,

      Lena

  • Lars Erik STORGAARD
    Lars Erik STORGAARD replied on the discussion topic Attributes in PLU - voidable but not nillable in GML application schema
    Thank you both, Peter and Enrico. Your explanation and the GML example was very useful to us. //Lars view reply
  • Enrico Iredi
    Enrico Iredi replied on the discussion topic Attributes in PLU - voidable but not nillable in GML application schema
    Hello Lars, here is an etf valid gml example. That should answer your question ... Enrico view reply
  • Enrico Iredi
    Enrico Iredi uploaded the file GML Example PlannedLandUse (PLU)
    gml file now ETF valid (status 9.4.2019) https://metaver.de/trefferanzeige?docuuid=D059011F-EDBD-4810-9307-BA8D227B5008&plugid=/ingrid-group:ige-iplug-HH&docid=D059011F-EDBD-4810-9307-BA8D227B5008
  • Peter PARSLOW
    Peter PARSLOW replied on the discussion topic Attributes in PLU - voidable but not nillable in GML application schema
    The backgroundMap attribute of the SpatialPlan feature type is nillable:(I'm not sure how you made your sample visible!) Same applies to the SupplementaryRegulation & ZoningElement. This should mean that a code fragment... view reply
  • Peter PARSLOW
    Peter PARSLOW uploaded the file INSPIRE LU xsd extract
  • Lars Erik STORGAARD
    Lars Erik STORGAARD replied on the discussion topic Attributes in PLU - voidable but not nillable in GML application schema
    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... view reply
  • Peter PARSLOW
    Peter PARSLOW replied on the discussion topic Attributes in PLU - voidable but not nillable in GML application schema
    Lars, 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... view reply
  • Lars Erik STORGAARD
    Hi all, My colleague is trying to set up a WFS service for PLU data in GoPublisher. He has imported the schema (http://inspire.ec.europa.eu/schemas/plu/4.0/PlannedLandUse.xsd) and the data is stored in our data warehouse. Our data can fit into...
    • 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:SpatialPlan>
      
          ....
      
          <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 ...

      Enrico

      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.

      //Lars

  • Bresters PIETER
    Bresters PIETER replied on the discussion topic Existing Landuse harmonization in Hale
    Dear Lena and all, I have uploaded our Hale project here. And I also uploaded an adjusted SLD that works with the output of our transformation. It looks like below:   view reply
  • Bresters PIETER
    Bresters PIETER uploaded the file SLD for existing Land Use
    This is a SLD-file for existing Land Use that works on the output GML from the transformation example of the Netherlands. It is based on the same styling as Lena provided, extended with a class for Water.
  • Bresters PIETER
    This is an example of harmonization of exiting Land Use in the Netherlands using Hale. There are 2 things that might be improved: 1) I needed a field for the HILUCS code, without the long URL from the codelist, to refer to from the SLD. So I...
  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic Missing namespace declaration in embedded description
    Hi everyone, To inform you all about the news regarding the ISO19144-2 Land Cover Meta Language standard. In May 2018 a Land Cover workshop was held at the ISO TC/211 meeting in Copenhagen. Global needs, INSPIRE needs (e.g. see this... view reply
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