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

6.7. Standardisation initiatives

environments (e.g. Corba, DCOM, Java, HTTP). UML is (mainly) used as basic language for the formalism of models defined in the Abstract and Implementation Specifications. Examples of Implementation Specifications are [159]:

•OpenGIS Location Services (OpenLS): consist of the composite set of basic services comprising the OpenLS Platform for location based services (mobile GIS).

•Catalog Interface: defines a common interface that enables diverse but conformant applications to perform browse and query operations against distributed and potentially heterogeneous catalog servers.

•Coordinate Transformation Services: provide interfaces for general positioning, coordinate systems, and coordinate transformations.

•Grid Coverages: designed to promote interoperability between software implementations by data vendors and software vendors providing grid analysis and processing capabilities.

•Simple Features - CORBA: provide application programming interfaces (APIs) for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point) using CORBA.

•Simple Features - SQL: provide application programming interfaces (APIs) for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point) using SQL.

•Simple Features - OLE/COM : provide application programming interfaces (APIs) for publishing, storage, access, and simple operations on Simple Features (point, line, polygon, multi-point) using OLE/COM.

•Geography Markup Language (GML 3.0): the Geography Markup Language (GML) is an XML (eXtendible Markup Language, see section 8.4) encoding for the transport and storage of geographic information, including both the spatial and non-spatial properties of geographic features.

Geography Markup Language

An example of GML code to describe a polygon in 3D space, is:

<gml:PolygonPatch>

<gml:exterior>

<gml:LinearRing>

<gml:coordinates>

105111.588,448909.588,9 105132.743,448884.341,9 105137.45,448888.285,12 105116.295,448913.532,12 105111.588,448909.588,9

</gml:coordinates>

</gml:LinearRing>

</gml:exterior>

</gml:PolygonPatch>

The conceptual model underlying the representation of geometry and topology in GML [155] is that of Topic 1 of the OGC Abstract Specification [152] (which adopted the ISO 19107 standard, see next section and chapter 7). The ISO model describes the correspondence of topological and geometrical relationships up to three dimensions. GML 3.0 [155] includes the ability to handle complex properties, to describe coordinates with x,y and z (already possible in version 1 and 2) and to define 3D

115

Chapter 6. Theory of spatial data modelling

objects. A topological volume in GML is described using the TopoSolid type. A TopoSolid type is defined by faces, faces are defined by edges and edges are defined by nodes. The user is free to choose where to explicitly store the geometry: at face, edge or node level. However, the topology has to be defined fully to node level. The user is also free to choose whether to define co-boundary relationships as well, i.e. the face-solid relationships, the edge-face relationships and the node-edge relationships.

OGC Web Services

OGC specifications also define several Web Service Implementations for disseminating geo-information across the Internet: Web Map Services, Web Feature Services, Web Coverage Services and Web Terrain Services. A service is a collection of operations, accessible to a user through an interface [156]. OGC compliant applications operating on user terminals (e.g. desktop, notebook, handset, etc.), can then “plug into” a server supporting the services to join the operational environment. Web Services are based on the general request-response rules used by Hypertext Transfer Protocol (HTTP). Support of GET and POST methods are available within this protocol. An example of a HTTP request is:

http://www2.dmsolutions.ca/cgi-bin/ mswms_world?SERVICE=WMS&VeRsIoN=1.1.1&Request=GetMap&LAYERS=WorldGen_Outline

The OGC specifications for Web Services describe how to define a request string to be appended to the URL sent to the specific Web Service. They also define what requests are possible and what the output format of the responses should be.

Web Map Services

The Web Map Service Specification (WMS) [153] was the first OGC Implementation Specification to standardise the way in which a client requests maps. Clients communicate with a WMS by sending a URL request (using the HTTP protocol) to a WMS instance via general Web Server software like Microsoft Internet Information Server or Apache. The URL contains the name of the layer and other parameters such as the size of the returned map as well as the spatial reference system to be used when drawing the map. The WMS defines three operations:

•GetCapabilities: the response to a GetCapabilities request is general information about the service itself and specific information about the available maps.

•GetMap: returns a map image with a defined spatial extent and spatial reference system.

