INTERLIS Language for Modelling Legal 3D Spaces and Physical 3D Objects by Including Formalized Implementable Constraints and Meaningful Code Lists

: The Land Administration Domain Model (LADM) is one of the ﬁrst ISO spatial domain standards, and has been proven one of the best candidates for unambiguously representing 3D Rights, Restrictions and Responsibilities. Consequently, multiple LADM-based country proﬁle implementations have been developed since the approval of LADM as an ISO standard; however, there is still a gap for technical implementations. This paper summarizes LADM implementation approaches distilled from relevant publications available to date. Models based on land administration standards do focus on the legal aspects of urban structures; however, the juridical boundaries in 3D are sometimes (partly) bound by the corresponding physical objects, leading to ambiguous situations. To that end, more integrated approaches are being developed at a conceptual level, and it is evident that the evaluation and validation of 3D legal and physical models—both separately and together in the form of an integrated model—is vital. This paper brieﬂy presents the different approaches to legal and physical integration that have been developed in the last decade, while the need for more explicit relationships between legal and physical notions is highlighted. In this regard, recent experience gained from implementing INTERLIS, the Swiss standard that enables land information system communications, in LADM-based country proﬁles, suggests the possibility of an integrated LADM/INTERLIS approach. Considering semantic interoperability within integrated models, the need for more formal semantics is underlined by introducing formalization of code lists and explicit deﬁnition of constraints. Last but not least, the ﬁrst results of case studies based on the generic LADM/INTERLIS approach are presented.


Background
Over the past couple of decades, rapid urbanization has led to an increasing demand and pressure for land development, resulting in the division of property ownership so that different owners can have property interests in limited space on, above or below the ground surface.This means that the built environment is becoming more and more spatially complex.Currently, land administration practices mainly rely on 2D-based systems to define the legal boundaries of legal interests.In response to the challenges regarding registration of multi-level properties, the feasibility of 3D information and 3D digital models is being investigated, and their need is often underlined.
In the context of the significant developments in computer graphics in terms of modelling and rendering 3D models of urban structures in different formats and Levels of Details (LoDs), the research on the integration of legal and physical notions of objects has received significant attention.Legal information refers to legal interests, legal boundaries and legal attributes, while it is also a prerequisite for the management of Rights, Restrictions and Responsibilities (RRRs) maintained by cadastral data models (LADM, ePlan).On the other hand, data associated with physical objects is characterized by geometric and semantic information in various LoDs, maintained by physical data models (CityGML, BIM/IFC, IndoorGML), which do not support legal or cadastral information.Researchers investigate the integration between legal and physical data models to simultaneously manage both legal and physical dimensions of 3D RRR data, as presented in Section 2.2.
Moreover, automatic and semi-automatic methods based on Conceptual Schema Languages (CSL) offering direct implementable model descriptions of the corresponding conceptual models have been developed.The transformation of the logical model into a physical database provides a better understanding of the model at a conceptual level, while revealing its strengths and limitations.Over the years, a large number of projects have been conducted-mostly within the academic discourse, but also in the industry-in which the technical implementation of LADM country profiles has been investigated.In the last couple of years, several projects have suggested describing the LADM country profiles with the conceptual schema language INTERLIS, as they both share the same Model-Driven Architecture principles [1], as also described in Sections 2.3, 4.1 and 4. 3.
An important step in this direction is the formulation of constraints, which are often initially described in natural language; however, experience has shown that this results in ambiguities.Formal description of constraints is a complex task that needs to be undertaken in the early stages of conceptual design in order to avoid higher costs, as it has negative effects when added too late.The consistency of (spatial) data can be checked if the underlying constraints are properly modelled and enforced [2].UML diagrams, together with Object Constraint Language (OCL) notation, have been found to be a suitable tool for expressing the designed constraints.However, constraints defined in OCL cannot be automatically converted into implementations.
Various formalization approaches applicable to (3D) geo-constraints do exist today, and they pave the way for extending the current state-of-the-art of constraint modelling into a higher dimension; a brief review of them is presented in Section 2.4.Furthermore, the importance of semantics in land administration, mostly used to further provide explicit meaning to code list values in a more refined manner, is constantly underlined in various research projects, as briefly presented in Section 2.5.
It should be noted that this paper is part of a wider research study, some of the results of which have already been presented in previous publications and conferences [3][4][5][6][7][8][9].The paper covers a literature review of the whole spectrum of related work, emphasizing the role and use of the INTERLIS language at an international level.Additionally, it explores the possibilities of linking 3D legal RRR spaces, modelled with Land Administration Domain Model (LADM) [10], with their physical counterparts, described as 3D objects.
To this end, standardization techniques are used in order to explicitly define data models including their constraints, and also to test the performance of advanced technological tools in terms of consistency and integrity.

Scope and Methodology
The need to link the legal and physical notions of objects in order to support 3D applications in the land administration domain, reflecting the interrelations of those two aspects, is presented in this paper.As this topic is broad enough, the paper is structured in a way to cover the wide range of research objectives that need to be addressed; i.e., current best practices and approaches towards this investigation, use of standards in order to realize them, formalisation of constraints, semantically enriched definition of code lists, etc.
Focus is placed on the INTERLIS conceptual language and the corresponding software packages, as well as the implementation of INTERLIS formalism in the LADM standard, specifically in terms of the standard's country profiles for Switzerland, Greece and Colombia.Finally, the paper addresses an approach for enabling the representation of the relationships between physical and legal boundaries, and presents some preliminary results.In order to address the afore-mentioned research objectives, the methodology illustrated in Figure 1 was followed.
ISPRS Int.J. Geo-Inf.2017, 6, 319 3 of 35 research objectives that need to be addressed; i.e., current best practices and approaches towards this investigation, use of standards in order to realize them, formalisation of constraints, semantically enriched definition of code lists, etc. Focus is placed on the INTERLIS conceptual language and the corresponding software packages, as well as the implementation of INTERLIS formalism in the LADM standard, specifically in terms of the standard's country profiles for Switzerland, Greece and Colombia.Finally, the paper addresses an approach for enabling the representation of the relationships between physical and legal boundaries, and presents some preliminary results.In order to address the afore-mentioned research objectives, the methodology illustrated in Figure 1 was followed.Following those steps, the rest of the paper is organized as follows: in the next Section, a literature review is presented covering the whole spectrum of necessary background of research information and practices.Section 3 presents INTERLIS, the Swiss standard for land information systems communication and the corresponding software package.The integrated LADM/INTERLIS approach, as well as the knowledge gained from its implementation approaches in three countries-Switzerland, Greece and Colombia-is discussed in Section 4. The proposed structures for semantically enriched code lists, formalization of constraints and 3D data types in INTERLIS are analysed in Section 5, together with some preliminary results from the prototype implementation of the generic LADM/INTERLIS approach.Finally, conclusions are presented in Section 6, focused on addressing limitations and opportunities that arise from this research, while the last Section is dedicated to discussion and recommendations for future work discussing future trends in this domain.

Related Work
The necessary background information to this research is briefly presented in the following subsections.The need for the third dimension in the field of land administration is underlined in Section 2.1, while current approaches to and initiatives for the integration of legal and physical concepts that have been carried out in recent years are briefly presented in Section 2.2, followed by examples of MDA-based applications implementing LADM profiles from different countries (Section 2.3).The role of constraints in data modelling is highlighted in Section 2.4 and, in the last subsection, the significance of semantics in land administration is presented with reference to the use and management of code lists.Following those steps, the rest of the paper is organized as follows: in the next Section, a literature review is presented covering the whole spectrum of necessary background of research information and practices.Section 3 presents INTERLIS, the Swiss standard for land information systems communication and the corresponding software package.The integrated LADM/INTERLIS approach, as well as the knowledge gained from its implementation approaches in three countries-Switzerland, Greece and Colombia-is discussed in Section 4. The proposed structures for semantically enriched code lists, formalization of constraints and 3D data types in INTERLIS are analysed in Section 5, together with some preliminary results from the prototype implementation of the generic LADM/INTERLIS approach.Finally, conclusions are presented in Section 6, focused on addressing limitations and opportunities that arise from this research, while the last Section is dedicated to discussion and recommendations for future work discussing future trends in this domain.

Related Work
The necessary background information to this research is briefly presented in the following subsections.The need for the third dimension in the field of land administration is underlined in Section 2.1, while current approaches to and initiatives for the integration of legal and physical concepts that have been carried out in recent years are briefly presented in Section 2.2, followed by examples of MDA-based applications implementing LADM profiles from different countries (Section 2.3).The role of constraints in data modelling is highlighted in Section 2.4 and, in the last subsection, the significance of semantics in land administration is presented with reference to the use and management of code lists.

The Third Dimension in the Field of Land Administration
The inherent challenges of the third dimension (3D) in the field of geo-technology, as well as the growing importance of 3D modelling in the complete development of land administration activities, are constantly being underlined, along with their need to be managed, resolved and their benefits maximized.As stated in [11], "3D reality needs 3D design, engineering and analyses"; thus, multiple approaches for 3D data acquisition and modelling, 3D data representation, 3D data storage (in spatial databases), 3D file formats for data exchange, and web services that support 3D features have been developed.Indicatively, in 2004, the United States Department of Labour [12] predicted geo-technology to be one of the three "mega-technologies" of the new millennium that promised to drive radical changes in society.Additionally, smart cities are being mapped directly in 3D with buildings being represented at several LoDs; hence, it is worth considering that such data could potentially be reused for land administration purposes.
While registrations and RRRs are necessary elements in land administration systems, the central element is the land parcel, which defines a 3D volume of legal space, including its physical features.For developments above and below the ground, a 2D land parcel is no longer an appropriate basic spatial component for cadastral models, as it cannot adequately represent 3D properties [13].The increasing complexity of infrastructures and densely built-up areas requires proper registration of the legal status of properties and their spatial components.As stated in [14], "the insight into the third dimension of physical objects helps to understand the location and size of the legal spaces, as well as it is relevant in the context of developing multipurpose cadastral systems".
3D cadastres represent the division of 3D geo-space, and many urban features-such as buildings, open spaces, transportation infrastructure, under/above ground constructions, overcrossing buildings, etc.-are considered 3D cadastral entities [15].As stated by the authors, a 3D cadastral entity (land, marine, air, underground, etc.) is a synthesis of geometry, attributes and social and legal semantics, which is built by processing constructed 3D objects and topological reconstruction, and incorporating semantic information of both the legal space and the physical component.
Furthermore, 4D and 5D modelling are on the horizon, if not already here, which include the time dimension in both spatial and legal aspects, as well as adding different scales of geo-data, especially in the case of physical features.The research of Oosterom et al. [16] introduced a conceptual full partition of 3D space, including time and scale without overlaps or gaps, and realized in a true 5D generic model, providing a sustainable and solid foundation for the Geo Information Infrastructure (GII).

