Simplification Encoding Rule

This rule issue is to be referenced from the best practice paper.

Name of the Rule

Restrict a property to be by reference only.

Category

• Reduce nested structures (inline referencing causes nested structures with many levels)
• Reduce implementation effort of and duplication of data by data providers, if the value of the property is a resource managed by another data provider.

Description

Information regarding resources can be stored in an external register or non-INSPIRE online application, not necessary using GML, possibly other standardised encodings. That information be referred to from a GML application schema "by reference".

It gives a lot of work for data providers when they have to document a lot of metadata regarding e.g. laws, documents, authorities, etc. that they are not responsible for, and when this information is already online somewhere else this is redundant work. Therefore, properties referring to laws, documents, authorities and other online resources not typically belonging to the geographic information domain should be implemented by reference, and it should be recognised that their values are not necessarily encoded in GML.

UML Model

N/A

Example instance in default encoding:

All of the following are possible:

<am:ManagementRestrictionOrRegulationZone>
  <!-- ... -->
  <am:legalBasis
    xlink:href="http://www.retsinformation.dk/eli/lta/2017/122"
    xlink:title="Bekendtgørelse af lov om skove"
  >
    <base2:LegislationCitation>
      <base2:name>Bekendtgørelse af lov om skove</base2:name>
      <base2:shortName>LBK nr 122 af 26/01/2017</base2:shortName>
      <base2:date>
        <gmd:CI_Date>
          <gmd:date>
            <gco:Date>2017-01-26</gco:Date>
          </gmd:date>
          <gmd:dateType>
            <gmd:CI_DateTypeCode
              codeListValue="creation"
              codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" />
          </gmd:dateType>
        </gmd:CI_Date>
      </base2:date>
      <base2:link>http://www.retsinformation.dk/eli/lta/2017/122</base2:link>
      <base2:level xlink:href="http://inspire.ec.europa.eu/codelist/LegislationLevelValue/national" xlink:title="national" />
    </base2:LegislationCitation>
  </am:legalBasis>
  <!-- ... -->
</am:ManagementRestrictionOrRegulationZone>

<am:ManagementRestrictionOrRegulationZone>
  <!-- ... -->
  <am:legalBasis>
    <base2:LegislationCitation>
      <base2:name>Bekendtgørelse af lov om skove</base2:name>
      <base2:shortName>LBK nr 122 af 26/01/2017</base2:shortName>
      <base2:date>
        <gmd:CI_Date>
          <gmd:date>
            <gco:Date>2017-01-26</gco:Date>
          </gmd:date>
          <gmd:dateType>
            <gmd:CI_DateTypeCode
              codeListValue="creation"
              codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" />
          </gmd:dateType>
        </gmd:CI_Date>
      </base2:date>
      <base2:link>http://www.retsinformation.dk/eli/lta/2017/122</base2:link>
      <base2:level xlink:href="http://inspire.ec.europa.eu/codelist/LegislationLevelValue/national" xlink:title="national" />
    </base2:LegislationCitation>
  </am:legalBasis>
  <!-- ... -->
</am:ManagementRestrictionOrRegulationZone>

<am:ManagementRestrictionOrRegulationZone>
  <!-- ... -->
  <am:legalBasis
    xlink:href="http://www.retsinformation.dk/eli/lta/2017/122"
    xlink:title="Bekendtgørelse af lov om skove"
  />
  <!-- ... -->
</am:ManagementRestrictionOrRegulationZone>

Example instance in simplified encoding:

Only the following is possible:

<am:ManagementRestrictionOrRegulationZone>
  <!-- ... -->
  <am:legalBasis
    xlink:href="http://www.retsinformation.dk/eli/lta/2017/122"
    xlink:title="Bekendtgørelse af lov om skove"
  />
  <!-- ... -->
</am:ManagementRestrictionOrRegulationZone>

Model transformation rule:

Tagged value inlineOrByReference should be added/updated to have value "byReference" on the property.

Instance transformation rule:

It is only possible to convert an instance using the "inline" pattern when the URL is present somewhere in the data, which then must be inserted in @xlink:href. A name or title, if present, may be inserted in @xlink:title.

Solves usability issues:

TODO

Known usability issues:

Display of @xlink:href and @xlink:title may not be supported in all clients. However, this is the same problem as for code lists, which are widely used in INSPIRE.

Reversibility:

Fully reversible.

Simplified encoding example

Short description

The ShapeChange tool processes application schemas according to ISO 19109 and generates resources derived from the conceptual schema. Creating an implementation schema of an application schema in general will involve some transformation of the application schema in order to meet the needs of a use case or implementation constraints. Some of these transformations can be classified as "simplifications".

Example instance

These are not instance examples, but related links:

• See chapter 3 of the input from Denmark in the 2016.1 fitness-for-purpose process
• PODS Lite, this document provides an overview

Purpose & use

The ShapeChange tool processes application schemas according to ISO 19109 and generates resources derived from the conceptual schema. The typical output is an implementation schema (e.g. XML, SQL DDL, ArcGIS workspaces, JSON Schema) but other outputs like documentation and other more specific outputs are supported, too.

Creating an implementation schema of an application schema in general will involve some transformation of the application schema. ShapeChange provides a tool set with a range of configurable transformations to transform the conceptual schema before generating the target outputs.

Used simplification rules

Some of the transformations can be classified as "simplifications". For example, the Flattener supports the flattening of data structures (data types, multiple values, inheritance, etc.) with rich options to control the flattening rules that are applied.

Profiling is another important aspect that is usually used to reduce the information in an application schema to the scope of the source data or the target use case.

Simplified encoding example

Short description

In order to support the activities of MIWP2016.1 the GDI-DE Coordination office on behalf of the German National Point of Contact for INSPIRE launched a call for recommendations for changes to INSPIRE aiming at improving the implementation and use of INSPIRE Annex III data.
The study aimed at identifying exemplary issues and structural problems from Annex III Implementation Rules and Technical Guidance and to indicate possible measures for streamlining and simplification of INSPIRE implementation.

Example instance

https://ies-svn.jrc.ec.europa.eu/attachments/download/2136/%5BDOC9%5D_170510_FitnessForPurpose_RecommendationsForChange_final.pdf

Purpose & use

Recommendations were given e.g. for Flattening of complex structures and Simplify attributes in an exemplary way.

Used simplification rules

Additional information

Alternative encoding example

Short description

Large scale topography touching several INSPIRE features. The WFS includes JSON. A UML of the source model is included. It allows for analyzing simplification rules

Example instance

https://geodata.nationaalgeoregister.nl/beta/bgt/wfs?request=getcapabilities&service=wfs

Sources

Please describe/list the sources of data used in this example.

Underlying (INSPIRE) conceptual model

If the encoding is implementing a conceptual model (e.g. from INSPIRE), please provide
details and/or a reference to the conceptual model (e.g. the relevant INSPIRE application
schema) here.

Purpose & use

publication of base data of topography

Used simplification rules

• Does the encoding example have special rules (e.g. for codelists, voidable elements,
  specific (complex) types, complex structures in general, etc.)?:
  This has to be analyzed and is related to the source UML.

Additional information

This is an optional section for additional information, e.g.

• Are there known limitations or issues with the encoding?
• What enhancements would you like to do to the example?
• What do you consider to be the best aspects/characteristics of this example?
• What clients or other software was this encoding tested with? What were the results?

Simplified encoding example

Short description

OS MasterMap Highways Network - this specification extends the INSPIRE Transport Network - Roads model, with quite a lot of additional attribution to meet customer requirements - represented by UK's Department for Transport and two major maintenance supervision authorities (Highways England, and Transport for Scotland).

Also includes Ferry Link, as specialisations of INSPIRE Water Transport Network WaterwayLink.

We achieved this be creating Enterprise Architect UML models which import/extend the INSPIRE models, and then using ShapeChange to create the XSDs. We have inhouse documentation on achieving this.

The specification is at https://os.uk/docs/technical-specifications/os-mastermap-highways-network-roads-technical-specification.pdf, with a supplementary section for routing & asset management at https://www.ordnancesurvey.co.uk/docs/technical-specifications/os-mastermap-highways-network-routing-and-asset-management-technical-specification.pdf

The XML schema files are at: https://os.uk/xml/schema/highwaysnetwork/index.html

Additional support artefacts (videos, getting started guide, FME workbenches) at: https://os.uk/business-and-government/help-and-support/products/os-mastermap-highways-network.html

Example instance

Sample 'road' data: https://os.uk/docs/sample-data/os-mastermap-highways-network-roads.zip#sample-data-download
Sample 'routing and maintenance' data: https://os.uk/docs/sample-data/os-mastermap-highways-network-roads-routing.zip#sample-data-download

Purpose & use

The key use cases were 'high level routing' of traffic across the network, and maintenance of the assets (i.e. the road surfaces)

Used simplification rules

There are two simplifications, in the sense of 'making the data easier to use':

• putting 0 to 4 road names on links & nodes, in addition to having them on the Road link set
• extending SimplePointReference with an absolute position, in addition to the offset

Additional information

See forum discussions at https://www.ordnancesurvey.co.uk/forums/discussion/1010653/in-routing-and-asset-management-what-is-the-relationship-linking-asset-management-tables-to-street - implies issues with some software not noticing some attributes

we do not have the attribute information such as widths in rural areas due to the accuracy to which the data is mapped in those areas.

Should we focus on generic rules (for all/most INSPIRE themes) or specific ones (for one or a small number of themes)?

If the latter, which themes/use cases should be used to prototype and test the simplification rules / GeoJSON encoding rule?

Simplification Model Transformation Rule

This rule issue is to be referenced from the best practive paper.

Use the sections below to specify the Model Transformation rule.

Name of the Rule

Attribute - complex structure to simple structure

Category

Add the category into one of the following categoies:

• Flatten nested structures

Description

Complex structered attributes are transformed to separate attributes.
The separate attributes are recognized as a group by a created stereotype named after the original complex attribute.
In addition, these attributes get a common prefix, indicating that they form a group.
This makes the attributes also recognisable as a group at the implemenation level.

UML Model

transformed to:

Example instance in default encoding:

Provide an example in the default encoding.

Example instance in simplified encoding:

Provide an example feature that is based on the transformed model.

Model transformation rule:

Describe the actual model transformation rule, either in free text or in an algorithmic form.

Instance transformation rule:

Describe how data in a property needs to be transformed, if necessary. As an example, there are rules which concatenate values (e.g. in the GeoSciML Lite approach).

Solves usability issues:

Describe as concrete as possible, ideally using the test classes described in CanIUse, which issues in which software this approach addresses and solves.

Known usability issues:

Describe whether this transformation leaves problems unsolved, or introduces new issues.

Reversibility:

entirely reversible.

Simplification Model Transformation Rule

This rule issue is to be referenced from the best practive paper.

Use the sections below to specify the Model Transformation rule.

Name of the Rule

Give the rule a summary name.

Category

Add the category into one of the following categoies:

• Alternate Structures for specific types or type hierarchies (can be applied to specific types)
• General model simplification rules (can be applied everywhere)
• Flatten nested structures
• Flatten attributes (e.g. uom)
• Flatten lists/arrays
• Profiling (reduction of degrees of freedom, e.g. usage of property types in choices)

Description

Restrict multiple attributes to one and use ; separation for multiple values

Limit the number of permitted cardinality of the attributes to one. For attributes with cardinality higher than 1 create a valuetype that allows for an array of separated values. (for example ";")

The advantage of this is that you can record unlimited values. The disadvantage is that there is no
enumeration or other data type other than a (alphanumeric) string. Extra effort is also needed to (machine) read individual values.

UML Model

If this rule falls into the "Alternate Structures for specific types" category, provide a UML class diagram of your alternative model. For other rules, you may optionally provide a UML diagram.

Example instance in default encoding:

Provide an example in the default encoding.

Example instance in simplified encoding:

Provide an example feature that is based on the transformed model.

Model transformation rule:

Limit the number of permitted cardinality of the attributes to one. For attributes with cardinality higher than 1 create a valuetype that allows for an array of separated values. (for example ";")

Instance transformation rule:

Describe how data in a property needs to be transformed, if necessary. As an example, there are rules which concatenate values (e.g. in the GeoSciML Lite approach).

Solves usability issues:

Describe as concrete as possible, ideally using the test classes described in CanIUse, which issues in which software this approach addresses and solves.

Known usability issues:

The disadvantage is that there is no
enumeration or other data type other than a (alphanumeric) string. Extra effort is also needed to (machine) read individual values.

Reversibility:

not entirely reversible because the original valuetype is not visable anymore and there for can not be validated.

Simplified encoding example

Short description

Simplified schemas that takes the form of flat table of attributes (conformant to OGC Simple Features Level-0 profile); previously called EarthResourceML-Portrayal.

ERML-Lite is an abridged version of the full EarthResourceML model and can be used to deliver simplified views on mineral occurrences and their commodities, mines, mining activities and mine waste products.

There are six EarthResourceML-Lite views descibed in the 2.0.1 standard, these are: MineView, CommodityResourceView, MineralOccurrenceView, MiningActivityView, MiningWasteView, and ProcessingPlantView

For full details of the ERML-Lite schema see: http://schemas.earthresourceml.org/earthresourceml-lite/2.0/erml-lite.xsd

For documention see: http://www.earthresourceml.org/earthresourceml-lite/2.0.1/documentation/

Example instance

See the following URLs for example of service providing ERML-Lite output

http://13.95.69.121/geoserver/erl/ows?service=WMS&request=GetCapabilities&

http://13.95.69.121/geoserver/erl/ows?service=WFS&request=GetCapabilities&

erl:CommodityResourceView

<?xml version="1.0" encoding="UTF-8"?>
<erl:CommodityResourceView xmlns:erl="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml"
    xsi:schemaLocation="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0 
    http://schemas.earthresourceml.org/earthresourceml-lite/1.0/erml-lite.xsd"
    gml:id="ga.commodityResourceView.123456">
    <erl:identifier>http://data.geoscience.gov.au/feature/ga/commodityResourceView/ga.commodityResourceView.123456</erl:identifier>
    <erl:commodity>gold</erl:commodity>
    <erl:commodityRank>primary commodity</erl:commodityRank>
    <erl:commodityImportance>very large</erl:commodityImportance>
    <erl:mineralOccurrenceName>Lassiter's Reef</erl:mineralOccurrenceName>
    <erl:mineName>Lassiters</erl:mineName>
    <erl:totalEndowment>1300 Mt @ 2.7 g/t Au</erl:totalEndowment>
    <erl:totalReserves>800 Mt @ 2.9 g/t Au</erl:totalReserves>
    <erl:reservesCategory>proved ore reserves</erl:reservesCategory>
    <erl:totalResources>500 Mt @ 2.6 g/t Au</erl:totalResources>
    <erl:resourcesCategory>inferred mineral resource</erl:resourcesCategory>
    <erl:classificationMethodUsed>JORC code</erl:classificationMethodUsed>
    <erl:observationMethod>surveyed</erl:observationMethod>
    <erl:positionalAccuracy>0.5 metre</erl:positionalAccuracy>
    <erl:source>BHP Billiton Pty Ltd annual report, 2010</erl:source>
    <erl:commodityClassifier_uri>http://resource.geosciml.org/classifier/cgi/commodity-code/gold</erl:commodityClassifier_uri>
    <erl:mineralOccurrence_uri>http://data.geoscience.gov.au/feature/ga/mineralOccurrenceView/ga.mineralOccurrenceView.123456</erl:mineralOccurrence_uri>
    <erl:mine_uri>http://ga.gov.au/feature/mine/ga.mine.123456</erl:mine_uri>
    <erl:reservesCategory_uri>http://resource.geosciml.org/classifier/cgi/reserve-assessment-category/proved-ore-reserves</erl:reservesCategory_uri>
    <erl:resourcesCategory_uri>http://resource.geosciml.org/classifier/cgi/resource-assessment-category/inferred-mineral-resource</erl:resourcesCategory_uri>
    <erl:classificationMethodUsed_uri>http://resource.geosciml.org/classifier/cgi/classification-method-used/jorc-code</erl:classificationMethodUsed_uri>
    <erl:specification_uri>http://ga.gov.au/feature/commodityResource/ga.commodityResource.123456</erl:specification_uri>
    <erl:shape>
        <gml:Point srsName="epsg:4283" srsDimension="2"
            gml:id="GA.commodityResourceView.123456.point">
            <gml:pos>138.234 -26.747467</gml:pos>
        </gml:Point>
    </erl:shape>
