Visualization of 3D Survey Data for Strata Titles

Major cities and urban areas are beginning to develop and use 3D properties and public facilities. Consequently, 3D cadastral surveys are increasingly being employed for strata unit ownership registration as a part of land administration services. At present, most national land information systems do not support 2D and 3D cadastral visualizations. A field survey or validation survey is required to determine the geometry of 3D spatial units for property registration. However, the results of 3D surveys and mapping are not stored in the land information system. This work aims to integrate 2D and 3D geospatial data of property units collected from cadastral surveys with their corresponding legal data. It reviews the workflow for the use of 3D survey data for first-titling of 3D properties in Indonesia. A scenario of use and a prototype were developed based on existing practices and the possibility of extending Indonesia’s Land Administration Domain Model (LADM) to represent 3D units. Data submitted to the prototype as 3D geometries was survey data from 3D cadastral surveys or validation surveys utilizing terrestrial survey methods. The prototype used PostGIS and Cesium Ion to store 3D geometries of data from six 3D surveys. Registrars in local land offices could use the prototype to undertake strata unit registration that establishes a relationship among geospatial features and their survey documents and legal documents. Cesium JS was used as a 3D browser, customized as a web application, to manage and visualize 3D survey data to support strata title registration. The results demonstrate that the first titling of 3D cadaster objects could be conducted and properly visualized in Indonesia by extending the existing LADM with more support for 3D spatial representations and survey documents.


