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

9 rows selected.

A PL/SQL script has been written to generate the spatial description (topology and geometry) of the 3D right-volumes which is linked to the non-spatial information.

Topological structure DBMSs do not (yet) support topology structure management (2D nor 3D). Therefore, the topological structure has to be defined in a DBMS by means of user-defined references. For the prototypes we use the Simplified Spatial Model of [240]. A 3D geometry object is therein defined as a polyhedron consisting of nodes and faces (see section 7.2.4). A PL/SQL script was written to generate the BODY, FACE and NODE table based on the z-list containing height values of properties on one parcel and the geometry of the parcel. In this model the faces within one parcel are shared between bodies as it should be in a full topological model and nodes are shared between faces.

From topology to geometry To realise the geometry of the 3D right-volumes, based on the topological tables, a function has been written. In this function the nodes of one 3D right-volumes are retrieved by the following query (see section 7.2.4) whereupon the 3D geometry is reconstructed:

/* for the body bid=1*/

SELECT body.bid,face.fid, face.seqn, node.nid, node.x, node.y, node.z FROM body, face, node WHERE body.bid=1;

Having the geometry it is possible to visualise, query and edit the data in GIS and CAD software and to perform spatial queries in the DBMS.

Geometrical primitives The geometry of 3D right-volumes is generated by means of the implemented realisation function and be made available in a view. The realised geometry of 3D right-volumes can be defined as a polyhedron data type as it is possible within current techniques: either as a set of polygons in 3D or as a multipolygon defined in 3D. For the prototypes we used the multipolygon representation since this representation is recognised as one object by front-ends. As part of the implementation of the 3D primitive in the DBMS (section 7.4), a conversion tool has been written to convert 3D objects stored as multipolygons into the 3D polyhedron primitive. For the 3D right volume with bid=3 (which is the 3D right-volume on parcel 13290), this looks as:

255

Chapter 12. Prototypes applied to case studies

SELECT return_polyhedron(shape) FROM dh_multipol WHERE bid=3;

RETURN_POLYHEDRON(SHAPE)

------------------------

