Spatial Data Structure and Functionalities for 3D Land Management System Implementation: Israel Case Study

Abstract

With the existence of mature technologies and modern urban planning necessities, there is a growing public demand to improve the efficiency and transparency of government administrations. This includes the formation of a comprehensive modern spatial land management (cadastre) system having the capacity to handle various types of data in a uniform way—above-terrain and below-terrain—enabling the utilization of land and space for various complex entities. To utilize existing knowledge and systems, an adaptive approach suggests extending and augmenting the existing 2D cadastre systems to facilitate 3D land management capabilities. Following a comprehensive examination of the Survey of Israel’s operative cadastral system that supports 2D land administration, it turned out that it is crucial to outline new concepts, modify existing terms and define specification guidelines. That is, to augment and provide full 3D support to the current operative cadastral system, and to create a common and uniform language for the various parties involved in the preparation of 2D and 3D mutation plans required for modern urban planning needs. This study refers to the legal and technical aspects of Survey of Israel’s CHANIT, which is the legal set of cadastral work processes specifications, focusing on database, data structure, functionality, and regulation gaps while emphasizing on 3D cadastral processes. The outcome is recommendations concerning data structure and functionalities needed to be addressed for the facilitation and implementation of an operative 3D land management system in Israel.

1. Introduction

A 3D cadastral information system is the framework for defining and understanding the spatial restrictions, responsibilities, and rights related to spatial land arrangements. According to Aien et al. [1], the information model should allow the understanding of the various parts in the three-dimensional cadastre (geometries, classes, and attributes), explain how they are arranged, organized and conserved using computerized systems (instances of classes and constraints), and simplify data understanding required by all parties involved. 3D cadastral systems should support the implementation of spatial cadastre processes, including (1) The promotion of spatial standards used by the involved parties; (2) The establishment of 3D databases and facilitation of processes and functionalities concerned with data dissemination; (3) The interoperable exchange, combine and share of datasets; (4) The provision of management functionalities required for the establishment of 3D cadastre data, ensuring the integrity and legitimacy of geometry, topology, and semantics.

Establishing a 3D cadastral information system is a direct response to the increasing public demand aimed at improving the existing efficiency and transparency of government administrations, required today to manage the ever-growing complex modern urban planning necessities. To date, cadastre systems rely mostly on 2D registration and management procedures, such that they are limited in managing multi-layered environments. 3D cadastre, on the other hand, should handle various types of data in a uniform way—both spatially and temporally, with emphasis on infrastructure development that must be addressed and registered with respect to the third dimension—above-terrain and below-terrain. That is, establishing a conventional and well-organized series of conditions and functionalities, which will enable utilization of land and space for various complex entities and projects, which are individually or publically owned. This paper addresses and suggests the definition of an appropriate topology for spatial parcels and the implementation of 3D cadastral workflows, ensuring that the data-structure and datasets defined for both 2D and 3D representations in the land management system are compatible with the existing spatial reality.