Legal and Physical Reality: Towards Integrated Approaches
Standards have been widely used, since they provide efficiency and support in communication between organizations and countries, as well as facilitating system development and data exchange based on common terminology.In the field of land administration, multiple standards have been developed nationally, regionally and internationally in the form of domain-specific standardization, which is necessary for capture the semantics of this field.Integrating such models in order to support registrations and land administration procedures utilizing Geographic Information Systems, along with Data Base Management Systems and applications, for the purpose of implementing land policy measures, is vital.
Legal cadastral data models (defining legal spaces), such as LADM [10] and ePlan [17], are mainly designed to manage and maintain property interests, and do not integrate their physical counterparts [18].Furthermore, INSPIRE Data specifications on Cadastral Parcels (D2.8.I.6) and INSPIRE Data specifications on Buildings (D2.8.III.2) have been prepared in a way that supports compatibility with LADM.However, Cadastral Parcels focuses on the geometric aspect, without taking into consideration the parties and the associated RRRs applied to it.Moving from land to the sea, the proposed S-121 Maritime Limits and Boundaries Standard [19], built upon ISO 19152, provides a detailed conceptual model description for marine administration based on common national and international requirements.
On the other hand, purely physical models usually manage and store spatial and, sometimes, semantic information at various LoDs; the most frequently used physical data models in the geoinformation field are IFC (ISO 16736:2013) [20,21], OGC CityGML [22], OGC LandInfra/InfraGML [23,24], LandXML [25], and OGC IndoorGML [26].Among those models, CityGML and IndoorGML provide a comprehensive set of entities, most of which could potentially be used for mapping legal interests within indoor environments [27].
Principally, physical data models provide their own extension mechanisms for incorporating legal objects, whereas legal data models can be connected to physical objects through external linkages [27].At the research of Stadler et al. [28] it is stated that since legal and physical objects are often maintained separately, confrontation inescapably will lead to geometrical inconsistencies (as will be noticed in the GII setting).Semantic information can help to reduce the ambiguities of geometric integration, provided it is coherently structured with respect to geometry.
This integration has been investigated in recent years, and various approaches are being developed.The need for integrating legal objects with their physical counterparts has also been underlined by [18], who proposed the "3D Cadastral Data Model" (3DCDM), which defines an application schema of GML, and introducing the concepts of Legal Property Object and Physical Object.The model was developed based on the core cadastral data models, and was extended to support urban physical objects, consisting of packages serving different user requirements and applications.
How LADM can be mapped and encoded with the CityGML schema has been examined, mostly suggesting that ADE mechanisms could be an appropriate solution.Dsilva [29] developed a preliminary ADE for managing legal interests within CityGML for cadastral purposes in the Netherlands, called "KadasterApartment"; Ça gdaş [30] developed a CityGML extension enabling the modelling of cadastral parcels and condominiums to support the requirements of the immovable property taxation system in Turkey; while Rönsdorff et al. [31] proposed two options for creating an ADE using LADM to represent the legal space, and examined how this could be mapped onto the CityGML standard in the context of 3D cadastres.The first option is to develop a jurisdiction-specific profile for LADM, and then implement it as an ADE for CityGML.The second option is to directly implement the fundamental concepts inside LADM, without customizing them for a specific jurisdiction, as a general CityGML ADE.This ADE proposes three core feature classes, namely "Parcel", "LegalSpace", and "LegalSpaceGroup", which are implemented based on the relevant LADM classes.
Gózdz et al. [14] proposed a jurisdiction-specific implementation of LADM as a CityGML ADE within the context of the Polish cadastre.The main objective was to elaborate the possibilities of applying CityGML for cadastral purposes, drawing particular attention to the three-dimensional representation of buildings.In order to link legal objects to their physical counterparts, relationships between the proposed legal classes and "AbstractBuilding" class (from CityGML) were also defined within the ADE mechanism.
Moreover, Li et al. [32] developed a comprehensive LADM-based CityGML ADE as a feasible approach for describing the ownership structure of condominium units in Chinese jurisdictions by proposing a legal and a physical hierarchy.Based on the legislation in China, the proposed ADE facilitates the management of associations between legal and physical notions, and represents the ownership structures of various privately and publicly owned condominium units, defined as multi-level buildings [27].
Gózdz et al. [14] proposed that further research should aim at the investigation of other possible alternatives of combining LADM and CityGML standards, including:

•
embedding the selected CityGML classes into a (broader) LADM framework; and • introducing a link between both domain models (in an SDI or GII setting) using references between object instances.
The authors concluded that introducing semantic representation for land administration within CityGML would be advisable.Isikdag et al. [33] proposed that integrating 3D RRR spaces with 3D physical models (IFC or CityGML) could provide significant benefits for the valuation and taxation of properties.Moreover, cadastral extension of the Unified Building Model (UBM) was investigated by [34], examining the capability of both the IFC and CityGML standards for dealing with 3D cadastral systems.The authors proposed that UBMs could be extended to include boundaries without physical objects or counterparts, which are necessary for representing above-and below-ground RRR spaces in the context of the Swedish jurisdiction.
Oldfield et al. [35] suggested that space objects (IfcSpace), and the grouping of these spaces as legal zones (IfcZone), could underpin the utilization of BIM models in 3D cadastres.It was also reported that the boundaries of legal spaces could be modelled by "IfcRelSpaceBoundary".The presented workflow described how cadastral data requirements could be efficiently communicated between project initiators and authorities, which would, in turn, facilitate procedures for obtaining legal spaces from BIM models.
Kim et al. [36] proposed a framework for a 3D underground cadastral system with the ability to register various types of properties and manage RRR information using indoor mapping for as-built BIMs associated with 3D properties located underground in the context of the Korean jurisdiction.
Recently, Atazadeh et al. [27] has investigated the feasibility of BIM for urban land administration and, in particular, 3D digital management of legal interests in multi-storey building developments.A BIM data model was extended with legal data, and a prototype BIM model for a multi-storey building development was implemented to demonstrate the viability of the extended IFC data model for 3D digital management and the visualization of data related to complex legal arrangements.Relevant entities, suitable for modelling legal information, were identified and proposed in the IFC standard.These entities have been extended to model legal information with the minimum change possible in the current IFC data structure.The adopted approach for extending relevant IFC entities with legal data elements has mainly been predicated on using the extension mechanism provided within the current schema of the IFC standard.
An approach for linking RRR information to indoor environments was introduced by Zlatanova et al. [26], proposing an LADM-based extension for IndoorGML.For this first approach, it was argued that the subdivision of LADM space on the basis of properties and rights-of-use could be used to define semantically and geometrically available and accessible spaces, and could therefore enrich the IndoorGML concept.The second step of the authors' research, described in [37], was to define an external linkage mechanism for associating IndoorGML entities with LADM entities, or vice versa.
Last but not least, LandInfra is a conceptual model developed to model information about land and infrastructure facilities [23,24].It is an OGC standardization approach in which some concepts from the cadastral data models (LADM, and LandXML) have been adopted for modelling legal objects, while some physical entities (adopted from IFC and CityGML) have been utilized for modelling physical objects.LandInfra's encoding standard is InfraGML.
Table 1 summarizes the above-mentioned approaches to legal and physical integration.It is noted that, recently, a comprehensive review of integrated 3D spatial data models was also presented in [27].Finally, it is evident that, while scientific publications-as also presented in the next subsection-represent one type of research output, the next step is to the transfer these into applied software.* The proposed extension has been modified and adopted in OGC's land and infrastructure (LandInfra) conceptual standard [23,24].

LADM Implementations Based on Model-Driven Architecture Applications
The Land Administration Domain Model (LADM) is one of the first spatial domain standards within ISO TC 211, and aims to support "an extensible basis for efficient and effective cadastral system development based on a Model Driven Architecture (MDA)" and to "enable involved parties, both within one country and between different countries, to communicate based on the shared ontology implied by the model" [40].It is a descriptive standard, rather than a prescriptive one that can be expanded, which also meets the need for efficient interoperability, required for fulfilling the principle of legal independence, in which each institution assumes the responsibility for the management of its own legal land objects [41].
As stated by Kaufmann et al. [41], the principle of legal independence stipulates that "legal land objects, being subject to the same law and underlying a unique adjudication procedure, have to be arranged in one individual data layer; and for every adjudicative process defined by a certain law, a special data layer for the legal land objects underlying this process has to be created."Thus, the principle of legal independence is clearly supported within its structure, while MDA facilitates the structuring of specifications and thematic specializations in the modelling process.The model is flexible and widely applicable; and therefore, a plethora of LADM-based country profile implementations have been developed since the approval of LADM as an ISO standard in 2012.
Automatic and semi-automatic methods based on Conceptual Schema Languages (CSL) offering direct implementable model descriptions of the corresponding LADM-based conceptual models have grown the research interest in this field.The rest of this Section briefly presents some approaches based on the MDA concept, in which LADM profiles have been implemented, some of these being collaborations between universities in different parts of the world, working together with manufacturers in putting research into practice.
To start with, Hespanha [42] proposed the description of the initial model in UML packages using Enterprise Architect (EA) software, and then exported and parsed the model into Eclipse UML 2.0 class models and diagrams, enabling its implementation in a PostgreSQL/PostGIS database.The final result was a Java abstract layer, accessible to other applications running under the Eclipse Integrated Development Environment (IDE) and the corresponding database schema, which could be further populated with data.In another approach, Hespanha et al. [43] used IBM's Rational Software Architect for implementing the proposed LADM country profile for the Philippines.
Additionally, research was carried out by Delft University of Technology [44], considering the development of a Computer-Aided Software Engineering (CASE) tool that performs a model transformation where the initial UML model, expressed as an XMI, is translated into an SQL file with a set of DDL (Data Definition Language) commands.However, it is a prerequisite that the UML model (i.e., the LADM-based model) be transformed into a Platform Specific Model (PSM), therefore requiring decisions to be taken regarding the hardware and software platform on which the model will be implemented.
Based on the Social Tenure Domain Model (STDM), as the so-called "developing country profile" of LADM, a pro-poor land rights recording system was developed based on free and open-source geographic software products (PostgreSQL/PostGIS, QGIS Python plugin), with the source code freely available from GitHub [45].LADM was also the starting point for the UN FAO Open-Source Software Project FLOSS Solutions for Open Land Administration (SOLA); an example implementation of LADM (IT System Specification) was released in 2011 using PostgreSQL [46], while LADM was used to develop a concrete feature catalogue for Addis Ababa in 2012 [47].
In recent years, several projects [2,3,5] have suggested describing the developed LADM country profiles with the conceptual schema language INTERLIS.Both INTERLIS and LADM share the same Model Driven Architecture principles [3].
In particular, INTERLIS has been successfully applied in the Swiss Cadastre System for several decades, and became a Swiss standard in 1998.Since 2007, it has been part of the Swiss Federal Act on Geoinformation, and all data models of the Swiss NSDI have to be described with the standard by law.In 2004, the Swiss Land Management Foundation started an initiative to facilitate and speed up LADM implementation by describing the LADM with INTERLIS.The first steps towards the implementation of the Swiss LADM country profile in INTERLIS were introduced by [3]; these are further elaborated in Section 4.1.
Additionally, INTERLIS was selected as the modelling language to obtain a prototype implementation of a proposed Multipurpose Land Administration System (MLAS) for Greece [7].The implementation of the proposed LADM-based model with INTERLIS followed the methodological steps discussed in [3,4], drawing particular attention to the explicit formulation of constraints, code lists and enumeration values, as well as the initial description of a 3D volumetric primitive.
Finally, institutional stakeholders in Colombia, with technical assistance from a Swiss cooperation (SECO) project, have recently developed a Colombian LADM profile, applying an in-depth planned modelling process.Experts working on the project suggested implementing the developed conceptual profile using INTERLIS and thus, an INTERLIS-based COL-LADM data model was developed, which will be applied in World Bank-financed pilot projects related to a new Multipurpose Cadastre [5].The Model-Driven Approach (MDA) defined by the Object Management Group (OMG) [1] was suggested, with LADM being the core standard because of the complex institutional setting for land administration in Colombia and, consequently, the need for improved data interoperability and legal independence, as it is defined in [40].

