Introduction

For many years, researchers in the field have focussed on the visualisation of 3D city models. Innovations in computing helped bring attention to matters such as the realistic construction of 3D models and the automation of the related process. It is clear now that 3D city models must be more than simple geometrical representations of a city (buildings, roads, vegetation) and instead must evolve towards a 3D portray of the objects present in a city, thus allowing the combination of diverse sources of information (Willenborg et al., 2016). This evolution leads to a city information model that is essential for the future management of smart cities (Chaturvedi & Kolbe 2016; De Nicola & Villani 2021; Jovanović et al. 2020).

It is understood that the management of city spaces is closely connected to the development of smart subsystems. The complexity of urban infrastructure demands the existence of smart process management. Until now, researchers worldwide have focussed on the integration of data into 3D models that will allow for the management of the urban environment (Dahan & Ba-Alwi 2021; Yao 2019). Despite the advancements in 3D representation of the urban environment and the methods and approaches available in creating 3D city models (Toth & Jóźków, 2016), there are many problems which need to be overcome to allow for the proper modelling of the urban world in 3D form. Further, it is not simply a matter of representing the 3D environment; it must be interactive. Research shows that the main problems related to 3D modelling are the inability of large data collection (F. Biljecki et al. 2016; Ledoux et al. 2021; Rook et al. 2016), the reduced levels of automation (Jokela 2016; Park & Guldmann 2019; Wendel et al. 2017), the absence of state modelling standards and rules (S. Ates Aydar et al. 2016a, b; Eriksson et al. 2020b; Ohori et al. 2017; Soon & Khoo 2017), and the limited applications for the visualization of city models (Lim et al. 2020; Noardo et al. 2020).

This paper presents a proposal to expand CityGML that can be used for the storage and exchange of data in relation to real estate (especially buildings and to a lesser extent plots) in Greece. GRextADE has been designed with the goal of becoming a national standard for the storage and management of 3D data. No other published ADE proposal has been designed for this purpose. All published ADE that come from countries with an already existing national standard for the management of 3D data have the goal of adapting CityGML to the national standard or are interoperable between the national standard and CityGML. GRextADE does not simply expand the capabilities of the base standard but also describes national peculiarities that characterise the Greek laws and regulations. It proposes a specific XSD/UML, unlike two-thirds of the existing extensions, which are surveys and are limited to pilot proposals, without a published XSD/UML or specific application. It does not overlap with any other published ADE—several ADEs are extensions of each other. It can work as a standalone extension of CityGML or coexist in parallel with another ADE. Last, it is compatible with the new CityGML 3.0 standard.

The main fields for its application could be the design of the urban environment, the management of properties, the prevention of and dealing with destruction, the support for citizens, and the reduction of bureaucracy. These are fields that would improve quality of life, the provided level of agencies offered by authorities, and they would aid financial development.

The development of GRextADE brought a series of challenges both from a design and a technical perspective. Regarding the former, GRextADE could not simply be an extension of the base standard and merely a specialisation in one field. The goal was to describe and organise all national peculiarities, laws, and regulations that rule a field that concerns thousands of citizens, the authorities, and professionals. The modelling had to make good use of the existing data in order to ensure the interoperability with the existing infrastructure. The form and volume of the data did not allow the use of the Generics section of the CityGML specifications. This methodology would have been simpler, given that it does not require the change of the existing CityGML scheme of application. First, we attempted the modelling in this way, but there were problems with the depiction of complex categories of characteristics, the description of semantic relationships between classes, and the ability to support all types of data. As a result, we chose to develop the extension from scratch via a UML diagram by following the coding rules from UML to XML.

In the remainder of this document, a brief introduction into CityGML, the available extensions (ADE) and their visualization capabilities is given. Next, the current situation in the Greek real estate market is presented, followed by the methodology of developing an extension of CityGML for the needs of the country and the visualization of this data. The use of GRextADE is illustrated on a case study. Finally, a discussion of the conclusions follows.

A General Overview of CityGML