•GetFeatureInfo (optional): returns information about features shown on the map based on the x,y position indicated by a click action of a user.

Web Feature Services

The next step was the Web Feature Service Specification (WFS) [154] that provides further extension of Web functionality, i.e. insert, update, delete and query of geographic features. A WFS delivers GML (vector) representations of features in response to queries from HTTP clients instead of image representations in case of a WMS. Clients access features through WFS by submitting a request for just those features that are needed for an application. A WFS can either be a basic WFS (read-only) or a transaction WFS. A basic WFS implements three operations:

116

6.7. Standardisation initiatives

•GetCapabilities: similar as in WMS.

•DescribeFeatureType: returns a schema of the data structure of the data set maintained at the data host on which the WFS has been implemented.

•GetFeature: returns a set of features in GML according to the query of the user based on spatial and non-spatial attributes of features.

With a transaction WFS it is, apart from querying features, also possible to insert, delete and update data. Therefore a transaction WFS implements, in addition to supporting all the operations of a basic WFS, the Transaction operation (and optionally the LockFeature operation).

Web Coverage Services

The Web Coverage Service Specification (WCS) [158] defines Web based access to raster data. The raster data can be delivered in image format and can be further processed, e.g. rendered by visualisation software at client-side or used as input into scientific models. Operations in WCS are very similar to WMS operations which work only on vector data.

Web Terrain Services

The Web Terrain Services Specification (WTS) [149] (not yet fully adopted as OGC specification) defines how to create views out of 3D data, like city models and digital elevation models. The view (3D scene) is defined as a 2D projection of 3D features into a viewing plane. The view is created based on input parameters, such as point of interest and horizontal angle between the north direction and the horizontal projection. The Service returns a rendered (2D) image of the 3D view.

We illustrate the working of OGC Web Services by showing the system architecture for a WFS and WMS (figure 6.5). A client sends a URL, defining a request, to a Web Server. The Web server sends the HTTP request to an OGC Web Service (WMS or WFS). The OGC Web Service translates the request and sends it to a data host. The data host sends the resulting dataset to the OGC Web Service, whereupon the OGC Web Service translates the resulting data set into a format understandable to the client, as an image in case of a WMS or GML format in case of a WFS. The OGC Web Service sends the image or GML file back to the client. To be able to view the data at the client, the client needs to be able to ‘understand’ the image respectively GML.

6.7.2ISO TC/211

The ISO Technical Committee 211 (TC/211): Geographic Information/Geomatics also defines standards related to GIS. TC/211 prepares geographic information standards in cooperation with other ISO technical committees working on related standards such as IT standards. The project no. 19107, Geographical Information: Spatial Schema defines a conceptual model of geometry and topology related to geographic features.

TC/211 is divided into several working groups. In total nine working groups have been started, while four of them have been disbanded since they achieved the goals of the specific working group [86]. Working groups that were disbanded are:

117

Chapter 6. Theory of spatial data modelling

Figure 6.5: System architecture for disseminating geo-information using Web Map and Web Feature Services.

•Working group 1: Framework and reference model

•Working group 2: Geospatial data models and operators

•Working group 3: Geospatial data administration

•Working group 5: Profiles and functional standards

Working groups that are still alive are:

•Working group 4: Geospatial services

•Working group 6: Imagery

•Working group 7: Information communities

•Working group 8: Location Based Services

•Working group 9: Information Management

Since 1997 ISO and OGC have worked together based on the large overlap of their area of interest. Today, OpenGIS Consortium is working, via formal liaisons, with ISO TC/211 to harmonise abstract and implementation specifications. OGC members have access to key ISO documents and contribute (indirectly) to their evolution and in turn some of the future OGC specifications (geometry, metadata) will essentially be ISO specifications repackaged under agreement. In the future, the same specifications will be published by both ISO and OGC (“i.e. double branding”).

118

6.8. Conclusions

6.7.3CEN/TC 287

