European Commission logo
INSPIRE Community Forum

Group activity

  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic Open Land Use Map
    Dear Tomas, Is it so that this activity or project is no longer active? Would you like to make a summary of your results or new activities related to Land Use? If not, I'll close this discussion topic. Lena view reply
  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic Would you agree on this approach for using HILUCS and HSRCL?
    Dear Julian, Many thanks for your answer. I'm not sure if fully understood what you meant here. We can't change the fact that regoinal land use plans are digitised in a coarse scale and therefore some of the features are represented as... view reply
  • Lena Hallin-Pihlatie
    Lena Hallin-Pihlatie replied on the discussion topic HILUCS question related to protected areas
    Hi, I just realised I never got back to report on our decision. We decided to use include the protected areas both as zoning elements (http://inspire.ec.europa.eu/codelist/HILUCSValue/6_OtherUses) and supplementary regulation... view reply
  • Are you interested in solving exciting challenges with open data, in getting visibility for your work and in winning great prizes? 
  • Wideke BOERSMA
    Wideke BOERSMA added a new discussion topic Overlapping zoningelements
    Dear colleagues, We have the question if zoningelements in the application schema Planned Land Use of the dataspecification Land Use may overlap? In the Netherlands zoning elements can overlap. But in the dataspecification is stated: “A...
    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Dear Wideke,

      Sorry for the delay in answering.

      I had a look at the Planned Land Use data model, the ATS and the implementation rules (IR) and yes, I agree. I can just find a written description implying this requirement. My experience from regional land use plans in Finland is that zoning element polygons are not supposed to overlap within a plan, but they may do so because of digitalisation errors and due to the fact that some reservations (zoning elements) are digitised as polygons and other as points or lines. I understand it so, that the intention is that zoning elements shouldn't overlap. However, I'd like to interpret it in such a way that that it will not be a requirement of INSPIRE to fix a possible overlap of zoning elements. However, this is just my personal interpretation.

      In Finland most land use reservations (plan markings) that clearly overlap with the zoning elements,  can be considered as supplementary regulations, at least for regional land use plans. One challenge is that INSPIRE only allows zoning elements to be of type MultiGeometry (polygons), while in Finland they may also be points (eg. big complexes for shopping, major industries) or lines (eg. roads) due to scale, which means that we have to map them to supplementary regulation instead.

      Hth,

      Lena

       

  • Enrico Iredi
    Enrico Iredi replied on the discussion topic Dimensioning Indication
    Hello Andrej, here you can find an example with many 'plu:dimensioningIndication' values. https://themes.jrc.ec.europa.eu/file/view/229340/gml-example-plannedlanduse-plu All the best Enrico view reply
  • Andrej ABRAMIC
    Andrej ABRAMIC replied on the discussion topic Dimensioning Indication
    Hi Enrico,  just saw your post. Thank you for explanation, it fits. Would be nice if someone can point an example to see how is encoded, as complex data type.  Best,  Andrej   view reply
  • Enrico Iredi
    Enrico Iredi replied on the discussion topic Dimensioning Indication
    Hello Andrej, not an expert, but I think the dimensioningIndication attribute includes binding planning specifications. For example: Height dimensions for buildings, Maximum number of apartments in residential buildings, building types... xsd... view reply
  • Andrej ABRAMIC
    Andrej ABRAMIC added a new discussion topic Dimensioning Indication
    Dear all,  I am trying to understand Planned Land Use conceptual data model, and one of the attributes is very difficult to understand what is it for.  The Data specs. do not provide explanation or I did not find it. Attribute is...
    • Enrico Iredi

      Hello Andrej,

      not an expert, but I think the dimensioningIndication attribute includes binding planning specifications. For example: Height dimensions for buildings, Maximum number of apartments in residential buildings, building types...

      xsd description:

      ZoningElement - -- dimensioningIndication Definition -- Specifications about the dimensioning that are added to the dimensioning of the zoning elements that overlap the geometry of the supplementary regulation.

      SupplementaryRegulation – dimensioningIndication Definition -- Specifications about the dimensioning of the urban developments.”

      Best regards

      Enrico

    • Andrej ABRAMIC

      By Andrej ABRAMIC

      Hi Enrico, 

      just saw your post. Thank you for explanation, it fits. Would be nice if someone can point an example to see how is encoded, as complex data type. 

      Best, 

      Andrej  

    • Enrico Iredi

      Hello Andrej,

      here you can find an example with many 'plu:dimensioningIndication' values.

      https://themes.jrc.ec.europa.eu/file/view/229340/gml-example-plannedlanduse-plu

      All the best

      Enrico

  • 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...
    • 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

       

       

    • Lena Hallin-Pihlatie

      By Lena Hallin-Pihlatie

      Dear Julian, all,

      There is a need to find a solution related to the LU extent:GM_MultiSurface in order to be able to close this issue.

      I looked through all the implementations available with a national scope on the INSPIRE Geoportal a few weeks ago. I could find three harmonised examples. A change in data model would have an effect on these three implementations and possible other regional implementations out there, but I assume there aren't many around yet.

      If changing the data model isn't feasable, then there is a need to make a textual amendment to the the Technical Guidelines of Land Use.

      I'll make a proposal of an updated schema and get back to you for comments.

      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
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