CityGML is an open data model for the storage of basic objects and properties of a virtual 3D city model. It is based on XML and allows for the storage and exchange of 3D city models. The basic characteristic of CityGML is the 3D depiction of the geometry and topology between the spatial objects, with the representation of various thematic and semantic attributes, their classification, and their grouping (Fig. 1). It uses the Open Geospatial Consortium’s Geography Markup Language 3 (GML 3.1).

Fig. 1
figure 1

Overview of the CityGML modules (cf. Gröger et al. 2012)

Full size image

CityGML is structured in several sections (Fig. 2). The vertical sections correspond to the different thematics (bridge, building, city furniture, city object group, land use, relief, transportation, tunnel, vegetation, water body), whereas the horizontal (CityGML core, appearance, generics) refer to the relevant structures or to structures that can be applied to all the vertical thematic sections.

Fig. 2
figure 2

source: OGC City Geography Markup Language (CityGML) Encoding Standard)

Schematic representation of the CityGML 2.0 standard (

Full size image

In the framework of semantic 3D city modelling, CityGML is the only available open data model and allows for a complete representation of all the city objects to the city’s scale and their relationship with one another. It defines different standard levels of detail (LODs) for 3D objects. This standardised representation can be used in a variety of ways.

CityGML Application Domain Extension (ADE)

One of the core advantages of CityGML is that it can be augmented with an Application Domain Extension (ADE). The ADE concept was introduced in the early days of CityGML (CityGML 0.4, released in May 2007). Its two main goals are to provide the capability of adding new objects and features as well as new properties and values to existing classes, in order to increase the modelling offered by CityGML.

The developers of CityGML 2.0 (OGC 2012) have included two examples of ADEs, the noise ADE and the ubiquitous network robots services (UNR-PF). The first one as a goal is to provide support for generating noise pollution maps with simulations based on 3D city models, while the second one provide features necessary for robot navigation and is an example of an ADE that is dependent on the LOD (Teramoto et al., 2012). Other popular examples are the Energy ADE (Agugiaro 2016; Agugiaro et al. 2018; Nouvel et al. 2015) which is enriching the data model with information required for energy simulations and the UtilityNetworkADE (Becker et al. 2011, 2013; Kutzner & Kolbe 2016) which enables modelling utility networks in CityGML. Αn overview of the published ADEs from the introduction of CityGML (2008, version 0.4) to 2018 has been presented by Biljecki et al. (2018a).

There are several geospatial and visualisation software (free and commercial) that can be used to visualise these ADEs. A visualiser that supports both CityGML and ADE extensions (Lim et al. 2020) is FZKViewer,Footnote 1 developed by IAI/KIT.Footnote 2 It has incorporated the schemas of the most widely used and widespread ADEs, projecting their geometries and semantic data (ADE Energy, NoiseADE, UtilityNetworkADE). A relevant proprietary software is the Feature Manipulation Engine (FME)Footnote 3 which is an extract, transform, load (ETL) software that transfers data from one form into another and fully supports CityGML, as well as ADEs.

Related Works: Formation of National 3D Modelling Standards

A 3D model of a city environment is a complex task. In order to ensure the consistency of the 3D models, specifications—the adoption of specific and common practices and modelling rules—need to be followed. The more specific the specifications are during the preparation of a 3D model, the more interoperable, expandable, and as a result sustainable the model will be.

The adoption of national standards would ensure consistency of the modelled objects. In order to achieve a successful national application of a 3D standard, one needs to prepare different development phases: (i) the definition of the standard, (ii) a pilot application, (iii) evaluation, and (iv) universal adoption. A characteristic example of the adoption of a national 3D standard is the implementation of the CityGML extension CityGML-IMGeo ADE by the Netherlands (Van den Brink, et al. 2013). Its implementation was achieved with the participation of national entities, corporations, and volunteers. This extension incorporates CityGML fully to the already existing 2D national information model IMGeo (Information Model Geography) for large-scale topography. The modelling of IMGeo regards 2D geometry of points, curves, or surfaces for all objects. It has been developed in UML (unified modelling language) and includes the definitions of objects for large-scale reproduction (roads, bodies of water, bridges, land usage, etc.) and their properties. The current version, IMGeo 2.0, is fully compatible with CityGML, and the 2D IMGeo data can be reproduced in 2.5D (to simulate height) and in 3D (as a volumetric representation) following the CityGML geometric and semantic specifications. It is used in national databases for large-scale topographical data but also in the national system for the exchange of data. Large-scale topographical data providers are required to share their data and are encouraged to provide any extra data they may have. In this way, the functionality of this specification is ensured and so is its sustainability.

Another attempt to establish a national 3D standard for buildings is that of AvD-CityGM by Germany. What is unique in the case of Germany is that many cities had created their own city models, which were not supported by quality data, and updating them was not always possible, making them obsolete as time passes. This led to the decision to create a national database for 3D buildings (Gruber et al. 2014). AvD-CityGM (CityGML 1.0 ADE, AvD-CityGM) is in essence a national 3D standard for buildings that expands CityGML in such a way as to include the needs for 3D information of buildings (urban design, noise and energy simulations, etc.) in the case of Germany. The sections found at the core of this extension are Building, Generics, and Appearance, and the LODs accepted by the ADE are LOD1 and LOD2, with the additional possibility of adding characteristics for a series of qualitative information (Robert Roschlaub et al. 2018). The data management of AvD-CityGML is through the open-source 3D database 3DCityDB, which includes a spatial database schema for all the thematic sections of CityGML. The development of this ADE took place in two phases. In the first phase, the data regarding building information at LOD1 was gathered, while in the second phase, data for LOD2 was gathered.

Another attempt at creating a national 3D standard took place in Turkey, with the development of a CityGML extension to incorporate data from the pre-existing TRKBIS standard for large-scale topographical characteristics (Serpil Ates Aydar et al. 2016a, b). The design of this extension focussed mostly on how ADEs could be used in the creation of 3D city models based on the Turkish standard. Buildings were compared in CityGML and TRKBIS, and a CityGML ADE was developed via UML that included data (classes, attributes, code lists) from TRKBIS.

Early 2020 saw the publication of a study regarding the development of a 3D modelling standard via ADE for Sweden. It focussed on transferring the pre-existing Svensk Geoprocess Byggnad (SGP Building)—with 2D and 3D building models—and incorporating specific national information. The result of this attempt was the development of CityGML Sve-Test (Eriksson et al. 2020a). It is a national standard that supports the representation of both 2D and 3D buildings. It has made sure, where necessary, to comply with the CityGML standard. It can also incorporate more information regarding national specificities. It should be noted that the development of CityGML Sve-Test was based on the upcoming version of CityGML 3.0. According to the creators of the extension, the unofficial version of CityGML 3.0 was chosen as it includes some new sections that served the needs of Sweden and SGP Building. For example, a core difference is the management and definition of space, AbstractSpace, AbstractSpaceBoundary, and the way the geometrical representations are related to it (Kutzner et al., 2020a). Another example is the option of adding time-related data for the management of the cycle of life of models. One can also create multiple versions of a 3D city model and connect them to each other.

The Situation in Greece, with an Overview of the Infrastructure and an Analysis of the Needs

Greece—a country of 137.000 km2—has 37,000,000 properties. Many of these are either not recorded in the system or are not sufficiently identified. This causes a series of problems and glitches in the management and utilisation of the data. It also hinders the effort to introduce the new reality of smart cities to Greece. The solution to this problem is the creation of a regulatory context for the collection of the data that regulates real estate property and the introduction of a national model for the creation of the framework of a 3D depiction of the urban space.

There is a lot of interest in Greece as a destination for investments of assets in real estate. However, the lack market transparency and delays form a barrier to that. According to the latest report by the real estate company Jones Lang LaSalle (JLL),Footnote 4 Greece is the 41st out of 99 countries and one of the lowest ranked within the EU when it comes to transparency within the market. The lack of sufficient information, inadequate digitisation, bureaucracy, non-completion of the cadastre, the changes in the taxation system, and the spatial planning system are only some of the many reasons that the Greek real estate market is characterised as ‘opaque’. Because of the above problems, delays nearing 8 to 10 months occur during the completion of transactions.

The implementation of the Greek cadastre at the beginning of the twenty-first century made a big difference in stopping construction without a permit and helped organise the space of the country. It is a unified and continually updated database in which all legal, technical, and other information for buildings, as well as the rights related to them, are stored by the Greek public sector.Footnote 5 Its goal was the creation of a modern, completely automated archive of real estate ownership, the details of which could also be used for verification. It thus ensures the greatest possible transparency and security for transactions. Unfortunately, this work is not yet complete, and most of the information incorporated comes from cities. Moreover, the existing cadastre is based on a 2D recording of the properties, with the result that it cannot properly depict all the proprietorial rights present in the actual surface, or of the buildings and the rights in rem.

There have been made a few attempts, by the authorities, to modernise this existing framework, such as the creation of the platform for the declaration of outdoor properties and those built without a permit,Footnote 6 or the digital issuing of building permits.Footnote 7 An example of that is the informative portal ‘digital city planning’Footnote 8 that enables the public sector, engineers, and interested private individuals to be informed on the building regulations and land rights for each building and the general geospatial data based on the current city planning rules that define the ownership status, construction status, exploitation status, and protection status of real estate property.

Problems present for years may have been improved on or even fixed, but new ones were created. The main reason for this is the multitude of different applications, each with a different organisation as its creator, without interoperability, creating an incongruous and deficient quantity of data.

Digital Building ID

In order to deal with problems in the real estate market, the Greek government developed and implemented the Digital Building ID (DBID).Footnote 9 This is a digital file for a building that includes all information, such as its construction licence, its energy efficiency rating, the floor plan, the table of ownership percentages, the certificate of building control, the certificate of inspection, and the declarations of submission for the suspension of rules for buildings without a permit. Though it existed as an idea since 2010, DBID began being tested in Greece in early 2021 and has been in full operation since 01.02.2021. Its operation is managed by the Technical Chamber of Greece (TEE-TCG).Footnote 10 The goal is to use this system to connect all the digital systems for real estate that have been operated by different services and sectors. The ministry for the environment and energy has characterised DBID as ‘an institution of the outmost importance for the public interest, the fight against construction without a permit, and the protection of property’.

The digital file for a building can be issued when all the necessary data are submitted. The authorised engineer can then issue the Property/Independent self-contained Property File, or the Certificate of Plenitude, which includes a summary of the details found in the property file as well as the certificate of the engineer on the presence of illegal construction and the actions undertaken to legalise it. This certificate can be issued for each property and is used during handover proceedings.Footnote 11 For apartment buildings, the Building ID consists of the totality of independent self-contained properties and communal spaces. This certificate is valid for two months after its issue. Both the certificate of plenitude and the property file have a unique identification code that prove their authenticity.

Methodology

GRextADE: a Greek Case Study

The goal of GRextADE is the gathering of a large range of data based on the CityGML model and the expansion of the basic data model so that it may successfully manage the data in Greece. The data comes from infrastructure relating to the real estate market but also from different agents that work in the field (i.e. real estate agents, accountants). The final goal of this extension is the creation of a national 3D modelling standard that would hold all the data relating to a building and provide information to a large number of interested parties (owners, professionals, services).

It is clear that GRextADE is a proposal that aims to set codification rules in a place with clear deficiencies and shortages. The main goals set during the development of this extension were as follows:

  • The developed proposal should be as complete as possible and have the possibility of being applied universally in the activities of both the cadastre and the market.

  • The digital DBID system should be at the forefront of the proposed solution.

  • The developed extension should have a simple, versatile, and scalable model.

  • The creation of the foundation of a database schema in order to store the 3D data regarding all buildings.

  • The ensuring of its compatibility with the upcoming CityGML 3.0.

At the centre of this extension is the data gathered by law in the DBID system. All the fields and qualities of GRextADE must be compatible with the DBID system. An ulterior goal is to extract specific data from the DBID platform and automatically insert it in a database (i.e. 3DCityDB) where the 3D model—following the CityGML specifications—of the city would be present.

The proposed extension focusses on the development and the enrichment of three main fields: (i) building identification (BDID-Building ID), (ii) commercial management (PROPERTY DETAILS), and (iii) the legal status of a building (PROPERTY FACTORS), and its development workflow is fully described in (Fig. 3).

Fig. 3
figure 3

Τhe basic structure of the GRextADE

Full size image

The development of this model was done with the use of UML diagrams using Enterprise Architect (EA). EA is a modelling and design software based on OMG UML.Footnote 12 It fully supports the development of data models compatible with GML (Van den Brink et al. 2013). The UML standards comply to ISO 19100.Footnote 13 The data model standards for GML and CityGML have been developed to work with the EA framework in order to facilitate the appropriate design of CityGML ADEs (Fig. 4).

Fig. 4
figure 4

Creation of UML diagrams with information from the Digital Building ID

Full size image

After that, the open-source tool ShapeChange was used,Footnote 14 in order to convert the UML diagram into an XML schema. ShapeChange is a Java-based tool that implements UML to GML encoding rules described in ISO 19136 (ISO-ISO 19136:2007-Geographic Information—Geography Markup Language (GML), 2007), ISO 19118 (ISO-ISO 19118:2011-Geographic Information—Encoding, 2011), and ISO 19109 (ISO-ISO 19109:2015-Geographic Information—Rules for Application Schema, 2015; OGC 2012). The XML schema (.XSD) is generated only for the ADE classes and attributes. In order for ShapeChange to read and analyse the UML diagram from EA (.EAP), a configuration file was generated on ShapeChange that was followed by the extraction of the XML schema.

In order to create a valid XML dataset for GRextADE, FME transform software was used. FME extracts the geospatial data in different forms and transforms it to the ADE dataset, following a clear definition of semantic chartography between the input and output data.

Visualisation of the results was achieved with the usage of three well-known 3D visualisers: FME Inspector by Safe Software, which is incorporated in FME; the open-source FZK; and Google Earth Pro.Footnote 15

Area of Interest

In order to illustrate the usability of GRextADE, the coastal part of the Elliniko neighbourhood, located close to the old airport grounds, was chosen. This area was constructed in early 1920, while the airport opened in 1938. This area comprises 292 buildings.

It is an area that will be at the forefront of the changes that will take place with the goal of redeveloping the area of the old airportFootnote 16 and represents the general gentrification efforts in many parts of Europe. According to a study by IOBE,Footnote 17 during the construction period, the redevelopment of Elliniko will bring in more than 14 billion euros to the Greek economy, and it will create about 70,000 jobs in a number of fields after its completion.

Development of the Extension

As a first step, the blueprints of the buildings of the area were inserted into ArcGIS, creating a shapefile with the data of the building areas (Fig. 5). Since there was no access to data and details regarding the properties of the area studied, pseudorandom number generators were used to produce the accompanying data files, which were to be submitted in the LOD1 model, which could be upgraded to LOD2.

Fig. 5
figure 5

The footprints of the Agios Kosmas buildings in ArcGIS software

Full size image

GRextADE UML

The CityGML section Building is expanded in GRextADE. FeatureType Building is the connecting point between the basic model and the GRextADE standard (Fig. 6). This extension was achieved by the development of three diagrams: (i) BDID, (ii) PROPERTY DETAILS, and (iii) PROPERTY FACTORS.

Fig. 6
figure 6

The GRextADE extension of CityGML

Full size image

BDID (Building ID) has been structured with pre-existing information found in the responsible public entities and in DBID which effectively combines all the data describing a building (Fig. 7). The plot of land and its characteristics are submitted («FeatureType» PFIR) along with a unique number (PFNumber), and the properties present in that plot are connected to it («FeatureType» BIR). A building has a plot as its reference point, and its respective unique number (PrNumb) includes the plot’s number as the second part of its name. Once the connection is achieved, the properties are characterised, and all data relating to them are added (area, usage, floor) along with the main legal documents that accompany each property (MainDocCopy) until the building’s completion (topography, building licence, architectural study, etc.). «FeatureType» ACT enables the addition of data relating to subsequent legal changes (such as the legalisation of illegal construction) and certificates (such as an energy efficiency rating certificate), with the dates they were issued in and the issuing authority (ministry, energy provider, etc.).

Fig. 7
figure 7

Extract from the BDID UML diagram (Building Digital ID)

Full size image

PROPERTY DETAILS

(Fig. 8) allows for the input of more information in the model, as well as the real estate’s commercial value through «FeatureType» PropertyDetails. It gives the capability of adding more data and characteristics regarding the use, condition, and value (both commercial and tax), and even the yearly surcharge for the owner.

Fig. 8
figure 8

Extract from the PROPERTY DETAILS UML diagram

Full size image

PROPERTY FACTORS

(Fig. 9) supports the input of data regarding those liable for the building (such as the owner or whoever is taxed for it), or the listing of all those related to its building (topographer, engineer, architect) through «FeatureType» PropertyLiable. The engineer tasked with overseeing the data submission in the digital system is listed separately in «FeatureType» PropertyEngineer.

Fig. 9
figure 9

Extract from the PROPERTY FACTORS UML diagram

Full size image

One of the most important goals during the development of GRextADE was the possibility of adding to it and enriching it in the future without affecting its structure and functionality. As such, no changes were made in the existing CityGML standards, nor in the Building class, which is at the core of this extension. Since there was no universal modelling framework in Greece, it was of paramount importance to provide a flexible and simple extension that would allow for further corrections and updates.

The CityGML philosophy was followed, namely, the usage of a simple core with the possibility of expanding it for specific purposes and a minimal number of common functions. This avoids the development of a large and complex data model with a high number of classes.

Converting GRextADE to an XML Schema

Extracting an XML schema from a UML diagram was done using ShapeChange. The configuration file made the reading and analysis of the UML diagram possible (Fig. 10). The schema definition file CityGML-GRextADE.xsd (Fig. 11) was then extracted.

Fig. 10
figure 10

Extract from the CofigurationFile of the ShapeChange application for the GRextADE extension

Full size image
Fig. 11
figure 11

Extract from the conversion of the «FeatureType» BIR into the XML schema file (CityGML-GRextADE.xsd)

Full size image

Creating the GML File

For the creating of the final file that incorporated the developed ADE in CityGML format, the conversion software FME was used. After ‘reading’ the ADE, FME found the connections to the basic standard and allowed the extraction of geospatial data with the necessary datasets before connecting them to their corresponding characteristics of the extension (Fig. 12). Lastly, FME allows the transfer of the interpreted data to the ADE datasets following a clear definition of the semantic cartography between the entry and exit data.

Fig. 12
figure 12

Extract of the schematisation of the interfaces via FME software and the transmission of the interpreted data to the corresponding ADE datasets

Full size image

GRextADE Visualisation

In order to visualise the data found in the model, three different software were as follows: FME Inspector, incorporated into FME, FZK, and Google Earth Pro.

FME Inspector demands the usage of an XML schema (.XSD) in order to see the relationships with the basic CityGML standards (Fig. 13). It offers the possibility of adding a series of parameters in order to present the desired information and then provides the possibility of extraction of the visualised result in a number of file types. Moreover, it can visualise different levels of details and different ADEs.

Fig. 13
figure 13

Visualization of 3D buildings of the Elliniko area, at LOD1 level of detail and projection of GRextADE information via FME Inspector software

Full size image

In order to support any ADE, FZK necessitates the addition of an XML schema (.XSD) into its catalogue together with the other schemata that are provided by the software itself. It lacks the option of adding parameters of FME Inspector but provides a complete visualisation environment for all the information of GRextADE (Fig. 14). It allows the extraction of the visualised 3D model in IFC, KML, Collada, STL, and gbXML file types.

Fig. 14
figure 14

Visualization of 3D buildings of the Elliniko area, at LOD1 level of detail and projection of GRextADE information via FZK software

Full size image

The 3D model can be seen via Google Earth Pro as well (Fig. 15). The visualisation of the information supported by GRextADE is presented sufficiently, and the information can also be organised by layers to make it more accessible in a web environment.

Fig. 15
figure 15

Viewing via Google Earth Pro information embedded in the 3D models with the GRextADE extension

Full size image

It is clear that FME Inspector and FZK can visualise more complex information both wholly (for a whole city) and in greater detail (a given building). Google Earth Pro is more user-friendly and easy to navigate and gives simple users the possibility to access GRextADE.

Discussion and Conclusions

GRextADE achieves the main objectives that have been set, and the proposed solution can be adapted to any need to extend CityGML by changing the UML diagram and the fields exists within.

In the case of Greece, the peculiarity that prevails is the absence of infrastructure for the 3D modelling of cities. As it has been described, the recording of real estate property via the Greek Cadastre has not been completed making our task more challenging. Recognising the importance of DBID and the expectations it has created, it was decided not to ignore it during the development of GRextADE and instead create the foundations for a collaboration between the new platform and the CityGML extension in development. At the same time, it is a universal proposal to tackle the absence of a national 3D standard.

In order to illustrate the functionality of the extension and due to lack of a robust dataset, a typical urban area in Athens was chosen, in which GRextADE was applied, with data concerning that area being randomly generated, or manually collected when possible.

The case study illustrated has been encouraging and conforms to the initial goals. They are the foundation on which the Greek state could obtain a national standard. It has been proven that disparate data in different forms, from a plethora of sources and files, can be gathered, organised sufficiently, and integrated into 3D building models. The visualisation of the 3D models takes place without any issues and using software developed for other reasons (Fig. 16). The data on objects is gathered and expanded on by the already existing infrastructure of the digital systems. It has also been seen that tables and their connections can be automatically created in the 3DcityDB database of the GRextADE extension following the CityGML standards (Fig. 17).

Fig. 16
figure 16

The development workflow of the GRextADE extension

Full size image
Fig.17
figure 17

The extension of the GRextADE-based CityGML tables to the 3DCityDB database using the Importer/Exporter tool

Full size image

Table 1 displays the total assessment of the GRextADE extension via testing with various amounts of data. GRextADE ensures coherence and integrity of data without any loss, regardless of the bulk of data (information display), but the resulting file (file size) becomes large (more than 10.000 3D buildings) when it comes to the extensive 3D modelling. Manipulating the final file (select items, move and rotate the 3D model) through visualization applications (3D Model Management) proves challenging. When the number of buildings exceeds 50,000, the projection screen freezes after any attempted action in the 3D model (3: bulky in the 3D Model Management). Up to 10,000 buildings there is no handling problem (1: excellent), and up to 50,000 the model is highly functional (2: acceptable). The total duration of the modelling process (Session Duration) increases in proportion to the number of buildings, as does the data reading time (User) and the operating time of the processor (CPU). A similar effect is observed in the computer memory (Peek Process Memory Usage).

Table 1 Total assessment of the GRextADE
Full size table

GRextADE classes are designed as subclasses of AbstractBuilding, which exists in all LODs (LOD1-LOD4), so the functionality of the extension is not affected regardless of the level of detail chosen. The challenges that stem from the increase of LOD based on the current capabilities of the software are as follows: (a) the adaptation of the creation mechanism in the FME in order to ensure the integration of all the information, (b) the visualization of information by the available software, (c) data integrity, and (d) manageability of the final file. Therefore, the limitations of the chosen LOD are mostly related to the hardware requirements and the visualization capabilities of the software. GRextADE with the existing design can be fully operational with the adoption and implementation of DBID in the Greek real estate market. Structural changes to the UML of the extension would only be required if the DBID structure was changed by the competent authorities.

As for the future work that needs to be undertaken for this ADE, GRextADE has to be adapted to CityGML 3.0.Footnote 18 The upcoming version will present a number of new possibilities and revisions (Fig. 18) that will increase its usability (Kutzner et al., 2020b). As seen above, GRextADE has been designed so that its application to the new version will be easy. The UML diagram, configuration file for ShapeChange, and XML schema (.XSD) have all been prepared with the specifications of CityGML 3.0 (Kutzner et al., 2020b). The main reason this extension was not presented directly in CityGML 3.0 is that the visualisation software is not yet compatible with the new version of CityGML 3.

Fig. 18
figure 18

CityGML 3.0 module overview. The vertical boxes show the different thematic modules. Horizontal modules specify concepts that are applicable to all thematic modules (Kutzner et al., 2020a)

Full size image

Further research should be undertaken on the provision and accessibility of data by the government. Suitable conditions for the disposal and evaluation of data are necessary in order to make the 3D city models of Greece viable. The research undertaken has concluded that the viability of an ADE is interwoven with acceptance by the state entities, and its adoption by those entities gives it credibility and acceptance.