ESTABLISHING A NATIONAL 3 D GEO-DATA MODEL FOR BUILDING DATA COMPLIANT TO CITYGML : CASE OF TURKEY

This paper presents the generation of the 3D national building geo-data model of Turkey, which is compatible with the international OGC CityGML Encoding Standard. We prepare an ADE named CityGML-TRKBIS.BI that is produced by extending existing thematic modules of CityGML according to TRKBIS needs. All thematic data groups in TRKBIS geo-data model have been remodelled in order to generate the national large scale 3D geo-data model for Turkey. Specific attention has been paid to data groups that have different class structure according to related CityGML data themes such as building data model. Current 2D geoinformation model for building data theme of Turkey (TRKBIS.BI) was established based on INSPIRE specifications for building (Core 2D and Extended 2D profiles), ISO/TC 211 standards and OGC web services. New version of TRKBIS.BI which is established according to semantic and geometric rules of CityGML will represent 2D-2.5D and 3D objects. After a short overview on generic approach, this paper describes extending CityGML building data theme according to TRKBIS.BI through several steps. First, building models of both standards were compared according to their data structure, classes and attributes. Second, CityGML building model was extended with respect to TRKBIS needs and CityGML-TRKBIS Building ADE was established in UML. This study provides new insights into 3D applications in Turkey. The generated 3D geo-data model for building thematic class will be used as a common exchange format that meets 2D, 2.5D and 3D implementation needs at national level. * Corresponding author


INTRODUCTION
In recent years considerable progresses have been realized in modelling 3D geo-data as CityGML ADE for different domains such as noise mapping (Czerwinski et al. 2007;Wilson 2011;OGC 2012), utility networks (Becker et al. 2011;Becker et al. 2013); immovable property taxation (Çaǧdaş 2012); time dependent variables (Wilson et al. 2011); inclusive routing (Prandi et al. 2013); energy potential assessment (Wate & Saran 2015;Bahu & Nouvel 2015;Krüger & Kolbe 2012;Kaden & Kolbe 2014;Nouvel et al. 2015), ubiquitous network robots services (OGC 2012), etc.Most of the above mentioned studies were carried out based on only CityGML specifications, that is existing national geo-data models were not taken into account.The first study that is aligned to both CityGML and national 2D geo-data model was realised in Netherlands in project named 3D Pilot (Stoter et al. 2013;Stoter et al. 2011).The resulting model is called IMGeo: Information Model Geography.
Due to fact that in CityGML specifications ADE generation is described only in XML, the approach that is described in OGC 12-066 referenced numbered "Modeling an ADE of CityGML in UML"-best practice paper is selected as guidance to establish the CityGML-TRKBIS.BI ADE in UML, as purpose of the research presented in this paper.This approach was selected as best alternative for IMGeo version 2.0 among several approaches after discussions within the SIG3D modelling subgroup and other participants (van den Brink, Stoter & Zlatanova, 2013).
Within the concept of reference model-driven framework for modelling CityGML ADEs in UML, the first step is conceptual mapping between CityGML and national information model.To test all stages of the framework for Urban GIS Turkey, Building data theme is mapped with CityGML-Building thematic model.All classes, attributes, code lists and code list values of the TRKBIS are tried to be mapped with related CityGML concept.New classes, attributes and code list values that will be added to CityGML Building model are determined based on this conceptual mapping.Finally, the new model for CityGML-TRKBIS.BI is established in UML with subclassing of the related CityGML classes.
The overall structure of this paper is as follows.Section 2 begins with general description of the existing geo-data model of Turkey (TRKBIS).Detailed structure of the TRKBIS.BI data theme is presented in Section 3. Section 4 is concerned with the methodology used for extending existing building model to CityGML ADE and proposed 3D building geo-data model is presented.Section 5 analyses the results and focus on the future developments.