In 1992 a special Technical Commission (TC) was erected as part of the European Commission of Normalisation (CEN, Comit´e de Normalisation) [21]: CEN/TC 287 Geographical Information. This TC ended her work in 1999 with the publication of a list of ENVs (European Norme Vorl¨aufig: tentative norms) in the area of geographical information aiming at the European market and society [1]. CEN/TC 287 was in process from 1992 to 1999. It was expected that ISO/TC 211 would take over the European working-programme of standardisation in the area of geographical information and that it was not necessary to have two TC’s. This was indeed the case when ISO TC/211 was erected. However now the European market has to decide how to include the ISO norms in current practise. Therefore in May 2003, CEN/TC 287 was brought back to live under the secretary of the NEN (Nederlands Normalisatie Instituut). The main goal of this new committee is to harmonise the ENVs developed in the nineties with the ISO TC/211 norms, developed since 1995 [1].

Also at national level initiatives on normalisation are developing. In the Netherlands a Geo-information Terrain Model was designed in 1995 [131]: NEN3610. This model was designed by the RAVI (Stichting Ravi netwerk voor geo-informatie) in collaboration with organisations and institutions. The aim of the NEN3610 model is to be able to easily exchange geographical information between di erent groups. The model describes objects at a global level. On a more detailed level NEN1878 and NPR3611 (practical regulations) have been developed. The project ‘Framework for Geo-information exchange’ (Framework voor Geo-informatie uitwisseling) will improve NEN3610, and replace NEN1878 and NPR3611 in order to better harmonise with international developments on open standards and in order to overcome the limitations of the current models [1].

6.8Conclusions

In this chapter the main topics of spatial data modelling were described. Applying these topics to the 3D cadastre research, a few concluding remarks can be made.

Object-based or field-based

For the 3D cadastre model an object-based (vector) approach instead of a field-based approach (raster) has been chosen for the spatial modelling part. The character of cadastral data (parcels, property) favours an object-based approach (no continuous character, identifiable objects, man-made objects). However, the terrain elevation aspects could be treated with a field-based model.

Core objects of a 3D cadastre

In 2D, the core object for a cadastre is the real estate object (parcel) that is registered in the cadastral system. A parcel is not always easy to identify in the field. The parcel has a relationship with persons via rights and/or restrictions as was seen in section 2.2.3. For the 3D cadastre, the objects to be considered are:

•representation of physical objects as they occur in the real world (tunnel, cable, pipeline);

119

Chapter 6. Theory of spatial data modelling

•‘property objects’, which are representations of 3D property units. Property objects are not always directly identifiable in the field, for example if a right of superficies has been established while the actual construction has not been built yet or when a right of superficies has been established for a tunnel which also includes a safety zone.

Phases of data modelling

In chapter 10 the conceptual model for a 3D cadastre will be described that has been designed during this research.

The next step is the translation of the conceptual model into the logical model (i.e. database structure of DBMS). As was seen in section 6.3.2 relational models have basic drawbacks when modelling the real world. Especially when modelling topological and geometrical characteristics of spatial objects. An object oriented approach overcomes these drawbacks. However, true object oriented DBMSs have only been implemented and used limitedly and object oriented technology still needs to be further developed and optimised, as was seen in this chapter. Object relational models, which are the compromise between the relational and the object oriented paradigm, are likely to be the leading DBMS technology for the next decades. In addition object relational models o er su cient functionality for the 3D cadastre domain. Therefore an object relational DBMS was selected for the 3D cadastre prototypes. Since this research does not aim at a complete operational application (although parts of a 3D cadastre have been developed in di erent prototypes) the logical model for a 3D cadastre will not be completely designed during this thesis. Only the main part of the data model will be translated into a logical model and implemented in prototypes. In chapter 11 principles of the DBMS model for a 3D cadastre will be considered, as well as what issues should be taken into account when designing the logical model for a 3D cadastre.

The physical model for a 3D cadastre is beyond the scope of this thesis.

120

Chapter 7

Geo-DBMSs

In section 6.6 it was concluded that DBMSs play a central role in the new generation GIS architecture. Within this architecture spatial and non-spatial information on objects is maintained in one integrated DBMS environment, called a geo-DBMS. This chapter describes how spatial information on objects can be structured in DBMSs and how this information can be used, e.g. in spatial analyses.