The Role of Constraints in (Spatial) Data Modelling/Modelling (Geo-) Constraints
There are various ways to model constraints, such as ontology and OCL.Ontology is defined as a "formal, explicit specification of a shared conceptualization" [48].The constraints in ontologies are defined by the components Rules and Axioms.Rules are statements in the form of an "if-then" sentence describing the logical inferences that can be drawn from an assertion in a particular form.On the other hand, axioms are assertions (including rules) in a logical form that together comprise the overall theory that the ontology describes in its domain of application [49].
Moreover, Object Constraint Language (OCL) is a notational language used to build and analyse software models, usually found as part of the UML.Every expression written in OCL relies on the types (i.e., the classes, interfaces, properties, relationships) that are defined in UML diagrams.It is a constraint and query language designed for object-oriented modelling, which enables the automated parsing, processing and implementation of OCL constraints, referring to classes, attributes, associations, and operations [50].
Furthermore, there are multiple database mechanisms that allow the realisation of constraints, via triggers and procedures, which execute the procedural code after hitting the trigger (that is, failing a certain check when data is inserted, updated or deleted).Triggers are used to avoid insertion of invalid data, and therefore make use of the spatial extensions of database management systems [51].
Constraints establish rules with which data must comply and, hence, should be part of the conceptual model (object class definition), as they provide additional semantics to the model.The implementation of constraints (whether at the front-end, database level or communication level) should be driven automatically by these constraints' specifications within the model [52].
Approaches for modelling and enforcing different types of constraints are many and diverse [51][52][53][54][55].As stated by [52,53], the main types of traditional constraints include domain constraints, key and relationship structural constraints, and general semantic integrity constraints; and these have been extended with new ones: topological, semantic and user-defined constraints [53].In particular, the classification of constraints based on relationships between objects can be characterized as follows [55]: thematic constraints, temporal constraints, and spatial constraints.The last can be further categorized into topological constraints, direction constraints, and distance constraints.Mixed constraints occur when the fundamental types of relationship constraints are mixed.
In this paper, the constraints are defined in UML models using OCL, which enables the expression of the constraints at a conceptual level in a formal way, and in a platform/vendor independent manner.Enterprise Architect (EA) software, which supports OCL syntax, as well as the ability to validate the OCL statement against the model itself, was used in the first steps to model the UML diagrams, meaning that verification that the OCL statement is expressed correctly in terms of actual model elements beyond just the syntax was possible, and that the kind of validation syntax that it used corresponded to the actual data types defined for these elements: numbers, strings, collections, etc.The definition of the constraints tested during the LADM/INTERLIS implementation is described in Section 5.2.
It is noted that difficulties are faced in generating an implementation (SQL/DDL) for Enterprise Architect's UML/ OCL models.An indicative example is that there is no normative way to translate UML code lists into SQL expressions, as the corresponding enumerated types of the PostgreSQL are static and cannot be extended.

Semantics and the Meaning of Code Lists in the Land Administration Domain
Semantic technologies (ontologies, RDF, SKOS, etc.) can be used in land administration and other domains to further provide explicit meaning to code list values in a more refined manner than just a hierarchy [56].In the context of Spatial Data Infrastructures (SDIs) or Geographic Information Infrastructures (GIIs), reference tools for sharing and maintaining code lists and their definitions are necessary.Hence, it is vital to establish mechanisms to bridge any difficulties in reaching a common understanding of code lists while, at the same time, allowing machine-readability.
In this domain, research has been carried out in recent years concerning the field of land administration at an international and European level.More specifically, the European Land Information Service (EULIS) Glossary is an initiative of the European Economic Interest Group, an online European portal enabling access to land registries across European countries, each with their own land administration legislation.Its goal is to assist better understanding of the local environment, not only literally, but also with regard to terminology [57], enabling the user to display a term and compare its definition with that in another land registry.
Moreover, according to [56] "firstly, it is possible that a European country may be compliant both with INSPIRE and with LADM and secondly, it is made possible through the use of LADM to extend INSPIRE specifications in future, if there are requirements and consensus to do so".It is noted that the European Directive (INSPIRE) does not include Parties and their associated RRRs in the definition of cadastral parcels, and thus, information regarding RRRs is not included in the code lists.
The approach implemented by INSPIRE is presented with regard to the hierarchical structuring of code list values, and means of managing these [58].The information model used by INSPIRE corresponds to ISO 19135 "Procedures for item registration" [59] for managing and disseminating code lists, and in order to reference the identifiers, all unique resource identifiers (URIs) are used.
Additionally, the Web Ontology Language, developed by W3C, is a computational logic-based language, a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things.OWL (Web Ontology Language) was developed as a vocabulary extension of RDF, while OWL documents, known as ontologies, can be published on the Web and may refer to or be referred to by other OWL ontologies [60].
Soon [38] presented a formalization of domain ontology for land administration from natural language definitions in the standard, emphasizing user roles.In 2014, Soon et al. [39] proposed an extension of the already-developed LADM Web Ontology Language (OWL), i.e., a semantics-based fusion framework for integrating CityGML with 3D LandXML, adopting ePlan as the conceptual model.
Through this framework, it is expected that a computer system will be able to perform reasoning and inference in the OWL ontology, as well as to retrieve the geometries of a building's legal space or physical space, or both [30,61].Subsequently, the authors' intention was to utilize the best of all available concepts (i.e., CityGML, LandXML and OWL) without affecting the existing schemas, which have been comprehensively developed for different applications [39].
Furthermore, Simple Knowledge Organization System (SKOS) is a common data model, and provides a framework for developing specifications and standards to support the use of Knowledge Organization Systems (KOS) such as thesauri, classification schemes, subject heading systems, and taxonomies, within the framework of the Semantic Web [62].It is designed for use as the domain modelling schema when the aim is to represent controlled vocabularies (e.g., taxonomies and thesauri) that organise domain concepts only through hierarchical and associative relationships [62].It provides a standard way of representing knowledge organization systems using the Resource Description Framework (RDF), allowing interoperability between computer applications.Using RDF also allows knowledge organization systems to be used in distributed, decentralised metadata applications [63].
Moreover, the Cadastre and Land Administration Thesaurus (CaLAThe) provides a controlled, standardized representation of structured vocabularies encoded using Simple Knowledge Organization Systems (SKOS) developed by the World Wide Web Consortium (W3C).CaLaThe is inspired by and derived from ISO 19152 LADM [10], and covers terms regarding real estate, cadastre, land administration, and LADM code lists and classes [63].A graphical overview of the CaLAThe term collection related to land is presented in Figure 2.
Recently, a group of researchers has initiated the development of a valuation component for LADM as a draft extension module [64] concerning the fiscal parties involved in the valuation practices and fiscal real property units that are the objects of valuation.This valuation information model provides a template for the specification of valuation databases used for recurrently levied property taxes.This initiative is supported by the development of a domain vocabulary and thesaurus [65] to define the semantics of valuation information encoded through SKOS specifications for the standardized representation of structured vocabularies.
Last but not least, to further provide explicit meaning to code list values, Lemmen et al. [56] provided input for future LADM development, in that they introduced an extended classification of the LADM class of rights, restrictions and responsibilities.As described by the authors, in the current version of LADM, code lists are in the informative part of the standard, and not in the normative part; hence, their values are indicated only by their name, without any definition.They concluded that two aspects of updating LADM code lists can be identified: organizational (who is responsible for managing a register, who can be involved and have access, what are the roles and responsibilities of the involved parties) and technical (systems for the code list registers/database, web services for accessing and updating code list values, etc.).Lemmen et al. [56] were the first to propose the use of semantic technologies, ranging from hierarchically structured code lists to the RDF vocabulary, while for structuring and maintaining LADM code lists, ontologies were proposed [65].The authors mentioned that it is possible to extend LADM and its code lists by using the Legal Cadastral Domain Model [67] and the Social Tenure Domain Model [45] to make it possible to represent RRRs on a more detailed level, including informal rights, restrictions and responsibilities.Figure 3   Last but not least, to further provide explicit meaning to code list values, Lemmen et al. [56] provided input for future LADM development, in that they introduced an extended classification of the LADM class of rights, restrictions and responsibilities.As described by the authors, in the current version of LADM, code lists are in the informative part of the standard, and not in the normative part; hence, their values are indicated only by their name, without any definition.They concluded that two aspects of updating LADM code lists can be identified: organizational (who is responsible for managing a register, who can be involved and have access, what are the roles and responsibilities of the involved parties) and technical (systems for the code list registers/database, web services for accessing and updating code list values, etc.).
Lemmen et al. [56] were the first to propose the use of semantic technologies, ranging from hierarchically structured code lists to the RDF vocabulary, while for structuring and maintaining LADM code lists, ontologies were proposed [65].The authors mentioned that it is possible to extend LADM and its code lists by using the Legal Cadastral Domain Model [67] and the Social Tenure Domain Model [45] to make it possible to represent RRRs on a more detailed level, including informal rights, restrictions and responsibilities.Figure 3 illustrates an ontology diagram showing land-use relations.
Code lists in LADM, and the rest of the ISO standards on which it is based, are used to express a list of potential values with the aim of enabling the use of local, regional and/or national terminology [68].In contrast, by means of enumeration, all values admissible for this type are pre-determined, and cannot be extended without creating a new data type, whereas code lists are more open and flexible.
In terms of the life cycle of a model and its components, the model has a long life cycle, code lists have shorter life cycles, and real data has the shortest life cycle, meaning that it should be changed more frequently.Code lists are considered to be neither part of the model, nor real data; and they need to be updated more often than the model, and less often than the data.Code lists in LADM, and the rest of the ISO standards on which it is based, are used to express a list of potential values with the aim of enabling the use of local, regional and/or national terminology [68].In contrast, by means of enumeration, all values admissible for this type are predetermined, and cannot be extended without creating a new data type, whereas code lists are more open and flexible.
In terms of the life cycle of a model and its components, the model has a long life cycle, code lists have shorter life cycles, and real data has the shortest life cycle, meaning that it should be changed more frequently.Code lists are considered to be neither part of the model, nor real data; and they need to be updated more often than the model, and less often than the data.

