(وب سايت شرکت راه و ساختمانی مقياس زنجان)

   (وب سايت علوم مختلف نقشه برداری)

>> صفحه اصلی

تجربه من در اين چند سال نشان داد که در دنیای مجازی و اینترنت افراد و مجموعه ای که وب سایت به روز و فعال نداشته باشد عملاً وجود ندارد!    دکتر رامین کيامهر

وب سايت شخصی فريد اسماعيلی - تاريخ آخرين بروز رسانی - 18/10/85 - وضوح تصوير نرمال برای مشاهده صفحات اين وب سايت 800*600 - مطالب و مقالات اين وب سايت به طور ميانگين هر 2 ماه يک بار به روز رسانی می گردند

مقاله 344 صفحه ای در مورد کاداستر 3 بعدی - پايان نامه دکتری

3D Cadastre
September, 2004
Cover design: Axel Smits
This PhD thesis is published under the same title in the series:
Publications on Geodesy 57
ISBN 90 6132 286 3
NCG, Netherlands Geodetic Commission
P.O. Box 5058
Delft, the Netherlands
E-mail: ncg@lr.tudelft.nl
Website: www.ncg.knaw.nl
3D Cadastre
Proefschrift
ter verkrijging van de graad van doctor
aan de Technische Universiteit Delft,
op gezag van de Rector Magnificus prof.dr.ir. J.T. Fokkema,
voorzitter van het College voor Promoties,
in het openbaar te verdedigen
op maandag 13 september 2004 te 10:30 uur
door
Jantine Esther STOTER
doctorandus Fysische Geografie
geboren te Hoogeveen
Dit proefschrift is goedgekeurd door de promotoren:
Prof.dr.ir. P.J.M. van Oosterom
Prof.dr. J. de Jong
Samenstelling promotiecommissie:
Rector Magnificus, voorzitter
Prof.dr.ir. P.J.M. van Oosterom, Technische Universiteit Delft, promotor
Prof.dr. J. de Jong, Technische Universiteit Delft, promotor
Prof.dr. P.J. Boelhouwer, Technische Universiteit Delft
Prof.dr.tech. H.E. Mattsson, Royal Insitute of Technology, Sweden
Prof.dr.ir. M. Molenaar, ITC
Prof.dr. H.F.L. Ottens, Universiteit Utrecht
Dr.ir. M.A. Salzmann, Kadaster, Apeldoorn
Dr. H.D. Ploeger heeft als begeleider in belangrijke mate aan de totstandkoming van
het proefschrift bijgedragen.
Acknowledgements
I could never have finished this work without the support of a group of very pleasant
people and I feel privileged that I was able to work with them. I would like to thank
all the people who contributed either directly or indirectly to this work. However,
there are a few people who I would like to specifically mention here.
First of all I would like to thank Peter van Oosterom. His enthusiasm stimulated me
to do this research with great enjoyment and our discussions were very inspiring for
me. Hendrik Ploeger contributed largely to this thesis by discussing my findings using
his juridical expertise. I would like to thank Sisi Zlatanova because we collaborated
(from my side with great pleasure) on different topics of this thesis. Wilko Quak
and Theo Thijssen were indispensable during my research because they were always
available assisting me in all kinds of technical issues (they never said ‘no’, ‘maybe’
or ‘later’). Marian de Vries supported me in the Internet part of my research. I
cooperated with Ben Gorte on the terrain modelling issues. I am grateful to Jitkse
de Jong for giving me supervision on juridical matters. Axel Smits assisted me in
preparing the illustrations in this thesis, he also designed the cover.
I would like to thank all other members of the section GIS technology as well as the
members of the section Geo-information and Land Development because they contributed
to the motivating environment in which I was able to perform this research.
The Kadaster cooperated in this research by providing me with data and by discussions
on data models and on research developments. I am grateful to the following
persons of the Netherlands’ Kadaster: Auke Hoekstra, Zacharias Klaasse, Martin
Salzmann, and Berry van Osch. Piet Beekman from the cadastral office in Zuid-
Holland was very valuable because he provided me with all the cadastral information
needed for the Dutch case studies.
I worked with people from the Danish cadastre (KMS) in Copenhagen and the Centre
for 3D GeoInformation in Aalborg on the case study in Denmark.
The following persons provided me with useful comments about the contents of this
thesis: Elfriede Fendel, Hans-Gerd Maas and Jaap Zevenbergen.
Rod Thompson of the Department of Natural Resources, Mines and Energy (Queensland
Government) provided me with data sets needed for the Queensland case study.
Moreover, Rod did a great job because he gave me advice on the English text of this
thesis. Also George Sithole: thanks for your suggestions on the English text.
I thank the companies Laser-Scan, Oracle, ESRI and Bentley for their collaboration
in this research and because I was able to use their software. In addition they gave
me advice on technical issues.
I appreciate the contribution of the NAM (Nederlandse Aardolie Maatschappij), the
project-team of the HSL-Zuid and the Bouwdienst van Rijkswaterstaat because they
provided me with 3D data on physical constructions for the case studies. AGI (Adviesdienst
Geo-informatie en ICT) provided me with point heights of case study areas.
Calin Arens, Friso Penninga and Erik van Nieuwburg contributed to several issues in
this thesis (respectively the polyhedron implementation, the effective filtering of a TIN
and the Internet application to query a database) as part of their MSc programme,
Friso the last few months as a colleague.
Finally there are a number of people who supported me in finishing this thesis in a
more indirect way. To have these people around me give me the possibility to explore
and experience the things in life that are essential to me. First of all I would like to
thank Riet, Roel, Suzan and Marije (my family). They gave me the possibility in the
first place to start my education and study and they always support me in doing what
I find important to do. Secondly, I would like to thank all my inspiring friends who
I either meet frequently or rarely. These contacts were very important to me during
my research. There are two people who I like to mention specifically. Madeleine was
essential for me during this period because of our spiritual discussions, her stimulation,
and laughter. Finally, Gerbert, my soulmate, was of great importance to me because
of his practical and mental support, his encouragement and understanding.
Contents
1 Introduction 1
1.1 Need for a 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Research scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Topics within the scope of this thesis . . . . . . . . . . . . . . . 7
1.2.2 Topics outside the scope of this thesis . . . . . . . . . . . . . . 9
1.3 Research approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Research objectives . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Research methods . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Previous and related research . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Related research on 3D cadastres . . . . . . . . . . . . . . . . . 11
1.4.2 Related research on 3D tools and 3D modelling . . . . . . . . . 11
1.5 Contribution of the work . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 Organisation of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . 13
I Analysis of the background 17
2 Current cadastral registration of 3D situations in the Netherlands 19
2.1 Different types of cadastral registrations . . . . . . . . . . . . . . . . . 20
2.2 The Netherlands’ Kadaster . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Organisation of the Netherlands’ Kadaster . . . . . . . . . . . . 24
2.2.2 Public Registers and cadastral registration . . . . . . . . . . . 25
2.2.3 Cadastral model . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.4 Mapping real world objects . . . . . . . . . . . . . . . . . . . . 26
2.3 3D registration and Private Law . . . . . . . . . . . . . . . . . . . . . 27
i
CONTENTS
2.3.1 Right of ownership . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Right of superficies . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.3 Right of long lease . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.4 Right of easement . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.5 Apartment right . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.6 Joint ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 3D registration and Public Law . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Belemmeringenwet Privaatrecht . . . . . . . . . . . . . . . . . . 35
2.4.2 Law on Monuments . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.3 Law on Soil Protection . . . . . . . . . . . . . . . . . . . . . . . 38
2.5 Other relevant aspects of cadastral registration . . . . . . . . . . . . . 38
2.5.1 Underground objects in the cadastral registration . . . . . . . . 38
2.5.2 Parcels and part parcels . . . . . . . . . . . . . . . . . . . . . . 39
2.5.3 Frequency of types of cadastral recordings . . . . . . . . . . . . 40
2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Current practice of 3D registration: case studies 45
3.1 Building complexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.1 Case study 1: Building complex in The Hague . . . . . . . . . 46
3.1.2 Case study 2: The Hague Central Station . . . . . . . . . . . . 47
3.1.3 Case study 3: Apartment complex . . . . . . . . . . . . . . . . 49
3.2 Subsurface infrastructure objects . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Case study 4: Railway tunnel and station in urban area . . . . 52
3.2.2 Case study 5: Railway tunnel in rural area . . . . . . . . . . . 54
3.2.3 Case study 6: Utility pipelines . . . . . . . . . . . . . . . . . . 55
3.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 3D cadastre abroad 59
4.1 3D cadastral registrations abroad . . . . . . . . . . . . . . . . . . . . . 59
4.2 Evaluating 3D cadastral issues in the Netherlands . . . . . . . . . . . 62
4.3 Denmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.1 Evaluating 3D cadastral issues in Denmark . . . . . . . . . . . 64
4.4 Norway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
ii
CONTENTS
4.4.1 Evaluating 3D cadastral issues in Norway . . . . . . . . . . . . 67
4.5 Sweden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5.1 Evaluating 3D cadastral issues in Sweden . . . . . . . . . . . . 70
4.6 Queensland, Australia . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6.1 Restricted, building and volumetric parcels . . . . . . . . . . . 71
4.6.2 A case study in Queensland . . . . . . . . . . . . . . . . . . . . 73
4.6.3 Evaluating 3D cadastral issues in Queensland . . . . . . . . . . 74
4.7 British Columbia, Canada . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.7.1 Evaluating 3D cadastral issues in British Columbia . . . . . . . 77
4.8 Israel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.8.1 Evaluating 3D cadastral issues in Israel . . . . . . . . . . . . . 79
4.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5 Needs and opportunities for a 3D cadastre 83
5.1 Current cadastral registration of 3D situations in the Netherlands . . . 84
5.2 Complexities of current cadastral registration . . . . . . . . . . . . . . 85
5.2.1 Complexities of current Dutch cadastral registration . . . . . . 86
5.2.2 Locating infrastructure objects in the current cadastre . . . . . 88
5.3 Basic needs for a 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 Opportunities for a 3D cadastre . . . . . . . . . . . . . . . . . . . . . . 91
5.5 3D applications outside the cadastral domain . . . . . . . . . . . . . . 92
5.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
II Framework for modelling 2D and 3D situations 97
6 Theory of spatial data modelling 99
6.1 Data models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.1.1 Data models in GIS . . . . . . . . . . . . . . . . . . . . . . . . 101
6.1.2 Design phases in modelling . . . . . . . . . . . . . . . . . . . . 103
6.2 Conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3 Logical model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3.1 Relational model . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3.2 Object oriented model . . . . . . . . . . . . . . . . . . . . . . . 105
iii
CONTENTS
6.3.3 Object relational model . . . . . . . . . . . . . . . . . . . . . . 107
6.4 Physical model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.5 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.6 Spatial data modelling and DBMS . . . . . . . . . . . . . . . . . . . . 112
6.7 Standardisation initiatives . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.7.1 OpenGIS Consortium . . . . . . . . . . . . . . . . . . . . . . . 114
6.7.2 ISO TC/211 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.7.3 CEN/TC 287 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7 Geo-DBMSs 121
7.1 Geometrical primitives in DBMSs . . . . . . . . . . . . . . . . . . . . . 122
7.1.1 2D geometrical primitives in DBMSs . . . . . . . . . . . . . . . 122
7.1.2 3D geometrical primitives in DBMSs . . . . . . . . . . . . . . . 124
7.2 Topological structure in DBMSs . . . . . . . . . . . . . . . . . . . . . 127
7.2.1 OGC, ISO and planar partition topology . . . . . . . . . . . . 128
7.2.2 User-defined DBMS implementation of 2D topological structure 129
7.2.3 Commercial DBMS implementation of 2D topological structure 138
7.2.4 User-defined DBMS implementation of 3D topological structure 139
7.3 Spatial analyses in DBMSs . . . . . . . . . . . . . . . . . . . . . . . . 141
7.3.1 2D spatial analyses using geometrical primitives . . . . . . . . 142
7.3.2 3D spatial analyses using geometrical primitives . . . . . . . . 144
7.3.3 Spatial analyses using the topological structure . . . . . . . . . 145
7.3.4 Case study: topological structure or geometrical primitives? . . 146
7.4 Implementation of a 3D geometrical primitive in a DBMS . . . . . . . 148
7.4.1 Definition of 3D primitive . . . . . . . . . . . . . . . . . . . . . 149
7.4.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.4.3 Spatial indexing in 3D . . . . . . . . . . . . . . . . . . . . . . . 156
7.4.4 3D functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
8 3D GIS and accessing a 3D geo-DBMS with front-ends 163
8.1 3D GIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
iv
CONTENTS
8.1.1 Organisation of 3D data . . . . . . . . . . . . . . . . . . . . . . 164
8.1.2 3D data collection and object reconstruction . . . . . . . . . . 165
8.1.3 Visualisation and navigation in 3D environments . . . . . . . . 166
8.1.4 3D analyses and 3D editing . . . . . . . . . . . . . . . . . . . . 168
8.2 Accessing a geo-DBMS with a CAD front-end . . . . . . . . . . . . . . 168
8.3 Accessing a geo-DBMS with a GIS front-end . . . . . . . . . . . . . . 173
8.4 Accessing a geo-DBMS using Web technology . . . . . . . . . . . . . . 177
8.4.1 VRML and X3D . . . . . . . . . . . . . . . . . . . . . . . . . . 177
8.4.2 Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
8.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
9 Integrating 2D parcels and 3D objects in one environment 189
9.1 Absolute or relative coordinates . . . . . . . . . . . . . . . . . . . . . . 190
9.2 Introduction of a case study . . . . . . . . . . . . . . . . . . . . . . . . 191
9.2.1 Description of data sets . . . . . . . . . . . . . . . . . . . . . . 191
9.2.2 Combining point heights and 3D objects . . . . . . . . . . . . . 192
9.2.3 Assigning height to parcels . . . . . . . . . . . . . . . . . . . . 192
9.3 Integrated TINs of point heights and parcels . . . . . . . . . . . . . . . 195
9.3.1 Unconstrained TIN . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.3.2 Constrained TIN . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9.3.3 Conforming TIN . . . . . . . . . . . . . . . . . . . . . . . . . . 198
9.3.4 Refined constrained TIN . . . . . . . . . . . . . . . . . . . . . . 200
9.4 Analysing and querying parcel surfaces . . . . . . . . . . . . . . . . . . 202
9.5 Generalisation of the integrated TIN . . . . . . . . . . . . . . . . . . . 203
9.5.1 Detailed-to-coarse approach . . . . . . . . . . . . . . . . . . . . 204
9.5.2 Coarse-to-detailed approach . . . . . . . . . . . . . . . . . . . . 204
9.5.3 Integrated height and object generalisation . . . . . . . . . . . 204
9.6 Generalisation prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 206
9.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
III Models for a 3D cadastre 211
10 Conceptual model for a 3D cadastre 213
v
CONTENTS
10.1 Introduction of possible solutions . . . . . . . . . . . . . . . . . . . . . 213
10.2 A 2D cadastre with 3D tags . . . . . . . . . . . . . . . . . . . . . . . . 216
10.3 The hybrid approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
10.3.1 Registration of 3D right-volumes . . . . . . . . . . . . . . . . . 217
10.3.2 Registration of 3D physical objects . . . . . . . . . . . . . . . . 220
10.4 A full 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
10.4.1 Combined 2D/3D alternative . . . . . . . . . . . . . . . . . . . 222
10.4.2 Pure 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . . . . 224
10.5 Evaluating the conceptual models . . . . . . . . . . . . . . . . . . . . . 225
10.5.1 Solutions seen from a cadastral point of view . . . . . . . . . . 225
10.5.2 Solutions seen from a technical point of view . . . . . . . . . . 226
10.5.3 The optimal solution for a 3D cadastre . . . . . . . . . . . . . . 228
10.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
11 Logical model for a 3D cadastre 231
11.1 3D right-volumes in the DBMS . . . . . . . . . . . . . . . . . . . . . . 232
11.1.1 Spatial data model . . . . . . . . . . . . . . . . . . . . . . . . . 232
11.1.2 Administrative data model . . . . . . . . . . . . . . . . . . . . 234
11.1.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
11.1.4 Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
11.2 3D physical objects in the DBMS . . . . . . . . . . . . . . . . . . . . . 237
11.2.1 Spatial data model . . . . . . . . . . . . . . . . . . . . . . . . . 237
11.2.2 Administrative data model . . . . . . . . . . . . . . . . . . . . 238
11.2.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
11.2.4 Fundamental issues when linking GIS and CAD . . . . . . . . . 241
11.2.5 Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
11.3 Volume parcels in the DBMS . . . . . . . . . . . . . . . . . . . . . . . 242
11.3.1 Spatial data model . . . . . . . . . . . . . . . . . . . . . . . . . 243
11.3.2 Administrative data model . . . . . . . . . . . . . . . . . . . . 244
11.3.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
11.3.4 Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
11.4 Maintaining history in the 3D cadastre . . . . . . . . . . . . . . . . . . 245
vi
CONTENTS
11.4.1 History for 3D right-volumes . . . . . . . . . . . . . . . . . . . 246
11.4.2 History for 3D physical objects . . . . . . . . . . . . . . . . . . 246
11.4.3 History in a full 3D cadastre . . . . . . . . . . . . . . . . . . . 246
11.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
IV Realisation of a 3D cadastre 249
12 Prototypes applied to case studies 251
12.1 Prototypes of the hybrid cadastre . . . . . . . . . . . . . . . . . . . . . 252
12.1.1 Case study 1: Building complex in The Hague . . . . . . . . . 252
12.1.2 Case study 2: The Hague Central Station . . . . . . . . . . . . 254
12.1.3 Case study 3: Apartment complex . . . . . . . . . . . . . . . . 259
12.1.4 Case study 4: Railway tunnel in urban area . . . . . . . . . . . 261
12.1.5 Case study 5: Railway tunnel in rural area . . . . . . . . . . . 263
12.1.6 Evaluation of hybrid cadastre . . . . . . . . . . . . . . . . . . . 266
12.2 Prototype of the full 3D cadastre . . . . . . . . . . . . . . . . . . . . . 268
12.2.1 The Gabba Stadium in Queensland . . . . . . . . . . . . . . . . 268
12.2.2 Evaluation of full 3D cadastre . . . . . . . . . . . . . . . . . . . 271
12.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
13 Summary, conclusions and further research 277
13.1 Analysis of the background . . . . . . . . . . . . . . . . . . . . . . . . 277
13.1.1 Current registration practise of 3D property units . . . . . . . 278
13.1.2 Cadastral and juridical constraints for a 3D cadastre . . . . . . 280
13.1.3 Needs and requirements for a 3D cadastre . . . . . . . . . . . . 281
13.2 Framework for modelling 2D and 3D situations . . . . . . . . . . . . . 282
13.2.1 2D and 3D geo-objects in geo-DBMS . . . . . . . . . . . . . . . 282
13.2.2 3D GIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
13.2.3 Accessing spatial information organised in a DBMS . . . . . . 284
13.2.4 2D parcels and 3D geo-objects in one 3D environment . . . . . 285
13.3 Models for a 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . . . 286
13.3.1 Conceptual solutions for a 3D cadastre . . . . . . . . . . . . . . 286
13.3.2 The optimal solution for a 3D cadastre . . . . . . . . . . . . . . 287
vii
CONTENTS
13.4 Realisation of a 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . . 288
13.4.1 Full 3D cadastre . . . . . . . . . . . . . . . . . . . . . . . . . . 288
13.4.2 Hybrid cadastre . . . . . . . . . . . . . . . . . . . . . . . . . . 289
13.5 Future directions for a Dutch 3D cadastre . . . . . . . . . . . . . . . . 291
13.6 Further research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
13.6.1 Institutional aspects of 3D cadastral registration . . . . . . . . 293
13.6.2 Geo-Information Infrastructure . . . . . . . . . . . . . . . . . . 293
13.6.3 3D in the new generation GIS architecture . . . . . . . . . . . 293
13.7 Main results of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . 296
Bibliography 297
A Visualising attributes in VRML 315
B XSLT stylesheet to transform XML to X3D 317
Nederlandse samenvatting 321
Curriculum Vitae 327
viii


Chapter 1
Introduction
During the last two centuries population density has increased considerably making
land use more intense. This trend has caused a growing importance of ownership of
land, which has changed the way humans relate to land. This changing relationship
necessitated a system in which property to land is clearly and indisputably recorded.
In this thesis such a system is referred to as a ‘cadastre’ although many systems with
different names are instituted world-wide, which fulfil (more or less) similar tasks,
such as cadastral registration, cadastral system, land registry, land registration, land
administration, property register and land book.
No unique form of a cadastre exists. In [34] it was noted that:
“It is impossible to give a definition of a Cadastre which is both terse and
comprehensive, but its distinctive character is readily recognized and may
be expressed as the marriage of (a) technical record of the parcellation
of the land through any given territory, usually represented on plans of
suitable scale, with (b) authoritative documentary record, whether of a
fiscal or proprietary nature or of the two combined, usually embodied in
appropriate associated registers.”
In principle, this thesis follows the description of a Cadastre as it is given in the FIG
(International Federation of Surveyors) Statement on the Cadastre [53]:
“Cadastre is normally a parcel based, and up-to-date land information
system containing a record of interests in land (e.g. rights, restrictions
and responsibilities). It usually includes a geometric description of land
parcels linked to other records describing the nature of the interests, the
ownership or control of those interests, and often the value of the parcel
and its improvements. It may be established for fiscal purposes (e.g. valuation
and equitable taxation), legal purposes (conveyancing), to assist in
the management of land and land use (e.g. for planning and other administrative
purposes), and enables sustainable development and environmental
protection.”
1
Chapter 1. Introduction
Although the aim of this thesis is not to focus on one Cadastre in particular, the Dutch
Cadastre, which will be described extensively in chapter 2 and 3, will be used as the
basic starting point. In the Netherlands the Cadastre, which is the responsibility of
the Netherlands’ Cadastre and Land Registry Agency (Kadaster), comprises both the
cadastral registration and the land registration. The land registration (in the Netherlands)
is a Public Register in which documents describing interests in land are kept.
In some countries the land registration refers to the ordered and recorded legal documents
as in the Netherlands, also called a deed registration, while in other countries
the land registration refers to a property register, also called a title registration.
The cadastral registration in the Netherlands is a record of the rights that are registered
on land. In the cadastral registration essential information from documents
recorded in the land registration is linked to a location (parcel). Cadastral registration
(or cadastre) as used in this thesis refers to both the active process of registration
and the result of registration (also called register).
Basic entities of the cadastral registration are ‘real estate’, ‘real property’ or ‘property’
and ‘subject’. In general land and buildings on the land are referred to as real estate,
while various rights associated with land are called real property (or property) [53].
The subjects are persons or organisations that are entitled to real estate through
property rights.
Originally, cadastral registration was often introduced to assist in land taxation. Today
cadastral registration also provides relevant information for land transactions and
helps to improve the efficiency of those transactions and security of tenure in land in
general. It provides governments at all levels with relevant information for taxation
and regulation. Cadastral registration is increasingly used by both private and public
sectors in land development, urban and rural planning, land management and environmental
monitoring and is no longer related to cadastral surveying and mapping
alone [53, 212].
To be able to meet all these requirements, the main tasks of current cadastres can be
defined as:
• to register the legal status of and governmental restrictions on real estate: the
persons who have interests in land; what the interests are (nature and duration
of rights, restrictions and responsibilities); on what land the interests are
established (information on parcels such as location, size, value);
• to provide information on the legal status of and governmental restrictions on
real estate.
In order to perform these tasks adequately, cadastral registration needs to maintain
correct and consistent information, consisting of a complete set of cadastral parcels as
well as a record containing interests on the parcels. Moreover cadastral registration
has to be organised in such a way that the legal status of real estate becomes clear
when querying the cadastral registration.
Individualisation of property started originally with subdividing the surface into property
units using 2D boundaries. For this reason the basic entity of current cadastral
maps is the ‘parcel’, which makes the cadastral map a 2D map. To ensure completeness
and consistency, 2D parcels may not overlap and gaps may not occur (forming a
2
1.1. Need for a 3D cadastre
planar partition). Although parcels are represented in 2D, someone with a right to a
parcel always has been entitled to a space in 3D, i.e. a right of ownership on a parcel
relates to a space in 3D that can be used by the owner and is not limited to just the
flat parcel defined in 2D without any height or depth. If the right of ownership only
applied to the surface, the use of the property would be impossible. Consequently,
from a juridical point of view cadastral registration always has been 3D. The question
can be posed if traditional cadastral registration, which is based on the concept of a
2D parcel, is adequate for registering all kinds of situations that occur in the modern
world or does cadastral registration need to progress to a 3D approach.
The FIG Bathurst Declaration [55] concluded that “most land administration systems
today are not adequate to cope with the increasingly complex range of rights,
restrictions and responsibilities in relation to land”. Since many existing cadastres
are still based on a paradigm that has its origin centuries ago, this paradigm needs
to be reconsidered and adjusted to today’s world. This thesis reconsiders the central
paradigm of cadastral registration with respect to the issue of dimensions (2D and
3D).
This chapter presents the topic of this thesis and sets the outlines of the research
described in this thesis. The chapter starts with a description of the need for a 3D
cadastre (section 1.1). In section 1.2 the scope of this research is presented, while
in section 1.3 the research objectives and the research methods that were used to
reach the objectives of this research are described. Related research to this thesis is
presented in section 1.4. The contribution of this work is described in section 1.5.
This chapter ends with an overview of this thesis.
1.1 Need for a 3D cadastre
Pressure on land in urban areas and especially their business centres has led to overlapping
and interlocking constructions (see figure 1.1). Even when the creation of
property rights to match these developments is available within existing legislation,
describing and depicting them in the cadastral registration poses a challenge. This
is not surprising when looking at the FIG description of a Cadastre in which the
parcel is the basic entity. The challenge is how to register overlapping and interlocking
constructions when projected on the surface in a cadastral registration that
registers information on 2D parcels. Although property has been located on top of
each other for many years, it is only recently that the question has been raised as
to whether cadastral registration should be extended into the third dimension. The
growing interest for 3D cadastral registration is caused by a number of factors:
• a considerable increase in (private) property values;
• the number of tunnels, cables and pipelines (water, electricity, sewage, telephone,
TV cables), underground parking places, shopping malls, buildings above
roads/railways and other cases of multilevel buildings has grown considerably
in the last forty years;
• an upcoming 3D approach in other domains (3D GIS (Geographical Information
Systems), 3D planning) which makes a 3D approach of cadastral registration
technologically realisable.
3
Chapter 1. Introduction
(a) Underground metro,
Rotterdam, the Netherlands
(b) Subsurface shopping mall, Rotterdam, the
Netherlands
(c) Business district La Defense in Paris, a road and a metro in the subsurface
intersect buildings and plazas
Figure 1.1: Examples of complex property situations.
The core terms used in this thesis are 3D cadastre, 3D property unit, 3D (property)
situation and parcel. A 3D cadastre is a cadastre which registers and gives insight
into rights and restrictions not (only) on parcels but on 3D property units. A 3D
property unit, also abbreviated to ‘3D property’ in this thesis, is that (bounded)
amount of space to which a person is entitled by means of real rights. In fact the
traditional parcel, with only one person using the parcel, is also a 3D property unit
(often not explicitly bounded). However this has never caused any problems with
4
1.1. Need for a 3D cadastre
respect to the third dimension, since current cadastral registration is adequate to give
insight into these traditional property situations. The problems arise in 3D property
situations.
3D property situations (in this thesis also abbreviated to ‘3D situations’) refer to
situations in which different property units (with possibly different types of land use)
are located on top of each other or constructed in even more complex structures, i.e.
interlocking one another (see figure 1.2).
􀀀
􀀀
􀀀
􀀀
􀀀
􀀀
􀀀
Figure 1.2: Example of 3D property situation.
In this thesis 3D property situations are also referred to as stratified properties.
In 3D property situations several users are using an amount of space (volume), which
is bounded in three dimensions. These volumes are positioned on top of each other,
either all within one base parcel (the volumes are located in the same parcel column
defined by the boundaries on the surface) or crossing base parcel boundaries. Real
rights are established to entitle the different persons to the different volumes. A
parcel is a separated piece of land, to which a person (or persons) is (are) entitled
with a real right, such as right of ownership. Although, the ownership of land is not
explicitly bounded in the third dimension, in most countries the ownership reaches
as far as the owner has possible interest, while other persons are allowed to use space
above and below a parcel as long as the user cannot reasonably object to this use (see
figure 1.3).
Figure 1.3: An illustration of the spatial extent of the right of ownership to a parcel.
5
Chapter 1. Introduction
Consequently, the geological subsurface may be very important for the factual demarcation
of the third dimension of ownership. In areas with a solid geological subsurface,
e.g. in most Scandinavian countries, a tunnel twenty-five meters below the surface will
not cause any inconvenience to the owner of the surface parcel. Therefore such a construction
may be allowed according to the concept of the right of ownership, while in
countries with a ‘soft’ subsurface the space below the surface may be of much more
interest for the owner of the surface parcel since subsurface activity may damage
surface property.
To register 3D property situations in current cadastres, the legal status of 3D situations
has to be translated in such a way that it can be registered in the current
cadastral registration (see figure 1.4).
Figure 1.4: How to register 3D situations in a 2D cadastral registration?
FIG Commission 7 (Cadastre and Land Management) produced a vision of where
cadastral registrations might be in 2014 taking current trends into account, such as
the changing relationship of humankind to land, the changing role of governments in
society, the impact of technology on cadastral reform, the changing role of surveyors
in society and the growing role of the private sector in the operation of the cadastre
[54]. The study resulted in the following six statements on Cadastre 2014 based on a
four-year process involving input from many countries world-wide:
• Cadastre 2014 will show the complete legal situation of land, including public
rights and restrictions.
• The separation between ‘maps’ and ‘registers’ will be abolished.
• Cadastral modelling will take over cadastral mapping.
• Paper-and-pencil cadastre will disappear.
• Cadastre 2014 will be highly privatised and public and private sector will work
closely together.
• Cadastre 2014 will be cost recovering.
Although the statement on Cadastre 2014 does not mention 3D cadastre explicitly,
the report emphasises that cadastres in the future will no longer be based on or restricted
to (2D) cadastral maps. Future cadastres will show the complete (thus also in
6
1.2. Research scope
all dimensions) legal situation of land, including public rights and restrictions. Also
demands from practise will get growing influence on cadastral registration in the future.
These aspects motivate the study of the 3D issues of cadastral registration in
a broad, integrated view. The result of such a broad integrated approach is that all
rights, restrictions and responsibilities related to land, often overlapping, are considered.
This include many more aspects than would traditionally be of interest of and
be recorded in a cadastral registration [212].
The Netherlands’ Kadaster has the responsibility for cadastral registration in the
Netherlands. Until now the Netherlands’ Kadaster has been able to register 3D situations
within current registration possibilities. Are these registration-methods sufficient
to fulfil the main tasks of a cadastral registration, i.e. to register the legal status
of real estate and to provide insight into the legal status of real estate?
Since a few situations have occurred (and more are expected in the future) which
could not be registered unambiguously and clearly in the cadastral registration, the
discussion started on what to do with 3D situations. To support this discussion the
Netherlands’ Kadaster and the TU Delft took the initiative to start a research on
3D cadastral registration to study the needs, constraints and possibilities of a 3D
cadastre. This thesis is the result of this research which was carried out at TU Delft
in collaboration with the Netherlands’ Kadaster.
1.2 Research scope
The scope of research on 3D cadastre is demarcated by three frameworks which determine
the needs, constraints and possibilities for 3D cadastral registration. These
frameworks are linked to each other in a hierarchical order:
• Juridical framework: how can the legal status of stratified properties be established?
how to establish property boundaries other than traditional 2D parcel
boundaries? what rights can be used and how can these rights be used?
• Cadastral framework: once the legal status of property in 3D situations has been
established and described in deeds and in field works that are archived in the
land registration, the next issues are how to register the rights and restrictions
to property (bounded in three dimesnions) in the cadastral registration and how
to provide information on the legal status of 3D property situations?
• Technical framework: what system architecture (computer hardware, software,
data structures) is needed to support cadastral registration in 3D situations?
what architecture is technologically possible?
This thesis will focus mainly on the cadastral and technical framework.
1.2.1 Topics within the scope of this thesis
Several fundamental considerations outline the scope of this thesis as follows:
• Current cadastral registration (in combination with current land registration)
serves its purposes well in most (2D) situations and it has a good foundation
7
Chapter 1. Introduction
in today’s society based on long history. It is therefore not feasible to think
of a 3D cadastre totally outside the current juridical and cadastral framework.
This does not mean that (feasible) adjustments in the framework cannot lead
to improvements. Therefore the precondition of this thesis is to start with
the current cadastral registration and to see where this registration suffices
and where it needs improvements (extensions) in case of 3D situations. This
precondition imposes special demands on this research to 3D cadastre, since the
3D cadastre should fit to some extent within the current juridical, cadastral and
technical framework.
• Although generalities on 3D registration are addressed, this thesis focuses on
cadastral registration in particular.
• Disseminating information via the Internet is important in today’s society.
Therefore the cadastral registration that is considered should fit in a Geo-
Information Infrastructure (GII).
• This thesis focuses in the first place on cadastral registration in the Netherlands.
Since cadastral registration abroad has similar fundamental characteristics, the
main conclusions drawn in this thesis are extendible in (a limited way) to other
cadastral registrations. However, it should be noted that many minor differences
are present between cadastral registrations in different countries due to different
legislation and different implementation history.
• Cadastral registrations in other countries will be considered in order to examine
the need for 3D registration in other countries, to see if and how other countries
solve the problem of 3D cadastral registration and to come to more general (not
only valid for the Dutch situation) conclusions.
• Both cadastral and technical issues will be addressed. Cadastral issues deal with
the main tasks of the cadastre in 3D situations and technical issues determine
how these cadastral issues can be implemented.
• Since a DBMS (DataBase Management System) is an essential part of the architecture
that is capable of maintaining large amounts of (spatial) data such as in
cadastral registration, a main issue of this thesis is how to model 3D geo-objects
(topologically and geometrically) in a DBMS.
• The cadastral registration must provide access to a wide spectrum of users
(citizens, real estate agents, notaries, GIS/CAD specialists). Therefore another
major issue is how the cadastral DBMS can be made accessible for users.
• With respect to 3D GIS, efficient methods for geometric construction, data
structuring, organisation of 2D and 3D data in one environment, database creation
and updating have yet to be developed. This thesis will give considerations
and preliminary solutions for these issues.
• The main focus of this thesis is to give technical solutions and technical recommendations
to implement a 3D cadastre. For this purpose the needs for a
3D cadastre in general are studied and translated into technical needs. Current
(commercially available) techniques are tested to evaluate if they are able to
meet these needs. If fundamental solutions are not provided by commercially
available techniques, concepts are designed which are tested by translating the
concepts into prototypes.
8
1.3. Research approach
1.2.2 Topics outside the scope of this thesis
Topics that are not within the scope of this thesis can be described as:
• It is not the aim of this thesis to provide solutions for 3D registration for any
cadastre outside the Netherlands, although cadastres in other countries can use
the findings of this thesis that address general issues of cadastral registration in
3D situations.
• Juridical issues will be addressed in this thesis, but will be merely used as
preconditions. It is not the aim of this thesis to give recommendations on
(major) changes of the legal system in the Netherlands. However the experiences
and findings in this thesis may lead to recommendations for developments and
further research on juridical issues.
• This thesis does not intend to develop an operational 3D cadastral registration,
since this is not considered feasible at this stage, in which many issues still need
to be resolved and in which choices need to be made on where to go to. This
thesis firstly aims at a clear definition of the problem, a development of concepts
and validation and evaluation of the concepts by prototyping key aspects.
• Functionality of 3D cadastral registration is the main topic of this research.
Performance testing and benchmarking with respect to 3D cadastral registration
or other information systems are therefore not part of this research.
• This thesis addresses cadastral registration in particular and will therefore not
address topographical or other registrations.
1.3 Research approach
In this section the research objectives and the research methods that were used to
achieve these objectives are explained.
1.3.1 Research objectives
The main objective of this thesis is to answer the question how to record 3D situations
in cadastral registration in order to improve insight into 3D situations. The emphasis
of this thesis is on the technical aspects of cadastral registration. To realise this
objective, this thesis concentrates on four different topics:
• Analysis of the background. This part focuses on identifying problems of
current cadastral registration concerning 3D situations, both in the Netherlands
and abroad, in order to get insight into the needs and requirements for 3D
cadastral registration and in order to structure the national and international
discussion on 3D cadastre.
• Framework for modelling 2D and 3D situations. In this part techniques
are explored that are needed for a 3D cadastre:
– How to model 2D and 3D geo-objects in a DBMS which is the core of the
new generation GIS architecture?
– What is the state-of-the-art of 3D GIS?
9
Chapter 1. Introduction
– How to access and analyse 3D geo-objects organised in a geo-DBMS?
– How to combine 2D parcels and 3D geo-objects in one environment?
• Models for a 3D cadastre. In this part conceptual models are designed
based on current registration and based on available techniques in order to
improve 3D cadastral registration. Also considerations are given for translating
the conceptual models of a 3D cadastre into logical models.
• Realisation of a 3D cadastre. The proposed conceptual models are evaluated
by translating conceptual alternatives into prototype implementations
using techniques explored and developed as part of this thesis and by performing
functional tests. Performance tests are not part of this thesis.
1.3.2 Research methods
To answer the research questions, the following research methods are used.
Analysis of the background
“What are the actual needs for 3D registration?” is the first important topic of this
research. To answer this question a literature study will be carried out to come to a
list of types of cadastral recordings with a possible 3D component. To conclude on
the actual complications of current registration of 3D situations in the Netherlands,
six (national) case-studies will be carried out. To get insight also into the needs for
cadastral registration abroad, the question will be addressed “how are 3D situations
internationally registered and do other countries meet the same problems?” To answer
these questions an international workshop on 3D cadastres was organised. Knowledge
obtained during this workshop supplemented with literature study will be presented.
During a working visit to Aalborg, Denmark, the Danish cadastral registration in case
of 3D situations has been examined. In collaboration with Queensland Government,
Australia, also a case study in Brisbane, Queensland has been carried out. The results
of both case studies will be described.
Framework for modelling 2D and 3D situations
How geometrical primitives and topology structure can be modelled both in 2D and 3D
in a DBMS and what is the current state-of-the-art of 3D GIS are the next topics. The
description of the state-of-the-art of 3D GIS is a result of literature study. Answer to
the first question is basically a result of carrying out experiments with current DBMSs
and with new developments designed and implemented as part of this research. The
same approach will be followed to find out how 3D geo-information stored in a geo-
DBMS can be accessed by front-ends. Experiments will also be carried out to explore
fundamental issues of combining 2D parcels and 3D geo-objects in one environment.
Models for a 3D cadastre.
The main question in this research is how can current cadastral registration be improved
in case of 3D situations? To answer this question conceptual modelling for 3D
cadastre will be carried out based on the findings of the analysis of the background
and of the analysis of the technological possibilities of modelling 2D and 3D situations.
Realisation of a 3D cadastre.
The conceptual models will be translated into prototype implementations. In experiments
in which the prototype implementations will be applied to the case studies,
10
1.4. Previous and related research
the conceptual models for a 3D cadastre will be evaluated. The experiments with the
prototypes will also lead to conclusions on how to realise an effective 3D cadastre.
1.4 Previous and related research
Related research to this thesis, which focuses on cadastral and technical aspects of a
3D cadastre, can be divided into research on 3D cadastral registration and research
on 3D tools and 3D modelling.
1.4.1 Related research on 3D cadastres
Israel is one of the countries which faces high pressure on the use of land. This has
promoted developments for a 3D cadastre. Therefore in Israel for the past five years
several studies have started on 3D cadastres [9, 57, 58, 63, 64] (see also section 4.8).
Mid European countries such as Ukraine [116], Hungary [161], Czech Republic [81]
and Slovenia [170] are in the phase of examining the current cadastre for potential
registration of 3D property units, including apartments.
International marine cadastres traditionally have a 3D approach, as the use of the
marine environment is volumetric by nature and involves rights to the surface, water
column, seabed and subsoil. The University of New Brunswick (Canada), Department
of Geodesy and Geomatics Engineering is developing a 3D marine cadastre to support
effective and efficient decision making associated with marine governance [126, 232].
In [60] the framework issues are discussed that must be considered in the development
of marine cadastral data and the use of these data in a marine information system
for the United States. In this discussion 3D aspects are also addressed.
Some other countries and states have already solved part of 3D cadastral registration
(Norway, Sweden, Queensland and British Columbia), as will be seen from the study
on 3D cadastral registration abroad (chapter 4).
1.4.2 Related research on 3D tools and 3D modelling
3D registration deals with maintaining spatial and non-spatial information on 3D
objects, which are core topics of 3D GIS. Therefore developments in 3D GIS are
important when examining a 3D registration.
The main characteristic of researches on 3D models intended for 3D GIS and 3D
geo-DBMSs, is that they are extensive and that the results of these researches are
fragmented. Examples of 3D models intended for 3D GIS and 3D geo-DBMSs are
[56, 94, 119, 168, 169, 184]. Implementations of 3D models in user-developed systems
can be found in [19, 147, 181, 227].
Research on spatial querying and 3D visualisation of geo-objects using Web technologies
has resulted in several prototype systems [13, 31, 35, 96, 104, 240]. Research on
spatial querying and 3D visualisation of geo-objects organised in a DBMS has not yet
11
Chapter 1. Introduction
resulted in any publications, apart from publications that were written as part of this
research.
Since developments in 3D GIS are important when studying the possibilities for a 3D
cadastre, a section is included in this thesis which describes the current state-of-theart
of 3D GIS (section 8.1).
1.5 Contribution of the work
The main contributions of this work can be summarised as follows:
• Enabling a complex registration addresses many issues in a variety of disciplines
(technical, cadastral, juridical, organisational). This thesis is the first extensive
research on 3D cadastres in which the problem of registration in complex situations
has been studied using an integrated approach. Therefore this thesis has
strong explorative characteristics resulting in a clear analysis as well as a distinct
definition of the essential problems of registering 3D situations in current
cadastres taking all involved disciplines into account.
• This thesis structures the national and international discussion on the need for
3D cadastre by providing a universal overview of the basic and fundamental
needs for a 3D cadastre, considered from different points of view (juridical,
cadastral, technical) and by providing insight into country-specific aspects which
influence the need for and possibilities of 3D cadastral registration.
• This thesis gives solution-directions for a 3D cadastre. Several models for a
3D cadastre will be introduced and translated into prototype implementations.
Experience with the prototypes will result in concrete recommendations. Based
on these recommendations, decision-makers will be able to base choices on if
and how to implement a 3D registration on fundamental considerations.
• In technical respect, the outcomes of this research contribute to 3D GIS in
general, i.e. how to model and maintain 3D geo-objects in a DBMS, how to
access and query these objects by front-ends and how to combine 3D geo-objects
and 2D geo-objects in one 3D environment. With respect to improving 3D
GIS functionalities, an extension of a geo-DBMS has been built to support 3D
primitives. Also a study was carried out to generate an appropriate integrated
height model in a TIN (Triangular Irregular Network) structure based on both
the 2D planar partition of parcels and point heights.
• This work contributes to supporting the demand for 3D geo-information in
today’s society in general. Other organisations responsible for (spatial) registrations
and for spatial data sets can use the outcomes of this work to see
the possibilities and constraints to extend their systems into the third dimension
(e.g. registrations for cultural heritage, for buildings, for zoning plans, for
cables and pipelines, and databases of topographical mapping agencies).
12
1.6. Organisation of the thesis
1.6 Organisation of the thesis
Chapter 1 (this chapter) presents the need for a 3D cadastre, specifies the objectives,
the scope and the contributions of this research and describes related research.
The main body of this thesis, apart from the introduction (chapter 1) and conclusions
(chapter 13), is divided into four major parts corresponding with the four main
research topics of this thesis as described in section 1.3.1.
1. Part I: Analysis of the background (chapters 2, 3, 4, 5)
2. Part II: Framework for modelling 2D and 3D situations (chapters 6, 7, 8 and 9)
3. Part III: Models for a 3D cadastre (chapters 10 and 11)
4. Part IV: Realisation of a 3D cadastre (chapter 12)
Readers who are familiar with cadastral registration with respect to the 3D component
and are less interested in a detailed study on needs for 3D cadastral registration may
skip part I. Readers who are familiar with spatial modelling in DBMSs both in
2D and 3D and with accessing this information with front-ends or the reader who
is not interested in technical issues of 3D cadastral registration may skip part II.
The introduction and evaluation of new conceptual data models for 3D cadastral
registration is described in part III and part IV.
Chapter 2 gives an overview of the types of cadastral recordings in the Netherlands
with a potential 3D component. The aim of this chapter is to get a clear view on the
cadastral domain on which the 3D cadastral research should focus. For what types
of cadastral recordings should a 3D approach of registration be considered? Cadastral
registration is in this chapter subdivided into cadastral registration according to
Private Law and cadastral registration according to Public Law. The chapter starts
with a description of common alternatives of cadastral registrations, followed with an
introduction into the cadastral registration of the Netherlands’ Kadaster.
Chapter 3 describes the results of six case studies which were carried out to indicate
the complexities of registering 3D situations within the current Dutch cadastral registration.
Three case studies were selected based on multilevel building complexes
in urban areas that interact with other land use, such as roads and railways. The
other three case studies were selected based on subsurface infrastructure objects.
The basic purpose of cadastral registration of building complexes is to provide insight
into the property units within the building complex. The basic purpose of cadastral
registration of infrastructure objects is to register the person who is responsible for
the infrastructure object. The case studies resulted in findings which describe the
limitations of current cadastral registration and the actual needs for a 3D cadastre.
Chapter 4 presents the results of a study abroad. To see if this thesis can learn from
international developments and to place this research in an international context,
countries abroad were examined. Six countries and states in which the discussion
on 3D cadastre has already started or that have solved (part) of the problem of
3D cadastral registration were examined: Denmark, Norway, Sweden, Queensland
(Australia), British Colombia (Canada), and Israel. The results of the study abroad
are reported in chapter 4.
13
Chapter 1. Introduction
Chapter 5 elaborates on the needs and opportunities for a 3D cadastre based on the
findings described in chapters 2, 3 and 4.
Chapter 6 aims at clarifying some basic terms and concepts concerning spatial data
modelling that are used and applied in this thesis. Data models and in specific
characteristics of spatial models are described, followed by a description of the basic
phases of data modelling. UML (Unified Modelling Language) is used in this thesis to
describe the data models. The basic characteristics of UML are explained. How the
relationship between spatial data modelling and DBMSs has evolved is also discussed.
The chapter ends with a description of standardisation initiatives.
Chapter 7 discusses the state-of-the-art of DBMSs in the new generation GIS architecture:
how spatial objects can be maintained in a geo-DBMS using both a structure
of geometrical primitives and a topological structure. Spatial analyses on both
structures are considered as well. The chapter also contains a section describing the
implementation of a 3D primitive in a DBMS, a study which was carried out as part
of this thesis.
As described in chapter 7, geo-DBMSs are the core of the new generation GIS architecture.
3D GIS is a basic instrument to deal with 3D geo-information in general.
Therefore the state-of-the-art of 3D GIS aspects other than geo-DBMSs is discussed
in chapter 8. Chapter 8 reports also the results of a research that was carried out to
access (query and visualise) 3D objects that are organised in a geo-DBMS. For this
research three front-ends were studied: a CAD oriented system, a GIS system and a
self-implemented system using Web based techniques.
Chapter 9 deals with the fundamental issue of combining 3D geo-objects (3D cadastral
objects) and 2D geo-data (parcels) into one system: how to relate the two data sets in
space. A case study was carried out to show possibilities and problems of integrating
a 3D geo-object (pipeline) and surface parcels in one environment. TINs, representing
integrated height models of point heights and parcels, that were created during this
case study, are described together with their data structure and their results. The
TINs are inserted in the DBMS which makes it possible to perform spatial analyses
on height surfaces of (individual) parcels. In order to obtain a more effective height
model, a generalisation method was developed and is described in this chapter. This
method has partly been implemented in a prototype. The prototype selects only the
significant TIN-nodes while removing the non-significant TIN-nodes. Results of the
prototype are also reported.
Chapter 10 introduces three concepts for a 3D cadastre, each with different alternatives,
which were designed as part of this research. Based on both cadastral and
technical considerations two of these three concepts were selected as most optimal
solution for a 3D cadastre: a hybrid 3D cadastre (with two alternatives) and a full
3D cadastre (only one alternative).
Chapter 11 considers issues that come with translating the conceptual models that
were introduced in chapter 10 into logical models: issues concerning the spatial data
model, the administrative data model, as well as the process of data collection to
obtain data that can be inserted into the spatial data models. Also 4D requirements
of a 3D cadastre that need to be taken into account in the phase of logical modelling
are considered.
14
1.6. Organisation of the thesis
Chapter 12 evaluates the proposed conceptual models from chapter 10 by applying
prototypes, which contain the key aspects of the conceptual and logical models, to
the case studies introduced in chapter 3 and 4.
Chapter 13 summarises this thesis and concludes the major findings of this research.
In this chapter it is concluded that a full 3D cadastre is a feasible solution to solve 3D
cadastral issues at a fundamental level, taking juridical, cadastral as well as technical
aspects into account and that such a cadastre is realisable. The chapter also contains
recommendations for future research.
15

Part I
Analysis of the background
17

Chapter 2
Current cadastral registration
of 3D situations in the
Netherlands
Multilevel use of land is not new. In the Middle Ages cellars below roads along
wharfs (werfkelders) already existed in Dutch cities (see figure 2.1), and for more
than a century stores, workplaces, pubs and even houses, have been situated under
railway viaducts. How are 3D situations like this recorded in the current cadastral
registration; what are the complications of these recordings, and why has the question
for a 3D cadastre only been raised recently? To answer these questions, first an
inventory has been made of current cadastral recordings of the Netherlands’ Kadaster
in which the 3D aspects of registration are considered. Results of this inventory will
be described in this chapter. The aim of the inventory is to get a clear view on the
cadastral domain on which the 3D cadastral research should focus.
Many types of cadastres exist based on country specific characteristics such as local
cultural heritage, physical geography, land use, technology etc. The type of a cadastre
(organisation, technical implementation etc.) influences needs as well as possibilities
for 3D registration. Therefore this chapter starts with a short introduction of different
classifications of cadastral registrations (section 2.1).
After an introduction into the registration of the Netherlands’ Kadaster (2.2), the
types of cadastral recordings according to Dutch Private Law for which 3D aspects
might be relevant are described (2.3), followed by a description of types of 3D cadastral
recordings according to Dutch Public Law (2.4). Section 2.5 describes other aspects
of cadastral registration in the Netherlands which are relevant for this thesis. The
chapter ends with conclusions.
19
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
Figure 2.1: Cellars below roads in Utrecht.
2.1 Different types of cadastral registrations
Traditionally, cadastral registrations consisted of a set of cadastral maps containing
cadastral parcels with (mostly) unique parcel numbers and a paper archive in
which property information on parcels was maintained. Since the end of the last
century cadastral registrations in developed countries have been converted from analogue
cadastral registrations into digital registrations. Spatial information on parcels
is no longer maintained on paper maps but in GIS and CAD or even more sophisticatedly
in spatial DBMSs. Information on property and other information that is
nowadays registered in cadastral registrations (mortgage, soil pollutions, monuments)
is no longer (only) maintained in paper archives but in cadastral databases. A link
is maintained between the digital cadastral map and the cadastral administrative
database. The link provides the possibility to query the spatial part and administrative
part of cadastral registration and combine the results. In more advanced systems
it is possible to query the spatial and administrative part of cadastral registration in
one integrated environment.
Cadastres can be classified in many ways, based on different criteria e.g. as proposed
in [53]:
• primary function (e.g. supporting taxation, conveyancing, land distribution, or
multipurpose land management activities);
• the types of rights recorded (e.g. private ownership, use rights, mineral leases,
public law restrictions);
• the degree of responsibility in ensuring the accuracy and reliability of the data
(e.g. complete state mandate, shared public and private responsibility);
• location and jurisdiction (e.g. urban and rural cadastres; centralised and decentralised
cadastres);
20
2.1. Different types of cadastral registrations
• the many ways in which information about the parcels is collected (e.g. ground
surveys tied to geodetic control, uncoordinated ground surveys and measurements,
aerial photography, digitising existing historical records, etc).
All these factors determine the required resolution and scale of spatial data, the type
and characteristics of data recorded in both thematic and geometrical attributes,
and the organisational and professional responsibility for managing the data. Consequently,
these factors also influence the need for 3D cadastral registration in a specific
country and how the 3D issue is or will be approached.
In [236] and [237] different classifications are proposed to describe most common
alternatives for cadastral (and land) registration. These classifications are based on
the most essential criteria. Since these classifications form a good overview of the
differences that may exists between different cadastral registrations, the classifications
are described below.
Deed versus title registration
The classification of deed registration versus title registration, is the most often used
classification. The most basic difference is that “deed registration is concerned with
the registration of the legal fact itself and title registration with the legal consequence
of the fact” [73]. However, mostly also other factors are taken into account when
distinguishing between titles and deeds. The complete definition given in [73] is:
Deed registration A deed registration means that the deed itself, being a document,
which describes an isolated transaction, is registered. This deed is evidence
that a particular transaction took place, but is in principle not itself proof
of the legal rights of the involved parties and, consequently, it is not evidence of
its quality. Thus before any dealing can be safely effected, the ostensible owner
must trace his ownership back to a good root of title.
Title registration A title registration means that it is not the deed describing the
transfer of rights that is registered but the legal consequence of that transaction,
i.e. the right itself (title). So the right itself together with the name of the
rightful claimant and the object of that right with its restrictions and charges
are registered. With this registration the title or right is created.
In the deed registrations, (which is common in most of the countries in Western Europe
and many of their former colonies, the Unites States and countries in Latin
America falling under Spanish/Portuguese law) the documents filed in the land registration
are the evidence of title. The registration itself does not prove title: it
only records a transaction between parties. In the title registrations (common in the
United Kingdom, most of the countries of the Commonwealth and many countries
in Central Europe), the register itself serves as the primary evidence. The title is
constituted by registration. The registration of title enables a title to be ascertained
as a fact. A title registration is an authoritative record kept in a public office. The
register is maintained and warranted by the state.
As concluded in [237] the debate on ‘title versus deeds’ is complicated, since no
distinct definition can be given. Also technological developments have provided the
21
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
instruments to decrease the former differences. Generally speaking, there are examples
of good and bad title registrations and good and bad deed registrations. The real
protection of land ownership is more dependent on the quality of information in the
land and cadastral registration and not on the type of land and cadastral registration.
In order to avoid making the 3D cadastral issue more complicated than necessary, this
debate will be left out of this thesis. The classification based on titles versus deeds
was mentioned here for completeness.
A centralised or decentralised cadastral registration
In every country the protection of rights to land is considered a governmental task.
However, not every country has a strong national authority. In some cases financial
and technical responsibility lies at regional or even local level. Therefore cadastral
registration may be the responsibility of local governments while in others it is a
state or national responsibility. Apart from the question of whether local or national
government is responsible for cadastral registration, cadastral registration can be
carried out at different levels (in a central database, in regional or local databases or
at regional and local level while a centralised database is maintained). The question of
the existence of a centralised cadastral database is dependent on three main aspects:
• State of the art of database technology. A cadastral registration consists of an
administrative and a spatial part mostly maintained in databases. For decentralised
systems many databases have to be maintained, which should be avoided
since databases (especially the spatial part) requires expensive equipment and
expertise. Technical development on the area of databases also motivates concentration
at national level, since DBMS technology favours an approach of one
centralised DBMS in which all objects of interest for a specific application are
maintained. A centralised DBMS is easier and cheaper to manage.
• State of the art of telecommunication by mobile telephones and Internet facilities.
Decentralised systems were set up to bring cadastral information closer to
end-users. With modern technologies of telecommunication and Internet it is
no longer as relevant where cadastral information is maintained.
• The question whether to have a centralised or a decentralised cadastral system
is dependent on the way a specific country organises its whole administration,
since a cadastral system is part of the administration of a country.
The Ministry responsible for the cadastral registration also differs per country:
• Ministry of Finance. This is mostly the case when a cadastral registration was
originally started as a fiscal cadastre.
• Ministry of Agriculture. In some countries this Ministry only has the responsibility
for rural activities (land consolidation), while in other countries this
Ministry has the responsibility for the whole national cadastre (e.g. Hungary).
• Ministry of Housing or the Ministry of Public Works. This Ministry has the
responsibility for the urban cadastre.
• Ministry of Justice. The Ministry of Justice has the responsibility for cadastral
registration since land registration originally has a legal nature. Registration
takes place in local courts (Austria and Romania).
• Ministry of Interior (Poland).
• A separate authority is responsible to prevent the discussion of the ministerial
responsibility.
22
2.1. Different types of cadastral registrations
At what authority level and by which Ministry the 3D issue of cadastral registration
is approached depends on the organisation of cadastral registration.
Land registration with separate or integrated cadastre
In several countries land registration and cadastral registration are handled by one
organisation. This makes it easier to make the contents of both registrations identical.
In other countries the separation of land registration and cadastral registration
has a historical background (e.g. Denmark, Austria, Bulgaria and Poland). In these
countries the land registration and cadastral registration are also mostly the responsibility
of different Ministries. Land registration has generally been the mandate of the
courts and the legal profession. Mapping, parcel boundary delimitation and maintenance
of parcel data for fiscal, land use control, and land redistribution purposes is
traditionally the responsibility of the surveying profession [53]. In case of manual registrations,
it is hard to keep two separated registrations up-to-date and identical. In
an integrated cadastre, land registration and cadastral registration are better geared
to one other. Therefore, improvement of information supply in case of 3D situations
can be achieved by the combined efforts of both land registration and cadastral registration.
In a separated system it will be harder to join the two registrations in
order to achieve one common goal (i.e. improve insight in case of 3D situations). This
goal cannot be achieved without a tight collaboration between land registration and
cadastral registration.
Fiscal or legal cadastre
Very often cadastral registrations started as a fiscal cadastre for taxation, e.g. the
‘Napoleontic Cadastre’. Such cadastres were based on a full survey of the ownership
parcels. After a few decades such fiscal cadastres were changed into legal cadastres.
In some countries there are still problems with the old cadastral maps. For example
in the Ardennes, in Belgium, the cadastral maps give the real area of the surface of
land parcels that are located on the slope of hills. The transfer of this information
to a cadastral map, which is a projection of the terrain onto a horizontal plane, is
so expensive that a digital map in this country was never produced (note that this
is a nice example of a 3D cadastral aspect). A fiscal cadastre is less complex than
a legal cadastre. In the case of a fiscal cadastre a cadastre can be less accurate in
maintaining geometry and other attributes if the property tax is based on valuation.
In addition a fiscal cadastre needs an up-date every year (when following a yearly
tax cycle), whereas a legal cadastre needs an up-date every day. A legal cadastre
will therefore impose more conditions on the availability of information in case of 3D
situations.
General or fixed boundaries
A parcel is defined by indicating its boundaries. General boundaries are boundaries
which have to be visible features on the landscape. These features are supposed to
coincide with the position of boundaries and can be mapped relatively easily because
the features are easy to measure with surveying, with aerial photogrammetry or from
topographic maps. Although these boundaries do not indicate the exact location
of parcel boundaries, the parcel is reasonably defined and can be identified beyond
doubt. In case of fixed boundaries all parties involved have to fully agree on the
exact position of each boundary point (after which the position of parcel boundaries
can be marked on the terrain). The demarcation, measuring and registration of fixed
23
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
boundaries requires more time. Once 3D property units are defined within cadastral
registration, the type of boundaries within the specific cadastral registration (general
or fixed) will impose requirements for the boundaries demarcating 3D property units.
Financed by government or cost-recovering
In general the maintenance of the cadastral registration is a regular task of the government
which means that normal cadastral activities are generally financed by the
government. Cadastral registrations generate income from fees for registration of
transactions, mortgages etc. and supply of information. The income generated by
the cadastre goes straight to the State Treasury when the cadastre is a regular task of
the national government. Consequently there is no link between the income and the
expenses of the cadastral registration. The motivation to take care of user requirements,
e.g. to establish a 3D cadastre, is therefore limited [236] unless it is imposed
by the government. The alternative is that a cadastre is an independent organisation
which is responsible for its own income and expenses forcing them to listen to
changing user requirements.
2.2 The Netherlands’ Kadaster
In this section the Netherlands’ Kadaster and the basic principles of Dutch cadastral
registration are described.
2.2.1 Organisation of the Netherlands’ Kadaster
The Netherlands has a deed registration, which is maintained together with the cadastral
registration by one organisation: the Netherlands’ Kadaster. The national government
(Ministry of Spatial planning, Housing and the Environment) is responsible for
the Cadastre, although the Kadaster is an independent organisation since 1994. The
organisation is financially fully self-supporting. Till recently the cadastral registration
was maintained at regional level, but is now organised at one location, although
the actual registration is still performed at fifteen regional offices. The Netherlands’
Kadaster serves both fiscal and legal purposes. The Kadaster also supports land management
by registering legal restrictions dictated by Public Law such as soil pollution
and monuments apart from real rights. Fixed boundaries are used in the Netherlands,
which means that all persons involved have to fully agree on the location of parcel
boundaries. Apart from the main cadastral tasks the Netherlands’ Kadaster has the
following responsibilities:
• consolidation of land;
• maintaining the Large Scale Map of the Netherlands (GBKN) together with
other parties;
• maintaining the Dutch Geometric Infrastructure together with the Survey Department
(NAP) from the Dutch Ministry of Transport, Public Works and Watermanagement;
• since January 2004 the Kadaster is responsible for the traditional tasks of the
Dutch Topographic Service, since they merged with the Topographic Service.
24
2.2. The Netherlands’ Kadaster
2.2.2 Public Registers and cadastral registration
The Netherlands’ Kadaster maintains the land registration, i.e. the Public Registers
(Openbare Registers) [115]: a collection of notarial deeds creating or transferring real
rights to land. These deeds have been (analogously) archived in chronological order.
Since 1999 the deeds in the Public Registers are available in scanned format and will
soon be available through the cadastral database.
The Netherlands’ Kadaster also has the responsibility for the cadastral registration in
the Netherlands comprising registration of parcel boundaries and registration of the
legal status of parcels, which is a summary of the information described in deeds. The
cadastral registration makes information in deeds (rights and restrictions) referring to
individual parcels accessible. The Dutch cadastral registration consists of two parts
[102]:
• a 2D geo-DBMS for maintaining the geometry and topology of parcels as well
as streetnames, house numbers, parcel numbers and buildings for reference purposes
called LKI (Landmeetkundig Kartografisch Informatiesysteem, ‘Information
system for Surveying and Mapping’). LKI also contains the Large Scale
Map of the Netherlands. Both the cadastral map and the Large Scale Map can
be generated out of the LKI database since the objects in the database contain
a code specifying if the object is part of the specific map;
• an administrative DBMS for maintaining legal and other administrative data
related to parcels as well as a registration of mortgages called AKR (Automatisering
Kadastrale Registratie, ‘Automated Cadastral Registration’).
A link between the spatial and administrative database exists through the unique
parcel number [102].
Recently the Netherlands’ Kadaster has developed the Querytool by which the two
databases can be queried in one integrated environment [138]. Another application
launched by the Kadaster (Kadaster-online) makes both databases (spatial and administrative)
accessible for specific purposes.
2.2.3 Cadastral model
The current administrative cadastral data model in the Netherlands, and also in most
other countries, is based on three key types: real estate object, person (subject) and
right or restriction. The UML class diagram of the data model is shown in figure 2.2
(see also [101]). Real estate objects are (part of) parcels and apartment rights (linked
to a ‘mother’ parcel, not shown in figure 2.2). Persons are persons or organisations
with rights on parcels. Beside rights, there can also be a ‘restriction’ relationship
between a real estate object and a person, since a person can be the subject of a
restriction, e.g. a holder of a pipeline for which a restriction has been established.
Real estate objects and persons have n:m relationships via rights (and restrictions); a
person can have rights related to more than one real estate object (e.g. a person owns
three parcels) and one real estate object can be related to more than one person (e.g.
one person is bare owner of a parcel and another person has the right of superficies on
the parcel) [137]. Every person in the regsitration should be associated with at least
25
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
Figure 2.2: The current administrative cadastral data model in a UML class diagram.
one real estate object and vice versa; every real estate object should be associated
with at least one person (indicated with the multiplicity of ‘1..*’; for a description of
UML see section 6.5).
2.2.4 Mapping real world objects
Parcels defined in 2D are the basis for cadastral registration. Constructions and
infrastructure under or above the surface are not registering objects themselves. A
building registration also does not exist in the Netherlands, although research has been
carried out to set up such a registration in the future [92]. Therefore, the legal status
of constructions above, on and under the surface is not registered on the construction
itself. The legal status of the construction can be known from the rights that are
registered on the surface parcel(s). The notary deed, which has led to registration,
may be accompanied by an analogue drawing of the physical object but this is not
obligatory. The inclusion of digital 2D and 3D drawings in the cadastral registration
is not possible at the moment.
The Dutch cadastral geographical data set contains the boundaries of parcels and
parcel numbers, outlines of buildings (for reference purposes), street names and house
numbers. The outlines of real world objects can be incorporated in the topographic
part of LKI (which is not part of the cadastral map). Examples of such real world
objects are railways and since recently also transport systems and telecom-networks.
Apart from the classification code, these lines are encoded with a visibility code.
The visibility code indicates the visibility of the topographic line. A visibility code
‘2’ means ‘not visible from above’. Figure 2.3 shows part of the LKI database (the
topographic part). In this figure a road (running from north-west to south-east)
crosses a railway (running from south-west to north-east) with a viaduct (the road is
below the railway). The road at the location of the viaduct is invisible from above.
All lines encoded as ‘invisible from above’ are only drawn in the left figure in figure 2.3
and are omitted in the figure on the right. The mapping of underground features using
a special classification and ‘invisible’ code is optional and therefore not required.
26
2.3. 3D registration and Private Law
Figure 2.3: Lines encoded as ‘invisible’ in the topographic data set are not drawn in
the map on the right.
2.3 3D registration and Private Law
Regarding Private Law, the main types of cadastral recordings with a 3D component
are (the Dutch terms are added in italic, in brackets):
• right of ownership (eigendomsrecht) (section 2.3.1);
• limited ownership rights (beperkte rechten):
– right of superficies (opstalrecht) (section 2.3.2);
– right of long lease (erfpacht)(section 2.3.3);
– right of easement (erfdienstbaarheid) (section 2.3.4);
• right to an apartment or condominium right (appartementsrecht) (section 2.3.5);
• joint ownership (mandeligheid) (section 2.3.6).
In the remainder of this section, these rights are described, together with the cadastral
registration of these rights. Also the codes that are used in AKR (administrative
database) are given. These codes will return in the description of the case studies in
chapter 3.
2.3.1 Right of ownership
The most extensive right that a person can have is the full right of ownership, code
‘VE’ in the AKR (volle eigendomsrecht). To the exclusion of everybody else, the
owner is free to use the thing, provided that its use does not breach the rights of
others and that limitations based upon statutory rules and the rules of unwritten law
are observed [41].
The right of ownership of a parcel has a 3D component. This becomes obvious when
the upper and lower boundaries of the right lead to disputes; i.e. when more than one
27
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
person uses the parcel. Actually, the right of ownership to a parcel (as all other real
rights) always relates to a space, otherwise the use of the parcel would be impossible.
According to the Articles 20 and 21 of Book 5 of the Dutch Civil Code [41] the right
of ownership comprises:
• exclusive use of the right of space above the parcel;
• ownership of the earthlayers beneath it;
• ownership of buildings and constructions forming a permanent part of the land
(directly or by means of other constructions).
This quotation from the Civil Code indicates the ambiguity of the way ownership
is defined in the third dimension: the third dimension of ownership is not explicitly
bounded. The ownership to a parcel includes the competence to use the land owned.
This includes the space above and under the parcel to a height and depth to which
the user has (possible) interest. The use of space above and under the surface is
permitted to third persons, as long as this is sufficiently high or low, that the owner
cannot reasonably object to this use or when this use is regulated by other laws, e.g.
by the Law on Air-traffic (Luchtvaartwet) which prescribes regulations for air-traffic
[38] or by the Law on Mining which provides the possibility to extract minerals in the
ground of private owners by concession (Mijnwet 1810) [36] or permit (Mijnbouwwet
2003) [45].
Since ownership is not explicitly limited in the third dimension, in principle the right
of ownership of land reaches from the middle of the earth up to the sky. Horizontal
division of this volume is only possible by establishing rights and limited rights
on surface parcels, such as a right of superficies (section 2.3.2), right of long lease
(section 2.3.3), right of easement (section 2.3.4), and apartment right (section 2.3.5)
[127]. Horizontal division of the volume enclosing the whole parcel column leads to
3D property units, which are bounded spaces to which persons are entitled by means
of real rights.
Restrictions according to Public Law (section 2.4) and restrictions imposed by regional
and local land use plans, e.g. no more than five floors per building, can also
restrict the owner in using his parcel (column). Restrictions according to regional and
zoning plans are not registered in the cadastral registration and will therefore not be
considered within this thesis.
Vertical accession to real estate
According to Dutch Law the basic rule of accession, derived from Roman Law, is
that buildings and other constructions that are permanently fixed to the land are
considered part of that land. Consequently constructions under or above the surface
that are permanently fixed to the surface are owned by the owner of the land unless
other rights or restrictions have been established on the surface parcel (verticale natrekking)
(’superficies solo cedit’) [41]. However this is not a strict rule. The owner of
a construction below or above the surface is not necessarily always the same person
as the owner of the land parcel.
Horizontal accession to real estate
When the legal status of separated ownership on one parcel is not established (and
therefore not registered), the legal status can be obtained by the rule of ‘horizontal
accession to real estate’ (horizontale natrekking) [90]. According to the Dutch Civil
28
2.3. 3D registration and Private Law
Code, constructions fixed to the land are part of the property by vertical accession,
unless the construction is part of another property. In that case the parts encroaching
another parcel are part of the main part by the rule of horizontal accession (see
figure 2.4). Consequently these parts do not belong to the encroaching parcel, as
would be the case using the rule of vertical accession. Therefore the owner of the
main construction is also the owner of parts of the construction that encroach another
parcel. For example, where the ownership of a tunnel is not explicitly established and
registered on an intersecting parcel, the owner of this component of the tunnel could
be found by finding the point, and thus the parcel, where the main part of the tunnel is
fixed to the surface, which is presumably where the entrances are (see also discussion
in [70, 71]). The owner of the parcels containing the entrances can in this case be seen
as the owner of the entire construction, including the components which run below
the surface parcels against which no rights have been established.
Figure 2.4: An illustration of ‘horizontal accession to real estate’. The part of the
grey house that is situated under the white house (cellar) belongs to the owner of the
parcel under the grey house since this part is a component of the grey house
With a horizontal accession to real estate a factual horizontal division in ownership
takes place. The legal status follows from the factual situation. Consequently, the
legal status may change if the factual situation changes. The disadvantage of horizontal
accession to real estate is that the legal status of the situation is not registered
and therefore not clear in the cadastral registration.
The horizontal accession to real estate might conflict with the definition of the right
of ownership (vertical accession to real estate). According to the Civil Code the right
of ownership contains all constructions that are permanently fixed to the parcel while
in case of horizontal accession to real estate the owner of a parcel that intersects with
a construction is not the owner of the construction [70, 71, 218]. In principle, vertical
accession always gets priority unless horizontal accession can be applied.
It should be noted that the horizontal accession to real estate does not justify the
factual situation. It is for example not allowed to build a construction encroaching
another parcel without permission of the owner of the encroached parcel.
29
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
2.3.2 Right of superficies
According to article 101 of Book 5 of the Dutch Civil Code the right of superficies
(opstalrecht) is “a real right to own or to acquire buildings, works or vegetation in, on
or above an immovable thing owned by another”. A construction may also intersect
the surface level (located partly below and partly above the surface). The holder
of this limited right is the owner of the construction. As a limited real right it
restricts the original owner of the land: the owner has to tolerate the existence of the
construction in, on or above his land. In case of a right of superficies, AKR uses the
code ‘OS’ for the right of superficies and the code ‘EVOS’ for the right of ownership
to the land encumbered with the limited real right.
A right of superficies can be used when the owner of the construction is not the same
as the owner of the parcel. By means of this right, a horizontal division in ownership
takes place [89], although no geometry is maintained in the cadastral registration to
reflect the spatial extent of the ownership of the buildings nor of the right itself. The
complete parcel is therefore affected with the right of superficies. It is possible to add
a drawing to the deed recorded in the Public Registers to clarify the situation. The
establishment of a right of superficies provides the possibility to dictate restrictions
to the owner of the land in order to avoid damage to the construction [117].
When a right of superficies is established for a cable or pipeline, AKR uses the special
code ‘OL’ (Opstalrecht ten behoeve van leiding). This special case of a right of
superficies is in the cadastral registration not treated as a limited real right but as a
legal notification.
A legal notification (Object belemmering: object restriction) is an indication in the
cadastral registration that a restriction is imposed on the ownership of the parcel.
Legal notifications are an administrative category which describe rights and restrictions
but are not rights themselves. In most cases these are Public Law restrictions
(section 2.4), e.g. the building on the parcel is a protected monument, or the obligation
to tolerate a construction needed for a public work (e.g. a high voltage power
line) imposed by special acts, like the Belemmeringenwet Privaatrecht.
When the restriction or right registered with a legal notification affects only a part of
a parcel, the code is followed by the suffix ‘D’ (referring to the Dutch word deel, i.e.
part). Consequently a right of superficies established for a pipeline that is intersecting
with just a part of the parcel will get the indication ‘OLD’, although the location of
the pipeline is not specified in the cadastral geographical data set. In general, in case
of legal notifications, no spatial information is registered in the cadastral registration.
It is possible to add a drawing to the deed, although this is not obligatory.
The registration of the right of superficies for cables and pipelines (code ‘OL’) was
introduced in 1992. Before 1992, the AKR code ‘BZ’ (or ‘BZD’) was used in similar
cases. The code BZ is referring to a special right in rem for pipelines and other works,
which was made possible by the Belemmeringenwet Privaatrecht (Zakelijk recht als
bedoeld in art. 5 lid 3 onder b van de Belemmeringenwet Privaatrecht).
A ‘BZ’ refers to a right based on Public Law, although the right itself is a right
according to Private Law. The right was established by a notary deed signed by the
parties concerned. A ‘BZ’ right is in juridical sense similar to a right of superficies. A
30
2.3. 3D registration and Private Law
‘BZ’ legal notification should not be confused with the earlier mentioned obligation to
tolerate a construction also according to the Belemmeringenwet Privaatrecht (which
is a Public Law restriction) (see section 2.4).
Since the introduction of the new Dutch Civil Code in 1992 it is no longer possible
to establish the special right in rem registered with a ‘BZ’ code, although the old
registration codes are still maintained and not converted into the ‘new’ type of right
of superficies. After 1992, new ‘BZ-cases’ are established with a right of superficies
because of a pipeline (AKR code ‘OL’). It is confusing that in those two cases (’BZ’
and ‘OL’) the limited real rights in the cadastral registration are treated as legal
notifications and not as limited rights.
2.3.3 Right of long lease
The legal status of constructions below or above the surface can also be established
with a right of long lease (emphyteusis), code ‘EP’ in AKR (erfpachtsrecht). Code
‘EVEP’ is used to indicate the ownership of the land encumbered with the right of
long lease. Right of long lease is a juridical instrument which is sometimes used in
3D situations, however this right is not specifically meant for 3D situations.
A right of long lease gives the long leaseholder the permission to hold and use the
parcel of the bare owner, as if he were the owner. The deed of establishment may
impose an obligation upon the leaseholder to pay a sum of money (canon) to the
owner every year. This deed also contains an end-date of the lease.
It is not possible to impose a right of long lease to just a part of a parcel or a part of
a ‘parcel column’: i.e. no (juridical) horizontal division in ownership takes place by a
right of long lease. The right of long lease includes the surface parcel as well as space
below and above the parcel including the buildings that are fixed to the parcel.
In some cases of 3D constructions a right of long lease has been used. Usually the
bare owner of the parcel is the ‘user’ of the construction. The long leaseholder has
the right to use the parcel above (or below) the construction. By means of conditions
imposed on the leaseholder (described in the deed), the use and protection of the
construction can be arranged and also the dimensions to which the right of long lease
applies (which causes a factual horizontal division in ownership).
Again the geometry of the space to which the right applies is not maintained in the
cadastral registration and can only be specified in a drawing attached to the deed. The
right of long lease has been applied to (parts of) the metro in Amsterdam [90]. The
geometry of the metro or of the right itself is not known in the cadastral geographical
data set, nor in the administrative database. The only place where information could
be found on the factual situation is in the deeds archived in the Public Registers
which may be accompanied by scanned and paper drawings [90].
2.3.4 Right of easement
An easement (servitude) is a charge (encumbrance) imposed upon a parcel (the serving
parcel), in favour of another parcel, the dominant parcel [41] (erfdienstbaarheid). An
31
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
example of this is when an owner A of a parcel can reach the public road easier
by crossing the parcel of his neighbour B rather than crossing his own parcel. An
easement can be imposed on the parcel of B in favour of the parcel of A, which makes
it possible for owner A to cross the parcel of B.
It is also possible to establish a right similar to a right of easement without linking
it to a dominant parcel. This can be used when a right of easement is established for
a pipeline which has no clear dominant parcel. The restriction on the serving parcel
(Kwalitatieve verbintenis: restrictive covenant, literally: qualitative obligation) is
established in a deed archived in the Public Registers, while AKR registers a ‘KV’
code as a restriction on the serving parcel (as a legal notification). The restriction
is linked to the subject who causes the restriction. A Kwalitatieve verbintenis is a
contract which imposes an obligation on an owner of land to tolerate a pipeline. This
obligation is also binding for future owners.
In general, the deed establishing an easement may impose an obligation upon the
owner of the dominant property to pay to the owner of the serving property a sum of
money. The easement must be exercised in a way that causes the least inconvenience
to the serving property. In the example this means that A has to take the shortest
path across the parcel of B. When the dominant property is divided, the easement
continues to exist for the benefit of each part to which it may be beneficial [41]. The
easement is linked to a parcel (establishing a parcel to parcel relationship): when the
parcel is sold, rights and restrictions of an easement are taken over by the next parcel
owner.
Apart from the easements without dominant parcels (code ‘KV’), easements are not
registered in AKR as limited real rights and they also cannot spatially be defined in
the cadastral geographical data set, although a drawing can be added to the deed
specifying the spatial extent of the easement. However, in case of easements linked
to dominant parcels, the scanned deeds (and drawings) will not be directly accessible
through the cadastral database (the existence of the easement is not known as limited
real right in the cadastral database). The vertical dimension of a right of easement
can be relevant, for example when a right of easement is established for a bridge above
the serving parcel or for a pipeline that crosses a parcel. It is also possible to establish
a right of easement for having a building on a serving parcel. In all these cases, the
registration would be improved firstly by registering the existence of the easement as
limited real right in the cadastral database, and secondly by a 3D visualisation of the
space where the right applies.
2.3.5 Apartment right
The most frequently occurring 3D situations are apartment complexes. Most countries
have introduced juridical instruments to establish the ownership of apartment units.
In Germany, France and most other European countries legislation on apartment
ownership is based on the so-called “dual system” [3]. Every apartment owner has
the full ownership of a part of the building (apartment). The communal areas of
the building, such as staircases and elevators are held in co-ownership. This can
be described as compulsory co-ownership, or an accessory restricted co-ownership.
“Accessory” because it cannot be separated from the ownership of the apartment,
32
2.3. 3D registration and Private Law
“restricted” because during the time the building is divided into apartments, the
separation and division of the common areas is not possible.
Some European countries have adopted the “unitary system”, e.g. Norway, Austria,
Switzerland and the Netherlands [3]. It is important to notice that in this system the
apartment ownership is based on co-ownership of the whole complex (consisting of
ground parcel(s) and buildings on the parcels(s)).
Article 106 of Book 5 of the Dutch Civil Code [41] describes apartment ownership or
apartment right (appartemensrecht) as follows:
1. An apartment right means a share in the ownership of the property
involved in the division which also comprises the right to exclusive
use certain parts of the building which, as indicated by their lay-out,
are intended to be used as separate units. The share can also include
the right to exclusive use of certain parts of the land pertaining to
the building.
2. An apartment owner means a person entitled to an apartment right.
The owners of the apartment units are joint owners of the entire building and the
ground below. The underlying ground may consist of several parcels which can be
disjoint. The co-ownership includes the right to have the exclusive use of a certain
part of the building: the apartment unit (exclusief gebruikersrecht). This means that
the persons do not legally own a separate apartment unit, although the apartment
ownership can be mortgaged.
The division in apartment rights is based on a notarial deed, the so-called “deed of
division” (splitsingsakte). A plan obliged in this deed is maintained in paper and
scanned format in the Public Registers. This plan gives an overview of the building
and a detailed plan of each floor. Thick dark lines indicate the borders of every
apartment, i.e. the area of exclusive use. How apartment units are registered in the
current cadastral registration will be described in more detail by a case study in
chapter 3.
Though an apartment right is the best way to establish multilevel ownership on one
parcel, the registration of apartment units can still be improved. Only the ground
parcel(s) of the apartment building is (are) maintained as part of the cadastral geographical
data set and therefore the individual apartments cannot be recognised
on the cadastral map. Consequently apartment units cannot spatially be queried,
although ownership information on the individual units is available in AKR. Another
complication that can be mentioned is that an analogue (or scanned) drawing
is used to clarify the cadastral situation in the deeds. Spatial information available in
vector format and in real world coordinates would make it possible to integrate the
information from the drawings with the cadastral geographical data set.
Basic characteristics of apartment units are that the apartment units within one complex
have a juridical relationship with each other (e.g. they share common area in a
building) and the apartment complex is concentrated on one or several parcel(s).
However apartment rights are also used in the case of independent stratified properties
crossing parcel boundaries, e.g. for shops and dwelling units in one building or
33
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
for public underground parkings, which motivates the search for a more general solution
for 3D situations. This solution should better reflect the nature of independent
multilevel ownership on one parcel or crossing several parcels.
2.3.6 Joint ownership
Dutch land law knows a special type of joint ownership: mandeligheid (compare the
French “mitoyennet´e”). This is a right to land and/or a construction that can be
registered similar to common area as in condominiums. This immoveable thing arises
when an immoveable thing is joint owned by the owners of two or more properties
and where it is designated by them for the common benefit of those properties by a
notarial deed between them, which is then recorded in the Public Registers [41]. Joint
ownership comprises the obligation of each joint owner to give the other joint owners
access to the thing held in joint ownership. Things held in joint ownership must be
maintained, cleaned and, if necessary, renewed at the expense of all joint owners. A
joint owner of a thing held in joint ownership may transfer his share in the thing to
the other joint owners separately from his property. This characteristic is why joint
ownership is in some cases favoured above registration by means of condominium by
which it is not possible to transfer shares separately from the property (apartment
unit). A specific cadastral characteristic of joint ownership that it is only registered
on a parcel and not linked to a subject. The 3D characteristic of an immovable
thing held in joint ownership can be of importance in cadastral registration when not
the whole parcel is held in co-ownership, e.g. underground parking places, swimming
pools, tennis courts, aerials etc.
2.4 3D registration and Public Law
The Kadaster also registers restrictions in the ownership of parcels as dictated by
Public Laws (Publiekrechtelijke Beperkingen). For a better understanding of the Public
Law restrictions that need to be registered, a selection of such laws containing
a 3D component was made. These laws as well as the cadastral registration of the
restrictions imposed by these laws will be described below:
• Belemmeringenwet Privaatrecht: obligation on the owner of land to tolerate a
construction for public good (section 2.4.1);
• Law onMonuments (Monumentenwet): registration in order to protect historical
monuments (section 2.4.2);
• Law on Soil Protection (Wet Bodembescherming): registration of severe soil
pollution (section 2.4.3).
A proposal has been prepared by the Ministry of Spatial Planning, Housing and the
Environment to renew the Public Law recordings and to register legal restrictions
issued by the national government (about twenty-five) and by the provincial government
(about ten) in the cadastral database as listed in the proposal. At this
moment, the list still needs to be finalised [238]. Examples of laws which will lead to
34
2.4. 3D registration and Public Law
a cadastral registration of a restriction on a parcel are Wet voorkeursrecht gemeenten,
Belemmeringenwet privaatrecht, Landinrichtingswet, Reconstructiewet Midden-
Delfland, Woningwet, Natuurbeschermingswet, Wet geluidhinder, Deltawet, Wet op
de lijkbezorging and the Boswet. The municipalities will be responsible for a registration
of restrictions (also on parcels) according to municipal regulations. Therefore
they will maintain a municipal restriction register, which is linked to the cadastral
registration [238].
All the restrictions mentioned here are registered on parcels as object restrictions
(Object belemmering), i.e. as legal notifications. The parcels are affected with a restriction
in the right of ownership, which is stored in the administrative database.
The restrictions are registered, not the factual objects which cause the restriction
(monument, cable, pollution etc.).
2.4.1 Belemmeringenwet Privaatrecht
According to a special law in the interest of public good (Belemmeringenwet Privaatrecht)
[37] the owner of land can be obliged to tolerate constructions hold by others
such as lampposts, electrical cables, water pipes, telecom pipes, tunnels etc. [194].
AKR uses the codes ‘BP’ and ‘BG’, or ‘BPD’ and ‘BGD’ for an obligation established
for a part of a parcel. This restriction is used only when no other agreement
can be arranged with the owner (e.g. right of superficies, personal rights described in
contract etc.). In addition, the restriction does not allow the imposition of precisely
described limitations on the user of the parcel in order to protect the construction
against damage. Therefore this restriction is rarely used.
Since the objects themselves (cables, pipelines, tunnels) are not registered, only the
parcels are known below (or above) which a construction is situated. The exact
(horizontal and vertical) location of the construction is not known in the cadastral
registration, although it is possible to make the outlines of an underground construction
visible on the cadastral map.
The obligation of toleration by law only holds for cables and pipelines for public good.
Consequently, for those cables and pipelines for which no toleration can be enforced
(when it does not serve the public in total) and for which no right of superficies has
been established, nothing is registered.
According to Private Law, the owner of the intersecting parcel becomes the owner
of the cable or pipeline, since the construction is permanently fixed to the surface
(verticale natrekking). If horizontal accession gets priority to vertical accession, (as
in most cases) the owner of the parcel where the cable or pipeline is permanently
fixed to the surface (comes to the surface) becomes the owner of the cable or pipeline.
An exception to the vertical and horizontal accession to real estate are the type
of pipelines that fall under the Law on Telecommunication [44]. For an extensive
juridical discussion on the ownership of cables and pipelines see [70, 71].
According to a decision of the Dutch Supreme Court in June 2003 [46] telecomnetworks
are immovable goods and these cables are always owned by the holder of
the permit to exploit the cable. This holder has (usually) a right on the parcel where
the cable comes to the surface. Since telecom-networks are considered as immovable
35
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
goods, the cadastre is obliged to register the transfer of networks as well as the
establishment of limited real rights on them. It is expected that in the future this
decision will apply to other cables and pipelines (gas and electricity) as well. It should
be noted that a lot of infrastructure objects are or can be used for telecommunication
and the may all fall under this law. The registration of telecom-networks is done in
the following way. If a telecom-network is transferred, the holder of a telecom-network
offers the spatial description (centre line) of the network to the cadastre. The network
is then registered on at least one ‘anchor’ parcel on which the holder of the network
has a real right, e.g. on a parcel where a network substation is located. The other
intersecting parcels do not need to be mentioned in the deed but can be found by
consulting the drawing archived in the land registration (see figure 2.5).
Figure 2.5: Example of drawing added to deed in case of a telecom-network.
On all intersecting parcels an object restriction (legal notification) can be registered,
AKR code ‘TC’ or ‘TCD’. The spatial description of the network can only be incorporated
in the topographic part of LKI and not in the cadastral geographical data set
[107]. According to article 174 and 175 of Book 6 of the Dutch Civil Code the manager
of the cable or pipeline is always responsible for damage caused by a defect in the
cable or pipeline or by hazardous material transported through the pipeline whether
he is the juridical owner or not. This also holds if the manager is not registered as
the owner of the cable or pipeline.
The establishment of a right of superficies (right according to Private Law) for cables
or pipelines provides the possibility to keep the right of ownership explicitly with the
cable or pipe holder. This special case of right of ownership (right of superficies for
cables and pipelines) is registered as such by the Kadaster by using the code ‘OL’
36
2.4. 3D registration and Public Law
(Opstalrecht ten behoeve van leiding). As was seen in section 2.3.2 this is a legal
notification in the administrative database [90].
2.4.2 Law on Monuments
The Law on Monuments (Monumentenwet) [39], established in 1961, protects buildings
and parts of buildings with monumental value but also earth layers below the
surface with archaeological value. According to this law, it is possible to impose restrictions
on the owner of a monument, e.g. not rebuild certain parts of a house. The
restriction is registered on the whole parcel (code ‘MW’ or ‘MWD’ when only part of
the parcel is encumbered with a restriction) while the geometry (outline of the monument
or archaeological site) is not maintained in the cadastral register (figure 2.6).
Figure 2.6: A selection of parcels (highlighted in the map) encumbered with a notification
because of a monument in the city centre of Delft.
More details on the exact location of the monument on the parcel can be found in the
Public Registers on drawings added in deeds. To protect monuments, a complete and
correct registration of monuments is necessary. An owner of a monument gets funding
from the government. This also requires a correct registration of monuments in order
to assign the funds to the right person. Another reason why cadastral registration
according to the Law on Monuments is becoming more important is that recently
archaeological sites have received more protection under European agreement [216].
This agreement states that planners of new projects (infrastructure or new city sites)
have to take care of the conservation of archaeological treasures in the unexplored
subsurface. Cadastral registration can provide the planners of new projects with
information on archaeological sites.
Often only the fa¸cade of a building or just a part of a building is a monument and not
the whole building. In current cadastral registration the whole parcel is encumbered
with a ‘MW’ (or ‘MWD’) code. Although the actual part that covers the monument is
37
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
indicated in the deed archived in the Public Registers, a 2D (or 3D) spatial description
of the monument in the cadastral registration would show immediately that not the
whole parcel (or building) is a monument. Also the spatial description of underground
space with archaeological value in the cadastral registration would provide insight into
the exact location of the protected site, without having to look in the Public Registers.
At the moment about 60,000 monuments have been registered in the cadastral registration
(using one or several parcels). The Register for Monuments (Monumentenregister)
[179] also registers monuments. Consequently there are two sources for
monuments: the cadastral registration that records the existence of a monument on a
whole parcel and the Register for Monuments that records the monument itself. However,
the Register of Monuments was out of date and contained many errors since it
was never linked to the cadastral registration. Therefore, the Register for Monuments
started a project in 1999 to clear their register by linking it to the cadastral registration.
The clean up action is a tremendous job, since all monuments have to be
checked to see if the recording of a monument is still valid, although the process is
performed semi-automatically. According to the plans, it will take 200 man-years and
15 million Euro to clean the whole register [180]. Spatial information on monuments
(2D and preferably 3D) in the cadastral registration could support the Register for
Monuments to maintain a good (up-to-date and precise) registration.
2.4.3 Law on Soil Protection
According to the Law on Soil Protection (Wet Bodembescherming) [42], cases of severe
soil pollution have to be registered in the administrative part of the cadastral
registration, using code ‘WB’ or ‘WBD’. When (a part of) the subsurface of a parcel
is polluted, the parcel is indicated as a polluted parcel. The provinces are obliged to
report a severe pollution to the Kadaster. With this report a (2D, analogue) drawing
of the location of the pollution is archived in the Public Registers (see figure 2.7).
However since the accuracy of the drawings is not prescribed, the exact locations of
pollution are still very unclear in most cases. 3D information on pollution locations
is totally lacking. The disadvantage of this registration is that, due to lack of spatial
information, the whole parcel becomes affected by the decision. The exact location
(in the horizontal as well as in the vertical dimension) of the pollution is not registered
and therefore not known in the cadastral registration.
2.5 Other relevant aspects of cadastral registration
In this section other aspects of cadastral registration in the Netherlands are described
which are relevant for this research or will occur in the case studies in chapter 3.
2.5.1 Underground objects in the cadastral registration
A special case of legal notifications is the registration code ‘OB’ or ‘OBD’ (Ondergronds
Bouwwerk: underground construction), which was introduced in 1998. This is
38
2.5. Other relevant aspects of cadastral registration
Figure 2.7: Drawing added in deed to indicate severe soil pollution (Note that polluted
area is indicated by hatching).
just an indication in the administrative database of the existence of an underground
object in the subsurface of a parcel. An ‘OB’ code is linked to a parcel and to a
subject (which is the person responsible for the object). The ‘OB’ code indicates the
factual situation but it is not a right or restriction itself. Although it is registered as
an object restriction, it has no juridical consequences and it does not indicate how the
legal status of the construction has been established. To find out the legal status of
the underground object, one has to find out what other rights, restrictions and legal
notifications are established on the surface parcel. Recently it has become possible to
add boundaries of transport systems and telecom-networks in the topographic part
of LKI (which is not part of the cadastral map, see section 2.4.1). If these boundaries
are below the surface they are also encoded with the visibility code ‘2’ (’not visible
from above’).
2.5.2 Parcels and part parcels
According to the Dutch Kadasterwet [43] (Law on the Cadastre and the Public Registers)
the existing parcel must be subdivided if the ownership of a part of a parcel is
39
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
transferred, or a limited real right (e.g. a right of superficies) is established for only a
part of a parcel (e.g. in case a tunnel intersects with only a part of the parcel). The
boundaries of the new parcels are based on the part of the parcel that is transferred, or
is encumbered with the limited right. However, unlike many other countries, in Dutch
law it is not compulsory to obtain the permission of authorities preceding the subdivision.
Additionally it is not necessary that new parcels are measured and created in
the (spatial part of the) cadastral registration before the ownership is transferred or
before the limited right has been established. Therefore, it is common practice that
new parcels are created months (or in some cases even years) after the notary deed
establishing the limited right, or transferring a part of a parcel has been registered in
the Public Registers. It is also possible to subdivide a part parcel into parts before
surveying.
As long as the new parcel boundaries are not measured, the cadastral registration
uses the expression ‘part parcel’ (deelperceel). Awaiting the formal spatial creation
of the new parcels, the administrative number of the parcels to be created is the old
parcel number followed by the suffix ‘D’ and an index number. It is important to
notice that those part parcels are in fact still one (original) parcel on the cadastral
map. An example will make things clear. L, the owner of a parcel numbered A 1000,
establishes a right of superficies (held by S) on a part of this parcel. In this case the
original parcel must be subdivided into two new parcels, one held in full ownership
by L, and the other held in restricted ownership by L, encumbered by the right of
superficies held by S. Awaiting the formal division the two part parcels will get the
numbers A 1000 D1 and A 1000 D2. On the cadastral map the part parcels are
drawn at the same location as the original parcel A 1000. Only after a surveyor of
the Netherlands’ Kadaster has measured the new parcel boundaries, are new numbers
assigned, e.g. A 1199 and A 1200 and the new parcel boundaries become visible on
the cadastral map.
Not in all cases is a new parcel created when a limited right only affects part of
the (original) parcel. An important exception to this rule is the right of superficies
concerning cables and pipelines (art. 6 Kadasterbesluit) [40]. Even when the location
of a cable or pipeline is indicated in the notary deed establishing this right, the parcel
will not be subdivided. The ‘BZD’ (before 1992) or the code ‘OLD’ (after 1992) will
be used instead of ‘OS’ as in ‘normal’ cases of right of superficies (see section 2.3.2).
2.5.3 Frequency of types of cadastral recordings
To see how frequently the limited rights and legal notifications as described in this
chapter currently occur, we examined the cadastral database of September 2003. The
next table shows the frequency of AKR codes, referring to limited rights and legal
notifications described in this chapter, as they occurred in the cadastral database of
September 2003. The numbers also include the notifications and limited rights that
were established on part of parcels (using the suffix ‘D’).
OS OL TC BZ EP BP/BG WB MW OB
63,538 225,779 1,569 836,702 331,809 650 195,009 111,223 1,532
40
2.6. Conclusions
OS = right of superficies
OL = right of superficies for pipeline, registered after 1992
TC = parcel used to register telecom-network
BZ = similar to OL, but registered before 1992
EP = right of long lease
BP or BG = imposed toleration for public good
WB = restriction because of Law on Soil Protection
MW = restriction because of Law on Monuments
OB = underground object
It should be noted that these figures only indicate how often a specific code is registered
in the cadastral registration. The question as to whether the registration refers
to a 3D property situation cannot be obtained from these figures. The total number
of parcels in the database of September 2003 is 6,595,393. The topographic part of
the cadastral registration (LKI) was queried for occurrences of transport systems and
telecom-networks. This resulted in no occurrences, although about 9000 pipelines
were present in the data set.
The numbers in the table underline once again the need for more information in case
of 3D situations. Almost two million recordings were found that could indicate a 3D
situation. The apartment units are even left out from these numbers. In total 120,188
parcels where found in the database of September 2003 which contain apartment
complexes that consist of 1,260,573 apartment units. In total 50,743 parcels are
registered as parcels which are subdivided but not remeasured yet (which means they
contain two or more part parcels). Another interesting result of this examination
was that 1,569 parcels have been found with a ‘TC’ code (parcels intersecting with a
telecom-network) while only five networks have been registered, with three holders in
total:
• GC PAN EUROPEAN CROSSING NEDERLAND
• ENERGIS N.V.
• MCI WORLDCOM
This indicates the overhead of information in case of infrastructure objects.
2.6 Conclusions
In this chapter 3D aspects of cadastral registration according to Dutch Private Law
and Public Law were described.
Establishing the legal status of 3D situations
The most important cadastral registration is the right of ownership. The right of
ownership is established on a parcel and applies for all space above and below the
surface parcel, i.e. the ownership of a parcel is not limited in the third dimension. An
owner of a parcel can be restricted in using the whole parcel column by establishing
limited real rights on the parcel, by establishing apartment rights or by imposing
Public Law restrictions.
41
Chapter 2. Current cadastral registration of 3D situations in the Netherlands
When no rights are established, the rules of vertical and horizontal accession apply.
Vertical accession means that the owner of a parcel also owns all constructions which
are permanently fixed to the surface parcel. Horizontal accession defines that parts
of a construction encroaching another parcel (above as well as below the surface)
are part of the main part by accession. Both vertical and horizontal accession are a
consequence of the factual situation and not established with (limited) rights and can
therefore conflict in a certain situation. Another disadvantage is that the legal status
of the 3D property situation, which is a consequence of the factual situation, is likely
to change with the creation or destruction of constructions.
An explicit horizontal division in property can only be juridically effectuated by either
a right of superficies or an apartment right. Also a right of long lease and a right
of easement are limited real rights which can restrict the bare owner (i.e. the person
who holds the ownership of a parcel that is encumbered with limited real rights) in
using the whole parcel (column). Although these rights do not establish a juridical
horizontal division in ownership, conditions in the deeds establishing these rights can
define (and thus limit) the space where the specific right applies to. Apartment rights
and limited real rights cause therefore a horizontal division of the parcel (column)
into 3D property units which are bounded volumes to which persons are entitled by
means of real rights.
Restrictions according to Public Law can also restrict an owner of a parcel in using
his parcel. In this chapter a selection of Laws were described that impose restrictions
according to Public Law and that are registered in the cadastral database:
• restriction because of an obligation to tolerate a construction the for public good
(this does not regulate the ownership of the construction);
• restriction according to Law on Monuments;
• restriction according to Law on Soil Protection.
Registration of the legal status of 3D situations
Once the legal status of 3D situations has been established (the juridical step), the
next question is how these limited rights and (Public Law) restrictions are registered
in the cadastral registration and if information on the space to which rights apply is
registered and available in the cadastral registration. The legal status of (2D) parcels
as well as the spatial extent of parcels are very well registered in the (Dutch) cadastral
registration. However, as can be concluded from this chapter, there are several reasons
why information on the legal status of 3D situations is not (always) straightforwardly
accessible.
The legal status of constructions and phenomena above, on and below the surface
(buildings above roads, tunnels, pipelines, monuments and pollutions) is not registered
in the current cadastral registration. The legal status in those situations can be found
by examining the (limited) rights that are established (and thus registered) on the
surface parcel(s) that intersect with a construction or phenomenon. The reason for
this is the basic principle of a cadastre, i.e. rights and limited rights are established
and registered on (2D) parcels. The function of a real right and whether it concerns
a construction on, above or below the surface is not registered.
Spatial information on rights can be added in deeds, but is not incorporated in the
current cadastral registration (to what space does the right apply?). The current
42
2.6. Conclusions
(2D) cadastral geographical data set (the spatial part of the cadastral registration)
only contains parcels and buildings. Outlines of other real world objects for reference
purposes can be inserted into the topographic data set that is maintained by the
Kadaster.
Only in the case of apartment units, the registration provides clear administrative
information on the factual situation, since the administrative database does contain
information on individual apartment units. To get a spatial overview of the property
situation of apartment rights, the deeds archived in the Public Registers need to be
examined. Once the deeds are digitally accessible through the cadastral database,
which will be possible within this year (2004), the overview drawings of apartment
complexes can be viewed directly from the cadastral registration.
A person who queries the cadastral registration wants to obtain insight into the legal
status of the situation. However since constructions are not registered as themes and
since rights are mostly also not explicitly related to physical objects in the real world,
the accessibility of information on the legal status of 3D situations is poor.
The necessity of improving information on 3D situations was emphasised by a query in
the cadastral database of September 2003, which yielded about two million cadastral
recordings of situations in which more than one person has interest in one parcel.
However, in those cases further investigation needs to be done to find out the spatial
extent of the concerning rights and restrictions in order to get insight into the factual
situation.
As can be concluded from this chapter there are many recordings both according to
Private Law and Public Law for which a 3D approach for registration would give
better insight into the factual situation and would provide better means to manage
the situation (e.g. in the case of monuments and soil pollution).
Based on the inventory in this chapter, we can define two basic limitations in the current
cadastral situation as it applies 3D situations. Firstly, the space where a right
applies for is not registered and not available in the cadastral registration. Secondly,
constructions and other phenomena above or below parcels are not registered as such
in the cadastral registration and cannot be queried. Since there is no link with a
3D representation of reality (representation of physical construction), the cadastral
registration cannot properly reflect the real situation. Therefore a 3D approach comprises
two aspects: give insight in spatial component of (limited) rights on the one
hand and make it possible to maintain spatial as well as non-spatial information on
constructions in addition to parcels on the other hand.
43

Chapter 3
Current practice of 3D
registration: case studies1
In chapter 2, 3D aspects of the current Dutch cadastral registration were described.
To illustrate the way 3D situations are currently registered in the Dutch cadastral
registration, six case studies in the Netherlands were selected. The aim of the case
studies is to show if current registration possibilities are sufficient in the case of
stratified property or if improvements are needed. 3D situations are still relatively
rare and mainly occur in urban areas. However some 3D situations are particularly
for rural areas, e.g. a pipeline crossing several parcels owned by private persons. The
case studies were selected in such a way that they form a representation of the types
of 3D situations that currently occur in practice. Another criterion in the selection
process was that the cases should be simple in order to illustrate as clearly as possible
the constraints of current registration. The case studies are divided into building
complexes (section 3.1) and subsurface infrastructure objects (section 3.2). Building
complexes mostly occur in urban areas and interact with other types of land use.
In those cases mostly private parties are involved. Subsurface infrastructure objects
are mainly constructions meant to serve the public. Other cases (e.g. soil pollution,
archaeological sites and monuments) are not studied because it is the intention of
these case studies to get a picture of the complexity of cadastral registration of 3D
situations in general, rather than to analyse all possible cadastral recordings with a 3D
component, which are numerous and all have their specific characteristics. Therefore
the most common and basic types of cadastral registration have been selected. It
can be expected that types of cadastral registration that are not dealt with in these
case studies, would show similar basic complications. The chapter will end with
conclusions.
Future cadastral registration of the selected case studies will be shown in chapter 12,
where the prototypes developed as part of this research are applied to the case studies
introduced in this chapter.
1This chapter is based on [200] and [201].
45
Chapter 3. Current practice of 3D registration: case studies
3.1 Building complexes
The main characteristics of property units in building complexes are that two or more
parties are involved in the ownership of the building and that different property units,
often with different functions, are located within one building complex, concentrated
on one or several ground parcel(s). The demand that private persons have concerning
the cadastre is that their properties are registered properly. Cadastral query must
provide sufficient insight into what persons own, and the location of the property
boundaries. Since real estate has significantly gained value during the last decades, it
has become more important to register property clearly and unambiguously. Building
complexes are therefore relevant objects to study current registration possibilities
of 3D situations. How are property units in building complexes registered at the
moment? In what way does the cadastral registration provide insight into the property
units in building complexes? Does the cadastral registration provide insight into the
location of boundaries of the property units, also in the third dimension? To answer
these questions, three case studies are described: an arch (building above a road), a
multi-functional building complex and an apartment complex.
3.1.1 Case study 1: Building complex in The Hague
Figure 3.1: Building over a road
Figure 3.1 shows an example of a 3D situation: a building over a highway in The
Hague. The right of property of the building has been established by establishing
rights on the three intersecting parcels (figure 3.2). On the cadastral map (figure 3.2)
you can see the outlines of the building (on surface level) and the surface parcels. The
arrow indicates the view position of the camera in figure 3.1. The firm ‘Ing Vastgoed
Belegging BV’ is holder of the whole building. The rights and restrictions established
on the intersecting parcels are as follows. The municipality holds a restricted right
of ownership on parcels 1719 and 1720. ‘Ing Vastgoed Belegging BV’ possesses an
unrestricted right of ownership on parcel 1718, a right of superficies on parcel 1719
46
3.1. Building complexes
and a right of long lease on parcel 1720. In this example there is one building with
one owner (’holder’). However three parcels are used to establish the legal status of
the whole building.
Figure 3.2: Cadastral map of the building in figure 3.1. The arrow indicates the
position of the camera.
3.1.2 Case study 2: The Hague Central Station
The Hague Central Station is a building complex in the city centre of The Hague.
It is a combination of a multilevel public transport interchange (bus/tram station
and railway station), an office centre and shops (see figure 3.3 (a)). All parts of this
complex are owned by different governmental and commercial organisations. This
is achieved by dividing the high building (office and railway station) into apartment
rights, and the establishment of a right of superficies for the bus/tram station.
The use of apartment rights will be discussed in more detail in the next case. Here
we take a closer look at the right of superficies. A right of superficies is a limited
real right that entitles its holder to build and have a building (or an other type of
construction) in, on or above the land owned by another. As a limited real right it
restricts the landowner in his use: he has to tolerate the existence of (a part of) the
building on his parcel. On the other hand, the holder of the right of superficies is
the full owner of the erected building. In the case of The Hague Central Station, the
holder of the right of superficies is entitled to build and own the tram/bus station on
47
Chapter 3. Current practice of 3D registration: case studies
top of the railway platforms. The cadastral map of this complex is shown in figure 3.3
(b). The arrow indicates the position of the camera in figure 3.3 (a). The bus/tram
station on top of the railway platform is erected on parcel ‘13295’, the business center
is on top of the railway station on parcel ‘12131’.
(a) Overview of situation (b) Cadastral map
Figure 3.3: The Hague Central Station, combination of a business centre, a railway
station and a bus/tram station.
According to the cadastral DBMS (AKR), the right of the concerning parcels are:
Parcel Kind of right Right owner
12131 VE VER. VAN EIG. STICHTHAGE
divided into two apartment untis:
12205A0002 VE STICHTHAGE TRUST B.V. GEV. TE’S-GRAVENHAGE
12205A0001 VE NS VASTGOED BV
13288 VE NS VASTGOED BV
13289 VE NS VASTGOED BV
13290 VE NS VASTGOED BV
13291 EVOS NS VASTGOED BV
13291 OS Gemeente Den Haag
13292 EVOS NS VASTGOED BV
13292 OS Gemeente Den Haag
13293 EVOS NS VASTGOED BV
13293 OS Gemeente Den Haag
13294 EVOS NS VASTGOED BV
13294 OS Gemeente Den Haag
13295 EVOS NS Railinfratrust BV
13295 OS Gemeente Den Haag
VE = full right of ownership
OS = right of superficies
EVOS = right of ownership, restricted by a right of superficies
48
3.1. Building complexes
Analysing these results, it is clear which persons have a right on the relevant parcels.
For example for parcel 13295, AKR shows that “NS Railinfratrust BV” is owner of
the land (with the railway platforms), and that the municipality of The Hague (in
Dutch: gemeente Den Haag) is holder of the right of superficies (tram/bus station).
However, neither these data nor the cadastral map give insight into how the rights are
divided in the vertical dimension on every single parcel. There is also no indication in
the cadastral registration that the municipality is the factual owner of the bus/tram
station. A study in the Public Registers did not reveal much more information.
Except for parcel 12131 (divided into apartment rights), the concerning deeds do
not contain a spatial description or a (clear) drawing to clarify the division into 3D
property units.
3.1.3 Case study 3: Apartment complex
A typical form of multiple use of space, known in Dutch law since 1953, is apartment
ownership (condominium ownership). For this case, we used a ‘simple’ apartment
complex, consisting of one ground parcel and three apartments. One apartment is
located on the ground floor, and the two other apartments are located on the second
and third floor, next to each other, with an entrance on ground level (see figure 3.4).
Figure 3.4: Apartment complex used in case study.
The deed of division of this apartment complex (archived in the land registration)
contains a drawing with a cross-section and the overview of every floor (see figure 3.5).
The individual apartments are numbered. The rights at the location of the apartment
complex according to the cadastral registration are as follows:
Parcel Kind of right Right owner
5238 G0 VE VER. VAN EIG. I.HOORNBEEKSTRAAT 51-55, DELFT
divided into three apartment units:
6408 A3 VE PERSON1
6408 A2 VE PERSON2
6408 A1 VE STOTER
VE = full right of ownership
49
Chapter 3. Current practice of 3D registration: case studies
(a) 1st floor (b) 2nd floor (c) 3rd floor
Figure 3.5: Drawing added to deed of division.
At first glance it seems that there are four owners, the “vereniging van eigenaren”
(association of owners) and the holders of each of the three apartments. But this
conclusion is incorrect. The parcel 5238 G0 refers to the ground parcel with the
apartment complex erected on it. In practise the Kadaster names the “vereniging
van eigenaren” (the association of owners) as owner. From a legal point of view
this is not correct. The complex is co-owned by all the apartment owners, not by
the association. In Dutch law the association of co-owners is merely a legal body
entrusted with the day-to-day administration and management of the complex. All
the co-owners of the complex are by definition members of this association, which is
not explicitly registered in the cadastral registration.
Apart from the (co-owned) ground parcel, the individual apartments are each indicated
by a unique number (6408 A1, 6408 A2, 6408 A3). The suffix A shows that
this number refers to an apartment right. The last digit is the same as the apartment
number in the deed of division.
Importantly the individual apartments, the areas of exclusive use, cannot be found on
the cadastral map (see figure 3.6). The land registration has to be queried to find the
plan of division. Addition of (3D) spatial information on the individual apartments
in the cadastral registration would enhance insight. Another disadvantage of current
apartment registration is that the plans in the notarial deeds are only available on
analogue (and in the future on scanned drawings) in a local coordinate system (in 2D
50
3.2. Subsurface infrastructure objects
layers). When spatial information on apartment units would be available in vector
format in the national reference system, this information could be incorporated as
part of the cadastral geographical data set or in other geo-data sets (e.g. topographic
data) when requested.
Figure 3.6: The cadastral map of the apartment complex in figure 3.4. The parcel in
question has been drawn with a thicker line-style. The front of the building is indicated
with an arrow. Note that the parcel is larger than the footprint of the building, since
the parcels also includes a garden (’tuin’ in drawing of deed of division).
3.2 Subsurface infrastructure objects
Infrastructure objects are objects that are necessary to transport all kinds of things
(cars, trains, electricity, water, communication). The main characteristics of infrastructure
objects are their benefit to the public, their linear shape, and the fact that
they cross parcel boundaries. From a cadastral point of view, it is important to register
the property rights of infrastructure objects and to register public restrictions
because of the infrastructure objects, not merely to secure the value of the real estate
for the persons involved, but also to indicate who is responsible for the object (for
example in case of damage). In addition, establishment of rights on infrastructure
constructions provides a means to protect the construction against damage by specifying
conditions in the accompanying deeds. A precise registration is also required,
since the holder of the construction is usually obliged to pay the parcel owner a sum
of money. Finally, information on the exact location of tunnels and pipelines is indispensable
in risk management with regard to the increased attention on calamities in
the past ten years (although it can be questioned if this is a specific cadastral task).
In this section three case studies of subsurface infrastructure objects are described
(a railway tunnel in an urban area, a railway tunnel in a rural area, and two utility
pipelines) to show the possibility to locate infrastructure objects in current cadastral
registration.
51
Chapter 3. Current practice of 3D registration: case studies
3.2.1 Case study 4: Railway tunnel and station in urban area
Figure 3.7: Rijswijk railway station (left) and kiosk (right).
An interesting case of multiple use of space in the Netherlands can be found in the
centre of Rijswijk, a suburb of The Hague. Some years ago the railway line running
through this town was tunnelled. On top of this tunnel buildings were constructed. A
small part of the tunnel area is shown in figure 3.7 and 3.8. In figure 3.9 the cadastral
map of the situation is shown. According to AKR the following rights have been
established on the parcels:
Parcel Kind of right Right owner
7854 OS NS VASTGOED BV
7854 EVOS NS RAILINFRATRUST BV
7855 OS NS VASTGOED BV
7855 EVOS NS RAILINFRATRUST BV
7856 VE NS VASTGOED BV
7857 OS NS VASTGOED BV
7857 EVOS NS RAILINFRATRUST BV
7944 OS DE GEMEENTE RIJSWIJK
7944 EVOS NS RAILINFRATRUST BV
7945 VE NS RAILINFRATRUST BV
7946 VE NS RAILINFRATRUST BV
7949 EVOS NS RAILINFRATRUST BV
7949 OS DE GEMEENTE RIJSWIJK
VE = full right of ownership; OS = right of superficies;
EVOS = right of ownership, restricted by a right of superficies
In this area there is:
• a railway station building, owned by NS Vastgoed BV (parcel 7856 whole parcel
column; 7857 ground level)
• a railway tunnel, and platforms owned by NS Railinfratrust BV (parcel 7854,
7855, 7857, 7944, 7949 underground; 7945, 7946 whole parcel column)
• public space owned by Gemeente Rijswijk (7944, 7949 ground level)
• a kiosk, owned by NS Vastgoed BV (7855 and 7854 ground level)
52
3.2. Subsurface infrastructure objects
Figure 3.8: The location of parcels around the building of the railway station.
Figure 3.9: Fragmented pattern of parcels caused by the projection of 3D objects on
the surface. The arrow indicates the position of the camera in figure 3.8.
In figure 3.7 the pyramid-shape object is the building of the railway station (parcels
7856 and 7857), the building on the right is a kiosk (parcels 7854 and 7855) and the
railway tunnel is located beneath the buildings.
The cadastral map and the photo of figure 3.8 show that the station building, owned
by NS Vastgoed, has been built for the major part above the tunnel (assuming that
the tunnel is located below the surface parcel 7857) and for a relatively small part next
to the tunnel (parcel 7856). For the first part NS Vastgoed holds a right of superficies
on the parcel owned by NS Railinfratrust BV, for the second part NS Vastgoed has
the full ownership of the parcel. This case also shows that the 3D spatial extent of
rights is not available in the cadastral registration, although it is possible to see that
more than one person is entitled to a parcel.
This example is a good illustration of how 3D physical objects below and above the
ground control the parcel pattern in the cadastral map (e.g. 7856 and 7857 for the
railway station building, also the tunnel is identifiable in the patterns of parcels).
Moreover 3D physical objects are “divided” into parts according to the parcel boundaries
on the surface. The cadastral map on this location reflects the basic principle
of the current cadastre, i.e. registering rights on 2D parcels.
53
Chapter 3. Current practice of 3D registration: case studies
3.2.2 Case study 5: Railway tunnel in rural area
In the Netherlands the Paris-Amsterdam High Speed Railway (figure 3.10) is currently
under construction (planned to be finished in 2007). Since this railway is passing
through unaffected rural land, it was decided to drill a tunnel for this part of the
railway. The project team of the tunnel provided us with 3D data for the tunnel,
which we then imported as one spatial object (a linear object) into the cadastral
DBMS. Therefore it was possible to query the legal status of the intersecting parcels.
Normally this is not possible since physical objects are not maintained within the
cadastral registration. The tunnel itself is about 15 metres in width and 8.5 kilometers
long: 7,160 meters for the actual drilled tunnel and two entrance sections of 660 meters
and 770 meters in length.
Figure 3.10: The railway tunnel in the “Green Heart” of the Netherlands.
In November 2001 the activities for this tunnel started. The drilling of the tunnel
was completed in January 2004. We had access to three snapshots of the cadastral
database: June 2000, June 2001 and September 2003. Between June 2000 and
September 2003, most of the property rights needed by the Ministry of Transport and
Public Works were obtained and registered. For this reason we were able to study
the differences in the legal status of the parcels that contain the tunnel between the
different snapshots. The results of this investigation are shown in table 3.1.
As can be concluded from this table, at the location of the planned tunnel many
changes have taken place between June 2000 and September 2003. Of the original
104 (complete) parcels that intersected with the tunnel in June 2000, 36 are not
subdivided in September 2003 (and 50 were not subdivided in June 2001). The other
68 parcels (and 54 in June 2001) are subdivided (without being surveyed yet) because
the tunnel has been built just below a part of these parcels. The subdivision of parcels
avoids that part of parcels that do not intersect with the tunnel are encumbered with
a right for the tunnel. Most of the subdivided parcels are divided into two parts. A
minority of them are divided in three, or even four new parcels.
Of the 104 intersecting parcels, in June 2000 the Ministry of Transport and Public
Works had a right on 12 intersecting parcels which are all ownership rights. In June
2001, the Ministry had a right on 80 intersecting parcels; 44 ownership rights and
36 rights of superficies. Finally in September 2003, the Ministry had a right on 99
intersecting parcels; 47 ownership rights and 52 rights of superficies. All intersecting
parcels affected with a right of superficies are also affected with the legal notification
‘OB’ (underground construction), with the Ministry as subject. In the snapshot of
54
3.2. Subsurface infrastructure objects
June 2000 June 2001 September 2003
1.Number of parcels intersecting with
the projection of the tunnel
104 104 104
2.Number of intersecting parcels that
contains part parcels
0 54 68
3.Number of parcels of (1) that is
encumbered with a right that belongs
to the Ministry of Transport and Public
Works
12 80 99
4.Number of parcels (including part
parcels) that is encumbered with a
right that belongs to the Ministry of
Transport and Public Works
12 91 121
5.Number of rights mentioned in (3) that
is a right of ownership
12 44 47
6.Number of rights mentioned in (3) that
is a right of superficies
0 36 52
6a.Number of parcels affected with an
‘OB’ notification
0 36 52
7.Number of rights mentioned in (4) that
is a right of ownership (registered both
on part parcels and complete parcels)
12 53 60
8.Number of rights mentioned in (4)
that is a right of superficies (all
registered on part parcels)
0 38 61
Table 3.1: Results of the queries on the legal status of the parcels intersecting with the
railway tunnel passing through the ‘Green Heart’ of the Netherlands.
June 2000, none of the intersecting parcels had an ‘OB’ notification.
The results based on the cadastral database of September 2003 show that at that
moment the Ministry still had to obtain a right on five intersecting parcels.
3.2.3 Case study 6: Utility pipelines
A Dutch company owning an important network of utility pipelines (hereafter: the
“Company”) provided us with 3D information on two pipelines in a rural area. We
imported this data into the cadastral DBMS. Therefore it was possible to query the
legal status of the intersecting parcels (see also [135]). The lengths of the pipelines
are approximately 4 and 6.5 kilometres. We queried the legal status of the pipelines
with a copy of the cadastral database of June 2001. The querying was again based on
both spatial and administrative information. The results of the querying are shown
in table 3.2. Registration of these pipelines will change as will be described at the end
of this section. First of all we can conclude that not all parcels crossed by the two
pipelines have the legal notification referring to a right held by the Company. In total
42 parcels are intersecting pipeline 1, of which 27 parcels have a legal notification
and one parcel has a right of superficies for the pipeline, registered as such (and not
as a special case of right of superficies for a pipeline, AKR code ‘OL’). In total 43
parcels are intersecting pipeline 2, of which 38 parcels have a legal notification with
the Company as subject. Another query showed that some of the “non affected”
parcels are in full ownership of the Dutch government. In these cases a public law
55
Chapter 3. Current practice of 3D registration: case studies
permit is sufficient. In most cases this is not registered in the cadastre. Recently
a project was started to register those permits as well. Additionally two privately
owned parcels intersecting with the pipelines do not have a legal notification (see
figure 3.11). A possible explanation can be that the Company has a personal right to
use the land (short lease). The personal right of short lease cannot be registered in
the cadastre (article 17 of Book 3 of the Dutch Civil Code).
Pipeline 1 Pipeline 2
1.Number of parcels intersecting with the projection
of the pipeline
42 43
2.Number of parcels of (1) that is encumbered with a
right of superficies held by the Company
1 0
3.Number of parcels of (1) that is encumbered with a
right of full ownership held by the Company
0 0
4.Number of intersecting parcels (including part
of parcels) that has a legal notification with the
Company as subject
27 38
5.Legal notifications of 4 mainly BZ(D) mainly OL(D)
Table 3.2: Results of the queries on the two pipelines of the Company.
This case study reveals some complexities of current registration.
• The information that can be obtained from the cadastre is fragmented since
only the rights on the intersecting parcels are registered. It is not possible to
query the pipeline itself.
• The location of the pipeline itself is not registered. Even if a right has been
established allowing the Company to build and hold a pipeline on a parcel (e.g.
with the legal notification ‘OL’), the exact location of the pipeline (in 2D and
3D) is not known.
• A drawback of the cadastral registration of pipelines (and other cross-boundary
objects) is that there is redundancy: for every parcel crossed by the pipeline, a
reference is made to the same subject (holder of the pipeline), which may result
in inconsistencies.
• Cadastral registration of infrastructure objects is not uniform. OL(D), BZ(D),
OS (right of superficies), short lease are all used to register the legal status
of pipelines (and even personal right of short lease, which is not registered in
the cadastral registration). It should be noted that OL(D), BZ(D) and OS are
different codes in the cadastral registration and all refer to exactly the same
right (i.e. right of superficies in case of a pipeline), which is obviously confusing.
• Another complication is a ‘BZ’ or ‘OL’ notification instead of a ‘BZD’ or ‘OLD’
notification. The ‘D’, indicates that the right in rem is established on just a
part of the parcel. The deed in which this notification is established contains
information about the location of the pipeline. When a parcel is subdivided the
notary (in the Netherlands a publicly appointed offical charged with drawing
up authentic deeds and legalising documents) is obliged to perform further examination
to the exact location of the pipeline where a ‘BZD’ or ‘OLD’ is used.
When a ‘BZ’ or ‘OL’ is used, the notary will not do this examination which
results in an establishment of the legal notification on all the new parcels that
were created on the location of the original parcel, even on parcels that do not
intersect the pipeline.
56
3.3. Conclusions
(a) Pipeline 1 (b) Pipeline 2
Figure 3.11: Intersecting parcels (privately owned) with no cadastral recording.
The Company had met the same complications (parcels that intersect with a pipeline
without a restriction, but also parcels that do not intersect with a pipeline of the
Company with a restriction). Therefore, in 2000, the Company started an action in
collaboration with the Netherlands’ Kadaster to clean up the registration. In April
2003 they finished one province (Drenthe). For this province, all parcels intersecting
with a pipeline of the Company have been manually examined. For all parcels intersecting
with the Company’s pipelines for which nothing was registered in the cadastral
registration, action was undertaken to improve cadastral registration. For example
when a public law permit was used for a parcel (not registered in the cadastral registration)
in the new situation an ‘OB’ code has been registered for that parcel. With
this notification it is now possible to see that something is located below the intersecting
parcel. The subject of the ‘OB’ code is the Company. It will be a challenge to
keep the registration clear after subdividing parcels. Since the clean up action of this
first province yielded good results, the other provinces will also be cleaned up. A new
query in the future will therefore show other (better, more complete, clean) results.
This case shows the complications for other utility companies that could learn from
the action that was undertaken by the Company.
3.3 Conclusions
In this chapter six case studies concerning cadastral registration of 3D situations were
described. The case studies were carried out in order to get an overview of the actual
needs and requirements for a 3D cadastre.
Cadastral registration of building complexes
The first three cases illustrate the cadastral registration of 3D property situations that
mainly occur in urban areas: multifunctional building complexes. Stratified property
in building complexes is registered by means of all kinds of (limited) rights on the
57
Chapter 3. Current practice of 3D registration: case studies
ground parcel(s): right of superficies, apartment rights, right of easement. Consequently
there is no uniform cadastral registration for stratified property in building
complexes. In the current registration one can only see which persons have a right on
the ground parcel(s), but the 3D extent of rights is not registered (what is the space
to which a right applies?). The (2D and 3D) extent of property units in buildings is
not visible on the cadastral map. Also administrative information on the property
unit itself is not available in the cadastral registration, except in case of apartment
rights (each apartment unit has at least an id). The Public Registers can be consulted
to get insight into the actual 3D situation only in case of apartment rights. However,
the overviews of apartment complexes added to deeds are paper or scanned drawings,
which are not and cannot be integrated with the cadastral geographical data set. In
other cases such as establishing a right of superficies, adding plans to deeds is voluntary.
Consequently consulting the Public Registers does not necessarily yield more
information. Since deeds will soon be available in scanned format, the deeds (and thus
the drawings added to deeds) can be accessed directly from the cadastral database
through a link. This will offer better accessibility of information in 3D situations,
especially in the case of apartment complexes.
Cadastral registration of infrastructure objects
The legal status of infrastructure objects is established by means of limited rights
(mostly right of superficies) and legal notifications established on intersecting parcels.
Information on a 3D physical object itself (with a 2D or 3D description) is not available
because no unique id for infrastructure objects is maintained in the cadastral
registration. Also the limited rights and legal notifications established for the objects
are not related to a spatial description. Therefore we cannot find out where infrastructure
objects are located in the 2D cadastral map and if the objects are located
above, on or below the surface. The current cadastral recording of infrastructure
objects leads to a fragmented pattern of parcels, while the 3D object is divided into
parts in order to let them match with surface parcels. The limited rights and legal
notifications are not linked to infrastructure objects in the real world, but to the holders
of infrastructure objects. The reference to the holder of the infrastructure object
is repeated for every intersecting parcel, which leads to redundancy and to potential
inconsistencies.
The type of rights used to establish the legal status of infrastructure objects is also
not uniform, since several methods were found for establishing the legal status of
infrastructure objects. It is also possible that a holder of an infrastructure object has
a personal right to use the land (short lease) or that the owner of an infrastructure
object is the same as the owner of a parcel (e.g. both governmental bodies). In
these cases no information on the 3D situation can be found at all in the cadastral
registration.
In the case studies described in this chapter, we were able to perform queries such
as ‘which parcels intersect with this infrastructure object’ since the holders of the
infrastructure objects used in the case studies provided us with 3D information on
the infrastructure objects. However, this query is not possible within the current
cadastral registration as the infrastructure objects themselves are not available within
the cadastre.
58
Chapter 4
3D cadastre abroad
Countries throughout the world have experienced an increased pressure on land which
has led to multilevel property. Since individualisation of property started originally
with a subdivision of land using 2D boundaries causing a 2D parcel to be the base
cadastral registration unit, cadastres will have to find solutions to deal with 3D property
situations. Therefore, an indispensable question in this research is how do other
countries deal with 3D situations, concerning legal, technical as well as organisational
aspects and can we learn from other countries?
In this chapter we will have a closer look at 3D cadastral issues in six selected countries
and states: Denmark, Norway, Sweden, Queensland (Australia), British Columbia
(Canada) and Israel (section 4.3 to section 4.8). The reason for selecting these countries
is either that the discussion on 3D cadastral issues has already started in these
countries or that these countries have introduced solutions that solve (part of) the
problem of 3D cadastral registration. To be able to compare the results of these international
studies with the Netherlands, first the Dutch situation is summarised in
section 4.2.
This chapter uses the results of the international workshop on 3D Cadastres that was
organised in Delft, November 2001 as part of this research [142]. The international
discussion that was started during this workshop, was continued at the FIG congress
in April 2002 in Washington and at the FIG Working Weeks in April 2003 in Paris
and in May 2004 in Athens during special sessions on 3D cadastres. The results of
these meetings are completed with results that were obtained by literature study and
by case studies that were carried out in Denmark and Queensland, Australia.
This chapter starts with an introduction on 3D cadastral registrations abroad and
ends with conclusions.
4.1 3D cadastral registrations abroad
Countries throughout the world are confronted with the complexity of cadastral registration
of 3D property situations. Developments to face and solve these problems
59
Chapter 4. 3D cadastre abroad
depend on the national legal system and the state of the art of the cadastral registration
in the specific country.
Third world countries are still in the phase of getting the 2D cadastre up-to-date,
let alone worrying about 3D registration. Additionally the type of cadastral registration
as described in section 2.1, has its influence on how 3D situations are registered.
Countries with a cadastral registration financially supported by the government (unlike
the Netherlands) will be less motivated to take care of changing user requirements
unless the government is an important user itself. However, if a government guarantees
title there is also a strong motivation to take all possible steps to ensure changing
requirements are taken care of. Another factor that seems to influence the discussion
on 3D registration is the basis of the legal system. For example, in the Netherlands
the concept of property rights to real estate is still land (surface) oriented, while
other countries, as will be seen in this chapter, have dissolved the complications of
3D cadastral registration at the juridical level. The legal system in these countries
provided the possibility to establish multilevel ownership no longer related to surface
parcels.
In most countries apartment rights (condominium rights) or strata titles are used
to establish 3D property units. The registration of apartment rights is different in
every country. However, there are no cadastral registrations known in which the
spatial extent of apartment units is registered (in 2D or 3D) as part of the cadastral
geographical database.
Kenya, South Africa, Australia and England (basically all Common Law countries)
use strata titles [191] in the case of 3D situations. Different terms (e.g. sections)
are used in these countries for more or less the same concept. The land registration
contains an analogue or scanned drawing of the situation. This drawing includes an
overview of the complete parcel divided into individually owned units and common
property, augmented by the cross sections of the different buildings (figure 4.1). These
drawings are not incorporated in cadastral registrations.
Other international solutions to establish 3D situations involve the right of superficies
or the use of easements. These rights can be spatially defined in titles or deeds by
means of plans and cross sections, and in some countries also in 2D on the cadastral
map (e.g. Australia, Denmark). However, no cadastral registration has been found
that is able to reflect the third dimension of rights as part of the cadastral geographical
data set.
The disadvantage of the solutions to register 3D property units in current cadastral
registration, is that the 3D information is not integrated in the spatial part of the
cadastral database (only available in titles, survey plans and/or deeds). It is for
example not possible to see the 3D situations of two neighbouring parcels in one
visualisation. Also querying the 3D situation (’who is owner of this stratum’) is not
possible. The 3D drawing in the land registration is just a (2D) visualisation of the
3D situation. Therefore it is not possible to view the 3D situation interactively.
The discussion on 3D registration has started in many countries as can be concluded
from the workshop in Delft, 2001, that attracted eighty participants from twentyseven
countries. Additionally the establishment of 3D property units with separate
ownership apart from the traditional ownership of 2D parcels is already practised in
60
4.1. 3D cadastral registrations abroad
Figure 4.1: Example of drawing in strata title (by courtesy of Michael Barry).
some countries. However the international discussion on 3D cadastres is a very complex
one, since every country has its own specific problems concerning 3D registration
and also its own specific juridical and cadastral framework (dependent on the historical
background) within which they have to face the problem of 3D registration. 3D
cadastral issues of six countries and states were studied: Denmark, Norway, Sweden,
Queensland (Australia), British Columbia (Canada), and Israel. The aim of these
studies was to illustrate the country-specificity of the discussion on 3D cadastres, to
streamline the international discussion on 3D cadastres and to see if this research can
learn from experiences abroad. From the experiences in the described countries it
can be concluded that several countries have been able to solve some aspects of 3D
cadastral registration, although the approaches differ. The main drawback of these
solutions is that they all lack a fundamental approach by taking the juridical, the
cadastral as well as the technical framework into consideration: the solutions that
were found mainly focus on the juridical aspects. Another important conclusion from
the experiences abroad is that it is impossible to talk about the complications of 3D
cadastral registration and it is also hard to talk with people from different countries
about the 3D cadastre, since persons from different countries may use similar terms
with (slightly) different meanings.
The remainder of this chapter will describe the results of the studies on the six countries
and states. It was examined if the specific country has faced the 3D cadastral
problem, and if so, how it has faced the problem. When establishing a 3D cadastral
registration, several phases can be distinguished. 3D cadastral registration starts with
the ability to establish 3D property units within the juridical framework. The next
step is to provide insight into the 3D property units, e.g. by drawings included in the
land registration (which is the Public Register describing interests in land) or, even
better, by integrating the 3D information in the cadastral registration (which links
61
Chapter 4. 3D cadastre abroad
the essential information from documents recorded in the land registration to geometry
of real estate objects). In a final phase, regulations could be laid down, which
define how to prepare and structure the 3D information that is used to maintain 3D
property units in the land registration and/or the cadastral registration.
The different countries have been assessed by examining the following questions:
• How can 3D property units be established within the existing juridical framework?
• What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
• Do 3D property units exist as independent properties in the land registration?
• Do 3D property units exist as independent properties (with 3D geometry) in
the cadastral registration, and if so, how (e.g. with link to 3D geometry or
integrated in cadastral geographical data set)?
• What are the main shortcomings of current registration of 3D property situations?
To be able to compare 3D cadastral registration abroad, the questions will be first
answered for the Dutch situation.
4.2 Evaluating 3D cadastral issues in the Netherlands
How can 3D property units be established within the existing juridical framework?
Property rights in the Netherlands always have to relate to surface parcels. Consequently,
the ownership of real estate is always established on surface parcels. Owners
can be restricted in using the whole parcel column by limited rights or a parcel column
can be divided into different property units by apartment rights (which are also
related to the surface parcel).
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
The discussion in the Netherlands was started since a few 3D property situations were
met that could not be registered unambiguously in current cadastral registration. In
addition, the current registration cannot provide sufficient information in case of 3D
property situations, as can also be concluded from chapter 2 and 3.
Do 3D property units exist as independent properties in the land registration?
3D property units do not exist independently in the land registration, but are always
related to 2D parcels. The only exception is an apartment unit which is known as
an individual property unit in the land registration. However also an apartment unit
must always relate to one or more 2D parcel(s). Information on 3D property units
can only be obtained by querying deeds that establish real rights on surface parcels.
Do 3D property units exist as independent properties in the cadastral registration?
Only in the case of apartment rights, the 3D property units exist as separate real
estate objects in the administrative part of the cadastral registration. Apart from
62
4.3. Denmark
apartment units, the only real estate objects known in the Dutch cadastral registration
are parcels. Since recently cables and pipelines meant for telecommunication can be
registered in the cadastral database. However, these objects still need to be registered
on a surface parcel (the anchor parcel). The outlines of subsurface objects can only
be indicated in the topographic part of the cadastral database by using a specific
classification and visibility code.
What are the main shortcomings of current registration of 3D situations?
The main shortcomings of Dutch cadastral registration in case of 3D property situations
is that the 3D situation is projected on the surface and that the spatial extent
of rights is not available in the cadastral registration. In addition, the real situation
is not properly reflected in the cadastral registration, e.g. by showing (3D) outlines
of physical constructions above and below the surface.
4.3 Denmark
A case study was carried out in Denmark during a working visit in Aalborg (November
2003) in collaboration with the Danish National Survey and Cadastre (Kort & Matrikelstyrelsen)
and the 3D geo-information centre of Aalborg University. During the
case study the issues of land registration and the cadastral registration with respect
to 3D were studied. Two types of 3D property situations were further examined:
apartment units and infrastructure objects crossing parcel boundaries. These case
studies were examined in the same way as the case studies in the Netherlands. The
case studies in Denmark are described in detail in [196] and [203].
The main findings of the study in Denmark are that two main aspects influence the
discussion on 3D cadastral registration in this country:
• the organisation of real estate registration in Denmark;
• the lack of information on rights and subjects in the cadastral registration.
Organisation of real property registration in Denmark
In Denmark there are four basic registrations of real properties falling under different
authorities:
• Cadastral registration, maintained by the National Survey and Cadastre (KMS)
which is an agency within the Ministry of Environment.
• Land registration (Land Book), which is a registration of property rights in real
estate under the responsibility of the Ministry of Justice.
• Building and dwelling registration (BDR), maintained by municipalities (275 in
total). The BDR contains information on three levels of registration:
– property (related to buildings) which is the same property as registered in
the cadastral registration;
– building;
– units.
• Valuation registration, also maintained by municipalities, to record valuation on
single properties, which may themselves be units in the building and dwelling
registration. The valuation registration assists authorities in calculating and
63
Chapter 4. 3D cadastre abroad
collecting property taxes. The Ministry of Economic and Business Affairs is
responsible for both the building and dwelling registration and the valuation
registration.
All these four registrations contain some information on real property objects. The
entity ‘property’ in the land registration, the cadastral registration and the valuation
registration refers to the same object: one or a collection of parcel(s), which
is defined (in the cadastral registration) as one real property. However, the entity
‘property’ is separately maintained (different instances in different databases), while
inter-relationships between the different databases are not digitally maintained. Property
in the building and dwelling registration also refers to the ‘property’ entities
in the other three registrations. However, this property is only registered when it is
related to a building. The valuation registration divides the properties further into
smaller property units. These property units can be:
• self-owned apartment units also registered as legal apartment units in the land
registration;
• rented apartment units;
• apartment units in apartment complexes owned by a housing association.
In conclusion much information on real property is registered in Denmark. However,
since registration of real property in Denmark is divided among different governmental
bodies and since the definition of real property may slightly differ in the different
registrations, the organisation of information on real property is complex. Consequently
information on real property is not easily accessible, even in 2D situations.
Information on the factual situation, both in 2D and 3D, would be better accessible
if the different registrations were linked.
Information available in the cadastral registration
The cadastre in Denmark consists of four elements:
• a registration of real properties (ejendom) and land parcels;
• cadastral map;
• measurement sheets related to boundaries;
• registration of control points used for cadastral surveys.
However, the Danish cadastre does not contain any information on 3D situations:
• information on different types of land use on one parcel cannot be maintained:
only the main use of a parcel is maintained;
• information on rights and subjects of rights on parcels is not maintained, with
the exception of public restrictions (protected forest areas, dune protection
zones, coast protection zones, polluted land parcels);
• the existence of an apartment cannot be known from the cadastral registration.
4.3.1 Evaluating 3D cadastral issues in Denmark
How can 3D property units be established within the existing juridical framework?
In Denmark, real property is always related to surface parcels. Consequently, the
64
4.4. Norway
ownership of real estate is always established on surface parcels. Owners can be
restricted in using the whole parcel column by easements or a parcel column can be
divided into different property units by apartment rights.
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
In Denmark real estate is defined by surface parcels. Since this concept is a limiting
factor for establishing and providing insight into the juridical situation in the case
of 3D property situations, the question arose as to how to establish and register 3D
property units.
Do 3D property units exist as independent properties in the land registration?
Limited rights and apartment rights are only known in the land registration. The legal
documents that establish the title can be accompanied with drawings of the situation,
but this is only obliged in case of direct (individually owned) apartment units. In this
case a drawing with an overview of the floor(s) is included in the document in which
the apartment right is established. The apartment units in apartment complexes that
are owned by one housing association cannot be known from the land registration.
Do 3D property units exist as independent properties in the cadastral registration?
Cadastral registration only contains a parcel register and a real property register.
Rights and subjects to rights cannot be obtained from the cadastre. Therefore, even
the current registration does not provide information on the establishment of more
than one right (or restriction) on one parcel. The land registration always has to be
queried to determine what rights are established on a parcel. In addition, apartment
complexes are not known in the cadastre.
What are the main shortcomings of current registration of 3D situations?
In the current registrations of real property, information on the factual situation is
not readily accessible, since information on real estate is maintained in four different
registrations. Different registrations need to be queried to get insight into the juridical
situation. In addition registrations of real rights and real property is separated:
real rights are only recorded in the land registration while real properties are only
recorded in the cadastral registration. Therefore, a first step is to bring the land
registration and the cadastral registration together, which will make it simpler to
determine what rights are established on a parcel and which persons have a right to a
parcel. Reorganising registration of real property, which is the first step in improving
the accessibility of information (both in 2D and 3D), requires decisions at the political
level.
A Danish Geo-Information Infrastructure will support setting up an integrated data
model of property registration at the conceptual level which makes it possible that
the different registrations can communicate and that representations of the same real
property can be interrelated with each other (see also section 5.3).
4.4 Norway
Norway has a solid subsurface in a geological sense, in contrast to the subsurface
of the Netherlands which consists only of sediments. In Norway tunnels for roads,
65
Chapter 4. 3D cadastre abroad
trains, and water drilled in the subsurface do not influence the economic value of the
surface property. Therefore these subsurface objects are already common practice in
Norway without subdivision and formal registration in the cadastre and in the Land
Book. The owners of surface properties are only compensated financially if the surface
property has been damaged in any way.
At the beginning of the nineties, providing the possibility for 3D property was listed as
an important motivation for the improvement of cadastral legislation in Norway, since
the current juridical framework does not provide the establishment of 3D property
units with separated ownership on one surface parcel. It was expected that investors
would be more willing to invest money in registered ownership, than in all kinds of
limited rights that are currently used to establish stratified property.
A committee was established in 1995 which concluded that three types of 3D property
should be facilitated:
• volumes below the surface of the earth, such as underground parkings, shopping
areas, tunnels;
• buildings and other constructions erected on pillars or by other means realised
above the original surface of the earth, mostly above roads or railways;
• constructions on pillars at sea or fresh water.
The findings of the committee led to a proposal for a law on ‘construction properties’.
It is assumed that this law will be enacted in 2006 [133]. In this law the surface
property is still the basic property object including all land and permanently fixed
constructions except what is subdivided from the surface property. It is expected that
the chosen legal instruments will have effect on prices. A 3D construction property
has the following characteristics:
• A 3D property construction can only be established by subdivision of the surface
property and may cross several parcels.
• It is up to the parties involved to decide whether to use the 3D property construction
solution or to use other possible solutions such as servitudes or to
remain unregistered in the cadastre.
• The parties involved enjoy much freedom and carry the risk of making bad arrangements.
It is expected that the new law will accept construction or building
drawings as satisfactorily for registration, without additional surveying. Any detailed
surveying of the 3D property beyond that level of accuracy would be the
choice and responsibility of the parties involved.
• Since a new parcel can only be established when it follows the planning and
building acts, a subdivision of a parcel in general is not permitted unless it is
likely that the subsequent construction on the parcel is approved. This means
that there is a direct link between the new parcel and the building to be created.
3D construction properties that will remain unused are prevented by this regulation.
In addition the potential for speculation in land and in space is reduced.
A 3D construction property will be approved when it is needed to support a
particular and approved construction. Therefore, the law on 3D construction
property inhibits the free construction of 3D property units.
• A 3D construction property will cease to exist should the actual construction
to which it alludes collapse and not be rebuilt within three years.
66
4.4. Norway
• A 3D construction property can only be established when the surface can still be
used for a relevant purpose as part of the property from which the construction
property will be subdivided. Therefore a building standing directly on the
surface cannot be established as a 3D construction property.
• A 3D construction property cannot be established for parts of buildings. It is
only possible in the case of separate buildings in which the 3D properties have
no relationship to the neighbouring properties beyond the usual relationship
between neighbouring surface properties. In the other cases, apartment rights
(eierseksjon) must be used, for example in the case where new units are part of
a common owned building.
At this moment no specifications for surveying or solutions for the cadastre are part
of the proposal. Conditions in this area would only delay the introduction of the
law that meets the demand of the market. For the short-term future it is expected
that the cadastre will accept rather simple solutions such as visualising the projection
of the 3D property on the surface only, while referring to more detailed information
contained in the deeds.
Awaiting the new law, the municipalities (which are the cadastral authorities at local
level) have for many years established properties as volumes above and below the
surface, subdividing the volume from the surface property. They have extended the
existing cadastral law with municipal regulations to be able to divide properties in
3D. The proposed regulations are based on existing practices. An example of this
practice is the municipality of Oslo. This city introduced a practical approach to
register 3D properties as real property both in the cadastral registration and the title
register [217]. These properties have the same rights and restrictions just as surface
parcels. The existing law does not provide for these 3D real properties, and hence
the Oslo method has mostly been limited to underground facilities. In the case of
2D subdivision, the new parcel boundaries are surveyed and marked. In the 3D case,
it is impossible to survey before the actual construction has been built. Therefore,
the plans and drawings from the applicant are sufficient. Usually, this drawing is also
accepted as the final document against which a survey certificate is issued without any
surveying. On the survey certificate each corner is given by coordinates and heights
both at floor and ceiling level. The registration number and the survey identify the
parcel as a volume, but in the various registers the parcels size is given in square
meters and not in cubic metres. This is due to the Land Subdivision Act that has
no provision for 3D parcels. A 3D parcel is identified by a unique parcel number. 3D
parcels can be recognised because the parcel number ends with ‘300’. The numbering
of the 3D parcels is done in such a way that the relationships with the surface parcel
are preserved.
4.4.1 Evaluating 3D cadastral issues in Norway
How can 3D property units be established within the existing juridical framework?
The new law will enable to establish 3D construction properties that may cross several
surface parcel boundaries. Although such construction properties are not yet formally
allowed, municipalities and the land registration already accept it, as was shown by
the Oslo method.
67
Chapter 4. 3D cadastre abroad
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
Currently multilevel ownership can be established by apartment rights or just by
virtue of the owner’s legal right to use his property (unobstructed by legislation). In
the latter case, the legal status is not established and not registered, which is always
a risk, especially in case of constructions owned by private persons. Therefore it
is required to ensure the legal status of real property in the cadastre. Apartment
rights must always relate to a surface parcel on which the related building is erected,
while the 3D construction properties are not necessarily related to the surface parcels.
The 3D construction property enables 3D ownership for which apartment rights are
not an appropriate solution. Examples include independent volumes below the surface
crossing several parcels (underground garages, shopping areas, tunnels etc.), buildings
and other constructions erected on pillars or by other means realised above the original
surface frequently built above roads and railways.
Do 3D property units exist as independent properties in the land registration?
The 3D property units that will be established will be known in the land registration.
However there are no requirements for surveying and mapping the 3D property unit.
The 3D geometry of the property unit may therefore not be known (in detail) in the
land registration.
Do 3D property units exist as independent properties in the cadastral registration?
The 3D property units exist in the administrative part of the cadastral registration.
The footprint of 3D construction properties can be drawn in the cadastral map.
However, the 3D geometry of the 3D property unit will not be maintained.
What are the main shortcomings of current registration of 3D situations?
The first shortcoming in Norway is that construction property has to relate to real
constructions. Furthermore, the cadastral registration can be improved by firstly setting
up regulations to survey 3D property units and secondly by solving the technical
aspects of 3D cadastral registration which is “how to incorporate the 3D information
in the cadastral map”.
4.5 Sweden
Before January 2004 in Sweden the division of ownership was not possible in the third
dimension. This has led to remarkable legal structures. For example the space for
the Stockholm underground is granted through an easement. The dominant parcel to
which the easements are linked is a small property formed for a lift shaft going down
to the underground railway [114].
The need for 3D property has been influenced by the fact that apartment units in an
apartment complex can only be owned totally, e.g. by one housing association. Each
member in such association has a flat connected with his apartment and when his share
is sold, the right to the flat follows with the purchase. So, each apartment owner may
sell his net share of the co-operative association (bostadsr¨att). Both the association
and the member may take a loan secured as mortgage. However, the association loan
can be secured in the land registration and then be related to the whole property,
68
4.5. Sweden
while the member loan is secured in a register kept by the association and is then
related to the membership. Difficulties can arise when two types of security are in
the same property and then also when different types of use are combined in one
building (e.g. apartment units and offices), since this requires different right holders
as well as the possibility of mortgaging the parts separately. One of the problems
is the non-transparency of the related information, since the property and mortgage
information is maintained in different registers. The separation of the right holders
would make the apartment units as well as the offices more attractive on the real
estate market (the office property will no longer constrain the housing property and
vice versa). Therefore, for financial and administrative reasons, there is a need to
divide properties in such a way that the facilities or parts of them can be mortgaged
separately and owned as separate properties.
In [91] and [114] a new law is described that facilitates 3D property units. The law
came into force in January 2004 [208]. The law was prepared by a committee, appointed
by the Swedish government in 1994 to investigate the potentials for solving
the problems of different types of use in one building. The main conclusion of the
committee was that the most appropriate solution would be the facility to establish
3D property similar to 2D property. 3D properties can then be mortgaged and information
on the 3D properties will be accessible through the real property register. The
main objection to the proposal was that the fundamental property concept should not
be radically altered from 2D since the number of 3D properties will probably be small.
Therefore the new 3D properties had to fit within the structure of 2D properties. The
following criteria have been set up for 3D properties (3D-fastighet, 3D-utrymme):
• Title must be in perpetuity.
• Title shall, as far as possible, be independent of the (land) property within
whose parcel column it is located and shall be separately transferable, without
any simultaneous transfer of the surface land.
• A 3D property must be an object for credit; public authorities, credit providers
and other outsiders shall be permitted to obtain information on the rights
established on the property.
• The new rules should as far as possible be in accordance with the existing
principles of real property law.
• The ultimate aim of 3D property formation is to create better opportunities for
3D property use and also to permit such properties to serve as security for the
grant of credits.
Formation of 3D property is only permitted if it accommodates, or intends to accommodate,
a building or other construction and if it is assured of the rights necessary
to its appropriate use (e.g. rights to joint facilities, easements). To avoid empty, airspace
property units, the 3D property has to relate to a real construction. When it
relates to a construction to be built, the cadastral authority can set a deadline for
the completion of the construction. Unlike in Norway a construction itself may be
divided into different property units with this new law. This is also the main type
of ownership situation that the new law aims to facilitate. However, a 3D property
for housing purposes must contain at least five apartment units, which means that
the new legislation does not afford scope for the creation of individual apartment
ownership. The 3D property units may intersect boundaries of surface parcels.
69
Chapter 4. 3D cadastre abroad
The 3D property is registered in the real property register and therefore accessible by
the public. The new law takes care only of the legal issues and then in the same way as
2D properties. The projection of the 3D property units is indicated on the cadastral
map. Details describing the boundaries, like marks, are described in scanned files in
the cadastral database. Therefore these files can be checked (separately from each
other) in computers.
4.5.1 Evaluating 3D cadastral issues in Sweden
How can 3D property units be established within the existing juridical framework?
The new law enables the establishment of 3D property units that may cross several
surface parcel boundaries.
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
The main problem of the existing juridical system is that parts of multifunctional
building complexes cannot be mortgaged independently, which may discourage investors
from investing in multi-purpose building complexes. In normal cases this is
no problem as the situation is instead handled through tenant-ownership. However, in
cases with mixed land use problems can arise. Since the new law prescribes that a 3D
property unit should contain at least five individual apartment units, the mortgage of
individual apartment owners can still not be registered in the cadastral registration.
Do 3D property units exist as independent properties in the land registration?
The 3D property units are registered in the land registration. However there are no
requirements for surveying and mapping the 3D property units. The 3D geometry of
the property unit may therefore not be known (in detail) in the land registration.
Do 3D property units exist as independent properties in the cadastral registration?
Although 3D property units are registered as independent property units in the administrative
part of the cadastral registration, it is not yet clear how 3D property
units will be documented as part of the cadastral geographical data set. Until now, it
was not the goal of the Swedish legislator to regulate the way 3D property units are
incorporated in the cadastral database. At this moment the footprint of 3D property
units can be drawn on the cadastral map. This means that 3D property units are
registered in the same way as 2D property units.
What are the main shortcomings of current registration of 3D situations?
As in Norway, the 3D property units have to relate to built constructions. Consequently,
the 3D property units do not cover all 3D situations. Furthermore cadastral
registration can be improved by setting up regulations to survey the 3D property
units and by solving the technical aspects of 3D cadastral registration: for example
how to incorporate the 3D information as part of the cadastral geographical data set.
4.6 Queensland, Australia
In Queensland, Australia, the 3D registration has also (partly) been solved.
70
4.6. Queensland, Australia
Since 1997, it has been possible to create parcels defined with 3D geometries. The
juridical framework of Queensland, which originated from Common Law, provided
the possibility of establishing 3D property units (which can be both freehold and
leasehold estates). However, the cadastre only includes the footprint of these 3D
parcels on the cadastral map, and therefore the cadastral issue of 3D property units
is not solved in Queensland.
The cadastral registration in Queensland will be described more extensively compared
with the other states and countries. The cadastral registration in Queensland is used
to illustrate in more detail the possibilities and constraints of a 3D cadastre in the case
of a land registration that is already able to define parcels with a bounded volume.
In section 4.6.1 the different types of parcels that can be established in Queensland
are described. In section 4.6.2 a case study from practise will be introduced to show
possibilities and constraints of current cadastral registration of a 3D situation in
Queensland. Improvements of the cadastral recording of this case will be showed in
chapter 12, where the prototypes developed as part of this research are applied to this
case study. Section 4.6.3 evaluates the 3D cadastral issues in Queensland.
3D cadastral issues in Queensland have been studied in collaboration with Queensland
Government, Department of Natural Resources, Mines and Energy (NRME).
4.6.1 Restricted, building and volumetric parcels
According to the Land Title Act of Queensland [174], a standard parcel (defined in
2D, but implying the 3D column) is a lot (or a collection of lots) which are unlimited
in height and depth. Apart from these ‘unrestricted’ parcels, four types of parcels
with a 3D component are distinguished:
• building parcels, which are parcels that are generally defined by floors, walls
and ceilings;
• restricted parcels, which are parcels restricted in height or depth by a defined
distance above or below the surface or by a defined plane (restricted easements
can also be restricted in height and depth). The boundaries of the restricted
parcels must coincide with the boundaries of the surface parcel;
• volumetric parcels, which are parcels that are fully bounded by surfaces and are
therefore independent of the 2D boundaries of the surface parcels;
• remainder parcels, which are parcels that remain after a volumetric parcel or
building parcel have been subdivided out of it.
The ‘in strata’ parcels that were used before 1997 (and are not applied anymore)
included both the volumetric parcels and the restricted parcels.
A standard parcel may be subdivided using three different formats of survey plans:
standard, building or volumetric format. In the document “Registrar of titles, directions
for the preparation of plans” [175] the conditions for the different plans are
exactly described.
A standard format plan defines land using a horizontal plane and references to marks
on the ground. A standard format plan is used for standard parcels, restricted parcels
71
Chapter 4. 3D cadastre abroad
and restricted easements. In case of standard parcels, the drawn parcel refers to the
whole parcel column. Restricted parcels (which are restricted in height or depth) are
also indicated on standard format plans by values relative to the surface (defining
horizontal planes), or by a defined plane. For restricted easements, the vertical restriction
shall be detailed on the plan with reference to the Australian Height Datum
together with details of the Permanent Mark on which this is based (page 20 of [175]).
A building format plan defines land using the structural elements of a building, including
floors, walls and ceilings (building parcels). A building format plan is used in
situations similar to apartment units in the Netherlands. A parcel is subdivided into
a minimum of two building units (lots) and a common property that is shared. The
common property is linked to the units and not to the persons owning the units. Lot
numbers in buildings shall be numeric and may be made up in the form FL, TFL or
TL, where T is a tower number, F is a floor number and L is the lot number. The
building format plan should include a main plan with the location of each building or
structure with respect to the outer boundaries of the base parcel (i.e. the projection of
the outermost walls of the building). This plan should include any sub-surface basements
and a diagram of every level of the building showing the parcels and common
property on that level (page 32 of [175]). The maximum amount of encroachment
(the intersection of this building with any other parcel) permitted is limited to half
the width of the wall (page 36 of [175]). Consequently “the boundary of a building
format lot may not be projected beyond the boundaries of the base parcel”.
A volumetric format plan defines land using 3D points to identify the position, shape
and dimensions of each bounding surface and is used to reflect volumetric parcels.
A volumetric parcel is a parcel, which is fully limited by bounding surfaces (which
may be other than vertical or horizontal) and are above, below or partly above and
partly below the surface of the ground (compare with restricted parcels and notice
the difference). Volumetric parcels are possible in Queensland under the Land Title
Act since 1997. The use and purpose of volumetric parcels (not per se related to
constructions e.g. for a panorama) are determined by the local government and other
legislation. One volumetric parcel can intersect several surface parcels. All lines
on a volumetric format plan are straight and all surfaces are flat unless explicitly
stated otherwise, hence any surface which is mathematically definable (so that an
intersection can be calculated) can be registered. The height used to define volumetric
parcels cannot refer to above or below a depth from the surface (the height cannot be
defined as relative height or depth) since “this is subject to change and not capable
of mathematical definition” [175]. The corners of volumetric parcels should refer to
existing structures or marks as much as possible. The vertices of the corners should
be given in bearings and distances of existing cadastral corners and the height levels
in the Australian Height Datum. Each volume shall be given an area, which is the
area of its footprint, and a volume in cubic meters. The plan should show a 3D
representation of the parcel. The 3D descriptions are maintained in titles in the land
registration while a footprint of the volumetric parcel is shown on the cadastral map.
The cadastral geographic data set of Queensland has a “base layer”, which is a complete
non-overlapping coverage, and consists of parcels, road, rail, watercourse and
intersection parcels. An intersection parcel is part of a roadway (the intersection of
two roads). Volumetric parcels are not part of the non-overlapping coverage, but the
72
4.6. Queensland, Australia
footprints of these 3D parcels are drawn on the cadastral base layer and therefore they
are overlapping with the base parcels. Also easements, having their own geometry
(and survey plans), are drawn on the base layer and may therefore intersect several
parcels. Initially easements are defined on a single base parcel, but the base parcel
may get subdivided, leaving the easement whole. Building parcels are not drawn on
the cadastral map.
4.6.2 A case study in Queensland
Since volumetric and restricted parcels are advanced examples of 3D property units,
a case study from practice will be used to illustrate the establishment of these parcels:
the establishment of 3D property units for the Gabba Cricket stadium in Brisbane.
This stadium overlaps two streets: Vulture Street in the north and Stanley Street in
the south (see figure 4.2).
Figure 4.2: Overview of Gabba Stadium overhanging Stanley Street in the south and
Vulture Street in the north, Brisbane, Australia.
Three 3D properties have been established: for the intersection with Vulture Street a
stratum with parcel identifier 100 (established before 1997) and a volumetric parcel
with identifier 101 and for the intersection with Stanley Street a volumetric parcel with
identifier 103. The volumetric parcels were established after 1997. All three parcels
are leasehold estates. This means that the holder of the real estate has the right of
use and exclusive possession of the property for a specified time, which is comparable
to the right of long lease (erfpacht) in the Netherlands. However, it should be noted
that most volumetric parcels are related to freehold estates.
The titles establishing the 3D parcels contain very detailed 3D information imposed
by the regulations: cross sections are added in case of the strata title and 3D diagrams
73
Chapter 4. 3D cadastre abroad
are added in the titles for the volumetric parcels (see figure 4.3 for parcels 101 and
103). All coordinates that are needed to demarcate the 3D property are present in
the titles in bearings and distances. The coordinates are only determined when the
information is entered into the cadastral database. The height of all coordinates is
defined in the Australian Height Datum.
(a) 3D diagram of parcel 101 (b) 3D diagram of parcel 103
Figure 4.3: Examples of 3D diagrams added to volumetric titles.
The footprints of the 3D properties are part of the cadastral geographical data set.
Figure 4.4 (a) shows the cadastral map with the footprints of the 3D parcels and
figure 4.4 (b) shows the cadastral base map without the footprints of parcels 100, 101
and 103 (and without the geometry of easements). Figure 4.4 shows that 3D parcels
are not part of the base parcel map and that volumetric parcels (and traditional strata
parcels) exist separately from the base map and may therefore intersect parcels of the
base parcel map. For example the 3D stratum parcel 100 crosses two parcels of the
base map.
This example shows the very good potential for establishing 3D properties in the
current registration in Queensland. How 3D information, which is part of survey
plans and (volumetric) titles, could be used further to improve cadastral registration,
will be explained in chapter 12, where the concepts developed as part of this thesis
are applied to this case study in a prototype.
4.6.3 Evaluating 3D cadastral issues in Queensland
How can 3D property units be established within the existing juridical framework?
3D parcels (either bounded or unbounded) can be established. The way Queensland
has solved the 3D property problem, shows that the law introduced in 1997 made it
possible to establish 3D property units unrelated to the surface.
74
4.6. Queensland, Australia
(a) Cadastral map with footprint of 3D
parcels (100, 101 and 103) (and easements)
(b) Cadastral map without footprints of
parcels 100, 101 and 103 (and without
easements)
Figure 4.4: Cadastral map on the location of the Gabba stadium, Brisbane, Australia.
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
The existence of overlapping and interlocking constructions called for the ability to
establish multilevel ownership. The legal system was extended to allow the establishment
of 3D property units and the cadastral registration followed the legal practise.
Do 3D property units exist as independent properties in the land registration?
The 3D property units (bounded and unbounded parcels) are known in the land
registration. The ‘Registrar of Titles directions for the preparation of plans’ dictates
how to incorporate 3D information in survey plans. In case of restricted parcels, the
projected parcels with values relative to the surface are sufficient, while volumetric
survey plans require 3D diagrams, including values in the Australian Height Datum.
It should be noted that the survey plans are (scanned) drawings. It is therefore not
possible to view the volumetric parcels in an interactive 3D environment.
Do 3D property units exist as independent properties in the cadastral registration?
3D property units exist in the administrative part of cadastral registration. The
footprint of the volumetric property is drawn on the cadastral map, and is therefore
known in the cadastral registration. However, the 3D geometry is not available in
the cadastral geographical data set, and therefore it is not possible to query the 3D
situation from the cadastre, nor is it possible to see if two volumetric parcels overlap.
What are the main shortcomings of current registration of 3D situations?
Although, the titles contain detailed 3D information, the registration of the 3D properties
meet some complications due to a number of reasons:
• Since the 3D information is laid down on paper (or scanned) drawings (which
are 2D visualisations), the 3D information cannot be interactively viewed. This
is a weak point because the ability to do so may be very helpful in case of
complex volumetric parcels to interpret the situation correctly (e.g. parcel 103).
• The 3D properties are only described by coordinates and edges on drawings,
75
Chapter 4. 3D cadastre abroad
i.e. no 3D primitive is used. Therefore it is not possible to check if a valid 3D
property has been established (is the 3D property closed, are the faces planar?).
• The 3D information is not integrated with the cadastral map or with other 3D
information, e.g. two or more neighbouring parcels cannot be visualised in one
view in 3D and it is also not possible to check how volumetric parcels spatially
interact in 3D (overlap, touch etc.).
In Queensland, the basic improvement for 3D registration would therefore be to incorporate
the information on 3D property units, which is already very well described
in survey plans in the land registration, into the cadastral registration.
4.7 British Columbia, Canada
In British Columbia, Canada, an owner of a parcel has the right to subdivide his land
into air-space parcels according to section 139 of the Land Title Act 1996 [16]. The
air-space parcel may continue, or exist completely below the surface. Only the ‘fee
simple estate’, which consists of all ownership rights that can be attached to a certain
parcel (complete ownership), can be subdivided and not a leasehold estate (which
is an estate created between a landlord and a tenant under a contract, comparable
with the right of long lease in the Netherlands). For every subdivision, even in 2D,
a subdivision plan has to be made. For air-space parcels a special part of the Land
Title Act applies.
Every new 3D parcel (air-space parcel) has to be created within an existing conventional
parcel. The grant of an air-space parcel does not transfer any easements or
restrictive covenant that limits the use of the grantor’s land. The title to the ground
below and to the air-space above and below the granted air-space parcel, as well as
the easements and covenants remains the possession of the grantor. This means that
an easement has to be created separately if access to the newly created air-parcel is
desired or if the existing easements have to apply to the new air-space parcel as well.
The main requirement for creation of an air-space parcel is the provision of an airspace
plan on the title [17]. This plan must consist of a 3D drawing to show that the
boundaries lie within the boundaries of a single parcel (figure 4.5). This raises the
question what will happen when the surface parcel is subdivided in the future. The
plan must further indicate if it is a subdivision of the whole parcel shown on the plan
or just a part thereof. A geodetic elevation (in the National Height Datum) is needed
which must be noted on at least one of the corners of the parcel on the ground and
for every corner or angle of the subdivided air-space parcel. Air-space parcels can be
used for stratified property, but also for the purpose of later granting a right of view
to benefit a parcel next to a planned construction [61].
For a further division of the air-space parcel, the rules of the Condominium Act
applies. This divides the air-space into strata lots. The Condominium Act states that
a building or land may be subdivided into strata lots by the provision of a building
strata plan. The strata lots are coupled with an interest as a tenant in the remaining
common areas. It is possible to establish either freehold or leasehold condominiums.
The new strata lots have the same status as any land that is registered at the Land
76
4.7. British Columbia, Canada
(a) Plan of air-space parcel (b) Cross section
Figure 4.5: Drawing in title of air-space parcel taken from [61].
Title Office. The strata plan must contain a diagram of the proposed project, showing
the boundaries of the land included in the strata plan and the location of the buildings.
In British Columbia the survey plans are registered in the Crown Land Registry and
in the Land Titles Office. The Crown Land Registry lists all Crown land converted to
private ownership, all private land turned over to the government, all existing Crown
land tenures, leases, licences, or other time-limited holdings and includes maps that
record the location of Crown land parcels. In British Columbia the Crown owns ninety
percent of the land. The remaining ten percent is privately owned [61].
In the Land Title System, all titles are given a parcel identifier number, which is
part of the legal description and should be included in all land titles documents. A
registered title for a ‘fee simple estate’ can either be a conventional parcel or an airspace
parcel, which are both considered as land under the Land Title Act. It can also
be a part of the building, i.e. a strata lot according to the Condominium Act.
There is no general map which covers all existing parcels. There is only a plan that
defines the specific area. Therefore information on the 3D (and 2D) properties can
only be found in the land registration in the title documents. One has to look in the
survey plans to get insight into the juridical situations.
4.7.1 Evaluating 3D cadastral issues in British Columbia
How can 3D property units be established within the existing juridical framework?
3D property units with separate ownership within one parcel are allowed since it is
possible to establish air-space parcels, apart from conventional parcels and apart from
lots that are the results of subdivision under the Condominium Act. Air-space parcels
may not intersect surface parcel boundaries.
77
Chapter 4. 3D cadastre abroad
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
As in the case of Queensland, the existence of overlapping and interlocking constructions
called for the ability to establish multilevel ownership. Also in British Columbia
the legal system was extended to establish 3D property units. The cadastral and land
registration followed the legal practise.
Do 3D property units exist as independent properties in the land registration?
Air-space parcels are known as individual property units in the land registration. The
3D property situations are indicated with 3D diagrams in survey plans and can be
known from the documents and records in the land registration.
Do 3D property units exist as independent properties in the cadastral registration?
In British Columbia, the cadastral registration is actually the land registration which
includes a title registration. The survey plans are maintained as part of the titles.
However there is no cadastral map in British Columbia. In 2D, neighbouring parcels
cannot be integrated in one view, by which it is hard to get an overview of a certain
situation and to see if two parcels overlap. Consequently, air-space parcels can also
not be shown in one integrated view with other (air-space) parcels.
What are the main shortcomings of current registration of 3D situations?
Since 3D survey plans are prepared and available in a (more or less) similar way
as in Queensland, basically the same shortcomings apply. In addition, 3D cadastral
registration in British Columbia would be improved by two major steps. The first
step is to make 2D survey plans digital and to create one parcel map out of the plans,
with no overlaps and gaps in 2D. The second step is to make 3D survey plans digital
(to be able to view the 3D property units interactively and to check the 3D property
units) and to include the 3D information that is in detail available in survey plans
in the digital cadastral data set. This would make it possible to query the air-space
parcels in a combined view with the cadastral geographical data set.
4.8 Israel
Israel also faces high pressure on the use of land because some parts of it are intensively
used. This has promoted developments of a 3D cadastre. At this moment, in Israel
the 3D cadastral issue is only a topic of research. Since the research on 3D cadastre
also started in Israel, this country was included in the study on 3D cadastre abroad.
The Survey of Israel has started a research and development project into the registration
of the rights of land in three dimensions. This plan has an interdisciplinary
approach in which legal, technical, as well as organisational aspects are considered
[57, 58].
In the city transportation centre of Modi’in a large project has started including
buildings, roads, tunnels, a railway station, bus station and more. This project has
been used to examine the current land registration in Israel, and is now used to study
the possibilities for 3D registration [63]. In [64] a case study is described in which 3D
volumes where modelled for an underground parking in order to register rights for
the parking. A precise 3D CAD model was constructed and intersected with surface
78
4.8. Israel
parcels leading to a spatial division of the 3D object. The aim of the model was to
prepare a plan for registration of rights in 3D.
At the Geodetic Engineering Division of the Technion-Israel Institute of Technology a
research is carried out in order to find a cadastral solution for utilising space above and
below the surface and for defining the characteristics of a future 3D cadastre that will
replace the existing 2D geographical surface cadastre in Israel. In the research many
alternatives for a 3D cadastre have been defined based on different classifications.
The defined alternatives will be studied into more detail in future research. The
classifications do not yet take into account considerations for conceptual modelling of
a 3D cadastre. The classifications that are distinguished in the research are based on
different criteria and include the following topics (the terms used for these alternatives
are based on [9]):
• multilayer information management models;
• alternatives for registering multilevel properties by using existing tools;
• 3D cadastral mapping;
• conceptual definition of the spatial parcel boundary;
• land settlement for 3D cadastre;
• restriction of current parcel column;
• 3D cadastral database: hybrid or integrated system;
• measuring of needed 3D data.
A list of criteria has been set-up, such as costs, feasibility, flexibility, continuity, and
quality in order to assess the different alternatives. The design of a conceptual model
for a 3D cadastre will be the next step after the best alternative has been chosen.
4.8.1 Evaluating 3D cadastral issues in Israel
How can 3D property units be established within the existing juridical framework?
At this moment 3D property units can be established in Israel in the same way as in
the Netherlands. By establishing limited real rights on surface parcels, subdivision of
the parcel column is possible.
Do 3D property units exist as independent properties in the land registration or the
cadastral registration?
Also in Israel the 3D property units do not exist independently in the land registration
or in the cadastral registration. Information on 3D property situations can be
obtained when looking at drawings that are included in legal documents in which real
rights are established.
What was the main trigger to establish 3D property units or to start the discussion
on how to establish 3D property units?
Intensive use of some parts of Israel has led to overlapping and interlocking constructions.
Since the right of ownership in Israel is not explicitly bounded in the third
dimension and since this concept of ownership cannot easily be changed within the
juridical framework, the question arose as to how to maintain and provide insight into
the legal status of 3D property situations.
79
Chapter 4. 3D cadastre abroad
What are the main shortcomings of current registration of 3D situations?
Since the land registration and the cadastral registration maintain information on
3D property situations comparable to the Dutch registration, the main complications
of current situations in Israel are similar as the complications that are met in the
Netherlands (see chapter 2 and chapter 3).
4.9 Conclusions
Many countries have met the problems of registering 3D situations within current
cadastral registrations which were originally developed to register the legal status of
2D parcels. The developments on 3D cadastral registration depend on the national
legal system, on the state of the art of the cadastral registration as well as on the type
of cadastral registration. For example, the main objective of many (less developed)
countries is to get their 2D cadastral registration up-to-date, which means they do not
bother (yet) with 3D registration. Apartment rights or strata titles, right of superficies
and servitudes are used world-wide to establish stratified property, although no
cadastral registration exists that reflects the 3D characteristics of these 3D property
units as part of the cadastral geographical data set. All these rights and limited rights
are still related to surface parcels.
This chapter presented the 3D cadastral issues in six countries and states: Denmark,
Norway, Sweden, Queensland (Australia), British Columbia (Canada) and Israel.
From these studies it can be concluded that no complete solution exists for 3D
cadastral registration.
In Denmark the separate registrations of real property in the land registration and
of real estate in the cadastral registration makes it already difficult to check the legal
status of 2D situations. Therefore, the first step towards a 3D cadastre requires
linking the land registration and the cadastral registration more closely together,
allowing both registrations to access the information of each other. Some countries
are, or will be soon, able to establish 3D property units with multilevel ownership no
longer related to surface parcels within the existing juridical framework (with some
extensions): Norway, Sweden, Queensland and British Columbia. These solutions
differ per country, e.g. the footprints of 3D property units are limited to the 2D
surface parcels (British Columbia) or not (Norway, Sweden, Queensland), the 3D
property units have to relate to built constructions (Norway, Sweden) or not (British
Columbia, Queensland), the 3D property units have to be described in survey plans
(British Columbia, Queensland) or not (Norway, Sweden).
As can be concluded from this chapter, none of these solutions is a complete solution
for 3D cadastral registration. Firstly, a digital description of the 3D property
unit in vector format is not maintained (only scanned or paper drawings) in the land
registration. Therefore, the 3D property unit cannot be viewed interactively and the
geometry of the 3D property unit cannot be checked. Secondly, the 3D properties are
still not incorporated in 3D in the geographical data set of the cadastral registration,
hence it is not possible to query the 3D situation. The 3D property units are incorporated
into the cadastral data set in the same way as 2D properties (as footprints).
These solutions therefore do not address technical issues, such as how to store, query
80
4.9. Conclusions
and visualise 3D property objects (in 3D) and how to make sure that 3D properties
do not overlap (the condition that 2D parcels may not overlap assures complete and
consistent registration in current cadastres).
Although the examples of establishing multilevel ownership show good potentials
for a 3D cadastre, in some countries the step to register 3D properties that are no
longer related to surface parcels may be too extensive for the short-term future. An
introduction of multilevel ownership requires redefining the cadastral concept. It
is dependent on the legal system if 3D property units that are no longer related to
surface parcels are easily possible within the current juridical framework. In countries
where the concept of ownership of real estate is still restricted to a surface parcel, the
3D cadastre either has to find solutions to improve cadastral registration using the
concept of a surface parcel or has to reconsider the traditional concept of ownership.
81

Chapter 5
Needs and opportunities for a
3D cadastre
The first part of this thesis focused on the basic question ‘what are the needs for a 3D
cadastre’. Therefore first an inventory was made of types of Dutch cadastral recordings
with a possible 3D component (chapter 2). To show the complexities of current
cadastral registration of 3D situations in the Netherlands, chapter 3 described six (national)
case studies. Chapter 4 described international developments on 3D cadastral
registration in order to see if this research on improving 3D cadastral registration in
the Netherlands can benefit from experiences abroad.
The implementation of a 3D cadastre will only be successful if the considerations
for the 3D cadastre reflect on the current cadastral framework. The current cadastral
registration of 3D situations in the Netherlands will therefore be summarised in
section 5.1.
The current cadastral registration meets complications in 3D situations, causing a
need for a 3D cadastre. This chapter will elaborate on the findings of the first part
of this thesis in order to see what the needs are for a 3D cadastre. In addition, this
chapter will also describe the potentials for a 3D cadastre.
The complexities of current registration will be summarised in section 5.2. From
the complexities, the basic needs for 3D cadastral registration can be deduced (section
5.3). A 3D cadastre offers other opportunities as well, as will be described in
section 5.4. When looking at the opportunities of a 3D cadastre, it is relevant to look
for applications outside the cadastral domain which may benefit from a 3D approach
of cadastral registration and vice versa, directly (since 3D information can be interchanged)
as well as indirectly (since they can learn from the experiences from each
other). Section 5.5 will describe 3D applications outside the cadastral domain. This
chapter will end with conclusions.
83
Chapter 5. Needs and opportunities for a 3D cadastre
5.1 Current cadastral registration of 3D situations
in the Netherlands
In Dutch practice the legal status of most 3D situations is secured using apartment
rights or right of superficies established on surface parcels. In case of apartment rights
spatial information is available in the land registration using the legally prescribed
(paper or scanned) drawings including cross sections. Although not strictly 3D, a
drawing of each vertical layer is provided. In case a right of superficies is established in
general no drawings are available in the land registration. Only in case of apartment
units, the 3D property unit is known in the (administrative part of the) cadastral
registration. In both cases the 3D property unit is not incorporated (in 2D nor in
3D) in the spatial part of the cadastral registration, with the exception that outlines
of underground objects can be inserted into the topographic part of the cadastral
database (which is not part of the cadastral map) by using a specific classification and
visibility code. The scanned drawings will soon be accessible through the cadastral
registration.
Current cadastral registration of 3D situations can be accomplished by a notification
in the cadastral registration specified with an ‘OB’ code (Ondergronds Bouwwerk:
underground construction). Such a notification is registered on a parcel. The OB
notification indicates that something is located below the surface, whereupon the
user can do further examination in the land registration (see section 2.5). The legal
documents recorded in the land registration describe which rights are established on
the intersecting parcels and may be accompanied by a drawing. The OB code does
not say anything about the legal status of the 3D property situation. In addition,
this solution only covers constructions below the surface and covers therefore only
part of the 3D situations. As was seen in section 2.5.3, many other types of cadastral
registration (occurring in more than 2 million cadastral recordings in September 2003)
may indicate a 3D situation as well.
The cadastral database of September 2003 showed 1532 occurrences of an OB code,
while none of these situation was indicated in the cadastral geographical data set.
Notaries have to get used to this new type of registration. They will only use it
when it has public benefits to them or their customers (e.g. more legal security, less
work). Further the OB code is not used in a uniform way. We selected the registered
OB codes, grouped by the different (cadastral) municipalities. Note that in the
Netherlands, the notaris (civil law notary) is a publicly appointed offical charged with
drawing up authentic deeds and legalising documents. He is also a legal specialist on
real etstate law and acts as such also as an advisor of parties involved in transactions.
The diagram in figure 5.1 shows the number of occurrences of an OB code (on the
y-axis) per municipality (on the x-axis). Municipalities with no OB codes are not
included. In total there are 1218 cadastral municipalities in the Netherlands of which
44 with one or more occurrence(s) of an OB code. The municipalities are ordered
on the number of OB occurrences. These results show that four municipalities are
responsible for 40 percent of the OB occurrences: Emmen, De Wijk, Dalen and Norg.
In addition 28 municipalities of this list (responsible for 1386 OB recordings) are all
situated within the cadastral district of the regional office of Assen (which is one of the
84
5.2. Complexities of current cadastral registration
less dense populated parts of the Netherlands). From the fact that a spatial correlation
is present in the registration of OB codes, while the high number of OB recordings
does not correspond with a more frequent occurrence of underground constructions,
it can be concluded that the registration of an OB code is strongly influenced by
preferences of the parties involved and consequently that the registration of an OB
code is not uniform. For both the person who is responsible for the registration of an
OB code (mostly the notary) and the person who queries the cadastral registration,
it is not unambiguously clear when an OB code is to be used. The subjects that are
linked to the OB codes are too diverse to be able to conclude if for example the user
of the volume below the surface influences the registration of OB codes (for example
a company that owns a large network of pipelines in this area).
Figure 5.1: The number of occurrences of an OB code per cadastral municipality.
Not in all cases the establishment of special rights for underground objects is juridically
necessary. Many underground situations relate to infrastructure where the owner
of the parcel is also the owner of the subsurface object (e.g. a subway-tunnel under
land owned by the municipality). In these cases no reference to a subsurface object is
made at all in the deed, let alone that a drawing is provided. Consequently, this will
also not lead to a cadastral recording of the situation. Other cases of underground
constructions that do not lead to a cadastral recording are cases of not-registered personal
rights (short lease), obligations to tolerate constructions for public good that
follow from general laws and when nothing is registered.
5.2 Complexities of current cadastral registration
Requirements and developments of 3D cadastre are dependent on the type of cadastre
as well as on the historical and juridical background of a specific country.
85
Chapter 5. Needs and opportunities for a 3D cadastre
A study abroad showed that cadastral registrations in many countries are based on the
same principle as the Dutch cadastral registration: a parcel is the basic registration
entity for cadastral registration. This principle of cadastral registration follows the
juridical definition of ownership of land. Ownership of land is defined by boundaries
on the surface and is not explicitly limited in the vertical dimension. In general, the
ownership of land includes all space above and below the parcel, as well as all constructions
that are permanently fixed to the land. The consequence is that property
to land is very well registered in the cadastral registration by means of 2D parcels,
while 3D property units are established and registered by means of limited rights and
other restrictions on intersecting parcels, i.e. an owner can be restricted in using the
whole parcel column by establishing limited rights, apartment rights or Public Law
restrictions.
Some other countries and states have redefined the unlimited ownership of a parcel.
In these countries and states it has recently (or will soon) become possible to establish
ownership rights related to bounded volumes by defining volumetric parcels (Queensland),
air-space parcels (British Columbia) or 3D construction properties (Norway
and Sweden). These 3D property units are the result of subdividing 2D parcels (or
actually parcel columns). The solutions fit into the existing juridical framework of
the specific country or only required small adjustments. The possibilities to establish
multilevel ownership have not (yet) been translated into an appropriate cadastral
registration of 3D property units. The 3D property units exist as independent properties
in the land registration and are described on 3D survey plans. The 3D property
units also exist as independent properties in the administrative part of the cadastral
registration. However, it is impossible to view the 3D property units interactively
(which is helpful to get insight into complex 3D property units) since the drawings
are only available in scanned or paper format. In addition, consistency checks are not
possible: are two 3D properties neighbours, is there a gap, is there overlap? Finally,
the 3D properties are not available in 3D as part of the cadastral geographical data
set.
5.2.1 Complexities of current Dutch cadastral registration
Although it is possible to register the legal status of 3D situations in the Netherlands
administratively, the registration is not satisfactory, because of several reasons:
• The right itself is administrated, but not the function of the object to which the
rights refer (underground infrastructure, metro station, subterranean parking
place).
• 3D spatial information on rights (geometry, location) is not available, e.g. does
the right of superficies apply to space above or below the surface?
• The administrative information (by means of restrictions and limited rights)
may indicate that something could be located above or below the surface. As
was seen in section 2.5.3 in September 2003, a total of about two million of such
recordings were available in the cadastral database. However, this is the only
information that the current cadastral registration can provide in 3D property
situations.
86
5.2. Complexities of current cadastral registration
• In the Netherlands (and most other countries) no rules or standardisation exist
for establishing rights and for setting up deeds in 3D situations, leading to
diverse solutions. Every notary (or licensed surveyor in other countries) that is
confronted to register rights in 3D situations has to decide upon which rights
to use in specific situations and what information to include in deeds (ranging
from detailed 3D surveys to a global description).
Cadastral registration of property units in building complexes
Property units in buildings are mainly established by means of apartment rights, and
sometimes with a right of superficies, as was seen in chapter 3. With the cadastral
registration of these rights, it is possible to see which persons have a right on a
parcel or an apartment unit. However, the cadastral registration cannot provide
information on how properties are located in the complex itself. Also the property
units in building complexes, which are established with means other than apartment
rights cannot be found as distinct objects in the land and cadastral registration.
Drawings can be added in deeds, which are archived in the land registration (which is
obligatory only in the case of apartments rights). The deeds, and thus the drawings,
will soon be available in scanned format, thus making these documents accessible
through the cadastral network. However, spatial information in vector format in real
world coordinates would provide the possibility to incorporate this information as
part of the cadastral geographical data set.
Cadastral registration of infrastructure objects
In case of infrastructure objects, the 2D parcel is strongly limiting the amount of
information that can be obtained from the cadastral registration:
• The rights for 3D infrastructure objects are established by means of ownership
rights, limited rights, and legal notifications; all established on intersecting
parcels and not on the infrastructure objects themselves. These rights are not
related to the infrastructure objects.
• There is no uniform way to establish the legal status of infrastructure objects
and consequently the registration for infrastructure objects is not uniform.
• The infrastructure object is partitioned over the many parcels it intersects with.
No information on the whole infrastructure object is available, not even an id,
i.e. the existence of the object is not known in the cadastral registration. Since
the spatial extent of the objects is not known the following queries cannot
be performed ‘which parcels intersect with the 3D object?’ ‘what rights and
restrictions are established on the parcels intersecting with the 3D object?’, ‘are
there any 3D objects (tunnels, pipelines) intersecting with a specific parcel?’.
• When the parcel is subdivided (e.g. in case of a transfer of a part of the parcel),
it is not always known in which part of the parcel an infrastructure object is
actually located. Therefore, the cadastral database can become polluted since
all child parcels will be encumbered with a restriction due to the (potential)
presence of a construction. The registration does therefore not necessarily reflect
the real situation.
87
Chapter 5. Needs and opportunities for a 3D cadastre
5.2.2 Locating infrastructure objects in the current cadastre
There are basically three possibilities of locating infrastructure objects in the current
cadastral registration. The case of the HSL railway tunnel (see section 3.2.2) can be
used to illustrate these possibilities. We used the parcel boundaries of the intersecting
parcels and 3D spatial information on the tunnel to create a fictive cadastral map (see
section 12.1.5) with new parcel boundaries to limit the parts of the parcels that are
affected by the tunnel (according to Dutch rules). Although the actual cadastral
geographical data set of 2003 was used, the examples in this section are not intended
to show the actual parcel boundaries: they are only meant to clarify the alternatives.
(a) Whole parcel is affected
(b) New parcels are generated
(c) As (b) but
now some parcels
are not divided
Figure 5.2: Three possibilities to register infrastructure objects.
The first map (figure 5.2 (a)) would be the result if all parcels intersecting with the
tunnel were completely affected with a right to build the tunnel. The location of
the 3D object is (vaguely) indicated when all parcels that are intersecting the tunnel
are selected. This selection is done by finding all the parcels that are encumbered
with a right of which the Ministry of Transport and Public Works is the subject.
The relationships between the tunnel and (limited) rights and notifications that are
established are not stored (the tunnel itself is not stored). The only information that
the cadastral registration can provide is what rights and notifications are established
on a parcel and who the subjects are of the rights and notifications. In the case of the
HSL tunnel, this subject is the Ministry of Transport and Public Works. Since the
Ministry owns many other objects as well, this does not give insight into the nature
of the 3D object that the Ministry keeps on the intersecting parcels: the object could
also be a viaduct or a road at surface level. In addition, the result could also be a
mix of several different objects (belonging to the same owner).
88
5.3. Basic needs for a 3D cadastre
When the tunnel partially intersects a parcel, normally the ownership or the right
of superficies will just be obtained for only a part of the land (according to Dutch
legislation, as explained in section 2.5.2). This will lead to the creation of new parcels.
Figure 5.2 (b) illustrates this situation: the Ministry has obtained rights of ownership
or superficies for the extent of the tunnel (with a needed safety zone on both sides).
New parcels are generated. Still the relation between the tunnel and all the parcels is
not maintained in the database. Because of the pattern of (new) parcels, the location
and direction of the tunnel is clearly visible. But if other constructions are (partly)
built on top of the tunnel and new parcels will be created according to the footprint
of these buildings as in the Rijswijk case (section 3.2.1), this image will be disturbed.
Also, the same parcel pattern might be the result in the case of physical objects
above the surface (roads). The cadastral map is even more disturbed in figure 5.2
(c). It is more realistic to suppose that the Ministry is not the owner of only the land
right above the tunnel, but also of complete parcels. For example when during the
negotiations they agree to buy all the land from the original owner (and not only the
small zone that is actually needed). In this case, there is no need to generate new
parcels.
In case of cables and pipelines it is not always required to create new parcels to be
able to establish the restriction on only a part of the parcel. In those cases AKR uses
a ‘BZD’ or a ‘OLD’ code (see section 2.3.2). The exact location of the restriction can
be defined in the deed, but is not maintained in the cadastral registration. Consequently,
the location of the restriction is not clear from the cadastral registration. The
alternative is to split parcels and to register a ‘OL’ code (BZ codes are not possible
after 1992).
5.3 Basic needs for a 3D cadastre
The complexities described in the previous section, are not (all) new. However, they
have become more obvious during the last decades. This is partly due to the fact that
3D situations have been occurring much more often than forty years ago (number
of multi-purpose buildings has increased, number of cables and pipelines has grown,
many tunnels have been built during the end of the last century). But also due to a
considerable increase in the value of property during the last decades, users want to
have the legal status of their property clearly ensured in the cadastre. This means
that the cadastre should give sufficient insight into property and in the boundaries of
property in all dimensions.
From the complexities and limitations summarised in the previous section, conclusions
on the basic needs for a 3D cadastre can be drawn. The basic needs for a 3D cadastre
can be summarised as:
• to have a complete registration of 3D rights (rights which entitle persons to
volumes). The current cadastre already registers rights which entitle persons to
volumes, however a 3D cadastre should explicitly register the 3D space to which
these rights apply;
• to have good accessibility to the legal status of stratified property including
(3D) spatial information as well as to Public Law restrictions.
89
Chapter 5. Needs and opportunities for a 3D cadastre
It is disputable and dependent on the background of a cadastral registration if information
that does not directly support the main tasks of a cadastre should be registered
and maintained in the cadastral registration, e.g. the exact location of cables
and pipelines. In addition, it will be more effective (e.g. with respect to data integrity
and data consistency) if information on constructions and other objects of interest
are maintained at their source and accessible within and from the 3D cadastre.
Based on these considerations, we can conclude that a 3D cadastre should incorporate
the following functionalities:
• register 3D information on rights (what is the space to which the person with a
real right is entitled?) and make this information available in a straightforward
way;
• establish and manage a link with external databases containing objects of interest
for the cadastre (infrastructure objects, soil pollution areas, forest protection
zones, monuments) and incorporate the location (and other information)
of these objects in the cadastral registration;
• use the information on these objects to support registration tasks, i.e. to detect
and correct errors or in the process of registering and viewing the legal status
of 3D situations. Are all intersecting parcel encumbered with a right for the
infrastructure object?.
Linking different registrations and linking different databases can be established by
the set-up of a well-working national Geo-Information Infrastructure (GII).
Geo Information Infrastructure
The term “Spatial Data Infrastructure” (SDI) or “Geo-Information Infrastructure”
(GII) is often used to denote the collection of technologies, policies and institutional
arrangements that facilitates the availability of and access to geo-information to the
benefit of many users [132]. The word infrastructure is used to promote the concept
of a reliable, supporting environment, analogous to a road or telecom-network, that,
in this case, facilitates the access to geo-information using a minimum set of standard
practices, protocols, and specifications. Like roads and networks, a GII facilitates the
conveyance of virtually unlimited packages of geographic information [132]. A GII
consists of the following four components [65]:
• geographic data;
• technology for storing, access, distribution and use of geo-information;
• standards for describing, exchanging and linking geo-information;
• policy and organisation.
A distributed set-up of registrations within a GII provides the possibility to link information
maintained in different databases. In this way the geometry of infrastructure
objects and other 3D objects of interest can remain and be maintained at their original
source (in databases at organisations who are responsible for these objects), while
this information can be used to improve cadastral registration in 3D situations.
90
5.4. Opportunities for a 3D cadastre
5.4 Opportunities for a 3D cadastre
A 3D approach to cadastral registration offers improvements for the main tasks of a
cadastre for a number of reasons:
• 3D registration provides information on the 3D extent of rights, limited rights
and legal notifications and allows integration of 3D information in the current
cadastral geographical data set. In the case of 3D registration, a 3D property
unit can be queried in a 3D environment in the same way a parcel can be queried
in the current registration (with some other attributes).
• A 3D cadastre will incorporate digital information on 3D situations. In the
current registration analogue drawings clarifying the 3D information can be
added to deeds. The availability of deeds in digital (scanned) form has already
improved the accessibility of information. It is now possible to link digital documents
to parcels in the cadastral geographical data set (e.g. the document
appears after clicking on a parcel). However, a vector representation of the situation
in the national reference system (not scanned) instead of a drawing will
offer better registration possibilities, since it is easier to integrate the vectorinformation
with the current cadastral geographical data set to get an overview
of the whole 3D situation (and not just at the location of the specific parcel).
Digital information will also offer better possibilities for quality checks. In addition,
digital information facilitates the exchange and integration of information
between and within cadastral offices, municipalities and provinces and it facilitates
viewing of 3D (property) situations interactively.
• When enabling 3D registration, the parties involved have a tool to register 3D
situations, which may motivate them to include spatial information in deeds and
to establish the legal status of 3D situations in a uniform way. This makes it
possible to have uniform, and consequently readily accessible, recordings of 3D
property units (it should be noted that coordinates, also in 3D, should always
be obtained from cadastral surveying).
A 3D cadastre can interact with other registrations, which offers other opportunities
as well:
• If the exact 3D location of infrastructure constructions is available within the
cadastral registration (maintained in databases by holders of these objects), the
cadastre can use this source for certain cadastral tasks e.g. during clean-up of
registration or to support other cadastral tasks.
• Holders of infrastructure constructions will benefit from a clear registration of
the location of infrastructure objects, since they have more legal protection
(rights are better maintained) and they do not pay compensation for parcels
that do not intersect. In current practice errors occur such as a cable crosses a
parcel but no limited right or notification has been established or a limited right
or notification has been established while the parcel is not crossed by a cable.
By knowing the exact locations, the parcels and thus the persons involved and
who need to be compensated can be more accurately determined.
• Linking databases containing infrastructure objects with the cadastral registration
can also be used for registering pipelines according to the Law on Telecommunication.
According to a decision of the Dutch Supreme Court, telecomnetworks
are considered as immovable goods (this decision will in the future
91
Chapter 5. Needs and opportunities for a 3D cadastre
apply to other cables and pipelines as well). Consequently the cadastre has to
be able to register these networks apart from parcels and apartments (see section
2.4.1). This registration can be improved when a direct link is maintained
with the database of the holder of the networks (and of other pipelines in the
future).
5.5 3D applications outside the cadastral domain
To ensure legal security and to support town and regional management in general, 3D
geo-information gets more attention in today’s society where there is an increasing
interest to place different types of land use on top of each other. Registrations and
applications outside the cadastral domain are therefore also confronted with the fact
that 3D information becomes more and more important. A 3D cadastre can benefit
from other domains that develop towards 3D and vice versa, since knowledge and
experiences can be shared and since 3D data can be interchanged.
Many examples of applications that have a growing interest in 3D information have
been cited in [145, 146]. Traditionally, the military applications were the first to
look for 3D solutions and provided the first elaborated systems for 3D visualisation
and simulation [105]. Nowadays more and more civil applications need the third
dimension:
• Urban planning is one of the most demanding areas pushing 3D developers to
provide fast modelling approaches, extended visualisation and interaction tools,
and elaborated spatial functionality [123, 190]. The influence of new buildings
and infrastructure on the existing environment can be visualised best in 3D
environments, which is important in discussions with citizens. In addition, 3D
visualisations of planned infrastructure and underground constructions provides
better insight into the vertical planning of regions [90].
• Landscape modelling seeks specific 3D tools for interactive design and simulation
[12, 25].
• Road, railway and canal construction and maintenance benefits largely from
visual 3D environments [15].
• Maintaining 3D information on real-world objects enables to deal with 3D characteristics
of buildings, e.g. calculating the volume of buildings (for tax purposes)
or dictating a maximum construction height and depth.
• 3D geo-information can serve as input for 3D spatial modelling such as modelling
noise levels [93] and risk modelling for buildings when a tunnel is being drilled
[124].
• Knowledge about 3D characteristics of natural processes can be used to impose
limitations and obligations, e.g. in case of noise control, odour nuisance and
safety measures.
• In telecommunications the decision on the locations of antennas requires 3D
analysis to obtain information on the area which can be covered and on the
costs of using a specific location.
• Geological applications (e.g. finding fractures or salt domes) require 3D analysis
[230].
92
5.5. 3D applications outside the cadastral domain
• In order to predict the consequences of bursting of dikes (flooding), a good
terrain model is needed together with 3D software [231, 239].
• Cables, pipelines and tunnels can be better protected against damage when
their 3D location can be visualised in the real world [182] (see figure 5.3). Based
on knowledge of the location of constructions precisely defined restrictions can
be imposed on the owners of the surface land from doing anything that could
damage the underground construction.
• Location-based services (LBS) for shopping, tourism, rescue operations etc. is
another area, where the use of 3D visualisation (and most probably 3D GIS) is
rapidly increasing [29, 80].
A last example with increasing interest in incorporating 3D geo-information is the
domain of local land use plans. At the moment there are no standards or rules to
incorporate 3D information in local land use plans. Consequently every local land use
plan that has to regulate different types of land use on top of each other reinvents the
method how to deal with the 3D component of local land use planning. Local land use
plans can also differ within one project since local land use plans are the responsibility
of municipalities and infrastructure objects may cross municipality boundaries, e.g.
as in the case of the HSL-tunnel.
Figure 5.3: To avoid damage to cables, first digging by hand is necessary (Dutch
Newspaper, July, 2000).
An example of a local land use plan which had to deal with 3D information is the
‘Noord-Zuid lijn’ in Amsterdam.
3D local land use plan of the Noord-Zuid lijn Amsterdam
In Amsterdam a metro-tunnel is being drilled from north to south (the ‘Noord-
Zuidlijn’). A local land use plan was needed in which the use of a tunnel below
other types of land use was guaranteed. The tunnel is planned partly below houses.
93
Chapter 5. Needs and opportunities for a 3D cadastre
Figure 5.4: Local land use plan of metro tunnel (Noord-Zuid lijn) in Amsterdam.
‘Ondergronds railtrac´e waarboven’ means ‘Subsurface metro line on which’.
Figure 5.4 shows part of the map that was produced for this local land use plan. It
is a 2D map. The areas on the 2D map are encoded (as ‘multi-layers’) and the 3D
information (tunnel below houses) is added as a description in the legend and not as
a 3D spatial description. Consequently, the local land use plan of the Noord-Zuidlijn
does not include 3D spatial information (also not elsewhere in the local land use plan).
5.6 Conclusions
This chapter summarised from the previous chapters the complexities and limitations
of current cadastral registration in 3D property situations.
From a juridical point of view it does not seem problematic to establish 3D property
units. This can be realised either within juridical frameworks that still strongly hold
to the unlimited concept of ownership that is linked to surface parcels (using right
of superficies, apartment rights and strata titles) or within more flexible juridical
frameworks that enable establishment of multilevel ownership (e.g. air-space parcels,
volumetric parcels, construction properties) as was observed in a few other countries.
In the Netherlands, where 3D property units are established by means of limited
rights on surface parcels, the registration of the legal status of 3D situations has until
now been limited to an administrative registration. In the case of apartment units or
94
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 offers 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 offers 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 different 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.1 Data 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 ‘isa’
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.1 Data 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 offered 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 offer 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 different 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.
Buffer, convex hull, union of objects and all types of generalisations fall in the group
of specialisation operations.
6.1.2 Design 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.2 Conceptual 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.3 Logical 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.1 Relational 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
different 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
6.3. Logical model
SQL
SQL is the most widely implemented database language for relational models. SQL
has two components: the DDL (Data Definition Language) and the DML (Data
Manipulation Language). The schema of the database (containing definitions for
tables and constraints) is specified with the DDL. The DDL is used to create, delete
and modify the definition of the tables in the database, while the actual queries are
posed and rows are inserted, updated and deleted in the DML. The basic principles of
SQL [214] are described below to provide understanding of the SQL statements used
in this thesis. Oracle SQL is used here as example, although slight differences can be
present between the SQL in different relational DBMSs. A table can be created using
the DDL component of SQL:
CREATE TABLE subject (
subject_id number(12),
name varchar2(128),
street varchar2(24),
place varchar2(24),
PRIMARY KEY subject_id)
The name of the created table is ‘subject’. The table has four attributes, and the
name of each column and its corresponding data type is specified. Tables no longer
in use can be removed from the database using the ‘drop table’ command. After the
table has been created, data can be inserted in the table (’populating the table’).
This is done in the DML component of SQL. The following statement adds one row
to the table ‘subject’:
INSERT INTO subject VALUES (999, ‘Stoter’, ‘Jaffalaan 9’, ‘delft’)
To add another row with the same subject id will be rejected by the DBMS because of
the primary key constraint specified in the ‘create table’ statement. The alternative
to the insert command is ‘bulk loading’ which can be used to save time when inserting
high volumes of data. Once the database schema has been defined and the tables are
populated, queries can be expressed in SQL to extract the subsets of interest. The
return values of a select query can also be the result of operations on the resulting
subset. The basic operations are union, intersection and difference. All the rows of
the table are scanned and the ones where the sought value is found are returned as
results. The basic form of a select query (which is part of the DML) is:
SELECT column names FROM relations WHERE row-constraint
Operations can be specified after both the SELECT and the WHERE key-word.
6.3.2 Object oriented model
Although objects always have been the basis in the conceptual phase of data modelling,
the existing technologies forced the data model to be implemented in other
structures such as the relational structure. However, relational modelling is table and
record oriented and not object oriented, which has proved to have its limitations when
modelling the real-world [74]:
• A restricted set of data types are available even for less complex data.
105
Chapter 6. Theory of spatial data modelling
• The structure of relational databases (tables, rows, columns) does not accommodate
complex data types easily.
• Complex data can be stored as BLOBs (Binary Large Objetcs), which can be
retrieved from relational databases, but not searched, indexed, or manipulated.
• Relational tables offer an inadequate model of real-world objects, since you can
only model objects as a set of relationships, e.g. how to deal with behaviour of
objects.
• Relational tables offer poor support for integrity constraints.
• Operations are only available in a limited way.
• In relational DBMSs it is difficult to handle recursive queries.
The basic idea of object oriented modelling is to make a direct correspondence between
real-world entities and their computer representation. In an object oriented data
structure, classification is the main principle. Classification is the mapping of objects
or instances to a common type. The combination of classes, objects and operations
(methods), together with the inheritance principle, characterises the object oriented
model, in contrast to the record oriented relational model [99].
Classes and objects
Classes are collections of objects with the same behaviour. Instances are particular
occurrences of objects for a given class. Within classes subclasses can be defined, for
example the class trees can be divided into leaf trees and fir trees. The subclasses are
specialisations of the superclass, as was mentioned before.
Attributes
Objects have attributes associated with them with their data types (which can be
user-defined data types). Attributes are the descriptive properties of the object.
Instances of an object have all the attribute types of the class in common. Attribute
values can be defined at either the class or the instance level.
Methods
Classes are not only characterised by attributes but also by methods. ‘Method’ refers
to an operation on objects: a procedure that can be applied to a class of objects. A
method is a member function of the class.
Inheritance
In classification hierarchies, an object in a subclass (specialisation) inherits all attributes
of the corresponding higher-level superclass. For example if we have a superclass
LineString we can define subclasses LinearRing and Line which both inherit the
operation Length from LineString.
In object oriented modelling the spatial and non-spatial attributes of spatial objects
are not very much different from each other. The attributes ‘area’ and ‘geometry’
of a land parcel are not treated differently as other alphanumerical attributes. According
to [234] there are some problems with object oriented databases that cause
performance to be a difficulty in object oriented databases:
• Provision of query optimisation is made difficult by the complexity of object
types. Many operations are available compared with the few operations in
relational DBMSs. It is therefore hard to estimate the cost of execution and to
choose between different strategies to execute a query.
106
6.3. Logical model
• Indexing is hard. The difficulty is that indexes rely on direct access to attribute
values, while an object is only accessible via messages through its protocol and
identified by the object-id.
• Transaction in object oriented databases may be of a much higher level of complexity
than simple transactions within a relational DBMS. Due to the hierarchical
nature of much object data, transactions may cascade downwards and
affect many other objects.
According to [74] the problems of the object oriented approach are that there is no
standard data model, object orientation has no clear theoretical basis and, most importantly,
there is no standard query language, such as SQL in relational databases.
Because of these problems, object oriented modelling has been less adopted in mainstream
DBMSs than relational modelling.
6.3.3 Object relational model
The object relational model [195] introduces the advantages of object oriented models
in relational models. In relational databases the set of data types is fixed. In object
relational modelling this limitation is overcome because of the built in support for
user-defined data types: Abstract Data Types (ADTs). Like classes in object oriented
technology, a user-defined type consists of (internal) attributes and member functions
to access the values of the attributes. Member functions are callable within SQL
and can modify the values of the attributes in the data type. A user-defined type
can appear as a column attribute type in a relational schema. The term abstract is
used because the end user does not need to know the implementation details of the
associated functions. The structure is hidden from the user, who can access it only
through the operations defined on it. All that the end users need to know is the
interface, i.e. the available functions and the data types of the input parameters and
output results [186]. The ADTs appear at the same level as base data types, such as
float or string.
Spatial data and Abstract Data Types
Spatial database applications must handle complex data types such as points, lines
and polygons in 2D and 3D and also 3D primitives such as polyhedrons. Traditional
relational DBMSs only support a set of alphanumerical data types (date, string,
number). In [47] it was stated that the principal demand of spatial SQL is to provide
a higher abstraction of spatial data by incorporating concepts in relational databases
closer to our perception of space. This can be accomplished by incorporating the
object oriented concept of user-defined ADTs. When a user-defined type ‘point’ is
created, one can define a column name ‘location’, of type ‘point’. The operations that
can be performed on the data type are stated in the type definition. For the point
type for example a function ‘distance’ can be defined, which computes the distances
between two points. Another example is a land parcel stored in the database. A
useful ADT may be a combination of the type polygon and some associated function
(method), say ‘is adjacent’. The adjacent function may be applied to land parcels to
determine if they share a common boundary.
The OpenGIS Consortium (see section 6.7.1) defined specifications for incorporating
107
Chapter 6. Theory of spatial data modelling
2D spatial ADTs in SQL. These ADTs include topological and geometrical operations.
How mainstream DBMSs implemented these specifications is described in detail in
chapter 7.
6.4 Physical model
In the phase of the physical design, the logical model is translated into hardware and
software architecture. The physical model is hidden from the user. The design of
the physical model is critical to ensure reasonable performance for various queries.
Therefore, the physical design has to enable the operations for manipulating the
logical model in an efficient way. At the physical level the following tasks are handled
by the DBMS [178]:
• Storage. The DBMS manages an efficient organisation of the data on a persistent
secondary storage unit (mostly one or many disks). The representation at
this level might be completely different from that shown to the user according
to the logical data model. A table might be stored in several files, possibly
distributed over many disks. Data sets are often too large to fit in the primary
memory of the computer and accessing secondary memory is much slower than
accessing primary memory caused by moving the head of the disk reader. On
the other hand transporting data between primary and secondary memory may
also cause a performance bottleneck. The goal of good physical database design
is therefore to keep the amount of data transfer between primary and secondary
memory to an absolute minimum.
• Access paths and (primary) indexes. In response to a query the spatial access
method should only search through a relevant subset of objects to retrieve the
query answer set. This can be achieved by primary and secondary indexes.
Primary indexes are built with the table itself, while secondary indexes are
additional structures. A DBMS provides data access methods or access paths
that accelerate data retrieval. A typical data structure that accelerates data
retrieval is the B-tree [28].
• Query processing. Processing (evaluating) a query usually involves several operations.
To efficiently evaluate the query, these operations must be properly
combined. An important issue in query processing is the design of efficient join
algorithms.
• Query optimisation. Because most query languages are purely declarative, it is
the responsibility of the system to find an acceptably efficient way to evaluate
a query.
• Concurrency and recovery. The DBMS manages concurrent access to data and
resources from several users and should guarantee the security and consistency
of the database, as well as the recovery of the database to a consistent state
after a system failure.
Another aspect that can be added to this list is [186]:
• Clustering: Goal of clustering is to reduce seek and latency time in answering
queries that result a range of data. For spatial data this implies that objects that
108
6.5. UML
are close to each other in the real world and are commonly requested jointly
by queries, should be stored physically together in secondary memory. The
design of spatial clustering techniques is more difficult compared with traditional
clustering, because a storage disk is a one-dimensional device. What is needed
is a mapping from a higher dimensional space to a one-dimensional space which
is distance preserving. Several mappings to accomplish this are Z-order, Gray
code and Hilbert curve [52].
6.5 UML
The Unified Modelling Language (UML) [215] has become a standard language for
object oriented software design at the conceptual level but also for many other applications.
The language can be used to model the structural schema of a data model
at conceptual level. There are many types of UML diagrams: use-case diagram, class
diagram, object diagram, sequence diagram, collaboration diagram, statechart diagram,
activity diagram, component diagram and deployment diagram. Apart from
the diagrams the UML-standard offers a language to formally describe limitations
and constraints in the diagrams: the Object Constraint Language (OCL). UML has
two diagrams to describe the static structure of a system: class diagram and object
diagram. Both diagrams show the elements of the system and the structural relationships.
The class diagram contains the classes in the system with their attributes,
operations, relationships (associations) and constraints. The class diagram is a model:
it describes the structure and the limitations of the objects. The object diagram is a
representation on a certain timestamp of the objects that have been created according
to the structure of the class diagram. In most cases only the class diagram is used.
In this thesis the class diagram of UML is used to describe the data models. UML
notation for class diagrams is briefly described in this section (see also [228]).
Class
Class is the encapsulation of all objects which share common properties in the context
of the application. The UML notation of a class is a rectangle with three parts. In the
top of the rectangle the name of the class is stated, in the second part the attributes
and in the third part the operations.
Parcel
+Object id:number
-First line id:number
+Return polygon(object id):geometry
Object
An object is denoted in UML with a rectangle containing underlined text, starting
with a colon, followed by the name of a class (e.g. : Parcel).
Attributes
An attribute is information, maintained by an object (instance of a class). Every
attribute has exactly one value for every instance of the class. These values represent
the state of an object. Attributes are stated in the middle part of the representation
of a class. The type of the attribute is reflected after the colon after the name of the
109
Chapter 6. Theory of spatial data modelling
attribute. A ‘+’ for the attribute indicates that the attribute is known outside the
object (public attribute), a ‘-’ indicates that the attribute is only known within the
object (private attribute).
Operations
The collection of operations of an object represents the behaviour of an object. Since
all instances of a class have the same operations, the operations are described within
the class. An operation can have arguments and a return-value. Operations are stated
in the bottom part of the representation of a class. Parameters are given with round
brackets after the operation name. The type of a return-value is given behind a colon
after the parameters. The ‘+’ or ‘-’ can be added to indicate whether the operation
is public or private.
Association
An association is a structural relationship between two classes. Structural means that
an instance from one class is related to an instance from the other class during its
existence. The relationship can change over time. Between two classes more than
one association can be defined. For example a person can work for a company, and a
person can be a customer of a company. In UML an association is drawn with a line.
The name of an association is typed along the line. The names of the relationship
are drawn from left to right and from top to bottom. If this is different, an arrow
indicates the direction of the relationship. The following types of associations can be
distinguished:
• generalisation/specialisation;
• aggregation;
• composition.
Generalisation/specialisation
Generalisation is the grouping of classes into new classes. A new class can be specified
if there are more than one class with identical characteristics (operations or
attributes). The original classes inherit these identical characteristics of the new created
class. The new class is called superclass or generalisation, the classes with the
identical characteristics are called subclasses or specialisations. In UML a generalisation/
specialisation is drawn with a large, open arrow. The arrow points to the
superclass (see figure 6.1 (a)). A superclass can represent an abstract class. An abstract
class is a class of which no instances can exist. In UML this is denoted by
giving the name of the class in italics, optionally followed by {abstract}, or by denoting
it as a stereotype, using <<name stereotype>>. A stereotype can be used
to specify that the class or object belongs to a more general group of classes or objects
which give them specific characteristics, e.g. interface, enumeration, application,
implementation, abstract etc.
Aggregation
Aggregation is a special kind of association to show that one or more classes are
part of another class. The parts can exist independently from the complex class. An
example of an aggregation is a bicycle having wheels and a frame. The wheels and
frame can exist individually and can be taken from the bicycle to be used for another
bicycle. In UML an aggregation is denoted with a white diamond on the side of the
complex (figure 6.1 (b)).
110
6.5. UML
(a) Generalisation/specialisation (b) Aggregation
Figure 6.1: Examples of UML notations.
Composition
In a composition relationship, also a special kind of association, a part can only
belong to one complex and there is a restriction that a part ceases to exist when the
complex ceases to exist: a part cannot exist independently from the complex. This
is called lifetime dependency. An example is a polygon existing of linear rings, when
the polygon is removed, the linear rings defining the polygon also cease to exist. A
composition is denoted with a black filled diamond on the side of a complex.
Multiplicity
The multiplicity is the number of instances of the associated class with which one
instance of the class can have a relationship. In UML the multiplicity is drawn with
an asterisk or a number. When nothing is defined, the multiplicity is one. The
possible notations for multiplicity are:
• 5: exactly 5;
• *: zero or more;
• 1..*: one or more;
• 2..5: two till five;
• 2,5: two or five.
The multiplicity can be drawn on both sides of the association. The multiplicity in
figure 6.2 (a) is read as ’a car transports two till six passengers and a passenger is
transported by zero or one car’.
Association class
An association class is a class related to an association. This means that the class is
identified with the association, which contains additional details (attributes, operations).
As soon as there is a relationship between two instances, an instance of the
association class exists. An example of an association class is a marriage, which is an
association class between a man and a woman, and in some countries also between a
man and a man or a woman and a woman (or between one woman and one ore more
men or vice versa) (see figure 6.2 (b)). An association class is used when the association
has attributes, when the association has operations or when the association itself
has associations with other classes than the two on which this association is based.
111
Chapter 6. Theory of spatial data modelling
(a) Multiplicity
(b) Association class
Figure 6.2: Examples of UML notations.
An association class is like a normal class and therefore it has the same characteristics
as normal classes within UML. In UML notation an association class is drawn with
the class symbol which is linked with a dashed line to the association it belongs to.
Constraints
A constraint is a limitation on one or more elements in the class diagram. In UML
constraints can be defined using the OCL (Object Constraint Language). An OCLconstraint
is denoted with the notation {OCL-constraint} in a notebox linked to an
object or class, e.g. {area of parcel > 0}. There are also two predefined constraints
in UML:
• The ordered collection of objects with multiplicity greater than one is denoted
with {ordered}, e.g. the ordered collection of linear rings in a polygon.
• The symbol {XOR} with a dashed line to two or more associations indicates
that only one of the associations can be instanced, e.g. a cadastral object can
be an apartment unit or a parcel, but not both.
An example of an UML class diagram is shown in figure 6.4, section 6.7.1.
6.6 Spatial data modelling and DBMS
Spatial data is mostly part of a complete work and information process. Therefore
in many organisations there is a growing need for a central DBMS (at least at the
conceptual level) in which spatial data and alphanumerical data are maintained in
one integrated environment. Consequently DBMSs are an essential part of the new
generation GIS architecture.
An extended description on how GISs have evolved with respect to DBMSs can be
found in [221]. GISs used to be organised in a dual architecture consisting of 1) data
112
6.7. Standardisation initiatives
management for administrative data in a (relational) DBMS and 2) data management
for spatial data in a GIS. This was caused by the different nature of alphanumerical
and spatial data and the inability of early DBMSs to handle spatial attributes. In
the dual architecture (figure 6.3, left) the two parts are connected to each other via
links (unique id’s). The spatial attributes are not stored in the DBMS and therefore
they are unable to use the traditional database services (query, index). In the dual
architecture the consistency of the data is hard to manage. For example if a parcel is
deleted in the spatial part, persons can no longer have a relationship with this parcel,
which is maintained in the non-spatial part.
Figure 6.3: Evolving architectures of GIS. Left: dual architecture; middle: layered
architecture, right: integrated architecture, taken from [221].
The solution to the problems of dual architecture was a layered architecture in which
all data is maintained in a single (relational) DBMS. Since spatial data types were
at that time not supported at DBMS level, knowledge about spatial data types was
maintained in middleware (figure 6.3, middle). Spatial information was maintained
in the DBMS by means of BLOBs (Binary Large Objects). SQL cannot process data
stored as BLOBs and therefore the data depends on the host application code, which
handles the data in BLOB format. This solution requires data transport from the
DBMS to middleware and consequently queries cannot be implemented optimally.
In recent times DBMSs have evolved towards an integrated architecture in which all
data is maintained in one object relational DBMS (figure 6.3, right). Presently, most
mainstream DBMSs support spatial data types and spatial functions by means of
ADTs. This architecture ensures an integrated and consistent set of data. Chapter 7
describes the state-of-the-art of geo-DBMSs in this new integrated GIS architecture.
6.7 Standardisation initiatives
Since the same geo-information is used by more and more people and applications,
interoperability of geo-information and geo-processes (together named geo-services)
has become a major issue in geo-sciences. With respect to interoperability, three
standardisation initiatives should be discussed and taken into account in this thesis,
i.e. OpenGIS, ISO TC/211 and CEN/TC 287.
113
Chapter 6. Theory of spatial data modelling
6.7.1 OpenGIS Consortium
The main mission of the OpenGIS consortium (OGC), founded in 1994, is to enable
interoperability of geo-services. Interoperability is the ability of digital systems to
1) freely exchange all kinds of spatial information and 2) cooperatively run software
capable of manipulating such information over networks [157]. The OGC Specification
and Interoperability Program provide an industry consensus process to plan,
develop, review and officially adopt OpenGIS Specifications for interfaces, encodings
and schemas that enable interoperable geo-services, data, and applications [157]. At
the moment more than 250 public and private organisations participate in OGC.
Among the members are TU Delft, the Netherlands’ Kadaster and ITC. An important
concept in the OGC model is a spatial (or geographical) feature, which is an
abstraction of a real world phenomenon associated with a location relative to the
earth [152] and a geometry. The basic spatial class of the geometries is ‘GM Object’
(figure 6.4).
Figure 6.4: UML class diagram of geometry basic classes with specialisation relations,
taken from [152].
OGC produces Abstract Specifications and Implementation Specifications [150]. The
aim of the Abstract Specifications is to create and document a conceptual model
sufficient to create the Implementation Specifications. The Implementation Specifications
translate the Abstract Specifications into common distributed computing
114
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 severalWeb 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.2 ISO 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.3 CEN/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 different 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.8 Conclusions
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 offer sufficient 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 different 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.1 Geometrical 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 differs slightly
from the ADTs as defined by OGC. The OGC Implementation Specification for
SQL defines separate data types for different 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.1 2D 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
CREATE TYPE sdo geometry
AS OBJECT (
SDO GTYPE NUMBER, type of the geometry (e.g. point,
linestring, polygon)
SDO SRID NUMBER, reference to the spatial
reference system
SDO POINT SDO POINT TYPE, specific entry for pints
SDO ELEM INFO MDSYS.SDO ELEM INFO ARRAY, indicates how the coordinate
array should be interpreted
SDO ORDINATES MDSYS.SDO ORDINATE ARRAY); list of coordinates
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 offset
1 in the coordinate list.
􀀀
􀀀
􀀀 @
@
@
􀀀
􀀀
@ 􀀀
@
@
(0,1)
(0,3)
(1,4) (2,4)
(3,3)
(3,1)
(1,0) (2,0)
SDO GEOMETRY Column =
(
SDO GTYPE = 2003
SDO SRID = NULL
SDO POINT = NULL
SDO ELEM INFO= (1,1003,1)
SDO ORDINATES =(1,0, 2,0, 3,1,
3,3, 2,4, 1,4, 0,3, 0,1, 1,0)
)
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.2 3D 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
7.1. Geometrical primitives in DBMSs
Most DBMSs (including Postgres, IBM, Ingres and Informix) support the storage of
points (0D), lines (1D) and polygons (2D) in 3D space as illustrated by this example,
but not of 3D volumetric data types. However, volumetric objects can be stored in
a geometrical primitive within current techniques using 3D polygons. 3D objects can
be represented as polyhedra (body with flat faces) in two ways: as a set of polygons
or as multipolygon (one object consisting of several polygons). To illustrate this, the
cube in figure 7.2 has been used.
Figure 7.2: Cube to be stored in the DBMS.
In the first option (defining a 3D object as a set of 3D polygons) two tables are used:
a table ‘BODY’ and a table ‘FACE’. In the table ‘BODY’ the 3D spatial object is
defined by a set of records representing a polyhedron with references to the (flat)
faces it consists of. In the table ‘FACE’ the actual geometries of faces are stored as
polygons in 3D space (sdo gtype: 3003, sdo elem info: (1,1003,1)). This structure is
partly a topological structure, since the body is defined by references to the faces and
the faces can be shared by neighbour-bodies. However, shared edges and nodes are
represented in every face they belong to, which leads to many redundant coordinates.
The generated tables for the cube are shown in table 7.1 (x1, y1, z1 refers to the x,
y and z-coordinate of point 1 in figure 7.2).
In the second representation (defining a 3D object as a multipolygon) a body is stored
as one record instead of a set of records. The multipolygon, which is also supported in
BODY
BID FID
1 1
1 2
1 3
1 4
1 5
1 6
FACE
FID sdo ordinate array
1 (lower face) x4,y4,z4, x3,y3,z3, x2,y2,z2, x1,y1,z1, x4,y4,z4
2 (side 1) x3,y3,z3, x4,y4,z4, x8,y8,z8, x7,y7,z7, x3,y3,z3
3 (side 2) x4,y4,z4, x1,y1,z1, x5,y5,z5, x8,y8,z8, x4,y4,z4
4 (side 3) x1,y1,z1, x2,y2,z2, x6,y6,z6, z5,y5,z5, x1,y1,z1
5 (side 4) x3,y3,z3, x2,y2,z2, x6,y6,z6, z7,y7,z7, x3,y3,z3
6 (upper face) x5,y5,z5, x6,y6,z6, x7,y7,z7, z8,y8,z8, x5,y5,z5
Table 7.1: Tables representing a 3D cube using a set of 3D faces.
125
Chapter 7. Geo-DBMSs
Oracle Spatial, is used for this representation (sdo gtype: 3007, sdo elem info: (starting
offset,1003,1)). This has also been implemented. The resulting table ‘BODY’, in
which the cube of the example is stored, is shown in table 7.2.
An advantage of 3D multipolygons (compared to a set of polygons) is that they
are identifiable as one object by front-end applications (GIS, CAD) that can access
objects stored in the DBMS. Another advantage of the 3D multipolygon approach
is the one-to-one correspondence between a record and an object. A disadvantage of
both representations is that the topological structure between objects cannot be used,
which implies risks for consistency as well as redundant storage of coordinates (and
in the 3D multipolygon solution also of faces). Also topology within one object is
not maintained. However, the main disadvantage of these implementations is that no
true 3D geometrical primitive (as volumetric data type) is supported by the DBMS
and therefore it is not recognised as such by the DBMS. In addition, functions on
0D, 1D and 2D primitives that are defined in 3D space project the primitives on a
2D plane (as will be illustrated in section 7.3.2).
These disadvantages can be overcome with the implementation of real 3D (volumetric)
data types. In [198] an extension of Oracle Spatial 9i is proposed with support of a
true 3D data type: the polyhedron primitive. This primitive has been implemented
in this research including the data model, validation functions and spatial functions
in 3D [5] (see section 7.4).
BODY table
Bodyid Geometry
1 SDO GEOMETRY(3007, – 3007 indicates a 3D multipolygon
NULL, NULL, SDO ELEM INFO ARRAY( – offset of
polygons is specified
1, 1003, 1,
16, 1003, 1,
31, 1003, 1,
46, 1003, 1,
61, 1003, 1,
76, 1003, 1
),
SDO ORDINATE ARRAY(
x4,y4,z4, ,x3,y3,z3, x2,y2,z2, x1,y1,z1, x4,y4,z4, –end of 1st
(lower) polygon
x3,y3,z3, ,x4,y4,z4, x8,y8,z8, x7,y7,z7, x3,y3,z3,
x4,y4,z4, ,x1,y1,z1, x5,y5,z5, x8,y8,z8, x4,y4,z4,
x1,y1,z1, ,x2,y2,z2, x6,y6,z6, z5,y5,z5, x1,y1,z1,
x3,y3,z3, ,x2,y2,z2, x6,y6,z6, z7,y7,z7, x3,y3,z3,
x5,y5,z5, ,x6,y6,z6, x7,y7,z7, z8,y8,z8, x5,y5,z5 – end of last
(upper) polygon
))
Table 7.2: Table representing a 3D cube using a 3D multipolygon.
126
7.2. Topological structure in DBMSs
7.2 Topological structure in DBMSs
Topological structures are generally used to represent planar or space partitions without
redundancy and to represent (linear) networks. In this thesis (on cadastral registrations)
the focus is on planar and space partition. Therefore linear networks will
not be further considered. In planar partitions (2D topological structures) and space
partitions (3D topological structures) spatial objects are defined on the basis of nonoverlapping
objects.
A large number of 2D topological structures are already available in literature, of
which some have been implemented in commercial [97] and user-defined systems [136]
and populated with data. Many 3D topological structures are also reported but only
a few of them have been tested for large data sets, e.g. [243].
In general, many questions related to topological structures in relation to DBMSs still
have to be resolved. How many and which primitives to store persistently? How many
and which relationships to store explicitly? Is it sufficient to maintain the relationships
to only low dimensional objects (edges and nodes in the case of polygons) or does the
relationships to high dimensional objects (co-boundary relationships, e.g. edges that
refer to their left and right polygon) also need to be maintained? In this respect, it is
likely that a data model appropriate for a certain application may fail to serve another
application. Thus a simultaneous maintenance of several topological structures in the
DBMS might be needed. In [144], organisation of many topological structures in the
DBMS is suggested by using a detailed description in a metadata table.
An extensive argumentation for the need to organise the topology support at DBMS
level is provided in [144]. As specified there, a topological structure at DBMS level
has many advantages:
• It avoids redundant storage (more compact than a full geometrical model).
• It is easier to maintain the consistency of the data after editing.
• It is more efficient during the visualisation in some types of front-ends, because
less data has to be read from disk and transferred to clients.
• It is the natural data model for certain applications; e.g. during surveying an
edge is collected (together with attributes to a boundary).
• It is more efficient for certain query operations (e.g. find neighbours).
An Implementation Specification for topological structures (complex features in OGC
terms) is currently being developed by the OpenGIS Consortium in cooperation with
ISO. A request for a proposal on this topic was issued in 2001 (and not updated since
then) [151]. The request aimed at extending the interfaces in the OpenGIS Simple
Features Implementation Specification. The new interfaces will build on the OpenGIS
Simple Features Specification to address feature collections and more complex objects
and concepts including curves and surfaces in 2D and 3D, compound geometries, arcs
and circle interpolations and topology. Note that GML is able to model complex
objects and 3D objects as defined in the OGC Abstract Specifications Topic 1.
In the current Implementation Specifications for Simple Features topological relationships
can be derived by spatial operations on geometrical primitives (see also
section 7.3.1).
127
Chapter 7. Geo-DBMSs
Relational DBMS has proven that it can efficiently store the topological references: a
face left and right of an edge, boundary to boundary references, treatment of islands,
etc., i.e. the modelling aspect of topology. The problem with a standard relational
DBMS, however, is that the declarative language SQL cannot handle the ‘navigational
access’ needed to obtain the geometry of a topological primitive. In SQL it is not
possible to express the statement: ‘follow the next references of the boundary until
we are back at the beginning’. This functionality has to be provided by embedded
queries using programming languages (able to ‘loop’ the data), e.g. PL/SQL (procedure
language of Oracle) or Java. This functionality is however already available
in every object oriented DBMS implemented within methods associated with classes.
Currently, few user-defined and commercial implementations of topological structure
in DBMSs exist using object relational technology. Also the next version of Oracle
Spatial (10g) will have some support for topological structure.
To illustrate possibilities of topological structure in current DBMSs, this section describes
a user-defined implementation of 2D topological structure (section 7.2.2) and
a commercial solution (Laser-Scan Radius Topology [97]) (section 7.2.3). Both implementations
represent a planar partition structure. First a description of planar
partition topology according to both OGC and ISO is given (section 7.2.1). Like the
3D geometrical primitive, 3D topological structure has not (yet) been implemented
as part of a DBMS. In section 7.1.2 a data structure was described in which the
faces of a 3D body are geometrically described in a face table. The body table in this
data structure contains references to the faces where the body consists of, but the
data structure does not contain references to edges and nodes. In this data structure,
bodies can share faces. Section 7.2.4 describes user-defined implementations of a full
3D topological structure.
7.2.1 OGC, ISO and planar partition topology
Spatial models defined by planar partitions are based on faces, edges and nodes.
Polygon is the geometrical equivalent of the topological primitive ‘face’. This section
describes how ISO and OGC define the feature ‘face’ and the geometrical equivalent
‘polygon’ in a planar partition topological structure.
ISO/TC 211
The ISO standard 19107 ‘Geographic information - Spatial schema’ defines geometrical
primitives for which the code starts with ‘GM’, and related topological primitives,
for which the code starts with ‘TP’. A TP FaceBoundary consists of one or more
TP Rings. One of these rings is distinguished as being exterior of the boundary.
Each ring is oriented so that the face is on its left, which means an anti-clockwise
orientation for outer rings and a clockwise orientation for inner rings. A TP Ring is
used to represent a single component of a TP FaceBoundary. It consists of a number
of TP DirectedEdges in a cycle. The endNode of a TP DirectedEdge is the startNode
of the next TP DirectedEdge. Since TP Rings are used in TP FaceBoundary objects,
the ring will be oriented so that the face is on its left.
According to the ISO/TC 211 standard a face is defined by edges and those edges are
anti-clockwise oriented in case of outer rings (and clockwise in case of inner rings):
128
7.2. Topological structure in DBMSs
-
6

?
6
-
?
Every edge has a reference to the preceding and succeeding edge. The associated
geometrical primitive of a face is ‘polygon’. From the specifications it is not clear
whether the outer boundary of a polygon is allowed to touch itself, nor is it clear if
inner rings can touch the outer boundaries or other inner rings [140]. However, since
only one outer boundary is allowed, a polygon with two outer boundaries (defining
potentially disconnected areas) is certainly invalid.
OGC specifications for SQL
The ISO definition of the topology of a face is at the abstract level. As was stated
before, the OpenGIS Consortium adopted the ISO Spatial Schema as Abstract Specifications
and transformed these to the implementation level in the OpenGIS Simple
Feature Specification for SQL.
Since the OpenGIS Specification for SQL does not define topology, we will have
a look at the geometrical primitive of a polygon according to this Implementation
Specification. A polygon is defined as a simple surface that is planar. A very precise
definition of the polygon is given in the OGC specifications. The main characteristics
from this definition relevant for the topology implementations described below is
that rings may touch each other in at most a point. However, since polygons are
built of LinearRings and since LinearRings are simple geometries, self-intersection of
outer and inner rings is not allowed [140]. Inner rings, which divide the polygon into
disconnected parts, are also not allowed. Note that the Simple Feature Specification
does not say anything concerning the orientation of polygons.
7.2.2 User-defined DBMS implementation of 2D topological
structure1
To explore the possibilities of using topology in spatial DBMS, a data set of cadastral
parcels was selected, provided by the Netherlands’ Kadaster. This data set is modelled
topologically in a relational DBMS, i.e. the geometry of the parcels is not stored
explicitly, but can be inferred from the cadastral boundaries that are stored [136].
The most important tables are ‘boundary’ (cadastral boundaries) and ‘parcel’ (parcel
identifiers). There is no need for the geometric data type ‘polygon’, because the area
features (parcels) are stored topologically in the ‘parcel’ and ‘boundary’ table using
the winged edge structure [7]. The edges in the boundary table contain references
to other edges according to the winged edge structure, which are used to form the
complete boundary chains (parcels). The edges in the winged edge structure also
1This section is based on [173].
129
Chapter 7. Geo-DBMSs
contain a reference to the left and right parcel.
According to [136] there are a number of reasons why the Netherlands’ Kadaster has
chosen to maintain parcels in a topology structure:
• The approach allows calculations on correctness of topology after updates.
• It opens the possibility to relate attributes to the boundaries between parcels,
e.g. date of survey, name of person locating the boundary, etc.
• If each parcel would be represented in the DBMS by a closed polygon, it would be
complicated to represent the basic object of cadastral surveying: one boundary
between two neighbour parcels.
• Closed polygon representation would lead to double (or triple or even more)
storage of all coordinates (except the territorial boundary), which complicates
data management in a substantial way.
• Closed polygon representation can result in the introduction of gaps and overlaps
between parcels, which is not related to reality.
A parcel has exactly one reference to one of the surrounding boundaries and one
reference to a boundary of each enclave. The structure of the topological references
and the relationship between parcels and boundaries are visualised in figure 7.3.
Figure 7.3: Topological structure in the spatial DBMS of the Netherlands’ Kadaster,
taken from [136].
The apparent disadvantage of storing spatial objects in a user-defined topological
structure in the DBMS is that the DBMS is not aware of the geometry of spatial
objects. Because there is no geometry attribute in the parcel table, it is for example
not possible to calculate the area of a parcel or use the geometry of a parcel in overlapfunctions.
By extending the DBMS with a function that materialises (realisation in
OCG terms) the geometry from the topological relationships it is possible to store
data topologically and still use the spatial operations offered by the DBMS built on
the geometrical model.
130
7.2. Topological structure in DBMSs
Therefore a function ‘return polygon’ has been implemented which realises the geometry
of a polygon. The implementation is done in Oracle Spatial 9i. In order to
get high performance and to avoid unnecessary conversions and data communication
between DBMS and client, the return polygon function must be performed within
the geo-DBMS itself. In Oracle Spatial 9i, this can be done by stored procedures or
functions which work within the database. The stored procedures and functions can
be written in PL/SQL and/or Java, both of them using SQL to access the data. With
the help of the spatial index, spatial clustering and an index on the id’s of objects
this should lead to good performance. The return polygon function can be used in
an SQL-statement, e.g. in a query to compute the area of a parcel:
SELECT sdo geom.sdo area(return polygon(object id), 1) FROM parcel;
The function to realise the geometry of polygons has been implemented in two ways.
The first solution uses only the information on the relationships between the preceding
and succeeding edges. The second solution is based on the left-right information of
edges. Both implementations will be described and compared in the next paragraphs
of this section.
A function-based spatial index is created on the face of the parcels in order to optimise
the performance. Since version 9i, Oracle has offered function-based indexes, i.e.
an index which is created on the return value of a function in addition to a normal
index created directly on the value of an attribute. A function based spatial index
facilitates queries that use locational information of type sdo geometry returned
by a function. The spatial index is created based on the pre-computed values returned
by the function. This is implemented in Oracle 9i in two steps. First, the
user sdo geom metadata table was updated (defining the lower and upper bounds
and tolerance in each dimension) to specify the function name:
INSERT INTO user_sdo_geom_metadata VALUES(
‘PARCEL’, ‘return_polygon(object_id)’, mdsys.sdo_dim_array (
mdsys.sdo_dim_element(‘X’, 82291, 84261, 0.0005),
mdsys.sdo_dim_element(‘Y’, 453039, 455632, 0.0005)), NULL);
The next step is to create a spatial index by specifying the function name and parameters.
For example, creating an R-tree index, is done with the following SQL-statement:
CREATE INDEX parcel_idx ON parcel(return_polygon(object_id))
INDEXTYPE IS mdsys.spatial_index;
Without a function-based spatial index it would not have been possible to properly
index the faces. During an overlap query or any other query using the spatial index,
objects are filtered by means of this index. That is, using the pre-computed bounding
boxes which are stored in the R-tree. Then the return polygon function is executed
to obtain the complete geometry of filtered objects to be used in the exact overlap
test. The return polygon function depends on the values in other tables. Therefore
when the index is built it contains the results of evaluating the function as at the
time of index build. If the function does not produce the same results next time it is
evaluated, the index search algorithm will give the wrong results. Therefore the index
needs to be rebuilt each time an update is done that affects the bounding box of any
131
Chapter 7. Geo-DBMSs
parcel. A trigger on the edge updates could probably do the job to also update the
appropriate index entries in the R-tree. However, this was not tested.
Realising geometry of polygons based on relationships between edges
The function return polygon based on the relationships between edges has been implemented
in PL/SQL. The function starts with the table ‘parcels’ and uses the
‘boundary’ table. The function creates a polygon geometry, of which the orientation
is valid according to the Oracle Spatial (and OGC) rules: the coordinates of the outer
ring are listed in anti-clockwise order and the coordinates of the enclaves are listed
in clockwise order. In the data set the winged edge structure is defined in both directions,
since every boundary contains a reference to its four connecting boundaries
(which is dissimilar to the ISO definition that only define references to the succeeding
and preceding edge).
The relevant attributes in the ‘parcel’ table used in the construction of polygons are:
• object id: the unique identifier of parcels;
• line id1: reference to one of the surrounding boundaries (stored in the boundary
table);
• line id2: reference to one of the boundaries of the first enclave (also stored in
the boundary table).
If there is more than one enclave the ‘parcelover’ table is used. The relevant attributes
in this table are:
• object id: the unique identifier of parcels;
• line id1: reference to one of the boundaries of the second enclave;
• line id2: reference to one of the boundaries of the third enclave;
• .......
• line id10: reference to one of the boundaries of the eleventh enclave.
These line id’s contain also references to a line in the boundary table. If a parcel
has more than eleven enclaves, the parcelover table has more than one entry for that
object id. Consequently the attribute ‘line id1’ in the parcelover table may refer to
the second, the twelfth, the twenty-second etc. enclave, the attribute ‘line id2’ may
refer to the third, the thirteenth, the twenty-third etc. enclave, etc.
The relevant attributes in the ‘boundary’ table in LKI are:
• object id: unique identifier of boundaries;
• geo polyline: geometry of the line;
• fl line id: reference to the first line on the left, seen from the middle point of
the line, looking back to the beginning;
• ll line id: reference to last line on the left, seen from the middle point of the
line, looking towards the end;
• fr line id: reference to the first line on the right, seen from the middle point of
the line, looking back to the beginning;
• lr line id: reference to last line on the right, seen from the middle point of the
line, looking towards the end;
132
7.2. Topological structure in DBMSs
• l parcel: parcel that is located at the left-hand side from the directed boundary
(when looking from the beginning to the end of the boundary);
• r parcel: parcel that is located at the right-hand side from the directed boundary
(when looking from the beginning to the end of the boundary).
Note that these references are different from those in figure 7.3. In figure 7.3 the
references at the start of the edge are ‘left’ or ‘right’ seen from the starting point of
the edge. In contrast, in the data set these references are ‘left’ or ‘right’ seen from
the middle point of the edge and therefore they are reversed (which is the Dutch
interpretation of the winged edge structure).
How the function works, will be illustrated with an example in which the polygon of
parcel 603 is realised (see figure 7.4). The attributes of line id1 and line id2 in the
parcel table are:
SELECT object id, parcel, line id1, line id2 FROM parcel WHERE parcel=603;
OBJECT_ID PARCEL LINE_ID1 LINE_ID2
---------- ------ ---------- ----------
310148953 603 310439663 0
Figure 7.4: Parcel 603 and 973 are used in the examples.
The parcel has one reference to its outer boundary (i.e. line id1) and no enclaves
(because line id2=0). The polygon of the parcel can now be constructed by starting
with the first boundary, with object id=310439663. The boundary table is queried
to look for the coordinates of this boundary and to look for the boundaries that
are connected to it in anti-clockwise direction. This step is repeated until the first
boundary is found again. To avoid a select statement having to be performed for every
next boundary, first all boundaries together with the relevant attributes, which have
parcel 603 on their right-hand or left-hand side, could have been selected (see figure 7.5
and the query below). However, the implementation of the function described here
only uses the ‘connect’ information, while the implementation as described in the next
session only uses the left-right information.
133
Chapter 7. Geo-DBMSs
SELECT object_id, fl_line_id, fr_line_id, ll_line_id, lr_line_id, l_parcel, r_parcel
FROM boundary WHERE l_parcel=603 OR r_parcel=603;
OBJECT_ID FL_LINE_ID FR_LINE_ID LL_LINE_ID LR_LINE_ID L_PAR R_PAR
---------- ---------- ---------- ---------- ---------- ----- -----
310547374 310419672 -310419673 310594168 310439663 973 603
310419672 -310419673 310547374 310518755 310419671 603 960
310518755 310419671 -310419672 -310439663 310439732 603 605
310439663 -310547374 310594168 310439732 -310518755 960 603
Figure 7.5: Id’s and direction of boundaries of parcel 603.
After having followed all edges of the outer ring the polygon can be constructed
by connecting all line strings of the resulting boundaries. In this process the line
strings, which are oriented in clockwise order (referred to with a minus), need to be
reversed. The polygon geometry is realised in such a way that the coordinates at
connection points are stored only once, and polygons are closed (first and last point
is repeated). The collected geometry information is returned as a spatial data type
of Oracle (polygon).
Now we will look at a polygon with enclaves: parcel 973 (see figure 7.4). As can be
seen from line id2, parcel 973 has at least one enclave, starting with the boundary
with object id 310376490 (line id2):
SELECT object_id, parcel, line_id1, line_id2 FROM parcel WHERE parcel=973;
OBJECT_ID PARCEL LINE_ID1 LINE_ID2
---------- ----- ---------- ----------
310152502 973 -310419676 310376490
The realisation of the outer boundary of the polygon is performed in the same way as
in the first example and will not be explained here. Parcel 973 contains one or more
enclaves (line id2 > 0). Therefore the rings of the enclaves need to be constructed in
clockwise direction according to ISO and Oracle rules. The first enclave starts with
the boundary with object id 310376490 (line id2). In principal we can follow the same
procedure as in the case of the outer boundary: create a list with all connecting arcs
(this time in clockwise order) to realise the geometry of the enclave.
134
7.2. Topological structure in DBMSs
The geometry of enclaves is constructed in the same way as the geometry of outer
boundaries: linestrings are connected, duplicate coordinates are removed, linestrings
in anti-clockwise direction are reversed and the polygon is closed. To see if this parcel
has more than one enclave the ‘parcelover’ table is checked:
SELECT * FROM parcelover WHERE object_id IN (SELECT object_id
FROM parcel WHERE parcel=973);
LINE_ID1 LINE_ID2 LINE_ID3 LINE_ID4 LINE_ID5 ........... LINE_ID10
---------- --------- --------- --------- -------- ----------
-310379237 -310205718 0 0 0 ........... 0
The result is two more enclaves. The enclaves are generated in the same way as
the first one. Again, the collected geometry information of enclaves together with
the geometry of the outer boundary is inserted in the spatial data type of Oracle to
create the polygon geometry of the parcel in Oracle.
Realising geometry of polygons based on left-right information
The alternative version of the ‘return polygon’ function uses only the left-right information
stored with every parcel boundary and a geometrical comparison to find and
join connected boundaries in a ring. Here the boundaries that have the given parcel
to the left or right are selected. By repeatedly joining boundaries that end in the
same endpoint, we end up with the boundary of the complete parcel. Enclaves are
realised in the same way. At the end of the procedure it has to be detected which of
the rings defines the outer boundary and which of the rings define enclaves.
The attributes in the ‘boundary’ table that are used by the algorithm are:
• geo polyline: geometry of the line;
• l parcel: parcel, located at the left-hand side from the directed boundary;
• r parcel: parcel, located at the right-hand side from the directed boundary.
The function has been implemented in the Java programming language and is integrated
in the database server. The function accesses the database tables via an
internal JDBC connection.
The first step is to retrieve all boundary lines that are part of the parcel:
SELECT geo polyline FROM boundary WHERE l parcel = 973 OR r parcel = 973;
This query results in a collection of LineStrings. What needs to be done now is to
glue these LineStrings together in such a way that they form an ordered collection of
rings. This is done using two data structures:
• Rings: In this variable we collect the completed LinearRings (LineStrings that
form a loop) that are formed during the algorithm.
• Graph: The graph structure contains all LineStrings that still need to be combined
to form loops. The graph contains vertices (nodes) and edges. The endpoints
of the LineStrings form the nodes of the graph. The edges in the graph
are formed by the LineStrings and run between two nodes, being the startpoint
and the endpoint of the LineString.
The algorithm first fills the graph structure and then tries to move all LineStrings
from the graph into the ring structure from which the result is constructed.
135
Chapter 7. Geo-DBMSs
// 1. Initialization.
for (all LineStrings that belong to the parcel boundary)
{
Insert the LineString into the graph.
}
// 2. Main Loop.
while (graph contains a node with two edges)
{
Delete the node and the two edges from the graph.
if (the two edges at the node are the same edge)
{
we have found a loop and add the edge to the rings.
}
else
{
glue the two LineStrings together to form one big LineString.
Insert the new LineString into the graph.
}
}
// Now the graph should be empty. If this is not the case, the input
// data was incorrect.
// 3. Construct Polygon from rings.
Find the ring which encloses the largest area.
This is the outer boundary assuming that the input data is correct.
The rest of the rings are enclaves.
Construct a polygon using the boundary and the enclaves.
Calculate the orientation and return the polygon as Oracle’s spatial data type.
Discussion on self-implemented return polygon function
The performance of both implementations is of course dependent on the complexity
of the data: the more points in a boundary, the worse the performance, also the more
boundaries in a polygon the worse performance. Also the following of pointers as in
the implementation based on the relationships between edges is not very compatible
with the relational model, since it leads to “row at a time” processing. This also
causes response time issues with increasing boundaries in a polygon. To test these
statements we did some tests of which one of the results is shown in figure 7.6.
On the x-axis of this figure the number of points in the resulting polygon are shown,
on the y-axis the construction time per polygon in seconds. For both implementations
the trend is visible of increasing construction time when the number of points in
the resulting polygon increases. This trend is more apparent in the left-right implementation.
Probably this is due to the fact that in the left-right implementation the
boundaries are connected by finding common points. In this process computational
costs increase with the number of points. Since the left-right method has been implemented
in Java and the method based on relationships between edges in PL/SQL
the performance of both methods cannot be compared. Apart from performance, the
implementations differ in the underlying geometrical primitive. In the relationshipsbetween-
edges implementation, the outer ring of a face can touch itself on the outer
boundary at exactly one point, and in the left-right implementation this is not possible.
This difference can be illustrated by the polygon shown in figure 7.7: a polygon
that has an island that touches the boundary at exactly one point. The relationships-
136
7.2. Topological structure in DBMSs
Figure 7.6: Construction time per polygon for different number of points in the resulting
polygon. The black line represents the implementation based on the relationships
between edges and the grey line represents the left-right implementation.
between-edges algorithm will generate a polygon with one self-touching outer ring,
while the left-right algorithm will return a polygon with a boundary and an island.
As was described in section 7.2.1, a self-touching boundary is not allowed according
to the OpenGIS Specification for SQL and not valid according to Oracle (rings may
only touch other rings). Therefore the relationships-between-edges method returns a
non-valid geometry according to OGC and Oracle rules. Post-processing invalid polygons
is possible, but requires so much geometrical and topological calculation that it
is easier to use the left-right topology. From this it can be concluded that the winged
edge structure as implemented in the cadastral data set is not OGC compliant, but
also the OGC standard might need to be refined.
Figure 7.7: A polygon with a hole that touches the boundary.
137
Chapter 7. Geo-DBMSs
7.2.3 Commercial DBMS implementation of 2D topological
structure
Compared to user-implemented models, the implementation of topology structure in
Laser-Scan Radius Topology [97], which is based on Oracle Spatial, is much more
developed. It is a ‘complete’ implementation of topology with support for linear
networks and planar topology, including updates, insertions and deletions.
To retrieve geometry from a topologically structured data set, Radius offers a function
‘get geom’ that is equivalent to the ‘return polygon’ function of our own implementations.
Most users however choose not to use this function, but instead store a copy
of the geometry explicitly. This increases the storage requirements, but it means
that there is no performance penalty when accessing geometries (e.g. for display or
geometric queries) since the geometry is instantly available and does not have to be
computed. The use of database triggers in the Radius Topology architecture ensures
that the geometries and their topological representation are always synchronised.
Additionally support for topological querying (containment, adjacency, connectivity,
overlap) is available in Radius Topology by means of a topo relate operator.
All required topological references are stored explicitly: the winged edge representation
(in the edge-to-edge table) makes up just a small part of the complete system
(see figure 7.8). Topological primitives are stored in the NODE, EDGE and FACE
tables while faces are only stored by references to edges. A number of reference tables
are used to store various types of topological references. The TOPO table is the
link between the features and the topological structures. Topology is organised in
‘manifolds’. Associated with each manifold and with the system as a whole are some
metadata and error tables. Before topologically structuring data in Radius Topology,
the user can specify rules in order to control the way the structuring works (snap
tolerances, which features/primitives are moved and which stay while snapping, etc).
In [108] a performance test is described in which the topological structure of Laser-
Scan Radius Topology (version 1.0) was compared to the geometrical primitive of
Oracle Spatial 9i. In the topology case less points are stored (by avoiding storing
‘common’ boundaries twice). However disk space requirements are much bigger in
the topological case due to the increased number of topological primitives and the
references between them compared to the number of area features (and the way geometry
is implemented in Oracle Spatial: small objects have relatively much overhead).
The total storage requirement for topology is intended for references, id’s and associated
indexes that are required for the Radius Topology structure. The storage
requirement will probably be more favourable for topology in the case of smaller scale
data and data with a relatively high number of intermediate points in the boundaries.
From the tests described in [108] it can be concluded that performance of geometrical
querying on a data set structured with Radius Topology is slower. This is due to the
cost of computing the geometries on-the-fly from the topological information. This
occurs when geometries are not stored explicitly alongside the topology. For this
reason users often store the geometries explicitly as described above.
138
7.2. Topological structure in DBMSs
Figure 7.8: Radius Topology database tables (version 1.0), taken from [98].
7.2.4 User-defined DBMS implementation of 3D topological
structure
In 3D, there is yet no consensus on a single topological structure. Different topological
structures can be defined depending on the number of primitives to maintain,
and also the number and nature of relationships to explicitly store. The problems
of defining 3D topological structures are relatively many compared to 2D. Due to
the large amounts of data and higher complexity, one data structure representing a
specific topological structure, which is appropriate for a certain application, may not
be easy to serve another application. Unfortunately, 2D topological structures are not
directly extendable to 3D. 2D structures are mostly built around the properties of
an edge. One edge has exactly two neighbouring nodes (begin and end) and exactly
two neighbouring faces (left and right). This property is not true in 3D space. An
edge can have more than two neighbouring faces, i.e. the order of the faces has to be
specified.
Since the 3D topological structure of Zlatanova [240] is one of the few implementations
of a topological structure defining volumetric objects, and since the implementations
showed good results [30, 244], we had a closer look at this model. The Simplified
Spatial Model (SSM) is a typical boundary representation. The role of the edge
139
Chapter 7. Geo-DBMSs
(=boundary) in 2D is now the role of the face (=boundary) in 3D. Nodes describe
faces, faces describe bodies. The 1D primitive as part of a body (edge), is not explicitly
stored in the model (see figure 7.9). Shared faces and nodes are only stored once.
This 3D topological structure is described in detail in [240].
Figure 7.9: UML class diagram of Simplified Spatial Model [240].
This 3D topological structure can be implemented in several ways in an object relational
DBMS. The first approach is the relational implementation. The conceptual
model can be converted directly into a relational data model. For each object (node,
face, and body) a separate relational table is created. The NODE table contains the
id of the node and the three coordinates of the points. The FACE table contains the
id of the face, a column denoting the order (anti-clockwise) of the nodes in a face
and the id’s of nodes that the face consists of. A BODY table contains references to
the id’s of faces it consists of. Since the relationship between a face and constituting
nodes (and between a body and constituting faces) is one-to-many, multiple rows (or
columns) represent one face (and one body) in a traditional relational implementation
using only plane relational tables and traditional data types. In the multiple-column
representation the number of columns is fixed and a high number of columns has to
be chosen in order to be able to represent also faces with a large number of nodes
and bodies with a large number of faces. This leads to a table with large amounts of
zero fields and consequently to overhead of information. Multiple-row representation
is therefore preferred. The same is true for the relationship between body and faces.
Another possibility is the object relational implementation. The list of id’s referring
to lower dimensional objects (faces, nodes) is stored in a single column. This means
that the number of rows in the object table is reduced to the actual number of the
higher dimensional object (body, face). Object relational implementation is a twostep
procedure, i.e. creating objects (ADTs) and creating tables. The object relational
implementation of 3D topological structure is illustrated with Oracle Spatial 9i. Two
extended Oracle data types are used, which are intended for representing the one-tomany
relationship, i.e. varrays (variable arrays) and nested tables. The syntax of the
commands to create a data type of type varray is:
CREATE TYPE NodeArray AS varray (10000) OF number (5);
Utilising the newly created data type NodeArray, the FACE object can be stored in
the database in the following way:
CREATE TABLE face
(fid NUMBER(11) NOT NULL, num NUMBER(11) NOT NULL, nids NodeArray NOT NULL);
140
7.3. Spatial analyses in DBMSs
The other method to represent one-to-many relationships using only one column is
nested tables. The commands to create a data type of type table and to use this new
data type in the FACE object are:
CREATE TYPE NodeTable AS table OF number(5);
CREATE TABLE FACE (
FID number(11) not null,
NUM number(11) not null,
NIDS NodeTable not null);
As can be concluded from [244], the nested table shows slower performance than
the tables with varrays. This is probably due to the fact that nested tables are less
efficient then varrays because more overhead is produced during the implementation.
To be able to use the spatial operations of the DBMS on topologically structured
data, a realisation function was written. This function realises the geometry of the
3D spatial objects, based on the topological tables. The function is based on the
relational implementation. In the function the nodes of one 3D spatial object are
retrieved by the following query:
/* 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.fid=face.fid AND face.nid=node.nid AND body.bid=1;
After this, the obtained nodes are translated to either a complex geometrical object
of 3D polygons, a 3D multipolygon (see section 7.1.2), or a polyhedron primitive (see
section 7.4).
7.3 Spatial analyses in DBMSs
Spatial analyses in the context of a DBMS are related to operations that are performed
on spatial objects (in vector-format) in which often no distinction is made between the
spatial and thematic components of spatial objects. In this section we will concentrate
on the part of spatial analyses that is only related to the spatial component.
The Abstract Specifications of OGC distinguish between two sets of operations (also
called operators or functions) defined for both geometrical and topological primitives
while some of them are identical. The operations can be classified as unary
(performed on one object) and binary (performed on two objects). For example,
fifteen unary (mbRegion, representativePoint, boundary, closure, isSimple, isCycle,
distance, dimension, coordinateDimension, maximalComplex, transform, envelope,
centroid, convex hull, buffer) and seven binary relations (contains, intersects, equals,
union, intersection, difference, symmetricDifference) are suggested within the geometry
schema. Within the topology schema the unary operations are seven (dimension,
boundary, coBoundary, interior, exterior, closure, maximalComplex). The binary operations
for the topology schema can be a different number depending on the used
formalism for detecting relationships. Three frameworks are accepted as fundamental:
Boolean set of operations (considering intersections between closure and exterior),
141
Chapter 7. Geo-DBMSs
Egenhofer operations (taking into account exterior, interior and boundary of objects)
[49] and Clementini operations using the same topological primitives as Egenhofer
but considering the dimension of the intersection [24]. It should be noticed that
the Abstract Specifications do not discuss implementation environments. The current
Implementation Specification for SQL [148] specifies eight relationships based
on the Egenhofer framework, i.e. equals, disjoint, intersects, touches, crosses, within,
contains and overlaps, which are only defined for Simple Features, i.e. geometry.
In this section spatial analyses in DBMS are considered, distinguishing between spatial
analyses on geometrical primitives (2D in section 7.3.1 and 3D in section 7.3.2) and
spatial analyses on a topological structure (section 7.3.3). In section 7.3.4 a case
study is described which compares the same spatial analysis (using the same test
area) performed on geometrical primitives on the one hand and on a topological
structure on the other hand.
7.3.1 2D spatial analyses using geometrical primitives
The OGC Simple Feature Specification for SQL [148] describes geometrical and topological
functions that should be supported at DBMS level as part of the implementation
of the geometrical primitive. The defined operations to obtain the topological relationships
do not give the dimensionality of the relationship as a result. For example
the query ‘Find all adjacent parcels to a query parcel’ (using the touch relationship),
gives all parcels that touch with the query parcel as a result regardless the dimensionality
(touch at edge or point). To restrict the result data set to only parcels that
touch at an edge, the query should be extended with the condition that boundaries
of two parcels should also overlap. Overlap results ‘true’ if the intersection results in
geometry of the same dimension as the input geometries.
In Ingres the support for topological relationships is minimal. Oracle, IBM DB2,
Informix and PostGIS support geometrical and topological functions defined by OGC
and often more functions than these as reported in [139].
Oracle Spatial 9i is used to illustrate the possibilities of spatial analysis using the
geometrical primitive in DBMSs. Currently, Oracle Spatial supports three groups of
selection operations, i.e. topological relationship operations, metric operations and
specialisation operations.
Topological relationship operators between two geometries are implemented with respect
to the nine-intersection model of Egenhofer [49]. The names of the operations
slightly differ from the ones suggested by OGC. In Oracle Spatial 9i all these topological
relationships are implemented using one function (sdo geom.relate) or operator
(sdo relate), where the type of relationship is passed as a text string (table 7.3, left).
The spatial operator requires and utilises a spatial index and is therefore faster than
the spatial function, which also work without a spatial index.
In the Egenhofer model each spatial object has an interior, a boundary, and an exterior.
The boundary consists of points or lines that separate the interior from the
exterior. The boundary of a line consists of its end points. The boundary of a polygon
is the line that describes its perimeter. The interior consists of points that are in the
object but not on its boundary, and the exterior consists of those points that are not
142
7.3. Spatial analyses in DBMSs
Topological operations
OGC Oracle
equals equal
disjoint disjoint
intersects anyinteract
touches touch
crosses overlapbdydisjoint
within inside
contains contains
overlaps overlapbdyintersect
coveredby
covers
on
Metric and specialisation operations
OGC Oracle
Unary metric operations
Area sdo area
Length sdo length
Unary specialisation operations
Buffer sdo buffer
Convexhull sdo convexhull
Centroid sdo geomcentroid
Boundary sdo mbr
Binary metric operations
Distance sdo distance
Binary specialisation operations
Intersection sdo intersection
Union sdo union
Difference sdo difference
Symdifference sdo xor
Table 7.3: Topological, metric and specialisation operations in the DBMS according
to Implementation Specifications of OGC and the Oracle Spatial implementations.
in the object. Some of the topological relationships of the 9-intersection model have
names associated with them that specify the type of relationship, e.g. INSIDE and
COVEREDBY. INSIDE returns true if the first object is entirely within the second
object and the object boundaries do not touch, otherwise, it returns false. COVEREDBY
returns true if the first object is entirely within the second object and the
object boundaries touch at one or more points, otherwise it returns false.
Besides the relationship operations, many metric and specialisation operations are
proposed by OGC that can take one (unary operations) or two geometries (binary
operations), or other parameters (e.g. buffer size) and calculate some values or new
geometries. The most important of them together with their Oracle equivalents are
given in table 7.3, right. An example is when one wants to obtain a new geometry that
is the intersection between the geometry of parcels and the geometry of the extent of
a tunnel. The query to create these new geometries is the following (to speed up this
query a ‘where’ clause could be added using ‘anyinteract’) :
CREATE TABLE new_geometry AS
SELECT t.object_id, p.parcel_number,sdo_geom.sdo_intersection(t.shape, p.shape,1) shape
FROM parcel p, tunnel t;
Another class of spatial operations in Oracle Spatial returns an aggregate of a collection
of geometries. These are not defined within OGC (see table 7.4).
143
Chapter 7. Geo-DBMSs
SDO AGGR CENTROID Returns a geometry object that is the centroid
(“center of gravity”) of the specified geometry
objects
SDO AGGR CONVEXHULL Returns a geometry object that is the convex
hull of the specified geometry objects
SDO AGGR MBR Returns the minimum bounding rectangle of
the specified geometry objects
SDO AGGR UNION Returns a geometry object that is the topological
union (OR operation) of the specified
geometry objects
Table 7.4: Examples of aggregate functions in Oracle Spatial 9i.
7.3.2 3D spatial analyses using geometrical primitives
Our experiments showed that it is possible to maintain objects with 3D coordinates
in Oracle Spatial 9i (see section 7.1.1). However, the current implementations of
geometry operators (e.g. compute area of 3D polygon) in Oracle Spatial 9i omit the
z-value.
In the following example, a table (geom) is created in Oracle Spatial 9i in which a 2D
polygon and a polygon defined in 3D space are inserted. After that, the geometrical
operators area and length (perimeter) are performed on both polygons. The operator
‘validate’ is performed to show that the polygons are both valid. As can be seen in
the results of the queries, sdo area and sdo length (both spatial operators in Oracle)
return the same value for both polygons, although the 3D polygon actually has a
greater area and length (perimeter). In these calculations, the 3D polygon is projected
on the surface.
/* 66: a 2D polygon */
INSERT INTO geom (shape,tag) VALUES (mdsys.sdo_geometry(2003, NULL, NULL,
mdsys.sdo_elem_info_array(1, 1003, 1),
mdsys.sdo_ordinate_array(12,15, 15,15, 15,24, 12,24, 12,15)), 66);
/* 88: a 3D polygon */
INSERT INTO geom (shape,TAG) VALUES (mdsys.sdo_geometry(3003, NULL, NULL,
mdsys.sdo_elem_info_array(1, 1003, 1),
mdsys.sdo_ordinate_array(12,15,0, 15,15,0, 15,24,999, 12,24,999, 12,15,0)), 88);
SELECT tag,
sdo_geom.sdo_area(shape, 1) area,
sdo_geom.sdo_length(shape, 1) length
sdo_geom.validate_geometry(shape, 1) geom_validate
FROM geom;
TAG AREA LENGTH GEOM_VALIDATE
--- ---- ------ -------------
66 27 24 TRUE
88 27 24 TRUE
Many other DBMSs support a similar set of geometry operators as most of them
also skip the z coordinate. Some exceptions are PostGIS (PostgreSQL) [171] and
144
7.3. Spatial analyses in DBMSs
the MapInfo Spatialware Datablade [113] (based on Informix) that do have limited
support for geometry calculation in 3D, such as length and perimeter in 3D. This is
illustrated in the next PostGIS example.
First, four tables are created: line2D, line3D, polygon2D and polygon3D in which
respectively a 2D line, a 3D line, a 2D polygon and a 3D polygon are inserted (’\g’
in PostGIS is used to end a command):
/* a table with a 2D line */
CREATE TABLE line2d (id int4)\g
SELECT addgeometrycolumn(‘test’,‘line2d’,‘shape’,0,‘LINESTRING’,2)\g
INSERT INTO line2d (id, shape) VALUES(1,
geometryfromtext(‘LINESTRING(1 1,2 2)’,0))\g
/* a table with a 3D line */
CREATE TABLE line3d (id int4)\g
SELECT addgeometrycolumn(‘test’,‘line3d’,‘shape’,0,‘LINESTRING’,2)\g
INSERT INTO line3d (id, shape) VALUES(1,
geometryfromtext(‘LINESTRING(1 1 0,2 2 50)’,0))\g
/* a table with a 2D polygon */
CREATE TABLE polygon2d (id int4)\g
SELECT addgeometrycolumn(‘test’,‘polygon2d’,‘shape’,0,‘POLYGON’,2)\g
INSERT INTO polygon2d (id, shape) VALUES(1,
geometryfromtext(‘POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))’,0))\g
/* a table with a 3D polygon */
CREATE TABLE polygon3d (id int4)\g
SELECT addgeometrycolumn(‘test’,‘polygon3d’,‘shape’, 0,‘POLYGON’,3)\g
INSERT INTO polygon3d (id, shape) VALUES(1,
geometryfromtext(‘POLYGON((0 0 0, 1 0 0, 1 1 100, 0 1 100, 0 0 0))’,0))\g
In the next step the following queries are executed:
SELECT length(shape) FROM line2d\g
SELECT length3d(shape) FROM line3d\g
SELECT perimeter(shape) FROM polygon2d\g
SELECT perimeter3d(shape) FROM polygon3d\g
As the results show, length and perimeter do work in 3D:
length 1.4142135623731 (1 row)
length3d 50.0199960015992 (1 row)
perimeter 4 (1 row)
perimeter3d 202.009999750012 (1 row)
The other functions (overlap, area, distance) in PostGIS (and also in the SpatialWare
Datablade of MapInfo) are performed in 2D. PostGIS also has a box3D function that
gives the maximum extents in 3D as result.
7.3.3 Spatial analyses using the topological structure
Some spatial operations are specific to topological structure, for example validation
functions on topological structure (e.g. is loop closed?) and network computation
145
Chapter 7. Geo-DBMSs
(e.g. find shortest path). Another spatial operation specific to topological structure
is realisation of geometry, which is the basis for nearly all metric operations and
needed for visualisation of the objects. The complexity of the realisation functions
considerably varies with respect to the different implementations of the topological
structure. For example the geometry (coordinates) of a body can be extracted by
only one SQL statement (in case of relational implementation) if the geometry is
maintained explicitly, but a PL/SQL script is required if the body is represented as
a variable array of id’s of faces and the coordinates are only stored at node level.
Although not yet very common, spatial analysis on topological structure is available
in some DBMS software (e.g. Laser-Scan Radius, Oracle Spatial 10g) but the support
is still limited. A lack of native topology support of DBMS is compensated by many
user-defined implementations of topological structure. Each implementation has its
own set of topological operations available with the model. It depends on the topological
structure and thus on the relationships defined in the topological structure
which topological operations are available. For example if a topological structure of
planar partition is implemented with only information on connecting edges, without
information on the left and right face of an edge, an adjacent analysis (give all polygons
adjacent to this polygon) cannot be performed on the topologically structured
data. Therefore, first the geometries of polygons have to be realised and the analysis
has to be performed on the geometrical primitive.
We have developed several functions to realise geometry (PL/SQL and Java) related
to two different topological structures, i.e. winged edge (in 2D, section 7.2.2), and SSM
(in 3D, section 7.2.4). Both topological structures were user-defined implementations
in a object relational DBMS. As can be concluded from the experiments with the
realisation functions, the required realisation of geometry requires traverse of all the
relational tables, which may result in poor performance of metric analyses for large
data sets.
7.3.4 Case study: topological structure or geometrical primitives?
As has already been mentioned a number of times before, it can be expected that spatial
queries relying only on topological references perform very well on the topological
structure compared to the geometrical primitive, e.g. to find all features that are adjacent
to a certain feature. In contrast, the performance of metric and specialisation
operations will be slower on the topological structure. These last operations need the
coordinates of the objects, which, if performed on the topological structure, will most
initiate a join of all the relational tables (dependent on the type of implementation).
In [77] it is also concluded that some operations (compute area, distance, etc.) on
topological structured data will be slower than on geometrical primitives since it requires
querying and joining different relational tables. Another explanation for the
better performance of these spatial operations on the geometrical primitives is the
internal optimisations provided by the DBMSs and the possibility to apply spatial
indexes.
To illustrate the power of topological structure in performing relationship operations,
146
7.3. Spatial analyses in DBMSs
an experiment was carried out in Oracle Spatial 9i on a data set, which is a selection
of the cadastral database of the Netherlands. The test data set contains 1,788,019
parcels and 5,599,089 boundaries. The first query that we use in this experiment is to
find all adjacent parcels to the parcel with object identifier 6862 (see figure 7.10). The
query was performed on both a topologically structured data set and a geometrically
structured data set. The geometries of the parcels were therefore stored explicitly
in a table with the geometrical primitive of Oracle Spatial and populated with the
return polygon function (section 7.2.2). A spatial index was built on the geometrycolumn
to speed up spatial analyses. The topological structured data set was described
in section 7.2.2. Note that performance depends also on spatial clustering,
which was not taken into account in this test. For the data set described by geometrical
primitives, the query to find all adjacent parcels is given below (using a ‘subselect’
structure), in which the polygons of parcels are stored in the table ‘parcels geom’ in
the column named ‘shape’. The query finds all parcels that have a ‘touch’ relationship
with parcel ‘6862’ using the spatial operator ‘sdo relate’ which is implemented
on geometrical primitives.
SELECT object_id FROM parcels_geom WHERE sdo_relate(shape,(SELECT shape
FROM parcels_geom WHERE object_id=6862), ‘MASK=TOUCH, QUERYTYPE=WINDOW’) = ‘TRUE’;
The query returned the following result:
OBJECT_ID
----------
7142
2067
2066
7141
2065
6862
6861
Elapsed: 00:00:22.05
For this query we use Oracle’s spatial operator since spatial operators use the spatial
index in contrast to the spatial functions in Oracle (see section 7.3.1). The query plan
of the query was checked to verify that the query indeed used the spatial index. As
shown in the result, the time needed to perform the geometrical query is about 22
seconds.
In the topologically structured data set, all adjacent parcels to parcel ‘6862’ can be
found when all the boundaries are selected which have the specific parcel on the left
or right side. The next step is to find the parcel that is located on the other side of
the selected boundaries. The result is 0.01 seconds:
SELECT l_obj\id, r_obj_id FROM boundary WHERE r_obj_id=6862 OR l_obj_id=6862;
L_OBJ_ID R_OBJ_ID
---- -----
2066 6862
6862 7141
6861 6862
6862 7142
Elapsed: 00:00:00.01
147
Chapter 7. Geo-DBMSs
Figure 7.10: Query parcels (6862 and 7142) used in test queries.
The same test was performed for parcel ‘7142’ (with 28 adjacent parcels). The processing
time for this second query was 22.56 seconds for the geometrical query and
00.01 seconds for the topological query. The queries were repeated a number of times
which resulted in processing times of the same order, every time. These examples
show that this topological query is indeed faster on a topologically structured data
set than on the data set described with geometrical primitives.
There is another conclusion that can be drawn from the first query: the results differ.
The topological query does not give parcels ‘2067’ and ‘2065’ as a result since these
parcels touch parcel ‘6862’ only at a point and are therefore not seen as adjacent
parcels from the topological point of view as defined in the winged edge structure.
The result set in spatial analyses using topological structure depends therefore on the
topological structure implemented.
The geometrical query does find parcels ‘2067’ (neighbour on the right of parcel
‘2066’) and ‘2065’ as adjacent parcels since they do touch parcel ‘6862’, even if it is
at a point. The geometrical query could be further specified by adding the condition
that boundaries of two parcels should also overlap (see section 7.3.1). It is a moot
point which of these results is ‘correct’. Some applications will require the ‘corner
contact’ parcels to be returned as well, and other applications don’t.
7.4 Implementation of a 3D geometrical primitive
in a DBMS1
Present geo-DBMSs do not support 3D geometrical primitives, although 3D objects
can be modelled within current techniques as was seen in section 7.1.2. The absence
of a real 3D primitive in geo-DBMSs, results in two main problems:
• Geo-DBMSs do not recognise 3D spatial objects, because they do not have a 3D
primitive to model the 3D object. This results in DBMS functions not working
properly (e.g. there is no validation for the 3D object as a whole and functions
1This section is based on [5].
148
7.4. Implementation of a 3D geometrical primitive in a DBMS
only work with the projection of these objects, because the third dimension is
ignored).
• Where 3D objects are stored as one multipolygon or a set of polygons, no relationship
exists between the different 2D polygons defining the object. Besides
the fact that no validation can be performed and that any set of polygons can
be inserted, the main disadvantage is that the same coordinates are listed multiple
times (causing risks of inconsistencies) and there is no information about
outer or inner boundaries of the polyhedron. Where 2D polygons that bound a
3D object are stored in multiple records, a 1:n relationship exists between the
object and the number of records; a more clear and more efficient administration
of large data sets requires a 1:1 relationship between objects in reality and
objects in the database.
ISO/TC211 spatial schema [87] adopted by OGC defines 3D geometry primitives
in an abstract (mathematical) manner. However 3D geometrical primitives are not
(yet) included in the OGC Implementation Specification for SQL. In order to fill this
gap we worked on a solution in the form of a design and an implementation of a
real 3D primitive within a DBMS context. This section presents this solution and
describes how 3D spatial objects can be modelled, i.e. stored, validated and queried in
a geo-DBMS using a 3D geometrical primitive (also using 3D spatial functions). Many
concepts have been developed in the area of 3D modelling [94, 119, 168, 169, 184, 240].
In the research presented here the developed concepts have been translated into a
prototype implementation of a true 3D primitive in a DBMS environment. The
implementation has been based on a proposal for extending the spatial model of
Oracle Spatial 9i with support for a 3D primitive [198].
7.4.1 Definition of 3D primitive
There are a number of 3D geometrical primitives possible to model 3D spatial objects:
• A set of tetrahedra: This is the simplest 3D primitive and consists of four
triangles that form a closed object in 3D coordinate space. The tetrahedron
is well defined, because the three points of the four triangles always lie in the
same plane. It is relatively easy to create functions that work on this primitive.
The disadvantage is that it could take many tetrahedra to construct one factual
object; this does not solve the disadvantage of not having a 1:1 relationship
between the factual object and the object’s representation in the database.
• Polyhedron: This is the equivalent of a polygon, but in 3D. It is made up by
several flat faces that enclose a volume. An advantage is that one polyhedron
equals one factual object. Because a polyhedron can have holes in the exterior
and interior boundary, it can model many types of objects. A disadvantage is
that the buffer operation results into a non-polyhedral object, because it will
contain spherical or cylindrical patches, which cannot be represented by the
polyhedron primitive. The solution is to approximate the result of the buffer
operation [224].
• Polyhedron combined with spherical and cylindrical patches: This is
the equivalent of the current 2D geometry data model of most geo-DBMSs
149
Chapter 7. Geo-DBMSs
(i.e. straight lines and circular arcs). This solution makes it possible to model
3D objects more realistically (although it is also not closed under the buffer
operation). However, modelling with this primitive is complex.
• CAD objects: There are many possibilities [120], such as Constructive Solid
Geometry, cell decomposition, octree [19] and objects with curved faces. These
objects either do not fit with the present OpenGIS/ISO 2D geometry data model
or are complex to model without an advanced graphical user interface.
To choose a suitable 3D primitive, a number of criteria were evaluated [2]. The
implementation should lead to valid objects. It should be easy to specify instances
and to create and enable efficient algorithms. Furthermore, the size and redundancy
of storage (conciseness) should be taken in consideration.
The tetrahedron was not selected, because there are several primitives necessary to
model one object. CAD objects with curved faces can model a spatial object very
realistically, but are complex to model without an advanced graphical user interface
and also 2D CAD objects do not (always) fit within the present 2D geometry data
model. That leaves the polyhedron option with and without the cylindrical/spherical
patches. The one with spherical and cylindrical patches would fit better to the present
2D geometry data model (in which geometry is not only defined by straight lines but
also by circular arcs), but ease of creation and implementation favour the polyhedron
without spherical and cylindrical patches at first. Therefore, the polyhedron is chosen
as the 3D primitive in this research to start with. If needed, spherical and cylindrical
patches are approximated by several flat faces. It was also expected that choosing a
relatively simple primitive will give more insight into the problems that occur when
implementing more complex primitives in the future.
Implementation
The 3D primitive has been implemented in a geometrical model with internal topology
(i.e. topology is maintained within one instance of the object and not between objects).
Managing topological structures between objects (e.g. sharing common faces) is not
within the scope of the polyhedron primitive. The polyhedron is defined by storing
the vertices explicitly (x,y,z) and describing the arrangement of these vertices in the
faces of the polyhedron. Internal topology within one object is maintained since only
the vertices are stored (no polygons or lines). Faces are defined by internal references
to nodes and nodes are shared between faces (figure 7.11). This yields a hierarchical
boundary representation [2, 240]. Note that edges are not stored explicitly in this
model. The Oracle Spatial geometry type has been extended in order to support the
polyhedron primitive. The vertices and arrangement of faces are all stored in the
sdo ordinate array.
The interpretation code of the faces (figure 7.11) describes if the list of node references
refers to an outer or inner boundary of a polyhedron (face) or if the list of node
references refers to an outer or inner ring of a(n outer or inner) face. Most polyhedra
will just have an outer boundary, but an inner boundary can for example be used to
create a hollow object: the inner boundary will then describe this hollow space. Most
faces will just have an outer ring, but inner rings can be used to create cavities in
polyhedron. With these elements it is possible to model complex objects, e.g. objects
with cavities or objects that are hollow inside. This set of elements is enough for the
150
7.4. Implementation of a 3D geometrical primitive in a DBMS
Figure 7.11: UML class diagram describing storage of polyhedron primitive.
implemented functions in the next sections to understand what the 3D spatial objects
look like.
In the field of computer graphics (see for example [129]) it is a custom to order all
the vertices of outer boundaries (rings) anti-clockwise, seen from the outside of an
object, and the vertices of inner boundaries (rings) clockwise. That is, the normal
vector of the face points to the outside of the object. This practice is followed in the
implementation (details and examples in [4]). A table can now be created to hold
polyhedra:
CREATE TABLE polyhedron table (id NUMBER, geometry MDSYS.SDO GEOMETRY);
Then the metadata table can be updated:
INSERT INTO user_sdo_geom_metadata VALUES (
‘POLYHEDRON_TABLE’,‘GEOMETRY’,
mdsys.sdo_dim_array(
mdsys.sdo_dim_element(‘X’,-100,100,0.001),
mdsys.sdo_dim_element(‘Y’,-100,100,0.001),
mdsys.sdo_dim_element(‘Z’,-100,100,0.001)),
NULL);
To be able to use the 3D R-tree index of Oracle, the polyhedron primitive is defined as
an existing sdo gtype: ‘3002’. This corresponds to a fictive 3D polyline going through
all the coordinates of the defined polyhedron. When creating a 3D spatial index, a
bounding box is created around this line. This bounding box equals the bounding
volume around the polyhedron. Oracle Spatial ignores all elements with sdo gtype
or e type = 0. If the sdo gtype = 0, the object is also ignored by the spatial index.
These values are therefore used for the remainder of the elements of the polyhedron
(flat faces).
Summarising, the following parameters are used for storing a cube as a polyhedron
primitive defined as an extension of the sdo geometry type:
151
Chapter 7. Geo-DBMSs
• sdo gtype = 3002 (3D line)
• sdo srid = NULL (no spatial reference system)
• sdo point = NULL (no point data)
• sdo elem info = 1,2,1 (line consisting of straight segments), and x,0,1006 (6
times an exterior polyhedron boundary, x is the starting offset in the array with
ordinates)
• sdo ordinates: contains eight coordinate triplets and six face descriptions
The query to insert a cube in the table, is:
INSERT INTO polyhedron_table (id, geometry) VALUES (1,
mdsys.sdo_geometry(3002, -- geometry type: 3D polyline
NULL, NULL,
mdsys.sdo_elem_info_array(1,2,1, 25,0,1006, 29,0,1006, 33,0,1006, 37,0,1006,
41,0,1006, 45,0,1006),
-- starting offset, e_type, interpretation code,
-- first triplet is fictive polyline, followed by 6 faces
mdsys.sdo_ordinate_array(
1,1,0, 1,3,0, 3,3,0, 3,1,0, -- vertices
1,1,2, 1,3,2, 3,3,2, 3,1,2,
-- bottom, top, front face, defined by references to nodes:
1,2,3,4, 8,7,6,5, 1,4,8,5,
-- back, left, right face, defined by references to nodes:
2,6,7,3, 1,5,6,2, 4,3,7,8
)));
Note that in a full implementation of the 3D primitive (that starts from scratch)
two arrays would be used: one for the coordinates and one for the references. However,
since the sdo geometry framework was used, both arrays were combined in the
sdo ordinate array. A 3D R-tree index can be created by the following SQL-statement:
CREATE INDEX polyhedron_table_index ON polyhedron_table(geometry)
INDEXTYPE IS mdsys.spatial_index parameters(‘sdo_indx_dims=3’);
7.4.2 Validation
It is important that the spatial data is checked (validated) when it is inserted in the
DBMS or when it is updated. Valid objects are necessary to make sure that the
objects can be manipulated in a correct way, e.g. it is impossible to compute the
volume of a cube when the top face is omitted; this would be an open box without
a volume. Validating may seem quite easy for humans, but a computer needs an
explicit set of rules to check the spatial data. To allow for checking the spatial data,
it is important to give an accurate definition of the 3D primitive. In [2] definitions of
both a polyhedron and a pseudo-polyhedron are given:
• Polyhedron: A polyhedron (figure 7.12 (a)) is a bounded subset of 3D coordinate
space enclosed by a finite set of flat polygons such that every edge of a
polygon is shared by exactly one other polygon (adjacent polygons). The vertices
and edges of the polygons are the vertices and edges of the polyhedron; the
polygons are the faces of the polyhedron. The edges and faces are two-manifold
(see below).
152
7.4. Implementation of a 3D geometrical primitive in a DBMS
• Pseudo-polyhedron: A pseudo-polyhedron (figure 7.12 (b)) is a bounded
subset of 3D coordinate space enclosed by a finite set of planar faces such that
(a) every edge has at least two adjacent faces, and (b) if any two faces meet,
they meet at an edge.
(a) Two polyhedra (b) Pseudo-polyhedron
Figure 7.12: Examples of polyhedra.
Polyhedra are therefore, a subset of pseudo-polyhedra. Edges and vertices, as boundary
elements for polyhedra and pseudo-polyhedra, may be either two-manifold (in
case of polyhedra) or non-manifold (in case of pseudo-polyhedra) elements.
In the case of edges, they are two(non)-manifold elements when every point of it is
also a two(non)-manifold point, except that either or both of its ending vertices might
be a point of the opposite type. A two-manifold edge is adjacent to exactly two faces,
and a two-manifold vertex is the apex of only one cone of faces.
In our implementation we used the definition of a polyhedron of [2], which is a twomanifold
element. Consequently, a valid polyhedron bounds a single volume, which
means that from every point (also on the boundary), every other point (also on the
boundary) can be reached via the interior. Based on this definition, a validation
function has been implemented.
Tolerance
The validation function and some of the 3D functions have a tolerance value as input
parameter. The points that make up the polygon can be slightly out of the flat
plane, because of the geodetic measuring methods [210] and the finite representation
of coordinates in a digital computer. To solve this problem a tolerance value has been
introduced. The faces of a polyhedron are flat within this tolerance. This tolerance
value should not be too large, otherwise invalid objects will be accepted as valid. A
good value for the tolerance is the standard deviation of the geodetic measurements.
Implementation
The definition of the polyhedron primitive is the basis for a set of validation rules that
have been implemented to evaluate the validity of stored objects. All the rules together
enforce the correctness of the stored polyhedra. According to the implemented
validation rules, a polyhedron is valid when (see below):
153
Chapter 7. Geo-DBMSs
• it has been stored correctly;
• it has flat faces;
• it is two-manifold (it bounds a single volume);
• its faces are simplicit;
• it is orientable.
Correct storage First of all, a check is needed on the storage of the data. It is
important for the validation function to work properly that the spatial objects are
stored as described in section 7.4.1. This means that valid interpretation codes need
to be used and that node references in the faces should correspond with an existing
vertex. If the spatial object is correctly stored the next test can be carried out.
Flatness characteristics The next test evaluates the flatness of the faces. At
the same time it is tested if an inner boundary of a face is in the same plane as its
corresponding outer boundary. All faces should be flat within a given tolerance. This
is tested by estimating a least squares plane through the average coordinate of all
vertices:
xc = 1
n Pn
i=1 xi yc = 1
n Pn
i=1 yi zc = 1
n Pn
i=1 zi
A least squares plane minimises:
Pn
i=1(Axi + Byi + Czi − D)2
where A, B and C are the components of the normal vector, D is the distance to the
origin, xi, yi and zi are the vertices and n is the number of vertices. If the average
coordinate is substracted from the vertices, the plane goes through the origin, which
results in D=0. The components of the normal vector are now the unknowns and the
eqations can be solved. To retrieve the plane equation, D can be computed by:
Axc + Byc + Czc + D = 0
where xc, yc and zc are the average coordinates of all vertices. The derived plane
equation is used to compute the distance from each vertex to this least squares plane.
If all distances are smaller than the tolerance value, the face is planar.
Two-manifold characteristics The next step is to test if the polyhedron bounds
a single volume in 3D space (two-manifold polyhedron). To test if a polyhedron is a
two-manifold polyhedron, a set of rules has been set up and implemented to enforce
the two-manifold characteristic of a polyhedron:
• All edges (defined by two vertices) occur exactly twice in opposite order.
• Inner or outer faces should not intersect (touch is allowed).
• A polyhedron can only contain one connected volume containing one or more
holes.
• Vertices related to one shell-structure should be two-manifold.
154
7.4. Implementation of a 3D geometrical primitive in a DBMS
Simplicity characteristics The faces should be simplicit. Therefore a test was
implemented to check that faces have an area, they are not self-intersecting and they
are not built of disconnected parts. Also an inner boundary of a face should not
intersect (touch is allowed) with its outer boundary.
Orientation characteristics The final test of the validation is to check if the
vertices in the faces are orientated correctly, i.e. anti-clockwise (looking from the
outside) for outer boundaries and clockwise for inner boundaries. Only one face of
the polyhedron has to be tested, because if the edges are two-manifold, the whole
object is either orientated correctly or incorrectly. It is important which face to test.
From the bottom face we know that the normal vector should be pointing towards
the negative z-direction. The cross product of two following edges of a convex part
of this bottom face gives the normal vector. The z-component of this normal vector
should be negative [210].
If all the criteria in the validation are met, then the spatial object is valid. The
following SQL-statement tries to validate the two objects shown in figure 7.13. How
the validation function has been implemented is described in section 7.4.4.
SELECT validate\_polyhedron(geom,0.05) VALID FROM table;
VALID
-------------------------
Not a 2-manifold object
Not a 2-manifold object
Figure 7.13: Invalid objects, because of dangling face (left) and intersecting faces
(right).
Both objects are detected to be invalid within a tolerance value of 0.05. Note that
the coordinates of these objects are measured in metres. A tolerance value of 0.05
then corresponds to a maximum error of 5 centimetres.
Critical objects
The statement that 3D data structures are very complex compared to 2D data structures
and that therefore a correct and finite definition of a polyhedron is not easy
to give, is underlined by the fact that still some valid polyhedra are determined as
invalid by our validation test. The definitions above exclude the valid polyhedron as
shown in figure 7.14 (a), which is a cube with a triangle-shaped hole which touches
the upper face. The upper face is divided into two parts, by which the middle-edge
155
Chapter 7. Geo-DBMSs
of this face occurs four times in the definition of the polyhedron. According to the
definition (and our implementation) this polyhedron is not valid, since the edge in
the upper face is used more than twice. However, in this case this does not cause
division of the polyhedron into disconnected parts. Therefore this polyhedron should
have been determined as valid. If the same polyhedron is modelled by not dividing
the upper-face and only defining a hole (that touches the upper-face), the object is
determined as valid.
(a) Edge in upper-face is used
four times
(b) Front face contains disconnected
parts due to three
tetrahedral dents
Figure 7.14: Valid polyhedra which are determined as invalid by the implementation.
Another valid polyhedron, which is not valid according to the implemented rules, is
shown in figure 7.14 (b). This is a polyhedron with three pyramid-shaped dents in
the front face, by which the front face contains disconnected parts. The front face is
not simplicit, since the inner rings of the face divide the face into disconnected parts.
However, since the face does not divide the polyhedron into disconnected parts, the
polyhedron should have been determined as valid.
7.4.3 Spatial indexing in 3D
Oracle Spatial 9i supports R-trees [68] up to four dimensions and the (2D) quadtree
(no support for octree). Therefore the Oracle R-tree indexing can be used for the 3D
primitive. Using the Oracle spatial index is made possible by storing the 3D objects
in a special way, as was mentioned before. A 3D polyline going through all the
coordinates of the defined polyhedron can be imagined. When creating a 3D R-tree
in Oracle, a bounding volume is created around this line, which equals the bounding
volume around the polyhedron.
2D or 3D spatial index?
In many spatial applications the extent of the domain in the x,y plane is larger than
156
7.4. Implementation of a 3D geometrical primitive in a DBMS
in the z-direction. For example, a city plan typically covers an area of five by five
kilometres with buildings up to 50 meters tall. This, plus the fact that queries usually
try to find all the objects in a specific x,y region (with possibly objects that are on
top of each other), may make a 3D spatial index hardly any more useful than a 2D
index (on x,y coordinates only). In these kinds of queries the x- and y-coordinates
are more selective than the z-coordinates. This means a 2D spatial index might work
just as well as or better than a 3D spatial index.
A test was executed to see if one might just as well use a 2D spatial index instead of
a 3D spatial index [4]. The test data set consisted of 1348 3D objects that are stored
with the 3D primitive. In the test (retrieving 3D objects that intersect with a 3D
box) the efficiency of the spatial index was measured by determining the number of
candidates that were selected by the spatial index compared to the actual number of
intersections. Sdo filter is the Oracle Spatial function that uses the spatial index to
select candidates for spatial queries. It is the only Oracle Spatial function that works
in 3D (in connection with the 3D R-tree).
The following SQL-statement shows how to use this filter to retrieve the number of
candidates:
SELECT COUNT(id) FROM buildings_table WHERE SDO_FILTER(geometry,
(SELECT geometry FROM querywindow WHERE id=1), ‘querytype = WINDOW’)=’TRUE’;
To retrieve the number of actual intersections, a 3D Boolean intersection function is
used that also was implemented (see section 7.4.4). The function can be used in an
SQL-statement as follows:
SELECT COUNT(id) FROM buildings_table WHERE intersection(geometry,
(SELECT geometry FROM querywindow WHERE id=1), 0.05)=1;
To use the spatial index in the implemented function, the spatial filter has to be
combined with the intersection function like this:
SELECT COUNT(id) FROM buildings_table WHERE SDO_FILTER(geometry,
(SELECT geometry FROM querywindow WHERE id=1), ‘querytype = WINDOW’)=‘TRUE’
AND
INTERSECTION(geometry, (SELECT geometry FROM querywindow WHERE id=1), 0.05)=1;
From the results of the test it can be concluded that a 2D index works as good as a
3D spatial index when the query window contains the ground level [4]:
Query box Result No spatial index 2D R-tree 3D R-tree
# cand. eff. # cand. eff. # cand. eff.
0-50m 509 1348 37.76% 510 99.80% 510 99.80%
20-50m 59 1348 0.04% 510 11.57% 59 100%
However, if the ground level is not included in a 3D query window then the 3D R-tree
is significantly faster (more efficient), because most objects can be skipped.
With the knowledge that the overhead of a 2D R-tree and a 3D R-tree are both
relatively small, there may be no reason to build a 2D R-tree on the data set instead
157
Chapter 7. Geo-DBMSs
of a 3D R-tree. The 3D R-tree performs equally well as the 2D R-tree when the query
window contains the ground level height, but it performs a lot better when this query
window does not contain the ground level height.
7.4.4 3D functions
As was mentioned in section 7.3.2, the standard functions in Oracle, just as in most
geo-DBMSs, only work with the projection of 3D spatial objects onto 2D coordinate
space, because the third dimension is ignored. To offer realistic functionality,
some of the most common functions have been implemented in 3D (for 0D up to 3D
primitives):
• function to insert data: creating data from 3D multipolygons and VRML;
• function to validate polyhedron: validation function;
• functions that return a Boolean: point-in-polyhedron query and intersection
test (polyhedron-polyhedron);
• unary functions that return a scalar: area, perimeter and volume;
• binary functions that return a scalar: distance between centroids;
• unary functions that return a simple geometry: bounding box, centroid, 2D
footprint and transformation functions;
• binary functions that return a simple geometry: line segment representing the
distance between centroids.
Functions that return a complex geometry such as tetrahedrisation and skeletonisation
are not implemented yet, but are also interesting, because of their analogy with
2D triangulation and generalisation. The functions are implemented in Java which
has the advantage that the functions are available outside Oracle as well (though
implementation in PL/SQL would probably show better performance).
It is clear that functions in 3D require more complex algorithms than 2D functions.
This also has a big influence on the computational complexity. To maintain good
performance, the algorithms have been implemented as efficiently as possible. Spatial
data sets can contain many objects, so a slightly more efficient algorithm already will
yield noticeable better performance when querying all these objects.
The next example shows how to compute the area, volume and perimeter (length of
edges) of the objects in figure 7.15. The figure shows a tetrahedron (1), a cube (2), a
cube with a dent in one of the faces (3), a hollow cube (4) and a cube with hole that
runs through the whole cube (5).
SELECT id, area3d(geom), volume(geom), perimeter(geom) FROM testobjects;
ID AREA3D(GEOM) VOLUME(GEOM) PERIMETER(GEOM)
-- ----------- ------------ ---------------
1 22.9530689 5.5 22.0723224
2 54 27 36
3 58 26 48
4 204 98 96
5 64 24 56
158
7.5. Conclusions
Figure 7.15: Set of five polyhedra used to show some 3D unary functions. Note that
object 4 is hollow.
7.5 Conclusions
This chapter showed that DBMSs are getting increasingly mature in maintenance of
spatial objects.
Geometrical primitive in DBMSs
Mainstream and popular non-commercial DBMSs offer support, maintenance and
some operations that allow spatial analysis of objects defined in geometrical primitives.
However, the implementation of geometrical primitives is still not complete.
Real 3D volumetric data types are lacking. A solution for 3D representation in the
DBMS was designed as part of this thesis and described in this chapter. The implemented
geometrical primitive (polyhedron without spherical and cylindrical patches)
showed that it is possible to support a true 3D primitive in the DBMS (including validation
functions and geometrical functions in 3D) although the 3D primitive needs
further development to be able to model more complex geometries.
Topological structure in DBMSs
Support for topological structure management is a relatively new issue in DBMSs
(recently available in Laser-Scan Radius Topology and Oracle Spatial 10g). The
lack of topological structure has led to a variety of topological structures in frontend
applications missing uniformity as a result. Managing topology in front-ends
undermines data consistency and integrity at DBMS level. In addition, the conversion
between the stored geometry in DBMS and the application dependent topological
layer has its influence on performance. An issue which needs attention is the type
of topology and dimensionality of the models. Current efforts are towards providing
2D topological structure (planar partition, linear networks) that most probably will
restrict the topological operators to 2D. Maintenance of several different types of
topological structures appears unavoidable.
In this chapter two user-defined implementations of a topological structure in a DBMS
were described: one in 2D (winged edge) and one in 3D (Simplified Spatial Model).
The experiments with these structures, including realisation functions, show potentials.
However, at the moment user-defined solutions of topological structure focus on
organisation of data. The consistency checks and updates still need to be performed
outside the DBMS. Also performance of metrical operations on the topological struc-
159
Chapter 7. Geo-DBMSs
ture might become critical in case of large data sets. A commercial solution of a 2D
topological structure in the DBMS was described in this chapter (i.e. Radius Topology).
Topological structure or geometrical primitive in DBMSs
Geometrical primitives are already supported by DBMS and, as first implemented, are
considered as a basic model. However, to improve data quality and data consistency
topological structure offers better possibilities. As was illustrated in the example
(section 7.3.4), spatial queries only relying on topological references perform well in
the topological structure compared to topological analyses on geometrical primitives.
On the other hand, experiments with Radius Topology 1.0 with large-scale spatial
data [108] showed that storage requirements and performance of the plain geometry
approach are (still) superior in many cases. At the moment topological structure is
therefore mainly appropriate for representing relationship operations and for checking
the quality of data during updates.
To make geometrical analyses on topologically structured data possible a function is
needed to derive the geometry from the topology. On the other hand, for full support
of topology in DBMSs, a function to derive the topology from geometry is also needed.
Many spatial operations give geometries as a result and it should be possible to convert
these geometries into topological layers in order to get a topologically structured data
set (also in case of topological results with redundant information such a function is
needed). Consequently geometry based operators will always be necessary to build
the topology: to find all the topological relationships in a new layer, functions based
on geometrical primitives are required.
Spatial functions in DBMS or in front-ends
DBMS plays an important role in the new generation GIS architecture. Mainstream
DBMSs have implemented support for spatial data types and they are still improving
support for geometrical primitives and topological structures. Does it mean that a
DBMS will and should include all spatial analyses, including complex spatial analyses
which have been optimised in GISs during decades? Does it mean that traditional
GIS software (or extended with attribute maintenance CAD software) has to convert
to a tool for import, visualisation, editing and exploration of spatial data?
Many spatial functionalities are (and probably will be) available only at the front-end
and not at DBMS level (e.g. spatial analyses which are specific for certain domains
and applications, tools for inserting new data, interaction tools for starting spatial
analyses, visualisation tools). Also, too many operations performed at a DBMS level
may lead to overloading of the server and affecting the performance of the DBMS.
On the other hand, too few operations provided by DBMS will result in development
of many functionalities by the front-end, i.e. duplication of development efforts and
resources. The question now is: which spatial operations should DBMSs take over?
The balance depends very much on the scope and constraints of spatial analysis: what
is spatial analysis and what is spatial analysis in a DBMS context. DBMSs are essential
in applications in which large amounts of large-scale geo-data in vector-format
need to be maintained and managed, such as cadastral data, or spatial data used in
municipalities. In principal, generic spatial functionalities that are not specific to a
certain application belong in the DBMS and not in front-end applications. Examples
160
7.5. Conclusions
are the spatial functions which examine the topological relationships between spatial
objects. Arguments for this are logical consistency of the data, better performance
and better maintenance of the quality of the data. Unnecessary transport and conversions
of data between DBMSs and GIS front-ends prone to errors can be avoided.
In contrast to the group of selection operations, specialisation and navigation in the
spatial domain can be very complex and time consuming. If they are performed at a
DBMS level (on the server), the performance can decrease drastically. Furthermore,
such complex operations may not be needed for all kind of applications. Therefore,
complex operations falling in the group of specialisation and navigation operations
can be considered to be left for implementation by the front-end.
A relevant question in this whole discussion is whether spatial functionalities implemented
in the DBMS will replace spatial functions that were originally built in GISs.
GIS has become an important instrument in workprocesses of companies and governmental
offices. A lot of money and effort have been invested by GIS vendors for selling
their software and for giving support and by organisations to develop specific GIS applications.
Future will prove if GIS vendors are willing to give up spatial analyses
(which always have been an important part of GISs) by which GISs will be converted
into visualisation/interaction tools (including editing) built on top of geo-DBMSs and
if organisations will move from spatial analyses in GIS applications to spatial analyses
in DBMSs.
161

Chapter 8
3D GIS and accessing a 3D
geo-DBMS with front-ends
In chapter 7 the possibilities to maintain and analyse 2D and 3D spatial objects
in a geo-DBMS were described. A geo-DBMS is part of the new generation GIS
architecture as was seen in section 6.6. For this research on 3D cadastre other 3D
aspects of GIS than geo-DBMS functionality are also important. The implementation
of a 3D cadastre addresses the issues of inserting, maintaining, querying, editing and
visualising 3D geo-objects in general. These are core topics of 3D GIS. Therefore the
state-of-the-art of 3D GIS will be described in section 8.1.
Once 3D spatial objects have been stored in a DBMS, these objects can be optimally
maintained, together with 2D spatial objects and non-spatial objects, in an integrated
DBMS environment. In (object) relational DBMSs, geo-information can only be
accessed with SQL commands of which the output is a sequence of characters and
numbers (or binary output). In order to query and edit the spatial objects in a
visual environment, spatial information maintained in DBMSs should be accessible in
front-ends having visualisation utilities.
The aim of second part of this chapter is to show the state-of-the-art of technology
to access spatial objects, and 3D spatial objects in particular, which are stored in a
DBMS with different front-ends.
In this chapter three front-ends are examined to access 2D and 3D spatial information
organised in the geometrical model of Oracle: a CAD-oriented system (section 8.2),
a GIS (section 8.3) and a self-developed Web based front-end (section 8.4).
The chapter ends with concluding remarks.
163
Chapter 8. 3D GIS and accessing a 3D geo-DBMS with front-ends
8.1 3D GIS1
2D GIS analysis has shown its limitations in certain applications as was seen in
section 5.5. Therefore the need for 3D geo-information is rapidly increasing.
Developments in the area of 3D GIS are motivated by a growing need for 3D information
from one side and new technologies on the other side, e.g. improving techniques of
3D data collection, of 3D object reconstruction but also of computer hardware. Processors,
memory and disk space devices have become more efficient in processing large
data sets (especially graphical cards also used by the games industry). Furthermore
elaborated tools to display and interact with 3D data are evolving.
This section gives an extensive overview on the status of 3D GIS by considering the
core topics of 3D GIS:
• organisation of 3D data (section 8.1.1);
• 3D data collection and object reconstruction (section 8.1.2);
• visualisation and navigation in 3D environments (section 8.1.3);
• 3D analysing and 3D editing (see section 8.1.4).
8.1.1 Organisation of 3D data
3D representations
Several approaches may appear very appropriate for 3D GIS models: Constructive
Solid Geometry (CSG), voxel representation (regular space subdivision), irregular
space subdivision (Tetrahedron Networks) and boundary representation. All approaches
show advantages and disadvantages considering different criteria and depending
on the specific application. The advantage of CSG is that it is very appropriate
for computer-aided manufacturing: a brick with a hole drilled through is
represented as “just that”. The disadvantage for real world modelling is that the
objects and their relationships might become very complex. Voxels are appropriate
in modelling continuous phenomena such as geology, soil, etc. Voxels are regular in
modelling: the basic unit of the model is the same. A disadvantage of voxels is that
high-resolution data requires large volume of computer space. Another disadvantage
is that surface is not regular by nature: it is always somehow “rough”. The tetrahedron
object is well defined, because the three points of each triangle always lie
in the same plane [20, 220]. A disadvantage is that it could take many tetrahedra
to construct one factual object. The main advantage of boundary representation is
that it is optimal for representing real-world objects. The boundary of real-world
objects can be observed, measured and surveyed from properties that are visible (i.e.
‘boundaries’). Furthermore most of the rendering engines are based on boundary representations
(i.e. triangles). Unfortunately, boundary representations are not unique
and constraints (rules for modelling) may get very complex to implement (e.g. how
to determine neighbours in 3D, how to ensure planarity of faces in 3D, etc.).
Logical models of 3D data
DBMS vendors still have not made the step to implement 3D data types in their
1This section is based on [204].
164
8.1. 3D GIS
geometrical model as was seen in chapter 7. Reasons for this may be that the OpenGIS
Consortium (OGC) is still working on extension of the Simple Feature Specification
to support 3D features and consensus on a 3D topological structure has not yet been
achieve. Another limiting factor is the relatively low (but growing) market demand
for 3D support in DBMS. The new generation GIS architecture for 3D is not (yet)
adopted by GIS-users. The current trend is to develop specific ad hoc solutions
when using 3D geo-information instead of building a database for maintaining spatial
objects. User-defined implementations of 3D GIS models can be found in [19, 147,
181, 227].
At present, 3D implementations defined by ISO/TC 211 and OGC are focused on
boundary representation. However CSG may appear appropriate for designed largescale
real-world objects (trees, traffic signs, building ornaments, statues) and voxel
representation for continuous phenomena.
8.1.2 3D data collection and object reconstruction
3D GIS requires 3D representations of distinct objects. Traditionally, (2D) GIS makes
use of data collection techniques such as surveying and measurements of the real
world, while creating 3D models used to be done separately from GIS, either using
CAD software or photogrammetric methods and modelling software. This subsection
describes if and how CAD designs and 3D object reconstruction techniques can be
used for 3D GIS models.
GIS and CAD
In the late 80s and early 90s many publications were written on GIS versus CAD and
how GIS and CAD could be effectively combined [32, 75, 106, 125, 187]. The tendency
of these papers is ‘how to use CAD systems for certain GIS-tasks’. The typical
tasks range from geographic data entry to automated map production (including
some cartographic aspects). This was motivated by the fact that two decades ago,
CAD systems were more general available than GISs. However, one could hardly
observe the desire for true integration of the different data models and functionalities
offered by CAD and GIS. About a decade ago the attention indeed shifted to the
integration of CAD and GIS functionality driven by application domains such as urban
and landscape architecture and planning [79, 121, 185, 193, 206]. The presented
solutions are often of a very ad hoc nature (capturing and transferring simple 3D
models between the different systems) or require custom-made software solutions.
Often these papers end with the remark that the off-the-shelf CAD/GIS functionality
still needs to be integrated for better support of their applications. However, seldom
a clue is give how this could be achieved or what could be the fundamental issue
causing the integration problems. More recent sources seem to be commercial and/or
development notices such as [111], where the emphasis is on providing data exchange
mechanisms either through shared files, translators, or inter-API’s, but till now, there
has been little care for the fundamental issues that need to be addressed, such as
integrated geometrical data structures concerning 3D and topological support (see
[100] for an overview), harmonised semantics of the concepts used and integrated
data management (in contrast to independent and inconsistent information islands
with data conversions and transfer) [143]. The issue of a fundamental integration of
165
Chapter 8. 3D GIS and accessing a 3D geo-DBMS with front-ends
GIS and CAD will be further discussed in section 11.2.4.
Object reconstruction
In the last several years a lot of research is conducted towards automation of 3D
object reconstruction (especially man-made objects). There is a variety of approaches
based on different data sources and aiming at different resolution and accuracy. For
constructing 3D models, four general approaches can be considered:
• Bottom-up: using footprints (from existing 2D maps) and extrude the footprints
with a given height using laserscan data, surveying, GPS or photogrammetric
data. The problem with this approach is that the detail of roofs cannot
be modelled. Since one value is used for every footprint, the buildings appear
as blocks in the model. The approach however is very fast and sufficient for applications
that do not need high accuracy (do not need roofs) and many details.
• Top-down: using the roof obtained from aerial stereo-photographs, airborne
laserscan data and some height information from the ground (one or more height
points near the buildings, DTMs). These approaches emphasise the modelling of
roofs [11, 67]. Obviously the accuracy of the obtained 3D models are dependent
on the resolution of the source data.
• Detailed reconstructing of all details: the most common approach is to fit
predefined shapes (building primitives) to the 3D point clouds obtained from
laserscan data [222] or 3D edges extracted from aerial photographs [59, 109]. The
advantage of this approach is the full automation and the major disadvantage
is that it is very time-consuming since the algorithms used are very complex.
• Combination of all of them: e.g. laserscan data and topographic data [78],
aerial photographs and maps [69, 207] etc. This approach contains some risks
since many data sources are used and combined, all with different scale and
quality. Using only few data sources will introduce fewer inconsistencies to be
solved during processing.
There is not a universal automatic 3D data reconstruction approach. At the moment,
the manual approach is still needed to reconstruct large-scale detailed 3D models,
which is a bottleneck for modelling urban areas in 3D. More research is needed to
make the process of 3D reconstruction (semi)automatic. A tighter connection between
3D object reconstruction and GIS will support developments in 3D GIS.
Important for 3D object reconstruction is to derive terrain elevation itself (Digital
Terrain Models and Digital Elevation Models). Laser altimetry can be used to automatically
derive terrain and elevation models with high accuracy, e.g. the AHN
(Actueel Hoogtebestand Nederland), which is a DTM covering the whole area of the
Netherlands with a density of one point per 16 square meters and in forest areas a
density of 36 square meters (see chapter 9).
8.1.3 Visualisation and navigation in 3D environments
3D models usual deal with large data sets, requiring efficient hardware and software
for visualisation. Several techniques are being developed to improve efficiency of navigating
through a 3D model, such as different levels of detail [94, 162], low-resolution
166
8.1. 3D GIS
graphics and imposters (image of object instead of geometry of object) [163]. All
these techniques aim at visualising high detail when objects are close by and low detail
when objects are further away. Different representations of objects can be either
stored in the DBMS or created on-the-fly. The main problems of storing multirepresentations
are fitting high detailed data to data that is represented at a low level of
detail and the redundant storage of representations.
A specific problem that comes with visualising 3D geo-data compared to 2D geo-data
is readability of the data (approaching realism). To make a view realistic one can add
illumination, shade, fog, textures, shadow, and material to the geometry (apart from
traditional characteristics such as colour). Apart from visualising 3D models, interacting
in 3D environments (exploring 3D models) also requires specific techniques.
These issues touch the fundamental difference between the Digital Landscape Model
(DLM) and the Digital Cartographic Model (DCM) which is a well-known issue in
traditional map production. The stored data set of a specific study area is called
the Digital Landscape Model. This model has to be converted into a Digital Cartographic
Model to make the (spatial) data set suitable for communication to other
persons. The DCM consists of series of instructions to the plotter, printer, screen, etc.
to produce dots, dashes or patches, in different sizes, colours and textures to make the
content of the data set readable [95]. In 3D this means that apart from spatial and
non-spatial information of spatial objects (DLM) also characteristics for visualising
and interacting with the objects (DCM) need to be maintained. Although visualising
in 2D also requires organising cartographic aspects apart from the content of the data,
the DCM aspects to be considered in 3D are much more, such as physical properties
of objects (texture and material), behaviour (e.g. on-click-open) and different levels
of detail representations. This requires several new elements to be organised in the
database compared to 2D data.
Virtual reality and augmented reality
Virtual Reality (VR) and Augmented Reality (AR) are supporting techniques for
improving visualisations of and interaction with 3D geo-data [219], e.g. putting textures
on objects and facilitating navigation through the 3D environment [66]. VR is
a realistic representation of data (2D, 2.5D and 3D), which means that details and
physical properties are represented highly realistically even together with sounds and
behaviours of the objects. Manipulation and interaction in the views can take place
by mouse click, animations, navigation and exploration. In AR a user explores and
navigates in the real world augmented by computer generated data. Several researches
have already addressed the issue to link 3D GIS with VR, e.g. [219].
All kinds of devices are nowadays available to support visualisation in VR/AR environments
[241], such as elaborated 3D display (Head Mounted Device, workbench,
panorama, CAVE, Cockpit), wire and wireless devices for positioning (gyros, accelerators,
GPS, GSM, WLAN), sensor devices to track the movements of the user (Power
Glove, indoor outdoor tracking systems) and various acceleration hardware (see figure
8.1).
3D GIS and Internet
3D Web visualisation is also progressing. The research on spatial querying and 3D
visualisation using VRML (Virtual Reality Modelling Language), X3D (eXtensible
3D) and/or GML (Geographic Markup Language) has resulted in several prototype
167
Chapter 8. 3D GIS and accessing a 3D geo-DBMS with front-ends
(a) Head Mounted Display (b) CAVE
Figure 8.1: Examples of new devices to support visualisation in VR/AR environments.
systems [13, 31, 35, 96, 104, 240]. Although research on spatial querying and visualisation
of geo-objects organised in a DBMS using Web based techniques is not (yet)
available (see section 8.4).
8.1.4 3D analyses and 3D editing
GIS software-tools have also made a significant movement towards 3D GIS. In [242]
a survey on mainstream GIS software is presented including: ArcScene [51], Imagine
VirtualGIS [50], PAMAP GIS Topographer [165] and GeoMedia Terrain [85]. In [242]
it is concluded that major progress in 3D GIS has been made on improving 3D visualisation
and animation. However, 3D functionality is still lacking such as generating
and editing 3D geo-objects, 3D structuring, 3D manipulation and 3D analyses (3D
overlay, 3D buffering, 3D shortest route on polyhedral or TIN surface). An example
of the implementation of a specific 3D analysis, 3D buffering, is described in [224].
Concerning editing of 3D geo-data in the new generation GIS architecture, CAD and
GIS front-ends should be able to read 3D output and write it to both topological and
geometrical structures in DBMSs in which the front-end has to be able to preserve
the topology of the 3D object. This topic has not yet been addressed in previous
research.
8.2 Accessing a geo-DBMS with a CAD front-end
This section describes how to access spatial objects that are stored in Oracle Spatial
using a CAD oriented front-end. Bentley’s MicroStation GeoGraphics [10] is an
extension of the CAD software MicroStation containing functions specific for geoinformation
and for connection to Oracle Spatial. The organisation of data within
168
8.2. Accessing a geo-DBMS with a CAD front-end
MicroStation GeoGraphics (MS GG) is defined in a project hierarchical structure.
Project represents the data for the entire study area. The second level is the category,
which groups features with a similar theme (e.g. buildings, rivers). One project
can have many categories but a category may belong to only one project. Feature is
at the third level and represents one or more spatial objects with the same thematic
attributes (e.g. the bank building, the school building). A category may have many
features but a feature may belong to only one category. Feature is the basic structural
unit in MS GG.
With MS GG there are two tools delivered to query and post data from Oracle Spatial:
a MS GG tool and a Java applet “Spatial Viewer”. Here we focus on the MS GG
tool. The Spatial Viewer is described at the end of this section.
Visualisation of spatial data from Oracle Spatial 9i using the MS GG tool is relatively
simple and straightforward. The user has to create a project and connect to Oracle
Spatial. MS GG checks the Oracle metadata table for the name of the table(s) and
corresponding columns that contain spatial data. These are supplied to the user for
display. In this case, the geometries will be visualised, but will not be available for
querying and editing. More steps have to be taken in order to distinguish between
different spatial objects stored in Oracle Spatial (e.g. ‘identify’ or ‘query’) and also
in order to edit objects maintained in Oracle Spatial. In general, each spatial object
in the Oracle database has to be assigned to a predefined feature in MS GG, but
depending on the original source of the data (Oracle or MS GG), different steps have
to be followed. We completed a number of case studies with MS GG (version 8.1.0.7)
following the two different approaches of representing 3D objects (as a set of 3D
polygons and as a multipolygon defined in 3D), having the data initially organised
either in Oracle (user-defined tables) or in MicroStation (graphics in a design file)
(see also [242]).
Geometrical data initially organised in Oracle Spatial 9i
The required steps to assess and query the objects that are originally organised in
Oracle Spatial 9i are [242]:
• Create semantics, i.e. project (by specifying the Oracle connection and the Oracle
database), categories and features. This step is enough for only visualising
spatial layers from Oracle Spatial.
• Register the spatial table, stored in Oracle Spatial as MS GG layer by creating
a new MS GG layer and referencing this new layer to the corresponding Oracle
table and column that contains the geometries.
• Link features (the code of the feature) to the corresponding spatial objects (id of
spatial object). Running an appropriate script within Oracle is one of the easiest
ways to complete this operation in case of many objects. Both the features and
spatial objects are maintained in the DBMS.
To illustrate the steps to visualise and query spatial objects maintained in Oracle Spatial
with the MS GG tool, we use a table with buildings, represented as a set of faces
(3D polygons). The data set with buildings is organised in a relational table (BODY)
that originally consisted of only three columns (BODY ID, FACE ID and SHAPE).
The column SHAPE contains the geometries of the objects as mdsys.sdo geometry
type, i.e. the polygons. The links between FACE ID and SHAPE is 1:1 and the link
169
Chapter 8. 3D GIS and accessing a 3D geo-DBMS with front-ends
between FACE ID and BODY ID is m:1.
1. Creating project, category and features Bearing in mind the basic conceptual
structure of MS GG we created a project (cadastre), a category (buildings)
and several features (build1, build2, build3 and build4) in MS GG. The four buildings
(polyhedrons) are instances of the type (category) buildings. This operation
resulted in twelve new relational tables in Oracle Spatial. The names of the tables
created by MS GG and us (in bold) are: BODY, CATEGORY, FEATURE, MAPS,
MSCATALOG, UGCATEGORY, UGCOMMAND, UGFEATURE, UGJOIN CAT,
UGLAYER, UGMAP, UGMAPINDEX and UGTABLE CAT. ‘UG’ refers to Micro-
Station GeoGraphics. Among all these tables, MSCATALOG and FEATURE are of
practical interest. The first table maintains reference to all the tables used in the
project. The second one contains information (names, codes, unique identifiers, etc.)
related to all the features created by the user. The spatial data (BODY table in our
case) becomes visible after this step in the Query tool in MS GG, i.e. it is possible to
query and display the entire layer. In order to be able to post data in the database
and to query individual objects, the table has to be linked to a spatial layer and the
objects to features.
2. Creating spatial layer The table with the geometry (i.e. BODY) with geometry
column SHAPE has to be referred to as a spatial layer in MS GG. Further, all
the features that are to be associated with objects in this layer need to be assigned to
the layer (again in MS GG). This operation extended our table BODY with nine new
columns, all starting with ‘BODY ’. We also added a ‘mslink’ column (as primary
key), since MS GG requires a column, named ‘mslink’ with unique values to be able
to query attributes:
Column-name Type
BODY ID NUMBER(10)
FACE ID NUMBER(10)
SHAPE MDSYS.SDO GEOMETRY
BODY DFLAG NUMBER(10)
BODY UDL RAW(200)
BODY LOCK NUMBER(10)
BODY FID FCODE LIST
BODY CREATED DATE
BODY REVD DATE
BODY RETIRED DATE
BODY XML XMLTYPE (or BLOB or VARCHAR2)
BODY TXT VARCHAR2(1024)
MSLINK NUMBER(10)
3. Linking features to spatial objects First, one should make sure that the table
with the spatial data (i.e. BODY) is declared in the table MSCATALOG. The project
tables CATALOG and FEATURE are automatically registered in the CATALOG
table by MS GG under entity numbers 1 and 2. Second, the column BODY FID
170
8.2. Accessing a geo-DBMS with a CAD front-end
(in the BODY table) has to be populated. The FID (feature id) column contains
all database linkages that are related to elements in a DGN-file. The column is an
object of type Fcode list which is an array of Fcode item objects. Fcode item (p1,
p2, p3, p4) provides the link between a feature (from FEATURE) and a particular
spatial object (from BODY). The first of (in this case) two fcode items is related to the
feature as it is described in the FEATURE table and the second to the spatial object
from the BODY table. Parameter p1 is the number of the table in the MSCATALOG
(as it appears under the column ENTITY). Parameter p2 is the number of the feature
in the FEATURE table (given in the mslink column) in the first fcode item and the
identifier of the object (i.e. FACE ID) in the second fcode item. The third parameter
gives indication of whether the description is for feature (informational object) (i.e. 1)
or spatial (non-informational) object (i.e. 0). Cases in which more than one feature
refers to the same object are resolved by introducing a new fcode item in the fcode list
description. The operation to fill the FID column can be performed either in MS GG
or Oracle Spatial. Last, all the values in the column BODY LOCK (giving information
about the owner of the data) have to be set to zero (i.e. belong to the owner of the
table). A PL/SQL script completes these two operations within Oracle:
... FOR i in n..m LOOP
UPDATE body SET body_fid =
fcode_list (fcode_item (2,4,1,0), fcode_item (5,i,0,0))
WHERE face_id=i;
UPDATE body SET body_lock = 0 WHERE body_id=i;
END LOOP; ...
Note that in this case, one feature (i.e. number 4) is assigned to several objects, e.g.
to attach the set of polygons to one 3D object.
Geometrical data initially organised in MicroStation design files
3D objects that are initially stored in MicroStation dgn (design) files can be imported
in Oracle Spatial directly by the three following major steps: 1) Create project,
features, categories and spatial layers, 2) Select the entire geometry (polygons or
groups of polygons) per spatial object in MS GG and attach a feature to it, 3) Post
the spatial objects to the database.
In both approaches, after completing all the required steps, it was possible to query,
visualise, edit and post the spatial objects as they are defined in Oracle Spatial (see
figure 8.2). Evidently only spatial objects can be posted that are described with
geometrical primitives that are supported in Oracle Spatial. A query can be specified
either per layer or per feature and can be performed on the basis of the semantic
characteristics of the objects as defined in MS GG. For example, query on feature
‘buildings’ will result in visualising all the buildings. Apparently, such possibility
brings advantages for editing and updating large 3D models. Instead of working with
the entire model, the user can query and work with only one object. Thus rendering
of thousands of polygons can be easily avoided.
MS GG was able to visualise and edit both 3D geometrical representations (i.e. set of
3D polygons and 3D multipolygons) by following the steps described above. It should
be noted that MS GG interprets the two representations in a different manner. In the
first case the building is visually one object, but in the Oracle Spatial table, it is a set
of individual polygons (figure 8.3). The entire building can be selected only by placing
171
Chapter 8. 3D GIS and accessing a 3D geo-DBMS with front-ends
Figure 8.2: Querying spatial objects organised in Oracle Spatial, using MS GG.
a fence around all the polygons. In the second case, the building is one ‘group’, i.e. a
single click of the mouse will highlight the entire building. In order to edit the object,
however, the group has to be divided (’dropped’ in MS GG terms) into individual
polygons, i.e. the 3D object cannot be edited as a whole. To send the changes back
to the database, grouping of the objects will be required again. Otherwise, the object
will be considered as a set of several new polygons. It would be more efficient and less
sensitive to errors to be able to edit the 3D object as it is defined, without dropping
the element into 3D individual elements.
Figure 8.3: Editing and posting a 3D object as set of polygons using MS GG.
172
8.3. Accessing a geo-DBMS with a GIS front-end
Spatial Viewer
The Spatial Viewer is an example to show the possibilities of the MS GG API, in this
case: an implementation of how to handle spatial information without a GG project.
The Spatial Viewer is a Java applet and is delivered together with MS GG. The
Spatial Viewer is especially meant to show the possibilities for implementing ones
own data model.
Using the Spatial Viewer one can visualise, query and post (=update) elements. Also
here, an mslink column containing unique numbers needs to be added and populated
with unique values for accessing attribute data. The table name needs to be added in
the MSCATALOG table to be able to post data. The Spatial Viewer reads the Oracle
metadata table for available tables with geometries. In our example the relationship
between mslink and face id is 1:1. In the case one would like to use another column
as the key (e.g. body id for a reference to the whole 3D object), this can be achieved
by using the available API. Using the Spatial Viewer, a MS GG project is not
required, only the table MSCATALOG is needed and therefore the Spatial Viewer
requires less customisation and less work for querying and posting data from Oracle.
In addition the functionality can be adjusted to meet the user requirements. The
main disadvantage of the Spatial Viewer is that it is not directly available in the
menu of the MicroStation environment.
8.3 Accessing a geo-DBMS with a GIS front-end
ESRI software (ArcMap for 2D and ArcScene for 3D, both part of the complete
package ArcGIS) [51], is able to access data that is stored as a sdo geometry type in
Oracle with ArcSDE. ArcSDE is middleware that facilitates managing spatial data
in a DBMS (IBM DB2, IBM Informix, Microsoft SQL Server, and Oracle). Originally
ArcSDE was developed for the SDE binary format, which is a format for spatial data
types in the DBMS (stored as BLOBs) developed by ESRI. Since spatial data types
have become available in DBMSs, ArcSDE now also supports spatial data types. We
did experiments to see if and how 2D and 3D geo-objects stored in Oracle Spatial can
be accessed with ArcGIS version 8.3.
There are two methods to access data stored in Oracle Spatial via ArcSDE:
1. using SDE client/server software;
2. using ‘direct connect’, which does not use the SDE server, but only the SDE
client software which is part of ArcGIS; the required SDE server functionality
is included in the client software.
For the user who visualises the data both connections work similarly. The difference
is the way the connection is defined and how the connection works behind the GUI.
The ‘direct connect’ makes direct connection to the DBMS without using the ArcSDE
application server. On the other hand, for the ‘direct connect’ one needs Oracle
client software on the client platform (PC), which is not needed for the ArcSDE
connection. According to the manual, the ‘direct connect’ is easier to install and
maintain. However, for this connection one still needs the tables of the user ‘sde’ in
173
Chapter 8. 3D GIS and accessing a 3D geo-DBMS with front-ends
Oracle (the ArcSDE system tables) in combination with the Oracle Spatial metadata
tables. An advantage of the ‘direct connect’ is that you do not need an ArcSDE
licence to visualise data, in contrast with the SDE client/server connection. However,
also in the ‘direct connect’ case one needs a license when one wants to edit the data.
The steps to visualise data organised in Oracle in ArcMap and ArcScene are:
1. insert metadata in the Oracle Spatial metadata table;
2. register the table that contains the geometry in the SDE system tables;
3. define the DBMS connection in ArcCatalog (the ArcGIS program for management
of GIS-layers);
4. obtain the data in ArcMap or ArcScene.
Step 1: Insert metadata in the Oracle Spatial metadata table The insertion
of metadata in the Oracle metadata table was shown in section 7.1.
Step 2: Registering the table containing geometries For both connections
the table containing geometries needs to be registered as sde-layer. The registration
of a table ‘test2d’ containing line features in a geometry column ‘shape’ and a primary
key in the column ‘ID’ is registered as follows:
sdelayer -o register -l test2d,shape -k SDO GEOMETRY -e l
-u stoter -p password@database name -i sde:oracle9i -c id -C USER
For 3D information, the element type should be polygons in 3D. Also multipolygons
need to be supported. This is handled by the -e a3+ option (instead of -e l); ‘a’ for
area, ‘3’ for 3D and ‘+