</erl:CommodityResourceView>

erl:MineView

<?xml version="1.0" encoding="UTF-8"?>
<erl:MineView xmlns:erl="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml"
    xsi:schemaLocation="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0 
    http://schemas.earthresourceml.org/earthresourceml-lite/1.0/erml-lite.xsd" gml:id="ga.mineView.123456">
    <erl:identifier>http://data.geoscience.gov.au/feature/ga/mineView/ga.mineView.123456</erl:identifier>
    <erl:name>Lassiters</erl:name>
    <erl:status>operating</erl:status>
    <erl:owner>BHP Billiton</erl:owner>
    <erl:startDate>1978-01-01</erl:startDate>
    <erl:endDate>2009-01-01</erl:endDate>
    <erl:observationMethod>surveyed</erl:observationMethod>
    <erl:positionalAccuracy>0.5 metres</erl:positionalAccuracy>
    <erl:source>BHP Billiton Pty Ltd annual report, 2010</erl:source>
    <erl:status_uri>http://resource.geosciml.org/classifier/cgi/mine-status/operating</erl:status_uri>
    <erl:specification_uri>http://data.geoscience.gov.au/feature/ga/mine/ga.mine.abc123</erl:specification_uri>
    <erl:shape xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple">
        <gml:Point srsName="epsg:4283" srsDimension="2" gml:id="GA.mineView.123456.point">
            <gml:pos>138.234 -26.747467</gml:pos>
        </gml:Point>
    </erl:shape>
</erl:MineView>

erl:MineralOccurrenceView

<?xml version="1.0" encoding="UTF-8"?>
<erl:MineralOccurrenceView 
    xmlns:erl="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml"
    xsi:schemaLocation="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0 
    http://schemas.earthresourceml.org/earthresourceml-lite/1.0/erml-lite.xsd" gml:id="ga.mineralOccurrenceView.123456">
    <erl:identifier>http://data.geoscience.gov.au/feature/ga/mineralOccurrenceView/ga.mineralOccurrenceView.123456</erl:identifier>
    <erl:name>Lassiter's Reef</erl:name>
    <erl:mineralOccurrenceType>occurrence</erl:mineralOccurrenceType>
    <erl:commodity>gold, silver</erl:commodity>
    <erl:mineName>Lassiters</erl:mineName>
    <erl:geologicHistory>Mineralisation around 350-360 Ma</erl:geologicHistory>
    <erl:hostGeologicUnit>Killi Killi Formation</erl:hostGeologicUnit>
    <erl:mineralDepositModel>mesothermal vein gold</erl:mineralDepositModel>
    <erl:mineralOccurrenceShape>irregular</erl:mineralOccurrenceShape>
    <erl:explorationActivityType>subsurface exploration, detailed geophysics</erl:explorationActivityType>
    <erl:explorationActivityDuration>6 months</erl:explorationActivityDuration>
    <erl:explorationResult>mineral resource defined</erl:explorationResult>
    <erl:observationMethod>surveyed</erl:observationMethod>
    <erl:positionalAccuracy>0.5 metres</erl:positionalAccuracy>
    <erl:source>BHP Billiton Pty Ltd annual report, 2010</erl:source>
    <erl:mineralOccurrenceType_uri>http://resource.geosciml.org/classifier/cgi/mineral-occurrence-type/occurrence</erl:mineralOccurrenceType_uri>
    <erl:representativeCommodity_uri>http://resource.geosciml.org/classifier/cgi/commodity-code/precious-metal</erl:representativeCommodity_uri>
    <erl:mine_uri>http://data.geoscience.gov.au/feature/ga/mineView/ga.mineView.123456</erl:mine_uri>
    <erl:hostGeologicUnit_uri>http://dbforms.ga.gov.au/pls/www/geodx.strat_units.sch_full?wher=stratno=35397</erl:hostGeologicUnit_uri>
    <erl:mineralDepositModel_uri>http://resource.geoscience.gov.au/classifier/ga/mineral-deposit-model/mesothermal-vein-gold</erl:mineralDepositModel_uri>
    <erl:representativeAge_uri>http://resource.geosciml.org/classifier/ics/icschart/Carboniferous</erl:representativeAge_uri>
    <erl:representativeOlderAge_uri>http://resource.geosciml.org/classifier/ics/icschart/Famennian</erl:representativeOlderAge_uri>
    <erl:representativeYoungerAge_uri>http://resource.geosciml.org/classifier/ics/icschart/Tournaisian</erl:representativeYoungerAge_uri>
    <erl:specification_uri>http://ga.gov.au/feature/mineralOccurrence/ga.mineralOccurrence.123456</erl:specification_uri>
    <erl:shape>
        <gml:Point srsName="epsg:4283" srsDimension="2" gml:id="GA.mineralOccurrenceView.123456.point">
            <gml:pos>138.234 -26.747467</gml:pos>
        </gml:Point>
    </erl:shape>
</erl:MineralOccurrenceView>

erl:MiningActivityView

<?xml version="1.0" encoding="UTF-8"?>
<erl:MiningActivityView 
    xmlns:erl="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml"
    xsi:schemaLocation="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0 
    http://schemas.earthresourceml.org/earthresourceml-lite/1.0/erml-lite.xsd" gml:id="ga.miningActivityView.123456">
    <erl:identifier>http://data.geoscience.gov.au/feature/ga/miningActivity/ga.miningActivityView.123456</erl:identifier>
    <erl:activityType>open-pit mining</erl:activityType>
    <erl:activityEndDate>2008-06-21</erl:activityEndDate>
    <erl:activityStartDate>2006-05-13</erl:activityStartDate>
    <erl:mineName>Lassiters</erl:mineName>
    <erl:commodity>gold</erl:commodity>
    <erl:operator>Smiths Mining Contractors Pty Ltd</erl:operator>
    <erl:oreProcessedAmount>7.1 Mt</erl:oreProcessedAmount>
    <erl:productionGrade>3.5 g/t Au</erl:productionGrade>
    <erl:producedMaterial>bullion</erl:producedMaterial>
    <erl:productionAmount>22.6 t</erl:productionAmount>
    <erl:productionRecovery>90.95%</erl:productionRecovery>
    <erl:observationMethod>surveyed</erl:observationMethod>
    <erl:positionalAccuracy>0.5 metres</erl:positionalAccuracy>
    <erl:source>BHP Billiton Pty Ltd annual report, 2010</erl:source>
    <erl:activityType_uri>http://resource.geosciml.org/classifier/cgi/mining-activity/open-pit-mining</erl:activityType_uri>
    <erl:mine_uri>http://data.geoscience.gov.au/feature/ga/mineView/ga.mineView.123456</erl:mine_uri>
    <erl:commodity_uri>http://resource.geosciml.org/classifier/cgi/commodity-code/gold</erl:commodity_uri>
    <erl:specification_uri>http://data.geoscience.gov.au/feature/ga/miningActivity/ga.miningActivity.abc123</erl:specification_uri>
    <erl:shape xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple">
        <gml:Point srsName="epsg:4283" srsDimension="2" gml:id="GA.miningActivityView.123456.point">
            <gml:pos>138.234 -26.747467</gml:pos>
        </gml:Point>
    </erl:shape>
</erl:MiningActivityView>

erl:MiningWasteView

<?xml version="1.0" encoding="UTF-8"?>
<erl:MiningWasteView 
    xmlns:erl="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml"
    xsi:schemaLocation="http://xmlns.earthresourceml.org/earthresourceml-lite/1.0 
    http://schemas.earthresourceml.org/earthresourceml-lite/1.0/erml-lite.xsd" gml:id="GA.miningWasteView.123456">
    <erl:identifier>http://data.geoscience.gov.au/feature/ga/miningWasteView/ga.miningWasteView.123456</erl:identifier>
    <erl:wasteType>acid water</erl:wasteType>
    <erl:storageType>surface</erl:storageType>
    <erl:mineName>Lassiters</erl:mineName>
    <erl:processingType>chemical treatment</erl:processingType>
    <erl:environmentalImpacts>liquid emission</erl:environmentalImpacts>
    <erl:materials>water</erl:materials>
    <erl:density>1 g/cc</erl:density>
    <erl:grade>0.04% CN</erl:grade>
    <erl:volume>53.7 megalitres</erl:volume>
    <erl:observationMethod>surveyed</erl:observationMethod>
    <erl:positionalAccuracy>0.5 metres</erl:positionalAccuracy>
    <erl:source>Department of Environment report XYA-01, 2011</erl:source>
    <erl:mine_uri>http://data.geoscience.gov.au/feature/ga/mineView/ga.mineView.123456</erl:mine_uri>
    <erl:wasteType_uri>http://myVocabulary/mining-waste-type/acid-water</erl:wasteType_uri>
    <erl:storageType_uri>http://resource.geosciml.org/classifier/cgi/waste-storage/surface</erl:storageType_uri>
    <erl:specification_uri>http://data.geoscience.gov.au/feature/ga/miningWaste/ga.miningWaste.abc123</erl:specification_uri>
    <erl:shape>
        <gml:Point srsName="epsg:4283" srsDimension="2" gml:id="GA.miningWasteView.123456.point">          
            <gml:pos>138.234 -26.747467</gml:pos>
        </gml:Point>
    </erl:shape>
</erl:MiningWasteView>

ProcessingPlantView

<?xml version="1.0" encoding="UTF-8"?>
<erl:ProcessingPlantView 
    xmlns:erl="http://xmlns.earthresourceml.org/earthresourceml-lite/2.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml/3.2"
    xsi:schemaLocation="http://xmlns.earthresourceml.org/earthresourceml-lite/2.0 http://schemas.earthresourceml.org/earthresourceml-lite/2.0/erml-lite.xsd"
    gml:id="test_v2.0.1">  
    <erl:identifier>http://data.geoscience.gov.au/feature/ga/processingPlantView/ga.processingPlantView.123456</erl:identifier>
    <erl:name>Lassiter's Mill</erl:name>
    <erl:processingPlantType>concentrator</erl:processingPlantType>
    <erl:startDate>1905-10-01</erl:startDate>
    <erl:endDate>2017-12-26</erl:endDate>
    <erl:status>abandoned</erl:status>
    <erl:commodity>gold, copper, silver</erl:commodity>
    <erl:inputMaterial>ore</erl:inputMaterial>
    <erl:product>gold-copper concentrate</erl:product> 
    <erl:observationMethod>surveyed</erl:observationMethod>
    <erl:positionalAccuracy>2 metres</erl:positionalAccuracy>
    <erl:source>BHP Billiton Pty Ltd annual report, 2010</erl:source>
    <erl:processingPlantType_uri>http://resource.geosciml.org/classifier/cgi/processing-plant-type/concentrator</erl:processingPlantType_uri>
    <erl:status_uri>http://resource.geosciml.org/classifier/cgi/mine-status/abandoned</erl:status_uri>
    <erl:representativeCommodity_uri>http://resource.geosciml.org/classifier/cgi/commodity-code/precious_metals</erl:representativeCommodity_uri>
    <erl:specification_uri>http://data.geoscience.gov.au/feature/ga/miningWaste/ga.processingPlant.123456</erl:specification_uri>
    <erl:shape>
        <gml:Point srsName="epsg:4283" srsDimension="2" gml:id="GAprocessingPlantView.123456.point">          
            <gml:pos>138.234 -26.747467</gml:pos>
        </gml:Point>
    </erl:shape>
</erl:ProcessingPlantView>

Underlying (INSPIRE) conceptual model

Simplifies the standard data model EarthResourceML for Mineral Resources

Purpose & use

Developed for both WMS and simple feature WFS to more readily show Earth Resource data, using existing clients.

For WMS attributes follow defined element names to allow construction of harmonized styles, or the construction of SLD on-the-fly by aware clients.

For a discussion on harmonized styles for such a WMS see: https://themes.jrc.ec.europa.eu/discussion/view/119655/mapping-layers-to-be-provided-by-inspire-view-services-to-erml-lite

Used simplification rules

Based on rules used in GeoSciML-Lite see: #34

Additional information

GeoJSON (RFC 7946) only supports one projection (effectively urn:ogc:def:crs:OGC::CRS84), while INSPIRE requires projections based on ETRS89?

The best summary is probably http://docs.opengeospatial.org/guides/16-122r1.html section (5.3. OGC needs that GeoJSON does not cover). So for INSPIRE GeoJSON we will need to Extend GeoJSON for geometry but not using the geometry type, as per example "Example of GeoJSON file describing a protected area also in EPSG:25831 (coordinates are dummy)."

