CITYGML APPLICATION DOMAIN EXTENSION FOR 3D STRATA REPRESENTATIONS IN THE SMARTKADASTER SYSTEM: TOWARDS BEYOND CADASTRE PURPOSE IN MALAYSIA

Recent advancements in 3D city modelling and emerging trends in implementing and realising Digital Twins motivate the Department of Survey and Mapping Malaysia (JUPEM) to develop and implement SmartKADASTER (SKiP) Phase 2. SmartKADASTER Phase I was a precursor to this system, and it primarily focused on applying two-dimensional (2D) spatial data for 3D spatial analysis. CityGML was used as the data model for various Levels of Detail (LoD) in this new initiative to represent city models across the Greater Kuala Lumpur region. SmartKADASTER however, lacks strata information. Therefore, to integrate strata information into the SKiP citymodel environment, an Application Domain Extension (ADE) for CityGML has been developed to convert existing Strata XML to StrataGML, a CityGML-compliant data output format. This paper describes the purpose of the SmartKADASTER initiative in Section 1. Section 2 explains additional context for the initiative as well as some backgrounds. Section 3 discusses the conversion workflow and ADE definitions, followed by a brief discussion of visualisation in Section 4 and a project summary in Section 5.


The Trend
The trending implementations and use cases of 3D cities around the world have shown the importance of integrating various aspects of spatial and non-spatial data towards realizing smart city (Biljecki et. al, 2015) (Cousins, 2017) (Buyuksalih et. al, 2019) (Balzani et. al, 2020). Digital infrastructures, such as 3D cities platforms, essentially provide a platform that allows developments of digital ecosystems, which generates new opportunities, product and services as well as businesses, in addition to the benefit of better city management (Abdul Halim N. Z. et. al, 2021). Establishing such infrastructure commonly requires high commitments, initiatives and cooperation among various stakeholders and parties, as well as technical skillsets requirements.

The Motivation for SKiP
Apart from achieving the bigger vision to realize smart cities for Malaysia context, establishing SKiP was essentially required for the following use cases: i) Engagement of department with stakeholders and users, ii) Spatial analysis enablement with existing data, iii) Service accessibility for new businesses and opportunities, and iv) Visualizations of complex relationships between building parcels or lands with its surroundings (Abdul Halim N. Z. et. al, 2021). This initiative also allows engagements with multiple stakeholders, encourages spatial use-cases for business eccentric analyses, and providing a framework towards spatial-information-as-a-service model.

The Background of SKiP
As the Department of Survey and Mapping Malaysia (JUPEM) is responsible for spatial data custodian such as National Digital Cadastral Database (NDCDB), as well as Geodetic Reference Provider, it provides fundamental datasets for the realization of Malaysian Spatial Data Infrastructure (SDI). In SKiP Phase 1, it was mainly based on 2D spatial data. The cadastral information was based on 2D survey accurate NDCDB, however, served for 3D based analysis (N. Halim, 2021). Despite the availability of 3D cadastral information in Strata Title, it was not implemented in Phase 1. Thus, SKiP Phase 2 implementations involves 3D with related geodata such as building footprints, digital terrain models, meshed city models and strata information.