The OpenGIS Consortium adopted the ISO 19107 international standard [87] as Topic 1 of the Abstract Specifications: Feature Geometry [152]. These Abstract Specifications provide conceptual schemas for describing the spatial characteristics of spatial objects (geographic or spatial features, in OGC terms) with vector geometry and topology up to three dimensions embedded in 3D space. The Abstract Specifications also describe a set of spatial operations consistent with these schemas. According to the specifications, the spatial object is represented by two structures: 1) structure of geometrical primitives (i.e. simple feature) and 2) topological structure (i.e. complex feature). While the geometrical structure provides direct access to the coordinates of individual objects, the topological structure encapsulates information about their spatial relationships.

Geometrical primitives are a combination of geometry (coordinates) and a coordinate reference system. Topological primitives make use of id references to low dimensional primitives, e.g. a polygon refers to its edges and nodes. The coordinates are stored only with the low-dimensional primitives. In principle, topological primitives are introduced to accelerate the computational geometry algorithms replacing them with combinatorial ones. Topological primitives only have meaning within a topological model. The OpenGIS Abstract Specifications have been transformed into Implementation Specifications, of which the most relevant for this research is: the OpenGIS Simple Features Specification for SQL [148], which supports spatial objects up to two dimensions (in 2D and 3D space) in object relational DBMS environments. Mainstream DBMSs have adopted these Implementation Specifications.

This chapter describes how mainstream DBMSs can maintain spatial objects, using both a structure of geometrical primitives (section 7.1) and a topological structure (section 7.2). Section 7.3 describes spatial analyses that can be performed in DBMSs

121

Chapter 7. Geo-DBMSs

distinguishing between analyses that can be performed on geometrical primitives and analyses that can be performed on topological structure.

As will be seen in this chapter current support for 3D in DBMS is limited. Therefore, as part of this research a 3D primitive was implemented in a mainstream DBMS. The implementation will be described in section 7.4. When talking about 3D, the 2.5D representation of the terrain in a TIN (Triangular Irregular Network) structure should also be a topic of attention. The issue of TIN structures representing heights will be elaborated in chapter 9. This chapter ends with concluding remarks (section 7.5) including a discussion on which spatial analyses should be DBMS built-in functionality and which spatial analyses should be reserved for front-end applications.

7.1Geometrical primitives in DBMSs

Mainstream DBMSs (Oracle, [160], IBM DB2 [82], Informix [83] and Ingres [84]) and also popular non-commercial DBMSs such as PostgreSQL [172] and MySQL [122] have implemented spatial data types and spatial operators (also called ‘spatial functions’) more or less similar to the Simple Features Specification for SQL of OGC. The implementation described in the Specification for SQL consists of an SQL extension using ADTs that supports storage, retrieval, query and updating of simple spatial features (points, lines and polygons). The spatial features are stored in geometrical primitives. Topological relationships between geometries can be retrieved by the use of spatial operators (see section 7.3). OGC Implementation Specification for SQL has so far been in 2D. Also the implementations of spatial data types in mainstream DBMSs are based on supporting 2D primitives in 2D and 3D space. With the implementations of the geometrical primitive it is possible to store and query spatial features in a DBMS, but the relationships between neighbouring spatial objects is not standardised and can only be determined with a geometrical query. Also the geometrical primitive causes redundancy in the case of a planar partition such as a cadastral map: shared edges and shared nodes are stored twice. In this section we distinguish between 2D (section 7.1.1) and 3D geometrical primitives (section 7.1.2). To illustrate how spatial objects can be maintained in DBMSs, Oracle Spatial 9i is used. Oracle Spatial 9i is not fully OGC compliant, since the spatial ADT as defined in Oracle di ers slightly from the ADTs as defined by OGC. The OGC Implementation Specification for SQL defines separate data types for di erent types of geometry (points, linestrings, polygons etc.) while Oracle Spatial has only one data type for all types of geometry. Oracle is OGC compliant at level 1 (relational encoding of geometry) and not at level 2 (types and functions). However, the experiments show generic aspects for supporting geometry in a DBMS.

7.1.12D geometrical primitives in DBMSs