Introduction
The collection and management of 3D survey data for 3D Cadastre are still evolving and facing some challenges. Although the cadastre research has been progressing for the past 20 years, major challenges in integrating 3D parcels and 2D parcels in land administration systems include the legal and organizational aspects of adopting accurate 3D survey or 3D model submission for the registration of 3D parcels [1]. The storage and visualization of verified or collected 3D properties are not integrated with the National Land Information System, which continues to focus on 2D parcels. Most national land information systems do not address the simultaneous mapping and registration of 2D parcels and 3D properties. The common forms of 3D properties that are regulated explicitly by some national legislations in Asia and Australia (e.g., Victoria State, Singapore, Malaysia, and Indonesia) are known fulfil visualization and the cadastral system requirements. In this regard, visualization system requirements include Level of Detail (LOD), symbolization, interaction control, queries, underground view, cross-section view, and 3D measurements (see also Table 1 of [13]). Cadastral requirements include a capability of the system to provide the certainty of ownership, the representation of legal provision, and the unambiguous spatial location [14] of the initial registration, as well as data maintenance such as subdivision and right transfers. In this regard, cadastral information systems that facilitate the first registration and transactions of 3D spaces, from data collection until data processing and visualization and connecting surveyors, notaries, registrars, and owners, are still limited.
This work aims to visualize the 3D geospatial survey data of property units and their underlying 2D parcel along with their legal data. For that purpose, the visualization system should be able to display the field measurements and field verifications of 3D physical units. Previous work on 3D property visualization has shown the potential uses of visualization platforms using WebGL [12], GL Scene (which is also based on OpenGL, like WebGL) [15], and Google Earth [16,17]. This research applies Cesium JS as a visualization platform (https://cesiumjs.org/). It provides a wide range of possibilities for heterogeneous 3D data fusion, including Building Information Model (BIM) or CAD exterior and interior, point clouds, and imagery tiles for presentation as an interactive 3D map. This research illustrates the possibility of optimizing Cesium JS's uses as a web platform for supporting 3D cadastre visualization that provides the interactive visualization of the graphical representations of legal and spatial data. Cesium JS is a Javascript framework widely used for 3D Geospatial visualization. Cesium JS is able to integrate 2D and 3D geospatial data into a single platform for visualization and analysis, and therefore is a reasonable choice to be used in a 3D cadastre platform. Previous works that had started to develop a 3D cadaster platform also utilized Cesium JS for the 3D visualization of parcels, usually linked with a database management system (DBMS) to store 3D geometries and documents related to property rights (see, for example [18] and [13]). The work presented in [13] is also using Cesium JS. The differences between the work presented in [13] and this research are that the prototype of the 3D cadastral system here focuses on supporting 3D cadastral survey processing and on implementing the existing 3D property registration workflow.
As highlighted by Shojaei et al. [11], one of the challenges in 3D cadastre visualization is facilitating visualization and cadastral features. Visualization features in the system should convey not only ease of user interaction, LOD completeness, and tooltips but should also provide a symbolic representation of transparency. Cadastral features include the option to load spatial data and legal documents into a database, to perform queries, to see cross-section and underground views, and to display information on related attributes. The functions offered in the developed prototype of the 3D land information system should cover both visualization and cadastral features. As a new legal framework for 3D registration in Indonesia is being prepared, it is anticipated in the future that the registration of 3D properties will cover not only apartment units but also public infrastructures and commercial spaces above and below land and over water, close to or within the land mass.
This paper presents a research prototype that offers a possible solution for integrating 2D and 3D geospatial data of 3D properties into current land registration systems utilizing Cesium JS as a 3D geospatial platform. As showcased in the work of [13], this work also considers the Land Administration Domain Model (LADM) standard as a foundation to accommodate the data integration of the survey data of 3D property units with their property owner and underlying legal data. The next sections will elaborate on the development of the prototype based on the scenario-based design approach. Furthermore, the paper will discuss the data collection procedures and the methods to process and visualize the 3D property data. After presenting the results, the paper will discuss the remaining challenges and the possible follow up from the research.

Materials and Methods
From 2011 to 2016, the National Land Agency in collaboration with UGM (Universitas Gadjah Mada) carried out a pilot project for the 3D cadastre survey and mapping of 3D physical objects located ISPRS Int. J. Geo-Inf. 2020, 9, 310 4 of 20 in the city and in water areas. The measurements produced geospatial data for the 3D representations of buildings and infrastructure in Yogyakarta, Bandung, Semarang, and Makassar. The 3D objects surveyed were: (1) a mixed-use apartment building in Bandung Selatan, (2) a flyover in Yogyakarta, (3) an electronic shopping mall in Yogyakarta, (4) a three-story academic building of Geodetic Engineering of Universitas Gadjah Mada (UGM) in Yogyakarta, (5) a mixed-use apartment building in Semarang, and (6) a restaurant, hotel, and villa compound in Losari Beach, Makassar (located in water areas).

Collecting User Requirements
In keeping with 3D cadastre visualization requirements [12], public users must have access to features such as basic visualization, encompassing search, zoom in, zoom out, pan, and tooltip. Users with administrative access would have the same features as public users. They can also search records related to the party, rights, and spatial units, and can generate certificate view, upload and remove geometries, and edit attributes.
A user study was conducted to gather a clear understanding of user preferences and expectations for a new 3D cadastre visualization. It included user surveys, employing questionnaires and interview methods in the Land Office of Jakarta Province, the Surabaya Land Office, and the Yogyakarta and Semarang Land Office. The eight resource persons involved in the study were senior land officers responsible for cadastre surveys and property registration. The results from the user questionnaires and interviews were processed to list the user preferences in terms of object registration, data management, and data visualization. Interviews with a building manager who managed a number of strata titles and with a public notary who dealt with a lot of deeds for strata titles were performed to verify customer needs. The user familiarity with the current computing procedures for storing and managing strata titles was also ascertained to determine the expectation. A scenario for the use of the system was developed from the user perspectives to clarify activity, information, and user interaction that would need to be supported by the application (see Figure 1). Here, the focus is to serve different users dealing with a property registration, such as public notary, registrars and surveyors. In addition to that, the viewing capabilities are also designated to serve customer needs (e.g., a notary who helps deeds for property transactions and a person looking for or owning a property).
ISPRS Int. J. Geo-Inf. 2020, 9, x FOR PEER REVIEW 4 of 22 building in Semarang, and (6) a restaurant, hotel, and villa compound in Losari Beach, Makassar (located in water areas).

Collecting User Requirements
In keeping with 3D cadastre visualization requirements [12], public users must have access to features such as basic visualization, encompassing search, zoom in, zoom out, pan, and tooltip. Users with administrative access would have the same features as public users. They can also search records related to the party, rights, and spatial units, and can generate certificate view, upload and remove geometries, and edit attributes.
A user study was conducted to gather a clear understanding of user preferences and expectations for a new 3D cadastre visualization. It included user surveys, employing questionnaires and interview methods in the Land Office of Jakarta Province, the Surabaya Land Office, and the Yogyakarta and Semarang Land Office. The eight resource persons involved in the study were senior land officers responsible for cadastre surveys and property registration. The results from the user questionnaires and interviews were processed to list the user preferences in terms of object registration, data management, and data visualization. Interviews with a building manager who managed a number of strata titles and with a public notary who dealt with a lot of deeds for strata titles were performed to verify customer needs. The user familiarity with the current computing procedures for storing and managing strata titles was also ascertained to determine the expectation. A scenario for the use of the system was developed from the user perspectives to clarify activity, information, and user interaction that would need to be supported by the application (see Figure 1). Here, the focus is to serve different users dealing with a property registration, such as public notary, registrars and surveyors. In addition to that, the viewing capabilities are also designated to serve customer needs (e.g., a notary who helps deeds for property transactions and a person looking for or owning a property).

Designing Information Flow
In the current system, the first registration for strata titles is mandatory but has no support to visualize the 3D units on top of its underlying 2D parcel. For strata titling, the current system requires property subdivision (locally known as the separation deed produced by a notary) that includes the share values or proportional values of the individual apartment units. The registrars at the land offices only record the units based on the underlying parcel where the building is built. No 3D and 2D representations of 3D property units are available, as the registration will only store the link of the number of registrations with legal data. The accurate position and dimension of the unit cannot be retrieved visually from the system. Additionally, the survey documents are linked only to the common parcel. Figure 2 presents information windows in the existing land information system pertaining to a right of an apartment unit.

Designing Information Flow
In the current system, the first registration for strata titles is mandatory but has no support to visualize the 3D units on top of its underlying 2D parcel. For strata titling, the current system requires property subdivision (locally known as the separation deed produced by a notary) that includes the share values or proportional values of the individual apartment units. The registrars at the land offices only record the units based on the underlying parcel where the building is built. No 3D and 2D representations of 3D property units are available, as the registration will only store the link of the number of registrations with legal data. The accurate position and dimension of the unit cannot be retrieved visually from the system. Additionally, the survey documents are linked only to the common parcel. Figure 2 presents information windows in the existing land information system pertaining to a right of an apartment unit. Based on observations and interviews aimed at gathering information on the current implementation procedure to register a strata title, proposed changes are represented through a before and after diagram in Figure 3. The proposed changes will present the location, size, and dimension of individual units as an individual 3D geometry. An individual 3D geometry is built on the submitted plan and field verifications or field measurements. The current procedure only requests applicants to submit the hardcopy of floor plans, not the digital building model. Digital submissions in formats like International Foundation Class/IFC, City Geographic Markup Language/CityGML, or Keyhole Markup Language/KML would make 3D property registration easier. The purposes of the uses of IFC, BIM, CityGML, and KML may differ (e.g., [7,19,20]). However, the spatial capture of those different formats of 3D models can be easily extracted by land surveyors using modern CAD/GIS software in order to validate the dimensions of 3D spatial units. That submission requirement should be no problem for both groups of apartment owners and developers, as the 3D digital building files become prevalent in today's property market. Three-dimensional representations of units have become a must-have for developers and planners for multiple reasons, including to support spatial plans [21] and spatial restrictions [22], disaster risk financing, and energy monitoring for implementing smart city concepts [19,21,23,24]. Furthermore, the extensive development of vertical buildings, transportation infrastructure, and hubs above and below 2D parcels in big cities also create challenges, as the current legal system commonly restricts registration only to 2D parcels [25].
The property subdivision for all shared and individual (i.e., strata title) rights must be prepared by the developer or a group of apartment owners. The right registration can be completed with no spatial data submission of 3D property units. In practice, either a 3D survey or a 3D field verification activity is performed as a response to an incoming strata title application. Here, the proposed improvements in the prototype development include the preparation of the 3D geometry of individual units which are created either from a selective field survey or from field verifications of the submitted 3D model (see Figure 3). Shared objects and shared structures can also be registered as shared rights to a shared party (i.e., a group of property owners) by uploading corresponding 3D geometries. Once the registration is completed, the property registration can be visualized for a registered public user (e.g., owner or notary) and land office administrator. Based on observations and interviews aimed at gathering information on the current implementation procedure to register a strata title, proposed changes are represented through a before and after diagram in Figure 3. The proposed changes will present the location, size, and dimension of individual units as an individual 3D geometry. An individual 3D geometry is built on the submitted plan and field verifications or field measurements. The current procedure only requests applicants to submit the hardcopy of floor plans, not the digital building model. Digital submissions in formats like International Foundation Class/IFC, City Geographic Markup Language/CityGML, or Keyhole Markup Language/KML would make 3D property registration easier. The purposes of the uses of IFC, BIM, CityGML, and KML may differ (e.g., [7,19,20]). However, the spatial capture of those different formats of 3D models can be easily extracted by land surveyors using modern CAD/GIS software in order to validate the dimensions of 3D spatial units. That submission requirement should be no problem for both groups of apartment owners and developers, as the 3D digital building files become prevalent in today's property market. Three-dimensional representations of units have become a must-have for developers and planners for multiple reasons, including to support spatial plans [21] and spatial restrictions [22], disaster risk financing, and energy monitoring for implementing smart city concepts [19,21,23,24]. Furthermore, the extensive development of vertical buildings, transportation infrastructure, and hubs above and below 2D parcels in big cities also create challenges, as the current legal system commonly restricts registration only to 2D parcels [25].

Survey Data Handling
The boundary points of the 3D space of the spatial units were acquired as X, Y, and Z point data through field surveys, utilizing Total Stations, and Geodetic-type GNSS devices. The data were processed to reconstruct the point boundaries of the 3D room and corridor as individual 3D spatial units. This was done manually, utilizing AutoCAD software, with which most licensed and official land surveyors in the country are familiar. The walls and roofs were constructed as multi-polygon geometries. All the connected multi-polygon geometries that made up a 3D spatial unit were then converted into KML for an individual 3D model. The data were converted from CAD to KML using The property subdivision for all shared and individual (i.e., strata title) rights must be prepared by the developer or a group of apartment owners. The right registration can be completed with no spatial data submission of 3D property units. In practice, either a 3D survey or a 3D field verification activity is performed as a response to an incoming strata title application. Here, the proposed improvements in the prototype development include the preparation of the 3D geometry of individual units which are created either from a selective field survey or from field verifications of the submitted 3D model (see Figure 3). Shared objects and shared structures can also be registered as shared rights to a shared party (i.e., a group of property owners) by uploading corresponding 3D geometries. Once the registration is completed, the property registration can be visualized for a registered public user (e.g., owner or notary) and land office administrator.

Survey Data Handling
The boundary points of the 3D space of the spatial units were acquired as X, Y, and Z point data through field surveys, utilizing Total Stations, and Geodetic-type GNSS devices. The data were processed to reconstruct the point boundaries of the 3D room and corridor as individual 3D spatial units. This was done manually, utilizing AutoCAD software, with which most licensed and official land surveyors in the country are familiar. The walls and roofs were constructed as multi-polygon geometries. All the connected multi-polygon geometries that made up a 3D spatial unit were then converted into KML for an individual 3D model. The data were converted from CAD to KML using AutoCAD software. This was done for the 2D land parcels as well. The developed 3D models were then integrated with the 2D land parcels into databases. The databases were developed by importing spatial data in a KML format into the PostgreSQL-PostGIS database.
The KML data format was chosen because it has complete tags, which can represent geometries and style data. Other data formats available for 3D cadastre include IFC and CityGML, which are commonly used in SmartCity and 3D GIS applications [20,26,27]. KML is easier to use as a data standard for many visualization platforms, including Cesium JS. If a developer or building management submits an application of strata titles with a 3D model of the building, the 3D model is uploaded into a 3D model storage like the Cesium ION platform. This scenario was also considered as many developers in practices are ready to submit the 3D model during the application for strata titles.
In Figure 4, in case a land office receives an application for strata title ownership registration, the land office will assign the government and licensed surveyors to collect the 3D spatial data. Using the existing rules, the surveyors are required to create 3D geometries of the spaces to be registered. These 3D geometries can be generated either from validating the submitted 3D building models or conducting limited 3D cadastral surveys on the applied sites. The results of field surveys using Total Station, Distometers, and GNSS devices are drawn as CAD models. Figure 5 presents the results of a 3D survey of one of the 3D objects. The CAD model is then exported as KML data. Meanwhile, the 3D building model, which in this case is derived from a Terrestrial Laser Scanner (TLS) survey, is converted into a CityGML format before it is uploaded as Cesium assets (see later in Figure 8b). The software solution developed in this work is an application that separates the geospatial data model of spatial units from their corresponding rights information, following Land Administration Domain Model specifications; see discussions on the design and testing of an LADM-compliant 3D cadastral system [13]. Here, supporting documents, including field measurements and floor plans (in case of strata title units) are linked to their corresponding spatial extent and preserved in a digital format.
The common rights for legal 3D spatial units correspond to a group. In this case, the group for apartment ownership is an association of apartment owners. The shared objects and structures as well as the individual ownership rights for apartment units are part of 3D spatial units, built either above or below an underlying 2D parcel. Shared objects and structures can also be entered into the system if the corresponding geometries are uploaded. Only ownership rights for apartment units (ownerships with strata titles) are certified by the land office. This particular 3D legal space is represented as an individual 3D spatial unit. The legal and spatial documents related to strata titles (e.g., field sketches or field measurements) are stored in survey documents. The process model for storing strata title registration with their corresponding legal and survey documents is given in Figure 6.  The common rights for legal 3D spatial units correspond to a group. In this case, the group for apartment ownership is an association of apartment owners. The shared objects and structures as well as the individual ownership rights for apartment units are part of 3D spatial units, built either above or below an underlying 2D parcel. Shared objects and structures can also be entered into the system if the corresponding geometries are uploaded. Only ownership rights for apartment units (ownerships with strata titles) are certified by the land office. This particular 3D legal space is represented as an individual 3D spatial unit. The legal and spatial documents related to strata titles (e.g., field sketches or field measurements) are stored in survey documents. The process model for storing strata title registration with their corresponding legal and survey documents is given in Figure 6.
The following sequential steps are employed to register an apartment unit or other 3D spatial units as 3D legal spaces into the system: 1. CAD data from the field measurements of 3D objects are grouped into folders corresponding to the administrative area where the buildings are located.   The common rights for legal 3D spatial units correspond to a group. In this case, the group for apartment ownership is an association of apartment owners. The shared objects and structures as well as the individual ownership rights for apartment units are part of 3D spatial units, built either above or below an underlying 2D parcel. Shared objects and structures can also be entered into the system if the corresponding geometries are uploaded. Only ownership rights for apartment units (ownerships with strata titles) are certified by the land office. This particular 3D legal space is represented as an individual 3D spatial unit. The legal and spatial documents related to strata titles (e.g., field sketches or field measurements) are stored in survey documents. The process model for storing strata title registration with their corresponding legal and survey documents is given in Figure 6.
The following sequential steps are employed to register an apartment unit or other 3D spatial units as 3D legal spaces into the system: 1. CAD data from the field measurements of 3D objects are grouped into folders corresponding to the administrative area where the buildings are located. 2. The exact location of the building complex is verified against the cadastral map and a highresolution base map. Coordinate transformations and position adjustments are often carried out on all existing objects. 3. The data are converted from CAD to KML using AutoCAD. All converted files are named according to the parcel identifier number followed by the room identity number. All procedures up to this stage are performed on a desktop computer. 4. The data entry of attributes and geometries for registering 3D objects is done through the web application of the prototype. The prototype facilitates the addition and maintenance of 3D spatial units and their related rights. In case of changes in ownership rights, the system administrator has to update the dashboard. In cases of the subdivision or merging of spatial units, new field verification is required, which would necessitate new CAD data processing and KML conversion in addition to attribute changes. Procedure number 4 can only be performed by a system administrator. 5. The geometries uploaded in step 4 are automatically represented as geometries of the 3D spatial feature of MULTIPOLYGON Z and are stored into the PostgreSQL PostGIS database system. Figure 6. The process model of spatial and legal data storage and linkage in 3D Cadastre of a strata unit registration.

Application Development
The application design separates the data model from the user view. For users, access to functions and interactions is through a web application utilizing a Yii Framework of PHP (Hypertext Preprocessor), which implements the Model-View-Controller (MVC) pattern. The PHP codes are organized in Model, View, and Controller folders to separate data access and query, data population, and data visualization seamlessly. User requests are sent to the server, implementing a common data The following sequential steps are employed to register an apartment unit or other 3D spatial units as 3D legal spaces into the system:

1.
CAD data from the field measurements of 3D objects are grouped into folders corresponding to the administrative area where the buildings are located.

2.
The exact location of the building complex is verified against the cadastral map and a highresolution base map. Coordinate transformations and position adjustments are often carried out on all existing objects. 3.
The data are converted from CAD to KML using AutoCAD. All converted files are named according to the parcel identifier number followed by the room identity number. All procedures up to this stage are performed on a desktop computer. 4.
The data entry of attributes and geometries for registering 3D objects is done through the web application of the prototype. The prototype facilitates the addition and maintenance of 3D spatial units and their related rights. In case of changes in ownership rights, the system administrator has to update the dashboard. In cases of the subdivision or merging of spatial units, new field verification is required, which would necessitate new CAD data processing and KML conversion in addition to attribute changes. Procedure number 4 can only be performed by a system administrator.

5.
The geometries uploaded in step 4 are automatically represented as geometries of the 3D spatial feature of MULTIPOLYGON Z and are stored into the PostgreSQL PostGIS database system.

Application Development
The application design separates the data model from the user view. For users, access to functions and interactions is through a web application utilizing a Yii Framework of PHP (Hypertext Preprocessor), which implements the Model-View-Controller (MVC) pattern. The PHP codes are organized in Model, View, and Controller folders to separate data access and query, data population, and data visualization seamlessly. User requests are sent to the server, implementing a common data flow: (1) The corresponding script in the controller component sends a query to the databases while simultaneously handling the data results. The controller contains scripts to facilitate the addition, change, removal, and processing of data. (2) The model contains scripts to support the data formatting and managing of database records by classifying them in specified predefined tables. (3) The view has a function to present results sent by the controller. The results are XML elements inserted dynamically into the client browser. Figure 7 provides a schematic view of the Model-View-Controller workflow applied in this work.
The user requests and system responses form a repeated cycle that delivers an updated view to the user. The Yii Framework implements "functionality and usability" in AJAX (Asynchronous Javascript and XML) patterns [28] in presenting the data, including auto suggestion functions to search either parcels or 3D units. For data visualization, KML has been used to represent 3D objects on top of Cesium JS. To enable this, all new 3D registered units must be saved in the KML format. The application is designed to use a PHP XML DOM library to convert KML data into a Well-Known Text (WKT) format for storage in PostGIS. This conversion is performed for enabling the registration of 3D property units, thus adding new 3D objects into the databases. In contrast, for constructing a KML format for visualization, a data query extracts the geometry values of selected 3D objects to be combined with full KML elements, composed programmatically in the controller. The user requests and system responses form a repeated cycle that delivers an updated view to the user. The Yii Framework implements "functionality and usability" in AJAX (Asynchronous Javascript and XML) patterns [28] in presenting the data, including auto suggestion functions to search either parcels or 3D units. For data visualization, KML has been used to represent 3D objects on top of Cesium JS. To enable this, all new 3D registered units must be saved in the KML format. The application is designed to use a PHP XML DOM library to convert KML data into a Well-Known Text (WKT) format for storage in PostGIS. This conversion is performed for enabling the registration of 3D property units, thus adding new 3D objects into the databases. In contrast, for constructing a KML format for visualization, a data query extracts the geometry values of selected 3D objects to be combined with full KML elements, composed programmatically in the controller.

Results
The system prototype was built in accordance with user preferences for managing and visualizing 3D cadastre objects. Based on a user study involving local land offices in big cities, the system was designed to help targeted users easily complete 3D property management and visualization. First, user scenarios covering possible user activity, system information, and user interaction were developed to specify the cadastre features and visualization functions (Table 1). Second, based on user scenarios, a design of the list of features and functions to be delivered to users was specified (Table 2).

Results
The system prototype was built in accordance with user preferences for managing and visualizing 3D cadastre objects. Based on a user study involving local land offices in big cities, the system was designed to help targeted users easily complete 3D property management and visualization. First, user scenarios covering possible user activity, system information, and user interaction were developed to specify the cadastre features and visualization functions (Table 1). Second, based on user scenarios, a design of the list of features and functions to be delivered to users was specified ( Table 2).

Features Developed Functions
Party Registration Adding the owner information: a. Fill in the party name b.
Fill in the resident identity number (mandatory) c.
Fill in the account ID d.
Select the ownership type e.
Specify party addresses (province, regency, districts, village or city block of the party) f.

Specify contact information
Spatial Unit Registration Adding the 2D underlying parcel: a. Specify party addresses (province, regency, districts, village or city block) b.
Create Parcel Identity Number (PIN) if not existing c.
Define the types of rights (codelist) d.
Define dates of land certificates e.
Upload the geometry in *. Keyhole Markup Language KML format f.
If the common parcel has already been registered, specify the PIN (or right identifier) in order to verify the geometry g.
Enter attribute values of uses of land (codelist) h.
Enter a description on a 2D parcel i.
Add parcel photos or geotagging photos Adding the building model: a. Add a building name b.
Create a Building Identity Number (BIN) c.
Select the underlying parcel's PIN d.
Select the underlying common parcel right (codelist) e.
Enter attribute values on the total number of building levels f.
Enter attribute values on building compliance certificate (for public building) g.
Upload the geometry of the building in KML format or via Cesium ION h.
Add building photos from north, east, south, and west view Adding the 3D spatial units: a. Specify the building name/BIN b.
Specify the floor level c.
Generate the 3D spatial unit/Space Identity Number (SIN) d.
Enter the attribute values e.
Enter the types of rights (ownership right/shared part/shared object) f.
Upload the geometry of 3D spatial unit in *. KML format g.
Enter a description on 3D spatial units h.
Add 3D spatial unit photos from north, east, south, and west view Data visualization Managing spatial and legal (rights and party): a. Activate 2D/3D property visualization using 'view' button b.
Interact with 2D map canvas c.
Interact with building and 3D spatial units d.
Generate cross-section view using vertical plane e.
Remove spatial and attribute data using 'delete' button.

Property Registration
Managing property registration: a. List and validate 3D unit of registered 3D property b.
Validate the registered party and the ownership certificates c.

Retrieve relevant survey documents
To translate the requirements for information access and user interactions, menus were offered in accordance with the current standard operating procedure where the owner/party registration is entered into the system. Subsequently, the verification and registration of legal status (both 2D parcel and individual 3D spatial units) can be done by linking an individual 3D unit with its corresponding legal data, implementing the process model depicted in Figure 6. For this, the features and functions offered to users have to be capable of handling owner registration, common parcel registration, building and 3D unit uploads, and property registration. Table 2 lists some important features and functions offered to administrator users, developed on the basis of the activity, information, and interaction scenarios presented earlier in Table 1.

User Management
Users form an important consideration in prototype development. Based on the results of user questionnaires and interviews, a clear workflow is needed when registering a 3D property, as mandated by the existing regulation. Users must have a clear scope of the functions available for their role in the system.
User management was applied to control users' rights. Users are of three types: those who are owners (registered users), those with administrative roles in land offices, and those with super administrator roles. Users with super administrator roles can add or remove registered users. As the separation between the databases and presentation was clear, a pattern similar to that employing controller-model-and-view scripts was applied to support users' roles and functions for each user group. Table 3 shows the functions and user interactions of the prototype to deliver cadastral features in the 3D visualization system based on different user roles. Users could be public users that visit the website. Typical administrator users were land office administrators or government surveyors who dealt with 3D measurements and management. A public notary can also fall in this category to execute the function number two and number six, e.g., verify the units and upload the corresponding deeds for strata registration. Meanwhile, super administrator status was designated to be used by information managers at national and local land registration offices. Of the cadastral features listed in Table 3, numbers one, two, three, and six relate to the visualization system, while numbers four, seven, and eight relate to the data management system. The following subsections present the implementation of data management and subsequently the implementation of data visualization.

2D/3D Spatial Data Management
Data management aims to provide functions for the land office to handle 3D property registration. Administrators are offered generic functions to add, edit, and remove records related to nonspatial and spatial data. The prototype system facilitates manual data entry for nonspatial data, but a proof of concept of automatic data entry through data import from the Excel format has been implemented for personal information. The geometry is imported from the KML format through a web interface for 2D and 3D spatial data. The results of the data entry for spatial and nonspatial data are stored in PostGIS databases. Cesium assets are linked with the application by providing Assest ID. This link is also stored in PostGIS databases. The interface for the spatial data upload, which in this case is the building unit, is shown in Figure 8.

3D Cadastre Visualization
The data visualization is delivered through a set of functions to display geospatial data and the images or photos of survey documents. The visual displays used include table and tree views for attribute data and a map display for geospatial data. Spatial and nonspatial data are displayed using a virtual globe called Cesium JS. This is a 3D data library used to display 3D models of property units. The visualization features [10,12] adopted in the prototype are: (1) interactivity tools including measurement and tooltips, (2) transparency and simple symbolization, (3) results of data queries, (4) the visualization of surface-based 3D spatial units. Figure 9 shows the results of the prototype development for visualizing individual 3D spatial units on top of the common parcel.

3D Cadastre Visualization
The data visualization is delivered through a set of functions to display geospatial data and the images or photos of survey documents. The visual displays used include table and tree views for attribute data and a map display for geospatial data. Spatial and nonspatial data are displayed using a virtual globe called Cesium JS. This is a 3D data library used to display 3D models of property units. The visualization features [10,12] adopted in the prototype are: (1) interactivity tools including measurement and tooltips, (2) transparency and simple symbolization, (3) results of data queries, (4) the visualization of surface-based 3D spatial units. Figure 9 shows the results of the prototype development for visualizing individual 3D spatial units on top of the common parcel.
A summary of the system capabilities for visualizing registered 3D properties is given in Table 4. These system capabilities are based on the criteria developed by Pouliot et al. [10] and Shojaei et al. [11,12]. AJAX patterns were implemented to support user interaction in searching places and names as well as loading 2D and 3D models based on user selections (ticking on/off selections in the left window of Figure 9). A 3D model is rendered in an AJAX web-environment by Cesium JS using Javascript and eXtensible Markup Language data, as implemented earlier in the work of Mao and Ban [29].
As a proof of concept, the results of a 3D survey of six property objects, mentioned in Section 3.3, have been entered and managed in the prototype of the 3D registration system. The description of the objects is provided in Table 5 and displayed in Figure 10. The user can directly search to view the geometry based on the name of the building, administrative areas, apartment right identity, parcel identity, or 3D unit identity. After the search results are listed, the user can click to view the selected property (see Figure 11).

3D Cadastre Visualization
The data visualization is delivered through a set of functions to display geospatial data and the images or photos of survey documents. The visual displays used include table and tree views for attribute data and a map display for geospatial data. Spatial and nonspatial data are displayed using a virtual globe called Cesium JS. This is a 3D data library used to display 3D models of property units. The visualization features [10,12] adopted in the prototype are: (1) interactivity tools including measurement and tooltips, (2) transparency and simple symbolization, (3) results of data queries, (4) the visualization of surface-based 3D spatial units. Figure 9 shows the results of the prototype development for visualizing individual 3D spatial units on top of the common parcel. A summary of the system capabilities for visualizing registered 3D properties is given in Table  4. These system capabilities are based on the criteria developed by Pouliot et al. [10] and Shojaei et al. [11,12]. AJAX patterns were implemented to support user interaction in searching places and names as well as loading 2D and 3D models based on user selections (ticking on/off selections in the left window of Figure 9). A 3D model is rendered in an AJAX web-environment by Cesium JS using   Data Input

3D Data Production
To convert CAD to KML for each unit of apartments using AutoCAD Map 3D To convert CAD to KML (using AutoCAD Map 3D) with some manual editing to correctly georeference the spatial location.
To convert CAD to KML (using AutoCAD Map 3D) with some manual editing to correctly place it above the ground The raw data from the TLS survey was in *.clr format which then was converted into *.pts format.
To convert CAD to KML for each unit of apartments using AutoCAD Map 3D To convert CAD to KML (using AutoCAD Map 3D) with some manual editing to correctly georeference the spatial location.

Property Registration
The integrated between 2D and 3D data overlaid with a 2D parcel which has a right to build (HGB) status.
public infrastructure erected over a government land (main road) overlaid with a 2D parcel which has a right to build (HGB) status.
overlaid with a 2D parcel overlaid with a 2D parcel which has a right to build (HGB) status.
overlaid with 2D parcel which has a use right (right to manage). The cross-section view in this prototype was realized using the script acquired from the Cesium JS source [30]. It implements a movable vertical clipping plane to hide the outside part of the object and to see the inside part of the object through a clipping plane. Figure 11 presents the results in implementing the clipping plane to provide a cross-section of the object (d). The cross-section view in this prototype was realized using the script acquired from the Cesium JS source [30]. It implements a movable vertical clipping plane to hide the outside part of the object and to see the inside part of the object through a clipping plane. Figure 11 presents the results in implementing the clipping plane to provide a cross-section of the object (d). The first titling of property registration will be done once the apartment units are linked with their legal data. The legal data cover information is related to the underlying parcel, share or proportional values, and letter of measurements. In case the 3D properties are applied for strata titles, the prototype provides a possibility for an administrator in land offices to upload the submitted building models and corresponding 3D survey data. In addition to that, the system provides a possibility for uploading the underlying legal documents and the results of the 3D validation survey (see Figure 12). The cross-section view in this prototype was realized using the script acquired from the Cesium JS source [30]. It implements a movable vertical clipping plane to hide the outside part of the object and to see the inside part of the object through a clipping plane. Figure 11 presents the results in implementing the clipping plane to provide a cross-section of the object (d).

Rights of individual units
The first titling of property registration will be done once the apartment units are linked with their legal data. The legal data cover information is related to the underlying parcel, share or proportional values, and letter of measurements. In case the 3D properties are applied for strata titles, the prototype provides a possibility for an administrator in land offices to upload the submitted building models and corresponding 3D survey data. In addition to that, the system provides a possibility for uploading the underlying legal documents and the results of the 3D validation survey (see Figure 12). ISPRS Int. J. Geo-Inf. 2020, 9, x FOR PEER REVIEW 17 of 22 Figure 12. Managing spatial and non-spatial data related to objects (2D parcel, 3D building, 3D unit, other objects), registration documents (underlying rights, field sketches, measurement letters, separation deed), and owner information can be done through the data management menu.
The data entered in the prototype are example data that include six objects presented in Figure  10. As seen in Figure 11, options of actions for each selected row can be viewed, edited, or deleted. This set of options is available to all menus offered in the right widow (namely, spatial objects of parcel, building, 3D units, registration documents, and owner), performing functions from owner/party registration to property registration, as specified in Table 2. The results of the 3D survey must be uploaded first through "Obyek Ruang" in the "Obyek" menu (spatial objects). Information related to the floor area, volume, and share values for each 3D unit are displayed in the attributes window. The floor plan, field sketches, photographs, and digital certificate can be retrieved and printed upon request.

Discussion
The prototype can facilitate 3D spatial data uploads from survey and mapping for the first titling of property registration. Such a function is unavailable in the current property registration system. The data flow for the first titling of property registration can be made more efficient and transparent to stakeholders. The prototype offers functions to upload, manage, and view 3D spatial units and the ability to link the object and subject of property units in order to formally register the object. Lessons can be learnt in implementing current national procedures for registering apartment units from objects number one, number five, and number six. Unlike the current national system, the prototype allows the spatial boundaries of apartment units to be visualized as visible 3D objects after the users or administrators search for specific records regarding the strata titles. The 3D objects, number two and four, have been included to showcase opportunities to register government 3D infrastructure and public building objects.
The 3D cadastre visualization requirements for property registration are delivered in this work based on user studies and international recommendations in order to provide the best possible approach to handle 3D object registration in the country. The current prototype has not dealt with complex 3D legal representations above and below 2D parcels, as identified in Stoter et al. [31] and Registration documents (underlying rights, field sketches, measurement letters, deed) owner Spatial Objects (parcel, building, 3D unit, other) Figure 12. Managing spatial and non-spatial data related to objects (2D parcel, 3D building, 3D unit, other objects), registration documents (underlying rights, field sketches, measurement letters, separation deed), and owner information can be done through the data management menu.
The data entered in the prototype are example data that include six objects presented in Figure 10. As seen in Figure 11, options of actions for each selected row can be viewed, edited, or deleted. This set of options is available to all menus offered in the right widow (namely, spatial objects of parcel, building, 3D units, registration documents, and owner), performing functions from owner/party registration to property registration, as specified in Table 2. The results of the 3D survey must be uploaded first through "Obyek Ruang" in the "Obyek" menu (spatial objects). Information related to the floor area, volume, and share values for each 3D unit are displayed in the attributes window. The floor plan, field sketches, photographs, and digital certificate can be retrieved and printed upon request.

Discussion
The prototype can facilitate 3D spatial data uploads from survey and mapping for the first titling of property registration. Such a function is unavailable in the current property registration system. The data flow for the first titling of property registration can be made more efficient and transparent to stakeholders. The prototype offers functions to upload, manage, and view 3D spatial units and the ability to link the object and subject of property units in order to formally register the object. Lessons can be learnt in implementing current national procedures for registering apartment units from objects number one, number five, and number six. Unlike the current national system, the prototype allows the spatial boundaries of apartment units to be visualized as visible 3D objects after the users or administrators search for specific records regarding the strata titles. The 3D objects, number two and four, have been included to showcase opportunities to register government 3D infrastructure and public building objects.
The 3D cadastre visualization requirements for property registration are delivered in this work based on user studies and international recommendations in order to provide the best possible approach to handle 3D object registration in the country. The current prototype has not dealt with complex 3D legal representations above and below 2D parcels, as identified in Stoter et al. [31] and Stoter and van Oosterom [32]. The prototype is limited to handling the 3D registration applications of multi-level or apartment units. According to the ministry regulation on the cost for surveying services, the unit cost for a field survey for the strata titling of an apartment unit is determined to be three times higher than the unit cost for a 2D parcel (determined based on the area size). At present, the cadastral survey for strata titles will only be applied to some buildings applying for strata titles.
A data workflow that seamlessly transforms a 3D survey to a 3D spatial unit for 3D parcel registration has been identified as one of challenging issues in 3D cadastre [1]. This research aims at providing a feasible workflow that will work for stakeholders in strata registration, e.g., notaries, surveyors, land officers, and developers. The developed functions and user interfaces were aimed to support required activities and user interaction needs typically done by surveyors and registrars in land offices, as well as notaries and owners outside the land office environment. The prototype has not been tested formally using usability testing by targeted users. However, interviews with a professional in a land office and a notary were performed to collect feedback for further developments of the prototype. The interview was preceded by an application demonstration showing the prototype capabilities to manage and visualize the 3D survey data, and linked with survey documents and legal data for the first registration of strata titles. Both the land office professional and notary agreed that the possibilities to show the accurate 3D unit resulting from either a validation or survey activity is essential. However, those possibilities are not possible with the current system. For the notary, the ability to prepare the separation deed and underlying rights for the first registration of the strata title is very helpful.
With regard to 3D property visualization, countries that have laws on strata titles are still not fully implementing the 3D visualization of 3D property units; see [1,3,4,10]. In the research area, previous studies include the use of WebGL [11], Google Earth, and ArcGIS 3D Server [16,33], as well as GLScene [15]. In this work, the 3D visualization canvas for registered property is realized using the Cesium library. The developed visualization interface of the prototype can deliver all the required cadastre features mentioned in Pouliot et al. [10] and Shojaei et al. [12], except: (1) a subsurface view and (2) measurements (3D). The inability to provide a subsurface view means that many surveyed underground 3D units are not successfully displayed in Cesium. Underground views and subsurface visualizations are considered difficult to deliver with most 3D web browsers [34,35]. Only limited browsers currently provide this possibility, including a proprietary software from ESRI Inc. called CityEngine, which is capable of presenting underground 3D objects and infrastructure [36,37]. Although the prototype can manage the first registration of 3D legal property, there is room for improvement in its ability to represent units with a higher LOD and to visualize subsurface units.
The selection of a visualization platform can be adjusted depending on the urgency, effectiveness, and efficiency of the application system produced. Relevant to user requirements for a 3D platform of 3D cadastre, as done earlier by [12,13], Cesium JS has the advantages of completing visualization for its support in various data formats and its ease of integration with other web-based applications. Based on identification and comparison, Cesium JS has been chosen as the most suitable visualization system to deal with the visualization needs of 3D property objects, related 2D parcels, and legal and survey documents. In this research, 3D property objects are registered and presented using a hybrid approach, since land boundaries in cadastral maps are depicted as 2D objects (without contours). The registered 3D units can be placed and inspected according to their real position and level, not just as property registration information linked to the underlying common parcel, as is the case currently.
Cesium JS limits its camera movement for visualizing objects in the ground level or above, which means that 3D visualization for underground objects is yet to be supported as of this writing. Therefore, some additional strategies need to be employed to visualize and interact with 3D cadaster objects situated below the surface or terrain level. Some studies, such as [35], defined three strategies for visualizing underground 3D cadaster objects using Cesium: (1) using a ground-push plugin to define a rectangular boundary of the terrain and further push the region up or down; (2) utilizing some form of transparency on the terrain so that underground objects could be visible from above the ground; and (3) duplicating the terrain as a "fake surface" above the ground, with which users could visualize and interact with 3D cadaster objects situated below the fake surface. A fourth alternative could be seen from [18], which removed the terrain in its entirety and utilized parcel boundaries as fake terrain, so that users were able to interact with the model without the need to deal with an underground camera. The authors of [13] developed a 3D cadaster platform by utilizing both the second and third alternatives; it displays the 3D objects using terrain transparency and interactively lifts the surface using a fake terrain when users need to interact with the object.

Conclusions
Most national land information systems do not specifically address mapping and registration of 2D parcels and 3D properties at once. This work aims to integrate the 2D and 3D geospatial data of property units with their corresponding legal data. The 3D property objects result from 3D point-based survey practices. Objects surveyed using 3D survey methods are drawn as CAD files and converted to KML and stored as Simple Feature (i.e., Multipolygon Z) into PostgreSQL PostGIS to represent the wall and floor boundaries of a 3D spatial unit. The work employs the results of six 3D field measurements of properties located in Yogyakarta, Semarang, Bandung, and Makassar as case studies. Shared objects, shared structures, and apartment units, as well as infrastructure objects, are stored as unique 3D properties linked to their corresponding 2D parcels and building units. The legal boundaries of shared objects, shared structures, and apartment units are visualized through the Cesium JS application. The software solution developed in this work is an application that separates the geospatial data model of spatial units from their corresponding ownership and rights information, following LADM specifications. The supporting documents, including spatial sources, are linked with their corresponding spatial unit. Supporting documents are preserved in a digital format. The prototype has been developed as a web application that enables an effective workflow to support 3D data management and visualization of survey data and 3D models for strata registration. The prototype and workflow demonstrate that first titling of 3D cadaster objects could be conducted and properly visualized in Indonesia by extending the existing LADM with greater support to 3D spatial representations and survey documents.