TURKEY URBAN INFORMATION SYSTEM (TRKBIS-URBANGIS IN ENGLISH)
TRKBIS (UrbanGIS) is a standard for large scale geo-data (1:5000 and larger) which describes definition of object-based, large-scale topographic features.Version 1.0 of the national 2D urban information standard (TRKBIS 1.0) was published in 2012 by General Directorate of GIS (URL-2).The aim of the conceptual model components of TRGIS is to establish interoperable geo-data models that can be used from local to national level (Figure 1).Whole thematic geo-data classes are modelled compatible with both ISO/TC211 and INSPIRE standards.They are also determined based on TRGIS expectations and data requirement analysis (GD-GIS, 2012a).
The Unified Modeling Language (UML) is used as a modelling language for all TRKBIS data themes.TRKBIS objects have 2D geometry that is defined with GML 3 geometry types.Scale and resolution properties of the standard are defined based on Large Scale Map Information Production Regulation (BOHHBUY in Turkish).In Urban GIS data model, maps that have scale larger than 1:5000 are defined as large scale maps according to the regulation.The use of geo-data is determined with 5 level of detail from district (level4), county (level3), province (level2), region (level1), to country (level0).
County level (Level3-Large Scale) is the most effective level for GIS applications in Turkey.Therefore it is accepted as base geo-database level (Aydinoglu 2009).TRKBIS is related with county level and involves geo-data larger than 1:5000 scale.
Municipalities and provincial administrations produce and update geo-data from county level to district level (Figure 2).
Figure 2. TRGIS spatial hierarchy approach (Aydinoglu, 2009) The scope of the TRKBIS building model can be described as follows: "A Building is a construction that is enclosed; can be used individually; suitable for working, residential, recreation, praying purposes of humans; used for the shelter of animals and humans; and design for industry, education and other purposes."(GD-GIS2012b).
"A construction is a moveable or immoveable facility that includes constructions that can be on land and on the water; permanent or temporary; official and private; underground and aboveground.Installations, maintenance and modifications of this facilities are also covered by the constructions concept" (GD-GIS 2012b).
Building data theme comprises data about cadastral parcel, related buildings and building units.INSPIRE initiative aims to develop a common standard for cadastral parcel and building geo-data themes that meets requirements of all European countries (INSPIRE 2013).In Turkey, cadastral data and building data are independent from each other.However, the relation of cadastre and building is provided with parcel number on parcels that have construction ownership.In addition, address information of the building is independent from parcel.
TRKBIS Building (TRKBIS.BI) data theme contains basic required properties of the building and has detaily identified relationships between cadastre and address data themes.It involves buildings, building parts; additional feature types (building unit, installation and other construction) and additional properties, such as official information and more detailed physical description.Feature types of the building data theme are determined according to analyses, discussions with stakeholders and findings of the questionnaires that was realised in TRKBISS project.International standards INSPIRE and ISO/TC211 were also taken into account while determining feature types of the building.3)."OzetYapi (AbstractConstruction)" is the top level feature type in TRKBIS.BI data theme and encompasses basic attributes of the construction.Common semantic properties of OzetBina (AbstractBuilding), DigerYapi (OtherConstruction) and EkYapi (BuildingInstallation) are grouped in this feature type.Attribute kbsNo (identification number) is an object identifier that is defined to relate tables with each other.Temporal data is stored with; "versiyonBaslangicTarihi (creationDate)", "versiyonBitisTarihi (terminationDate)" and "versiyonNo (versionNumber)".These attributes are the same for the other themes.In addition, "insaatTarihi (yearOfConstruction)", "yapiAdi (name)" and "yapiDurumu (conditionOfConstruction)" are defined as priority attributes.In "OzetBina (AbstractBuilding)" feature type, other required attributes of the building are defined detaily.Common properties of Bina (Building) and BinaBlok (BuildingPart) are grouped in this feature type."EkYapi (BuildingInstallation)" represents building elements that are not defined in OzetBina (AbstractBuilding) such as; pedway between buildings, balconies, antennas, etc. "DigerYapi (OtherConstruction)" encompasses self-standing constructions that are related with building data theme and not considered as buildings as it is defined in INSPIRE.The main difference between Bina (Building) and DigerYapi (OtherConstruction) themes is that objects defined in DigerYapi (OtherConstruction) does not need to be enclosed such as; acustic fence, city etc. "Bina (Building)" feature type represents Bina (Building) feature type defined in Address data theme."BinaBlok (BuildingPart)" represents other sub-divisions of the building that are not defined as another feature type."BinaBagimsizBolum (BuildingUnit)" represents administrative aspect of building part or whole building.Building unit has its own access from the outside and functionally independed such as; flat, garage, celler, etc.

MODELING TRKBIS-BUILDING (TRKBIS.BI) AS CITYGML ADE IN UML
Since CityGML specifications do not provide information about generating ADEs with UML, the procedure to obtain the 3D  1).Mapping is the base of CityGML-TRKBIS.BI ADE.However, there is no one to one mappings for all TRKBIS.BI classes.In this case there are two approaches that can be used;


Remodelling TRKBIS concept to find complementary classes with CityGML.This method is used at "OzetBina" class in TRKBIS.


