GML feature collections (A set of XML documents. Each document contains a GML feature collection.)
Feature statistics
Type
Total Count
all
32086
Beacon
8441
Buoy
10113
CEMTClass
9
InlandWaterway
1643
MarineWaterway
25
MarkerPost
2809
TrafficSeparationSchemeCrossing
75
TrafficSeparationSchemeSeparator
75
TransportNetwork
1
WaterTrafficFlowDirection
1
WaterwayLink
4737
WaterwayNode
4157
Log path: Conformance class: INSPIRE GML encoding
Testing 32086 features
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-encoding/inspire-gml/ets-inspire-gml-bsxets.xml
Statistics table: 34 ms
Test Suite 'Conformance class: INSPIRE GML encoding' started
Test Case 'Basic tests' started
Test Assertion 'gml.a.1: Errors loading the XML documents': PASSED - 0 ms
Test Assertion 'gml.a.2: Document root element': PASSED - 0 ms
Test Assertion 'gml.a.3: Character encoding': NOT_APPLICABLE
Test Case 'Basic tests' finished: PASSED
Test Suite 'Conformance class: INSPIRE GML encoding' finished: PASSED
Log path: Conformance class: Reference systems, General requirements
Testing 32086 features
Indexing features (parsing errors: 0): 6014 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data/reference-systems/ets-reference-systems-bsxets.xml
Statistics table: 34 ms
Test Suite 'Conformance class: Reference systems, General requirements' started
Test Case 'Spatial reference systems' started
Test Assertion 'rs.a.1: Spatial reference systems in feature geometries': PASSED - 165 ms
Test Assertion 'rs.a.2: Default spatial reference systems in feature collections': PASSED - 31 ms
Test Case 'Spatial reference systems' finished: PASSED
Test Case 'Temporal reference systems' started
Test Assertion 'rs.a.3: Temporal reference systems in features': PASSED - 556 ms
Test Case 'Temporal reference systems' finished: PASSED
Test Suite 'Conformance class: Reference systems, General requirements' finished: PASSED
Log path: Conformance class: Reference systems, Transport Networks
Testing 32086 features
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-tn/tn-rs/ets-tn-rs-bsxets.xml
Statistics table: 35 ms
Test Suite 'Conformance class: Reference systems, Transport Networks' started
Test Case 'Additional theme-specific rules for reference systems' started
Test Assertion 'tn-rs.a.1: Test always passes': PASSED - 0 ms
Test Case 'Additional theme-specific rules for reference systems' finished: PASSED
Test Suite 'Conformance class: Reference systems, Transport Networks' finished: PASSED
Log path: Conformance class: Information accessibility, General requirements
Testing 32086 features
Indexing features (parsing errors: 0): 5327 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data/information-accessibility/ets-information-accessibility-bsxets.xml
Statistics table: 33 ms
Test Suite 'Conformance class: Information accessibility, General requirements' started
Test Case 'Coordinate reference systems (CRS)' started
Checking URL: 'http://www.opengis.net/def/crs/EPSG/0/4258'
Test Assertion 'ia.a.1: CRS publicly accessible via HTTP': PASSED - 552 ms
Test Case 'Coordinate reference systems (CRS)' finished: PASSED
Test Suite 'Conformance class: Information accessibility, General requirements' finished: PASSED
Log path: Conformance class: Information accessibility, Transport Networks
Testing 32086 features
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-tn/tn-ia/ets-tn-ia-bsxets.xml
Statistics table: 32 ms
Test Suite 'Conformance class: Information accessibility, Transport Networks' started
Test Case 'Code lists' started
Test Assertion 'tn-ia.a.1: Code list extensions accessible': PASSED - 0 ms
Test Case 'Code lists' finished: PASSED
Test Case 'Feature references' started
Test Assertion 'tn-ia.b.1: MarkerPost.route': PASSED - 168 ms
Test Assertion 'tn-ia.b.2: TransportLinkSet.post': PASSED - 236 ms
Test Case 'Feature references' finished: PASSED
Test Suite 'Conformance class: Information accessibility, Transport Networks' finished: PASSED
Log path: Conformance class: Data consistency, General requirements
Testing 32086 features
Indexing features (parsing errors: 0): 5906 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data/data-consistency/ets-data-consistency-bsxets.xml
Statistics table: 33 ms
Test Suite 'Conformance class: Data consistency, General requirements' started
Test Case 'Version consistency' started
Test Assertion 'dc.a.1: Version lifespan plausible': PASSED - 132 ms
Test Assertion 'dc.a.2: Unique identifier persistency': PASSED_MANUAL
Test Assertion 'dc.a.3: Spatial object type stable': PASSED_MANUAL
Test Case 'Version consistency' finished: PASSED_MANUAL
Test Case 'Temporal consistency' started
Test Assertion 'dc.b.1: Valid time plausible': PASSED - 93 ms
Test Case 'Temporal consistency' finished: PASSED
Test Suite 'Conformance class: Data consistency, General requirements' finished: PASSED_MANUAL
Log path: Conformance class: Data consistency, Transport Networks
Testing 32086 features
Indexing features (parsing errors: 0): 5750 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-tn/tn-dc/ets-tn-dc-bsxets.xml
Statistics table: 33 ms
Test Suite 'Conformance class: Data consistency, Transport Networks' started
Test Case 'Spatial consistency' started
Test Assertion 'tn-dc.a.1: Each Transport Network Link or Node geometry is within a Network Area geometry (Road Transport Networks)': PASSED - 21 ms
Test Assertion 'tn-dc.a.2: Each Transport Network Link or Node geometry is within a Network Area geometry (Railway Transport Networks)': PASSED - 29 ms
Test Assertion 'tn-dc.a.3: Each Transport Network Link or Node geometry is within a Network Area geometry (Waterway Transport Networks)': PASSED - 49 ms
Test Assertion 'tn-dc.a.4: Each Transport Network Link or Node geometry is within a Network Area geometry (Air Transport Networks)': PASSED - 57 ms
Test Assertion 'tn-dc.a.5: Manual review': PASSED_MANUAL
Test Case 'Spatial consistency' finished: PASSED_MANUAL
Test Suite 'Conformance class: Data consistency, Transport Networks' finished: PASSED_MANUAL
Log path: Conformance class: INSPIRE GML application schemas, General requirements
Testing 32086 features
Indexing features (parsing errors: 0): 5745 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data/schemas/ets-schemas-bsxets.xml
Statistics table: 33 ms
Test Suite 'Conformance class: INSPIRE GML application schemas, General requirements' started
Test Case 'Schema' started
Test Assertion 'gmlas.a.1: Mapping of source data to INSPIRE': PASSED_MANUAL
Test Assertion 'gmlas.a.2: Modelling of additional spatial object types': PASSED_MANUAL
Test Case 'Schema' finished: PASSED_MANUAL
Test Case 'Validation against declared schema' started
Test Assertion 'gmlas.b.1: xsi:schemaLocation attribute': PASSED - 0 ms
Validating tn_waterways.gml
Duration: 4237 ms. Errors: 0.
Test Assertion 'gmlas.b.2: validate XML documents against declared schema': PASSED - 4250 ms
Test Case 'Validation against declared schema' finished: PASSED
Test Case 'GML model' started
Test Assertion 'gmlas.c.1: Consistency with the GML model': PASSED - 526 ms
Test Assertion 'gmlas.c.2: nilReason attributes require xsi:nil=true': PASSED - 106 ms
Test Assertion 'gmlas.c.3: nilReason values': PASSED - 165 ms
Test Case 'GML model' finished: PASSED
Test Case 'Simple features' started
Test Assertion 'gmlas.d.1: No spatial topology objects': PASSED - 1259 ms
Test Assertion 'gmlas.d.2: No non-linear interpolation': PASSED - 186 ms
Test Assertion 'gmlas.d.3: Surface geometry elements': PASSED - 731 ms
Test Assertion 'gmlas.d.4: No non-planar interpolation': PASSED - 144 ms
Test Assertion 'gmlas.d.5: Geometry elements': PASSED - 806 ms
Test Assertion 'gmlas.d.6: Point coordinates in gml:pos': PASSED - 161 ms
Test Assertion 'gmlas.d.7: Curve/Surface coordinates in gml:posList': PASSED - 461 ms
Test Assertion 'gmlas.d.8: No array property elements': PASSED - 668 ms
Test Assertion 'gmlas.d.9: 1, 2 or 3 coordinate dimensions': PASSED - 150 ms
Test Assertion 'gmlas.d.10: Validate geometries (1)': PASSED - 545735 ms
Test Assertion 'gmlas.d.11: Validate geometries (2)': PASSED - 0 ms
Test Case 'Simple features' finished: PASSED
Test Case 'Code list values in basic data types' started
Test Assertion 'gmlas.e.1: GrammaticalNumber attributes': PASSED - 175 ms
Test Assertion 'gmlas.e.2: GrammaticalGender attributes': PASSED - 172 ms
Test Assertion 'gmlas.e.3: NameStatus attributes': PASSED - 175 ms
Test Assertion 'gmlas.e.4: Nativeness attributes': PASSED - 200 ms
Test Case 'Code list values in basic data types' finished: PASSED
Test Case 'Constraints' started
Test Assertion 'gmlas.f.1: At least one of the two attributes pronunciationSoundLink and pronunciationIPA shall not be void': PASSED - 74 ms
Test Case 'Constraints' finished: PASSED
Test Suite 'Conformance class: INSPIRE GML application schemas, General requirements' finished: PASSED_MANUAL
Log path: Conformance class: GML application schemas, Transport Networks
Testing 32086 features
Indexing features (parsing errors: 0): 5851 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-tn/tn-gml/ets-tn-gml-bsxets.xml
Statistics table: 32 ms
Test Suite 'Conformance class: GML application schemas, Transport Networks' started
Test Case 'Basic test' started
Test Assertion 'tn-gml.a.1: Transport Network feature in dataset': PASSED - 3845 ms
Test Case 'Basic test' finished: PASSED
Test Case 'Validation against INSPIRE official schema' started
Validating tn_waterways.gml
Duration: 4261 ms. Errors: 0.
Test Assertion 'tn-gml.b.1: validate XML documents against official schema': PASSED - 4275 ms
Test Case 'Validation against INSPIRE official schema' finished: PASSED
Test Suite 'Conformance class: GML application schemas, Transport Networks' finished: PASSED
Log path: Conformance class: Application schema, Transport Networks Common
Testing 32086 features
Indexing features (parsing errors: 0): 5608 ms
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-tn/tn-as/ets-tn-as-bsxets.xml
Statistics table: 84 ms
Test Suite 'Conformance class: Application schema, Transport Networks Common' started
Test Case 'Code list values' started
Test Assertion 'tn-as.a.1: AccessRestrictionValue attributes': PASSED - 90 ms
Test Assertion 'tn-as.a.2: RestrictionTypeValue attributes': PASSED - 89 ms
Test Case 'Code list values' finished: PASSED
Test Case 'Constraints' started
Analyzing up to 4737 feature references - this may take awhile...
Analyzing feature reference 100/4737
Analyzing feature reference 200/4737
Analyzing feature reference 300/4737
Analyzing feature reference 400/4737
Analyzing feature reference 500/4737
Analyzing feature reference 600/4737
Analyzing feature reference 700/4737
Analyzing feature reference 800/4737
Analyzing feature reference 900/4737
Analyzing feature reference 1000/4737
Analyzing feature reference 1100/4737
Analyzing feature reference 1200/4737
Analyzing feature reference 1300/4737
Analyzing feature reference 1400/4737
Analyzing feature reference 1500/4737
Analyzing feature reference 1600/4737
Analyzing feature reference 1700/4737
Analyzing feature reference 1800/4737
Analyzing feature reference 1900/4737
Analyzing feature reference 2000/4737
Analyzing feature reference 2100/4737
Analyzing feature reference 2200/4737
Analyzing feature reference 2300/4737
Analyzing feature reference 2400/4737
Analyzing feature reference 2500/4737
Analyzing feature reference 2600/4737
Analyzing feature reference 2700/4737
Analyzing feature reference 2800/4737
Analyzing feature reference 2900/4737
Analyzing feature reference 3000/4737
Analyzing feature reference 3100/4737
Analyzing feature reference 3200/4737
Analyzing feature reference 3300/4737
Analyzing feature reference 3400/4737
Analyzing feature reference 3500/4737
Analyzing feature reference 3600/4737
Analyzing feature reference 3700/4737
Analyzing feature reference 3800/4737
Analyzing feature reference 3900/4737
Analyzing feature reference 4000/4737
Analyzing feature reference 4100/4737
Analyzing feature reference 4200/4737
Analyzing feature reference 4300/4737
Analyzing feature reference 4400/4737
Analyzing feature reference 4500/4737
Analyzing feature reference 4600/4737
Analyzing feature reference 4700/4737
Test Assertion 'tn-as.b.1: TrafficFlowDirection can only be associated with a spatial object of the type Link or LinkSequence.': PASSED - 4084 ms
Test Assertion 'tn-as.b.2: All transport areas have an external object identifier.': PASSED - 91 ms
Test Assertion 'tn-as.b.3: All transport links have an external object identifier.': PASSED - 61 ms
Test Assertion 'tn-as.b.4: All transport link sequences have an external object identifier.': PASSED - 38 ms
Test Assertion 'tn-as.b.5: All transport link sets have an external object identifier.': PASSED - 53 ms
Test Assertion 'tn-as.b.6: All transport nodes have an external object identifier.': PASSED - 72 ms
Test Assertion 'tn-as.b.7: All transport points have an external object identifier.': PASSED - 79 ms
Test Assertion 'tn-as.b.8: All transport properties have an external object identifier.': PASSED - 188 ms
Test Assertion 'tn-as.b.9: A transport link sequence must be composed of transport links that all belong to the same transport network.': PASSED - 35 ms
Test Assertion 'tn-as.b.10: A transport link set must be composed of transport links and or transport link sequences that all belong to the same transport network.': PASSED - 58 ms
Test Case 'Constraints' finished: PASSED
Test Case 'Geometry' started
Test Assertion 'tn-as.c.1: No free transport nodes': PASSED - 1706 ms
Test Assertion 'tn-as.c.2: Intersections only at crossings': PASSED_MANUAL
Test Case 'Geometry' finished: PASSED_MANUAL
Test Case 'Network connectivity' started
Test Assertion 'tn-as.d.1: Connectivity at crossings': PASSED_MANUAL
Test Assertion 'tn-as.d.2: Unconnected nodes': PASSED_MANUAL
Test Assertion 'tn-as.d.3: Connectivity tolerance': PASSED_MANUAL
Test Case 'Network connectivity' finished: PASSED_MANUAL
Test Case 'Object References' started
Test Assertion 'tn-as.e.1: Linear references': PASSED_MANUAL
Test Assertion 'tn-as.e.2: Inter-modal connections': PASSED - 16 ms
Test Case 'Object References' finished: PASSED_MANUAL
Test Suite 'Conformance class: Application schema, Transport Networks Common' finished: PASSED_MANUAL
Log path: Conformance class: Application schema, Water Transport Networks
Testing 32086 features
Executing Test Suite: /etf/projects/inspire-ets-repository/ets-repository-2025.1.1/data-tn/tn-w-as/ets-tn-w-as-bsxets.xml
Statistics table: 36 ms
Test Suite 'Conformance class: Application schema, Water Transport Networks' started
Test Case 'Code list values' started
Test Assertion 'tn-w-as.a.1: FerryUseValue attributes': PASSED - 75 ms
Test Assertion 'tn-w-as.a.2: FormOfWaterwayNodeValue attributes': PASSED - 89 ms
Test Case 'Code list values' finished: PASSED
Test Case 'Constraints' started
Test Assertion 'tn-w-as.b.1: CEMTClass can only be associated with a spatial object that is part of a water transport network.': PASSED - 28 ms
Test Assertion 'tn-w-as.b.2: ConditionOfWaterFacility can only be associated with a spatial object that is part of a water transport network.': PASSED - 29 ms
Test Assertion 'tn-w-as.b.3: FerryUse can only be associated with a spatial object that is part of a water transport network.': PASSED - 21 ms
Test Assertion 'tn-w-as.b.4: RestrictionForWaterVehicles can only be associated with a spatial object that is part of a water transport network.': PASSED - 28 ms
Analyzing up to 4737 feature references - this may take awhile...
Analyzing feature reference 100/4737
Analyzing feature reference 200/4737
Analyzing feature reference 300/4737
Analyzing feature reference 400/4737
Analyzing feature reference 500/4737
Analyzing feature reference 600/4737
Analyzing feature reference 700/4737
Analyzing feature reference 800/4737
Analyzing feature reference 900/4737
Analyzing feature reference 1000/4737
Analyzing feature reference 1100/4737
Analyzing feature reference 1200/4737
Analyzing feature reference 1300/4737
Analyzing feature reference 1400/4737
Analyzing feature reference 1500/4737
Analyzing feature reference 1600/4737
Analyzing feature reference 1700/4737
Analyzing feature reference 1800/4737
Analyzing feature reference 1900/4737
Analyzing feature reference 2000/4737
Analyzing feature reference 2100/4737
Analyzing feature reference 2200/4737
Analyzing feature reference 2300/4737
Analyzing feature reference 2400/4737
Analyzing feature reference 2500/4737
Analyzing feature reference 2600/4737
Analyzing feature reference 2700/4737
Analyzing feature reference 2800/4737
Analyzing feature reference 2900/4737
Analyzing feature reference 3000/4737
Analyzing feature reference 3100/4737
Analyzing feature reference 3200/4737
Analyzing feature reference 3300/4737
Analyzing feature reference 3400/4737
Analyzing feature reference 3500/4737
Analyzing feature reference 3600/4737
Analyzing feature reference 3700/4737
Analyzing feature reference 3800/4737
Analyzing feature reference 3900/4737
Analyzing feature reference 4000/4737
Analyzing feature reference 4100/4737
Analyzing feature reference 4200/4737
Analyzing feature reference 4300/4737
Analyzing feature reference 4400/4737
Analyzing feature reference 4500/4737
Analyzing feature reference 4600/4737
Analyzing feature reference 4700/4737
Test Assertion 'tn-w-as.b.5: WaterTrafficFlowDirection can only be associated with a spatial object that is part of a water transport network.': PASSED - 4150 ms
Test Case 'Constraints' finished: PASSED
Test Case 'Object references' started
Test Assertion 'tn-w-as.c.1: Hydrography theme references': PASSED_MANUAL
Test Case 'Object references' finished: PASSED_MANUAL
Test Suite 'Conformance class: Application schema, Water Transport Networks' finished: PASSED_MANUAL
Conformance class: INSPIRE GML encoding
1
This test suite examines GML documents against basic requirements for the GML encoding for spatial data sets in INSPIRE. This only covers application-schema-independent, generic requirements. Requirements related to specific application schemas are part of conformance classes with a dependency on this conformance class.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion.
Report errors that occurred during loading the documents in the test object. A typical example is an XML document that is not well-formed and therefore cannot be processed.
Check for each XML document that the root element is a GML feature or a GML feature collection.
For feature collections the following root elements are recognised:
wfs:FeatureCollection (WFS 2.0),
gml:FeatureCollection (GML 3.2),
base:SpatialDataSet (INSPIRE Base 3.2 or 3.3).
This test is a pre-condition to identify the INSPIRE features in the test object.
Relevant requirements and recommendations:
Recommendation 11 - For the exchange of spatial objects in GML, an XML document with a FeatureCollection root element from ISO 19142:2010 (WFS 2.0) should be used.
Known limitations:
Currently only feature collections are recognized as the test engine BaseX is not schema-aware. A new extension function would be required to identify all feature elements.
This test ensures that all linguistic texts can be encoded consistently and in any language – which in turn simplifies the processing of data. The use of UTF-8 also aligns with common practice and is the default character encoding for XML documents.
Inspect each XML document. If an XML declaration exists, verify that the encoding attribute has the value "UTF-8" or that the attribute is missing.
Relevant requirements:
Requirement 12 - XML documents shall be required to be encoded using UTF-8 as character encoding.
Known limitations:
Currently the test is disabled as the test needs an BaseX extension - the XML declaration is NOT part of the node set in XML databases.
Conformance class: Reference systems, General requirements
2
This test suite examines a data set against the basic requirements related to reference systems (spatial and temporal, units of measurement). This test suite only examines requirements that are not specific to a data theme. Additional test cases will be defined per data theme, where needed.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are only supported, if the unqualified name of the feature type in the extension is the same as the name of the feature type in the INSPIRE application schema.
Verify that all references to coordinate reference systems in the features (srsName) use one of the approved CRS URIs listed in TG requirement 2.
Relevant requirements:
IR Requirement Annex II Section 1.2: Datum for three-dimensional and two-dimensional coordinate reference systems. For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.
IR Requirement Annex II Section 1.3: Datum for three-dimensional and two-dimensional coordinate reference systems. Spatial data sets shall be made available using at least one of the coordinate reference systems:
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
Compound coordinate reference system using one of the systems above plus, for the vertical component, one of the following coordinate reference systems shall be used:
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well- defined reference level close to the MSL shall be used as the reference surface.
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
For regions outside of continental Europe, Member States may define suitable coordinate reference systems. The geodetic codes and parameters needed to describe these coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created, according to EN ISO 19111 and ISO 19127.
IR Requirement Annex II Section 1.5 (1): Coordinate Reference System Identifiers. Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.
IR Requirement Annex II Section 1.5 (2): Coordinate Reference System Identifiers. Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.
Verify that all references to coordinate reference systems in the bounding box of the feature collection (srsName) use one of the CRS URIs listed in TG requirement 2.
Relevant requirements:
IR Requirement Annex II Section 1.2: Datum for three-dimensional and two-dimensional coordinate reference systems. For the three-dimensional and two-dimensional coordinate reference systems and the horizontal component of compound coordinate reference systems used for making spatial data sets available, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on the definition of the ITRS and there is a well documented relationship between both systems, according to EN ISO 19111.
IR Requirement Annex II Section 1.3: Datum for three-dimensional and two-dimensional coordinate reference systems. Spatial data sets shall be made available using at least one of the coordinate reference systems:
Two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
Plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference system.
Plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system.
Plane coordinates using the ETRS89 Transverse Mercator coordinate reference system.
Compound coordinate reference system using one of the systems above plus, for the vertical component, one of the following coordinate reference systems shall be used:
For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere, or other linear or parametric reference systems shall be used. Where other parametric reference systems are used, these shall be described in an accessible reference using EN ISO 19111-2:2012.
For the vertical component in marine areas where there is an appreciable tidal range (tidal waters), the Lowest Astronomical Tide (LAT) shall be used as the reference surface.
For the vertical component in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200 meters, the Mean Sea Level (MSL) or a well- defined reference level close to the MSL shall be used as the reference surface.
Three-dimensional Cartesian coordinates based on a datum specified in 1.2 and using the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid.
Three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a datum specified in 1.2 and using the parameters of the GRS80 ellipsoid.
For regions outside of continental Europe, Member States may define suitable coordinate reference systems. The geodetic codes and parameters needed to describe these coordinate reference systems and to allow conversion and transformation operations shall be documented and an identifier shall be created, according to EN ISO 19111 and ISO 19127.
IR Requirement Annex II Section 1.5 (1): Coordinate Reference System Identifiers. Coordinate reference system parameters and identifiers shall be managed in one or several common registers for coordinate reference systems.
IR Requirement Annex II Section 1.5 (2): Coordinate Reference System Identifiers. Only identifiers contained in a common register shall be used for referring to the coordinate reference systems listed in this Section.
Verify that all references to coordinate reference systems in the features use one of the approved http URIs, i.e. check that all references to coordinate reference systems in the frame XML attributes in the features use the URI 'http://www.opengis.net/def/trs/ISO-8601/'.
Note that all values in the XML Schema date/time types is automatically in the required reference system.
Relevant requirements:
IR Requirement Article 11 (1): Temporal Reference Systems. The default temporal reference system referred to in point 5 of part B of the Annex to Commission Regulation (EC) No 1205/2008 (14) shall be used, unless other temporal reference systems are specified for a specific spatial data theme in Annex II.
Conformance class: Reference systems, Transport Networks
1
This test suite examines a data set against the theme-specific requirements related to reference systems (spatial and temporal, units of measurement).
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are not fully supported.
This conformance class includes no assertions beyond the ones referenced by dependencies, i.e. those that apply across the data themes. This assertion will always pass and is included for technical reasons.
Conformance class: Information accessibility, General requirements
1
This test suite examines a data set against the basic requirements related to the accessibility of resources referenced by the data. This test suite only examines requirements that are not specific to a data theme. Additional test cases will be defined per data theme, where needed.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are only supported, if the unqualified name of the feature type in the extension is the same as the name of the feature type in the INSPIRE application schema.
Verify that any coordinate reference system is publicly accessible via HTTP, i.e. inspect links to coordinate reference systems. Verify that a HTTP GET request to the URI of each unique link (srsName, frame) retrieves a document.
Relevant requirements:
IR Requirement Article 10 (3): Life-cycle of Spatial Objects. Where the attributes beginLifespanVersion and endLifespanVersion are used, the value of endLifespanVersion shall not be before the value of beginLifespanVersion.
Conformance class: Information accessibility, Transport Networks
2
This test suite examines a data set against the themespecific requirements related to the accessibility of resources referenced by the data.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are not fully supported.
Verify that any code list extensions are publicly accessible via HTTP, i.e. inspect extensible code list valued property elements. If a reference (@xlink:href) has a value that does not start with http://inspire.ec.europa.eu/codelist/, verify that a HTTP GET request to the URI retrieves a document.
This data theme currently does not specify any extensible code lists. The test always passes.
Relevant requirements:
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points (b), (c) or (d) of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
Verify that any feature reference in an association role is publicly accessible via HTTP, i.e. inspect all relevant properties. If a reference (@xlink:href) has a value that starts with "#", verify that an element with a `gml:id` attribute with the referenced identifier exists in the same document. If the reference starts with "http", verify that a HTTP GET request to the URI retrieves an XML document.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Verify that any feature reference in an association role is publicly accessible via HTTP, i.e. inspect all relevant properties. If a reference (@xlink:href) has a value that starts with "#", verify that an element with a `gml:id` attribute with the referenced identifier exists in the same document. If the reference starts with "http", verify that a HTTP GET request to the URI retrieves an XML document.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Conformance class: Data consistency, General requirements
2
This test suite examines a data set against the basic requirements related to the consistency of the data. This test suite only examines requirements that are not specific to a data theme. Additional test cases will be defined per data theme, where needed.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are only supported, if the unqualified name of the feature type in the extension is the same as the name of the feature type in the INSPIRE application schema.
Verify that all endLifespanVersion values are from the allowed range. For all features verify that either
beginLifespanVersion or endLifespanVersion are missing or nil or
endLifespanVersion is not before the value of beginLifespanVersion.
Relevant requirements:
IR Requirement Article 10 (3): Life-cycle of Spatial Objects. Where the attributes beginLifespanVersion and endLifespanVersion are used, the value of endLifespanVersion shall not be before the value of beginLifespanVersion.
Verify that identifiers are persistent for a spatial object, i.e. inspect the documentation of the spatial data set and verify that rules for identifiers are specified in a way that the identifiers (namespace and localId) do not change during the life-cycle of a spatial object. If older versions of the data set are available compare the features and verify that the namespace and localId part of the INSPIRE identifiers have not changed between the versions.
Relevant requirements:
IR Requirement Article 9 (2): Identifier Management. The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object.
Verify that the type of a spatial object is unchanged for different versions, i.e. inspect the documentation of the spatial data set and verify that rules for the mapping to the INSPIRE application schema are specified in a way that the spatial object type do not change during its life-cycle. If older versions of the data set are available compare the features and verify that the types of the features has not changed between the versions.
Relevant requirements:
IR Requirement Article 9 (2): Identifier Management. The external object identifier for the unique identification of spatial objects shall not be changed during the life-cycle of a spatial object.
IR Requirement Article 12 (3): Other Requirements and Rules. Where the attributes validFrom and validTo are used, the value of validTo shall not be before the value of validFrom.
Conformance class: Data consistency, Transport Networks
1
This test suite examines a data set against theme-specific requirements related to the consistency of the data.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are not fully supported.
Verify that Transport Networks centreline representations and nodes in the Road Transport Network are located within the extent of the area representation of the same object.
Relevant requirements:
IR Requirement Annex II Section 7.9.1 (1): Theme-specific Requirements – Consistency between spatial data sets. Transport Networks centreline representations and nodes shall always be located within the extent of the area representation of the same object.
Verify that Transport Networks centreline representations and nodes in the Railway Transport Network are located within the extent of the area representation of the same object.
Relevant requirements:
IR Requirement Annex II Section 7.9.1 (1): Theme-specific Requirements – Consistency between spatial data sets. Transport Networks centreline representations and nodes shall always be located within the extent of the area representation of the same object.
Verify that Transport Networks centreline representations and nodes in the Waterway Transport Network are located within the extent of the area representation of the same object.
Relevant requirements:
IR Requirement Annex II Section 7.9.1 (1): Theme-specific Requirements – Consistency between spatial data sets. Transport Networks centreline representations and nodes shall always be located within the extent of the area representation of the same object.
Verify that Transport Networks centreline representations and nodes in the Air Transport Network are located within the extent of the area representation of the same object.
Relevant requirements:
IR Requirement Annex II Section 7.9.1 (1): Theme-specific Requirements – Consistency between spatial data sets. Transport Networks centreline representations and nodes shall always be located within the extent of the area representation of the same object.
Verify that transport networks are spatially connected across data sets. Review the data maintenance procedures and perform spot checks to verify that connectivity between transport networks across state borders and – where applicable – also across regional borders (and data sets) within Member States is established and maintained by the respective authorities, using the cross-border connectivity mechanisms provided by the NetworkConnection type.
Relevant requirements:
IR Requirement Annex II Section 7.9.1 (2): Theme-specific Requirements – Consistency between spatial data sets. Connectivity between transport networks across state borders and – where applicable – also across regional borders (and data sets) within Member States shall be established and maintained by the respective authorities, using the cross-border connectivity mechanisms provided by the NetworkConnection type.
Conformance class: INSPIRE GML application schemas, General requirements
6
This test suite examines GML documents against basic requirements for the GML encoding for spatial data sets in INSPIRE. This only covers application-schema-independent, generic requirements. Requirements related to specific application schemas are part of conformance classes with a dependency on this conformance class.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are only supported, if the unqualified name of the feature type in the extension is the same as the name of the feature type in the INSPIRE application schema.
Verify whether each relevant element of the source data set under inspection has been properly mapped to the INSPIRE application schemas. Inspect the documentation of the source data set and determine, if all relevant information has been mapped correctly to the INSPIRE application schema, i.e. that spatial object types, data types, attributes, association roles, code lists, and enumerations are mapped to the INSPIRE application schemas with the correct designation of mnemonic names.
Relevant requirements:
Article 4(1) - For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
Inspect the XML Schema namespace of each feature element. If a namespace URI does not start with "http://inspire.ec.europa.eu/schemas/" or "urn:x-inspire:specification:gmlas:" it is not one of the approved INSPIRE application schema namespaces. Review the extension documentation for the identified namespaces to check that any extensions do not overlap with the spatial object types and associated data types and enumerations that are defined in Annexes II, III and IV of the Implementing Rule.
Relevant requirements:
Article 4(1) - For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
Validate each document against the schema(s) specified in the xsi:schemaLocation attribute using strict XML schema validation.
Relevant requirements:
IR Requirement Article 3: Common Types. Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 5 (2): Types. Types that are a sub-type of another type shall also include all this type‘s attributes and association roles.
IR Requirement Article 5 (3): Types. Abstract types shall not be instantiated.
IR Requirement Article 6 (5): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types that have an enumeration type may only take values from the lists specified for the enumeration type.
IR Requirement Article 9 (1): Identifier Management. The data type Identifier defined in Section 2.1 of Annex I shall be used as a type for the external object identifier of a spatial object.
TG Requirement 1: Spatial object types and data types shall comply with the multiplicities defined for the attributes and association roles in this section.
TG Requirement 6: Data instance (XML) documents shall validate without error against the provided XML schema.
Note that validation is done on a file-by-file basis and access to many remote schema files is time consuming. I.e. it will be much faster to validate a single document with many features than many files with a few features each.
Inspect each property element and verify that it either carries a URI reference to an object (@xlink:href), contains one or more object elements as child elements or contains a non-empty text node (whitespace is trimmed before checking for empty text).
Strictly, empty string values are valid according to the GML model, but they are not an appropriate value for any of the string-valued attributes in INSPIRE.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
Inspect each XML element that represents a feature property and that has a nilReason XML attribute. Verify that xsi:nil='true' is present in the property element, i.e. a reason is only provided in properties that are void / nil.
Limitation: This test currently does not analyse properties of data types or objects embedded in a feature.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
Inspect all nilReason values and verify that either the values from the INSPIRE registry or the pre-defined values from the GML standard are used. Otherwise report incorrectReason. Valid values are:
Limitation: This test currently does not analyse properties of data types or objects embedded in a feature.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
Verify that all features that are not excluded from the default requirement that geometries meet the requirements of the Simple Features standard fulfill the requirements.
Verify that no spatial topology types are used, i.e. check that none of the GML object elements for spatial topology are used as child elements of a feature from the application schema.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that only linear interpolation is used, i.e. check that none of the nonlinear GML curve segment object elements are used as child elements of a feature from the application schema.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that only gml:Polygon or gml:Surface are used, i.e. check that none of the disallowed GML surface object elements are used as child elements of a feature from the application schema.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that only planar interpolation is used, i.e. check that only PolygonPatch is used as a GML surface patch object elements in features from the application schema.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that only valid GML geometry elements are used, i.e. check that none of the disallowed GML geometry object elements are used as child elements of a feature from the application schema.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that in points only gml:pos is used for coordinates.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that in curves and surfaces only gml:posList is used for coordinates.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that geometry aggregates do not use the GML array property elements, i.e. check that the only the regular property elements are used, but not the array property elements. For example, for a gml:MultiPoint, only gml:pointMember may be used, not gml:pointMembers.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Coordinate reference systems may have 1, 2 or 3 dimensions, i.e. check all occurances of srsDimension and for values greater than '3'.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Verify that in curves and surfaces only gml:posList is used for coordinates, i.e. validate all geometry elements of a feature from the application schema using a geometry library.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Note:
Cadastral Parcel and Building 3D features are excluded from this requirement.
Report any errors found while parsing GML geometries.
Relevant requirements:
IR Requirement Article 12 (1): Other Requirements and Rules. The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.
Verify whether all attributes whose value type is a code list take the values set out therein. This is usually part of the tests of the corresponding application schema. However, for data types that are used across the INSPIRE application schemas, this is best done in this test suite to avoid duplicating the same test in many test suites. The relevant data types for the Annex I data themes with code list values are: GeographicalName.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/GrammaticalNumberValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/GrammaticalGenderValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/NameStatusValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/NativenessValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
Verify that the features provided in the dataset adhere to the constraints specified in the INSPIRE application schema. This is usually part of the tests of the corresponding application schema. However, for data types that are used across the INSPIRE application schemas, this is best done in this test suite to avoid duplicating the same test in many test suites. The relevant data types for the Annex I data themes with constraints are: GeographicalName.
At least one of the two attributes pronunciationSoundLink and pronunciationIPA shall not be void
OCL: "inv: self.pronounciationIPA -> notEmpty() or self.pronounciationSoundLink -> notEmpty()"
Verify that for all features either or both pronunciationSoundLink or pronunciationIPA is not void.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Conformance class: GML application schemas, Transport Networks
2
This test suite examines the GML encoding of spatial objects specified in the INSPIRE GML application schema 'Transport Networks Simple'. Both currently approved GML application schema versions (3.0 and 4.0) are tested.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are not fully supported.
Validate each document against the latest INSPIRE official schema(s), using strict XML schema validation. The official schemas for this data theme are:
IR Requirement Article 3: Common Types. Types that are common to several of the themes listed in Annexes I, II and III to Directive 2007/2/EC shall conform to the definitions and constraints and include the attributes and association roles set out in Annex I.
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 5 (2): Types. Types that are a sub-type of another type shall also include all this type‘s attributes and association roles.
IR Requirement Article 5 (3): Types. Abstract types shall not be instantiated.
IR Requirement Article 6 (5): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types that have an enumeration type may only take values from the lists specified for the enumeration type.
IR Requirement Article 9 (1): Identifier Management. The data type Identifier defined in Section 2.1 of Annex I shall be used as a type for the external object identifier of a spatial object.
TG Requirement 1: Spatial object types and data types shall comply with the multiplicities defined for the attributes and association roles in this section.
TG Requirement 6: Data instance (XML) documents shall validate without error against the provided XML schema.
Conformance class: Application schema, Transport Networks Common
5
This test suite examines requirements associated with the application schema.
Note that since both code-list-valued properties of this application schema may be extended without restrictions, there is no test case for code list values.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are not fully supported.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/AccessRestrictionValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/RestrictionTypeValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
Verify that an TrafficFlowDirection only has a Network element association with a spatial object TransportLink or TransportLinkSequence.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport areas have an external object identifier
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportArea have an inspireId.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport links have an external object identifier.
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportLink have an inspireId.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport link sequences have an external object identifier.
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportLinkSequence have an inspireId.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport link sets have an external object identifier.
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportLinkSet have an inspireId.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport nodes have an external object identifier.
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportNode have an inspireId.<
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport points have an external object identifier.
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportPoint have an inspireId.<
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
All transport properties have an external object identifier.
OCL: "inv:inspireId->notEmpty()".
Verify that all TransportProperty have an inspireId.<
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Verify that all TransportLinkSequence are composed of all link that have the same value for the inNetwork association role as the TransportLinkSequence.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Verify that all TransportLinkSet are composed of all link that have the same value for the inNetwork association role as the TransportLinkSet.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
verify for each TransportNode that the geometry (a gml:Point) is located at a position that touches a TransportLink.centrelineGeometry (a gml:LineString or gml:Curve), i.e. that the node is at the start or end of a transport link. Otherwise report freeNode.
Relevant requirements:
IR Requirement Annex II Section 7.9.3 (2): Theme-specific Requirements – Geometry representation. In a Transport Networks data set which contains nodes, these nodes shall only be present where Transport Links connect or end.
Verify that transport link connections are consistent with the real world, i.e. check that TransportLink features ends are connected wherever a connection exists between the real world phenomena they represent. No connections must be created at connecting network elements when it is not possible for water to pass from one element to another.
Relevant requirements:
IIR Requirement Annex II Section 7.9.3 (1): Theme-specific Requirements – Geometry representation. Transport link ends shall be connected wherever an intersection exists between the real world phenomena they represent. No connections shall be created at crossing network elements when it is not possible to pass from one element to another.
Verify that all transport nodes are at the start or end of a transport link. For each TransportLink with a startNode or endNode property, verify that the distance between the start or end of the centrelineGeometry and the geometry of the start and end TransportNode is smaller than the connectivityTolerance.
Relevant requirements:
IR Requirement Annex II Section 8.7.7 (1): Theme-specific Requirements – Ensuring Network Connectivity. Wherever a connection exists in a transport network, all connected link ends and the optional node that take part in this connection have to be positioned at a distance of less than the connectivity tolerance from each other.
Known limitations:
To use a connectivityTolerance parameter would require that all geometries are first converted to a meter-based CRS, eg ETRS89 LAEA or LCC, which is currently not supported by the geometry library. In addition, it is unclear how to handle geometries outside of continental Europe. Therefore, the assertion has been classified as "manual" in this Executable Test Suite.
For each WatercourseLink verify that the only HydroNodes in the distance around the start or end of the centrelineGeometry are the nodes associated via the startNode and endNode properties.
Relevant requirements:
IR Requirement Annex II Section 8.7.7 (2): Theme-specific Requirements – Ensuring Network Connectivity. Link ends and nodes that are not connected shall always be separated by a distance that is greater than the connectivity tolerance.
Known limitations:
To use a connectivityTolerance parameter would require that all geometries are first converted to a meter-based CRS, eg ETRS89 LAEA or LCC, which is currently not supported by the geometry library. In addition, it is unclear how to handle geometries outside of continental Europe. Therefore, the assertion has been classified as "manual" in this Executable Test Suite.
Verify that the connectivity tolerance provided for the test is consistent with the metadata of the data set, i.e. check that the connectivity tolerance provided for the test is the same included in the metadata of the data set in the properties 'specification' and 'explanation' of the DQ_ConformanceResult element in a DQ_TopologicalConsistency element.
Relevant requirements:
IR Requirement Annex II Section 8.7.7 (1): Theme-specific Requirements – Ensuring Network Connectivity. Wherever a connection exists in a hydrographic network, all connected link ends and the optional node that take part in this connection have to be positioned at a distance of less than the connectivity tolerance from each other.
IR Requirement Annex II Section 8.7.7 (2): Theme-specific Requirements – Ensuring Network Connectivity. Link ends and nodes that are not connected shall always be separated by a distance that is greater than the connectivity tolerance.
Known limitations:
To use a connectivityTolerance parameter would require that all geometries are first converted to a meter-based CRS, eg ETRS89 LAEA or LCC, which is currently not supported by the geometry library. In addition, it is unclear how to handle geometries outside of continental Europe. Therefore, the assertion has been classified as "manual" in this Executable Test Suite.
For each NetworkProperty feature that links to a TransportLink or a TransportLinkSequence, verify that any linear references are consistent with the length of the geometry of the network feature.
Relevant requirements:
IR Requirement Annex II Section 7.9.2 (1): Theme-specific Requirements – Modelling of object references. When linear referencing is used in Transport Networks data, the position of referenced properties on links and link sequences shall be expressed as distances measured along the supplied geometry of the underlying link object(s).
Known limitations:
The length is not provided as an attribute of the Link features. I.e., the length needs to be derived from the centreline geometries. This would require that the geometries are first converted to a meter-based CRS, eg ETRS89 LAEA or LCC, which is currently not supported by the geometry library. In addition, it is unclear how to handle geometries outside of continental Europe. Therefore, the assertion has been classified as "manual" in this Executable Test Suite.
For each NetworkConnection with as value 'intermodal' for the type attribute, verify that the two elements referenced in the element association role belong to different networks, i.e. they reference different networks in their inNetwork association role.
Relevant requirements:
IIR Requirement Annex II Section 7.9.2 (2): Theme-specific Requirements – Modelling of object references. An inter-modal connection shall always reference two elements which belong to different networks.
Conformance class: Application schema, Water Transport Networks
3
This test suite examines requirements associated with the application schema.
Note that since both code-list-valued properties of this application schema may be extended without restrictions, there is no test case for code list values.
This is a draft version. It has limitations and is expected to contain errors. Please report any issues or problems in GitHub.
Known limitations are documented in the description of the applicable test case or test assertion. There is a general limitation in all assertions that extensions in additional application schemas are not fully supported.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/FerryUseValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
When an attribute has a code list as its type, verify that the values comply with the definitions and include the values set out in Annex II of the regulation. For this attribute, the allowed values are specified in code list http://inspire.ec.europa.eu/codelist/FormOfWaterwayNodeValue. For datasets using version 3 of the GML application schema, the value is the last path element of the code list value URI and it is in the child text node. For datasets using version 4 of the GML application schema, the value is in the xlink:href XML attribute and is the HTTP URI of the code list value.
Relevant requirements:
IR Requirement Article 4 (1): Types for the Exchange and Classification of Spatial Objects. For the exchange and classification of spatial objects from data sets meeting the conditions laid down in Article 4 of Directive 2007/2/EC, Member States shall use the spatial object types and associated data types, enumerations and code lists that are defined in Annexes II, III and IV for the themes the data sets relate to.
IR Requirement Article 4 (3): Types for the Exchange and Classification of Spatial Objects. The enumerations and code lists used in attributes or association roles of spatial object types or data types shall comply with the definitions and include the values set out in Annex II. The enumeration and code list values are uniquely identified by language-neutral mnemonic codes for computers. The values may also include a language-specific name to be used for human interaction.
IR Requirement Article 6 (1): Code Lists and Enumerations. Codelists shall be of one of the following types, as specified in the Annexes:
code lists whose allowed values comprise only the values specified in this Regulation;
code lists whose allowed values comprise the values specified in this Regulation and
narrower values defined by data providers;
code lists whose allowed values comprise the values specified in this Regulation and
additional values at any level defined by data providers;
code lists, whose allowed values comprise any values defined by data providers.
For the purposes of points 2, 3 and 4, in addition to the allowed values, data providers may use the values specified in the relevant INSPIRE Technical Guidance document available on the INSPIRE web site of the Joint Research Centre.
IR Requirement Article 6 (2): Code Lists and Enumerations. Code lists may be hierarchical. Values of hierarchical code lists may have a more generic parent value. Where the valid values of a hierarchical code list are specified in a table in this Regulation, the parent values are listed in the last column.
IR Requirement Article 6 (3): Code Lists and Enumerations. Where, for an attribute whose type is a code list as referred to in points 2, 3 or 4 of paragraph 1, a data provider provides a value that is not specified in this Regulation, that value and its definition shall be made available in a register.
IR Requirement Article 6 (4): Code Lists and Enumerations. Attributes or association roles of spatial object types or data types whose type is a code list may only take values that are allowed according to the specification of the code list.
Verify that a CEMTClass only has a Network element association with a spatial object InlandWaterway.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
ConditionOfWaterFacility can only be associated with a spatial object that is part of a water transport network.
OCL: OCL: "inv: networkRef.element.oclIsKindOf(PortArea) or networkRef.element.oclIsKindOf(PortNode)".
Verify that a ConditionOfWaterFacility only has a Network element association with a spatial object PortArea or PortNode.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Verify that a FerryUse only has a Network element association with a spatial object FerryCrossing.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
RestrictionForWaterVehicles can only be associated with a spatial object that is part of a water transport network.
OCL: "inv: networkRef.element.oclIsKindOf(WaterwayLink) or networkRef.element.oclIsKindOf(WaterwayNode)".
Verify that a RestrictionForWaterVehicles only has a Network element association with a spatial object WaterwayLink or WaterwayNode.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
WaterTrafficFlowDirection can only be associated with a spatial object that is part of a water transport network.
OCL: "inv: networkRef.element.oclIsKindOf(WaterLinkSequence) or networkRef.element.oclIsKindOf(WaterwayLink)".
Verify that a WaterTrafficFlowDirection only has a Network element association with a spatial object WaterLinkSequence or WaterwayLink.
Relevant requirements:
IR Requirement Article 4 (2): Types for the Exchange and Classification of Spatial Objects. Spatial object types and data types shall comply with the definitions and constraints and include the attributes and association roles set out in the Annexes.
Check that the Water transport networks re-uses, where it exists and is practicable, the water network centreline geometry of the Hydrography theme. Therefore, object referencing shall be used to link the water transport course with the existing water network geometry in the Hydrography theme.
Relevant requirements:
IR Requirement Annex II Section 7.9.4: Theme-specific Requirements – Modelling of object references. The Water transport networks shall re-use, where it exists and is practicable, the water network centreline geometry of the Hydrography theme. Therefore, object referencing shall be used to link the water transport course with the existing water network geometry in the Hydrography theme.