The geodatabase template is an essential element of ArcGIS for INSPIRE Classic. The geodatabase templates implement the application schemas of the abstract INSPIRE data models per the Annex 1, 2, and 3 data themes.
Installation
To install the INSPIRE Classic geodatabase templates, follow the instructions in the ArcGIS for INSPIRE Geodatabase Template Installation Guide. After installation, see the use case documentation for how to set up and use INSPIRE View Services, INSPIRE Feature Download Services, and INSPIRE Predefined Dataset Download Services.
ArcGIS for INSPIRE Classic geodatabase encoding rules
The implementation of the INSPIRE Classic application schemas in the geodatabase relies on encoding rules that describe how to translate the abstract INSPIRE Classic data models into the physical implementation in the INSPIRE Classic geodatabase templates. The INSPIRE Classic geodatabase templates support the publication of INSPIRE Classic View and Download Services and the respective underlying datasets.
The main encoding rules are described in the following table:
| Rule | Example |
|---|---|
An INSPIRE Classic spatial object is typically represented as a feature class in the geodatabase. In cases where a spatial object does not have a geometry property, an object class is used instead. | The INSPIRE Classic spatial object type AdministrativeUnits::AdministrativeUnit is stored in the geodatabase in the feature class auAdmUnitS. The INSPIRE Classic spatial object type Addresses::Address is stored in the geodatabase in the object class adAddress. |
Names of feature classes, object classes, and fields are limited to 30 characters in the geodatabase. The names from the application schemas are therefore typically shortened in the geodatabase. To simplify the mapping between the names and to guarantee uniqueness, all names in the geodatabase start with the short code of the application schema. | The INSPIRE Classic spatial object type AdministrativeUnits::AdministrativeUnit is stored in the geodatabase in the feature class auAdmUnitS. The short code for the application schema AdministrativeUnits is au. |
Each feature or object class has two fields with identifiers. Both are integers. The OBJECTID field is an internal identifier, used only for management in the geodatabase. It's automatically set by the database upon insert. The IFCID field is the identifier used in foreign key relationships. It must be set upon insert into the database by the transformation process adding data to the geodatabase. It must be unique for the feature and object class in the geodatabase and for the INSPIRE Classic spatial object type. | N/A |
Attributes of an INSPIRE Classic spatial object type with a maximum multiplicity greater than one are converted into their own object class. The attribute values are associated with the spatial object through foreign key references (RID field) to the associated feature or object class (IFCID field). Only by using this mechanism is it possible to have a general representation of multiple attribute values in a geodatabase. | The attribute name of the INSPIRE Classic AdministrativeUnits::AdministrativeUnit spatial object type is converted to the auAdmUnitS_name object class. The object class contains all information from the value data type of the attribute. In addition, it contains the RID field that references the entry in the auAdmUnitS feature class to which the name belongs. |
INSPIRE Classic distinguishes between properties where the value is unknown to a data owner (value type void) and where the data owner knows that the property is not applicable for the particular spatial object (for example, a road without a road name). These cases must also be distinguished in the geodatabase. In the INSPIRE Classic application schemas, these properties are marked with the stereotype <<voidable>>. An additional field with the suffix _void is added to the geodatabase in these cases.
| N/A |
Attributes with a data type that is marked with the stereotype <<codeList>> in the INSPIRE Classic application schema are converted into the following two fields:
| The nationalLevel attribute of the INSPIRE Classic spatial object type AdministrativeUnits::AdministrativeUnit is converted to the nationalLevel field and nationalLevel_cl field. The nationalLevel field contains a value from the code list AdministrativeHierarchyLevel, for example, 1stOrder. The nationalLevel_cl field contains the URL, for example, http://services.interactive-instruments.de/download/cl/AdministrativeHierarchyLevel.xml. |
Attributes with a data type that is marked with the stereotype <<enumeration>> in the INSPIRE Classic application schema are converted into a single field. The field contains the value from the enumeration, which is represented in the geodatabase in a domain. | The legalStatus attribute of the INSPIRE Classic spatial object type AdministrativeUnits::AdministrativeBoundary is converted to the legalStatus field. It contains a value from the enumeration, for example, agreed. |
For attributes with a value that's a structure data type, (it's marked with the stereotype <<dataType>> or <<union>> in the INSPIRE Classic application schema), all attributes of the data type are converted separately. Be sure that all names are unique. | The inspireId attribute of the INSPIRE Classic spatial object type AdministrativeUnits::AdministrativeUnit is converted to the fields id_localId, id_namespace, id_versionId, and id_versionId_void. |
Some INSPIRE Classic spatial object types allow instances to carry a range of geometry types (for example, either a point, line string, or polygon). In the geodatabase, this requires using separate feature classes depending on the geometry type. As a result, these INSPIRE Classic spatial object types are converted to multiple feature classes with different geometry types. To maintain uniqueness of the feature class names and indicate the geometry type, a short code is added to the end of the feature class name: P for points, MP for multipoints, L for line strings or multiline strings, and S for polygons or multipolygons. | The property geometry of the INSPIRE Classic GeographicalNames::NamedPlace spatial object type is of the GM_Object (an arbitrary geometry) data type. As a result, the spatial object type is converted to gnNamedPlaceP, gnNamedPlaceMP, gnNamedPlaceL, and gnNamedPlaceS feature classes in the geodatabase. |
There are spatial object types in the INSPIRE Classic application schemas that have multiple geometry properties. In the geodatabase, however, every feature class can have only one geometry property. In these cases, an additional feature class is added that references the main feature class using a foreign key reference (RID field). | The INSPIRE Classic CadastralParcels::CadastralParcel spatial object type has two geometry properties, geometry and referencePoint. The geometry attribute is converted to the SHAPE field in the cpParcelS feature class and the referencePoint attribute in the SHAPE field in the cpParcelS_refPoint feature class. |
Data types with geometry properties are converted to feature classes, not object classes. | The AdministrativeUnits::ResidenceOfAuthority data type is converted to a feature class in the geodatabase, even if instances of the data type conceptually do not have an identity and are values owned by the parent spatial object type. |
Most INSPIRE Classicapplication schemas use generalization relationships between spatial object types. Geodatabases do not support generalization as used in UML models. However, they support the subtype concept that has similarities and is used for converting generalizations to the INSPIRE Classic geodatabase. The root class of an inheritance tree is converted to feature and object classes and all properties of their subtypes are converted to fields of them. An additional STYPE field distinguishes the type of each instance. The STYPE field must be set for all such instances. Depending on the instance, only the applicable fields are relevant. | The INSPIRE Classic Hydro - Physical Waters::DrainageBasin spatial object type and the Hydro - Physical Waters::RiverBasin subtype are both converted to the hypBasinS feature class. |
In some cases, the INSPIRE Classic application schemas use multiple inheritance. In these cases, the properties from the abstract supertypes are propagated to all subtypes. | The hydroId, geographicalName, and relatedHydroObject properties from the HydroObject are represented in the feature classes of all subtypes, for example, DrainageBasin (hypBasinS). |
The associations between INSPIRE Classic spatial object types depend on the multiplicity of the relationship. For 1:n relationships, a field with a foreign key reference is added directly in the feature or object class. An intermediate table (object class) is created for n:m relationships. The relationship class capability of geodatabases is not used to improve performance, in particular during data loading. In addition, geodatabases do not support relationship classes for reflexive associations. The relationship is accessible in ArcMap via other mechanisms. | The 1:n relationship upperLevelUnit/lowerLevelUnit between instances of AdministrativeUnits::AdministrativeUnit is converted to the upperLevelUnit field. The n:m relationship coAdminister/administeredBy between instances of AdministrativeUnits::AdministrativeUnit is converted to the auAdmUnit_admBySS intermediate table. |
Additional notes and default values
The INSPIRE Classic geodatabase template is based on the following:
- The coordinate reference system is EPSG:4258.
- In the conversion process, you may want to apply dataset-dependent rules. A specific case is the mapping of the data type GeographicalNames::GeographicalName. The INSPIRE Classic data specification states that different profiles can be used, depending on the requirements. The complete data type contains a comprehensive model that's only relevant for a few datasets. In most datasets, a significantly reduced model is sufficient—converting a geographical name to a string. By default, the geodatabase is configured for the easiest profile. For cases where a complex model for geographical names is required, for example, representing a name in multiple languages and scripts (for example, Athen, Athens, Athína, and Αθήνα), a configuration option is available for enabling the full GN profile for NamedPlaces.
- All geometries are limited to linear interpolation including the theme Cadastral Parcels, which allows the use of circular arc interpolation.
- The geodatabase contains all INSPIRE application schemas (with the exception of the unused gazetteer schema) by default, even if only selected application schemas are needed.
- For properties where values are structured types from ISO 19115, for example, CI_Citation, the value must be stored in ISO/TS 19139 XML directly in the geodatabase field. This implies that no structured queries are supported on these attribute values.
- The relatedHydroObject property in all spatial objects that inherit from HydroObject is converted using a special rule. The standard rule leads to an inappropriate number of intermediate tables for relationships in the geodatabase. The property is converted to a field that must contain the URI of the referenced spatial object instead of the IFCID of the object.
Documentation of the feature and object classes in the INSPIRE Classic geodatabase for Annex I
The complete description of the INSPIRE Classic geodatabase is provided as a collection of linked documents that can be viewed in a web browser. This is available in the INSPIRE Classic installation folder under the GDB Templates folder.
For each feature or object class associated with an INSPIRE Classic spatial object type, a separate XML document is provided. In large parts, the documentation is taken directly from the documentation in the INSPIRE Classic application schemas. Each document contains the following:
- Index to the sections of the document with links to them
- List and documentation of the INSPIRE Classic spatial object types that are converted to the feature or object class; this includes the subtype codes (STYPE field)
- Fields of the feature or object class with the name of the field, name of the source property in the INSPIRE Classic application schema, list of INSPIRE Classic spatial object types for which this field applies, data type in the geodatabase, and documentation of the property with additional remarks about the conversion to the geodatabase
- Dependent feature or object classes (to represent additional geometry properties or multiple attribute values) with documentation and the list of all associated fields
- Intermediate tables of the n:m relationships
Notes for Annex II and Annex III data themes
The following are the Annex II- and Annex III-specific geodatabase implementation guidelines. These are Annex II and Annex III specific and take precedence over Annex I rules:
- Feature classes belonging to a particular data theme are organized in a feature dataset for that data theme. This supports better navigation and expansion when many additional data themes for Annex II and Annex III are implemented.
-
The Annex II and Annex III Geology and Land Cover feature classes and tables don't use the IFCID as the unique identifier as in Annex I. Instead, each table has its own unique identifier and the following are true:
- In the Geology data theme, featureID is used by multiple tables and must be unique within the table and in the data theme.
- In the Geology data theme, mappedFeatureID and boreholeID together are used by multiple feature classes and must be unique within the feature class and in the geology data theme.
- In Annex II and Annex III, the geodatabase relationship class is used to model the relationship between feature classes and tables to leverage geodatabase relationships. In most cases, the same identifier name is used for primary key and foreign key references.
- _void fields are populated using the geodatabase domain VoidReasonValue in Annex II and Annex III.
- Because many of the code list values in Annex II and Annex III are dynamic, expandable, and unknown in advance, in most cases, in the INSPIRE Classic geodatabase, the code list values for Annex II and Annex III are implemented through the following three fields:
- _code—Contains the code for the code list
- _label—Contains the label for the code list value
_uri—Contains the URI reference for the code list value
- Some of the attribute data with unbounded multiplicity defined in INSPIRE Classic spatial objects has been flattened in the geodatabase structure to make data population, performance, and presentation easier.
- Documentation for each Annex II and Annex III data theme includes a data model diagram and a data dictionary document that's available in the INSPIRE Classic installation folder under the enterprise geodatabase templates folder.