The Background of Strata XML
The current strata information is represented in XML described by custom schema definition (XSD) schema. The schema definition is defined based on cadastral information as well as height value for each valid legal entity (parcel, accessories etc). The basic entities for Strata XML are block, floor, space, accessory, common area, land parcel and club house. Figure 1 shows various objects in one lot, in the context of strata.
The legal provisions on strata in the National Land Code (NLC) have been revised several times since 1965 prior to the introduction of the Strata Title Act in 1985. The latest amendments to the Strata Title Act included Electronic Land Administration System of strata titles; the designation of limited common property, and the formation of subsidiary Management Corporations (MC) to represent the various interests of owners (Zulkifli et. al, 2021). To date, this schema is mature, and the progressive changes happen only when the code-list or the types of building usages change. The current schema is therefore, fit for purpose and is currently adopted by local professionals in strata registrations and submissions. Integrating this custom XML schema to existing standardized CityGML schema, requires conversion of schema which is allowed by creating ADE for application purposes (Biljecki et. al, 2018). Without conversion from existing data schema to CityGML, the existing XML schema is incapable of adequately accommodating the complex requirement associated with beyond-cadastre purpose in Malaysia.
As highlighted by Abdul Halim N. Z. et. al, 2021, the government of Malaysia envisions to realize spatium. It is the way forward from the current implementation and practices in producing 2D Certified Plan. This was proven by creating the pilot study (Rajabifard et. al, 2021) in implementing Z or height value in producing Certified Plan in the surveying practise. Various studies are either ongoing or planned, towards realizing cadastral with 3D information.
In Strata XML, the cadastral objects as shown in Figure 1 was described explicitly. Scheme related to a project scheme, which comprises information such as the location and lot, the survey job and related attributes, the registration files and approval related attributes, as well as the summary of cadastral objects in the relevant scheme. Besides that, Block comprises information associated to a particular building block, with its attributes such as block area, the entire block height, the usage type, the naming of the building and its related unique identifier.
For strata objects such as Petak and Ruang (Space), these are descendants of the object Tingkat (Floor), which then, is a descendant of Block. The Tingkat (Floor) properties refers to the summary of the floor, such as number of parcels, accessories, and its unique identifier. Despite the association of Tingkat and Accessory in the summary, however, the Accessory is not the descendant of Tingkat. In the Strata ADE, such structure has been slightly modified, where all StrataCommonArea and StrataAccessory are now descendants of StrataFloor.
Figure 2 and Figure 3 shows the attribute for strata XML basic entity of Scheme and Block. These attributes are required to exist in the CityGML datasets in the SKiP portal. By creating an ADE that store this information, the conversion process could map the vital information to the CityGML dataset which will exists as additional information complied to CityGML standard.
Designing an ADE by adopting certain principles as suggested (Biljecki et. al, 2021), could benefit overall ADE adoptions and practices, as different applications may require different and additional customized and application-oriented data. The basic principles are such as a) Develop independent ADE data models for single use case, and structured with customized data packages, classes and attributes; b) An ADE that accommodates data requirement from all use cases into single structure; c) An ADE data model with a shared core structure, by attaching to additional ADEs.
With the various use cases of ADE identified by Biljecki et. al, 2018, an ADE that suits for strata information especially for Malaysia, seems lacking. One of the reasons ADE is considered and adopted in this initiative implementation is due to the nature of ADE is to "support application". Besides that, ADE allows direct integration with CityGML without requiring to modify the existing schema, in this case, the Strata XML XSD. It only requires creating another XSD which defines the conformances and relations. Hence, this initiative attempts to create the Strata ADE for Malaysia, however, with the independent ADE data model designed for single use case.

THE STRATA ADE DEFINITIONS
The basic entities for Strata ADE comprise the similar entities as Strata XML. The prefix of 'Strata' is added on the existing entity name. The scheme definition generally consist of information for a project scheme, such as developer information, the responsible surveyor, the attributes of the project, lot number and etc. While block defines the building information that commonly consist of total number of floors, the unique building block identifier, certification number, the type of usage etc, floor defines the number of accessories, building parcels, common areas as well as the area and the height of the floor. For petak (which is building parcel in Malaysian language), common area and accessory, it generally defines the height of the parcel, gross and surveyed area, altitude, and parcel usage. In the Strata ADE design, StrataFloor is the parent for StrataBuildingParcel, StrataAccessory, StrataSpace and StrataCommonArea. For StrataScheme, it is the parent for StrataAddress and core:cityObjectMember.
In Malaysia, strata information generally focuses on the legal entity and area with height; however, semantic information such as window positions, door locations, and physical installations are not included. Nonetheless, strata information can be conceptually represented in the CityGML version 2.0 context between LoD0 and LoD4, ranging from land parcels to as-built 3D models of LoD4, but without the strata parcel's windows, doors, and physical installations. Since land parcels are also considered strata in some project schemes, the LoD0 representation is still relevant. The height information in the strata dataset allows for the construction of wall surface information as well as the entire legal space entity in solid or multisurface form. On the other hand, the boundary of the parcel, is considered in between wall of adjacent interior wall surface in CityGML context. In the current implementation for buildings, the Strata ADE only construct LoD1 to LoD4 solid and multisurfaces, with only generic wall surface defined as proof of concept. For upcoming enhancement, a custom wall surface extending from CityGML _BoundarySurface could be done that defines MiddleWall.
Each Strata ADE entity is abstracted from each abstract class type ith the naming such as, for StrataFloor by StrataFloorType abstract from AbstractStrataFloorType. Table 2 shows the extension of strata entity with respect to CityGML type.

