Экзамен зачет учебный год 2023 / Stoter, 3D Cadastre

5.6. Conclusions

when more than one real right is established on one parcel, it is possible to see that it concerns a 3D situation. In those cases it is possible to query which rights and persons are involved. However, no 3D overview of the situation can be obtained.

Also abroad no solutions have been found to incorporate the 3D geometry of 3D property units in the cadastral registration. Current cadastral registrations all lack a fundamental approach for 3D cadastral registration by combining juridical, cadastral as well as technical aspects with respect to 3D situations.

From this chapter the essential elements for a 3D cadastre can be defined. A 3D cadastre should be able to:

•maintain the spatial extent of real rights, and provide information on the spatial extent of real rights;

•establish and manage a link with external databases that contain objects that are of interest for the cadastre (infrastructure objects, monuments, soil pollution zones etc.);

•use information on these objects in the work processes of cadastral registration.

Registration of 3D situations o ers other opportunities as well. Once 3D information on situations is accessible (e.g. from the cadastral registration based on links with other registrations via the GII), this information can be used in other applications and vice versa. For example, exact information on the location of cables, pipelines and tunnels o ers opportunities to use this information in the management (planning activities) of the subsurface.

The remainder of this thesis aims at meeting the needs of cadastral registration (with the main focus on cadastral registration in the Netherlands) by studying possibilities and constraints to establish a 3D registration both from a technical and a cadastral point of view. The proposed solutions for a 3D cadastre should fit to some extent in the current juridical framework of the Netherlands.

95

Part II

Framework for modelling 2D and 3D situations

97

Chapter 6

Theory of spatial data modelling

This chapter presents an overview of the basic concepts and terms in spatial data modelling. The aim is to familiarise the reader with concepts used in this thesis. First data models and in particular characteristics of spatial data models are described (section 6.1), followed by a description of the di erent phases in data modelling including their characteristics (section 6.2 to 6.4). UML (Unified Modelling Language) has become a standard to represent data models and is used to represent the data models in this thesis. Therefore a short introduction into UML is also included in this chapter (section 6.5). DBMSs are essential systems in spatial data modelling and in the new generation GIS architecture. Section 6.6 describes how the relationship between spatial data modelling in GISs on the one side and in DBMSs on the other side has evolved. Finally when looking at spatial data models, the standardisation initiatives on spatial data modelling are important, which are described in section 6.7. The chapter ends with concluding remarks.

6.1Data models

The term ‘model’ is a frequently used term in many disciplines. Models in general are used to make an abstraction of reality with the aim to make reality understandable. Data models are intended to interpret the world in a way that is understandable to computers [223]. A data model is a generic blue print (structure); the data model can be populated with instances (data) to come to an abstraction of reality for a specific application. Data models consist of:

•classes;

•attributes;

•relationships;

•constraints;

•operations.

99

Chapter 6. Theory of spatial data modelling

Classes and objects

In data models classes are abstractions of phenomena in the real world that can be identified, e.g. parcels, persons, buildings. Objects are instances of classes. An object instance has at least a unique id, which is in principal meaningless but which can be used in references. In data models, the term object does not refer to objects as they occur in the real world, but to the representation of the real-world objects, which may be very confusing. The representations can be maintained in a DBMS. For example a road can be referred to as an object, i.e. the representation of the road. The object, containing both spatial and non-spatial attributes, can be maintained in the DBMS (e.g. line, with attributes such as owner, type of asphalt etc). Objects are basic elements in object oriented modelling (see section 6.3.2).

Attributes

Objects have attributes in which the property of the objects is described, e.g. a land parcel can have ‘area’ or ‘land use’ as an attribute.

Relationships

In the data model, relationships exist between the objects, identifying how the objects are related. For example a land parcel has a relationship with person: a parcel is owned by a person. There are three kinds of relationships with respect to cardinality: one-to-one, many-to-one, many-to-many. The objects can be structured in a class hierarchy. Objects that are derived from other objects have either a ‘is-part-of’ or a ‘is- a’ relationship with the objects they are derived from. The first type of relationships is called ‘aggregation’ and the second type is called ‘specialisation’.

Constraints

A constraint is a limitation on objects or on relationships in the data model, e.g. ‘the age of the object person must be more than zero’. Consistency constraints can be used to prevent any logical contradiction within a model of reality [48]. This is not the same as correctness, which excludes any contradiction with reality itself. Consistency constraints are used to enforce the logical consistency of the data model. Consistency constraints can be organised into two groups [213]:

•Inherent constraints, which are incorporated in the definition of the data model. The model can disallow certain objects or limit certain relationships by its definition. For example if the data model does not define relationships between a parcel and a subject, this relationship cannot be maintained.

