• Thorsten Reitz
Inheritance is a mechanism for reuse of software components, be it structure or behaviour. In object-oriented designs such as INSPIRE, inheritance is when a child class is based on a parent class. The child class inherits all the properties and methods from the parent class, which makes the child class usually interoperable to the target class. A child class can also override behaviour and in some cases structure of the parent class, making it at least partially incompatible to the parent class.
Inheritance establishes a clear hierarchy, which can be many levels deep. The parent class can have a grand-parent class, which can have a great-grand-parent class. All parents and further ancestors together are called superclasses of a class, while all children and grandchildren and further descendants are called subclasses. In INSPIRE GML, we have inheritance hierarchies up to eight levels deep. As a consequence, when we create a new class that inherits from an INSPIRE class, it will inherit every property defined on one of those superclasses.
Redefine is a special type of inheritance, where properties of the supertype can be modified in the subtype. You can use
Redefine to rename properties, e.g. to translate them from English to your native language. It’s also possible to change the type of a property, e.g. from a
Point to a
We recommend not to use
Redefine, as current implementation platforms can’t make use of the redefine information. As a result, interoperability is reduced.
In this pattern, there is a parent class and a child class. They are connected through a Generalisation association which points from the child to the parent:
When to use
The primary use case that you can solve well with inheritance is when your objects are conceptually very similar to the concept of the INSPIRE class, and you just want to add a few attributes.
Inheritance is furthermore an easy way to achieve compatibility of your new classes with the respective INSPIRE classes. Your data will have additional information that goes beyond what INSPIRE mandates, which is allowed. Inheritance is particularly useful when…
- You want to use one system for managing and publishing INSPIRE data and your extended data
- You want to create an association from an existing INSPIRE class.
- When there is not just a syntactic relationship, but also a semantic relationship between the child and the parent. This relationship is called a subtyping relationship and is usually read as child
- You want to automatically keep your model compatible when superclasses change.
Inheritance should only be used when the following conditions are met:
- Parent and child classes are in the same logical domain.
- The superclass’s implementation is necessary or appropriate for the subclass.
- The enhancements made by the subclass are primarily additive and don’t override the parent’s behaviour.
When not to use
Inheritance is a static relationship type with strong coupling. Many of the reasons not to use inheritance derive from that strong coupling:
- You don’t want to bring in complexity inherited from a large set of superclasses.
- You don’t want to inherit any changes from the imported superclasses.
- There is no
is-arelationship between your class and the INSPIRE class.
- Your class should have an equal relationship with multiple INSPIRE classes (or other classes from a local standard).
XML Schema Example
A potential schema structure for the inheritance pattern is as follows:
The key lines to look at are 9 and 12:
- In line 9, we use
substitutionGroup="cp:CadastralParcel"to indicate that
JoinedParcelcan be used in any place in an XML document where a
CadastralParcelwould be allowed.
- In line 12, we make
JoinedParcelinherit all properties from
|Due to the focus on the inheritance pattern, this example uses an in-place encoding of
XML Instance Example
Instances using this pattern have a simple structure in which the inheritance hierarchy is not apparent:
This section provides information when and how this pattern can be implemented on different types of platforms.
There is usually no support for inheritance on relational or document-oriented platforms. Some platforms, such as Esri’s Geodatabases, support a weaker form of subtyping, where all classes have the same property and differ in just one field value. This form of subtyping is suitable for sets of objects that are similar in data structure, but different in a classification value. An example for weak subtyping is a Road hierarchy, which can have different classes (regional, national, highway).
Nonetheless, an inheritance hierarchy can be mapped to a relational or document-oriented structure, and thus maintained. Three common approaches for such mappings include:
- Table per class hierarchy: Use one single table or document collection for all objects of all classes that are part of a given inheritance hierarchy. This can result in sparsely populated tables.
- Table per subclass: Use a separate table for every subclass in the hierarchy, even for abstract classes (classes such as
AbstractFeatureTypefor which no objects are created, but which are used to built efficient hierarchies). This approach preserves the design structure well, but results in lots of database joins to deliver complete objects.
- Table per concrete class: Use a separate table for each concrete class in the hierarchy, with all fields they inherit from their respective superclasses. This approach doesn’t preserve the design structure, but delivers higher performance, since no joins are required.
This pattern can be implemented on XML-based platforms without special considerations.
This pattern can be implemented on object-oriented platforms without special considerations.
Most GIS client applications do not make use of inheritance information and just process the instances as they are.
Examples in the Model Inventory
- Geological Database of Catalonia (1:250000)
- ZSIN - the Integrated System of Information about Real Estates
- Geographic Reference Information - Hydrography
- SOSI Vegnett (Road Network) and Linear Referencing
- Redes de Transporte (Spanish Transport Networks)
- INSPIRE for Dutch Provinces
- LISA (Land Cover)
- IMKL2015 (Information model cable and pipelines)
- EAGLE Data Model
- GeoSmartCity Buildings 2D-Energy
- GeoSmartCity Extended Utility Networks
- ELF Data Model
- SOSI Planned Land Use
- Example Model 2
- Example Model