In Israel, the Survey Of Israel’s (SOI) operative cadastre system requires the submission of 2D mutation plans according to the CHANIT specifications (http://mapi.gov.il/professionalinfo/chanit/documents/mifratlehagashatkvatsim.pdf (in Hebrew)), defining a unified set of instructions for data-transfer required for Cadastral work processes. This ensures that the submitted digital form and data of the mutation plan passes properly through the detailed automatic checklist, which validates a rigorous set of rules that are concerned with the existing 2D geometric, topologic and public law restrictions existing in Israel. CHANIT specifications are defined as the data package for mutation plan and border documentation scheme and offer the technical, legal and cadastral guidelines for submission and validation of 2D mutation plans. Since SOI’s approach is to adapt and augment the operative 2D cadastre system to facilitate the management of 3D cadastre [2], investigation and assessment of the CHANIT specifications are made. These, in turn, derive (among others) geometric and topologic modifications and updates required to be made in the existing 2D cadastre system database, which are addressed in this paper, focusing on the data structure, database, and functionalities.

Current studies mainly suggest new data models and systems for the representation and management of 3D cadastral data. Only several studies have addressed the issue by mapping the existing gaps to allow the transition from 2D to 3D land management systems. Our study identifies and categorizes the existing data structure, database and functionality gaps that are required to be resolved for the implementation of a 3D land management (cadastre) system in Israel. This paper will outline the recommendations and required new processes (actions) needed for advancing the capacity of validation workflow and the establishment of comprehensive 3D mutation plans. This includes, among others, aspects related to guidelines and regulations, data structure and database, data integrity and legality, cadastral processes and functionalities, visualization and presentation. Current requirements of all aspects are discussed and detailed, together with the necessary recommended amendments required for the future 3D extension, with the description of several examples.

2. Related Research

Recommendations made by the SOI related to 3D cadastre consisted mainly of two key aspects: preparing appropriate legislation and regulation, and establishing the technological base required for implementing the solution [3]. The idea of a united 3D volumetric parcel is made, representing the volume of a 3D spatial parcel, which can be part of (subtracted from) a number of 2D parcels. Already in 2009, an in-depth legal analysis made in Israel argued that the use of existing legal tools (especially leases and concessions), with no change made to the nature of existing features, might create a huge gap between the factual and legal reality [4]. Documents were drafted, stating four possible legal paths to reach this goal, where the one discussing the structuring and implementation of specific legislation of spatial 3D volumetric parcels was favored by the Israeli Ministry of Justice. These issues were reinforced when planning with an emphasis on complex urban clearly moved towards multi-layered spatial planning: above and under-ground [5]. Assessments made in Felus et al. [6], proved that these should lead to better use of land, protecting its rights and treatment, while preventing illegal use or misuse.

To define a data model for storing 3D objects, Kazar et al. [7] suggested using Oracle’s data model for storing 3D geometries. Stoter and van Oosterom [8] implemented a polyhedron data type in the DBMS as an extension to the geometry model of Oracle Spatial [9], while Groger et al. [10] proposed using existing OGC (Open Geospatial Consortium) standard CityGML. A method for recovering the geometry of a 3D polyhedron depicted in a single parallel projection presented in Lee and Fen [11] uses two sets of information: the list of faces in the object, obtained automatically from the drawing, and a user-identified cubic corner, to compute the coordinates of the vertices in the drawing. Using these two sets of information establishes the 3D geometry of the whole polyhedron. The algorithm exploits the topological structure of the polyhedron, implicit in the connectivity between the faces, resulting in a complexity that is linear in the number of faces. The method is extended to objects with no cubic corners as well. A similar approach is suggested by Ying et al. [12], which can “efficiently recognize and construct solids and represent the topological relationships of valid volumetric solids in 3D space in a straightforward way, whether there is an isolated solid, or a multi-solid/solid set”. Kazar et al. [7] presented different types and rules for storage, validation, and querying of 3D models, arguing that the GM_Solid representation consists of an unsophisticated qualitative model—in comparison to more topological models—for describing 3D geometry. In the same context, validation rules are addressed together with examples of valid and invalid geometries. Authors noted that actual validation rules are domain dependent, as in Cadastre. For example, it is unclear if dangling faces (patches) or self-intersection are allowed. Currently, both Oracle and ESRI geodatabases do not yet fully support 3D topology structure [6]. In conformity with the jurisdiction of Queensland, Australia, a specific set of digital data validation rules in realizing a 3D cadastre is proposed, in which 2D parcels are treated as infinite 3D columns containing the volume above and below ground [13]. Cadastral processes are designed to check and verify different aspects of 3D cadastre, such as verifying 3D encroachments using a cadastral database, disjointing of 3D rights, supporting 3D common property and curved surfaces. Shojaei et al. [14] presented a set of visualization requirements for 3D cadastral visualization systems, identifying three categories: (1) features that are specific to the visualization of the 3D cadastre, such as underground view and cross-section view; (2) features that pertain to visualization systems, such as interactivity and visual representation; (3) additional features that define how a 3D visualization system must behave, such as usability and interoperability.

3D cadastre studies are made, both on a national and international level (e.g., [15,16,17,18,19,20,21,22,23]). These studies conducted a detailed analysis of various 3D spatial configurations in an attempt to examine and finally evaluate the ability to provide a unified and proper configuration of a 3D cadastral system prototype. On a national level, Ho and Rajabifard [24] illustrated a case study on the mandatory introduction of BIM for compliance checking in Singapore, and developed a cyclic framework that could be used to inform the choice of strategic activities to support change. Drobež et al. [25] presented the existing cadastral registration system in Slovenia, discussing the required data for representing 3D cadastre, providing an example of the transition from 2D to 3D. Kim and Heo [26] proposed a data model that is based on LADM for expanding the current 2D cadastral system in Korea into a 3D system. Janečka and Souček [27] presented the Czech Republic LADM-based country profile, creating a conceptual model of the cadastre and tables (classes). Kitsakis and Dimopoulou [28] addressed the public law restrictions of the legal framework in applying a 3D cadaster management system in Greece, featuring the importance of 3D modelling based on a case study. Atazadeh et al. [29] provided a methodology for extending a BIM-based data model to support 3D digital management system of complex ownership spaces in Melbourne, Australia, presenting the data elements that are required for this purpose.

Most studies focused on specific aspects of such systems, such as legal and technical issues concerning 3D cadastre, with an intention to provide an optimal solution for defining and solving certain aspects, including the multiplicity of theoretical alternatives for spatial land registry standards of multi-level property. Van Oosterom et al. [30] and Van Oosterom [31], for example, conclude that no complete 3D Cadastre system, covering all aspects, is yet operational, where in most cases 3D cadastral parcels represent only housing units. Still, a number of countries (jurisdictions) investigated the transition to full spatial registration (e.g., [32]). Accordingly, it seems that in terms of conceptual and technological maturity obtained in Israel, now is the right time to reconsider the required technological and operative processes in accordance with the preliminary productive steps made.

3. Methodology

This research aims at setting an approach for expanding current 2D cadastral systems into 3D systems. The methodology to formalize this approach is set in accordance with the recommendations made by SOI, which structure the implementation of legislation related to 3D volumetric parcels, together with the review of SOI’s “CHANIT” specification; accordingly, recommendations that will set new methods are made, related to processes, functions, and data.

The first recommendation is to define 3D cadastral processes that should be handled by the management system. Since no 3D procedures are involved in the current 2D system, specifications should identify and detail the orders and sequences of 3D cadastral operations, as well as the possible cadastral procedures that might be applied to the 3D system. Main procedures are subdivision, consolidation/union and transfer (between different lots), in addition to other processes that are detailed later. The system is expected to enable automatic validations and verifications of the propriety of performing cadastral procedures with respect to geometric, topological and public law restrictions, on both the vertical and/or horizontal domains. For effectively managing 3D cadastral information, our research suggests the formation of three main processes: (1) Insertion of a new 3D object (2) Visualization of 3D objects (via search criteria entered by the user) (3) Creating a mutation plan. The processes are later detailed in the article, and implemented in python, with the presentation of a conceptual prototype.

The second recommendation focuses on defining the functions needed for performing the described processes. This research concluded that there is a need for carrying out the functions of: spatial intersection, spatial overlap/overlay, spatial buffer/extrusion, spatial union/merge, spatial clip/extract/select, spatial split, spatial delete/erase, distance calculation, area/projection calculation, and volume calculation. These are crucial to enable the system to perform the cadastral procedures effectively. For determining the relationship between two simple spatial parcels, the study uses an algorithm that is based on detecting the relation between the parcels’ nodes [33].

The third recommendation deals with creating a fit-for-purpose data structure and database for archiving the 3D objects. The database is created using SQL in python, where the next step will include the structuring of a small-scale prototype, and implementing a pilot for checking the reliability of the functions (this is not presented here, and is planned for future research).

The recommendations made here will serve as guidelines for constructing 3D cadastral management system. CHANIT specification will be also expanded accordingly. For the sake of expanding the existing 2D management system, database and functionality gaps in CHANIT specification were identified and categorized. Figure 1 illustrates the legal and technical aspects of CHANIT specifications that were reviewed, and that are needed to be modified. Recommendations relevant to the database, the data structure, and the cadastral processes are as follows.

3.1. Cadastral and Geometrical Processes

• Main Operations: according to Jaljolie et al. [2], cadastre management systems should offer these main operations: (1) 3D data collection and organization; (2) Visualization and navigation in the 3D environment; and, (3) 3D analysis, editing, and querying. However, for performing these operations, the technical framework needs to be determined in advance, including data structure, database, software, and hardware. Jaljolie et al. [2] also states that a useful 3D cadastre management system is required to efficiently process the operations and functionalities for a computerized handling of 3D cadastre RRRs, among them: (1) Insertion of a new 3D object (3D volumetric parcel); (2) Visualization of 3D objects (via search criteria); and, (3) Area analysis for plan and design. The first process is presented in Section 4.1 in detail with respect to the basic system functionalities. For providing efficient services, while archiving land RRRs in different zoning plans, cadastral processes include diverse functions for varying purposes. Some of which support taxation, property valuation, registering mortgages for future objects (and other fiscal operations). Other functions aim to enable efficient conveyancing, to support land use planning and land distribution processes. Well-built functions enable executing changes (derived from new/past land arrangements, such as subdivision/split, consolidation/union, transfer between lots, expropriation). Operating functions should be compatible with the correct spatial units, i.e., enabling survey, measure, visualize and store the property in convenient spatial units.
• Queries: Similarly to functions, it is possible to expand and upgrade the existing 2D queries to 3D cadastral systems. The implemented 3D queries should answer the user’s questions and fulfill his demands, which are analogous, in principle, to queries generally activated in 2D systems. For instance: calculating length and area (and now—volume) of parcels/buildings, calculating position (coordinates, datum), identify relationships of land parcels within an area of interest (ID, name, ownership, history, tax, value,…), 2D and 3D parcels, lots and objects—on- and sub-surface.

3.2. Functionalities—Data Integrity and Legality

This topic deals with the topological rules and geometrical validation of 2D and 3D parcels. Many clauses in CHANIT specifications emphasize the importance of 2D data integrity. The expanded specifications suitable for 3D support are designed to ensure 3D data integrity also, with an emphasis on vertical information, from different perspectives:

• Spatial Validation Functionalities: fulfilling the integrity requirements, it is important to build a chain of validation functionalities that ensure the veracity of the 3D data. The input of these new functionalities consist of 3D entities (e.g., structures, volumetric parcels, blocks), and the output can be: “valid”, in a case that there is no conflict of topologic and geometric rules, or “error”, otherwise. Several of these functionalities are listed and detailed in [2].

In the process of insertion a new 3D object/volumetric parcel (see Section 4.1), several geometric and topologic functions and validations should take place, before it is authenticated and inserted into the geodatabase, e.g., receives a system ID. The checklist includes format validity, “safe” distance validity and geometric validity. Format validity verifies that the 3D object topology is valid. The distance between two adjacent objects (above or below the ground) should be no less than the minimum distance according to the existing definition, that ensures, among others, environment protection, maintaining the stability of physical structures, and preventing negative mutual influence between objects. Usually, law and regulations determine the range of physical separation distance between objects. Keeping “safe” distances among 3D objects (especially when it comes to handling objects with no planar geometry, such as tunnels with curved facades, depicted in Figure 2) is one of the most important recommendations that was made by SOI’s 3D cadastre committee (recommendations that will probably be formulated into the 3D cadastre treatment and application). Geometric validity verifies that there is no partial or full intersection between the newly inserted volumetric parcel and the existing 3D objects.

2.

Legal Terminology: specifications should include cadastral guidelines for managing the 3D legal reality (RRRs—rights, restrictions, and responsibilities). Preliminarily, relevant terms should be officially and clearly defined, such as spatial parcel, volumetric parcel, “safe” distance, spatial physical object, etc. Following the basic existing definitions, clear regulations regarding the different aspects of 3D mapping and measurements, recording and storing, editing and submission, should be announced to enable planning institutions and surveyors to work properly and uniformly. For this purpose, new guidelines should be set, and old ones should be edited and updated.

3.3. Data Structure and Database

Although functional 3D databases (geodatabase) exist, enabling the storing, querying and representing of spatial geometric objects, they usually are not fit for managing 3D cadastral-objects; they need to be enhanced so that they would provide sufficient tools for handling complex 3D cadastral topological data models [34]. Geodatabases have yet to be developed and expanded, while according to Breunig and Zlatanova [35]: “the integration of 2D and 3D data models and the development of dimension-independent topological and geometric data models” is of a big importance.

CHANIT specifications provide a number of advantages, mainly with respect to the uniform contents and configurations of all cadastral maps that prevent file incompatibilities (e.g., incompatibility between CAD and SRV (A format used for cadastral data transfer from external sources to SOI: http://mapi.gov.il/ProfessionalInfo/DocLib/srv-v2.pdf (in Hebrew)) files), enabling easy transition from CAD environment to GIS environment. In principle, it is possible to profit from the same advantages in 3D reality-supporting specifications. However, the definition of a configuration for 3D cadastral maps, the type of files that will be used to construct and display the 3D cadastral reality, and the appropriate software for managing 3D properties, need to be defined. These issues are related directly to the data structure and database.

CHANIT specifications define the data structure suitable for 2D parcels and blocks. Accordingly, specifications should be updated for 3D reality management, such that a 3D data structure is required to be clearly defined in accordance with the following points:

• Height Dimension: first critical step is required to add the z-value (height dimension) to the existing coordinates in the operative database. According to previous recommendations made in Felus et al. [6]: …” So, for 3D parcels, it may be tempting to use relative height w.r.t. Earth surface. However, as the Earth surface may change over time (due to natural or man-related reasons) this is not a stable reference, and it is therefore advised to have at least absolute height in coordinates of 3D parcels, and maintain and use Earth surface (height) description as separate registration”. Such that we recommend that each point in the database will receive an absolute orthometric height value.
• 3D Data Format: the format required for creating volumetric parcels should be determined. Different approaches are prospective for defining a 3D data structure, including presenting a 3D spatial parcel as an extrusion of a 2D parcel, a 3D spatial parcel as a solid polyhedral body, or a 3D spatial parcel as a combination of primitives (points, lines, and facades). To enable a relatively simple and fast transition from 2D to 3D reality, and vice versa, the format recommended for creating 3D volumetric parcels should conform to the data-structure that exists and is implemented today in the CHANIT specifications, i.e., points, lines, and polygons.
• GeoDatabase: current databases necessitate to be amended and configured to be suitable for storing 3D cadastral data. A proper workspace for defining the various classes, features, and constraints of 3D entities is Python, as it allows creating vector layers in Shape File format (ESRI’s shp), currently used in SOI systems. The spatial entities will be implemented into the previously defined classes, while the storage of the entities will be performed by ESRI’s ArcMap and City Engine. Since open-source GIS software support Shape File format, working with alternative GIS software (e.g., QGIS, OpenGIS) should be considered at a later stage. Geodatabases should provide the framework to define the geometry and topology of nature-formed and man-made objects in a unified way [35]. In fact, for building and representing complex 2D/3D objects, it is necessary for the 3D cadastre management system to provide basic topological elements, for example, node, edge, face, and body, or geometric elements: points, line segments, triangles, tetrahedrons, and collections thereof to represent objects. In brief, the data-structure and database would significantly influence the development of the system, the way it is managed and the structure of the functions.

4. Implementation

Following the methodology and findings detailed in Section 3, we aim to provide practical recommendations for augmenting and promoting the existing operative 2D cadastral system to be suitable for comprehensive 3D land management. Accordingly, functions and processes are detailed here. Updated and additional classes, properties and methods, necessary for representing and handling 3D objects, are also suggested.

4.1. Functions and Processes

The basic system functionalities were identified and detailed based on a review of requirements that should serve all processes and terms of a 3D cadastral information system as mentioned in Section 3.2. The main processes were detailed in Jaljolie et al. [2], where as an example, in this section the process of insertion a new 3D object (3D volumetric parcel) is described in detail. In general, when inserting a new 3D volumetric parcel, several geometric and topologic functions and validations should take place, before the new 3D volumetric parcel is authenticated and inserted into the geodatabase, e.g., receives a system ID. These are depicted in the workflow in Figure 3, with a graphic example in Figure 4 and Figure 5. The stages are as follows, where after a 3D object is inserted, it passes through a detailed checklist, which outputs ‘true’ in the case that the object fulfills all the requirements and integrity rules, or ‘false’—in case it does not.

4.1.1. Format Validity

In the first stage, the system checks whether the topology stored for the 3D object is valid with respect to the one used in the GeoDatabase. In case the topology is not valid an error message will be presented, otherwise the process proceeds to the next stage.

4.1.2. “Safe” Distance Validity

This spatial validity verifies whether the distances between the new input 3D object and other neighboring objects (objects exist in its near space) are legal. The output depends on the system’s allowed “safe” distance definition, which is the minimum distance that should be preserved between any adjacent physical objects (see Section 3.2). For ensuring “safe” distances, and examining the proximity to neighboring 2D and 3D objects, the use of functions Buffer and Extrusion is made. According to the recommendations of SOI’s 3D cadastre committee, enlargement and reduction of 3D objects are intended for the examination of 3D objects and their correspondence with cadastral conditions on the one hand, together with the possibility to join such two neighboring 3D bodies into a single 3D object—on the other. Using the Buffer function is available here in different implementations:

• Using multiple offsets: one offset in the horizontal plane (“sideways”), and another offset in the vertical plane (“Height”/Extrude). It enables choosing vertical and horizontal buffers separately and independently. Working in this mode is considered for a 3D object when preserving “safe” distance is requisite in only one plane: either horizontally or vertically, or in case different “safe” distances exist for the different planes.
• Using a single offset (XYZ): this function enlarges a 3D object both vertically and horizontally in the same factor.

If the distances between the new inserted 3D object and the existing neighboring objects in the system do not deviate from the minimal required “safe” distances (as required by the law and regulations), the object proceeds to the next validation stage.

4.1.3. Geometric Validity

This stage uses the Intersection function: it checks whether the newly inserted object (or its “buffer”) intersects an existing object (or its “buffer”). In this case, an insertion of a 3D object, the intersection of 3D objects is applied first. In case the new inserted 3D volumetric parcel intersects existing 3D objects (whether partially or fully, as in contain), the system returns an error message, and the new 3D volumetric parcel is not added to the database. In case there exists no intersection among 3D objects, the next validation is concerned with the projection on the X-Y plane of the new 3D object and existing 2D objects (parcels). If there exists no intersection with other 2D objects, e.g., it is fully contained, the new 3D volumetric parcel is saved into the geodatabase, i.e., receives an ID, and the process of inserting a new 3D parcel ends. Otherwise, the inserted 3D volumetric parcel is associated with the 2D parcels according to the intersection of the 2D polygons geometry. According to [6], however, “To each of the 3D sub-parcels the same right and party should be attached, both initially, but also in future transactions (e.g., a tunnel that is sold to a company). The split process is necessary only in intermediate stages: “It is better to allow 3D parcels crossing many surface parcels. They could be created in one transaction involving all surface parcels, each selling a part of their property, to create a single 3D subsurface parcel to which the right and party can be attached (for the tunnel). So far, the historic reflections on the sub-parcel concept” [6].

The split action, which is required for indexing, is done by the Split function, which consists of four sub-functions; each is responsible for a slightly different operation. Only two are relevant here: (1) split of 3D objects in relation to existing/neighbouring 2D objects. The input is the new inserted 3D object and one (or more) 2D objects describing the limits of the 2D parcels and lots existing in the 3D parcel surroundings (above/below the 3D volumetric parcel). The function suggests the split of the 3D object on vertical planes determined by X-Y coordinates of the 2D objects. The output is two—or more—3D objects (multiple polyhedrons) created by splitting of the original 3D object. (2) Split of 3D objects as a function of geometric/cadastral constraints. The input is the new inserted 3D object, the geometric constraints function and/or the cadastral threshold values function. The output of the process will usually be composed of two—or more—3D objects derived from splitting up of the original 3D object. Examples of applying split of 3D objects as a function of geometric constraints could be splitting a 3D cadastral parcel on a horizontal or vertical plane; parallelism or perpendicularity between faces of the 3D object are maintained. Minimal object volume and minimal area of faces are examples of applying split of 3D objects as a function of cadastral constraints. To summarize, this step enables the split of a 3D parcel in accordance with both the cadastral aspect and topological aspect, as they are manifested in the projection of the 3D parcel on a 2D plane.

Following the Split operation, the process of inserting a new 3D volumetric parcel ends by saving the new 3D object (volumetric parcel) into the system’s geodatabase, i.e., it receives an ID, including all required indexing. This process can be referred to as the process of “Insertion of a 3D plan” if implemented several times until all 3D volumetric parcels that exist in the 3D plan are validated and inserted into the system.

Figure 4 and Figure 5 depict two graphic examples of the process described earlier. Figure 4 represents a valid process of inserting a new volumetric parcel into the existing database. After checking the topology of the newly inserted parcel, a buffer is created according to the required safe distance. Then, the system checks if the new parcel (including its buffer) intersects any existing parcel in the database. Because there is no intersection, the parcel is saved into the database. Figure 5 describes an invalid process, where the extent of the added volumetric parcel intersects an existing 3D parcel, generating a system error message; the new parcel is deleted, and the database is not updated.

4.2. Data Structure and Database

4.2.1. Classes

The main classes existing today in the operative 2D cadastral system, as well as the required new ones, are depicted in Figure 6. In red, new fields and methods relevant for 3D representation in existing classes. For representing 3D data, it is important to define two new classes, depicted in Figure 6 and Figure 7: CLS_3DVolumetricParcels (CLS denotes class) and CLS_3DPolygons, where CLS_3DPolygons represents facades, floors, and roofs. 3D volumetric parcels consist of floor, roof, and facades, while facades, floor, and roof could be defined by the coordinates of their corners (CLS_Point), and by their borders (CLS_Line).

The existing 2D classes should have additional fields (that can be optional in case of pure 2D data), used for representing 3D classes and objects (appears in red in Figure 6). Principle new fields, such as “Height”, should be added to class CLS_Point. CLS_Line indicates straight or curved line segment and should include a new field “Equation” that represents the equation function of the line in space required to make it possible to detect whether the line is vertical, horizontal or diagonal (essential for the practicality of functionalities—see Section 4.1). Adding the “Range” field (i.e., {x,y,z}_min {x,y,z}_max) in CLS_Line to indicate the range of the coordinates can be helpful for detecting the extent (and location) of a spatial line.

The main classes (entities) for representing the land properties are point (CLS_Point), line (CLS_Lines) and parcel (CLS_Parcel). Since mutation plans are submitted in CAD format, additional classes are used for reading the input data from the CAD files and writing them into the geodatabases and tables via the defined processes (CLS_CadReader, CLS_GDBRead, CLS_GDB_writer, and CLS_InProcessTable, depicted in Figure 7). CLS_Incoding serves for converting the layers’ codes that appear in the CAD files to a comprehensible language suitable for storing in the geodatabases. The review of CHANIT emphasizes the importance of different data formats for efficient usage, which makes these classes of big importance.

Hierarchical associations are created for better handling the different 3D entities: CLS_3DVolumetricParcel is associated to CLS_3DPolygon, which is associated to CLS_Line, which is associated to CLS_Point. This is necessary because a volumetric parcel consists of 3D polygons, where polygons consist of lines—which is consistent with the definitions of SOI’s existing 2D land management system, practical for a smooth transition from 2D o 3D.

4.2.2. Fields and Methods

The spatial objects that are considered for registration in deeds are tunnels, foundations and construction poles, sub-ground buildings, parking lots, and infrastructure. All these object types would fall under the category of 3DLegalObject (Figure 6). Every type of entity, whether it is a Line, a Parcel, a Point, a 3DVolumetricParcel, and a 3DPolygon, should have a code for the effective description of the system, such that the relevant class type should be added as a new field named “TypeCode”. For 3DVolumetricParcels, “TypeCode” declares the objects’ type (characteristics), such as a tunnel, foundations, construction shaft, sub-ground building, parking lot—to name a few. The class 3DLegalObject may be composed of more than one 3DVolumetricParcel classes.

According to the review of CHANIT specifications, the planning zones are the valid range of the vertical mapping that should be stated in the regulations in accordance with planning zones. Determining the legal range of vertical mapping depends on the specific mutation planning zone, which may be object type dependent. That means that the valid range of the vertical mapping should be stated in the regulations in accordance with the planning zones and the spatial objects’ types so that surveyors will be able to measure objects clearly and uniformly. This implies that it is necessary to add an association to planning zone (can be implied via spatial overlay). This new field should appear in all classes as “PlanningZone”, also declared in the “General” table, which includes some of the common fields and methods that will be part of all participating classes. “Is2D” field holds the Boolean value “true” in case the object has a constant height value (flat), or “false” in case the object is not planar.

The review of CHANIT recommends allowing the allocation of several land uses for any 2D parcel in accordance with height, inferring adding the fields “Height” and “LandUse”, which have a big importance. An array is a possible structure for the “LandUse” field, the same as a building could have several land uses associated with the horizontal and vertical location. The field “Height” is practically the fundamental field required for establishing a 3D management system since it extends the third dimension and the related important information.

The routines of edit and submission should be announced in the regulations. For practically editing the spatial objects, the methods “EditFields” and “GetFields” should be inserted and added to all classes in the data structure, so that the user can edit fields in a case that a real change is made. The numbering and naming of the 3D spatial parcels should be declared. Numbering is represented by the “ID” field in the data structure. Since the system aims to handle 3D mutation plans, “ID” field should be uniformly set in accordance with the planning zone and the data type of each object.

“LoadPolygons” method in the “CLS_GDB_writer” class is intended for loading facades, roofs, and floors, which are all 3D polygons, where “LoadVolumetricParcels” aims at loading 3D volumetric parcels for creating “volume tables” into the national cadastral database. These methods enable writing the relevant 3D objects into the geodatabase and tables. CLS_Parcel is associated with the 3D volumetric parcels that exist in the 3D entity that contains the volume above and below the 2D “CLS_parcel”, which is necessary for efficient processing in the system (e.g., search), as it associates between a 2D parcel and the 3D objects that are above or below it. Classes in Figure 7 are important since CHANIT specifications demand the submission of CAD files, where certain topological rules are validated and maintained. These rules need to be extended to multi-dimensional reality with an emphasis on 3D parcels. One clause in the specifications requires assuring that 2D parcels consist of closed polylines; this clause will be expanded, as follows: the volumetric parcels will consist of closed facades. The rules, related to 3D management, should be applied, including (among others): a border must not have self-intersection, and no overlaps between neighbouring parcels should exist. Stoter and Zlatanova [33], for example, suggested a method for determining the topological relationship between two 3D objects.

As depicted in Figure 8, it should be defined to which volumetric parcel the roof, floor and facades belong to, as well as stating to which 2D parcels a volumetric parcel is related to. CLS_3DPolygon is associated to two CLS_3DVolumetricParcels (i.e., left/right adjacent volumetric parcels or top/bottom). In case there is no bounded 3D parcel at one side of a face, then the adjacent corresponding CLS_3DVolumetricParcels would refer to the outside world/space (which can then be traced to the relevant column(s) of space defined by the 2D surface parcels).

5. Conclusions and Future Work

The objective of this research paper is to present recommendations concerning the complete and computerized sets of classes and functionalities required for the management and handling of 3D cadastral objects in a comprehensive 3D land management system in Israel. The rationale and motivation were based on physical and jurisdictional aspects related to the configuration and guidelines made by the SOI by adopting the currently operative 2D cadastral system based on CHANIT specification. Constructing proper and comprehensive classes, properties, methods, and functionalities is an indispensable part of building a good and reliable system. This paper started by identifying and categorizing the existing database and functionality gaps for establishing a 3D land management system implementation in Israel, and, accordingly, outlined the classes, methods and some of the functionalities necessary, required to extend and augment the existing 2D system rather than establishing a new cadastre system. The suggested functionalities and classes belong to two categories: one that is related to the handling of objects and data in the geodatabase (storage and converting between different data types), and the second that refers to the necessary geometric and topologic processes for data management.

So far, research in the field mainly concentrated on the topology of 3D cadastral objects, focusing on 3D spatial relationship models, with almost no discussion on the functions needed for the handling of reliable and correct operations. We believe that implementing these functionalities is vital to allow the establishment of these systems. Our next step is to follow these recommendations and construct an operational 3D geodatabase and data-structure required for handling 2D and 3D objects, integrating these functionalities, while implementing the different cadastral processes. Establishing this will contribute to the practice of good governance, in accordance with the definitions, guidelines and accuracy requirements made by the SOI. The research will also include requisites for functionalities validation and examining their workflow in various conditions and different situations within a system, to be adopted and implemented by the SOI in the near future.

Future work will also consider the creation of drawings and sketches, and the visualization of 3D mutation plans. Looking for a visual representation of 3D mutation plans, it would be necessary to comprehensively investigate the current software used for 2D representation, the symbology, layers, syntax rules, and the manner of converting data to drawings. An investigation of these aspects will indicate on updates and modifications required, so that vertical details, standard data, spatial objects, and information would be clearly represented in future cadastral systems. Next step will include the structuring of a small-scale prototype and the implementation of a pilot for checking the reliability of the data structure, database, and functions.