Extending CityGML with a new class which is defined as subclass of related CityGML class.This method is used for "EkYapi (OtherConstruction)" and "BinaBagimsizBolum (BuildingUnit)" feature types in TRKBIS (In TRKBIS BuildingUnit represents independent subdivisions of building which can be separately sold or rented out.There is no equivalent CityGML class.) TRKBIS.BI classes are determined as subclasses of related CityGML classes with their Turkish names.The stereotype of the subclass is no longer a <<featureType>>, It is marked as <<ADEElement>>.Using English names of the classes makes it clearly visible to understand which TRKBIS class is mapped to which CityGML class.Turkish name of the class is added as an alias for documentation purposes.<<ADEElemet>> stereotype provides only the possibility of adding attributes to current CityGML classes and the classes marked with this stereotype cannot be seen in GML application schemas that is generated automatically from UML models.In addition, the relationship between CityGML class and related subclass is marked with <<ADE>> stereotype.
TRKBIS "Bina (Building)" is related with CityGML "Building", "EkYapi (BuildingInstallation)" is related with CityGML "BuildingInstallation" class and "BinaBlok (BuildingPart)" is related with CityGML "BuildingPart" class by adding only new properties to current CityGML classes.Classes that are existing in TRKBIS model but not in CityGML are added as new classes as a subclasses of current CityGML classes.TRKBIS "BinaBagimsizBolum (BuildingUnit)" and "DigerYapi (OtherConstruction)" classes are examples of this situation (Figure 5).Properties of these new classes are defined in the model too.These classes may be visible in the GML application schemas that are generated from UML models automatically (Figure 6 and Figure 7).

CONCLUSIONS AND FURTHER RESEARCH
In this paper a new building data model (CityGML-TRKBIS.BI) has been proposed to be used as a common 3D geo-data model for storage and exchange of information about large-scale applications.This is the first study on extending CityGML data model according to Turkey national large-scale geo-data model for 3D applications.The developed model is mainly based on ADE mechanism of CityGML and provides integration between national data models and international CityGML standard.
The developed ADE might be an example for developing CityGML compatible data models for other domains.The follow-up research will look at a generic approach to 3D geodata model for Turkey.In this concept, all other data themes in Urban Geo-Data Model of Turkey (TRKBIS) will be remodelled according to CityGML data model with the help of experiences gained from CityGML-TRKBIS.BI application.
Currently the research on mapping other data themes of TRKBIS is running in parallel and as a result; a Turkey national large-scale 3D information model that covers all classes of existing 2D urban geo-data model (TRKBIS) and that is based on OGC CityGML standard will be developed.
Many further research topics are also identified during developing process of the CityGML-TRKBIS.BI ADE.Firstly, we have to do more research to identify how the new model works with real data.For this purpose, example 3D TRKBIS data is required at different levels of detail.Secondly, further work is needed for generating GML application schemas from identified UML models.In addition, encoding code list values with appropriate structure (SKOS, OWL, etc.) needs further attention.

Figure 4 .
Figure 4. Mapping between TRKBIS and CityGML data themes (Attributes marked with red in TRKBIS-AbstractBuilding are added to CityGML-AbstractBuilding with ADE mechanism).

Figure 5 .
Figure 5. Classes that are existing in TRKBIS model and added to CityGML model.

Figure 6 .
Figure 6.CityGML-TRKBIS.BI ADE (classes with green colour shows TRKBIS feature types; classes with light pink shows CityGML feature types; classes with dark pink shows new ADE classes).
As a result, all features of AbstractConstruction are inherited by related data themes.BuildingUnit is designed with distinctive structure and attribute named kbsNo is reused in this feature type to provide relation with other tables.Building and BuildingPart are related with each other and multiplicity property is defined for this relationship that means building or a building part can related with more than one building units.According to aggregation relationship defined between Building and BuildingPart, BuildingPart cannot exist without Building feature type (Figure TRKBIS Building (TRKBIS.BI) data theme provides data about building, building part, building installations, other constructions, etc. for different applications.Information about building and building parts are represented with area geometry and covers extended 2D properties of INSPIRE building thematic data group.TRKBIS.BI application schema is composed of feature types, data types, code list values and relationships between classes.
geo-data model from TRKBIS.BI builds on the work ofVan  den Brink et al. (2014).The model driven framework proposed by 3D Pilot in the Netherlands is the best practice for applying CityGML ADE mechanism in UML.However, there were structural differences in both data models; Dutch case IMGeo and Turkey case TRKBIS.As distinct from IMGEO data model, of the application and CityGML generic classes  Deciding which subclasses should be extended  Defining application code lists  Defining a geometry representation for each class for each applicable level of detail  Defining topologically correct LOD In this concept, corresponding classes, attributes, code lists and code list values are determined between CityGML Building model and TRKBIS.BI data themes (Table

Table 1 :
Summary of mapping CityGML and TRKBIS-Building data themesIt is decided to use TRKBIS.BI code list values instead of values determined in CityGML specifications.According to CityGML standard, code list values can be determined outside of the model.In CityGML 2.0, the mechanism is determined for extending and replacement of code list values.In this concept, all attribute values that use code list values must be identified with "gml:CodeType" attribute type.Optional code space is added to values that are determined with "gml:CodeType".
CodeSpace provide relationship between attribute and the dictionary that include code list values of this attribute with using URI (Unified Resource Identifier).Although CityGML 2.0 proposes a GML Dictionary Profile for encoding code list values, it is deprecated in GML 3.3.New standards are developed for this purpose such as; SKOS, OWL and RDF.In the scope of this research it is decided to use SKOS (Simple Knowledge Organisation System) for encoding code list values.This concept will be detailed in further research.