INTERLIS-Swiss Standard for Land Administration
This Section briefly introduces the INTERLIS concept and its characteristics as a modelling language, while the INTELIS tools are presented in Sections 3.1-3.7.
INTERLIS is a well-established Swiss national standard (SN 612030 for INTERLIS 1 and SN 312031 for INTERLIS 2) tailored to geospatial applications and, in particular, to geoinformation exchange, and the modelling and integration of geo-data, allowing cooperation between information systems and, especially, geographic information systems [69].
INTERLIS has been part of the Swiss Federal Act on Geoinformation since 2007 [70], and more than 170 data models of the Swiss National Spatial Data Infrastructure (NSDI) have been described in this language.At the same time, INTERLIS is an Object Relational modelling language, which is very precise and highly standardized at the conceptual level assuring a strict separation of model descriptions and data exchange formats [69] and supporting methodological freedom by taking a system-neutral approach.The "duality" of INTERLIS (data model and exchange) is presented in Figure 4.

INTERLIS-Swiss Standard for Land Administration
This Section briefly introduces the INTERLIS concept and its characteristics as a modelling language, while the INTELIS tools are presented in Sections 3.1-3.7.
INTERLIS is a well-established Swiss national standard (SN 612030 for INTERLIS 1 and SN 312031 for INTERLIS 2) tailored to geospatial applications and, in particular, to geoinformation exchange, and the modelling and integration of geo-data, allowing cooperation between information systems and, especially, geographic information systems [69].
INTERLIS has been part of the Swiss Federal Act on Geoinformation since 2007 [70], and more than 170 data models of the Swiss National Spatial Data Infrastructure (NSDI) have been described in this language.At the same time, INTERLIS is an Object Relational modelling language, which is very precise and highly standardized at the conceptual level assuring a strict separation of model descriptions and data exchange formats [69] and supporting methodological freedom by taking a system-neutral approach.The "duality" of INTERLIS (data model and exchange) is presented in Figure 4.
INTERLIS is a Conceptual Schema Language offering the necessary complement to the UML graphic description language [69]; and therefore, INTERLIS-described models are precise, unequivocal, and can be interpreted without misunderstanding.Data transfer between several databases via a common data model (data schema) described in a common data description language is provided by INTERLIS, as also described in Figure 5. INTERLIS is a Conceptual Schema Language offering the necessary complement to the UML graphic description language [69]; and therefore, INTERLIS-described models are precise, unequivocal, and can be interpreted without misunderstanding.Data transfer between several databases via a common data model (data schema) described in a common data description language is provided by INTERLIS, as also described in Figure 5.
As has already been mentioned, it follows MDA principles, enabling the utilization of data modelling in close connection with system-neutral (XML-based) interface services [8], and provides strict separation of transfer and modelling tasks.As a result of the experience with INTERLIS and its corresponding software packages, some incompatibility problems between the UML/INTERLIS Editor and other (commercial) modelling software, such as Enterprise Architect have been found.More specifically, this tool does not use OMG XMI, but, rather, Eclipse XMI, which can sometimes hinder communication with other software.It is noted that this is an issue of the UML/INTERLIS Editor, but not of INTERLIS itself, as INTERLIS does not actually rely on UML, although it supports it.
Among the advantages of INTERLIS are the formal description of constraints using an OCL-like language and the ability to quality-check INTERLIS data against INTERLIS data models using tools enabling automated validation of data.This makes INTERLIS development and use unique, as a system-independent means of providing quality-control mechanisms for models described at a INTERLIS is a Conceptual Schema Language offering the necessary complement to the UML graphic description language [69]; and therefore, INTERLIS-described models are precise, unequivocal, and can be interpreted without misunderstanding.Data transfer between several databases via a common data model (data schema) described in a common data description language is provided by INTERLIS, as also described in Figure 5.
As has already been mentioned, it follows MDA principles, enabling the utilization of data modelling in close connection with system-neutral (XML-based) interface services [8], and provides strict separation of transfer and modelling tasks.As a result of the experience with INTERLIS and its corresponding software packages, some incompatibility problems between the UML/INTERLIS Editor and other (commercial) modelling software, such as Enterprise Architect have been found.More specifically, this tool does not use OMG XMI, but, rather, Eclipse XMI, which can sometimes hinder communication with other software.It is noted that this is an issue of the UML/INTERLIS Editor, but not of INTERLIS itself, as INTERLIS does not actually rely on UML, although it supports it.
Among the advantages of INTERLIS are the formal description of constraints using an OCL-like language and the ability to quality-check INTERLIS data against INTERLIS data models using tools enabling automated validation of data.This makes INTERLIS development and use unique, as a system-independent means of providing quality-control mechanisms for models described at a conceptual level.Because of this, the quality-checking of data (and more explicit semantics via models and constraints) is becoming more and more important, as there is a growing number of users within the Geo Information Infrastructure further removed from the data producers (i.e., who may not know the data well, and may therefore need explicit documentation/explanation).In INTERLIS 2, four As has already been mentioned, it follows MDA principles, enabling the utilization of data modelling in close connection with system-neutral (XML-based) interface services [8], and provides strict separation of transfer and modelling tasks.As a result of the experience with INTERLIS and its corresponding software packages, some incompatibility problems between the UML/INTERLIS Editor and other (commercial) modelling software, such as Enterprise Architect have been found.More specifically, this tool does not use OMG XMI, but, rather, Eclipse XMI, which can sometimes hinder communication with other software.It is noted that this is an issue of the UML/INTERLIS Editor, but not of INTERLIS itself, as INTERLIS does not actually rely on UML, although it supports it.
Among the advantages of INTERLIS are the formal description of constraints using an OCL-like language and the ability to quality-check INTERLIS data against INTERLIS data models using tools enabling automated validation of data.This makes INTERLIS development and use unique, as a system-independent means of providing quality-control mechanisms for models described at a conceptual level.Because of this, the quality-checking of data (and more explicit semantics via models and constraints) is becoming more and more important, as there is a growing number of users within the Geo Information Infrastructure further removed from the data producers (i.e., who may not know the data well, and may therefore need explicit documentation/explanation).In INTERLIS 2, four geospatial primitives are defined: coord (coordinate or point types, described by their axes), polyline (describing linear elements), surface, and area (the two types for polygons, defined similarly to polylines, but implying that the linestring is closed).
ISPRS Int.J. Geo-Inf.2017, 6, 319 14 of 35 geospatial primitives are defined: coord (coordinate or point types, described by their axes), polyline (describing linear elements), surface, and area (the two types for polygons, defined similarly to polylines, but implying that the linestring is closed).Further information regarding the implementation of conceptual models (LADM and related models) by means of the INTERLIS language is presented in Section 4, INTERLIS is vendorindependent, and a tool chain (Java programs) that can be used to automatically generate implementation components for specific environments has been developed, and is briefly presented in the following paragraphs.The tools can be categorized into three main phases (1.data modelling and exchange format definition, 2. database schema and model conform data generation, and 3. data validation phase), as illustrated in Figure 6.A fourth alternative phase refers to the import of data from external data sources.Further information regarding the implementation of conceptual models (LADM and related models) by means of the INTERLIS language is presented in Section 4, INTERLIS is vendor-independent, and a tool chain (Java programs) that can be used to automatically generate implementation components for specific environments has been developed, and is briefly presented in the following paragraphs.The tools can be categorized into three main phases (1.data modelling and exchange format definition, 2. database schema and model conform data generation, and 3. data validation phase), as illustrated in Figure 6.A fourth alternative phase refers to the import of data from external data sources.
ISPRS Int.J. Geo-Inf.2017, 6, 319 14 of 35 geospatial primitives are defined: coord (coordinate or point types, described by their axes), polyline (describing linear elements), surface, and area (the two types for polygons, defined similarly to polylines, but implying that the linestring is closed).Further information regarding the implementation of conceptual models (LADM and related models) by means of the INTERLIS language is presented in Section 4, INTERLIS is vendorindependent, and a tool chain (Java programs) that can be used to automatically generate implementation components for specific environments has been developed, and is briefly presented in the following paragraphs.The tools can be categorized into three main phases (1.data modelling and exchange format definition, 2. database schema and model conform data generation, and 3. data validation phase), as illustrated in Figure 6.A fourth alternative phase refers to the import of data from external data sources.

UML/INTERLIS Editor
The UML/INTERLIS Editor tool is used for the following procedures: • graphical representation of existing INTERLIS data models as UML diagrams, providing a better understanding; and • description of new models (e.g., LADM country profiles) with UML diagrams.
As is mentioned by [6], the INTERLIS model file comprises an ASCII file, as well as a data file *.xtf; hence, it can be opened in any ASCII editor, and due to the development of plugins, there are editors (jEdit and Notepad ++ ) that support syntax highlighting.
A specific feature of the tool is the import functionality for class diagrams of UML models in XMI format.It is noted that this import is limited to models in XMI Rational Rose format (Rational Rose TM UML), as XMI files generated, for instance, in EA software cannot be imported, because they use different XMI versions.However, it is possible to generate an XMI from the UML/INTERLIS Editor and import it into EA.

INTERLIS Compiler
INTERLIS Compiler (ili2c) validates the syntactical correctness and semantic compliance of INTERLIS data models.More specifically, the tool checks for all kind of syntactical errors: missing declaration of data types, syntax errors, wrongly defined attributes or classes, etc.The compiler reads and writes INTERLIS models, and examines whether or not the models are in accordance with the syntactic and semantic conditions of INTERLIS [69].Amongst others, the compiler can generate XML schemas, XML-based exchange format (XTF files), GML schemas and HTML tables.It is noted that this toll is a model/schema checker and not data checker.

INTERLIS Checker
Among other things, a big advantage of INTERLIS is the possibility of validating the model compliancy of the transferred data against its data model [3].INTERLIS Checker (igchecker2) is the official (licensed) software tool used to quality-check INTERLIS XML data against INTERLIS data models (including specific constraints).The input is a INTERLIS data exchange file in XTF (readable by any GIS that recognizes the GDAL-OGR library for vector formats), and the output log files report whether there are errors or not in the input file.The toll is used by the Federal Cadastre Directorate as well as by almost all of the cantons.

INTERLIS Validator
The iliValidator tool was developed with funding assistance from two cantons of Switzerland, and the afore-mentioned Swiss cooperation project in Colombia, and which will be further described in Section 4.3.INTERLIS in Colombia.For this implementation, Java was chosen as the programming language, and the tool can be used with a simple Graphic User Interface (GUI) or the command line.Errors found during validation are logged in a simple ASCII log file or in an INTERLIS transfer file based on a simple INTERLIS ("shape file level") data model.With a configuration file, the user is able to switch the constraints on/off, or downgrade them to warnings instead of errors [5].iliValidator offers the possibility of validating complex user-defined constraints, by calling functions developed in Java from the model and executing them from within the tool.
As underlined by the authors, iliValidator can be used as a programming library, offering the possibility of integrating the data-validation phase into existing software, web services and/or existing processes.