The supported spatial features in Oracle Spatial 9i are points, lines and polygons (including arcs, boxes and mixed geometry sets in 2D and 3D). The object relational model in Oracle defines the object type sdo geometry as:

122

7.1. Geometrical primitives in DBMSs

An example of using the Oracle object relational model to represent a polygon is shown in figure 7.1. In sdo gtype=2003, the first position indicates the dimension (2D in this case), the last position indicates the element type (3 indicates a polygon). In sdo elem info, the combination ‘1003,1’ indicates that this is a polygon containing straight lines (’1003’ for polygon, and ‘1’ for straight lines). The first position in ‘1,1003,1’ (’1’ in this case) indicates that the first (and only) element starts at o set 1 in the coordinate list.

Figure 7.1: Example of storing a polygon using Oracle’s spatial data type.

The next SQL statements illustrate how a box with 0,0 as lower-left and 100,100 as upper-right coordinates is stored in Oracle (sdo geometry type) in the ‘geom2d’ table. Another way to represent a box is with a special element type in the sdo elem info array by which only the lower-left and upper-right coordinates are needed (which is not illustrated in this example).

/* creation of the table */

CREATE TABLE geom2d (shape mdsys.sdo_geometry not null, ID number(11) not null);

/* inserting data (2D box) */ INSERT INTO geom2d (shape,id) VALUES (

mdsys.SDO_GEOMETRY(2003, NULL, NULL, mdsys.SDO_ELEM_INFO_ARRAY(1, 1003, 1), mdsys.SDO_ORDINATE_ARRAY(0,0, 100,0, 100,100, 0,100, 0,0) ), 8);

123

Chapter 7. Geo-DBMSs

Besides the tables representing the geometries of the objects, metadata can be maintained describing the dimension, lower and upper bounds and tolerance in each dimension. In the following statements the information on the table geom2d is inserted in the metadata table. Finally, a spatial index (in this case R-tree, but a Quad-tree spatial index is also possible in Oracle Spatial) is created on the table (to speed up spatial queries). A spatial index can only be built when metadata has been inserted for the specific table:

/* inserting metadata, 2D table*/

INSERT INTO user_sdo_geom_metadata VALUES (‘GEOM2D’, ‘SHAPE’, mdsys.sdo_dim_array( mdsys.sdo_dim_element(‘X’, 0, 500, 0.5), mdsys.sdo_dim_element(‘Y’, 0, 500, 0.5) ), NULL);

/* creating index */

CREATE INDEX geom2d_i ON geom2d(shape) INDEXTYPE IS mdsys.spatial_index; ANALYZE TABLE geom2d COMPUTE STATISTICS;

7.1.23D geometrical primitives in DBMSs

2D primitives are also supported in 3D space, for example a ‘geom3d’ table can be created by the following query in Oracle:

/* creation of the table */ CREATE TABLE geom3d (

shape mdsys.sdo_geometry not null, ID number(11) not null);

Note that the commands to create a 2D table and a 3D table are the same. The following query inserts the box as used in the 2D example with a height of 50:

/* inserting data, a 3D box *

INSERT INTO geom3d (shape, id) VALUES ( mdsys.SDO_GEOMETRY(3003, NULL, NULL, mdsys.SDO_ELEM_INFO_ARRAY(1, 1003, 1),

mdsys.SDO_ORDINATE_ARRAY(0,0,50, 100,0,50, 100,100,50, 0,100,50, 0,0,50) ), 9);

Metadata can be inserted after which a spatial index (R-tree in 3D) can be created on the ‘geom3d’ table:

/* inserting metadata, 3D table*/

INSERT INTO user_sdo_geom_metadata VALUES (‘GEOM3D’, ‘SHAPE’, mdsys.sdo_dim_array( mdsys.sdo_dim_element(‘X’, 0, 500, 0.5), mdsys.sdo_dim_element(‘Y’, 0, 500, 0.5), mdsys.sdo_dim_element(‘Z’, 0, 300, 0.5) ), NULL);

/* creating index */

CREATE INDEX geom3d_i ON geom3d(shape)

INDEXTYPE IS mdsys.spatial_index parameters(‘sdo_indx_dims=3’); ANALYZE TABLE geom3d COMPUTE STATISTICS;

124