Annex I schema updates

On 30 April 2015, the schemas for all INSPIRE themes were updated in the INSPIRE schema repository at http://inspire.ec.europa.eu/schemas to reflect the changes have been introduced to the Annex I data models in the amendment of the Implementing Rules (Regulation (EU) no. 1253/2013) and the corresponding updated versions of the data specification Technical Guidelines.

Context

The updates of the Annex I schemas was necessary due to the following changes in the data models and encoding guidelines.

In the amendment of the Implementing Rules and the corresponding updated versions of the data specification Technical Guidelines, a number of changes have been introduced to the Annex I data models (for details, see Annex II of Commission Regulation (EU) No 1253/2013 and the updated data specifications), namely:

  1. Some candidate types and placeholders and the references to them have been removed (since they have been replaced by other types in the Annex II+III themes).
  2. Some candidate types and placeholders have been re-included in the Physical Waters package in the Hydrography theme
  3. Some references have been updated to types in Annex II+III themes
  4. Some additional sub-types of HydroObject have been created in the Sea Regions theme
  5. An additional data model has been developed for Maritime Units.
  6. One minor change of a geometry type (from GM_Surface to GM_MultiSurface) has been made in the candidate type Shore.

Furthermore, the encoding rules for the encoding of code lists were updated during the Annex II+III development process. According to the updated encoding rule, code list-valued properties are encoded using gml:ReferenceType instead of gml:CodeType.

Alternative proposals

Two alternative proposals for the update were considered: 

  • Approach 1: Backwards-compatible update: The main goal for this approach is that, where possible, any data sets and, where possible, software that have already been created according to the current schemas (v3.x) should also be valid according to the updated schemas.
  • Approach 2: Non-backwards-compatible update: The main goal for this approach is to use a methodologically clean approach for the update and to clearly communicate where there have been non-backwards-compatible changes to the data models and schemas.

Both approaches are described in detail in the attached document Alternative_approaches_Annex_I_schema_updates.pdf.

In a consultation with the MIG-T in January 2015, option 2 was unanimously preferred over option 1. However, some MS said that non backwards-compatible updates should be avoided in the future. The results of the consultation are summarised in this table.

In order to have a coherent set of schemas (including the references between them), all INSPIRE schemas (for Annexes I, II and III) had to be updated.

How long will the different versions be maintained?

It was agreed in the MIG-T that after April 2016, only the new versions of the schemas (i.e. v4.x for most schemas) will be maintained. This means that minor updates or bug fixes agreed by the MIG will only be made to the new schema versions.

How long can the old schemas still be used?

The MIG-T also discussed, for what period the usage of the old schemas is still acceptable.

Having concrete deadlines is important

  • for data providers, who need to know by when to update their harmonized INSPIRE data sets to the updated schemas,
  • for software vendors, who need to consider the deadlines in their release planning for their solutions (e.g. transformation tools or INSPIRE download services), and
  • for developers of client applications consuming INSPIRE data, who need to know how long their application need to support the previous versions of the schemas.

For the discussion about the deadlines, different types of updates were distinguished:

  • a new major version (e.g. v3.x --> v4.0), which is not backwards-compatible, i.e. existing data valid according to the older schema will no longer be valid according to the newer schema. Examples for non-backwards compatible changes include e.g. adding or removing mandatory properties or changing the types or names of existing properties;
  • a new minor version (e.g. v3.0.x --> v3.1), which is backwards-compatible, i.e. existing data valid according to the older schema will remain valid also according to the newer schema. Examples for backwards compatible changes include e.g. adding optional properties to existing types or adding new types;
  • a new bugfix version (e.g. v3.0 --> 3.0.1), which fixes an error in the schema. Bugfix versions are usually not backwards-compatible.

Based on feedback from MIG-T, the following time periods were agreed:

  • Deprecated versions should no longer be used after 2 years after a major release
  • Deprecated versions should no longer be used after 1 year after a bugfix release
  • There should not be specific deadlines for minor versions, i.e. the deprecated minor version can still be used as long as the corresponding major version may be used.

This would lead to the following schema:

It should be noted that, since the schemas are not legally required, these dates can only be recommendations.

Detailed changes (Annex I schemas)

The table below lists the detailed changes in the Annex I xml schemas. 

Application schema AS short name Old schema version New schema version Changes
Addresses.xsd ad 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • AddressComponent.status
    • AddressLocator.level
    • Address.status
    • AdminUnitName.level
    • GeographicPosition.specification
    • GeographicPosition.method
    • LocatorDesignator.type
    • LocatorName.type
    • PartOfName.type
  2. Target element of Address.building association role changed from bui:Building to bu-base:AbstractConstruction
  3. Schema imports updated to new versions for all imported schemas (au, base, bu-base, cp, gn, tn)