Conversion Process
The conversion was done in a program developed in this initiative. First, the Strata XML XSD was modelled in C# classes, while the ADE was also modelled in C# classes, which could be used for serialization and deserialization purposes. This step essentially used for mapping the content from serialized Strata XML content to Strata ADE, which the Strata ADE is a CityGML complianced XSD. Serialization of Strata XML data and mapped into classes, may trigger several issues that is resulted from non-compliant input. This step is used to generate useful error reports for validating the input, which end user can utilize to validate their datasets. A fully compliant data may partially indicate that the data is validated and smoothen the users' submission proces. However, a non-compliant dataset will also go through the conversion process and obtain a CityGML output complied with Strata ADE.
C# was used as the development framework due to the recent advancement in .NET Core and its standardization in cross platform as well as the initiative in the open source community. Furthermore, the software stacks that was used in the development pipeline is using .NET as well.
There are two ways of conversion can be done. A desktop application is deployed for the administrator to perform the conversion, while the other allows user to perform conversion through web tool in the SKiP portal. The web tool is using Web API to call the backend process initiating the conversion. Figure  4 shows the conversion process via Web API.

Visualizing the Output
Skyline was the initial choice for visualising the output in the SKiP 2 portal. However, due to plug-in limitations, CesiumJS was used instead and is highlighted further in this paper. The Cesium visualisation layer, in general, makes use of 3D tiles with varying resolutions. Despite the fact that Cesium ION can convert CityGML to 3D tiles and serve as an asset via a web service, it only recognises the basic CityGML datasets without extensions due to custom ADE requirements. Therefore, in this case, conversion of 3D tiles from CityGML was done via FME Engine. The software allows conversion of CityGML with custom ADE (Strata ADE in this case) and strict compliance, and convert it into 3D tiles. The output of the 3D tiles are then uploaded into Cesium ION as an asset for visualization testing. Figure 5 shows the output of the 3D tiles rendered via CesiumJS, served by Cesium ION. Figure 6 shows the converted scheme 13161 themed according to the strata requirements by DSMM.  The conversion process resulted certain loss of information which exists in the initial Strata XML input. Information such as the from-point to forward-point that constitute the traversing line is not retained in the final output of Strata-CityGML. The upside of this conversion process opens the potential whereby the Strata XML file can now be visualized through open platform based on CityGML compliant standard.

SUMMARY
This project initiative has been initiated with the objectives to be achieved as discussed in Section 1. Spatial data enablement for spatial analysis to achieve spatial-data-as-a-service model, is a way forward for organizations like JUPEM to adopt and potentially help generate more opportunities in terms of revenue, businesses and private institution engagement. This initiative also proves the concept of having a custom ADE -Strata ADE, for representing Malaysia Strata in city modelling. This paper focuses on the development of the ADE, which does not cover the scope in assessing the ADE overall effectiveness. Future works may include the assessment process, improving the definition for wall surfaces, updating the code-list for more strata usage types, adopting IfcADE (Biljecki et. al, 2021) with this ADE for possible more comprehensive application, as well as ensuring compatibility with future CityGML 3.0.