3D Cadastral Database Systems—A Systematic Literature Review

Abstract

Cadastral databases have been used for over 20 years, but most contain 2D data. The increasing presence of high-rise buildings with modern architecture complicates the process of determining property rights, restrictions, and responsibilities. It is, therefore, necessary to develop an efficient system for storing and managing multidimensional cadastral data. While there have been attempts to develop 3D cadastral database schemas, a comprehensive solution that meets all the requirements for effective data storage, manipulation, and retrieval has not yet been presented. This study aims to analyse the literature on 3D cadastral databases to identify approaches and technologies for storing and managing these data. Based on a systematic literature review integrated with a snowballing methodology, 108 documents were identified. During the analysis of the related documents, different parameters were extracted, including the conceptual data model, query type, and evaluation metrics, as well as the database management system (DBMS) used and technologies for visualisation, data preparation, data transformation, and the ETL (extract, transform, and load) process. The study emphasised the importance of adhering to database design principles and identified challenges associated with conceptual design, DBMS selection, logical design, and physical design. The study results provide insights for selecting the appropriate standards, technologies, and DBMSs for designing a 3D cadastral database system.

1. Introduction

With the increasing importance of land due to population growth and ongoing rapid urbanisation, land document registration and storage methods have constantly been changing, improving, and advancing along with the progress of technology. They have progressed from paper-based registration to digital and file-based storage, which has then led to the development of various file formats and, eventually, databases [1]. The construction of more modern high-rise buildings and utilities each day, as well as utilising various technologies and tools for collecting 3D data, makes it more complex and challenging to continuously register, record, update, retrieve, and maintain rights, restrictions, and responsibilities (RRRs) and data related to land. Therefore, a system for efficiently storing and managing 3D cadastral data is required. In addition, the need for implementing technical models such as database schemas and exchange formats was highlighted in the International Federation of Surveyors (FIG) Workshop [2].

A cadastral data model is required to cover both legal and physical aspects, as well as survey elements [3,4], which contains spatial and non-spatial data [5], multi-purpose and multidimensional data including 0D–4D (3D + time) [6,7,8,9], 5D (4D + scale [10] or 3D + bi-temporal [11]), metadata, and observations and measurements [12]. It is also suggested that the Land Administration Domain Model (LADM) should be expanded to include marine, valuation, and spatial plan information [13,14]. Depending on the requirements, these data can be created and manipulated using either file-based or database storage. For example, surveyors may use files to store and lodge 3D data, whereas land registry organisations may utilise databases to register and update 3D cadastral data [15]. There are several major disadvantages associated with traditional file-based solutions, including data isolation, data redundancy, and application dependency [16]. Aside from that, they do not guarantee the integrity and consistency, security, or concurrent access of the data [17]. Thus, a reliable Database Management System (DBMS) is essential for handling 3D spatial characteristics, including geometrical shape, topological and positional information, spatial data models, spatial queries, spatial data types, and spatial indexing [5,18,19]. DBMSs serve as the technical backbone and are an essential part of the cadastral system’s architecture; they are a significant investment for jurisdictions in land administration. They enable the secure storage, maintenance, and exploitation of cadastral data [6,20,21]. Moreover, efficient collaboration, sharing, and reuse of 3D data improve data harmonisation and usability, benefiting design efficiency, data acquisition, quality, and consistency. So, 3D cadastral databases are crucial in managing these aspects. Resolving data sharing and integration issues ensures organised data flow based on standards, enhancing efficiency, especially in complex environments [18]. Therefore, every new cadastral system solution or upgrade should include or incorporate an advanced DBMS in its lifecycle [20].

Land Administration Systems (LASs) still rely mainly on 2D-based cadastral systems to record, manage, and visualise data which pose legal, organisational, and technical challenges [22]. Research on 3D digital cadastral plan implementation and its contribution to cadastral databases is limited [23]. Despite some positive developments in the field, a comprehensive database schema for 3D cadastres has not yet been established. Designing a database involves four key steps: create the conceptual design, select the DBMS software, create the logical design, and create the physical design [24]. There are major challenges associated with designing a 3D cadastral conceptual model, its conversion to a logical model, and then its implementation as a physical model [25,26,27,28]. It is also challenging to determine whether to use a relational or non-relational database since each has its benefits and drawbacks and no single database satisfies all requirements. An example issue is how to model 3D geo-objects (topologically and geometrically) in a DBMS [29]. Most databases do not or only partially support 3D spatial functions and operators [30,31]. Another challenge is selecting the right data type for 3D spatial data, which are not fully supported by most databases [26]. Additionally, data are derived from various sources and need to be heterogeneous and interoperable [32]. It is also necessary for a cadastral system to provide access to a wide range of users with different roles. Consequently, another concern is how different users can access the cadastral system [29]. While there have been attempts to develop database schemas for storing 3D cadastral data, a comprehensive solution that meets all the requirements for effectively storing, editing, manipulating, querying, retrieving, managing, and analysing these 3D cadastral data has not yet been presented and remains a major research gap.

This review aims to thoroughly analyse the current research on 3D cadastral databases to identify appropriate approaches to storing and managing 3D cadastral data. The main objectives and contributions include (1) providing a background of 3D cadastral storage approaches with relevant research; (2) creating a literature inventory of the standard data models, technologies and development tools, and evaluation metrics; (3) performing a detailed analysis based on analytical criteria; and (4) discussing the challenges, limitations, and research gaps and suggesting recommendations for future directions. This research may provide references when researchers apply 3D spatial data storage methods in different areas, such as 3D cadastres, 3D GIS, 3D land administration, 3D urban planning, digital twins, and Building Information Modelling (BIM).

The remainder of this paper proceeds as follows. Section 2 outlines the methodology used to search, review, and select relevant studies and provides statistical information and trends related to the storage of 3D cadastral data. Section 3 summarises current approaches to storing these data and technical limitations and software and tools used in the process. In Section 4, challenges and knowledge gaps will be discussed. This review finishes with a conclusion and opportunities for future studies in Section 5.

2. Research Methodology

A systematic literature review (SLR) was undertaken in this research. As Kitchenham et al. suggest, software engineering researchers should adopt an evidence-based approach to their research and practice [33]. In addition to providing a comprehensive, objective, and evidence-based analysis of the existing literature on 3D cadastral databases and storage approaches, an SLR can highlight the limitations and challenges of various methods and tools, allowing for the selection of the most appropriate approaches. This study follows the guidelines and steps proposed by Kitchenham and Charters [34]. Consequently, the steps adopted included: 1. research questions (define review protocol), 2. search process (a search strategy that aims to detect relevant works of literature), 3. inclusion and exclusion criteria (assess potential primary studies), 4. quality assessment (choose eligible studies), and 5. data analysis.

2.1. Research Questions

The following research questions were formulated to provide insight into the analysis of published studies in 3D cadastral databases:

• RQ1: How are 3D cadastral data stored and managed currently?
• RQ2: What are the main technical limitations and challenges involved in storing 3D cadastral data? What are the strengths and weaknesses of the current practices?
• RQ3: How can 3D cadastral databases be developed in future with a focus on the research gaps and related directions?

2.2. Search and Selection Process