AdministrativeUnits.xsd au 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • AdministrativeBoundary.nationalLevel
    • AdministrativeUnit.nationalLevel
  2. Removed association role "NUTS" from AdministrativeUnits
  3. Schema imports updated to new versions for all imported schemas (base, gn)
  4. Exchanged definitions of "coAdminister" and "administeredBy" association roles
  5. Added -- Name -- tags in the documentation of all types and properties
BaseTypes.xsd base 3.2 3.3.1
  1. The SpatialDataSet, SpatialDataSetType and SpatialDataSetPropertyType elements are deprecated (in accordance with D2.7 v3.3 Recommendation 11 stating that wfs:FeatureCollection should be used instead)
  2. The (optional) SpatialDataSet.member attribute, which was accidentally removed in v3.3(.0), is re-included inside the (deprecated) SpatialDataSet element. 
CadastralParcels.xsd cp 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • CadastralZoningType.level
  2. Schema imports updated to new versions for all imported schemas (au, base, gn)
GeographicalNames.xsd gn 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • GeographicalName.nativeness
    • GeographicalName.nameStatus
    • GeographicalName.grammaticalGender
    • GeographicalName.grammaticalNumber
    • NamedPlaceType.type
HydroBase.xsd hy 3.0 4.0
  1. The HydroObjectPropertyType now only allows references to the following types:
    •   hy-p:DrainageBasin, hy-n:HydroNode, hy-p:HydroPointOfInterest, hy-p:ManMadeObject, sr:SeaArea, hy-p:Shore, sr:Shoreline, hy-p:SurfaceWater, hy-n:WatercourseLink, hy-n:WatercourseLinkSequence, hy-n:WatercourseSeparatedCrossing, hy-p:Wetland.
    • Schema imports updated to new versions for all imported schemas (gn, hy-p, hy-n, sr)
    • Schema imports removed for lc, nz, wfd
HydroNetwork.xsd hy-n 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • HydroNode.hydroNodeCategory
    • WatercourseLink.flowDirection
  2. Schema imports updated to new versions for all imported schemas (gn, hy, net)
HydroPhysicalWaters.xsd hy-p 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • Crossing.type
    • LandWaterBoundary.waterLevelCategory
    • ManMadeObject.condition
    • SurfaceWater.persistence
    • Watercourse.condition
  2. Additional elements (xxx) and types (xxxType and xxxPropertyType) for the following classes moved into this package from candidate packages:
    • Embankment (from NZ)
    • Shore (from LC)
    • Wetland (from LC)
  3. Target element of SurfaceWater.bank association role changed from lc:Shore to hy-p:Shore
  4. Schema imports updated to new versions for all imported schemas (base, gn, hy)
  5. Schema imports removed for lc
LandCover.xsd lc 0.0 -
  1. Elements (xxx) and types (xxxType and xxxPropertyType) for the following classes moved to package hy-p:
    • Shore
    • Wetland
Network.xsd net 3.2 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • LinkReference.applicableDirection
    • NetworkConnection.type
  2. Schema imports updated to new versions for all imported schemas (base, gn)
NaturalRiskZones.xsd nz 0.0 -
  1. Elements (xxx) and types (xxxType and xxxPropertyType) for the following classes moved to package hy-p:
    • Embankment
ProtectedSites.xsd ps 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • DesignationType.designationScheme
    • DesignationType.designation
  2. Changed type of percentageUnderDesignation from anyURI to decimal
  3. Schema imports updated to new versions for all imported schemas (base, gn)
CommonTransportElements.xsd tn 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • AccessRestriction.restriction
    • ConditionOfFacility.currentStatus
    • RestrictionForVehiclesType.restrictionType
    • TrafficFlowDirection.direction
  2. Schema imports updated to new versions for all imported schemas (base, gn, net)
AirTransportNetwork.xsd tn-a 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • AerodromeCategory.aerodromeCategory
    • AerodromeType.aerodromeType
    • AirRouteLink.airRouteLinkClass
    • AirRouteType.airRouteType
    • AirspaceArea.AirspaceAreaType
    • Navaid.navaidType
    • RunwayArea.runwayType
    • RunwayCentrelinePoint.pointRole
    • SurfaceComposition.surfaceComposition
    • UseRestriction.restriction
  2. Target element of AerodromeNode.controlTowers association role changed from bui:ControlTower to bu-base:AbstractConstruction and reversePropertyName removed.
  3. Schema imports updated to new versions for all imported schemas (bu-base, net, tn)
CableTransportNetwork.xsd tn-c 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • CablewayLink.cablewayType
  2. Schema imports updated to new versions for all imported schemas (net, tn)
RailTransportNetwork.xsd tn-ra 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • RailwayNode.formOfNode
    • RailwayType.type
    • RailwayUse.use
  2. Removed duplicate attribute Railwaylink.fictitious (see discussion on the Thematic Clusters platform)
  3. Schema imports updated to new versions for all imported schemas (net, tn, tn-ro)