{ "type": "FeatureCollection", 
  "features": [{ 
      "type": "Feature", 
      "geometry": { 
         "type": "MultiPolygon", 
         "coordinates": [ [[[102.0, 2.0], [103.0, 2.0], [103.0, 3.0], [102.0, 3.0], [102.0, 2.0]]], [[[100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0]], [[100.2, 0.2], [100.8, 0.2], [100.8, 0.8], [100.2, 0.8], [100.2, 0.2]]] ] }, 
       "id": "http://www.ecopotential.org/sierranevada", 
       "bbox": [100.0, 0.0, 103.0, 3.0], 
       "bboxCRS": { 
         "bbox": [500100.0, 4600000.0, 500103.0, 4600003.0], 
         "crs": "http://www.opengis.net/def/crs/EPSG/0/25831", } 
       "properties": { 
           "geometryCRS": { 
             "type": "MultiPolygon", 
             "crs": "http://www.opengis.net/def/crs/EPSG/0/25831", 
             "coordinates": [ [[[500102.0, 4600002.0], [500103.0, 4600002.0], [500103.0, 4600003.0], [500102.0, 4600003.0], [500102.0, 4600002.0]]], [[[500100.0, 4600000.0], [500101.0, 4600000.0], [500101.0, 4600001.0], [500100.0, 4600001.0], [500000.0, 4600000.0]], [[500100.2, 4600000.2], [500100.8, 4600000.2], [500100.8, 4600000.8], [500100.2, 4600000.8], [500100.2, 4600000.2]]] ] },
           "name": "Sierra Nevada", 
           "ecosystemType": "Mountain",
           "ecosystemService": ["turism", "biodiversity reserve"], 
           "elevationRange": [860, 3482], 
           "figureOfProtection": "National park" } } }

Should the GeoJSON encoding rule focus on the spatial aspects or also include simplification rules for the non-spatial properties, e.g. to create flatter structures or pre-defined type mappings for certain types (e.g. geographical names)?

Simplified encoding example

https://github.com/opengeospatial/omsf-profile/tree/master/omsf-gml

Short description

The purpose of this activity is to define simple encodings for the most used O&M Observation types, and thus enable interoperable O&M data exchange between existing software applications, servers and clients limited to using simple (non-complex) GML features.

Within the INSPIRE context, the provided GeoJSON encoding could be applied to data sets at least in in themes AC-MF and OF.

Example instance

<omsf:MeasureObservation gml:id="f-1">
  <gml:identifier codeSpace="fmi-fi-weatherobs">kumpula-2017-08-17_12-00_air-temp-1</gml:identifier>
  <omsf:phenomenonTime>2017-08-17T12:00:00Z</omsf:phenomenonTime>
  <omsf:resultTime>2017-08-17T12:01:25Z</omsf:resultTime>
  <omsf:usedProcedure
    xlink:href="http://xml.fmi.fi/process/met-surface-observations"
    xlink:title="Meteorological surface observations" />
  <omsf:observedProperty 
    xlink:href="http://vocab.nerc.ac.uk/collection/P07/current/CFSN0023/air_temperature"
    xlink:title="Air temperature" />
  <omsf:featureOfInterestTitle>Helsinki Kumpula</omsf:featureOfInterestTitle>
  <omsf:featureOfInterestGeometry>
    <gml:Point gml:id="p-1" srsName="http://www.opengis.net/def/crs/EPSG/0/4258" srsDimension="2">
      <gml:pos>60.20307 24.96131</gml:pos>
    </gml:Point>
  </omsf:featureOfInterestGeometry>
  <omsf:featureOfInterestReference xlink:href="http://sws.geonames.org/843429/about.rdf"/>
  <omsf:result uom="Cel">12.5</omsf:result>
</omsf:MeasureObservation>

Purpose & use

The purpose of the OMSF GML and GeoJSON encodings is to provide an standard encoding for relatively simple O&M based observation and forecast data. There is an on-going project funded by the Finnish Meteorological Institute and Vaisala to develop and test the OMSF encodings by developing a proof-of-concept WFS 3.0 server/service offering various weather and/or air quality related datasets. The OMSF encoding however is not specific to any data theme, but is applicable to any use case where the O&M data model usage is desired, but the client software cannot handle complex features.

The OMSF encodings are not yet used in operative services (as of July 2018), an open PoC service and related hackathon activities have been planned for early 2019.

Used simplification rules

The OMSF property mappings have been designed manually property by property, starting from the Observations and measurements UML model (as specified in ISO 19156:2011), and applying the most appropriate, simple encoding for each property considering the limitations of both the format requirements (GML Simple Features Profile 2.0, OGC 10-100r3) and the existing client software.

Additional information

OMSF GML encoding for the O&M UML classes OM_ComplexObservation, OM_DiscreteCoverageObservation, OM_GeometryObservation, OM_PointCoverageObservation, and OM_TemporalObservation are not provided. Thus this implementation is intentionally more limited than the one specified in the OGC Standard "Observations and Measurements - XML Implementation" (OGC Document 10-025r1) which is able to express the full O&M abstract model. However, expressing all these is possible by using the GenericObservation feature type with a remote reference to the Observation result.

This application profile does not provide encodings for the sampling feature data, as the feature of interest is only presented by it's geometry, optionally by it's name and, also optionally, by a remote reference to the description of the complete feature of interest.

Simplification Model Transformation Rule

This rule issue is to be referenced from the best practive paper.

Use the sections below to specify the Model Transformation rule.

Name of the Rule

Attribute: one multiple attribute to list of single attributes

Category

Add the category into one of the following categoies:

• Alternate Structures for specific types or type hierarchies (can be applied to specific types)
• General model simplification rules (can be applied everywhere)
• Flatten nested structures
• Flatten attributes (e.g. uom)
• Flatten lists/arrays
• Profiling (reduction of degrees of freedom, e.g. usage of property types in choices)

Description

Include as many instances as reasonably necessary for the attribute. When a (o..*) attribute
in practice has no more than 3 instances, one can construct three attributes for this
the simplified information model and give them a consecutive name (for example: name1, name2 and name3). The attributes must always start with the same substantive name and end with a number indication.

UML Model

If this rule falls into the "Alternate Structures for specific types" category, provide a UML class diagram of your alternative model. For other rules, you may optionally provide a UML diagram.

Example instance in default encoding:

Provide an example in the default encoding.

Example instance in simplified encoding:

Provide an example feature that is based on the transformed model.

Model transformation rule:

Include as many instances as reasonably necessary for the attribute. When a (o..*) attribute
in practice has no more than 3 instances, one can construct three attributes for this
the simplified information model and give them a consecutive name (for example: name1, name2 and name3). The attributes must always start with the same substantive name and end with a number indication.

Instance transformation rule:

Describe how data in a property needs to be transformed, if necessary. As an example, there are rules which concatenate values (e.g. in the GeoSciML Lite approach).

Solves usability issues:

Describe as concrete as possible, ideally using the test classes described in CanIUse, which issues in which software this approach addresses and solves.

Known usability issues:

Describe whether this transformation leaves problems unsolved, or introduces new issues.

Reversibility:

entirely reversible.

Simplified encoding example

Short description

OS MasterMap® Water Network Layer offers one of the world’s most detailed, heighted water networks – showing the flow and precise course of every river, stream, lake and canal in Great Britain.

It does this by extending INSPIRE HY-N with one or two extra attributes on each of three features, and a lot on WatercourseLink (& link set)

The key customers were the (England & Wales) Environment Agency, and the (Scottish) Environmental Protection Agency

Specification at: https://www.ordnancesurvey.co.uk/docs/technical-specifications/os-mastermap-water-network-technical-specification.pdf

Schema at: https://www.ordnancesurvey.co.uk/xml/schema/waternetwork/v1/index.html

We achieved this by importing & extending the UML models in EA, and using ShapeChange.

Example instance

https://www.ordnancesurvey.co.uk/docs/sample-data/os-mastermap-water-network-sample-data.gz#sample-data-download

Purpose & use

understand water-related risks in detail, combining OS MasterMap Water Layer with OS MasterMap Topography Layer, property information and 3D height data for even richer insights.

For planners, for surveyors, for engineers – this Layer offers the potential to model in 2D and 3D like never before, thanks to the clarity of river flow, gradient and river widths.

Case study: https://www.ordnancesurvey.co.uk/business-and-government/case-studies/dundee-city-council-managing-flood-risk.html

Used simplification rules

Moved names to links

Additional information

A separate issue to draw attention to earlier reflections on the encoding rule discussion: please have a look at the following document, and post your feedback.

AGENCY FOR DATA SUPPLY AND EFFICIENCY. 2016.1 Fitness for purpose Annex III - Danish comments [online]. 8 June 2017. Available from: http://inspire-danmark.dk/media/2918083/doc11-_20161-fitness-for-purpose-annex-iii-dk-comments.pdf

As a short introduction, hereby the table of contents of this document.

Table of contents

1 Scope.........................................................................................................................................................3
2 Executive summary ...................................................................................................................................3
3 “The Danish suggestion” summarized and clarified...................................................................................3
3.1 Profiling..............................................................................................................................................4
3.1.1 Property not maintained.................................................................................................................4
3.1.2 Property is constant .......................................................................................................................4
3.1.3 Property is never present...............................................................................................................4
3.1.4 Property of no relevance................................................................................................................4
3.2 Flattening inheritance structures........................................................................................................4
3.3 Flattening complex data types ...........................................................................................................5
3.4 Flattening multiplicity..........................................................................................................................5
3.5 Encoding & decoding.........................................................................................................................5
3.5.1 Encoding........................................................................................................................................5
3.5.2 Decoding........................................................................................................................................6
4 Comments on the German report ..............................................................................................................7
4.1 Section 4.1, the use case of data management.................................................................................7
4.2 REC-01: Flattening of complex structures .........................................................................................7
4.3 REC-02: Simplify attributes representing measures..........................................................................8
4.4 REC-03: Remove obligation to provide UnitOfMeasure for attributes that are Voidable ...................9
4.5 REC-06: Use alternative encoding for specific elements...................................................................9
4.5.1 Encoding of GeographicalName as string ...................................................................................10
4.5.2 Encoding of GeographicalName as string with language information .........................................11
5 References

Short description

Our objective was to investigate different strategies for conversion of existing INSPIRE GML to GeoJSON with the idea to test the usability of the end product with popular GIS tools (desktop and web clients). We discovered 'Addresses' data through the INSPIRE geoportal and converted it to GeoJSON.

Example instance

Example instances are available here.

Sources

Spanish dataset served through a WFS, discovered through the INSPIRE Geoportal.

Underlying (INSPIRE) conceptual model

Source data validates against the 'Addresses' schema.

Purpose & use

The GeoJSON conversion (with different approaches, see below) was developed ad hoc to evaluate the usability of the data set in different tools, and compare it with the original GML.

Specific technical problems investigated:

• Use CRS different from CRS84
• Feature (types) with multiple geometries
• Represent complex feature types
• Multiple attribute values
• Associations between features
• Encode features with no Geometry. In the case of our source AD dataset those are PostalDescriptor, ThoroughfareName, and AdminUnitName.

Used simplification rules

We tried different approaches, which resulted in several GeoJSON files:

• Result 1. Preserves the complex structure of the source GML
• Result 2. All attributes are flattened, while preserving the hierarchical structure of source attributes through the names of GeoJSON keys. Replicates all Feature types from the source GML in a single GeoJSON FeatureCollection.
• Result 3. One FeatureCollection (i.e. one GeoJSON file) per Feature type that requires 'Joining' of individual files within the client application through a common identifier. In the case of our source an Address has the following components: PostalDescriptor, ThoroughfareName, and AdminUnitName.
• Result 4. Combines all Feature types from the source GML as flat properties of a single 'Feature'
• Result 5. Further simplifies by preserving only selected (e.g. non-voidable and/or populated) attributes.

Additional information

Our source data was projected in EPSG:25830.

Issues with the encoding

• Complex features (Result 1.) are not optimally usable within tools without an intermediate ETL step (flattening). See snapshot below:

• Different Feature types (Result 2.) can be encoded as different Features of the same FeatureCollection only in case when single type geometry is mixed with features with no geometry ("geometry": null). If Features are not allocated a JSON null value is allowed in accordance with RFC 7946. However, mixing different features that are structurally different in the same feature collection is not useful, as properties of different features are appended.

• Multiple geometries
  In cases where onе Feature is represented by more than one geometry, the GeoJSON GeometryCollection can be used inside a Feature. However in accordance with RFC 7946:

Implementations SHOULD NOT apply any additional semantics to the "geometries" array.

Properties of the feature will in such case be shared by all geometries, i.e. we would need to come up with a means to identify which properties describe which geometry. Note: we did not observe such an issue with our test case, but indicate it here for discussion.

• Multiple attributes with the same name, (Result 3) existing in the source GML posed an issue with client applications (in the case of our examples we had three xlink to individual Address components). Only the first attribute was read by the tools. We had to rename the attributes in order to be able to consume the whole information in the clients.

• Very long names of JSON keys When flattening (Results 3, 4, 5), the names of keys easily become too long, e.g. when the GeographicalNames data type is used. A naming convention/rule for JSON keys that preserves the hierarchy of complex feature types might be needed.

• CRS In order to preserve the original CRS we used a 'crs' member (see example below) defined globally for the FeatureCollection. That approach is not part of RFC 7946.

Note that QGIS handles (reads/writes) the crs member and data can be reprojected, while this is not the case for the web application http://geojson.io (which only assumes CRS84 and thus does not correctly read and display the data).

"crs":{  
    "type":"name",
    "properties":{  
       "name":"urn:ogc:def:crs:EPSG::25830"
    }
 }

In addition, the inclusion of the CRS member does not go against RFC 7946, as the GeoJSON specification states that:

... where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

If we want to go that way, we should figure out a way to come up with an arrangement on the use of CRS.

• Source of properties If we combine attributes of different Feature types as properties of a single GeoJSON Feature, we do not anymore manage to keep track of the source type.

• Criteria for removal of attributes - If attributes are to be deleted (as done in Result 5.), we would need to elaborate on commonly agreed rules avoiding data loss, and ensuring to not be rooted in a specific use case only. For example, in Result 5, we have removed all properties related to associations, identifiers and life-cycle attributes of the joined features, and kept only the text attribute of the GeographicalName type.

What do you consider to be the best aspects/characteristics of this example?

The flattened examples are usable (out-of-the-box) within different tools. We tested with QGIS and http://geojson.io.

To summarise, from a usability point of view, the most user-friendly example is Result 4 (or Result 5, which is a further simplification of Result 4). Additional work should be done in order to decide if and how to remove the voidable or unnecessary attributes, and come up with better names of keys for a flat structure.

GeoJSON example

Short description

The ldproxy tool can be used as a facade on existing WFS 2.0 services, including INSPIRE Download Services, to provide access to the data according to the draft WFS 3.0 Core specification. Supporting GeoJSON is one capability.

Example instance

Link to a feature of a square (and the same feature in GML). This is from a topographic dataset in North-Rhine Westphalia (Germany).

Purpose & use

Support for users preferring JSON over XML.

Used simplification rules

If ldproxy is used as a facade to a WFS 2.0 service, it transforms the GML 3.2 data automatically to GeoJSON. The mapping can be configured to some extent.

Properties that are not useful for a target audience can be ignored. In the example above, the modellart property is suppressed as each feature in the dataset has the same value (stating that it is large-scale topographic data).

The property names can be changed to something more meaningful to a non-expert, if needed. This wasn't necessary in the example above.

For properties with multiple values, these can be either flattened (using suffixes for the additional values to keep the property names unique) or be represented as an array. I do not think the topographic dataset used in the link above has attributes with multiple values, but if it has, the values are flattened.

For properties with complex values, these can be either represented as a JSON object or be flattened. In the example above, the data has been flattened (e.g. lebenszeitintervall/AA_Lebenszeitintervall/beginnt).

Values that are codes can be transformed to human readable labels. In the linked example above, this is only done in the HTML representation (the art property value of 4000 is translated to Platz), but this could also be applied in the GeoJSON output.

Additional information

Not all cases are covered yet in the current implementation. For example, xlink:href and xsi:nil attributes are ignored as a default.

This is a link to the GML.next GeoJSON discussion we opened this year:

https://geoforum.nl/t/gml-next-hoe-zet-je-json-geojson-in-als-lichter-alternatief-voor-online-toepassingen/1681

GeoJSON example

Short description

Danish Addresses

Example instance

http://dawa.aws.dk/adresser?vejnavn=Rentemestervej&husnr=8&postnr=2400&struktur=mini&format=geojson

Purpose & use

Display data regarding addresses, and provide functionality regarding adresses.

E.g. search with different parameters, autocomplete of adresses on your own website, datawash of adresses in your own system, reverse geocoding, ...

See also http://dawa.aws.dk/dok/om and https://github.com/DanmarksAdresser

Used simplification rules

I would have to investigate.

Additional information

N/A

Some of the examples proposed (e.g. #4, #5, #6, #7) are extensions to the INSPIRE data models that include additional ("simple") properties with the aim to make data easier to use.

Should such extensions be considered in the simplification rules, and under what conditions?

Simplification rules could be implemented purely in the UML-to-encoding rules, or alternatively, in a first step, an implementation model could be manually developed in UML, and the UML-to-encoding rules could then be applied to that implementation model.

The latter was already foreseen in the data specifications template (for the UML-to-GML mapping):

Simplification Model Transformation Rule

This rule issue is to be referenced from the best practive paper.

Use the sections below to specify the Model Transformation rule.

Name of the Rule

Association to attribute

Category

Add the category into one of the following categoies:

• Alternate Structures for specific types or type hierarchies (can be applied to specific types)
• General model simplification rules (can be applied everywhere)
• Flatten nested structures
• Flatten attributes (e.g. uom)
• Flatten lists/arrays
• Profiling (reduction of degrees of freedom, e.g. usage of property types in choices)

Description

Associations can be implemented as references or be embedded. The latter provides a nested structure. By replacing associations with attributes with a specific attributevalue the association functionality is equally realised.

UML Model

Transformes to:

Example instance in default encoding:

Provide an example in the default encoding.

Example instance in simplified encoding:

Provide an example feature that is based on the transformed model.

Model transformation rule:

Describe the actual model transformation rule, either in free text or in an algorithmic form.

Instance transformation rule:

Describe how data in a property needs to be transformed, if necessary. As an example, there are rules which concatenate values (e.g. in the GeoSciML Lite approach).

Solves usability issues:

Describe as concrete as possible, ideally using the test classes described in CanIUse, which issues in which software this approach addresses and solves.

Known usability issues:

Describe whether this transformation leaves problems unsolved, or introduces new issues.

Reversibility:

entirely reversible.

GeoJSON example

Short description

Multiple Datasets on governmental platform. https://data.overheid.nl/data/dataset?q=geojson
Inspire theme: several but not according to data specifications.
https://data.overheid.nl/data/dataset?q=geojson

Example instance

Over 800 GeoJSON and JSON encoded datasets

Purpose & use

Use case:

Used simplification rules

Additional information

Glossary proposal

code

representation of a label according to a specified scheme
[ISO 19118:2011]

conversion rule

rule for converting instances in the input data structure to instances in the output data structure
[ISO 19118:2011]

data

reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or processing
[ISO/IEC 2382-1:1993]

encoding

conversion of data into a series of codes
[ISO 19118:2011]

encoding rule

identifiable collection of conversion rules that define the encoding for a particular data structure
[ISO 19118:2011]

information

knowledge concerning objects, such as facts, events, things, processes, or ideas, including concepts, that within a certain context has a particular meaning
[SOURCE: ISO/IEC 2382-1:1993]

format

language construct that specifies the representation, in character form, of data objects in a record, file, message, storage device, or transmission channel
[ISO 19145:2013; ISO/IEC 2382‑15:1999]

Simplified encoding example

Short description

GeoSciML Lite (previously called GeoSciML-Portrayal), is a simplification of parts of GeoSciML and Observations and Measurements (ISO 19156).

GeoSciML Lite conforms to the Level 0 of the Simple Features Profile for GML (OGC 10-100r, OGC 06-049).

The simple features profile supports only a limited subset of possible GML geometry types that may be used to describe feature geographic location and shape. For the purposes of GeoSciML simple features, these include GEO::Point, GEO::LineString, GEO::Curve, GEO::Polygon, GEO::Surface, GEO::MultiPoint, GEO::MultiCurve, GEO::MultiSurface and multi-geometry types consisting of collections of these base types.

There are seven GeoSciML-Lite views descibed in the 4.1 standard, these are: GeologicUnitView, ShearDisplacmentStructureView, ContactView, BoreholeView, SiteObservationView, GeologicSpecimenView, GeomorphologicUnitView.

UML model (HTML) for GeoSciML including Lite can be found at: http://www.geosciml.org/doc/geosciml/4.1/documentation/html/

Example instance

BoreholeView

The following services provide BoreholeView
WMS: http://resource.europe-geology.eu/service/wmsBorehole?service=WMS&request=GetCapabilities&
WFS: http://resource.europe-geology.eu/service/wmsBorehole?service=WFS&request=GetCapabilities&

Example request (GML):
http://mapsrefdev.brgm.fr/wxs/epos/epos_boreholeview?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=ms:BoreholeView&STARTINDEX=2000&COUNT=100&SRSNAME=urn:ogc:def:crs:EPSG::4326&BBOX=52.5561761583996514,-22.26424005614752488,64.09903939032463427,-6.31379936534628783,urn:ogc:def:crs:EPSG::4326

Underlying (INSPIRE) conceptual model

OGC Geoscience Markup Language 4.1 (GeoSciML) ~ http://docs.opengeospatial.org/is/16-008/16-008.html

Purpose & use

Developed for both WMS and simple feature WFS to more readily show Geoscience data, using existing clients. The intention is to support interoperable map services, for which interoperability is based on a shared data schema and the use of standard vocabulary terms for basic type classification of contacts and faults, age of geologic units and faults, and lithology of geologic units.

For WMS attributes follow defined element names to allow construction of harmonized styles, or the construction of SLD on-the-fly by aware clients.

Services exist and are registered in the OneGeology portal, portal can do SLD re-portrayal for WMS declaring conformance (through keywords), for GeologicUnitView.

Used simplification rules

Lite properties are mapped to existing GeoSciML or O&M properties. Values from GeoSciML and O&M complex properties are converted into GML SF-0 valid basic types (OGC 10-100r2, Clause 8.4.4.1). Different transformations scenarios are possible:

• The GeoSciML property is already a basic type and the value is used as-is
• A representative element of the complex type is used. For example; only SWE::Category::value.
• The value is constructed from several fields merged into a single string.

Lite properties cardinalities are limited to 0..1, while GeoSciML properties are often multiple. The data provider must then either a) choose one representative value or b) aggregate from the collection of values a new value. Strings will generally be concatenated while numerical values might be averaged or processed in some way to produce a significant value. Some Lite properties are designed to represent explicitly one particular occurrence, such as GeologicUnitView::representativeOlderAge_uri, which is the oldest age. Others are more suggestive and require the judgement of the data provider, such as GeologicUnitView::representativeLithology_uri. When values are concatenated, they shall be human readable and using simple separators (e.g., commas).