INTERLIS Loader for Relational Databases
In order to facilitate the translation of the object-oriented INTERLIS data models to relational databases, Object-Relational mappings (O/R mapping) were introduced, and are deployed for the implementation phase, using the tools ili2pg (INTERLIS 2 loader for PostgreSQL/PostGIS), ili2ora (INTERLIS 2 loader for Oracle) and ili2gpgk (INTERLIS loader for OGC Geopackage).Recently, the ili2sqlserver (INTERLIS 2 loader for Microsoft SQL Server) was developed.All tools mentioned are part of the ili2db project.
As an example to describe the functions of the tools, the ili2pg, can translate INTERLIS data model definitions to a PostgreSQL/PostGIS database, import INTERLIS data to the database created, and export it again to the XML-based INTERLIS exchange format (XTF).The other tools work similarly for their corresponding database management systems.

QGIS Project Generator Plugin
The Project Generator plugin is a tool developed in Python for QGIS version 3, and built on top of ili2db to centralize the process of generating physical models from INTERLIS models and capturing, importing, editing and exporting data to INTERLIS transfer files (XTF).Users with access to INTERLIS models and QGIS software can produce valid INTERLIS transfer files using QGIS as the data editor, and PostgreSQL\PostGIS as the database (the addition of GeoPackage as an alternative for data storage is currently under construction).
Project Generator downloads ili2db tools if needed, runs ili2db commands to create a physical model, and makes use of such models to configure a QGIS project ready for capturing data.Based on database objects generated by ili2db, as well as on INTERLIS metadata from the original models, Project Generator configures the QGIS layer tree, a form for each layer with appropriate edit widgets for attributes, units, constraints, value lists and relations among layers.With a QGIS project configured in this way, users can capture and edit data according to the rules defined in the INTERLIS models and generate valid data effortlessly.Project Generator can be installed from the official QGIS plugin repository.

INTERLIS Reader/Writer to FME
INTERLIS Reader/Writer to FME (ilii2fme) is a free tool that provides the Feature Manipulation Engine (FME) with access to INTERLIS 2 and INTERLIS 1 transfer files, supporting the rich geometry model of FME.The tool enables reading INTERLIS 1 and 2 data, and is necessary in order to manually define appropriate ili2fme parameters, read and write INTERLIS models, and write GML data.It is noted that FME is a commercial tool.

LADM Implementation in INTERLIS
This Section presents recent experience gained from implementing INTERLIS in LADM-based country profiles, and suggests an integrated LADM/INTERLIS approach.Sections 4.1-4.3present the experience gained from INTERLIS implementation in three countries: Switzerland, Greece and Colombia.
The generic LADM/INTERLIS approach proposed may be implemented in any LADM-based model, in order to produce a platform-independent exchange format linked to the conceptual model, allowing for automated quality control with promising results.Figure 7 illustrates the ISO standards on which LADM is based, and which have been described in the INTERLIS language, as well as the country profiles that have been translated into INTERLIS up until now.
The second version of the core classes and associations of ISO 19152 LADM modelled with INTERLIS 2 was released in 2016, with full 2D and 3D support, in the context of the Project "Modernization of Land Administration in Colombia".This version is more complete and coherent; it should be particularly noted that some code lists and structures (e.g., Image, ExtArchive) have now been completed, while more constraints have been added to various classes (e.g., the LA_SpatialUnitGroup class, and the LA_BAUnit class, as will also be presented in Section 5.3).
This Section presents recent experience gained from implementing INTERLIS in LADM-based country profiles, and suggests an integrated LADM/INTERLIS approach.Sections 4.1-4.3present the experience gained from INTERLIS implementation in three countries: Switzerland, Greece and Colombia.
The generic LADM/INTERLIS approach proposed may be implemented in any LADM-based model, in order to produce a platform-independent exchange format linked to the conceptual model, allowing for automated quality control with promising results.Figure 7 illustrates the ISO standards on which LADM is based, and which have been described in the INTERLIS language, as well as the country profiles that have been translated into INTERLIS up until now.An interesting approach in the case of the Colombian project is the modular approach applied: following the principle of legal independence, and in consideration of the MDA, the COL_LADM model is modularized around a Core or Minimum Model, containing the common elements that define the profile.The core model is implemented by the institutions that are responsible for each thematic area of data, tailoring it according to their specialized needs (Figure 8).Thus, the modular approach described implies that the Colombian LADM profile will be formed by a core model and its extended or specialized models for each of the thematic areas or regionalizations (for instance, a specialized model on the Department/District level).The second version of the core classes and associations of ISO 19152 LADM modelled with INTERLIS 2 was released in 2016, with full 2D and 3D support, in the context of the Project "Modernization of Land Administration in Colombia".This version is more complete and coherent; it should be particularly noted that some code lists and structures (e.g., Image, ExtArchive) have now been completed, while more constraints have been added to various classes (e.g., the LA_SpatialUnitGroup class, and the LA_BAUnit class, as will also be presented in Section 5. 3).
An interesting approach in the case of the Colombian project is the modular approach applied: following the principle of legal independence, and in consideration of the MDA, the COL_LADM model is modularized around a Core or Minimum Model, containing the common elements that define the profile.The core model is implemented by the institutions that are responsible for each thematic area of data, tailoring it according to their specialized needs (Figure 8).Thus, the modular approach described implies that the Colombian LADM profile will be formed by a core model and its extended or specialized models for each of the thematic areas or regionalizations (for instance, a specialized model on the Department/District level).
This generic "modular" approach-i.e., modelling a core profile, which can be extended by multiple specialized thematic profiles closely linked to each other, reflecting the complex institutional land administration setting-can be implemented in any jurisdiction, as part of an integrated LADM/INTERLIS approach.

INTERLIS in Switzerland
In Switzerland, the requirement for a clearly defined data model that can be adapted in flexible ways resulted in the development of a conceptual schema and object-oriented language, INTERLIS.INTERLIS is widely used in Switzerland, where the cadastral core data model, as well as many other models (i.e., utility services, land registry, urban planning, etc.), have been defined with INTERLIS [3].
In [5], it is stated that, in the case of Switzerland, the Act on Geoinformation [70] was an important milestone for applying the MDA approach for the entire Federal Spatial Data Infrastructure.The Swiss Land Management Foundation (SLM), a legal entity that is the result of close cooperation between the Swiss private sector and the Swiss government, started an initiative to This generic "modular" approach-i.e., modelling a core profile, which can be extended by multiple specialized thematic profiles closely linked to each other, reflecting the complex institutional land administration setting-can be implemented in any jurisdiction, as part of an integrated LADM/INTERLIS approach.

INTERLIS in Switzerland
In Switzerland, the requirement for a clearly defined data model that can be adapted in flexible ways resulted in the development of a conceptual schema and object-oriented language, INTERLIS.INTERLIS is widely used in Switzerland, where the cadastral core data model, as well as many other models (i.e., utility services, land registry, urban planning, etc.), have been defined with INTERLIS [3].
In [5], it is stated that, in the case of Switzerland, the Act on Geoinformation [70] was an important milestone for applying the MDA approach for the entire Federal Spatial Data Infrastructure.The Swiss Land Management Foundation (SLM), a legal entity that is the result of close cooperation between the Swiss private sector and the Swiss government, started an initiative to facilitate and speed up LADM development by describing the standard with INTERLIS.The core work was completed in February 2014, the first results were presented to Dutch Kadaster International.Using this integration, the INTERLIS tool chain can be employed to handle and implement LADM-based country profiles in a computer-assisted manner.Exchange of LADM data between IT systems will be easily possible with the XML-based INTERLIS transfer mechanism, thereby improving implementation efficiency and reducing cost.
It is noted that the LADM/INTERLIS approach developed by the SLM was initially implemented for the Netherlands LADM country profile (NL_LADM) in 2014.One year later, the first version of the LADM country profile for Switzerland (CH_LADM) was introduced, which has since been updated to a new version.

INTERLIS in Greece
The starting point of the development cycle of INTERLIS implementation for Greece was a model describing a proposed 3D Multipurpose Land Administration System (MLAS) based on LADM.Kalogianni [7] proposed a model for the LADM Greek country profile (GR_LADM hereafter), which considers the current registration of objects in 2D in Greece while, at the same time, being future proof and covering the requirements for future registration (including 3D).It is noted that this approach was developed at a research level.
This model is considered to be an effort to overcome current shortcomings based on international standards, including the representation of a wide range of different types of spatial units-in 2D and 3D-and aiming to establish an appropriate basis for the National Spatial Data Infrastructure (NSDI) of Greece [8].Given the particular nature of different types of spatial units, and the legislative framework in Greece, as well as the necessity of an integrated structure, an attempt was made to cover all Greek land administration-related information, currently maintained by different organizations, and to harmonize it all in one conceptual model [7].
Consequently, objects (more spatial units) other than those currently comprising the model of the Hellenic Cadastre (HC), were categorized and included in the proposed model, aiming at the creation of a multipurpose land administration system for Greece.Therefore, a wide range of spatial units-including areas of archaeological interest, buildings and unfinished constructions, utilities (legal spaces), 2D and 3D parcels, mines, planning zones, Special Real Property Objects (SRPO) usually found in the Greek islands (anogia, yposkafa), and marine parcels-are supported by the model.
As stated in [71], through the LADM concept, it is possible to describe a common denominator, or a pattern that can be observed in land administration systems.In this context, the concept of "LA_Level" in ISO 19152 is a novelty among the other standards related to land administration, as it is defined as a collection of spatial units with a geometric and/or topologic and/or thematic coherence.Additionally, the class "LA_SpatialUnit" provides various representations of RRRs and legal spaces; thus, a specialization of the "LA_Level" class, the proposed "GR_Level" class, is used to organize the spatial units of the GR_LADM, allowing the flexible introduction of spatial data from different sources and of different accuracies.The country profile also includes the content of various code lists, which are an important aspect of standardization.Figure 9 depicts INTERLIS tools and the sequence followed during the implementation of the prototype for Greece.Therefore, this model was initially described with UML diagrams using Enterprise Architect (EA) software, and then translated into the INTERLIS modelling language (GR_LADM).Next, INTERLIS tools were used to automatically generate implementation components for specific environments (database schema, exchange format, GUI/editor).Real datasets were gathered from Greek authorities involved in land administration procedures and used to populate the database.
The prototype system data refers to the majority of the levels created in the spatial part of the proposed model, mostly concerning condominiums, 2D and 3D rural parcels, archaeological spaces, special real property objects and planning zones.Although the currently available Greek datasets do conform with the structure of the proposed model, as new elements were added, sample data were generated for terms of completeness; i.e., the class GR_Archaeological is a new proposed class for which data was created in accordance with the Greek legislative framework.The database thus populated was used for the assessment.Analysis of the loading and querying of the database provided feedback, and the necessary changes were made to the database schema and the initial conceptual model in order to better represent the reality.
Once a valid INTERLIS model file (.ili format) is available, a database schema can be created in the PostgreSQL/PostGIS database using the ili2pg tool.Additionally, another possible output from ili2c is XML schema, and this can be used as exchange format.This INTERLIS file is then checked, and if there are no errors it can be imported into the database using ili2pg.

