One activity in the European Location Framework project was to harvest INSPIRE data from download services of Europe’s National Mapping, Cadastral and Land Registration Authorities, transform it to a native ArcGIS representation and publish it in ArcGIS Online.
The resulting GeoServices JSON encoding is very similar to GeoJSON and it is straightforward to convert data between the two encodings (for example, see https://github.com/Esri/geojson-utils).
Simplify the use of ELF/INSPIRE data for ArcGIS end users and developers.
Used simplification rules
General remarks
Several aspects have been covered in the transformation. Not all of them are strictly simplifications of the data structures, but all of them are executed in order to simplify the use of the data in map-based applications.
The implementation schema for INSPIRE/ELF data in ArcGIS was designed to be consistent with ArcGIS data modelling principles and practices, and is derived from the ELF/INSPIRE application schemas. The transformation process was automated.
The resulting data structures are intended to be easier to use in a GIS context and in maps (easier than the source data). The data is intended to be easier to understand and handled by users and developers.
Geometry types
Feature types often have geometric properties that are, for example, point or polygon, aggregate or primitive, etc. That is, the data may contain features of the same type with different geometry types. Such INSPIRE feature types have been fanned out into multiple feature types in the implementation schema, one for each geometry type that occurs in the source datasets.
Note that this is in a way ArcGIS-specific (in ArcGIS, every feature type has to have a fixed geometry type) and not strictly required in a GeoJSON context where no concept of a feature type exists anyhow. Nevertheless, it is not uncommon in GIS tools to expect homogeneous geometries per feature type.
Nested data types
Nested data types and properties are flattened, every property will be a property of the main feature class.
Multiplicity
Support for multiple values per property is an issue in ArcGIS and other GIS tools. The standard approach is to have a fixed number of attributes instead, typically three unless it is known that more or less values are needed. A suffix with an incremental number to the attribute names to distinguish the attributes.
Standard properties
The following standard properties occurring in most ELF/INSPIRE features encoded in GML are renamed and flattened in the implementation schema:
Reduce LocalisedCharacterStrings to three text values with language information
Every property that contains an unlimited number of values of the type LocalisedCharacterString is reduced to three text and language attributes, e.g.:
Properties that are nil (@xsi:nil="true", with or without a @nilReason attribute) are ignored in the transformation as ArcGIS does not have a means to distinguish between attribute values that are not known and cases where it is known that an attribute has no value.
Ignore selected XML attributes
In references to code list values, only the value itself is used in the transformation. Other information in the property is ignored.
Suppress unused properties
If properties are never provided in the source datasets, they are suppressed entirely in the implementation schema as they would never carry a value anyhow.
This includes association roles between feature types that are not provided in the source data, too.
Represent relationships
Relationships between feature types that are included in the source datasets are in general implemented as relationship classes in the implementation schema (but see also the next section).
Example: the upperLevelUnit relationship role for AdministrativeUnit features.
Note: Unlike ArcGIS, GeoJSON has no concept of relationships.
Resolve relationships through merging
If a feature type in a relationship does not own a geometry and can be reduced to one or several properties of another feature type, the relationship is resolved by merging the two feature types in the implementation schema.
An example is the networkRef relationship role between RailwayElectrification (or any other of the TransportProperty subtypes) and RailwayLink. The electrified property of RailwayElectrification is merged into RailwayLink. The relationship as well as the RailwayElectrification feature type of INSPIRE is not part of the implementation schema.
Another example are addresses where the AddressComponent feature types are merged into the Address feature type in the implementation schema, up to three instances per component type.
Scale range fan-out
The features in the application schema were intended to be used in Web Maps in ArcGIS. It is not always feasible or desired to show all the features in every scale range. Some feature types also have properties that categorize the features into different scale ranges, like the nationalLevel for AdministrativeUnit features.
As scale dependent rendering is usually done per feature types (and not on a feature-by-feature basis), where such a scale range categorization properties could be identified, the feature type has been fanned out into multiple feature types where the name is suffixed with the level. I.e., in the AdministrativeUnit case there are six feature types in the implementation schema, AdministrativeUnit_L1 to AdministrativeUnit_L6 - each associated with different levels of zoom levels.
Coordinate transformation
Beside the schema transformations, any geometry is also converted to WGS84 and the Web Mercator projection. Web Mercator is the default Coordinate Reference System used for maps in ArcGIS and most other web mapping environments.
Simplified encoding example
Short description
One activity in the European Location Framework project was to harvest INSPIRE data from download services of Europe’s National Mapping, Cadastral and Land Registration Authorities, transform it to a native ArcGIS representation and publish it in ArcGIS Online.
The resulting GeoServices JSON encoding is very similar to GeoJSON and it is straightforward to convert data between the two encodings (for example, see https://github.com/Esri/geojson-utils).
Example instance
An example in JSON:
Purpose & use
Simplify the use of ELF/INSPIRE data for ArcGIS end users and developers.
Used simplification rules
General remarks
Several aspects have been covered in the transformation. Not all of them are strictly simplifications of the data structures, but all of them are executed in order to simplify the use of the data in map-based applications.
The implementation schema for INSPIRE/ELF data in ArcGIS was designed to be consistent with ArcGIS data modelling principles and practices, and is derived from the ELF/INSPIRE application schemas. The transformation process was automated.
The resulting data structures are intended to be easier to use in a GIS context and in maps (easier than the source data). The data is intended to be easier to understand and handled by users and developers.
Geometry types
Feature types often have geometric properties that are, for example, point or polygon, aggregate or primitive, etc. That is, the data may contain features of the same type with different geometry types. Such INSPIRE feature types have been fanned out into multiple feature types in the implementation schema, one for each geometry type that occurs in the source datasets.
Note that this is in a way ArcGIS-specific (in ArcGIS, every feature type has to have a fixed geometry type) and not strictly required in a GeoJSON context where no concept of a feature type exists anyhow. Nevertheless, it is not uncommon in GIS tools to expect homogeneous geometries per feature type.
Nested data types
Nested data types and properties are flattened, every property will be a property of the main feature class.
Multiplicity
Support for multiple values per property is an issue in ArcGIS and other GIS tools. The standard approach is to have a fixed number of attributes instead, typically three unless it is known that more or less values are needed. A suffix with an incremental number to the attribute names to distinguish the attributes.
Standard properties
The following standard properties occurring in most ELF/INSPIRE features encoded in GML are renamed and flattened in the implementation schema:
@gml:id→sourceIdgml:identifier→identifierns:inspireId/base:Identifier/base:localId→inspireId_localIdns:inspireId/base:Identifier/base:namespace→inspireId_namespacens:inspireId/base:Identifier/base:versionId→inspireId_versionIdReduce geographical name properties to three names with language information
Every property that contains an unlimited number of values of the type GeographicalName is reduced to three name and language attributes, e.g.:
ns:name[1]/gn:GeographicalName/gn:spelling[1]/gn:SpellingOfName/gn:text→name_1ns:name[1]/gn:GeographicalName/gn:language→name_1_langns:name[2]/gn:GeographicalName/gn:spelling[1]/gn:SpellingOfName/gn:text→name_2ns:name[2]/gn:GeographicalName/gn:language→name_2_langns:name[3]/gn:GeographicalName/gn:spelling[1]/gn:SpellingOfName/gn:text→name_3ns:name[3]/gn:GeographicalName/gn:language→name_3_langReduce LocalisedCharacterStrings to three text values with language information
Every property that contains an unlimited number of values of the type LocalisedCharacterString is reduced to three text and language attributes, e.g.:
au:nationalLevelName[1]/gmd:LocalisedCharacterString→nationalLevel_name_1au:nationalLevelName[1]/gmd:LocalisedCharacterString/@locale→nationalLevel_name_1_langau:nationalLevelName[2]/gmd:LocalisedCharacterString→nationalLevel_name_2au:nationalLevelName[2]/gmd:LocalisedCharacterString/@locale→nationalLevel_name_2_langau:nationalLevelName[3]/gmd:LocalisedCharacterString→nationalLevel_name_3au:nationalLevelName[3]/gmd:LocalisedCharacterString/@locale→nationalLevel_name_3_langIgnore nil/void values
Properties that are nil (
@xsi:nil="true", with or without a@nilReasonattribute) are ignored in the transformation as ArcGIS does not have a means to distinguish between attribute values that are not known and cases where it is known that an attribute has no value.Ignore selected XML attributes
In references to code list values, only the value itself is used in the transformation. Other information in the property is ignored.
Suppress unused properties
If properties are never provided in the source datasets, they are suppressed entirely in the implementation schema as they would never carry a value anyhow.
This includes association roles between feature types that are not provided in the source data, too.
Represent relationships
Relationships between feature types that are included in the source datasets are in general implemented as relationship classes in the implementation schema (but see also the next section).
Example: the
upperLevelUnitrelationship role forAdministrativeUnitfeatures.Note: Unlike ArcGIS, GeoJSON has no concept of relationships.
Resolve relationships through merging
If a feature type in a relationship does not own a geometry and can be reduced to one or several properties of another feature type, the relationship is resolved by merging the two feature types in the implementation schema.
An example is the
networkRefrelationship role betweenRailwayElectrification(or any other of theTransportPropertysubtypes) andRailwayLink. Theelectrifiedproperty ofRailwayElectrificationis merged intoRailwayLink. The relationship as well as theRailwayElectrificationfeature type of INSPIRE is not part of the implementation schema.Another example are addresses where the
AddressComponentfeature types are merged into theAddressfeature type in the implementation schema, up to three instances per component type.Scale range fan-out
The features in the application schema were intended to be used in Web Maps in ArcGIS. It is not always feasible or desired to show all the features in every scale range. Some feature types also have properties that categorize the features into different scale ranges, like the
nationalLevelforAdministrativeUnitfeatures.As scale dependent rendering is usually done per feature types (and not on a feature-by-feature basis), where such a scale range categorization properties could be identified, the feature type has been fanned out into multiple feature types where the name is suffixed with the level. I.e., in the
AdministrativeUnitcase there are six feature types in the implementation schema,AdministrativeUnit_L1toAdministrativeUnit_L6- each associated with different levels of zoom levels.Coordinate transformation
Beside the schema transformations, any geometry is also converted to WGS84 and the Web Mercator projection. Web Mercator is the default Coordinate Reference System used for maps in ArcGIS and most other web mapping environments.