Properties ending with “_uri” shall not have concatenated values. Those properties are designed to fulfill specific query and rendering use cases.

For each GeoSciML Lite view, a table provides the mapping between Lite and GeoSciML properties. The mapping is expressed in OCL syntax as a path from the base type of the view to the property where the value resides in GeoSciML.

Additional information

Should the simplification rules / GeoJSON encoding rule include profiling, i.e. should they include the possibility to provide only a sub-sets of the properties (and maybe object types) defined in the INSPIRE conceptual data models?

simple features are also used for other process than viewing and spatial analysis , we can integrate generalisation tools , and change detection tools allowing to register the historical changes of a same dataset. When simplifying by mean of alternative datamodel, we should ensure that UIds and life-cycle info are kepts. But from complex datamodel to simplify ones is that achievable?

Is it correct to say:

The GeoJSON format differs from other GIS standards in that it was written and is maintained not by a formal standards organization, but by an Internet working group of developers.

Certainly that's how it started, but now it has been formalised as an IETF internet standard. IETF describe themselves as: The IETF is the premier Internet standards organization.

Default CRS is WGS 84

We shouldn't say it is WGS 84, but rather that it uses it, as per the standard...

a geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units
of decimal degrees. This is equivalent to the coordinate reference
system identified by the Open Geospatial Consortium (OGC) URN
urn:ogc:def:crs:OGC::CRS84.