•Explicit constraints, which are not part of the data structure but which need to be explicitly defined, e.g. the constraint that an employee cannot earn more than his manager.

Operations

The operations describe all the actions that can be performed on objects. Here we focus on operations in DBMSs. Four generic DBMS operations on objects using the Data Manipulation Language are distinguished in the database literature [213]:

•retrieve: make a whole data set available to the user;

•insert: add new data to the database;

•delete: remove data from the database;

•update: change existing data.

100

6.1. Data models

Apart from these generic operations, in [213] three other supporting operations in DBMSs are distinguished:

•selection: retrieve operation under a particular condition;

•navigation: operations that permit a logical path on the basis of a selection to be followed;

•specialisation: complex operation that allows a new object to be created on the basis of existing ones.

Note that the term specialisation is also used to denote a special type of relationships in data modelling as was mentioned above.

6.1.1Data models in GIS

In GIS, a data model is the structure used to identify and represent objects referenced by space relative to the earth surface [186]. Models of spatial information are usually grouped into two broad categories: field-based models (raster) and object-based models (vector).

In the field-based model, the world is modelled as a regular tessellation (raster), which is sampling based. For example height can be modelled in a field-based approach in which each point in space has exactly one value of height. Field-based models are often used to model continuous spatial trends such as elevation, temperature, and soil. In object-based models, the focus is to abstract spatial information into distinct, identifiable and relevant things or entities called objects. Individual objects are modelled together with their attributes. Object-based models are often used for man-made objects and are common in modelling transportation networks (roads), land parcels for property tax and legal ownership-related applications.

Objects in GIS

Traditionally geo-sciences focus only on real-world phenomena with a spatial extent. It is therefore relevant to distinguish between spatial (or spatial-temporal) objects and non-spatial objects. A spatial object is the representation of a real-world object having spatial (topology, size and shape, position and orientation) and thematic characteristics [6, 112, 118, 169]. A spatio-temporal object has three fundamental components: location (spatial), attributes (aspatial) and time (temporal) [233].

Till recently GIS models maintained only spatial objects, while non-spatial objects, such as subjects or rights in a cadastral context, were maintained in DBMSs or were integrated in GIS as semantic characteristics of spatial objects. However, integrated architectures are evolving in which both spatial and non-spatial objects are maintained in one integrated DBMS (see section 6.6).

Relationships in GIS

In spatial data models, spatial relationships exist. Spatial relationships describe the relationships between the geometric elements of spatial objects. In spatial modelling, spatial relationships serve two main purposes:

•to find the spatial relationships between two spatial objects (used in querying), e.g. find all parcels that are adjacent to a certain parcel;

101

Chapter 6. Theory of spatial data modelling

•to enforce the consistency of a model by formulating consistency constraints using spatial relationships (used in modelling and editing), e.g. two parcels should not overlap.

Spatial relationships can be classified as topological or geometrical. Topological relationships describe the connectivity, containment and adjacency relationships among spatial objects. These relationships are invariant under topological transformation, such as translation, scaling and rotation [234]. Geometrical relationships are described in terms of distance and directions and depend on the absolute positions of objects relative to a given reference system [234].

Constraints in GIS

In spatial data models, consistency constraints can be used to enforce spatial characteristics. For example topological constraints can enforce that lines only intersect at nodes and parcels shall not overlap. Semantic constraints can enforce spatial characteristics that are dependent on semantics, e.g. a building area should always be adjacent to a street [26]. Semantic constraints are application dependent.

Operations in GIS

Operations on spatial objects can be performed on both the spatial characteristics and the thematic characteristics of the objects or on a combination of these characteristics. Here we focus on operations on spatial objects maintained in spatial models in DBMSs. DBMSs have a strictly defined functionality based on relational algebra and calculus [176] and were originally not designed to manage spatial objects. The traditionally available operations have to be ‘translated/extended’ into the spatial domain to be able to handle spatial objects. As was seen, four basic operations are distinguished in the database literature [213]: retrieve, insert, delete and update. A similar set of operations (but more elaborated) has to be available for spatial data. The operations related to introducing a new element, deleting and updating an existing one have to be extended with respect to the data structure used. In [186] four groups of operations related to DBMSs are distinguished that use the geometrical characteristics of spatial objects:

•Update operations: standard DBMS operations such as insert, delete, modify, etc.

•Select operations: e.g. ‘retrieve all parcels that overlap with this pipeline’. Three basic groups of selection operations with respect to spatial objects can be defined to be o ered at DBMS level:

–Metric operations: selection operations that require computations of geometrical properties, e.g. compute distance, volume, area, length and centre of gravity. Metric operations need coordinates of the spatial objects and the result is always quantitative. Metric operations are unary operations and should not be confused with metric relationships, which are binary operations.