INTERLIS in Colombia
The support from the Swiss government is closely tied to the Peace Accords signed in 2016 between the Colombian government and the Colombian Revolutionary Armed Forces (FARC) [72], which contain an agreement on integral rural reform, including important aspects of establishing a new Multipurpose Cadastre [5,6].Within this context, the INTERLIS-based Colombian profile of LADM (COL_LADM hereafter) is part of a set of product specifications that must be applied by the operators of World Bank-funded pilot projects, executed on behalf of the National Planning Department (DNP).Therefore, this model was initially described with UML diagrams using Enterprise Architect (EA) software, and then translated into the INTERLIS modelling language (GR_LADM).Next, INTERLIS tools were used to automatically generate implementation components for specific environments (database schema, exchange format, GUI/editor).Real datasets were gathered from Greek authorities involved in land administration procedures and used to populate the database.
The prototype system data refers to the majority of the levels created in the spatial part of the proposed model, mostly concerning condominiums, 2D and 3D rural parcels, archaeological spaces, special real property objects and planning zones.Although the currently available Greek datasets do conform with the structure of the proposed model, as new elements were added, sample data were generated for terms of completeness; i.e., the class GR_Archaeological is a new proposed class for which data was created in accordance with the Greek legislative framework.The database thus populated was used for the assessment.Analysis of the loading and querying of the database provided feedback, and the necessary changes were made to the database schema and the initial conceptual model in order to better represent the reality.
Once a valid INTERLIS model file (.ili format) is available, a database schema can be created in the PostgreSQL/PostGIS database using the ili2pg tool.Additionally, another possible output from ili2c is XML schema, and this can be used as exchange format.This INTERLIS file is then checked, and if there are no errors it can be imported into the database using ili2pg.

INTERLIS in Colombia
The support from the Swiss government is closely tied to the Peace Accords signed in 2016 between the Colombian government and the Colombian Revolutionary Armed Forces (FARC) [72], which contain an agreement on integral rural reform, including important aspects of establishing a new Multipurpose Cadastre [5,6].Within this context, the INTERLIS-based Colombian profile of LADM (COL_LADM hereafter) is part of a set of product specifications that must be applied by the operators of World Bank-funded pilot projects, executed on behalf of the National Planning Department (DNP).
Given the complex institutional framework in Colombia, and the need for appropriate inter-institutional exchange of land information, the process of applying LADM as the basis for a Multipurpose Cadastre was carefully planned and implemented, and involved key stakeholders in land administration, as presented in [6].
Figure 10 illustrates the UML diagram of the Colombian cadastre-registry model-the COL_LADM profile model-which includes classes of ISO 19152, and classes of the core and the specialized cadastre-registry model.It is noted that the model is in Spanish.The figure reflects the cadastre-registry model as it is formally described in INTERLIS, described using the UML/INTERLIS Editor, and implemented using ili2db.
One of the results of the project in Colombia is a web system completely based on a FOSS architecture with several interrelated modules, where the proposed LADM-based model is structured around a Core or Minimum Model with various specialized models formed for each of the common thematic areas (e.g., Cadastre and Registry, Valuation, Spatial Planning, Social Mapping for formalization purposes, Protected Areas, etc.) [6].The core model is implemented by the institutions involved, who are responsible for each thematic area of data, tailoring it according to their specialized needs through specific classes, relationships, attributes, sets of values and constraints.Thus, in such a modular scheme, what is represented in a specialized model as a BAUnit on the basis of the legislation of a specific institution, may, in another model, be a restriction.
For the project in Colombia, the tool chain that was available for the implementation of the COL_LADM model in INTERLIS is being further enhanced; for example, the different tools mentioned in Section 3 are being integrated into a software called iliSuite, which has a modern GUI where all of the configuration options of tools can be selected, making the tool chain easier to use in general.The software has so far been translated into the English, German and Spanish languages.
The development of a generic web-based system for receiving, validating and storing INTERLIS data, and which is usable by any land administration institution that has to deal with receiving "Model-conform" data produced by third parties, is almost concluded.The whole system architecture is structured around a web interface, including a dashboard of statistical indicators, a GIS for visualizing the data and publishing it to different users, and a document repository with the aim of managing all documents that serve as the administrative or spatial sources of [6].The core module of the system allows the validation of INTERLIS data through a web interface.It can be used by operators and supervisors of the cadastre surveying projects, as well as-as mentioned above-by other institutions that generate data in compliance with the developed data model (or other official models).This implies a very important conceptual and technological advance, since, with approximately 14 million registered properties in Colombia, only a web-based-and, therefore, automated-validation process would allow this volume of information to be treated in an adequate and timely manner.The validation service takes advantage of the model repository module, in which all official INTERLIS data models are registered, and where the corresponding data model can be selected (or uploaded if not an official model) when proceeding to validate a data set.The use of FOSS, and the modularity of the developed tools, provides great flexibility in terms of integrating them into hybrid GIS environments.

Implementation
Considering semantic interoperability within integrated legal and physical models, the need for more formal semantics is underlined in Section 5.1, while the proposed formal specification of constraints is presented in Section 5.2.Finally, Section 5.3 presents the 3D data types that are supported by INTERLIS.

Code Lists and Enumerations
During the implementation of the Greek country profile in INTERLIS, it was decided that, in case of fixed values, the values of the model would be defined as enumeration types, while for values that can be extended, a catalogue table with referential integrity would be used to express code lists.
Furthermore, INTERLIS offers both options; enumerations can be set as lists of values (and even nested) within the model itself, while code lists from external catalogues can be referenced from the model and imported into the database.The main weakness of the latter approach is the potential lack of synchronization between code lists stored in the database, and their corresponding source.For example, two organizations could be using the same model, but with different list values from the same external catalogue (or even different versions of the catalogue).

Semantics in Code Lists
Consistency in the language and terms used is vitally important to semantic interoperability.Glossaries, dictionaries and ontologies, as presented in Section 2.5, support the coherent development of code lists, improve their consistency, and allow for better understanding of the model, the data, and the code lists.Code list values are similar to normal data content, and may often possess some kind of structure that carries meaning; e.g., hierarchical classification codes.

Implementation
Considering semantic interoperability within integrated legal and physical models, the need for more formal semantics is underlined in Section 5.1, while the proposed formal specification of constraints is presented in Section 5.2.Finally, Section 5.3 presents the 3D data types that are supported by INTERLIS.

Code Lists and Enumerations
During the implementation of the Greek country profile in INTERLIS, it was decided that, in case of fixed values, the values of the model would be defined as enumeration types, while for values that can be extended, a catalogue table with referential integrity would be used to express code lists.
Furthermore, INTERLIS offers both options; enumerations can be set as lists of values (and even nested) within the model itself, while code lists from external catalogues can be referenced from the model and imported into the database.The main weakness of the latter approach is the potential lack of synchronization between code lists stored in the database, and their corresponding source.For example, two organizations could be using the same model, but with different list values from the same external catalogue (or even different versions of the catalogue).

Semantics in Code Lists
Consistency in the language and terms used is vitally important to semantic interoperability.Glossaries, dictionaries and ontologies, as presented in Section 2.5, support the coherent development of code lists, improve their consistency, and allow for better understanding of the model, the data, and the code lists.Code list values are similar to normal data content, and may often possess some kind of structure that carries meaning; e.g., hierarchical classification codes.UML code lists are just lists with values without any structure, and therefore, for the INTERLIS GR_LADM model, code lists were designed as structures with attributes, and given a hierarchical structure, which makes them semantically more meaningful, and also extensible [9].
As also proposed by [73], each code list is implemented in the database with one single table.The table name has the extension "Type" after the code list name of the conceptual model.It consists of a unique identifier (cID) for each code list and description attributes.The advantage of this type of code list is that its value can be updated, and it can also be versioned when adding the attributes "beginDateTime" and "endDateTime".
In the GR_LADM model, the hierarchy is added as a reference to a parent code, the attribute "parent_cID", referring to the "parent" of the code list from which it is inherited, indicating the top-level code list.The attribute should be "NULL" for root codes, as there is no parent (e.g., internationally agreed-upon code lists, as suggested in ISO standards, etc.), while, for the rest, codes are refinements, and have descriptions, comments, etc. Theoretically, the user is not limited to giving only one parent to each code-list value; it could be that the multiplicity can be more than one.However, it was decided, in the context of this research, that for the attribute that indicates the parent of the code lists, the multiplicity would be exactly one (strict hierarchy).
An example from the implementation of a Greek code list is given below in INTERLIS language: With the proposed structure, the values take on a hierarchical structure, which provides some semantics, as terms higher in the hierarchy are internationally defined and agreed-upon, facilitating the communication between different countries and organizations.
Every code list has, in theory, the same structure as the one presented above; and therefore, all code lists could be maintained in a single table with an extra attribute to indicate the actual code list to which the code list value belongs.

Enumeration Types
In the GR_LADM INTERLIS model, there are more enumeration types than code lists.This means stronger typing but, at the same time, fixed sets of values that do not allow the extension of the admissible values for a type.This is preferable in some cases-e.g., in the case of dimensions: 0D, 1D, 2D, 3D-but is not appropriate for code lists that may require extension at some point in the future.The structure of the enumerations, which include a fixed set of values, is not (always) simply linear, but features a hierarchical tree-like structure, as described in [69].The leaves of this tree (but not its branches) form the set of admissible values.This method of creating extensible hierarchical enumerations was used to extend some of the enumerations that have already been introduced in the core LADM model described in INTERLIS, enriching them with the Greek values.
An example of the extensible hierarchical enumerations that were created is given below.In the core LADM model, the enumeration for the LA_StructureType attribute of the LA_Level class was formed as follows: LA _ StructureType = (point, line, polygon, other); INTERLIS offers the possibility of extending the parent domain and inheriting the entire enumeration, while making it possible to overwrite its values (this approach has been applied in the COL_LADM and GR_LADM models), as presented below: other (text, topological, drawing, unstructured));

Formal Specification of Constraints
Constraints in the INTERLIS language can be defined on an object level (MANDATORY CONSTRAINT) or a class level (SET CONSTRAINT, UNIQUE CONSTRAINT) [8].Therefore, some of the constraints/invariants of the LADM model can be directly expressed by the INTERLIS constraint language.