(or http://www.opengis.net/def/crs/OGC/1.3/CRS84)

We should perhaps add it is not the same as EPSG:4326

Simplified encoding example

Short description

OS Open Rivers, extends INSPIRE HY-N: names moved to links, a couple of extra attributes

Specification: https://www.ordnancesurvey.co.uk/docs/user-guides/os-open-rivers-user-guide.pdf

Schema: https://www.ordnancesurvey.co.uk/xml/open/rivers/1.0/OSOpenRivers.xsd

The key customers for this were the (England & Wales) Environment Agency and the Scottish Environmetal Protection Agency

Achieved by extending INSPIRE model in EA & then using ShapeChange

Example instance

Available from https://os.uk/opendatadownload/products.html#OPRVRS

Purpose & use

tag information with the river IDs used by environment agencies so everybody can use it.

Case study: https://os.uk/business-and-government/case-studies/dundee-city-council-managing-flood-risk.html

Used simplification rules

Moved names to links

Additional information

The https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/specification.md document has a section Projected CRS support but we probably don't just mean projected CRS, we mean support for any alternate coordinate reference system whether projected (like EPSG:3857) or geographic like EPSG:4326 or EPSG:4258)

Simplification Model Transformation Rule

Name of the Rule

Rule for transforming XML into JSON

Category

• Alternate Structures for specific types or type hierarchies (can be applied to specific types)

Description

General Rules for transforming XML into JSON originally taken from OGC 14-009r1 ~ Engineering Report: “OGC 14-009r1, OGC Testbed-10 Rules for JSON and GeoJSON Adoption: Focus on OWSContext" and amended in OGC 15-053r1 ~ Testbed 11 Implementing JSON/GeoJSON in an OGC Standard Engineering Report

UML Model

Example instance in default encoding:

TODO: GeoSciML-Lite GeoJSON encoding variant,

Example instance in simplified encoding:

Model transformation rule:

• The XML element local name is the JSON object name
• The XML element single text node is the JSON object value
• The XML element attributes nodes are transformed in JSON nested objects
• The XML nested elements are transformed in JSON nested objects
• An XML element text node is transformed in a JSON nested object when other types of nodes are present
• The XML element text value can be casted to a JSON object value type
• XML fragments can be transformed in text members
• XML repeated elements (or attributes) are transformed into JSON arrays. The JSON array name could be changed to plural when convenient
• XML namespaces are ignored

Instance transformation rule:

Describe how data in a property needs to be transformed, if necessary. As an example, there are rules which concatenate values (e.g. in the GeoSciML Lite approach).

Solves usability issues:

Provides a rule-set for a different encoding

Known usability issues:

Doesn't solve CRS issue for GeoJSON.
Introduces issues inherent to JSON (no validation...,)

Reversibility:

Reversibility will depend on XML to be transformed, For GeoSciML-Lite will be partially reversed.

Simplified encoding example

Short description

One activity in the European Location Framework project was to harvest INSPIRE data from download services of Europe’s National Mapping, Cadastral and Land Registration Authorities, transform it to a native ArcGIS representation and publish it in ArcGIS Online.

The resulting GeoServices JSON encoding is very similar to GeoJSON and it is straightforward to convert data between the two encodings (for example, see https://github.com/Esri/geojson-utils).

Example instance

An example in JSON:

{
  "feature" : 
  {
    "attributes" : {
      "objectid" : 1, 
      "sourceId" : "the-gml-id", 
      "sourceFeature" : "https://example.com/the/source/feature/in/GML", 
      "identifier" : "the-gml-identifier", 
      "inspireId_localId" : "local-id", 
      "inspireId_namespace" : "the-namespace", 
      "beginLifespanVersion" : 1414108800000, 
      "endLifespanVersion" : null, 
      "nationalCode" : "10000", 
      "nationalLevel" : "3", 
      "nationalLevel_name_1" : "Provincie", 
      "nationalLevel_name_1_lang" : "nl", 
      "nationalLevel_name_2" : "Provinz", 
      "nationalLevel_name_2_lang" : "de", 
      "nationalLevel_name_3" : "Province", 
      "nationalLevel_name_3_lang" : "fr", 
      "country" : "BE", 
      "name_1" : "Antwerpen", 
      "name_1_lang" : "nl", 
      "upperLevelUnitId" : "https://example.com/the/feature"
    }, 
    "geometry" : 
    {
       ...
    }
  }
}

Purpose & use

Simplify the use of ELF/INSPIRE data for ArcGIS end users and developers.

Used simplification rules

General remarks

Several aspects have been covered in the transformation. Not all of them are strictly simplifications of the data structures, but all of them are executed in order to simplify the use of the data in map-based applications.

The implementation schema for INSPIRE/ELF data in ArcGIS was designed to be consistent with ArcGIS data modelling principles and practices, and is derived from the ELF/INSPIRE application schemas. The transformation process was automated.

The resulting data structures are intended to be easier to use in a GIS context and in maps (easier than the source data). The data is intended to be easier to understand and handled by users and developers.

Geometry types

Feature types often have geometric properties that are, for example, point or polygon, aggregate or primitive, etc. That is, the data may contain features of the same type with different geometry types. Such INSPIRE feature types have been fanned out into multiple feature types in the implementation schema, one for each geometry type that occurs in the source datasets.

Note that this is in a way ArcGIS-specific (in ArcGIS, every feature type has to have a fixed geometry type) and not strictly required in a GeoJSON context where no concept of a feature type exists anyhow. Nevertheless, it is not uncommon in GIS tools to expect homogeneous geometries per feature type.

Nested data types

Nested data types and properties are flattened, every property will be a property of the main feature class.

Multiplicity

Support for multiple values per property is an issue in ArcGIS and other GIS tools. The standard approach is to have a fixed number of attributes instead, typically three unless it is known that more or less values are needed. A suffix with an incremental number to the attribute names to distinguish the attributes.

Standard properties

The following standard properties occurring in most ELF/INSPIRE features encoded in GML are renamed and flattened in the implementation schema:

• @gml:id → sourceId
• gml:identifier → identifier
• ns:inspireId/base:Identifier/base:localId → inspireId_localId
• ns:inspireId/base:Identifier/base:namespace → inspireId_namespace
• ns:inspireId/base:Identifier/base:versionId → inspireId_versionId

Reduce geographical name properties to three names with language information

Every property that contains an unlimited number of values of the type GeographicalName is reduced to three name and language attributes, e.g.:

• ns:name[1]/gn:GeographicalName/gn:spelling[1]/gn:SpellingOfName/gn:text → name_1
• ns:name[1]/gn:GeographicalName/gn:language → name_1_lang
• ns:name[2]/gn:GeographicalName/gn:spelling[1]/gn:SpellingOfName/gn:text → name_2
• ns:name[2]/gn:GeographicalName/gn:language → name_2_lang
• ns:name[3]/gn:GeographicalName/gn:spelling[1]/gn:SpellingOfName/gn:text → name_3
• ns:name[3]/gn:GeographicalName/gn:language → name_3_lang

Reduce LocalisedCharacterStrings to three text values with language information

Every property that contains an unlimited number of values of the type LocalisedCharacterString is reduced to three text and language attributes, e.g.:

• au:nationalLevelName[1]/gmd:LocalisedCharacterString → nationalLevel_name_1
• au:nationalLevelName[1]/gmd:LocalisedCharacterString/@locale → nationalLevel_name_1_lang
• au:nationalLevelName[2]/gmd:LocalisedCharacterString → nationalLevel_name_2
• au:nationalLevelName[2]/gmd:LocalisedCharacterString/@locale → nationalLevel_name_2_lang
• au:nationalLevelName[3]/gmd:LocalisedCharacterString → nationalLevel_name_3
• au:nationalLevelName[3]/gmd:LocalisedCharacterString/@locale → nationalLevel_name_3_lang

Ignore nil/void values

Properties that are nil (@xsi:nil="true", with or without a @nilReason attribute) are ignored in the transformation as ArcGIS does not have a means to distinguish between attribute values that are not known and cases where it is known that an attribute has no value.

Ignore selected XML attributes

In references to code list values, only the value itself is used in the transformation. Other information in the property is ignored.

Suppress unused properties

If properties are never provided in the source datasets, they are suppressed entirely in the implementation schema as they would never carry a value anyhow.

This includes association roles between feature types that are not provided in the source data, too.

Represent relationships

Relationships between feature types that are included in the source datasets are in general implemented as relationship classes in the implementation schema (but see also the next section).

Example: the upperLevelUnit relationship role for AdministrativeUnit features.

Note: Unlike ArcGIS, GeoJSON has no concept of relationships.

Resolve relationships through merging

If a feature type in a relationship does not own a geometry and can be reduced to one or several properties of another feature type, the relationship is resolved by merging the two feature types in the implementation schema.

An example is the networkRef relationship role between RailwayElectrification (or any other of the TransportProperty subtypes) and RailwayLink. The electrified property of RailwayElectrification is merged into RailwayLink. The relationship as well as the RailwayElectrification feature type of INSPIRE is not part of the implementation schema.

Another example are addresses where the AddressComponent feature types are merged into the Address feature type in the implementation schema, up to three instances per component type.

Scale range fan-out

The features in the application schema were intended to be used in Web Maps in ArcGIS. It is not always feasible or desired to show all the features in every scale range. Some feature types also have properties that categorize the features into different scale ranges, like the nationalLevel for AdministrativeUnit features.

As scale dependent rendering is usually done per feature types (and not on a feature-by-feature basis), where such a scale range categorization properties could be identified, the feature type has been fanned out into multiple feature types where the name is suffixed with the level. I.e., in the AdministrativeUnit case there are six feature types in the implementation schema, AdministrativeUnit_L1 to AdministrativeUnit_L6 - each associated with different levels of zoom levels.

Coordinate transformation

Beside the schema transformations, any geometry is also converted to WGS84 and the Web Mercator projection. Web Mercator is the default Coordinate Reference System used for maps in ArcGIS and most other web mapping environments.

Alternative encoding example

Short description

Inspire Theme Addresses.

Address data for the Dutch Address key-register.
Not harmonized with Inpsire.

Example instance

https://geodata.nationaalgeoregister.nl/bag/wfs?request=GetFeature&service=WFS&typeName=bag:verblijfsobject&outputFormat=json&srsName=EPSG:4326&count=1&version=2.0.0

Sources

Please describe/list the sources of data used in this example.

Underlying (INSPIRE) conceptual model

If the encoding is implementing a conceptual model (e.g. from INSPIRE), please provide
details and/or a reference to the conceptual model (e.g. the relevant INSPIRE application
schema) here.

Purpose & use

• Dutch key register. Alternative to GML

Used simplification rules

• Does the encoding example have special rules (e.g. for codelists, voidable elements,
  specific (complex) types, complex structures in general, etc.)?

Additional information

This is an optional section for additional information, e.g.

• Are there known limitations or issues with the encoding?
• What enhancements would you like to do to the example?
• What do you consider to be the best aspects/characteristics of this example?
• What clients or other software was this encoding tested with? What were the results?

Simplified encoding example

Short description

OS OpenNames extends INSPIRE GN, adding a number of attributes for 'outward pointing links' to other datasets. We believe this makes it easier to use in gazetteers & other situations, by providing explicit support to refine results of string matching: is this the 'Kingston' in Humberside, or Surrey?

Example instance

https://www.ordnancesurvey.co.uk/opendatadownload/products.html#OPNAME

Purpose & use

Used in the OS Names API, which in turn is used by websites to provide gazetteer functionality.

Case study: https://www.ordnancesurvey.co.uk/business-and-government/case-studies/iow-ambulance-dispatch.html

Used simplification rules

"simplification by extension" - i.e. extra attributes to support a common use case

Achieved this by importing & extending the UML models, and then using ShapeChange

Additional information

Also available in RDF at http://data.os.uk/datasets/opennames

Alternative encoding example

Short description

The purpose of the O&M Simple Feature encodings (OMSF) is to define an easily digestible data formats for data conformant to the Observations and measurement standard (O&M, ISO 19156:2011), and thus enable interoperable O&M data exchange between existing software applications, servers and clients limited to using simple (non-complex) GML features and/or GeoJSON.

There are two twin encoding formats based on GML Simple Features Profile 2.0 (OGC 10-100r3) and GeoJSON (IETF RFC 7946) with almost identical property names and semantics adapted to the conventions and technical possibilities of the mentioned specifications:

• https://github.com/opengeospatial/omsf-profile/tree/master/omsf-gml
• https://github.com/opengeospatial/omsf-profile/tree/master/omsf-json

Example instance (GML)

<omsf:MeasureObservation gml:id="f-1">
  <gml:identifier codeSpace="fmi-fi-weatherobs">kumpula-2017-08-17_12-00_air-temp-1</gml:identifier>
  <omsf:phenomenonTime>2017-08-17T12:00:00Z</omsf:phenomenonTime>
  <omsf:resultTime>2017-08-17T12:01:25Z</omsf:resultTime>
  <omsf:usedProcedure
    xlink:href="http://xml.fmi.fi/process/met-surface-observations"
    xlink:title="Meteorological surface observations" />
  <omsf:observedProperty
    xlink:href="http://vocab.nerc.ac.uk/collection/P07/current/CFSN0023/air_temperature"
    xlink:title="air_temperature" />
  <omsf:samplingFeatureName>Helsinki Kumpula weather observation station</omsf:samplingFeatureName>
  <omsf:geometry>
      <gml:Point gml:id="p-1" srsName="http://www.opengis.net/def/crs/EPSG/0/4258" srsDimension="2">
          <gml:pos>60.20307 24.96131</gml:pos>
      </gml:Point>
  </omsf:geometry>
  <omsf:ultimateFeatureOfInterestName>Helsinki Kumpula</omsf:ultimateFeatureOfInterestName>
  <omsf:ultimateFeatureOfInterestReference xlink:href="http://sws.geonames.org/843429/about.rdf"/>
  <omsf:result uom="Cel">12.5</omsf:result>
</omsf:MeasureObservation>

Example instance (GeoJSON)

{
  "type": "Feature",
  "id": "f-1",
  "geometry": {
    "type": "Point",
    "coordinates": [ 24.96131, 60.20307 ]
  },
  "properties": {
    "observationType": "MeasureObservation",
    "phenomenonTime": "2017-08-17T12:00:00Z",
    "resultTime": "2017-08-17T12:01:25Z",
    "usedProcedureName": "Meteorological surface observations",
    "usedProcedureReference": "http://xml.fmi.fi/process/met-surface-observations",
    "observedPropertyName": "air_temperature",
    "observedPropertyReference": "http://vocab.nerc.ac.uk/collection/P07/current/CFSN0023/",
    "samplingFeatureName": "Helsinki Kumpula weather observation station",
    "ultimateFeatureOfInterestName": "Helsinki Kumpula",
    "ultimateFeatureOfInterestReference": "http://sws.geonames.org/843429/about.rdf",
    "result": 12.5,
    "unitOfMeasureName": "Degree Celsius",
    "unitOfMeasureReference": "http://www.opengis.net/def/uom/UCUM/degC"
  }
}

Sources

The above examples are fictional meteorological temperature observations.

Underlying (INSPIRE) conceptual model

The encoding is base on the conceptual model of Observation as described by Observations and measurement standard (ISO 19156:2011), which is the basis of the D2.9 "Draft Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE Annex II and III data specification development". It is applicable to encoding of Observation features in INSPIRE themes AC-MF, OF, Geology, Environmental monitoring facilities and Soil.

Purpose & use

The main purpose of this encoding is publishing point and point time series observation and forecast data in a format that is directly accessible/readable with typical, off-the-self GIS software and libraries. It combines the conceptual model and well-known property names and semantics of the O&M standard with the technical simplicity of the plain GeoJSON Features (IETF RFC 7946). As with ISO 19156:2011, the use cases of the OMSF JSON encoding cover any measured or estimated quantitative information.

OMSF encodings were originally developed for encoding meteorological observation and forecast data to be published using OGC Web Feature Service (WFS) Download Services. These encodings make it possible to use non-INSPIRE specific, generic GIS software and software libraries for reading data conformant with the O&M conceptual model. Data conversions between other O&M data encodings, such as the Observations and Measurement - XML encoding (OGC 10-025r1), are relatively straight-forward, as the mappings between the O&M conceptual model attributes and the GML & GeoJSON encoding properties have been explicitly defined.

Both encodings are optimized for providing simple, near-flat data structures with additional information externally linkable.

Used simplification rules

• Geometry property of the OMFS Observation is the geometry of the sampling feature of the Observation event, or if no sampling feature is defined the geometry of the ultimate feature of interest. This ensures that each defined Observation feature type has a relevant geometry property for spatial processing and map visualization purposes.
• Properties with time period values have been encoded as two date-time valued properties with "Start" and "End" prefixed property names.
• Properties that have a complex structure in ISO 19156 conceptual model have been mostly encoded with a two separate properties: a name suitable for end-user display, and a reference with a URL link to a complete external resource.

Additional information

• Observations with coverage valued results are only supported by linking the entire result externally.
• Type of the Observation result depends on the sub-type of the OMSF Observation (GenericObservation, MeasureObservation, CategoryObservation, CountObservation, TruthObservation and MeasureTimeseriesObservation).
• The best aspect of these encodings is the compatibility with the existing GIS software.
• Extensive client testing of OMSF encodings is part of the on-going SOFP project. Preliminary tests with have been done with QGIS and and GDAL, and compatibility should be good with other tools too since the encodings comply to well-known GIS specifications (GeoJSON and GML Simple Features Profile 2.0).
• There is an on-going Open Source project for creating a proof-of-concept WFS3 server delivering OMSF encoded data see https://github.com/vaisala-oss/sofp-core. The project is funded by Vaisala and the Finnish Meteorological Institute.

Please use this issue to propose sample INSPIRE data sets, themes and/or use cases that we should consider in the action to develop examples of the proposed GeoJSON encoding and simplification rules.

These examples should serve to prototype and test the proposed approaches, to focus our discussion and to illustrate the proposed approaches in the GP documents.

Where possible, please also include (pointers to) open sample data that can be re-used.

Alternative encoding example

Short description

Example including profiling, model transformation and different encoding for certain properties with types from the Base Types 2 application schema.

Encoding format: XML

Thematic domain: Area Management Restriction and Regulation Zones (AM)

Example instance

<?xml version="1.0" encoding="UTF-8"?>
<gml:FeatureCollection
  xmlns:am="http://inspire.ec.europa.eu/schemas/am/4.0/alternative"
  xmlns:base="http://inspire.ec.europa.eu/schemas/base/3.3"
  xmlns:base2="http://inspire.ec.europa.eu/schemas/base2/2.0"
  xmlns:eli="http://data.europa.eu/eli/ontology#"
  xmlns:gml="http://www.opengis.net/gml/3.2"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:xml="http://www.w3.org/XML/1998/namespace"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://inspire.ec.europa.eu/schemas/am/4.0/alternative AreaManagementRestrictionRegulationZone.xsd"
  gml:id="id.af444cbf-ee85-40cf-8fec-b46280d20dff"
>
  <gml:featureMember>
    <am:ManagementRestrictionOrRegulationZone gml:id="id.6d1859e1-a144-42af-8ce7-05467e89d6b6">
      <am:inspireId>
        <base:Identifier>
          <base:localId>1234567890</base:localId>
          <base:namespace>https://geo.data.gov.dk/dataset/fc2571be-15cf-4c38-9a6c-9618266cb7e9</base:namespace>
        </base:Identifier>
      </am:inspireId>
      <am:thematicId>
        <base2:ThematicIdentifier>
          <base2:identifier>100016454</base2:identifier>
          <base2:identifierScheme>TemafladeID</base2:identifierScheme>
        </base2:ThematicIdentifier>
      </am:thematicId>
      <am:name_1 xml:lang="da">Et dansk navn</am:name_1>
      <am:name_2 xml:lang="en">A name in English</am:name_2>
      <am:geometry>
        <gml:Polygon
          srsName="http://www.opengis.net/def/crs/EPSG/0/25832"
          gml:id="id.6d1859e1-a144-42af-8ce7-05467e89d6b6.geom"
        >
          <gml:exterior>
            <gml:LinearRing>
              <gml:posList srsDimension="2">517452.333 6114185.527 517445.592 6114139.783 517470.845 6114171.731 517602.127 6114082.484 517623.259 6114200.763 517623.395 6114201.525 517601.806 6114217.231 517526.781 6114272.38 517471.161 6114313.669 517460.067 6114238.913 517452.333 6114185.527</gml:posList>
            </gml:LinearRing>
          </gml:exterior>
        </gml:Polygon>
      </am:geometry>
      <am:zoneType
        xlink:href="http://inspire.ec.europa.eu/codelist/ZoneTypeCode/forestManagementArea"
        xlink:title="forest management area" />
      <am:designationPeriod>
        <gml:TimePeriod gml:id="id.04f315bb-20f2-4cd8-93c0-a5f68a838434">
          <gml:begin>
            <gml:TimeInstant gml:id="id.d771d41a-59ba-473e-a6c4-01963dfef431">
              <gml:timePosition>2001-01-03</gml:timePosition>
            </gml:TimeInstant>
          </gml:begin>
          <gml:endPosition indeterminatePosition="now" />
        </gml:TimePeriod>
      </am:designationPeriod>
      <am:environmentalDomain
        xlink:href="http://inspire.ec.europa.eu/codelist/EnvironmentalDomain/naturalResources"
        xlink:title="natural resources" />
      <am:competentAuthority
        xlink:href="https://datacvr.virk.dk/data/visenhed?enhedstype=virksomhed&amp;id=62965916"
        xlink:title="Geodatastyrelsen" />
      <am:beginLifespanVersion>2018-06-03T17:03:03.488344000</am:beginLifespanVersion>
      <am:legalBasis
        xlink:href="http://www.retsinformation.dk/eli/lta/2017/122"
        xlink:title="Bekendtgørelse af lov om skove" />
      <am:plan
        xlink:href="http://link.to.plan.dk"
        xlink:title="A plan" />
    </am:ManagementRestrictionOrRegulationZone>
  </gml:featureMember>
</gml:FeatureCollection>

Sources

Based on a feature of a Danish AM dataset, with modifications and additions to illustrate aspects of the encoding.

Underlying (INSPIRE) conceptual model

Area Management Restriction and Regulation Zones.

Purpose & use

It is an example developed for this 2017.2 action.

It assumes that for GeographicalName, the name itself and the language is enough information.

It assumes that information regarding legal texts, documents and authorities is stored in an external register or other online application, not necessary using GML, possibly other standardised encodings, and that that information be referred to from a GML application schema "by reference".

It gives extra, unnecessary work for data providers when they have to document a lot of metadata regarding laws, documents, authorities, etc. that they are not responsible for, especially when this information is already online somewhere else. Therefore, properties referring to laws, documents, authorities should be implemented by reference, and it should be recognised that the values are not necessarily encoded in GML, as they come from other domains than the geographic information domain.

Work done in other initiatives such as the ISA2 action regarding the European Legislation Identifier (ELI), https://ec.europa.eu/isa2/actions/facilitating-exchange-legislation-data-europe_en , can be reused in INSPIRE in this way.

Used simplification rules

• Profiling: only a certain amount of properties of class ManagementRestrictionOrRegulationZone are included.
• Multiplicity is flattened.
• GeographicalName is encoded by means of gmlxbt:LanguageStringType , so only the name itself and the language are present in the encoding.
• Referencing is limited to referencing by value for certain attributes: #56
• The target element type is changed for legalBasis: the type should be eli:LegalResource (namespace http://data.europa.eu/eli/ontology#) instead of LegislationCitation.
• No target element type is stated for plan and competentAuthority (originally: DocumentCitation and RelatedParty).

Note that flattening of data types is not used. If it had been used, inspireId and thematicId would be have flattened to e.g. inspireId.localId, inspireId.namespace, thematicId.identifier and thematicId.identifierScheme (present in a new GML application schema for Bases Types 2). However, nested structures would still have been present because of the designation period.

      <am:designationPeriod>
        <gml:TimePeriod gml:id="id.04f315bb-20f2-4cd8-93c0-a5f68a838434">
          <gml:begin>
            <gml:TimeInstant gml:id="id.d771d41a-59ba-473e-a6c4-01963dfef431">
              <gml:timePosition>2001-01-03</gml:timePosition>
            </gml:TimeInstant>
          </gml:begin>
          <gml:endPosition indeterminatePosition="now" />
        </gml:TimePeriod>
      </am:designationPeriod>

The ShapeChange configuration used is:

<?xml version="1.0" encoding="UTF-8"?>
<ShapeChangeConfiguration xmlns:xi="http://www.w3.org/2001/XInclude" xmlns="http://www.interactive-instruments.de/ShapeChange/Configuration/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.interactive-instruments.de/ShapeChange/Configuration/1.1 http://shapechange.net/resources/schema/ShapeChangeConfiguration.xsd">
  <input>
    <parameter name="inputFile" value="$myInputFile$" />
    <parameter name="appSchemaNameRegex" value="(Area Management Restriction and Regulation Zones)" />
    <parameter name="publicOnly" value="true" />
    <parameter name="addTaggedValues" value="*" />
    <parameter name="extractSeparator" value="--" />
		<!--  -->
    <parameter name="checkingConstraints" value="enabled" />
    <parameter name="inputModelType" value="EA7" />
    <parameter name="folConstraintTypeRegex" value="" />
    <parameter name="loadGlobalIdentifiers" value="true" />
    <parameter name="oclConstraintTypeRegex" value="" />
    <parameter name="sortedOutput" value="true" />
    <parameter name="sortedSchemaOutput" value="true" />
    <xi:include href="http://shapechange.net/resources/config/DescriptorSourcesInspire.xml" />
    <xi:include href="http://shapechange.net/resources/config/StandardAliases.xml" />
  </input>
  <log>
    <parameter name="reportLevel" value="INFO" />
    <parameter name="logFile" value="log/report.xml" />
  </log>
  <transformers>
    <Transformer class="de.interactive_instruments.ShapeChange.Transformation.Identity.IdentityTransform" mode="enabled" id="transformerAddTaggedValues">
      <taggedValues>
        <TaggedValue name="profiles" value="myprofile" modelElementType="Class" modelElementName="ManagementRestrictionOrRegulationZone" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Class" modelElementName="EnvironmentalDomain" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Class" modelElementName="ZoneTypeCode" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="inspireId" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="geometry" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="zoneType" />
        <TaggedValue name="maxOccurs" value="1" modelElementType="Attribute" modelElementName="zoneType" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="environmentalDomain" />
        <TaggedValue name="maxOccurs" value="1" modelElementType="Attribute" modelElementName="environmentalDomain" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="thematicId" />
        <TaggedValue name="maxOccurs" value="1" modelElementType="Attribute" modelElementName="thematicId" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="name" />
        <TaggedValue name="maxOccurs" value="3" modelElementType="Attribute" modelElementName="name" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="designationPeriod" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="competentAuthority" />
        <TaggedValue name="maxOccurs" value="1" modelElementType="Attribute" modelElementName="competentAuthority" />
        <TaggedValue name="inlineOrByReference" value="byReference" modelElementType="Attribute" modelElementName="competentAuthority" />
        <TaggedValue name="xsdEncodingRule" value="external_ref" modelElementType="Attribute" modelElementName="competentAuthority" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="beginLifespanVersion" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="Attribute" modelElementName="endLifespanVersion" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="AssociationRole" modelElementName="legalBasis" />
        <TaggedValue name="maxOccurs" value="1" modelElementType="AssociationRole" modelElementName="legalBasis" />
        <TaggedValue name="inlineOrByReference" value="byReference" modelElementType="AssociationRole" modelElementName="legalBasis" />
        <TaggedValue name="profiles" value="myprofile" modelElementType="AssociationRole" modelElementName="plan" />
        <TaggedValue name="maxOccurs" value="1" modelElementType="AssociationRole" modelElementName="plan" />
        <TaggedValue name="inlineOrByReference" value="byReference" modelElementType="AssociationRole" modelElementName="plan" />
        <TaggedValue name="xsdEncodingRule" value="external_ref" modelElementType="AssociationRole" modelElementName="plan" />
      </taggedValues>
    </Transformer>
    <Transformer mode="enabled" class="de.interactive_instruments.ShapeChange.Transformation.Profiling.Profiler" id="profiler" input="transformerAddTaggedValues">
      <parameters>
        <ProcessParameter name="profiles" value="myprofile" />
      </parameters>
      <rules>
        <ProcessRuleSet name="profiler">
          <rule name="rule-trf-profiling-preprocessing-profilesValueConsistencyCheck" />
          <rule name="rule-trf-profiling-preprocessing-modelConsistencyCheck" />
          <rule name="rule-trf-profiling-postprocessing-removeEmptyPackages" />
          <rule name="rule-trf-profiling-processing-explicitProfileSettings" />
          <rule name="rule-trf-profiling-processing-classRemovalIncludesAllSubtypes" />
        </ProcessRuleSet>
      </rules>
    </Transformer>
    <Transformer mode="enabled" class="de.interactive_instruments.ShapeChange.Transformation.Flattening.Flattener" id="flattener" input="profiler">
      <parameters>
        <ProcessParameter name="targetNamespaceSuffix" value="/alternative" />
      </parameters>
      <rules>
        <ProcessRuleSet name="flattenrules">
          <rule name="rule-trf-prop-flatten-multiplicity"/>
        </ProcessRuleSet>
      </rules>
    </Transformer>
  </transformers>
  <targets>
    <TargetXmlSchema mode="enabled" class="de.interactive_instruments.ShapeChange.Target.XmlSchema.XmlSchema" inputs="flattener">
      <targetParameter name="basicTypeStyle" value="GLOBAL" />
      <targetParameter name="defaultEncodingRule" value="iso19136_2007_INSPIRE_Extensions" />
      <targetParameter name="enumStyle" value="GLOBAL" />
      <targetParameter name="gmlVersion" value="3.2" />
      <targetParameter name="noGMLtypeDefault" value="false" />
      <targetParameter name="outputDirectory" value="GML" />
      <targetParameter name="processOutput_modifyFileName" value="false" />
      <targetParameter name="schematron" value="false" />
      <targetParameter name="schematronExtension.matches.function" value="matches($object$, $pattern$)" />
      <targetParameter name="schematronExtension.matches.namespace" value="http://www.w3.org/2005/xpath-functions" />
      <targetParameter name="sortedOutput" value="true" />
      <targetParameter name="supportWSDL" value="false" />
      <xi:include href="http://shapechange.net/resources/config/StandardRules.xml" />
      <rules>
        <EncodingRule name="external_ref" extends="*">
          <!-- EncodingRule without rule-xsd-prop-targetElement -->
          <rule name="rule-xsd-cls-standard-gml-property-types" />
          <rule name="rule-xsd-prop-inlineOrByReference" />
          <rule name="rule-xsd-prop-nillable" />
        </EncodingRule>
      </rules>
      <xi:include href="http://shapechange.net/resources/config/StandardNamespaces.xml" />
      <xmlNamespaces>
		<!-- INSPIRE namespaces -->
        <XmlNamespace ns="http://inspire.ec.europa.eu/schemas/am/4.0" nsabr="am" />
        <XmlNamespace ns="http://inspire.ec.europa.eu/schemas/gn/4.0" nsabr="gn" location="http://inspire.ec.europa.eu/schemas/gn/4.0/GeographicalNames.xsd" />
        <XmlNamespace ns="http://inspire.ec.europa.eu/schemas/cvbase/1.0" nsabr="cvbase" location="http://inspire.ec.europa.eu/schemas/cvbase/1.0/CoverageBase.xsd" />
        <XmlNamespace ns="http://www.opengis.net/gmlcov/1.0" nsabr="gmlcov" location="http://www.opengis.net/gmlcov/1.0/http://schemas.opengis.net/gmlcov/1.0/coverage.xsd" />
        <XmlNamespace ns="http://inspire.ec.europa.eu/schemas/net/4.0" nsabr="net" location="http://inspire.ec.europa.eu/schemas/net/4.0/Network.xsd" />
        <XmlNamespace ns="http://inspire.ec.europa.eu/schemas/base/3.3" nsabr="base" location="http://inspire.ec.europa.eu/schemas/base/3.3/BaseTypes.xsd" />
        <XmlNamespace ns="http://inspire.ec.europa.eu/schemas/base2/2.0" nsabr="base2" location="http://inspire.ec.europa.eu/schemas/base2/2.0/BaseTypes2.xsd" />
		<!-- non-INSPIRE namespaces -->
        <XmlNamespace nsabr="eli" ns="http://data.europa.eu/eli/ontology#" location="http://publications.europa.eu/mdr/resource/eli/eli_xml/elixml-v2.xsd" />
      </xmlNamespaces>
      <xi:include href="http://shapechange.net/resources/config/StandardMapEntries.xml" />
      <xsdMapEntries>
        <XsdMapEntry type="URI" xsdEncodingRules="gml33" xmlPropertyType="anyURI" xmlType="anyURI" xmlTypeType="simple" xmlTypeContent="simple" />
		<!-- Map GeographicalName to a type only containing a text and the language of that text. -->
        <XsdMapEntry type="GeographicalName" xsdEncodingRules="gml33" xmlPropertyType="gmlxbt:LanguageStringType" />
        <!-- xmlPropertyType="gml:ReferenceType" only possible when value by reference, bit of a hack maybe, but necessary in order to get the desired GML application schema -->
        <XsdMapEntry type="LegislationCitation" xsdEncodingRules="iso19136_2007_INSPIRE_Extensions" xmlElement="eli:LegalResource" xmlType="eli:LegalResourceType" xmlPropertyType="gml:ReferenceType" />
        <XsdMapEntry type="DocumentCitation" xsdEncodingRules="iso19136_2007_INSPIRE_Extensions" xmlPropertyType="gml:ReferenceType" />
        <XsdMapEntry type="RelatedParty" xsdEncodingRules="iso19136_2007_INSPIRE_Extensions" xmlPropertyType="gml:ReferenceType" />
      </xsdMapEntries>
    </TargetXmlSchema>
  </targets>
</ShapeChangeConfiguration>

The resulting GML application schema is

<?xml version="1.0" encoding="UTF-8"?><schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:am="http://inspire.ec.europa.eu/schemas/am/4.0/alternative" xmlns:base="http://inspire.ec.europa.eu/schemas/base/3.3" xmlns:base2="http://inspire.ec.europa.eu/schemas/base2/2.0" xmlns:eli="http://data.europa.eu/eli/ontology#" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gmlexr="http://www.opengis.net/gml/3.3/exr" xmlns:gmlxbt="http://www.opengis.net/gml/3.3/xbt" xmlns:gn="http://inspire.ec.europa.eu/schemas/gn/4.0" elementFormDefault="qualified" targetNamespace="http://inspire.ec.europa.eu/schemas/am/4.0/alternative" version="4.0">
  <annotation>
    <documentation>area management restriction and regulation zones: The Area Management Restriction and Regulation Zones application schema contains the spatial object that represents zones or areas established to protect the environment via management, restriction or regulation.</documentation>
  </annotation>
  <import namespace="http://data.europa.eu/eli/ontology#" schemaLocation="http://publications.europa.eu/mdr/resource/eli/eli_xml/elixml-v2.xsd"/>
  <import namespace="http://inspire.ec.europa.eu/schemas/base/3.3" schemaLocation="http://inspire.ec.europa.eu/schemas/base/3.3/BaseTypes.xsd"/>
  <import namespace="http://inspire.ec.europa.eu/schemas/base2/2.0" schemaLocation="http://inspire.ec.europa.eu/schemas/base2/2.0/BaseTypes2.xsd"/>
  <import namespace="http://inspire.ec.europa.eu/schemas/gn/4.0" schemaLocation="http://inspire.ec.europa.eu/schemas/gn/4.0/GeographicalNames.xsd"/>
  <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
  <import namespace="http://www.opengis.net/gml/3.3/exr" schemaLocation="http://schemas.opengis.net/gml/3.3/extdEncRule.xsd"/>
  <import namespace="http://www.opengis.net/gml/3.3/xbt" schemaLocation="http://schemas.opengis.net/gml/3.3/extdBaseTypes.xsd"/>
  <!--XML Schema document created by ShapeChange - http://shapechange.net/-->
  <element name="ManagementRestrictionOrRegulationZone" substitutionGroup="gml:AbstractFeature" type="am:ManagementRestrictionOrRegulationZoneType">
    <annotation>
      <documentation>management restriction or regulation zone: Area managed, restricted or regulated in accordance with a legal requirement related to an environmental policy or a policy or activity that may have an impact on the environment at any level of administration (or used for reporting at international, European, national, regional and local) levels.</documentation>
    </annotation>
  </element>
  <complexType name="ManagementRestrictionOrRegulationZoneType">
    <complexContent>
      <extension base="gml:AbstractFeatureType">
        <sequence>
          <element name="inspireId" type="base:IdentifierPropertyType">
            <annotation>
              <documentation>inspireID: External object identifier of the spatial object.
NOTE An external object identifier is a unique object identifier published by the responsible body, which may be used by external application to reference the spatial object. The identifier is an identifier of the spatial object, not an identifier of the real-world phenomenon.

NOTE: ManagementRestrictionOrRegulationZone spatial objects commonly perform the role/function of &lt;i&gt;"Reporting Unit"&lt;/i&gt; for non-spatial reported data. The reported data shall contain object references to ManagementRestrictionOrRegulationZones. Therefore, all spatial objects shall be assigned an inspireID.</documentation>
            </annotation>
          </element>
          <element minOccurs="0" name="thematicId" nillable="true">
            <annotation>
              <documentation>thematic identifier: Descriptive unique object identifier applied to spatial objects in a defined information theme.
NOTE Some management, restriction or regulation zones may be assigned multiple thematic identifiers. These may have been established to meet the reporting requirements of different legislative instruments at International, European or at Member State levels.  

Where multiple thematicIDs exist all should be provided. This shall allow any external dataset that uses thematicIDs to referencing to the zone to continue to be linked to the spatial object.</documentation>
            </annotation>
            <complexType>
              <sequence>
                <element ref="base2:ThematicIdentifier"/>
              </sequence>
              <attribute name="nilReason" type="gml:NilReasonType"/>
            </complexType>
          </element>
          <element minOccurs="0" name="name_1" nillable="true" type="gmlxbt:LanguageStringType">
            <annotation>
              <documentation>name_1: A geographical name that is used to identify the management, restriction or  regulation zone in the real world. It provides a 'key' for implicitly associating different representations of the object.</documentation>
            </annotation>
          </element>
          <element minOccurs="0" name="name_2" nillable="true" type="gmlxbt:LanguageStringType">
            <annotation>
              <documentation>name_2: A geographical name that is used to identify the management, restriction or  regulation zone in the real world. It provides a 'key' for implicitly associating different representations of the object.</documentation>
            </annotation>
          </element>
          <element minOccurs="0" name="name_3" nillable="true" type="gmlxbt:LanguageStringType">
            <annotation>
              <documentation>name_3: A geographical name that is used to identify the management, restriction or  regulation zone in the real world. It provides a 'key' for implicitly associating different representations of the object.</documentation>
            </annotation>
          </element>
          <element name="geometry" type="gml:GeometryPropertyType">
            <annotation>
              <documentation>The geometry representing the spatial extent of the spatial object.
NOTE The geometry of a Management Area, Restriction or Regulation Zone can be defined using any geometry representation. Typically this shall be either a GM_Surface or GM_MultiSurface. 

NOTE: Where a zone forms as a polygon, this should be encoded as a GM_Surface or GM_MultiSurface not a GM_Curve.</documentation>
            </annotation>
          </element>
          <element name="zoneType" type="gml:ReferenceType">
            <annotation>
              <documentation>zone type: High level classification defining the type of management, restriction or regulation zone.</documentation>
              <appinfo>
                <targetCodeList xmlns="http://www.opengis.net/gml/3.3/exr">ZoneTypeCode</targetCodeList>
              </appinfo>
            </annotation>
          </element>
          <element name="designationPeriod" nillable="true" type="gml:TimePeriodPropertyType">
            <annotation>
              <documentation>designation period: Time period defining when the management, restriction or regulation zone was legally designated or became effective in the real world.
NOTE NOTE: designationPeriod uses the ISO 19108 TM_Period which is comprised of two properties - gml:beginPosition and gml:endPosition. 
If the zone shall remain in force for an indeterminate period of time then the endPosition/indeterminatePosition="unknown" can be used to state that the zone is still effective.</documentation>
            </annotation>
          </element>
          <element name="environmentalDomain" type="gml:ReferenceType">
            <annotation>
              <documentation>environmental domain: Classification of the environment domain(s) for which, through the establishment of the zone, certain environmental objectives shall be reached.
NOTE A zone may be established within one environmental domain (e.g. water) or may to cover a wide range of environmental objectives that cross-cut several domains. For example, Marine Regions may relate to water,  land use, sustainable development.</documentation>
              <appinfo>
                <targetCodeList xmlns="http://www.opengis.net/gml/3.3/exr">EnvironmentalDomain</targetCodeList>
              </appinfo>
            </annotation>
          </element>
          <element name="competentAuthority" nillable="true" type="gml:ReferenceType">
            <annotation>
              <documentation>competent authority: Description of the organisation(s) responsible for managing, restricting or regulating measures or activities within the zone.</documentation>
            </annotation>
          </element>
          <element name="beginLifespanVersion" nillable="true">
            <annotation>
              <documentation>begin lifespan version: Date and time at which this version of the spatial object was inserted or changed in the spatial data set.</documentation>
            </annotation>
            <complexType>
              <simpleContent>
                <extension base="dateTime">
                  <attribute name="nilReason" type="gml:NilReasonType"/>
                </extension>
              </simpleContent>
            </complexType>
          </element>
          <element minOccurs="0" name="endLifespanVersion" nillable="true">
            <annotation>
              <documentation>end lifespan version: Date and time at which this version of the spatial object was superseded or retired in the spatial data set.</documentation>
            </annotation>
            <complexType>
              <simpleContent>
                <extension base="dateTime">
                  <attribute name="nilReason" type="gml:NilReasonType"/>
                </extension>
              </simpleContent>
            </complexType>
          </element>
          <element name="legalBasis" nillable="true" type="gml:ReferenceType">
            <annotation>
              <documentation>Reference to, or citation of the legal instrument or document that required the establishment of the zone.</documentation>
              <appinfo>
                <targetElement xmlns="http://www.opengis.net/gml/3.2">eli:LegalResource</targetElement>
              </appinfo>
            </annotation>
          </element>
          <element minOccurs="0" name="plan" nillable="true" type="gml:ReferenceType">
            <annotation>
              <documentation>Reference to, or citation of a plan (management or action plan) that describes the environmental objectives and measures that shall be undertaken in the zone to protect the environment.</documentation>
            </annotation>
          </element>
        </sequence>
      </extension>
    </complexContent>
  </complexType>
  <complexType name="ManagementRestrictionOrRegulationZonePropertyType">
    <sequence minOccurs="0">
      <element ref="am:ManagementRestrictionOrRegulationZone"/>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
    <attributeGroup ref="gml:OwnershipAttributeGroup"/>
  </complexType>
</schema>

Additional information

QGIS support

When opening the file with QGIS, not all information is shown. The .gfs file that is generated by the underlying OGR library does not take all properties into account.

(Note that it is a GML file that is opened, the GML does not come a WFS, apparently QGIS does not use the OGR GML driver for GML coming fom a WFS.)

<GMLFeatureClassList>
  <GMLFeatureClass>
    <Name>ManagementRestrictionOrRegulationZone</Name>
    <ElementPath>ManagementRestrictionOrRegulationZone</ElementPath>
    <GeometryName>geometry</GeometryName>
    <GeometryElementPath>geometry</GeometryElementPath>
    <!--POLYGON-->
    <GeometryType>3</GeometryType>
    <SRSName>http://www.opengis.net/def/crs/EPSG/0/25832</SRSName>
    <DatasetSpecificInfo>
      <FeatureCount>1</FeatureCount>
      <ExtentXMin>517445.59200</ExtentXMin>
      <ExtentXMax>517623.39500</ExtentXMax>
      <ExtentYMin>6114082.48400</ExtentYMin>
      <ExtentYMax>6114313.66900</ExtentYMax>
    </DatasetSpecificInfo>
    <PropertyDefn>
      <Name>localId</Name>
      <ElementPath>inspireId|Identifier|localId</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>namespace</Name>
      <ElementPath>inspireId|Identifier|namespace</ElementPath>
      <Type>String</Type>
      <Width>68</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>identifier</Name>
      <ElementPath>thematicId|ThematicIdentifier|identifier</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>identifierScheme</Name>
      <ElementPath>thematicId|ThematicIdentifier|identifierScheme</ElementPath>
      <Type>String</Type>
      <Width>11</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_1</Name>
      <ElementPath>name_1</ElementPath>
      <Type>String</Type>
      <Width>13</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_2</Name>
      <ElementPath>name_2</ElementPath>
      <Type>String</Type>
      <Width>17</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>timePosition</Name>
      <ElementPath>designationPeriod|TimePeriod|begin|TimeInstant|timePosition</ElementPath>
      <Type>String</Type>
      <Width>10</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>beginLifespanVersion</Name>
      <ElementPath>beginLifespanVersion</ElementPath>
      <Type>String</Type>
      <Width>29</Width>
    </PropertyDefn>
  </GMLFeatureClass>
</GMLFeatureClassList>

When the .qfs file is changed manually to the one below, relevant properties are taken into account.

<GMLFeatureClassList>
  <GMLFeatureClass>
    <Name>ManagementRestrictionOrRegulationZone</Name>
    <ElementPath>ManagementRestrictionOrRegulationZone</ElementPath>
    <GeometryName>geometry</GeometryName>
    <GeometryElementPath>geometry</GeometryElementPath>
    <!--POLYGON-->
    <GeometryType>3</GeometryType>
    <SRSName>http://www.opengis.net/def/crs/EPSG/0/25832</SRSName>
    <DatasetSpecificInfo>
      <FeatureCount>1</FeatureCount>
      <ExtentXMin>517445.59200</ExtentXMin>
      <ExtentXMax>517623.39500</ExtentXMax>
      <ExtentYMin>6114082.48400</ExtentYMin>
      <ExtentYMax>6114313.66900</ExtentYMax>
    </DatasetSpecificInfo>
    <PropertyDefn>
      <Name>inspireId.localId</Name>
      <ElementPath>inspireId|Identifier|localId</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>inspireId.namespace</Name>
      <ElementPath>inspireId|Identifier|namespace</ElementPath>
      <Type>String</Type>
      <Width>68</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>thematicId.identifier</Name>
      <ElementPath>thematicId|ThematicIdentifier|identifier</ElementPath>
      <Type>Integer</Type>
    </PropertyDefn>
    <PropertyDefn>
      <Name>thematicId.identifierScheme</Name>
      <ElementPath>thematicId|ThematicIdentifier|identifierScheme</ElementPath>
      <Type>String</Type>
      <Width>11</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_1</Name>
      <ElementPath>name_1</ElementPath>
      <Type>String</Type>
      <Width>13</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_1_lang</Name>
      <ElementPath>name_1@lang</ElementPath>
      <Type>String</Type>
      <Width>2</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_2</Name>
      <ElementPath>name_2</ElementPath>
      <Type>String</Type>
      <Width>17</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>name_2_lang</Name>
      <ElementPath>name_2@lang</ElementPath>
      <Type>String</Type>
      <Width>2</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>zoneType_href</Name>
      <ElementPath>zoneType@href</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>zoneType_title</Name>
      <ElementPath>zoneType@title</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>beginDesignationPeriod</Name>
      <ElementPath>designationPeriod|TimePeriod|begin|TimeInstant|timePosition</ElementPath>
      <Type>String</Type>
      <Width>10</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>beginDesignationPeriod</Name>
      <ElementPath>designationPeriod|TimePeriod|begin|TimeInstant|timePosition</ElementPath>
      <Type>String</Type>
      <Width>10</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>beginDesignationPeriod_indeterminate</Name>
      <ElementPath>designationPeriod|TimePeriod|beginPosition@indeterminatePosition</ElementPath>
      <Type>String</Type>
      <Width>10</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>endDesignationPeriod</Name>
      <ElementPath>designationPeriod|TimePeriod|end|TimeInstant|timePosition</ElementPath>
      <Type>String</Type>
      <Width>10</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>endDesignationPeriod_indeterminate</Name>
      <ElementPath>designationPeriod|TimePeriod|endPosition@indeterminatePosition</ElementPath>
      <Type>String</Type>
      <Width>10</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>environmentalDomain_href</Name>
      <ElementPath>environmentalDomain@href</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>environmentalDomain_title</Name>
      <ElementPath>environmentalDomain@title</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>competentAuthority_href</Name>
      <ElementPath>competentAuthority@href</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>competentAuthority_title</Name>
      <ElementPath>competentAuthority@title</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>beginLifespanVersion</Name>
      <ElementPath>beginLifespanVersion</ElementPath>
      <Type>String</Type>
      <Width>29</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>endLifespanVersion</Name>
      <ElementPath>endLifespanVersion</ElementPath>
      <Type>String</Type>
      <Width>29</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>legalBasis_href</Name>
      <ElementPath>legalBasis@href</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>legalBasis_title</Name>
      <ElementPath>legalBasis@title</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>plan_href</Name>
      <ElementPath>plan@href</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
    <PropertyDefn>
      <Name>plan_title</Name>
      <ElementPath>plan@title</ElementPath>
      <Type>String</Type>
      <Width>200</Width>
    </PropertyDefn>
  </GMLFeatureClass>
</GMLFeatureClassList>

Non-GML encodings

Support for non-GML encodings can propably not be expected to be built-in in GIS clients. However, for web applications, or reporting purposes, this approach could be useful.

Apart from ELI, other initiatives such as Dublin Core may be considered within INSPIRE.

ELI

XML (http://publications.europa.eu/mdr/resource/eli/eli_xml/elixml-v2.xsd) or RDF/XML (http://publications.europa.eu/mdr/resource/eli/eli.owl).

The http://www.retsinformation.dk/eli/lta/2017/122 , when requested for RDF gives the resource below.

curl -L -H "Accept: application/rdf+xml" "http://www.retsinformation.dk/eli/lta/2017/122"

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rdf:RDF [
	<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
	<!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
	<!ENTITY xsd 'http://www.w3.org/2001/XMLSchema#'>
	<!ENTITY eli 'http://data.europa.eu/eli/ontology#'>
]>
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:eli="http://data.europa.eu/eli/ontology#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <eli:LegalResource rdf:about="http://www.retsinformation.dk/eli/lta/2017/122">
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2001/320" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2005/492" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2009/565" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2011/1114" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2015/1302" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/1001" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/1105" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/835" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/853" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/864" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/872" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/926" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/930" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/945" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/946" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/955" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2016/956" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2017/1577" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2017/776" />
    <eli:basis_for rdf:resource="http://www.retsinformation.dk/eli/lta/2018/1240" />
    <eli:changed_by rdf:resource="http://www.retsinformation.dk/eli/lta/2018/720" />
    <eli:consolidates rdf:resource="http://www.retsinformation.dk/eli/lta/2015/1577" />
    <eli:consolidates rdf:resource="http://www.retsinformation.dk/eli/lta/2016/1715" />
    <eli:date_document rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2017-01-26</eli:date_document>
    <eli:id_local rdf:datatype="http://www.w3.org/2001/XMLSchema#string">A20170012229</eli:id_local>
    <eli:in_force rdf:resource="http://data.europa.eu/eli/ontology#InForce-inForce" />
    <eli:is_realized_by rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan" />
    <eli:passed_by rdf:resource="http://www.retsinformation.dk/eli/resource/authority/passed_by#MFM" />
    <eli:relevant_for rdf:resource="http://www.retsinformation.dk/eli/resource/authority/relevant_for#INDOC" />
    <eli:transposes rdf:resource="http://data.europa.eu/eli/dir/1979/409/oj" />
    <eli:transposes rdf:resource="http://data.europa.eu/eli/dir/1992/43/oj" />
    <eli:transposes rdf:resource="http://data.europa.eu/eli/dir/2004/35/oj" />
    <eli:type_document rdf:resource="http://www.retsinformation.dk/eli/resource/authority/type_document#LBKH" />
    <eli:uri_schema rdf:resource="http://www.retsinformation.dk/{pubMedia}/{year}/{number}" />
  </eli:LegalResource>
  <eli:LegalExpression rdf:about="http://www.retsinformation.dk/eli/lta/2017/122/dan">
    <eli:is_embodied_by rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan/html" />
    <eli:is_embodied_by rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf" />
    <eli:is_embodied_by rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan/xml" />
    <eli:language rdf:resource="http://publications.europa.eu/resource/authority/language/DAN" />
    <eli:realizes rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122" />
    <eli:title rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Bekendtgørelse af lov om skove</eli:title>
    <eli:title_alternative rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Skovloven</eli:title_alternative>
    <eli:title_short rdf:datatype="http://www.w3.org/2001/XMLSchema#string">LBK nr 122 af 26/01/2017</eli:title_short>
    <eli:uri_schema rdf:resource="http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}" />
  </eli:LegalExpression>
  <eli:Format rdf:about="http://www.retsinformation.dk/eli/lta/2017/122/dan/html">
    <eli:embodies rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan" />
    <eli:format rdf:resource="http://www.iana.org/assignments/media-types/text/html" />
    <eli:legal_value rdf:resource="http://data.europa.eu/eli/ontology#LegalValue-official" />
    <eli:published_in rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Retsinformation</eli:published_in>
    <eli:uri_schema rdf:resource="http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}/{format}" />
  </eli:Format>
  <eli:Format rdf:about="http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf">
    <eli:embodies rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan" />
    <eli:format rdf:resource="http://www.iana.org/assignments/media-types/application/pdf" />
    <eli:legal_value rdf:resource="http://data.europa.eu/eli/ontology#LegalValue-definitive" />
    <eli:published_in rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Lovtidende A</eli:published_in>
    <eli:uri_schema rdf:resource="http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}/{format}" />
  </eli:Format>
  <eli:Format rdf:about="http://www.retsinformation.dk/eli/lta/2017/122/dan/xml">
    <eli:embodies rdf:resource="http://www.retsinformation.dk/eli/lta/2017/122/dan" />
    <eli:format rdf:resource="http://www.iana.org/assignments/media-types/text/xml" />
    <eli:legal_value rdf:resource="http://data.europa.eu/eli/ontology#LegalValue-official" />
    <eli:published_in rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Retsinformation</eli:published_in>
    <eli:uri_schema rdf:resource="http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}/{format}" />
  </eli:Format>
</rdf:RDF>

When requested for HTML, the following is given in the head section:

curl -L -H "Accept: text/html" "http://www.retsinformation.dk/eli/lta/2017/122

<meta id="ctl00_MetaDescription" name="description" content="LBK nr 122 af 26/01/2017 - Bekendtgørelse af lov om skove - Miljø- og Fødevareministeriet" /><meta id="ctl00_MetaKeywords" name="keywords" />
    <meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:is_realized_by' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:date_document' content='2017-01-26' datatype='xsd:date'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:type_document' resource='http://www.retsinformation.dk/eli/resource/authority/type_document#LBKH'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:passed_by' resource='http://www.retsinformation.dk/eli/resource/authority/passed_by#MFM'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:relevant_for' resource='http://www.retsinformation.dk/eli/resource/authority/relevant_for#INDOC'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:in_force' resource='eli:InForce-inForce'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:id_local' content='A20170012229' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:changed_by' resource='http://www.retsinformation.dk/eli/lta/2018/720'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:consolidates' resource='http://www.retsinformation.dk/eli/lta/2015/1577'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:consolidates' resource='http://www.retsinformation.dk/eli/lta/2016/1715'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2005/492'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2001/320'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2011/1114'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2009/565'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2015/1302'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/835'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/1001'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/926'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/930'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/853'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/864'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/945'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/946'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/872'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/955'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/956'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2016/1105'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2017/776'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2017/1577'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:basis_for' resource='http://www.retsinformation.dk/eli/lta/2018/1240'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:transposes' resource='http://data.europa.eu/eli/dir/1979/409/oj'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:transposes' resource='http://data.europa.eu/eli/dir/1992/43/oj'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:transposes' resource='http://data.europa.eu/eli/dir/2004/35/oj'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' typeof='eli:LegalResource'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122' property='eli:uri_schema' resource='http://www.retsinformation.dk/{pubMedia}/{year}/{number}'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:language' resource='http://publications.europa.eu/resource/authority/language/DAN'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:title' content='Bekendtgørelse af lov om skove' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:title_alternative' content='Skovloven' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:title_short' content='LBK nr 122 af 26/01/2017' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:is_embodied_by' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:is_embodied_by' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan/html'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:is_embodied_by' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:realizes' resource='http://www.retsinformation.dk/eli/lta/2017/122'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' typeof='eli:LegalExpression'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan' property='eli:uri_schema' resource='http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml' typeof='eli:Format'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml' property='eli:format' resource='http://www.iana.org/assignments/media-types/text/xml'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml' property='eli:published_in' content='Retsinformation' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml' property='eli:embodies' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml' property='eli:legal_value' resource='eli:LegalValue-official'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/xml' property='eli:uri_schema' resource='http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}/{format}'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/html' typeof='eli:Format'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/html' property='eli:format' resource='http://www.iana.org/assignments/media-types/text/html'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/html' property='eli:published_in' content='Retsinformation' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/html' property='eli:embodies' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/html' property='eli:legal_value' resource='eli:LegalValue-official'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/html' property='eli:uri_schema' resource='http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}/{format}'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf' typeof='eli:Format'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf' property='eli:format' resource='http://www.iana.org/assignments/media-types/application/pdf'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf' property='eli:published_in' content='Lovtidende A' datatype='xsd:string'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf' property='eli:embodies' resource='http://www.retsinformation.dk/eli/lta/2017/122/dan'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf' property='eli:legal_value' resource='eli:LegalValue-definitive'/>
<meta about='http://www.retsinformation.dk/eli/lta/2017/122/dan/pdf' property='eli:uri_schema' resource='http://www.retsinformation.dk/{pubMedia}/{year}/{number}/{language}/{format}'/>

Dublin Core

An XML encoding is available on http://dublincore.org/schemas/xmls/qdc/2008/02/11/

Idea for implementation:

<XsdMapEntry type="DocumentCitation" xsdEncodingRules="iso19136_2007_INSPIRE_Extensions" xmlElement="inspiredc:Document" xmlType="dcterms:elementOrRefinementContainer" xmlPropertyType="gml:ReferenceType" />

<?xml version="1.0" encoding="UTF-8"?>
<schema
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:gml="http://www.opengis.net/gml/3.2"
  xmlns:inspiredc="http://inspire.ec.europa.eu/schemas/dc/0.1"
  targetNamespace="http://inspire.ec.europa.eu/schemas/dc/0.1"
  elementFormDefault="qualified"
  version="0.1">

  <import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
  <import namespace="http://purl.org/dc/terms/" schemaLocation="http://dublincore.org/schemas/xmls/qdc/2008/02/11/dcterms.xsd" />

  <element name="Document" type="dcterms:elementOrRefinementContainer" />
  
  <complexType name="DocumentPropertyType">
    <sequence minOccurs="0">
      <element ref="inspiredc:Document"/>
    </sequence>
    <attributeGroup ref="gml:AssociationAttributeGroup"/>
    <attributeGroup ref="gml:OwnershipAttributeGroup"/>
  </complexType>

</schema>

<element minOccurs="0" name="plan" nillable="true" type="gml:ReferenceType">
            <annotation>
              <appinfo>
                <targetElement xmlns="http://www.opengis.net/gml/3.2">inspiredc:Document</targetElement>
              </appinfo>
            </annotation>
          </element>

GeoJSON example

Short description

City administrative bounderies.

Inspire theme: Administrative units

Example instance

General: https://www.dataplatform.nl/dataset/gemeente-wijk-en-buurtgrenzen-utrecht

Municipal boundaries city of Utrecht.
https://www.dataplatform.nl/resource/0953be2b-c979-491c-888b-3e682a662e20
https://ckan.dataplatform.nl/dataset/5713301f-c5cc-48b3-ae2a-8a107a6129f3/resource/0953be2b-c979-491c-888b-3e682a662e20/download/gemeentegrens-utrecht.geojson

Utrecht city districts
https://www.dataplatform.nl/resource/3a85bd19-6836-4e0f-8a27-bd5486632a44
https://ckan.dataplatform.nl/dataset/5713301f-c5cc-48b3-ae2a-8a107a6129f3/resource/3a85bd19-6836-4e0f-8a27-bd5486632a44/download/wijken-utrecht.geojson

Utrecht city sub disctricts
https://www.dataplatform.nl/resource/ddc3fcba-ba33-47d4-8ef8-fad31b4013bc
https://ckan.dataplatform.nl/dataset/5713301f-c5cc-48b3-ae2a-8a107a6129f3/resource/ddc3fcba-ba33-47d4-8ef8-fad31b4013bc/download/buurten-utrecht.geojson

Purpose & use

Use case: technical use case is bulk download.

Used simplification rules

Additional information

Related to the concept of flattening data structure.

We must come up with a proper (working) definition of what we mean by flattening of data structures. I suppose this can be found somewhere already or the editor can take care of it.

We usually take the different levels of simple features as levels of complexity. SF0 being the one that usually is the intended goal of a flattened data structure.

The introduction of https://github.com/INSPIRE-MIF/2017.2/blob/master/GeoJSON/specification.md currently says "The features include points (therefore addresses and locations), line strings (therefore streets, highways and boundaries), polygons (countries, provinces, tracts of land), and multi-part collections of these types."

Just like 'our' other standards, GeoJSON distinguishes between Feature Objects and Geometry Objects. "A Feature object has a member with the name "geometry". The value of the geometry member SHALL be either a Geometry object as defined above or, in the case that the Feature is unlocated, a JSON null value." (https://tools.ietf.org/html/rfc7946#section-3)

Therefore, it's better to say something like "GeoJSON Geometry Objects may be points (which can be used for features like addresses and locations), line strings (e.g. for streets, highways, boundaries), polygons (countries, provinces, tracts of land), and multi-part collections of these types."

GeoJSON example

Short description

City of The Hague Road sections
Inspire theme: Transport Networks, but according to Dutch topographical application schema

Example instance

Roadsections city of The Hague.
https://www.dataplatform.nl/dataset/3ebca230-091a-4bcd-b406-b3ef0d043176
https://ckan.dataplatform.nl/dataset/3ebca230-091a-4bcd-b406-b3ef0d043176/resource/2d02e519-2a11-4515-92e9-f3f08015507f/download/wegdelen-json.zip

Purpose & use

Use case:
technical use case: bulk download.
use case: background locational purpose

Used simplification rules

Additional information

daily update.

Some years ago we came up with a set of standard flattening rules. It was published as a guideline to help information modellers on the subject. It was part of a larger document on Geometry in UML and in GML.

Find it here: (for the Dutch speaking amongst us): https://www.geonovum.nl/uploads/documents/Geometrieinmodelengml_1.0_0.pdf

In there chapter: 5.3 Normalisatieregels

It covers the usual subjects: multiple attributes, complex datatypes and associations.

I would like to know if there are other documents on these guidelines for flattening.

Is by the way denormalisation not a better term?

GeoJSON example

https://github.com/opengeospatial/omsf-profile/tree/master/omsf-json

Short description

The purpose of this activity is to define simple encodings for the most used O&M Observation types, and thus enable interoperable O&M data exchange between existing software applications, servers and clients limited to using simple (non-complex) GML features and/or GeoJSON.

Within the INSPIRE context, the provided GeoJSON encoding could be applied to data sets at least in in themes AC-MF and OF.

Example instance

{
  "type": "Feature",
  "id": "f-1",
  "geometry": {
    "type": "Point",
    "coordinates": [ 24.96131, 60.20307 ]
  },
  "properties": {
    "observationType": "MeasureObservation",
    "phenomenonTime": "2017-08-17T12:00:00Z",
    "resultTime": "2017-08-17T12:01:25Z",
    "usedProcedureTitle": "Meteorological surface observations",
    "usedProcedureReference": "http://xml.fmi.fi/process/met-surface-observations",
    "observedPropertyTitle": "Temperature",
    "observedPropertyReference": "http://vocab.nerc.ac.uk/collection/P07/current/CFSN0023/",
    "featureOfInterestTitle": "Helsinki Kumpula",
    "featureOfInterestReference": "http://sws.geonames.org/843429/about.rdf",
    "resultValue": 10.1,
    "resultUnitOfMeasure": "Cel"
  }
}

Purpose & use

The purpose of the OMSF GML and GeoJSON encodings is to provide an standard encoding for relatively simple O&M based observation and forecast data. There is an on-going project funded by the Finnish Meteorological Institute and Vaisala to develop and test the OMSF encodings by developing a proof-of-concept WFS 3.0 server/service offering various weather and/or air quality related datasets. The OMSF encoding however is not specific to any data theme, but is applicable to any use case where the O&M data model usage is desired, but the client software cannot handle complex features.

The OMSF encodings are not yet used in operative services (as of July 2018), an open PoC service and related hackathon activities have been planned for early 2019.

Used simplification rules

The OMSF property mappings have been designed manually property by property, starting from the Observations and measurements UML model (as specified in ISO 19156:2011), and applying the most appropriate, simple encoding for each property considering the limitations of both the format requirements (GeoJSON RFC 7946) and the existing client software.

Additional information

OMSF GeoJSON encodings for the O&M UML classes OM_ComplexObservation, OM_DiscreteCoverageObservation, OM_GeometryObservation, OM_PointCoverageObservation, and OM_TemporalObservation are not provided. Thus this implementation is intentionally more limited than the one specified in the OGC Discussion Paper "Observations and Measurements – JSON implementation" (OGC Document 15-100r1) which is able to express the full O&M abstract model. However, expressing all these is possible by using the GenericObservation feature type with a remote reference to the Observation result.

This application profile does not provide encodings for the sampling feature data, as the feature of interest is only presented by it's geometry, optionally by it's name and, also optionally, by a remote reference to the description of the complete feature of interest.

Simplified encoding example

Short description

OS Open Roads - this specification extends the INSPIRE Transport Network - Roads model, with quite a few additional attributes on RoadLink, to meet customer requirements - represented by UK's Department for Transport. Also adds a feature type (MotorwayJunction).

We achieved this be creating Enterprise Architect UML models which import/extend the INSPIRE models, and then using ShapeChange to create the XSDs. We have inhouse documentation on achieving this.

The specification is at https://os.uk/docs/user-guides/os-open-roads-user-guide.pdf

The XML schema files are at: https://os.uk/xml/open/roads/1.0/OSOpenRoads.xsd

Example instance

Available at https://os.uk/opendatadownload/products.html#OPROAD

Purpose & use

The key use cases are simple mapping, and public reporting of issues (the highways authorities have 'lookups' from the Open Roads ids to the richer set in Highways)

Case study: https://os.uk/business-and-government/case-studies/south-yorkshire-passenger-transport-exectives-saves-money.html

Used simplification rules

• putting 0 to 4 road names on links

Additional information

GeoJSON example

Short description

Some of our data providers in Germany use the Geoserver default for GeoJSON output. They provide it usually in addition to GML and do not have a specific mapping.

Example instance

US:
https://geo.sv.rostock.de/inspire/us-govserv-schools/ows?service=WFS&version=2.0.0&request=GetFeature&typeNames=us-govserv-schools:GovernmentalService&outputFormat=application%2Fjson%20

Administrative Units:
https://geo.sv.rostock.de/download/opendata/gemeindeverbaende_mecklenburg-vorpommern/gemeindeverbaende_mecklenburg-vorpommern.json

http://geo5.service24.rlp.de/wfs/verwaltungsgrenzen_rp.fcgi?SERVICE=WFS&REQUEST=GetFeature&VERSION=1.1.0&typeName=gemeinde_rlp&srsName=urn:ogc:def:crs:EPSG::25832&outputFormat=application%2Fjson%3B%20subtype%3Dgeojson&FILTER=%3Cogc%3AFilter%20xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22%3E%3Cogc%3ABBOX%3E%3Cogc%3APropertyName%3EmsGeometry%3C%2Fogc%3APropertyName%3E%3Cgml%3ABox%20xmlns%3Agml%3D%22http%3A%2F%2Fwww.opengis.net%2Fgml%22%20srsName%3D%22urn%3Aogc%3Adef%3Acrs%3AEPSG%3A%3A25832%22%3E%3Cgml%3Acoordinates%20decimal%3D%22.%22%20cs%3D%22%2C%22%20ts%3D%22%20%22%3E396476.879043%2C5536231.57482%20517337.323409%2C5657092.01918%3C%2Fgml%3Acoordinates%3E%3C%2Fgml%3ABox%3E%3C%2Fogc%3ABBOX%3E%3C%2Fogc%3AFilter%3E

Soil:
https://gdi.thuenen.de/geoserver/bze1_wald/ows?typeName=bze1_wald:bze1_jrc4km&service=WFS&version=1.0.0&request=GetFeature&outputFormat=json&viewparams=thema:al_t1

Purpose & use

Used simplification rules

Additional information

GeoJSON example

Short description

City of Schiedam Monuments (buildings etc)
Inspire theme: Buildings, land use zoning, land use planning. but according to Dutch topographical application schema

Example instance

City of Schiedam Monuments
https://www.dataplatform.nl/dataset/monumenten-schiedam
https://www.dataplatform.nl/resource/94c9a26d-c8f4-47df-bbfc-160273ed13b1
https://ckan.dataplatform.nl/dataset/cc1d40ba-cada-4779-981f-ff981c9ee5f8/resource/94c9a26d-c8f4-47df-bbfc-160273ed13b1/download/monumentensdam.json

Purpose & use

Use case:
technical use case: bulk download.
use case: register of monumentes as related to legal status and zonification (land use planning)

Used simplification rules

Additional information

weekly update.

Glossary proposal

Add one or several proposals for terms and their definitions

Profile

In the context of application schema: Subset of the complete functionality and information content of an application schema.

Extension

In the context of application schema: Adding semantics and or functionality to an existing application schema.

Flattening

Simplifying a complex Application Schema model, up to the point where all complex data structures have been resolved to feature type properties whose type is either a simple type (like Integer, Boolean or CharacterString), a code list, or an enumeration. (note: the issue of multiple or singular attributes is not specifically included).
(Inspired on ShapeChange text)

GeoJSON example

Short description

City of The Hague Trees
Inspire theme: Landcover, but according to Dutch topographical application schema

Example instance

Roadsections city of The Hague.
https://www.dataplatform.nl/dataset/bomen-json
https://ckan.dataplatform.nl/dataset/d604d9bb-8c2f-4e7d-a69c-ee6102890baf/resource/85327fde-9e76-40f3-a8d4-25970896fd8f/download/bomen-json.zip

Purpose & use

Use case:
technical use case: bulk download.
use case: maintenance green area (public space), navigation, location

Used simplification rules

Additional information

This is an optional section for additional information, e.g. on known limitations or
issues.

daily update.