RoadTransportNetwork.xsd tn-ro 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • FormOfWay.formOfWay
    • NumberOfLanes.direction
    • RoadNodeType.formOfRoadNode
    • RoadServiceType.type
    • RoadSurfaceCategory.surfaceCategory
    • RoadWidth.measuredRoadPart
    • SpeedLimit.areaCondition
    • SpeedLimit.direction
    • SpeedLimit.speedLimitSource
    • SpeedLimit.vehicleType
    • SpeedLimit.weatherCondition
  2. Schema imports updated to new versions for all imported schemas (gn, net, tn)
WaterTransportNetwork.xsd tn-w 3.0 4.0
  1. Code list encoding changed from gml:CodeType to gml:ReferenceType for all code list-valued attributes:
    • FerryUse.ferryUse
    • WaterwayNode.formOfWaterwayNode
  2. Schema imports updated to new versions for all imported schemas (net, tn)

Changes (Annex II+III schemas)

As explained above, also the namespaces and schema imports of Annex I schemas had to be updated in the Annex II+III schemas in order to have a coherent set of schemas (including the references between them). 

Example for transforming a GML instance document to comply with the new schema version

This section describes what changes are required to transform an GML instance document to comply with the updated version of the ProtectedSites.xml schema.

Instance document (Ramsar_p_ps_3.0.gml) compliant with v3.0 of the Protected Sites schema (http://inspire.ec.europa.eu/schemas/ps/3.0/ProtectedSites.xsd):

<?xml version="1.0" encoding="utf-8"?>
<gml:FeatureCollection gml:id="fc" 
      xmlns:ps="urn:x-inspire:specification:gmlas:ProtectedSites:3.0"
      xmlns:base="urn:x-inspire:specification:gmlas:BaseTypes:3.2" 
      xmlns:gn="urn:x-inspire:specification:gmlas:GeographicalNames:3.0" 
      xmlns:gml="http://www.opengis.net/gml/3.2" 
      xmlns:gmd="http://www.isotc211.org/2005/gmd" 
      xmlns:gco="http://www.isotc211.org/2005/gco" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <gml:featureMember>
    <ps:ProtectedSite gml:id="I1">
      (...)
      <ps:siteDesignation>
        <ps:DesignationType>
          <ps:designationScheme
              codeSpace="http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/">ramsar</ps:designationScheme>
          <ps:designation
            codeSpace="http://inspire.ec.europa.eu/codelist/RamsarDesignationValue/">ramsar</ps:designation>
          <ps:percentageUnderDesignation>100</ps:percentageUnderDesignation>
        </ps:DesignationType>
      </ps:siteDesignation>
      (...)
    </ps:ProtectedSite>
  </gml:featureMember>
  (...)
</gml:FeatureCollection>

Required changes:

Note that, in this example, no change is required for the change of the type of element percentageUnderDesignation, since the value (100) is also valid for the new type xs:decimal. For instance document that do not already use a decimal number, the value needs to be changes as well.

Instance document (Ramsar_p_ps_4.0.gml) compliant with v4.0 of the Protected Sites schema (http://inspire.ec.europa.eu/schemas/ps/4.0/ProtectedSites.xsd):

<?xml version="1.0" encoding="utf-8"?>
<gml:FeatureCollection gml:id="fc" 
      xmlns:ps="http://inspire.ec.europa.eu/schemas/ps/4.0"
      xmlns:base="http://inspire.ec.europa.eu/schemas/base/3.3" 
      xmlns:gn="http://inspire.ec.europa.eu/schemas/gn/4.0" 
      xmlns:gml="http://www.opengis.net/gml/3.2" 
      xmlns:gmd="http://www.isotc211.org/2005/gmd" 
      xmlns:gco="http://www.isotc211.org/2005/gco" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xlink="http://www.w3.org/1999/xlink">
  <gml:featureMember>
    <ps:ProtectedSite gml:id="I1">
      (...)
      <ps:siteDesignation>
        <ps:DesignationType>
          <ps:designationScheme xlink:href="http://inspire.ec.europa.eu/codelist/DesignationSchemeValue/ramsar" />
          <ps:designation xlink:href="http://inspire.ec.europa.eu/codelist/RamsarDesignationValue/ramsar" />
          <ps:percentageUnderDesignation>100</ps:percentageUnderDesignation>
        </ps:DesignationType>
      </ps:siteDesignation>
      (...)
    </ps:ProtectedSite>
  </gml:featureMember>
  (...)
</gml:FeatureCollection>

Alternative_approaches_Annex_I_schema_updates.pdf - Alternative proposals for updating the Annex I xml schemas (551 KB) Michael Lutz, 08 Jan 2015 06:07 pm

Ramsar_p_ps_3.0.gml (2.83 MB) Michael Lutz, 05 May 2015 10:25 am

Ramsar_p_ps_4.0.gml (2.82 MB) Michael Lutz, 05 May 2015 10:25 am