"Hard" and "Soft" Constraints
Constraints can be subdivided into requirements that must be met by all objects ("hard" constraints) and those based on intentions, guidelines, or regulations, which in rare cases can be violated ("soft" constraints).Therefore, hard constraints must always be true, otherwise the transaction will be cancelled, and an error given to the user.For instance, the following represents a hard constraint: "the end date should be after the start date".
On the other hand, soft constraints may not always be true, and in the real world there may be some exceptions.Three different ways of dealing with soft constraints are presented in this Section: (1) exception list; (2) percentage of allowed violations; and (3) conditions when the constraint does not apply.
Firstly, if the constraint is true, then the transaction can be continued; if it is violated, then it should be checked whether the case belongs to an exception list.This means that it is a binary decision on the constraint and its presence in the exception list.The exception list can be defined as a way of officially marking entities as an allowed exception.If a soft constraint is violated and case is not included in the exception list, then it is considered to be violating as a hard constraint.The exception list should be created and maintained by the corresponding authorities.
Secondly, in INTERLIS, it is possible to define constraints that only apply as a general rule, and to indicate what percentage of instances of a class must normally comply with the constraint.Such constraints, which can be characterised as "soft" constraints, can be modelled using the rule PlausibilityConstraint.
Finally, adding a condition defining in which cases the constraint has to be checked represents the third type of soft constraint.For the LA_BAUnit class, the constraint {sum (RRR.share)= 1 per type if RRR.shareCheck} applies.The share must be specified, unless this is meaningless for the specific type (indicated by shareCheck = false).In this case, the constraint "sum (LA_RRR.share)= 1 per type" cannot be applied.This is a kind of hard constraint, but the rule is only intended for cases with RRR.shareCheck = true.In such cases, the constraint has to be valid for all of these instances, without exception.
A sample code fragment for modelling constraints in INTERLIS is displayed below: More complex constraints may include spatial data, which is useful for evaluating topological relationships (topological constraint type).The following example shows some topological rules of the COL_LADM model, along with its validation results.The "no_overlaps" function was implemented using Java plugins for iliValidator (spatial data types are explained in Section 5.  Another way to define complex constraints is to create a TYPE MODEL that contains all defined functions.These functions must be implemented externally using Java code to create plugins for the iliValidator tool.After that, the model with the function definitions can be imported into any INTERLIS-based model, and the functions can then be used to create complex constraints.Here again, the advantage of using INTERLIS is the possibility of importing one model into another, applying the "modular approach", as discussed in Section 4.  12 illustrates a set of test data, including an overlapping area between two polygons.Another way to define complex constraints is to create a TYPE MODEL that contains all defined functions.These functions must be implemented externally using Java code to create plugins for the iliValidator tool.After that, the model with the function definitions can be imported into any INTERLIS-based model, and the functions can then be used to create complex constraints.Here again, the advantage of using INTERLIS is the possibility of importing one model into another, applying the "modular approach", as discussed in Section 4.3.

Cross-Model Constraints
Apart from the associations and constraints that exist within a single domain (i.e., legal or physical) would be wise to define some "cross-model" associations and constraints with regard to both the legal (which could refer to LA_SpatialUnit in LADM) and the physical (which could refer to either CityGML or IFC) aspects.Such associations and constraints should both exist on the conceptual level of the two models, and also be supported at the implementation stage in order to enhance the efficiency and reliability of the model [2].
In the context of this research, a cross-model constraint was defined as follows: "the buffer of the physical object should always be inside the legal object".For the implementation of this constraint, a buffer

Cross-Model Constraints
Apart from the associations and constraints that exist within a single domain (i.e., legal or physical) would be wise to define some "cross-model" associations and constraints with regard to both the legal (which could refer to LA_SpatialUnit in LADM) and the physical (which could refer to either CityGML or IFC) aspects.Such associations and constraints should both exist on the conceptual level of the two models, and also be supported at the implementation stage in order to enhance the efficiency and reliability of the model [2].
In the context of this research, a cross-model constraint was defined as follows: "the buffer of the physical object should always be inside the legal object".For the implementation of this constraint, a buffer is used to examine the cross legal-physical representations, as the boundaries of the object could be subject to the resolution of the representations, data quality, and accuracy.It is evident that the physical boundary of the object, including potential inaccuracies, should be inside, or at least overlap with, the legal boundary.
However, this relation is often more complex, and the multiplicity is not always one-to-one.For instance, multiple buildings may be located inside one parcel, or multiple interior spaces located inside a complex building structure; these are related to each other, and together they form one bigger legal space.Hence, given the above, the legal (or, correspondingly, the physical) space can be defined as a collection of 3D parcels in which the multiplicity is many-to-one (* . . .1).
Figure 13a,b illustrates the ownership status of the building, and its corresponding physical model.For the physical representation, a 1 m buffer has been added.Figure 14 illustrates the integrated model, comprising both legal spaces and physical elements.As depicted below, the cross-model constraint is violated, as the physical aspect is not completely inside the boundaries of the legal; the physical part that violates the constraint is shown in red.
ISPRS Int.J. Geo-Inf.2017, 6, 319 26 of 35 However, this relation is often more complex, and the multiplicity is not always one-to-one.For instance, multiple buildings may be located inside one parcel, or multiple interior spaces located inside a complex building structure; these are related to each other, and together they form one bigger legal space.Hence, given the above, the legal (or, correspondingly, the physical) space can be defined as a collection of 3D parcels in which the multiplicity is many-to-one (*…1).
Figure 13 (a and b) illustrates the ownership status of the building, and its corresponding physical model.For the physical representation, a 1 m buffer has been added.Figure 14 illustrates the integrated model, comprising both legal spaces and physical elements.As depicted below, the cross-model constraint is violated, as the physical aspect is not completely inside the boundaries of the legal; the physical part that violates the constraint is shown in red.

3D Data Type in INTERLIS
LADM is based on ISO 19107, which specifies conceptual schemas for describing the spatial characteristics of geographic features and a set of spatial operations consistent with these schemas [74].When LADM was initially translated into INTERLIS, it included the basic concepts, but was limited with respect to 3D support.The second version of LADM described in INTERLIS was released in 2016, including the second version of ISO 19107 in INTERLIS, and now supports both 2D and 3D However, this relation is often more complex, and the multiplicity is not always one-to-one.For instance, multiple buildings may be located inside one parcel, or multiple interior spaces located inside a complex building structure; these are related to each other, and together they form one bigger legal space.Hence, given the above, the legal (or, correspondingly, the physical) space can be defined as a collection of 3D parcels in which the multiplicity is many-to-one (*…1).
Figure 13 (a and b) illustrates the ownership status of the building, and its corresponding physical model.For the physical representation, a 1 m buffer has been added.Figure 14 illustrates the integrated model, comprising both legal spaces and physical elements.As depicted below, the cross-model constraint is violated, as the physical aspect is not completely inside the boundaries of the legal; the physical part that violates the constraint is shown in red.

3D Data Type in INTERLIS
LADM is based on ISO 19107, which specifies conceptual schemas for describing the spatial characteristics of geographic features and a set of spatial operations consistent with these schemas [74].When LADM was initially translated into INTERLIS, it included the basic concepts, but was limited with respect to 3D support.The second version of LADM described in INTERLIS was released in 2016, including the second version of ISO 19107 in INTERLIS, and now supports both 2D and 3D geometries, as well as 3D structures.More precisely, the basic 3D types defined are GM_Point3D,

3D Data Type in INTERLIS
LADM is based on ISO 19107, which specifies conceptual schemas for describing the spatial characteristics of geographic features and a set of spatial operations consistent with these schemas [74].When LADM was initially translated into INTERLIS, it included the basic concepts, but was limited with respect to 3D support.The second version of LADM described in INTERLIS was released in 2016, including the second version of ISO 19107 in INTERLIS, and now supports both 2D and 3D geometries, as well as 3D structures.More precisely, the basic 3D types defined are GM_Point3D, GM_Curve3D and GM_Surface3D, and the 3D structures are GM_MultiCurve3D and GM_MultiSurface3D.
The basic 3D types are defined as follows: The 3D structures are defined as follows:

END GM _ MultiSurface3D;
There is no single definition for a solid, and in general, it is defined as a bounded 3D manifold, without distinguishing exterior boundaries.As stated in [74] "A GM_Solid is the basis for 3-dimensional geometry.The extent of a solid is defined by the boundary surfaces.The boundaries of GM_Solids shall be represented as GM_SolidBoundar".
The authors suggested the following definition of GM_Solid as the basic 3D primitive in their previous work [2]: It is noted that this structure is only a first step towards the definition of a 3D primitive in INTERLIS.A validation function (ILIFunctions.validSolid) as presented above that will ensure that the solid does not intersect with other geometries needs to be developed and added as a constraint in the GM_Solid proposed structure.If the constraint is not met, then a message should be given to the user.Finally, as presented above, in the new version of ISO 19107, the GM_MultiSurface3D structure is defined similarly to the definition proposed by the authors.

Conclusions
In the context of this paper, recent LADM implementation activities are briefly presented, while the need for more explicit relationships with physical models (e.g., BIM, IFC, LandXML, etc.) is underlined and the advantage of using LADM for this purpose (e.g., the external classes in LADM, such as ExtPhysicalBuildingUnit and ExtPhysicalUtilityNetwork) is highlighted.More specifically, the paper addresses an approach for enabling the representation of the relationships between physical and legal boundaries, when this is relevant in a particular country.Thus, by using the integrated LADM/INTERLIS approach, those relationships can be represented in the information model, while defining (and implementing) constraints to ensure that the actual data is valid (i.e., that there is consistency between physical and legal boundaries).Accordingly, from the research that has been carried out up until now on the link between legal and physical notions using international standards, it has been proven that the development of CityGML ADEs is becoming one of the possible solutions for the integration of LADM and CityGML.
As presented with regard to the project in Colombia (Section 4.3) being LADM-compliant will seldom be the reason behind establishing new Land Administration Systems or modernizing the existing ones.However, when a system is being modernized, then compliance with LADM is often required, while systems are benefitted.For this reason, several projects in recent years have suggested an integrated LADM/INTERLIS approach.The recent experience of implementing INTERLIS in three LADM-based country profiles has resulted in important knowledge on how to integrate those standards.
Hence, in this paper, focus is placed on the INTERLIS conceptual language and its corresponding software packages, as well as the implementation of INTERLIS formalism in the LADM standard, specifically in terms of the standard's country profiles of Switzerland, Greece and Colombia.The MDA-based system proposed by the project in Colombia could even be considered to be a basic technological solution for a Spatial Data Infrastructure related to land administration, being interesting even for implementation in the context of smaller administrations (e.g., at the level of a region or a large municipality).Thus, the integrated LADM/INTERLIS approach can be implemented in any LADM-based model to get a platform-independent exchange format linked to the conceptual model.From this integration and the projects that have adopted it thus far, it has been proved that the INTERLIS concept, supported by the development of supplementary tools, can be used as an external validating mechanism for LADM-based models.Considering all the above-mentioned factors, INTERLIS can be characterized as a promising solution for obtaining computer-processable model descriptions, and transferring conceptual model level LADM classes to technical, implementable model in XML [3].The LADM/INTERLIS approach represents a solution for the integration of legal and physical representations in a controlled manner by specifying constraints.The modularity of the LADM/INTERLIS approach (Figure 8), and hence its ability to structure country profiles in a way that consists of a core model that can be extended by several thematic or regional models of the land administration realm, is introduced in this paper.
Moreover, attention is also drawn to the system's development cycle, from conceptual model to the implementation of a working prototype within the proposed Multipurpose Land Administration System for Greece (Section 4.2).The process followed during this development was cyclic and repetitive, providing feedback on the initial model, and improving it in terms of efficiency and technical implementation.Considering the INTERLIS tool chain, several challenges faced during this research include, among others, the formal definition of various LADM constraints (OCL and others) in INTERLIS, including cross-model constraints; the definition of extensible hierarchical and versioning code lists in INTERLIS models achieving semantic meaningful content; discussion of 3D volumetric primitives in INTERLIS; and the introduction of a holistic LADM/INTERLIS approach for developing and implementing country profiles.
Considering semantic interoperability within the domain of land administration, the need for more formal semantics (ontologies, shared terminology and concepts, semantically enriched code lists, thesaurus, etc.) is underlined in this paper.Specifically, the formalization of code list values-and especially versioned code list values (allowing the possibility of changing over time; e.g., refined definition) and hierarchically structured code lists-is proposed and modelled in INTERLIS language.With the proposed structure, the values take on a hierarchical structure, which provides some semantics, as terms higher in the hierarchy have been internationally defined and agreed upon, facilitating communication between different countries and organizations.Adding more content, meaning and structure to the current code lists for the proposed MLAS is another step in the development of the LADM.
Initially, defined LADM code lists may be used as super-classes for a number of specific code lists, whose values may be used to specify the attribute value for each country profile.Additionally, adding a unique identification code for each code list is considered necessary for the establishment of a single management system.It is noted that the unique identifier should not be changed during the life-cycle of the code list.Additionally, the first results of case studies based on the generic LADM/INTERLIS approach have been presented, showing the power of the formalized constraints.
Finally, "Legal Independency" (as introduced by Kaufmann et al. [41]) is a principle of fundamental importance in the context of LADM, ensuring that the layering of data topics is defined under a common framework of spatial reference.Along with this, the "level" concept of LADM outlines a common denominator that can be observed in land administration systems, and represents coherence in different fields (Section 4.2).Hence, it can be concluded that areas and concepts such as "level" would benefit from further international standardization and explicit modelling, as they can be shared among jurisdictions.

Discussion and Future Work
3D modelling techniques are rapidly being developed, providing new challenges and roles in land administration, while the demand for 3D information from stakeholders and decision makers in this field is also growing.As also stated by [75], standards like the Land Administration Domain Model are crucial to jump-starting new initiatives, and are connecting top-down and bottom-up projects, enabling involved parties to communicate based on the shared ontology implied by the model.LADM constitutes a generic expandable domain model, designed to be connected in SDI-setting to data from other domain models and other standards [61].Additionally, LADM provides a reference model for development and refinement of efficient and effective land administration systems, and as an enabler for communication based on the shared vocabulary [76].
While standardization in land administration has been expanded to 3D and even 4D representations, adopting a multipurpose character, effective and efficient system development and maintenance of flexible systems demands further standardization and support with appropriate tools.Given this background, and as the LADM is now being studied, used and implemented around the world, it is inevitable that further issues will arise.Hence, within ISO TC211, the development of the 2nd edition of LADM has already been scheduled, and some of the identified trends, as discussed at the 6th FIG LADM Workshop [77], organized in Delft this year, are: update of current core version of LADM, potential conceptual model extensions (further modelling on RRR's or survey and spatial representation, 3D/4D Cadastre, etc.), definition of a methodology for modelling LADM country profiles, LADM implementation through application schemas, technical models and encodings (CityGML, IndoorGML, BIM, INTERLIS, RDF, etc.), development of a process and workflow standardization (initial registrations, ISO TC307, survey workflow, etc.), and development of sample implementations (open-and closed-source).
As concluded at the same Workshop [78], recent research has focused more on the link of 3D legal spaces with 3D physical spaces; as the (invisible) legal boundaries do not always match with the corresponding physical ones, 3D legal interests may exist when there is no actual construction, and vice versa.These usually lead to complex and ambiguous situations and discrepancies between the situation as presented by the legal models and the reality (physical models), while more integrated approaches have been developed (at the moment at a conceptual level) as described in Section 2. Thus, LADM implementation becomes a matter of priority, which has also been proved by the numerous research and professional projects that have been developed up to now.
Moreover, Multipurpose Land Administration Systems serve numerous goals, such as registering various rules and legal aspects for land use and tenure, spatial planning, taxation, etc.As described in Section 4.2, a holistic approach is taken when designing and implementing such systems, as they comprise land, marine and air parcels, buildings, utilities, archaeological spaces, environmental protected areas, natural resources, spatial planning zones, etc.Most of those cadastral objects have a 3D nature, which is not reflected by traditional registration in 2D systems, and often leads to confusing and complex situations.
The current version of LADM addresses survey, geometry, topology, party, legal and administrative aspects, while, as stated before, the revision of the standard has already been scheduled, and will start this year, and is expected to explore multiple extensions.One of these is LADM implementation of possibilities using either one of the existing application schemas and encodings, or a newly-developed, sample one.In this context, the possibilities of INTERLIS have been explored in terms of its complementary use (as a first step) with LADM, and the first results have been promising.However, much more work needs to be done in this direction.
As a final point in the context of LADM implementation, the "ExtPhysicalBuildingUnit" class (as represented according to CityGML, IndoorGML, or BIM/IFC) should be further explored when linking legal to physical models/ representations, including the level of detail as introduced in for example CityGML.
Considering the next steps, various technical and compatibility problems between INTERLIS tools and other systems should be addressed in their subsequent versions.Specifically, by introducing adequate general XML tools for INTERLIS, it is possible to make the concrete INTERLIS/XML-files available for an even wider range of applications.For instance, translations of standards such as CityGML, LandXML, InfraGML IndoorGML to INTERLIS, or vice-versa, would be interesting and important topics for future research.Furthermore, as INTERLIS starts to break Swiss borders, the update and development of the necessary mappings between the tools and the proposed structures is becoming necessary (i.e., mappings for the proposed hierarchical and versioned structure of code lists).
Additionally, initially defined LADM code lists may be used as super-classes for a number of specific code lists whose values may be used to specify the attribute value for each country profile.As a next step, in order to clear separate country profiles, the principles of the ISO 3166 (the International Standard for country codes and the codes for their subdivisions [79]) could be introduced.The question arises as to who will be responsible for managing the register, as well as who will have access in order to update those values, etc.What's more, complex and extensive constraints must be defined with views (e.g., a view that connects a certain class with itself), thus allowing the comparison of any attribute combination with all other objects of the class.Such constraints can be expressed by creating functions or triggers at the database level or, in cases where iliValidator is used, as functions that could be defined in a separate TYPE MODEL, and which call Java plugins executed by the tool.It is evident that the next version of INTERLIS will cover some of the afore-mentioned proposals.
More complete cross-model constraint and spatial constraint modelling is required, while, at the same time, performing complicated queries in order to visualize and investigate the integration of spatial and non-spatial data will lead to more conclusions.Additionally, the temporal dimension is needed, as both current and historic versions of (legal and physical objects) should always be accessible.
As INTERLIS has the necessary functionalities to be used as an external validating mechanism for LADM models, it is expected that further tools will be developed in order to support a holistic LADM/INTERLIS approach.In this context, and because the 3D primitives have now been introduced in the latest INTERLIS version, tools for 3D volumetric primitive validation should be developed.Ledoux [80] developed a methodology (val3dity) for validating solids according to the international standards, and states that having validation tools that respect the international standards helps to foster interoperability.The automatic repair of invalid solids could be considered as a next step.
As the LADM/INTERLIS approach becomes more familiar, building up adequate know-how in order to implement the LADM by means of INTERLIS should be accompanied by specific courses and on-the-job training in the use of the language and the tools, but also in understanding the LADM as a conceptual model.Some first steps have been made, and a lot of short training courses in exactly the afore-mentioned topics have been carried out in the context of the project in Colombia.
Concerning the next steps of this project, providing continued support to Land Administration stakeholders in Colombia for developing and implementing their thematic or regional models as specializations of the defined core model (spatial planning, tenure formalization, department level) is a matter of priority.The development, maintenance and improvement of the tool chain-i.e., UML/INTERLIS-Editor, ili2db, iliValidator and Project Generator plugin in QGIS-in response to user needs, experience and knowledge gained, and in terms of efficiency, is also one of the planned next steps.
Last but not least, bearing in mind LADM use and development, further "international" modelling of some areas that are frequently used in country profiles is becoming a necessity, as LADM is being more frequently used as a reference model in many countries.Indicatively, the LADM "level" approach needs further exploration in terms of standardized modelling, possibly in terms of legal, geometrical and thematic coherence.Similarly, the modular approach, where a national or core profile is extended by regional or thematic profiles, is productive, and INTERLIS provides the means to formalize such model extensions.

Figure 1 .
Figure 1.Methodology used to address research objectives.

Figure 1 .
Figure 1.Methodology used to address research objectives.
illustrates an ontology diagram showing land-use relations.

Figure 5 .
Figure 5. Data transfer between several databases via a common data model (data schema) described in a common data description language [69].

Figure 5 .
Figure 5. Data transfer between several databases via a common data model (data schema) described in a common data description language [69].

Figure 5 .
Figure 5. Data transfer between several databases via a common data model (data schema) described in a common data description language [69].

Figure 7 .
Figure 7. INTERLIS models used to describe LADM country profiles; country profiles that have been translated into INTERLIS language up until now.

35 Figure 7 .
Figure 7. INTERLIS models used to describe LADM country profiles; country profiles that have been translated into INTERLIS language up until now.

35 Figure 10 .
Figure 10.The UML of the COL_LADM profile.Figure 10.The UML of the COL_LADM profile.

Figure 10 .
Figure 10.The UML of the COL_LADM profile.Figure 10.The UML of the COL_LADM profile.

Figure 11 35 Figure 11
Figure 11 illustrates the web-based system developed for the project in Colombia, which allows for data reception of any INTERLIS-based LADM data, and its integration with a PostgreSQL/PostGIS database and the visualization of any LADM conform data through a GIS Viewer.

Figure 11 .
Figure 11.Integration of tools in the Web-Based System developed for the project in Colombia completely based on a FOSS architecture and developed with an MDA approach [6].

Figure 11 .
Figure 11.Integration of tools in the Web-Based System developed for the project in Colombia completely based on a FOSS architecture and developed with an MDA approach [6].

Figure 12
Figure12illustrates a set of test data, including an overlapping area between two polygons.Another way to define complex constraints is to create a TYPE MODEL that contains all defined functions.These functions must be implemented externally using Java code to create plugins for the iliValidator tool.After that, the model with the function definitions can be imported into any INTERLIS-based model, and the functions can then be used to create complex constraints.Here again, the advantage of using INTERLIS is the possibility of importing one model into another, applying the "modular approach", as discussed in Section 4.3.

Figure 12 .
Figure 12.Test data set created with the QGIS project generator plugin.

Figure 12 .
Figure 12.Test data set created with the QGIS project generator plugin.

Figure 13 .
Figure 13.(a) The physical model of the building (IFC); (b) The legal model of the building.

Figure 14 .
Figure 14.The integrated legal-physical model; where the cross-model constraint is violated is shown in red.

Figure 13 .
Figure 13.(a) The physical model of the building (IFC); (b) The legal model of the building.

Figure 13 .
Figure 13.(a) The physical model of the building (IFC); (b) The legal model of the building.

Figure 14 .
Figure 14.The integrated legal-physical model; where the cross-model constraint is violated is shown in red.

Figure 14 .
Figure 14.The integrated legal-physical model; where the cross-model constraint is violated is shown in red.