(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_GEOMETRY(3002, NULL, NULL,

--3002 refers to geometrytype: (fictive) 3D polyline

--in sdo_elem_info_array the elements are listed, first triplet is a line,

--followed by the (outer) faces (starting offset, e_type, interpretation code) SDO_ELEM_INFO_ARRAY(1, 2, 1, 67, 0, 1006, 78, 0, 1006, 82, 0, 1006, 86, 0, 1006, 90, 0, 1006, 94, 0, 1006, 98, 0, 1006, 102, 0, 1006, 106, 0, 1006, 110, 0, 1006, 114, 0, 1006, 118, 0, 1006, 122, 0, 1006),

--in the oridinate array, first the vertices are listed

SDO_ ORDINATE_ARRAY(82140054, 455389862, 0, 82124400, 455378306, 0,

Once a 3D right-volume is defined with the 3D polyhedron primitive, the implemented 3D functions can be performed on it, such as a validation, 3D area or 3D volume calculation (in this case in mm3):

SQL> SELECT bid, volume(return_polyhedron(shape)) FROM dh_multipol;

BID VOLUME(RETURN_POLYHEDRON(SHAPE))

-----------------------------------

11.6024E+13

25.3413E+12

31.1888E+13

44.6118E+11

55.7372E+11

66.6815E+11

76.6815E+11

82.6769E+11

92.6769E+11

106.8230E+11

116.8230E+11

121.0486E+12

131.0486E+12

144.6100E+13

154.6100E+13

15rows selected.

Topological model compared to geometrical primitives Disadvantages of using a topological model are:

256

12.1. Prototypes of the hybrid cadastre

•The data model needs three tables instead of just one (as in the multipolygon or polyhedron case).

•Since the DBMS does not recognise topology, inserting the data is one thing, but updates require a lot of e ort and experience or other software. Also the consistency of the data has to be checked by other software (until DBMSs o er topology structure management in 3D).

•Querying can be di cult at SQL level (topology is not recognised by DBMSs), for geometrical queries it is always necessary to generate a realisation of the object, instead of being able to use the spatial queries available in the DBMS directly.

Another problem that was mentioned in chapter 7 is the required storage capacity of the topological structure compared with the storage capacity needed for the geometrical primitives. Every row in the tables defining the topological structure has its overhead, also the references require a lot of storage capacity. To illustrate this we queried the storage capacity needed for the tables of the topological structure in the case of The Hague Central Station, which is twice the storage capacity needed for the polyhedron representation.

Advantage of the topological structure is that topology structure management can be used in the storage and the retrieval of data. For example, by means of the shared (horizontal) faces one can easily find the upper and lower neighbours of a 3D rightvolume.

Evaluating 3D right-volumes for The Hague Central Station

The visualisation of the 3D right-volumes for The Hague Central Station (figure 12.3 (a)) gives a clear insight of the various rights in the building complex. It not only gives an indication of the spatial extent of the property rights on each of the parcels concerned, it also shows the relation between the rights established on adjacent parcels. The 3D map of The Hague Central Station (classified on subject) clearly shows that the municipality of The Hague is not only holding the right of superficies on parcel 13295 (the big parcel in the centre, with the railway platforms on ground level), but also on parcels 13291, 13292, 13293 and 13294 (see the cadastral map in figure 12.3 (b)). At one glance one can see that the municipality is owner of the bus/tram station on the second floor, with the adjacent entrances at left and right hand side of the railway station. This is an advantage compared to the traditional 2D cadastral map. More advanced visualisation techniques may be needed in complex clusters of 3D right-volumes (e.g. make certain 3D right-volumes semi-transparent).

In this case the space of the railway platforms on parcel 13295 is visualised, however in the strict definition of 3D right-volumes (right-volumes only relate to positive rights) this is not correct. The space occupied by the railway platform belongs to the space that is left for NS Railinfratrust BV after the space related to the right of superficies has been subtracted from the infinite parcel column. The 3D right-volumes on parcel 13288, 13289 and 13290, which also have been related to the construction as built, are also visualised. This is also not correct according to the definition of 3D right-volumes since these parcels are hold in full ownership.

Again the limits of the 3D right-volumes are related to the construction as built. However it would be better to define the limitations in the deed based on 3D survey plans.

257

Chapter 12. Prototypes applied to case studies

(a) 3D representations of right-volumes.

(b) 2D cadastral map

Figure 12.3: Cadastral representation (2D and 3D) for The Hague Central Station.

For example who owns the space above the bus/tram station and the space below the railway platform? At the moment this seems not a relevant question. However if a business company wants to build a business centre on top of the bus/tram station, the ownership of the space above the tram/bus station will become an important issue.

3D physical objects

The 3D map in figure 12.3 only shows the 3D right-volumes and not the physical objects (although in this case the 3D right-volumes are related to the physical objects). The physical objects in the case of a physical object registration are maintained to visualise constructions, not subdivided by parcels that are crossed. In some cases the physical object coincides with a (conglomerate of) 3D right-volume(s). This is also the case for the The Hague Central Station where 3D right-volumes are related to the construction as built due to lack of other information. For example the physical

258

12.1. Prototypes of the hybrid cadastre

object for the bus/tram station is a combination of the 3D right-volumes established for the bus/tram station including the entrances on parcels 13291, 13292, 13293, 13294, 13295. In case of the railway platform, the whole platform (or railway) would be registered as one 3D physical object also on parcels that are in full ownership of NS Railinfratrust BV. Normally, the collection of 3D right-volumes that refers to a whole real estate object embraces the space occupied by a 3D physical object. Except on parcels for which no cadastral recording of the 3D situation has taken place since on those parcels no 3D right-volumes are established.

12.1.3Case study 3: Apartment complex

3D right-volumes

The case of the apartment building is more complex, since on the ground floor there are three apartment units and on the first and second floor two units, all established on one parcel. Furthermore the building covers not the whole parcel. This is quite common for apartment complexes. Consequently the footprints of the apartment units on every floor do not coincide with the parcel boundary.

To be able to apply the z-list with upper and lower limits of rights established on one parcel, the 2D boundaries of the individual apartment units are generated, which resulted in the 2D objects as shown in figure 12.4, with object ‘a’ (whole building minus ‘b’ and ‘c’), objects ‘b’ and ‘c’ defined for the ground floor and object ‘d’ and ‘e’ (both half of the building) defined for the first and second floor. The garden-area (which belongs to the apartment unit on the ground floor) and the space above this area are not included in the 3D right-volumes, although this could have been done.

Figure 12.4: The generated 2D objects: footprints of individual apartment units on every floor. The grey part is the extent of the building.

The 3D right-volume table for the whole apartment complex is as follows:

259

Chapter 12. Prototypes applied to case studies

’Parcel’ does in this case not refer to parcel numbers but to the 2D polygons of apartment units generated to define inner boundaries of the apartment units in order to be able to extract them in 3D. The drawings added to deeds of subdivision could be used to construct the 2D footprints, that is to say when the spatial information on the drawings is defined in (or can be transferred into) world-coordinates and in vectorformat. The visualisation of the generated 3D right-volumes is shown in figure 12.5.

(a) All apartments in the street

(b) The apartment complex of the case study which is the second complex from right

Figure 12.5: Apartments as 3D right-volumes. The horizontal lines between the first and second floor are for visualisation purposes.

260

12.1. Prototypes of the hybrid cadastre

This case shows some complications. Not only a horizontal division of the parcel column is needed to define the 3D right-volumes but also a vertical division of the parcel area (dividing the parcel into smaller parts). If only one 3D right-volume were to be established for the whole parcel area, it would not reflect the real situation and it would definitely not provide a clear picture of the situation (3D right-volumes would overlap) which is one of the main aims of 3D registration. However the generation of the smaller parts (footprints of apartment units) is a change in the concept of 3D right-volumes if they have the same legal status as ‘normal’ (traditional) parcels.

3D physical objects

The physical object registration would in this case be the same as the 3D right-volume registration in which the 3D right-volumes are related to the apartment units. The apartment units are the physical objects that would be identified as registering objects in the physical object registration. Although it can be disputed if a 3D physical object registration is appropriate for apartment units, since the main objective of a 3D physical object registration is to provide more insight into locations containing infrastructure objects (crossing parcel boundaries and mostly meant for public good) rather than to improve insight into private property situations.

12.1.4Case study 4: Railway tunnel in urban area

3D right-volumes

The 3D right-volume table for the railway tunnel in Rijswijk is as follows (for the parcel numbers see figures 3.8 and 3.9):

7854: Z ARRAY(-20, 0, 4) –tunnel with kiosk on top of it

7855: Z ARRAY(-20, 0, 4) –tunnel with kiosk on top of it

7857: Z ARRAY(-20, 0, 12) –tunnel with railway station on top of it

7944: Z ARRAY(-20, 0, 12) –tunnel with public space on top of it

7949: Z ARRAY(-20, 0, 12) –tunnel with public space on top of it

For parcel 7945 and parcel 7946 no 3D right-volumes are generated since NS Railinfratrust BV has a full ownership on these parcels.

The right of superficies established for the municipality to hold the public area at street level is in this case supposed to be bounded on a level of 12 meter above the surface level. This is not the real case.

In the deed, the space of the right of superficies is defined as ‘above the surface level’. How to visualise this? There are basically three solutions:

•make a 3D description of just the street level (figure 12.6 (a)); this representation could be confused with a 3D right-volume that is limited in height and is therefore not a good solution;

•make a very high (’unlimited’) 3D right-volume (figure 12.6 (b)); this also does not reflect the real situation correctly, since it looks as a very high building has been built;

•use an “open” polyhedron, without a top (and the side faces visualised until a reasonable height related to the height of the physical object).

261

Chapter 12. Prototypes applied to case studies

All these alternatives are vague indications that something is happening above the surface. The question is if these alternatives are correct and clear representations of the real situation.

(a)

(b)

Figure 12.6: The first two alternatives for unrestricted right of superficies (third option is not displayed). Note that the lowest 3D right-volumes (for the railway tunnel) are located below the surface (below the z=0 plane).

The 3D registration of this situation gives significantly more insight compared to the registration in the current cadastre. It is now possible to see not only which persons have a right on a parcel, but also where these rights are located in space. Although the gaps in the registration caused by the full ownership of NS Railinfratrust BV on some parcels as well as the undefined 3D right-volumes when 3D right-volumes are defined ‘above street level’ makes the situation unclear. The real situation might be better reflected when the tunnel itself is registered as 3D physical object.

262

12.1. Prototypes of the hybrid cadastre

3D physical objects

The registration of physical objects registers the tunnel as one whole object, together with the spatial extent of the tunnel and information on the tunnel. The station building could be registered as one physical object as well. The fragmented pattern of parcels could than be avoided. 3D information on the tunnel was not available for this research, but it would have been similar to the registration of the 3D physical object in the case of the railway tunnel in rural area as described in the next case. The 3D location of the tunnel helps to understand the real situation.

12.1.5Case study 5: Railway tunnel in rural area

3D right-volumes

Also in the case of the HSL, the 3D right-volumes start with the surface parcel boundaries. In order to avoid the situation where part of parcels that do not cross the tunnel are encumbered with a right for the tunnel (according to Dutch legislation), the intersecting parcels need to be subdivided. As was seen in section 3.2.2 most intersecting parcels were already subdivided but have not been surveyed yet. Therefore we created (fictive) new parcel boundaries using the new parcel boundaries as shown in figure 5.2. These new parcel boundaries were created by a spatial overlay in the database. First the tunnel axis, stored as a line, was bu ered with 15 meters, based on the diameter of the tunnel (15 meters) and a safety zone of 7.5 meters at each side (’shape’ in this query is the geometry column of the table in which the tunnel is represented with the centreline):

CREATE table hslbuffer AS

SELECT sdo_geom.sdo_buffer(shape,15000,1) shape

FROM hsltunnel;

Then a spatial overlay was carried out between the layer containing the tunnel bu er and the (realised geometry of) parcels:

CREATE TABLE hsl_parcel_new AS SELECT parcel, municip, osection,

sdo_geom.sdo_intersection(hb.shape,hp.return_polygon(object_id),10) shape FROM hsl_parcel hp,hslbuffer hb;

The newly created parcels (as well as the remainder parcels) got a unique parcel number. These new parcels were used to create the 3D right-volumes. The spatial extent of the 3D right-volumes is the spatial extent of the spaces where the rights established for the tunnel apply to: in this case the same as the 3D spatial extent of the tunnel under the specific parcels extended with a safety zone of 7.5 meters (in all directions). The upper and lower limits of a 3D right-volume for a specific parcel were derived from two sources: (1) the 3D centreline of the tunnel that intersects with the specific parcel and (2) information on the extent of rights established for the tunnel (diameter of 15 meter plus safety zone of 7.5 meter).

The obtained upper and lower limits of the right-space per parcel were inserted in the 3D right-volume table and used for the generation of 3D right-volumes for the tunnel (the z-values are in mm and in NAP):

263

Chapter 12. Prototypes applied to case studies

etc.......

From this 3D right-volume table the topology structure (and geometry) of 3D rightvolumes was obtained, representing the space to which the Ministry is entitled.

The 3D right-volumes give insight into the vertical dimension of the rights established (see figure 12.7 (a)). Now it is clear that the rights are established for an underground construction and not for a viaduct or a road. This solution also provides insight into the depth and height of the construction (if the height surfaces of parcels are also available), which is a considerable improvement of current registration.

The registration of a right for the tunnel will not take place, when the Ministry owns the intersecting parcel. This leads to ‘gaps’ in the 3D registration. This is clearly illustrated in figures 12.7 (b) and 12.7 (c). Figure 12.7 (b) shows the situation when new parcels are created and some of these parcels are in full ownership with the Ministry of Transport and Public Works. For those parcels a 3D right-volume will not be created (the Ministry owns the whole parcel column). The situation is even less clear in figure 12.7 (c). This will be the case when both new parcels and original parcels that are not divided are in full ownership of the Ministry.

Special cases are the parcels that are hold in bare ownership by the Ministry, while other persons are entitled to use space above and below the tunnel via limited real rights. In that case a 3D right-volume (multivolume object) would need to be maintained for the space above and below the tunnel. The representation of such ‘open’ 3D right-volumes would meet the same complications as the 3D right-volumes that refer to space ‘above street level’ in the Rijswijk case.

3D physical objects

Figure 12.8 shows the implementation of a physical object registration applied to the HSL tunnel. The spatial description of the whole tunnel is maintained as one 3D object in the database. Although the tunnel is a round shaped object which can easily be modelled in CAD software, implementing it in a DBMS reduces the precision of the data, since now the object needs to be approached by (many) flat polygons to be able to use the spatial primitives available in DBMSs.

The rights for the tunnel are still registered on the intersecting parcels. However, since the exact location of the tunnel is also maintained, it is not necessary to create new parcel boundaries. The holder of the tunnel is stored in the DBMS and is in this case the same as the subject who has a right of superficies or the right of ownership on the intersecting parcels. Note that in this case the safety zone is not included since

264