–Proximity operations: selection operations related to spatial location, e.g. objects in a certain area, volume or field of view.

–Relationship operations: selection operations based on spatial relationships between objects.

•Spatial join: like the join operator in relational databases, the spatial join is one of the more important operators. When two tables are joined on a spa-

102

6.2. Conceptual model

tial predicate (intersect, contains, is-enclosed-by, distance, northwest, adjacent, meets), the join is called a spatial join. This is equivalent to the map overlay in GIS. The operations combine two sets of spatial objects to form a new set. An example is ‘find all natural areas and forest areas that overlap’.

•Spatial aggregate: retrieve spatial objects based on spatial characteristics of other spatial objects; an example is ‘find the station closest to this building’.

The spatial join and the spatial aggregate are actually complex select operations.

In addition to these operations, the DBMS has to o er supporting operations such as navigation and specialisation. Navigation is an operation that is handled internally by the DBMS, e.g. follow pointers. Examples of spatial navigation related operations are route planning (which require multiple topology operations ‘meet’) and shortest path (which require multiple topology operations ‘meet’ and multiple metric operations ‘distance’). Specialisation operations are operations that create new objects on the basis of existing ones, which is a di erent meaning than the specialisation relationship in data modelling. A specialisation within the spatial domain would be when the user provokes the creation of a conglomerate called ‘university’ of several existing buildings. Bu er, convex hull, union of objects and all types of generalisations fall in the group of specialisation operations.

6.1.2Design phases in modelling

A data model is a structure to capture an abstraction of reality for a specific application. In designing a data model three phases are distinguished in literature which have their own data model associated with them [213, 223]:

•a conceptual model (section 6.2);

•a logical model (section 6.3);

•a physical model (section 6.4).

6.2Conceptual model

In the conceptual phase all classes that need to be included in the data model are identified, together with the characteristics and relationships of the classes. The aim of the conceptual model is to demarcate the part of the real world which is relevant for the specific application. The model has a high abstraction-level since it is the basis of the conception process. It consists of a schematic representation of phenomena and how they are related. The conceptual model not only provides a basis for schematising but is also a tool for discussion and, as such, a good conceptual model must be easily understandable. The model sharing may be done by using narrative language, but the transfer to the next stage is easier if a more formal language is used [99]. Till recently ER (Entity Relationship) [23] has been a popular tool for designing the conceptual data model. In the ER model, the world of interest is partitioned into entities (objects), which are characterised by attributes and interrelated relationships. Associated with the ER model is the ER diagram, which gives a graphic representation to the conceptual model. In the ER diagram entities are represented as

103

Chapter 6. Theory of spatial data modelling

boxes, attributes as ovals connected to the boxes and relationships as diamond boxes. Recently UML (Unified Modelling Language) has become a standard for conceptual (and logical) model design. The UML class diagram is the counterpart of the ER diagram. UML will be discussed in more detail in section 6.5.

6.3Logical model

In the phase of logical design the conceptual model is translated into a logical model. In this phase the conceptual schema is translated into the data model of a particular type of DBMS. Often the term logical model is associated with data structure, since in this phase the database structure is designed. Three types of database models are distinguished here (other examples are network models and hierarchical models): relational model, object oriented model and object relational model. These models will be described respectively in sections 6.3.1, 6.3.2 and 6.3.3.

6.3.1Relational model

The relational model was introduced by Codd [27]. A relation is an organised assembly of data that meets certain conditions. A relational database is a collection of relations. A relation has a number of attributes or data items representing some property of an entity. Relational models have been widely adopted by the market and have been implemented in mainstream DBMSs.

A table in a relational database represents a relation, and each column of a table is called an attribute. An object type can be defined by one or more relationships. The relationships between tables are established by keys. A key is an attribute (or combination of attributes) that contains unique values for each row in the table. Certain constraints on the relational schema must be maintained to ensure the logical consistency of the data. Three kinds of constraints can be distinguished:

•Key constraints. The key constraint specifies that every relation must have a primary key. There may be several keys in a relation. The one that is used to identify the entities is the primary key.

•Entity integrity constraints. The entity integrity constraint states that no primary key can be null.

•Referential integrity constraints. Logically consistent relationships between the di erent relations are maintained through the enforcement of referential integrity constraints. This constraint can be implemented using a foreign key. A foreign key is a set of attributes in a relation that is duplicated in another relation. The referential integrity constraint stipulates that the value of the attributes of a foreign key either must appear as a value in the primary key of another table or must be null. Thus a relation refers to another relation if it contains foreign keys.

Data definition and data manipulation of relational models can be done with the Structured Query Language (SQL). A short introduction into SQL follows below.

104