The process of identifying, screening, and selecting relevant publications used in this study is shown in Figure 1. Relevant references were found via automatic and manual search in Scopus and FIG databases. Scopus is a well-known and comprehensive database that has extensive and authoritative literature coverage. FIG resources (https://www.fig.net/resources/index.asp, accessed on 14 January 2024) encompass a wide range of materials including the proceedings from FIG events and workshops, peer-reviewed journals, books, and publications. These documents also include archives of publications related to 3D cadastres (http://www.gdmc.nl/3DCadastres/literature/, accessed on 14 January 2024).

An automatic keyword search was performed in Scopus using filters and a manual approach was employed to search in FIG resources. Initially, relevant and similar terms were selected, and a query was provided in Scopus, as presented in

Table 1. Overview of the query for keyword search in Scopus.

Search within	Keywords/Operator
Article Title, Abstract, Keywords	cadastre OR “land administration” OR cadastral
AND
Article Title, Abstract, Keywords	3d OR “three-dimensional” OR 4d OR multidimensional OR “multi-dimensional”
AND
Article Title, Abstract, Keywords	database OR “data base” OR dbms OR geodatabase OR file-based OR storage OR store OR query OR retrieve OR extract OR transfer OR integration OR conceptual OR logical OR physical OR querying OR storing
AND
Language	English

, which returned 341 papers. Generally, different forms of words were searched, and the results were compared. For example, the search terms “geodatabase” and “geo-database” returned the same papers, so the latter was removed from the search process. Additionally, “database management systems” and “ETL” were added to the search query, but the results did not change significantly.

To ensure the comprehensiveness of the review, there were no restrictions on the type of database or tools used in the papers. However, papers had to be in English and the references had to be accessible. Papers focused on 3D modelling, country profiles, and improving standards were outside the scope of this study. The inclusion and exclusion criteria are summarised in Table 2. Our primary focus for this paper was on studies related to databases or storage approaches in the 3D cadastre domain. Consequently, we specifically sought out papers that fulfilled at least one of the following criteria:

• Designing a database for 3D cadastral data;
• Using databases as part of their research;
• Identifying the criteria and challenges and need for developing a database.

Table 2. Criteria for systematic literature review.

Inclusion criteria	Studies focusing on designing a 3D cadastral database. Studies using a database as part of their work in 3D cadastres or related fields. Studies describing the concepts and challenges related to 3D cadastral storage approaches. Studies providing answers to the research questions.
Exclusion criteria	Papers that primarily focus on country profiles, 3D modelling, and developments without database implementation. Publication not available in full text. Publication not in English.

Table 2. Criteria for systematic literature review.

Inclusion criteria	Studies focusing on designing a 3D cadastral database. Studies using a database as part of their work in 3D cadastres or related fields. Studies describing the concepts and challenges related to 3D cadastral storage approaches. Studies providing answers to the research questions.
Exclusion criteria	Papers that primarily focus on country profiles, 3D modelling, and developments without database implementation. Publication not available in full text. Publication not in English.

The next step involved screening and filtering the papers according to their titles and abstracts/summaries. The full texts of the selected papers were then reviewed to determine whether they met the inclusion and exclusion criteria. After filtering and selecting the first list of papers, a forward and backward snowballing [35] method was applied to ensure that no documents were missed. The forward and backward searches examined “citations” and “references” of the selected papers with the same screening and filtering process. Our search for new papers was conducted through Google Scholar, which has better coverage than Scopus for finding citations. The search process was completed after four iterations. In total, 108 papers were eligible for inclusion in the analysis as the most relevant references. A wide range of documents were contained in this collection, including journals, conferences, books, and PhD and master’s theses. Based on the inclusion criteria, the papers were categorised into those without database implementations, those that used databases as part of their work, and those that focused on database design.

Table 3. List of publications by category.

Category	References	No. of Documents
Without implementation	[5,7,8,10,12,13,18,26,31,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53]	27
Using database	[6,9,11,15,20,32,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102]	55
Designing database	[1,25,27,28,29,30,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122]	26

shows the distribution of papers based on their categories. Among the selected papers, only 26 studies focused on designing databases for 3D cadastres. It should be noted that although our focus was not on file-based approaches, some papers were discovered during the selection process and have been discussed.

2.3. Data Analysis

After completing the identification, screening, and selection process, 108 publications were eligible to examine the current approaches, challenges, and limitations in designing and implementing a 3D cadastral database. Most (65%) of these publications were journal articles, while 30% were conference papers (Figure 2). These publications were released between 2001 and 2024, indicating that this topic has gained importance and attention over the last two decades. Additionally, Figure 3 demonstrates a growing interest in this subject in recent years. This trend may be attributed to various factors, such as technological advancements, changing attention to managing 3D data, and emerging research trends. It highlights the significance of monitoring research trends and changes to better comprehend the implications of academic work and its impact on society.

Figure 4 depicts the five most prominent journals in this domain that have issued the greatest number of publications. In the period between 2015 and 2024, “Land Use Policy” and the “ISPRS International Journal of Geo Information” have published 16 and 13 articles, respectively. It should be mentioned that many conference papers have been presented at FIG events such as conferences, workshops, congresses. The primary countries that have taken the lead in this area are The Netherlands, Australia, and Malaysia. Nonetheless, the data presented in Figure 5 demonstrate that scholars from various other nations have also concentrated on this subject.

3. Current Approaches to 3D Cadastral Data Storage

It can be inferred from the statistics report presented earlier that various studies have been conducted on storing 3D cadastral data over the past two decades. Database management systems, however, play a relatively small role in the existing literature. Despite efforts to design a database in this area, there has not yet been a dedicated database designed specifically for 3D cadastral purposes that comprehensively and effectively covers all the legal, physical, data management, and data analysis aspects, access controls, user requirements, and other relevant considerations to make sure 3D spatial data are accurately represented for and efficiently used by various stakeholders. This highlights the importance of the topic and discussion in this area. Figure 6 illustrates how the collected documents in this research are categorised.

3.1. Without Database Implementation

This research identified some publications that did not include database implementation or 3D spatial query analysis. Instead, their focus was on the conceptual and technical aspects of 3D cadastral databases such as modelling 3D cadastral data and accessing and analysing them; combining 2D parcels and 3D spatial data in one environment; required system architecture (computer hardware; software); different types of 3D spatial representations such as vector, voxel, and point cloud; 3D spatial indexing and clustering; 3D spatial data types; 3D operations; and 3D topological and geometrical structures [12,38,39,40]. In addition, they discussed specific needs and requirements [41], 3D topological support in different spatial databases [5], visualisation and editing of 3D data in a DBMS [42], and boundary representation [43]. A few papers proposed a framework or workflow [31,37] aimed at identifying 3D analytical requirements and bridging knowledge gaps in this domain. The possibility and feasibility of multi-purpose and multidimensional modelling [49,50,51] and 4D cadastres [7,52,53] and 5D cadastres [10,36] was also investigated.

Several papers discussed the use of INTERLIS to implement country profiles based on the LADM in countries such as Switzerland [46] and Colombia [47,48]. Figure 7 illustrates the workflow of an LADM implementation based on INTERLIS proposed by Jenni et al. [48].

Kara et al. worked on the requirements and new capabilities of LADM Edition II and suggested a new structure [13]. Shahidinejad et al. discussed the challenges and essential steps involved in implementing a 3D cadastral database based on the LADM. They emphasised the importance of following database design principles, incorporating 3D spatial data types, tackling normalisation issues, considering multivalued attributes, and recognising the necessity for a user-friendly standard in this context [26].

Thompson explored some issues in developing a Digital Cadastral Data Base (DCDB) based on the LADM, such as the level of data accuracy needed and validation issues [44]. He also discussed five levels of encoding the geometry introduced by the LADM including text-based, point-based, line-based, polygon-based, and topology-based encoding and the allowance of conversion between them. Rajabifard et al. proposed strategies for implementing a 3D National Digital Cadastral Database (3D-NDCDB) in Malaysia. They emphasised adopting an LADM-based approach, which would greatly simplify 3D cadastral registration, particularly in complex ownership cases. They concluded that the potential improvements and benefits that the LADM can deliver in Malaysia are multifaceted and encompass activities such as preparing land tenure data to measure indicators related to SDGs, achieving national-level harmonisation of land tenure data, and introducing 3D cadastres [45].

Kalogianni et al. examined the need to move from 2D-based Land Administration Systems (LASs) to 3D LASs, incorporating lifecycle thinking. They proposed a web-based system architecture (Figure 8) including four components: source data gathering, data processing and validation, data storage, and data dissemination and visualisation. A key objective of the proposed architecture was to enhance collaboration and interoperability and facilitate data reuse in various situations, such as reusing Industry Foundation Classes (IFC) data as source information for a 3D LAS [18].

Döner et al. investigated legal, organisational, and technical aspects in 4D cadastres. They discussed utility networks’ registration practices in Turkey, The Netherlands, and Australia (Queensland). The study emphasised the dual nature of boundaries, highlighting their spatial existence between parcels at the same moment and their temporal boundary, like the “transfer of rights on a parcel from person A to B on March 1st”. The authors also noted that dynamic objects such as moving rivers or coastlines could involve mixed spatial-temporal boundaries. They found that registering 3D and 4D aspects of utility networks in cadastres is more sustainable compared to traditional approaches, which neglect the three-dimensional and temporal aspects of network registration [8].

In addition, researchers have also expanded their efforts beyond the content covered in these articles, attempting practical implementations in related fields and domains. The works analysed in 3D cadastral data storage and management can be classified into two main technical categories based on where the data are stored and how they are managed: file-based methods and database approaches. The category of database approaches includes papers in which the primary objective was to design a database, as well as those that utilised a database as part of their research work. Each of these approaches will be explained in the following sections.

3.2. File-Based Approaches

In the early stages of 3D cadastre data management, the primary approach employed was utilising flat files. Our objective did not involve examining file-based approaches. The papers listed below were identified through a systematic literature review, and their inclusion for analysis was deemed valuable.

Some file-based approaches use BIM and IFC formats. For instance, Barzegar et al. developed a Revit plugin based on BIM to retrieve property boundaries in complex building structures using 3D spatial queries and visualising the outcomes in Revit [43]. Furthermore, this study addressed different challenges encountered in the process, including the influence of different design methods and issues related to balconies and doors. The implementation of algorithms for retrieving horizontal and vertical boundaries was accomplished by using the C# programming language and developing an Application Programming Interface (API) within Autodesk Revit. This study applied 3D topological relationships to the geometry of legal spaces to retrieve and identify property boundaries associated with physical objects in a complex building. Notably, the study highlighted the dependency of assigning property boundaries to physical objects on the spatial integrity of the model and the chosen design methods.

Some researchers have suggested expanding an Application Domain Extension (ADE) in CityGML, with one example being VicULA ADE, which was developed for managing 3D underground data. Saeidian et al. proposed an integrated legal-physical model to define spatial and semantic relationships for underground legal spaces. They used ShapeChange to create the XML file of the physical data model and exported the output into GML format [123]. In some cases, local formats like ePlan were used [15], while in others, ontology was used to combine different domains and to merge with other standards and formats. For example, Soon et al. proposed a semantic-based fusion framework by extending the LADM OWL ontology to integrate CityGML and 3D LandXML [124]. Similarly, Pauwels et al. explored ways to convert EXPRESS schemas of IFC into ifcOWL ontologies [125].

3.3. Using Databases

Several studies employed databases in their research; however, their primary objective did not revolve around developing a database specifically suited to 3D cadastral applications. These papers only utilised databases as a part of their research process without adhering to any database design principles. Several studies focused on data storage, spatial query analysis, and boundary representation. Meanwhile, others were engaged in the lifecycle of the 3D cadastral data. For most research in this area, cadastral data were converted into databases using a third software program. Analysing them provides valuable insights into how databases were utilised in various studies related to 3D cadastral data, shedding light on the broader applications and potential advantages of database usage in this field. These studies encompass various types of databases, including relational and non-relational databases. They cover a wide range of fields such as multipurpose land administration for cultural heritage areas [72], integrating the IFC-LADM and utilising 2D plans in creating 3D representation of the buildings [71], hybrid approaches involving integrating 2D and 3D survey data of property units [66,68,90] and visualising them on a web environment [73], and data structures and functionalities for the implementation of a 3D land management system [54]. Several papers have been published in various areas related to 3D cadastres that utilise databases as part of their work. These publications include storing 3D underground data and their utilities in spatial databases [84,86,91,99], 3D marine administration system [63,93], 3D indoor modelling [59], real estate valuation information model [64,96,98], link between the LADM and 3D crowdsourced data [97], 3D modelling of user movements in evacuation exercise [81], and 3D visualisation [83,95]. In addition, Koeva et al. investigated change detection based on point clouds in 3D indoor cadastre. They linked the change detection result to a 3D cadastre database [75]. Pantelios developed a QGIS plugin to facilitate the interaction with 3DCityDB for users without expertise in databases, SQL, programming languages, CityGML, and UML [94].

Multidimensional modelling is another aspect of cadastres that should be considered when designing a database. Storing and managing multidimensional objects and their topological relations can be quite challenging, particularly when dealing with time and time intervals. In order to address this issue, Ding et al. proposed a multidimensional topological data structure [102]. They considered various spatial and spatio-temporal objects based on the LADM including the boundary point, boundary line, boundary face, 2D spatial unit, 3D spatial unit, and time. Furthermore, changes in spatial objects were defined by adding a time interval. The conceptual data model was designed with three primary components: cadastral objects, geometry, and topology. According to their findings, for multidimensional objects, the ideal model should be independent of dimension and support the unified expression of topological relations. Their model was assessed using a case study and a variety of queries.

Döner et al. developed a prototype demonstrating the feasibility of a 4D cadastre using a case study of utility networks [9]. The motivation for this research was the challenges associated with modelling dynamic and multidimensional spatial information, as well as the related complex management tasks. Different alternatives for registering 4D utility networks were considered and analysed according to legal, organisational, and technical cadastral requirements. Underground utilities were imported into the Oracle Spatial database along with 3D geometric descriptions, and 3D data and time were stored using SDO_GEOMETRY and timestamp data types. Spatial queries were used to assess the model’s compliance with requirements, answering questions such as “what is the vertical distance between a parcel and a pipeline” or “is a pipeline at a particular distance from a cadastral parcel?”. Time can be incorporated into a cadastral database in two ways: event-based modelling and state-based modelling. As a result of the study, it was determined that a state-based model that combines 3D space with distinct temporal attributes is an appropriate solution. This approach has the potential to maintain temporal changes in utility networks, as well as to share and utilise geospatial information for multiple purposes [9].

Thompson et al. discussed the history of location changes and bi-temporal data that need to be recorded into a database and utilised to improve the accuracy of the boundaries. As a result of their findings, it is highly recommended to maintain the history within the live database [6]. Thompson et al. also suggested a 4D/5D schema by adding two forms of time to the three spatial dimensions which can be handled in cadastral databases [11].

A methodology for the efficient management of 3D cadastral data based on BIM was developed by Olfat et al. to streamline multi-story building cadastral data. The research is motivated by the problem of addressing the lack of a simplified and effective approach for modelling, storing, visualising, and querying 3D cadastral data. The authors used Autodesk Revit to prepare and model 3D cadastral data. They exported it to the IFC format, which was then stored in an Oracle Spatial database using a conversion model in FME software. Three main components were employed, including Reader (IFC entities as the data source), Transformer (performing conversions like translation, restriction, filter, and setting), and Writer (Oracle 3D spatial objects as the destination). Two significant challenges emerged during the mapping of IFC entities to Oracle Spatial tables: coordinate system transformation and wall features conversion. To tackle the first challenge, an FME transformer was considered to convert coordinates from local values to the Map Grid of Australia (MGA) system. The second challenge was resolved by introducing a Triangulator transformer, which splits wall geometry into triangular units, resulting in valid solid geometries in the 3D spatial database. Ultimately, the data were visualised using Cesium, and a few queries were used to verify the results [15]. This study offered a practical solution for streamlining the 3D cadastral data lifecycle, addressing data preparation, storage, management, and communication challenges.

Barzegar et al. developed a spatial query technique to identify different property boundaries, such as exterior, median, and interior boundaries [76]. This research was motivated by the challenge of extracting property boundaries assigned to the faces of building elements from IFC files in jurisdictions like Victoria, Australia. The paper proposed a methodology to extract building elements (walls, ceilings, and floors) and identify boundaries based on thickness, mathematical computations, and rules. They also attempted to extract faces of complex buildings, including oblique, curved, and holes, by subdividing them into smaller faces. They further suggested using 3D bounding boxes as part of their methodology. The findings demonstrated that this methodology works well with clean data. However, it was observed that errors in the input data could propagate into inaccuracies in the results of the boundary identification analysis. Consequently, data validation and cleaning are crucial steps during the data preparation phase to ensure reliable outcomes.

Rajabifard et al. designed an LADM-driven 3D land administration system for Malaysia to address the limitations of the existing 2D cadastral system in this country [69,77]. They proposed a methodology for calculating the height and for storing 3D data in the NDCDB, considering spatial and non-spatial elements based on the adoption of the LADM and the Malaysian country profile. To ensure database normalisation and minimise data redundancy, some entities within the LADM standard were merged into one class in PostgreSQL. The relationship between subclasses of a superclass was represented using a one-to-one relationship, and a separate table was created to handle complex relationships. Additionally, “look-up” tables were created to facilitate the management of code lists associated with specific attributes in the LADM. The study demonstrated that the cadastral infrastructure in Malaysia is ready for an upgrade, enabling the incorporation of 3D digital data using the standardised approach adopted by the LADM standard. Implementing the LADM-based approach would significantly streamline 3D cadastral registration, particularly in complex ownership scenarios.

Cemellini et al. developed a web-based prototype that combined 2D and 3D cadastres with a time component based on a server–client system architecture (Figure 9). Although their primary focus was on visualisation, they also designed a database schema by mapping the Queensland DCDB to the LADM [60]. Potential users carried out a usability test to assess the developed 3D cadastre prototype. Despite the efforts made to address the web-based functionality issues identified by users in the initial usability test, the results of the second usability test indicated that their research was still evolving. Therefore, additional activities need to be undertaken to resolve the existing user-friendliness limitations and to enhance functionality.

Tekavec et al. suggested a framework for 3D indoor modelling based on Slovenian cadastral data [59]. This research was driven by the need for indoor models as there are currently no solutions that enable acquiring large-scale indoor spatial data due to several limiting factors that present with the use of an indoor space. The final outputs utilised the IndoorGML standard, which offers a standardised data model designed to represent and exchange indoor spatial information, catering to indoor navigation and location-based services. They utilised raster floor plans as their data source, which were digitised, transformed, prepared, and stored as polyhedral surfaces in PostgreSQL. The transformed data were structured according to the IndoorGML framework and then written into the IndoorGML document. Their findings revealed several advantages, including centralised and easily accessible data, as-built information, and integration with RRRs associated with the building. However, they produced 3D geometries using extruded 2D polygons which did not offer many advantages over 2D geometries. So, in another study [61], they used 3D cadastre and BIM datasets as data sources. Using the simple features computational geometry algorithms (SFCGAL) library, they analysed available 3D building data to extract indoor navigation networks. The implementation was performed by the integration of FME as an extract, transform, and load (ETL) software and the PostgreSQL database with PostGIS and SFCGAL extensions. To evaluate the efficiency and performance of the network analysis, the processing and query execution times were examined. According to their analysis, the ST_3DIntersection function significantly reduced the query execution time. They found that geometry-based methods had limitations in identifying connections when geometries were spatially disjoint. In such cases, methods based on semantic information had an advantage. In this regard, they compared their approach to semantic-based approaches that utilise IfcRelSpaceBoundary entities to extract the navigation network from IFC datasets. Although the process was fast using attribute-based connections, it was discovered that the IfcRelSpaceBoundary entities contained errors, resulting in incorrect connections between spaces and doors [61].

Tekavec et al., in another study, worked on modelling 3D building data and explored the integration of their proposed data model, based on the LADM, with other standards like IFC, CityGML, and IndoorGML [20]. To address incomplete support for solids with internal holes in PostgreSQL, they introduced new tables with a Boolean attribute specifically designed to handle solids that have holes. The developed data model was based on indoor spaces touching each other at passages, meaning that 3D geometries of indoor spaces have shared faces. The proposed database implementation used the polyhedral surface to represent each indoor space, which means that the “touching” faces were duplicated. Consequently, the required storage space was increased. Additionally, the duplication could cause the data to be inconsistent. However, this approach offered several advantages over storing 3D geometries using the topological data structure. These advantages include (1) the ability to leverage the 3D functionalities of databases for managing the geometries, (2) direct access to 3D geometries without the need for constructing them from lower-dimensional features and their topological relationships, and (3) the ability to store the 3D geometries along with other attribute data. In another work, Tekavec et al. focused on simulating a large-scale 3D cadastral dataset and transforming it into a suitable format for storage in a spatial DBMS [74]. To avoid any issues with geometry conversion from FME, the geometries were triangulated, and then 3D buildings were inserted into PostgreSQL. A performance evaluation using spatial queries revealed issues with the ST_3DIntersection function, highlighting the importance of having a representative dataset during the design phase of 3D cadastral information systems.

Thompson et al. explored an integrated approach for defining 3D spatial units within the LADM. In their method, the “footprint” of the spatial unit was represented as a LA_BoundaryFaceString, linked to a set of more general faces (LA_BoundaryFace), which could be empty if necessary. Using this approach, 2D land parcels could be encoded, as well as volumes in 3D. According to their findings, this method was more storage-efficient than conventional polyhedrons. They discussed the approach from three points of views including a technique for capturing and validating mixed 2D and 3D cadastral data, an encoding method for transporting such data (e.g., LandXML or InfraGML), and a schema for database storage. They discovered that using a polyhedron attribute like GM_Solid for 3D spatial units is unsuitable for two reasons. In many instances, there is an overlap between the vertical faces of the polyhedron and the LA_BoundaryFaceString defined by the footprint, which can lead to redundancy and potential inconsistencies. Furthermore, GM_Solid is limited to representing fully bounded spaces. Consequently, they chose to associate LA_SpatialUnit with LA_BoundaryFace [82].

Borrmann proposed a spatial query language that supports different spatial operators, such as metric (closerThan, fartherThan), directional (above, below, northOf), and topological operators (touch, within, contain). A prototype was developed and displayed in a 3D environment with a touch operator using the Oracle database [78]. While they did not discuss 3D cadastres or conceptual data models, they presented a solution for using spatial operators in SQL statements.

Several publications focused on extending CityGML to create an ADE for modelling cadastral data. These projects typically involved creating a conceptual data model, converting it to an XML schema, importing data into 3DCityDB, and evaluating and visualising the results. As an example, Guntel et al. used FME to transfer CityGML data to ArcScene as a 3D geodatabase and, finally, to visualise data in CityGrid [87]. Li et al. developed a conceptual and relational database model to tackle data management and analyse problems of complex data fusion. By integrating CityGML and IFC4 classes, they developed a conceptual data model and defined mapping rules for transferring data into the PostgreSQL/PostGIS database. Complex classes and data types were identified, simplified, and mapped onto fewer tables according to the database’s interoperability. They analysed their model using some queries and visualised the result via QGIS [88]. On the other hand, Hanafi et al. proposed a conceptual model on the integration between both legal space (indoor) and legal objects using LADM Edition II and IndoorGML standards for strata purposes. They used ArcScene to store and retrieve data [89]. Other researchers, such as Hajji et al., presented an integrated approach based on CityGML and IFC which was implemented in ArcGIS [70]. Karim et al. developed a 3D model based on different methods of acquiring point clouds and storing them in a CityGML schema. They discussed accuracy and consistency issues and proposed quality checks for different problems involving the process of data acquisition and migration to the PostgreSQL [92]. Aringer et al. utilised the 3D city database importer/exporter, FME workbench, and 3D-PDF to store, manage, visualise, and update Lidar data of a Bavarian 3D building model [100].

Gürsoy Sürmeneli et al. proposed an ADE for a 4D (3D + t) cadastral data model which combines 3D spatial information with temporal attributes. Using time allows for the historical information and temporal inquiries of real estate to be noted. The research was motivated by the need for an open source 4D database to analyse the existing cadastral system in Turkey. They found that the LADM is not sufficient enough to show physical objects; therefore, an integrated LADM-CityGML data model was used, which allows for adequate representation of cadastral objects both legally and physically. The integrated data model was then transferred to the PostgreSQL database to eliminate the knowledge gap between the conceptual and logical models. The CityGML file was converted with Python code and the LADM data were exported using the 3DCityDB Importer/Exporter tool. However, there were still problems in transferring the model to the database since the normalisation principles of the developed conceptual data model did not fully comply with the database principles [55]. In another study, Gürsoy Sürmeneli et al. created a 4D cadastral legal model by leveraging the PostgreSQL database for storing their data. Their objective was to design a legal data model and corresponding database for a 4D cadastral system, incorporating international standards like the LADM. The study primarily focused on data modelling, and the developed 4D data model was tested using temporal queries [57]. The notable innovation lies in integrating the temporal dimension into the LADM and preserving relational aspects while transferring the created classes to the database. However, the model remains conceptual and represents cadastral objects without incorporating their physical aspects.

During the SLR process, we encountered similar papers in other fields such as BIM, Digital Twins, 3D GIS, and 3D city modelling that also utilised databases. It is valuable to understand how they designed 3D databases for their specific purposes. For instance, Li et al. [80] proposed an object-relational storage model to store IFC data by considering the object-based inheritance hierarchy of IFC (Figure 10). They utilised the Oracle database for storage and the IFC Engine DLL as a converter tool to convert IFC files to database tables. A key consideration in selecting Oracle was its object-oriented characteristics (Inheritance, Polymorphism, and Encapsulation). To determine whether there were any information errors or data losses during the exchange of data, a comparison was made between the generated model and the original model. In order to measure the efficiency of their storage model, the time required to transfer data between IFC files and databases was also recorded.

Another study by Solihin et al. stored 3D BIM data with geometry in Oracle, which supports the storage of 3D polyhedral geometry, and utilised octree decomposition for spatial indexing to perform a quick assessment of geometry-related operations such as checking topological relationships [79]. Sammartano et al. proposed a GIS-BIM approach for the creation of a 3D digital twin of Turin. They developed a public database schema in ArcGIS Pro using 2D parcel maps and Lidar data for the floor-scale only. To enrich the BIM, parametric connections were made to the public database to create a 3D Geodatabase. Visual Programming Language (VPL) rules were proposed for checking the connection and translation of parametrization between different databases [58]. An effort was made by Mignard et al. to integrate BIM and GIS into a facility management platform by developing an ontology to address the heterogeneity problem between BIM and GIS. They created a knowledge graph and populated it with information from standards like IFC and CityGML [65]. Solihin et al. focused on defining a database schema for BIM data. This research was motivated by the necessity to access data that are predominantly locked within specific BIM tools with limited capabilities to retrieve data using complex queries. The extraction of data from BIM remains challenging, even with open formats such as IFC. The schema was designed based on the star schema model that is commonly used in data warehouses. Despite its advantages, such as the simplification of data access and reduction in manual processes, there were some limitations like requiring considerable overhead for data manipulation and performance issues with spatial queries which take a long time to execute [85]. Toschi et al. presented the results of their project on geospatial data processing for a 3D city model, which aimed to efficiently utilise 3D data for smart city applications, integrating various data sources and technologies to develop a web-based geodatabase management system [67]. Li et al. proposed a spatial DBMS solution to manage integrated 3D city models at the precinct scale through multi-source heterogeneous data fusion. They implemented a Precinct Information Model (PIM) approach and created a database in PostgreSQL to test the usability of their solution [32].

Sun et al. developed a framework that allows 3D cadastre to be integrated with BIM and GIS (Figure 11), enabling the accurate representation of legal boundaries and visualisation of 3D cadastres in urban environments. A practical case study conducted in Sweden demonstrated that integrating cadastral data with BIM/GIS is feasible at both the conceptual and data level, enabling effective information exchange and improving 3D cadastral boundary representation [101].

In addition to relational databases, some research has explored the use of NoSQL databases. Unlike relational tables, NoSQL databases are non-tabular and store data differently [126]. These databases were introduced to store and process big data efficiently. Their main advantages are: (1) fast data reading and writing; (2) mass storage support; (3) easy expansion; and (4) low cost [127].

In this regard, Višnjevac et al. investigated the feasibility of utilising NoSQL databases in 3D cadastres [62]. This research was motivated by the inadequate 3D support offered by relational database management systems (RDBMS), particularly when dealing with large datasets. They found that NoSQL databases are well-suited for accommodating data models that lack strict definitions, making them a suitable choice for storing 3D cadastral data in formats like CityGML or XML. They are particularly advantageous for mixed models that combine traditional 2D cadastral registration systems with 3D cadastre elements. However, it is important to note that NoSQL databases still require ongoing development efforts to fully support all the requirements of 3D cadastres, including aspects like 3D spatial indexing, 3D queries, and 3D topology.

Da Purificação et al. developed a model for organizing a 3D cadastre tailored for historical and artistic heritage. They utilised OMT-G Designer to create a conceptual model based on LADM, which was then imported into MongoDB using the Robo 3T tool. To incorporate the 3D models into the BoundaryFace collection, a preliminary conversion to the 3D Tiles format was necessary. This conversion process provided a JSON file as one of the output data, which was subsequently inserted into the database and visualised on the Cesium platform [56]. Their data were obtained by capturing images and generating 3D models, which need to be investigated to determine if they meet the requirements of 3D cadastres.

3.4. Designing Databases/Physical Implementation

During the paper selection phase of our SLR method, we identified only 26 papers that specifically discussed the design of 3D cadastral databases. Our criteria for including these papers were:

• Their primary focus was designing a database for 3D cadastre or 3D land administration.
• They implemented a 3D database or cadastral system, particularly designing geodatabases or implementing physical data models.

According to the research objectives, the data collected from each source related to designing a database are compiled in

Table 4. Summary of database approach from literature review.

Reference	Conceptual Data Model	Data Preparation—ETL	Query Analysis	Evaluation	Technology
Gürsoy Sürmeneli et al. [55]	Integrated of LADM–CityGML	Importer/Exporter tool of 3DCityDB, Python code	Not used	Visualisation	3DCityDB, PostgreSQL/PostGIS, GeoServer, CesiumJS
Gürsoy Sürmeneli et al. [57]	LADM	SQL commands	Non-spatial queries	Query	PostgreSQL/PostGIS
Da Purificação et al. [56]	LADM	Robo 3T	Not used	Visualisation	OMT-G Designer, Robo 3T, MongoDB, CesiumJS, MeshLab
Liamis et al. [113]	CityGML	Importer/Exporter of 3DCityDB	Not used	Hardware, Time processing	ArcGIS, Enterprise Architect, ShapeChange, FME, 3DCityDB, FZK, Google Earth Pro
Olfat et al. [15]	IFC	FME	Non-spatial queries	Query, Visualisation	Revit, FME, Oracle, CesiumJS
Barzegar et al. [76]	IFC	FME	Spatial and non-spatial queries	Query, Visualisation	Revit, Psycopg2 API, FME, PostgreSQL/PostGIS
Barzegar et al. [30]	IFC	FME	Spatial and non-spatial queries	Query, Visualisation	Revit, ArcGIS Pro, FME, PostgreSQL/PostGIS, Solibri AnyWhere
Rajabifard et al. [69]	LADM	QGIS	Non-spatial queries	Query, Visualisation	PostgreSQL/PostGIS, QGIS, GeoServer, CesiumJS
Van Bennekom-Minnema [111]	LADM II	GeoDjango ORM	Non-spatial queries	Query, Visualisation	Django/GeoDjango, PostgreSQL/PostGIS, Object-Relational Mapper (ORM)
Sammartano et al. [58]	Not used	Dynamo, ArcGIS Pro	Spatial and non-spatial queries	Visual Programming Language	ArcGIS Pro, Revit, Dynamo, EDISCO DB
Hajji et al. [70]	Integrated of CityGML-IFC	FME	Not used	Geometric validation, Semantic validation, Visualisation	Revit, FME, ArcGIS, FZK Viewer
Halim et al. [104]	CityGML	SketchUp, FME, Importer/Exporter of 3DCityDB	Non-spatial queries	Query	SketchUp, FME, 3DCityDB, CityDoctor, CityEditor, ArcGIS, PostgreSQL/PostGIS, QGIS
Tekavec et al. [61]	IFC	FME	Spatial queries	Hardware, time processing	FME, FZK Viewer, PostgreSQL/PostGIS, SFCGAL library, SketchUp
Cemellini et al. [60]	LADM	SQL commands, Encoding approaches	Spatial and non-spatial queries	Visualisation, Questionnaire	PostgreSQL/PostGIS, SQL, CesiumJS, Apache Tomcat, GeoServer
Višnjevac et al. [103]	LADM	Scripts in R, Exchange file formats	Non-spatial queries	Query, Visualisation	QGIS, MongoDB, NoSQL Viewer, CesiumJS, Rest API, JSONP
Li et al. [88]	Integrated of CityGML-IFC	Unclear	Spatial and non-spatial queries	Query, Visualisation	PostgreSQL/PostGIS, QGIS
Zulkifli et al. [105]	LADM	Mapfile	Not used	Query, Visualisation	PostgreSQL/PostGIS, Mapfile, QGIS, Enterprise Architect, C# NetCore, XSD, XDocument
Alattas et al. [27]	Integrated of LADM- IndoorGML	Not used	Not used	Not used	PostgreSQL/PostGIS, Enterprise Architect
Alattas et al. [28]	Integrated of LADM- IndoorGML	Revit, in-house ODBC	Non-spatial queries	Query, Visualisation	Revit, Open Database Connectivity (ODBC), PostgreSQL/PostGIS, Enterprise Architect
Kara et al. [98]	LADM	Manual (SQL commands)	Non-spatial queries	Query, Visualisation	Oracle Spatial, QGIS, Oracle SQL Developer Query Builder, Oracle SQL Developer, INTERLIS, Enterprise Architect
Kalogianni et al. [121]	LADM	Not used	Not used	Not used	INTERLIS, Enterprise Architect
Solihin et al. [79]	IFC	Unclear	Spatial and non-spatial queries	Query, Time processing, Visualisation	Oracle
Li et al. [80]	IFC	IFC Engine DLL, OCILIB	Non-spatial queries	Time analysis, Data model comparison	Revit, IFC Engine DLL, OCILIB, Oracle
Thompson [106]	LADM	Not used	Spatial and non-spatial queries	Query, Time processing, Visualisation	PostgreSQL/PostGIS, Google Earth, Web Map Server,
Mutiarasari et al. [107]	Not used	AutoCAD Map 3D, Google Earth, FWTools	Spatial queries	Query	AutoCAD Map 3D, Google Earth, FWTools, PostgreSQL/PostGIS, X3D, AutoCAD Map 3D
Zulkifli et al. [110]	LADM	Manual (SQL commands)	Non-spatial queries	Query, Visualisation	Oracle Spatial, Bentley MicroStation, Enterprise Architect
Zulkifli et al. [108]	LADM	Manual (SQL commands)	Non-spatial queries	Query, Visualisation	Oracle Spatial, Bentley MicroStation
Spirou-Sioula et al. [66]	Not used	Manual (SQL commands), Autodesk FDO Provider for Oracle	Not used	Visualisation	Oracle Spatial, ArcInfo, AutoCAD Map 3D, ArcGIS, ArcScene, ArcSDE, SketchUP,
Budisusanto et al. [109]	LADM	AutoCAD Map 3D, Google Earth, Autodesk 3DS Max, FWTools	Not used	Query, Visualisation	AutoCAD Map 3D, Google Earth, Autodesk 3DS Max, FWTools, PostgreSQL/PostGIS, Enterprise Architect, Delphi programming language/GLScene

, which outlines the conceptual data models utilised (IFC, LADM, CityGML, Integrated, or others), the data preparation and transferring methods employed (FME, SQL commands, 3DCityDB, Script), the query analysis techniques applied (spatial/non-spatial), the evaluation metrics adopted (query, visualisation, hardware and time processing, questionnaire, computational analysis), and the technologies utilised (software, libraries, and tools) in previous research studies.

In this regard, Alattas et al. [27] designed a logical model for indoor navigation. This study aimed to evaluate the LADM-IndoorGML conceptual model and find the potential and limitations of the conceptual model through the process of conversion into a technical model. They employed Enterprise Architect modelling tools to transform the UML diagrams into table diagrams. However, they encountered some issues that were related to the transformation such as inheritance, primary key and foreign key, multiplicity, constraints, data type, spatial data type, code list classes, and indexing. To tackle most of these problems, they suggested manual steps. For example, most spatial data types and defined data types such as “Oid” were converted to “varchar” by the software during the transformation, which was solved by editing the SQL codes manually. Some issues remained unresolved; for instance, the transformation model did not convert the multiplicity of attributes into tables, and they found no solutions to rectify this issue. This paper demonstrates that despite using Enterprise Architect software, there are still numerous issues that necessitate manual adjustments [27]. Then, they selected some classes of the proposed conceptual model to create a database in PostgreSQL. Afterwards, a 3D building was created in Revit and imported into the database by in-house software using Open Database Connectivity (ODBC), semantic data and schedules were directly exported from Revit, and all properties, including 3D geometry, were linked using a unique geometry ID. Nevertheless, the tables associated with LADM were manually populated [28].

Zulkifli et al. worked on the utilisation of the LADM, in particular the parties, RRRs, and their integration with spatial data within both 2D and 3D cadastral environments. The conceptual model was translated into a physical model comprising seven tables, implemented in Oracle Spatial. The outcomes of the 2D and 3D queries were presented visually using Bentley Microstation [108]. Similarly, in another work, they designed a database and developed a prototype grounded in the LADM, concentrating specifically on the 3D spatial aspect represented by strata objects. Their objective was to delineate a practical approach for realizing a 3D cadastral registration system based on the LADM, aligning it with the Malaysian legal framework. The development of their prototype commenced with LADM-based data modelling, encompassing the selection of relevant classes and necessary extensions. Special attention was given to migrating data from the existing database in .xml format to an open-source PostgreSQL/PostGIS database. It was accomplished through the implementation of an intermediate mapfile. The output of the converter was then imported into a database. In their approach, code lists were implemented by their own tables, and due to potential updates, these lists were versioned, incorporating attributes like beginDateTime and endDateTime. To facilitate the conversion from a conceptual UML class diagram to a technical model, the researchers employed Enterprise Architect, involving manual steps as part of the process. For 3D visualisation and editing, data from the PostgreSQL database could be accessed through QGIS software. Their model had limitations such as a lack of multi-user functionality, unsuitability for handling large datasets, omission of certain tables, and absence of web-based interface development (being restricted to a desktop GIS interface) [105]. In another study, Zulkifli et al. developed a prototype to evaluate the Malaysian LADM country profile with the steps presented in Figure 12. They employed modelling tools like Enterprise Architect to automatically convert the conceptual model into the technical model. However, it was necessary to make some manual adjustments to the technical model. As part of this process, constraints, derived and multiplicity attributes, and indexing and clustering were discussed. This model was then populated with existing sample data and stored in an Oracle database. Access to these data was facilitated through Bentley MicroStation for 2D and 3D visualisation and editing and by using SQL for data retrieval. The prototype exhibited some limitations similar to the previous work, leaving room for future enhancements [110].

Furthermore, Zulkifli et al. designed a conceptual and technical model for registering 3D objects based on the LADM, emphasising semantic interoperability, and clarifying terminology concerns (e.g., lots, parcels, strata, 2D, 3D). For assessing the developed prototype, they employed Oracle Spatial as the database and Bentley Microstation for visualising SQL query results. However, their prototype had limited functionality and was confined to a small area [118]. Zulkifli et al. also created a prototype and addressed the registration of 3D strata objects and adapting local schemas to comply with the LADM. This study outlined the practical steps for achieving LADM-based 3D strata object registration in Malaysia, specifically transitioning from the current 2D representation to 3D for aspects like parcel units, accessory units, common property units, limited common property units, and land parcels [119]. Similarly, Nasorudin et al. developed a strata object database based on the LADM to address the shift from 2D to 3D geospatial databases in Malaysia. This study described the design process of a 3D geospatial database, including conceptual, logical, and physical models. Challenges in 2D databases were discussed and the need for such a database in the future was emphasised [117].

There have been some other attempts to develop a prototype based on data stored in a DBMS such as Oracle Spatial, retrieve data using queries (mostly spatial queries), and visualise them in MicroStation GeoGraphics (Bentley) [114,115].

A cadastral schema based on the LADM was proposed by Thompson that preserves history while developing all levels of encoding, variable accuracy, and topological purity. Subsequently, a database was created and loaded with Queensland cadastral parcels. To evaluate the performance of the schema, they conducted time and speed analyses under different scenarios. They found that the number of face strings was roughly equal to the number of parcels, which implies a balance in the retrieval speed of parcels and linework. Since the “LA BoundaryFaces” table only contained a small number of hand-encoded 3D parcels, 3D timings were not attempted [106].

Barzegar et al. designed a 3D database schema and proposed a methodology for transforming BIM data into the designed schema. The schema accommodates an IFC file for 3D cadastre (legal and physical) data. The paper proposed a methodology that contained seven steps including designing the architectural model and adding legal data, georeferencing, IFC data validation and cleaning, mapping process, database data validation and cleaning, spatial analysis, and visualisation. They used ArcGIS Pro for georeferencing and locating the data in the right position. The model was evaluated using some validation tools in FME, and the results of the spatial and non-spatial queries were analysed using FME Data Inspector [30]. The proposed 3D database supports both spatial and attribute queries, which can be used for 3D cadastral data analysis. In addition, a new method for modelling legal spaces with oblique walls and roofs was provided. This study highlighted that creating a 3D spatial database for 3D urban land administration is highly affected by the designing stage and exact design instruction is needed.

A database consisting of five tables was created by Budisusanto et al. [109] to investigate the registration of property ownerships in multi-level apartments. The study delves into the application of the LADM and employs Delphi and PostreSQL/PostGIS to handle spatial data and attributes, facilitating the registration and visualisation of multi-level apartments while applying the principles outlined in the existing legal framework and executive orders associated with the registration of strata titles for property objects.

Višnjevac et al. explored the strengths and weaknesses of NoSQL databases and designed a 3D cadastral prototype based on the LADM and stored data in the MongoDB database [103]. While the system enabled 3D cadastral data maintenance and basic interactive 3D visualisation, it required further development to fully support a modern 3D cadastral system. For instance, in terms of topology rule validation, there were no options to check if there were intersections or gaps between building units. Also, the issue with the developed application was that there were no options for spatial queries such as the selection of neighbouring objects, which was not supported by spatial operators in MongoDB.

Liamis et al. proposed GRextADE for storing and exchanging 3D cadastre data in Greece with the aim of creating a national standard. Their ulterior goal was to extract specific data from the Greek Government Digital Building ID (DBID platform) and automatically insert it into the 3DCityDB database where a 3D model of the city—according to the CityGML specifications—would be present. To achieve this, they used FME to create a GML file, which was then converted into a valid XML dataset. Visualisation was performed with three 3D visualisers: FME Inspector by Safe Software, the open-source FZK, and Google Earth Pro. Finally, they imported the data into 3DCityDB using the Importer/Exporter tool and evaluated their extension by testing it with various amounts of data and comparing the processing time and hardware [113]. However, the model was limited to LOD1 and was created by extruding 2D maps rather than utilising 3D data.

Halim et al. developed a 3D city database for phase 2 of the SmartKADASTER Interactive Portal (SkiP) platform in Malaysia, utilising 3D CityGML database schema [104]. The SmartKADASTER system did not store the 3D city models in any particular 3D database scheme, format, or standard, but instead managed the city model as a file-based system for visualisation purposes. So, this research was motivated by the need to store, manage, and analyse data in a structured manner. The 3D building models were constructed with Trimble SketchUp software and later imported into the respective CityGML LoD1, 2, 3, and 4 models (*.gml). The models were then imported into the PostgreSQL database based on a PostGIS schema and CityGML schema (3DCityDB). A 3D Unique Parcel Identifier (UPI) was introduced to link the respective 3D LoD buildings with their corresponding 2D cadastral lot. However, it was challenging and not straightforward due to different scenarios for building; for example, party wall buildings such as terrace houses or shop lots, which was solved by reconstructing them into individual models and was based on the exact building footprints. Before migration to the database, quality assurance and control (QAQC) was applied to the CityGML LoD models and schemas using the FME workbench, 3DCityDB, and CityDoctor. The 3DCityDB utilised SQL functions to create a more compact CityGML schema for PostgreSQL, resulting in a spatial relational database schema with fewer tables. Additionally, it allowed for easy integration with external GIS and ETL software applications, enabling them to enrich the 3D city model with additional information in the corresponding database tables. Tools like QGIS and ESRI ArcMap were used to edit, update, and delete features/objects in the database [104]. It is worth noting that relying solely on CityGML predominantly emphasises the physical aspects, while it may not facilitate the determination of RRRs.

Gkeli et al. proposed a new method based on crowdsourced data and a server–client system architecture (Figure 13) focusing on investigating technical aspects for capturing and integrating 3D crowdsourced cadastral data. The technical framework comprised the server side, involving the server of ArcGIS Online for storing collected data, and the client side, utilising a mobile application as a data capturing tool [112]. They used the LADM as the base of the conceptual model and new classes such as LandParcel3D were created for the geometry of the 3D spatial units. The main conclusions determined that the proposed technical solution has huge potential for the fast and economic implementation of 3D cadastral surveys as it can produce an accurate and reliable 3D information model, depending on the accuracy of the available basemaps.

Bar-Maor et al. implemented the LADM within ArcGIS, specifically focused on its integration with the ArcGIS Parcel Fabric. The Parcel Fabric in ArcGIS served as a framework for parcel data management, enabling editing and sharing capabilities in both single-user and multiuser environments, facilitated by web services and services-based architectures. Then, they detailed the process of migrating, extending, and configuring the LADM within ArcGIS, as well as quality management best practices. They argued that the parcel fabric aligns with the LADM and allows users to create LADM-compliant schemas. Additionally, it was managed through an Enterprise geodatabase, supported multiuser editing, and conformed to the LADM’s abstract test suite specifications [25].

Govedarica et al. proposed a roadmap including four phases for designing and implementing a cadastral system in Serbia including the LADM’s country profile development, definition of real estate cadastres’ business processes, database implementation and data migration, and the development of software solutions. They proposed desktop and web software solutions based on the principles of a Model-Driven Architecture (MDA) and Service-Oriented Architecture (SOA) [116].

Van Bennekom-Minnema investigated the possibilities and limitations of the Survey Package of the LADM’s implementation based on the Model Driven Architecture (MDA) approach. As a result, they developed a prototype which was used for the transformation of a Platform-Independent Model (such as LADM) and a Platform-Specific Model (such as PostGIS) [120]. In another study, van Bennekom-Minnema explored the application of GeoDjango, utilising Object-Relational Mapper (ORM), to implement the LADM II [111]. They encountered challenges during the manual entry of classes into the Django model, such as issues related to attribute inheritance and compliance with LA_RRR invariants. They discussed and implemented attribute constraints, like data types, mandatory/optional fields, and maximum lengths. This implementation also automatically generated a web-based graphical user interface (GUI) for data manipulation. The proposed approach can be used for future web applications, combining LADM classes with the ORM for data manipulation, offering web-based GUIs to interact with the user.

Kalogianni et al. developed a prototype of a 3D multipurpose land administration system based on the LADM which complied with the Greek national standards. This research was motivated by the need to derive a technical model, a database schema, or a data exchange format from a UML class diagram. They designed a UML diagram in Enterprise Architect and INTERLIS to transform data to a physical model [121]. Kalogianni et al. in another work [122] reviewed integrated conceptual models and LADM implementations. This research was motivated by the necessity to bridge the gap between conceptual and technical approaches and to clarify the relationships between legal and physical concepts and the need for more formal semantics in integrated models. As a possible solution to these problems, they suggested an integrated LADM/INTERLIS approach.

A comprehensive and valuable attempt to present different aspects of 3D cadastres including DBMSs was made by Stoter et al. [1,29]. They explained spatial data modelling and the implementation of conceptual and logical models for a 3D cadastre. Different technical aspects required in DBMSs were investigated including geometrical primitives, topological structure, and spatial analysis. Capabilities of different software for accessing and retrieving data in a Geo-DBMS and for validation and visualisation were also discussed. A prototype was developed to validate the proposed data model based on different case studies.

Mutiarasari et al. developed a 2.5D topology-based approach for storing 3D cadastre data. They established a topology schema with four tables, namely, node, edge, face, and relation, to fulfil topological needs. Additionally, they generated 3D models in a CAD format, which were subsequently transferred into KML for smooth conversion into spatial database geometries. The assessment encompassed various queries, although they encountered limitations in their lack of 3D spatial data. The findings help determine if open-source database technology is capable of effectively supporting the management of 3D spatial data [107].

After reviewing the literature, it is evident that most studies have concentrated on using databases or transferring data between different software applications, while fewer have addressed the development of a database for 3D cadastres specifically. Additionally, a considerable part of existing practices for constructing a 3D cadastral storage system relies on ETL tools such as FME to transfer files to a database. It is apparent that these approaches present significant challenges when it comes to effectively storing, editing, manipulating, querying, retrieving, managing, and analysing 3D cadastral data. In the next section, the challenges of different approaches and designing a conceptual model and converting it to a logical and physical model will be explained. Additionally, we will discuss the technologies employed in the process, elaborate on the tools used for the ETL process, explore query processing, and investigate evaluation metrics.

4. Discussion, Challenges, and Knowledge Gaps

According to the current practices, existing 3D cadastral databases do not meet the requirements of cadastral systems. The literature has not been able to implement an efficient database management system due to the lack of a robust database schema that fulfils all the aspects related to cadastre, guarantees data integrity and consistency, and is capable of handling large spatial datasets optimally. This section discusses the findings and accomplishments derived from reviewing the literature, as well as the benefits and drawbacks of existing approaches for storing and managing 3D cadastral data in either relational or non-relational databases or flat file formats. Various challenges and limitations encountered during the database design process, including conceptual design, transformation into logical and physical models, ETL processes, and query analysis are described.

The literature review presents a comprehensive analysis of various aspects related to 3D cadastral databases, which are summarized in Figure 14. In terms of conceptual data models, the studies explored standards including LADM, IFC, and CityGML, as well as alternatives such as IndoorGML and LandXML or a combination of these standards. The query analysis encompasses both spatial and non-spatial queries, emphasising the diversity of analytical needs within 3D cadastral contexts. However, 3D spatial queries remain more complex and require further research. The evaluation criteria include considerations of the hardware and processing time, visualisation of the query output, and user feedback through questionnaires. The management of 3D spatial data requires different technologies for various aspects, including data preparation, data transformation, data storage, and visualisation. It is important to note that there are more tools and software available; however, we focused only on those we found during literature review. For data transformation and ETL processes, FME has been widely used, followed by the Importer/Exporter of CityGML and JSON as the exchange format. In addition, researchers tended to use relational databases such as PostgreSQL/PostGIS and Oracle Spatial. Recently, CesiumJS has attracted considerable attention in terms of visualisation.

File-based approaches challenges: File-based solutions have significant issues, such as data isolation, redundancy, application dependency, scalability, integrity and consistency, security, and concurrent access of the data [16,17,103]. Since cadastral data are dynamic in nature and are subject to ongoing updates, any changes in data require the entire file to be regenerated and redeployed [15]. Consequently, this type of cadastral data storage makes it difficult to access, manage, query, or analyse the data effectively. DBMSs can eliminate most of the challenges associated with file-based approaches.

Challenges of conceptual design and standards: A 3D cadastral data model should meet all the legal, physical, and relationship requirements including multidimensional data and their topological relationships, dynamic data, complex and irregular shapes, and so on. Assigning property boundaries to physical objects highly depends on the spatial integrity of the model and adopted design methods [3]. Moreover, to ensure that the database designed meets all of the associated requirements, a guarantee must also be provided [30]. There have been many attempts to develop international standards over the past few years. The most relevant international standard to 3D land administration is the LADM [128]. Although LADM Edition I is widely used, it is only a conceptual model without specific implementation guidelines, so it requires further improvement in providing implementation instructions, covering land administration functions, supporting tenure security, and extending its scope [14,69,129]. LADM Edition II is currently under development and will cover different areas, including a generic conceptual model and land registration suitable for designing a cadastral conceptual data model, as well as an implementation [2,129]. As the document has not been officially released, an evaluation will be required after publication to assess its suitability and capabilities.

Other standards are commonly used in this field, such as CityGML and IFC, which offer conceptual data models for physical aspects but do not support legal requirements. Furthermore, since these standards are not explicitly designed for 3D cadastral purposes, other challenges will arise. For instance, extracting faces of solids from an IFC file is impossible since they are not considered separate objects [76]. In addition, the IFC standard contains many unnecessary classes, which increase its complexity and do not contain attribute/spatial data or are not necessary for 3D cadastres [15]. To provide better functionality, the IFC file should be mapped based on the requirements of a 3D cadastral database, which leads to reducing the number of tables and entities in the database and increasing its functionality. Another problem is that cadastral registration requires as-built data, which are not typically included in IFC models [20].

Conceptual design— Challenges of integrated data models: Integrated models have been proposed to address mentioned issues and to take advantage of other fields such as digital twins, BIM, and GIS to enrich 3D cadastres further [130]. These models have been formulated to meet the requirements for 3D cadastres in different domains such as underground space management, marine space, land and property valuation, indoor navigation, urban planning, real estate and property management, and facility, energy, and utility networks management. However, integration of them will pose new challenges in terms of interoperability and consistency due to incompatibility in geometric and semantic coherence, semantic mapping, coordinate systems, scope of interest, and data structures [5,32,131,132,133,134,135]. It will sometimes be impractical and time-consuming due to the complex data structure [55]. Changes in the conceptual design affect the final database and its performance. As current standards such as LADM and CityGML continue to evolve, integrating new data models and keeping them up to date can be challenging. So, it might be required to adjust or modify the final conceptual design in order to ensure ongoing compatibility and data reliability.

DBMS selection challenges (relational and non-relational databases): The literature review in the previous section indicates that relational databases are more popular than other types of databases. They support a wide range of spatial data types, spatial access methods, and a standard query language, in addition to providing high-efficiency spatial indexing structures and geometrical and topological analyses. Moreover, they link the geometric modelling of manmade and natural geo-objects [136]. Despite these advancements, RDBMs provide limited support for 3D objects and operations and do not fully satisfy all 3D cadastre requirements [62]. DBMSs must at least meet the following primary requirements:

• Supporting appropriate data type for 3D spatial data without changing or losing information during data migration or insertion;
• Modelling regular and irregular surfaces;
• Storing boundaries with complex structures such as oblique and curved ones;
• Modelling moving objects such as coastline and river boundaries;
• Supporting temporal aspects, time intervals, and versioning;
• Modelling multidimensional objects;
• Covering topological, geometrical, and directional relations as well as metric and Boolean operators;
• Providing 3D spatial functions;
• Handling large datasets;
• Ensuring data quality and validation;
• Defining spatial indexes;
• Optimizing storing and retrieving.

According to some researchers, land administration data are structured, so relational databases are the most appropriate method of storing them [31]. In contrast, semi-structured data organisation techniques have recently become increasingly popular in land administration, including GML, XML, and RDF [137], which can be easily adapted for use in NoSQL databases. Their popularity is due to their data storage and exchange simplicity.

Some papers have discussed that NoSQL databases have the potential to overcome the limitations of relational databases, such as their strict schema and the difficulty of dealing with large datasets [62,103]. Considering their flexibility to support non-strict data models, the NoSQL databases can store 3D cadastral data in different formats such as GML or XML [62]. The main drawback of using an NoSQL is that they do not guarantee ACID rules, which are often crucial for land transactions [138]. This can be problematic when transactions involve legal aspects of 3D cadastres, which require high data consistency [62,139]. In addition, NoSQL systems typically have their own APIs and do not support standards such as SQL, which is the most commonly used query language in relational databases [140]. On the other hand, NoSQL databases provide a smaller amount of available 3D spatial functions than relational databases. For example, there are no options for spatial queries such as selecting neighbouring objects or spatial operators for topology rules like checking intersections or gaps between building units [103].

Table 5. Comparison between NoSQL databases and RDBMS [142].

Features	RDBMS	NoSQL
Data	Structured	Structured, Unstructured, Semi-Structured
Schema	Fixed	Dynamic
Scalability	Vertical	Horizontal
Compliance	ACID	BASE
Architecture	Centralized	Distributed
Consistency	Strict	Eventual
Query Language	SQL	OO API, SQL Like
Performance	Slow	Fast

summarises the comparison between NoSQL databases and RDBMSs. However, comparing them in detail is beyond the scope of this study. Further information can be found in [126,127,138,141,142,143].

Logical design and conversion challenges: Since most of the developed 3D integrated data models are designed at the conceptual level, there is still a knowledge gap with logical data models, which are the next processing step in fully-integrated 3D data model stage [55]. In other words, fully transferring conceptual UML models to logical and physical database environments is still a major problem in the literature [55,57]. The transformation involves several issues, such as implementing inheritance, referential integrity and column constraints, multiplicity, methods, spatial data types, user-defined data types, normalisation, code lists and multivalued attributes, and so on. Most of these issues require manual intervention; however, some remain unresolved.

Physical design challenges: Spatial indexing is a crucial part of 3D data management, which enables efficient searching. Several strategies have been developed for indexing multidimensional data; however, creating appropriate 3D indexes remains a research challenge [12]. In addition to domain and referential integrity constraints, DBMSs should address general constraints, such as those in the LADM. Alternatively, triggers can be used to enforce some constraints. There may be instances where some or all of the general constraints are not supported by the system and are required to be incorporated into the application [144]. Moreover, it is essential to ensure that the cadastral system is accessible to a wide range of users. Therefore, another consideration is how users should access the cadastral database and what roles and permissions they should be granted and what controls should be in place to protect access to the database [1]. In addition, some aspects of physical design should be considered, including data security, backup and recovery, data storage and file organisation, scalability and extensibility, performance optimisation, clustering, and so on [24,144].

Data Migration and ETL process challenges: Data transformation and migration are important steps following the design of a database. Transferring data into a database mostly follows an ETL process that involves extracting data from various sources, transforming them to meet the requirements of the target system, and loading them into the destination database. Mapping and transforming the data to match the structure of the target database can be challenging. Georeferencing, for instance, is a necessary step that must be taken to ensure that the geometries from different files stored in a database share the same coordinate system and Spatial Reference Identifier (SRID) [30]. In addition, it requires data validation, ensuring compatibility (internal and external), spatial consistency, and integrity throughout the data transformation [145]. During the process of data exchange and mapping, errors, loss of information, and data corruption may occur [30,55,80].

An overview of the challenges involved in storing and managing 3D cadastral data including file-based approaches, databases, and associated steps including conceptual design, DBMS selection, logical and physical design, and ETL and data transformation issues is provided in Figure 15.

In summary, supporting fully 3D functions, modelling 3D spatial data topologically and geometrically in a DBMS, handling large datasets, and managing both 2D and 3D data with high performances is still a knowledge gap. While there have been attempts to develop database schemas for storing 3D cadastral data, a comprehensive solution that meets all the requirements for effectively storing, editing, manipulating, querying, retrieving, managing, and analysing these 3D cadastral data has not yet been presented and remains a major research gap. It should be mentioned that some of the papers in the literature were old and because of developments in technologies during recent years some of the issues have been resolved. On the other hand, the new tools, technologies, and standards require further investigation to examine their new capabilities. There is still a research gap to identify the requirements of a 3D cadastral database system and to determine whether current technologies meet them or not.

5. Conclusions

This study conducted a comprehensive review of the existing literature regarding the storage and management of 3D cadastral data, with an emphasis on the fundamental steps of database design. Research in this area was motivated by the need for an efficient 3D cadastral DBMS. There has been considerable effort invested in the development of 3D cadastres, but there is no operational 3D land information system that meets all of the requirements and fully utilises all the potentials. As part of our contribution, we identified different approaches, technologies, challenges, and principal steps involved in developing a 3D cadastral database. This study addressed a range of research questions including (i) current 3D data storage methods, (ii) functionality, maturity, tools, and technologies used, (iii) limitations and challenges involved in each step, and (iv) recent trends, gaps, and future directions. Following the SLR protocol in conjunction with the snowballing methodology and searching in Scopus, FIG archives, and Google Scholar databases, 108 studies including journals, conferences, books, and PhD and master’s theses were recognised as the most relevant to this study. Within this set, 27 papers focused on technical concepts and challenges or proposed frameworks and workflows and 55 papers incorporated databases primarily for data storage, while only 26 papers specifically concentrated on the design of a database for 3D cadastres.

Methods of 3D data storage and stages in the lifecycle of database design and system development were discussed along with the challenges and limitations of each. Identifying and overcoming these roadblocks is crucial to the development of an efficient cadastral database. File-based approaches are no longer suitable due to their limitations in ensuring data integrity, consistency, and efficient management. While it is preferable to use existing international standards and conceptual data models rather than to develop local data models, there are currently no standards that meet all the requirements. Accordingly, most studies have proposed integrated approaches to resolve their problems; however, new challenges have appeared that must be addressed. Furthermore, there was no detailed discussion of the integrity and quality control of these models. Although NoSQL databases can offer high performance, especially when dealing with large datasets, they are still in their infancy and do not support 3D spatial operations.

The importance of the following database design principles was highlighted in this research. Nevertheless, converting conceptual data models into logical and then physical data models presents many challenges. Several of these issues can be resolved manually; however, others remain unsolved. The potential of automatically converting conceptual models into technical models is still a knowledge gap. Moreover, data migration and ETL processes require significant time and resources. Choosing the most optimal transformation method is vital due to the complexity and size of 3D cadastral data. Moreover, validation and quality assurance and control (QA/QC) are required during the transformation, both prior to inserting data into the database and afterwards to ensure data quality and prevent any data loss. Additionally, transferring different data into a database requires data integrity and consistency, so another challenge is resolving interoperability issues.

In order to address the existing research gaps in 3D cadastral databases, a 3D database schema that fully accommodates land administration requirements is in high demand. Although this research discussed some of the main advantages and disadvantages of databases, a comparison between file-based and database approaches, as well as choosing an appropriate DBMS, is beyond the scope of this study. Therefore, selection of the appropriate database for 3D cadastres remains a knowledge gap that requires subsequent research. Furthermore, it is necessary to investigate the new technologies and capabilities of existing databases in terms of supporting different spatial relationships and functions. Finally, as modern vertical architectures and infrastructures continue to evolve, both above and below ground/water, and as technology advances constantly, ongoing updates are essential. As an example, LADM Edition II is currently under development and will be officially released in the future. A thorough examination of its conceptual capabilities and implementation potential is strongly recommended.