Introduction

The development of spatial data infrastructures (SDIs) (Valencia and Muñoz-Nieto 2018) has supposed a revolution in managing, using and broadcasting geographical information (GI). Its standards, such as CityGML (Gröger et al. 2012), have allowed the development of interoperable and scalable 3D urban models. It is thus desirable that these models be accessible through the internet, although some issues affecting potential users can arise.

An important issue is encountered during visualization of models on the internet. The SDI visualization services (WMS or WFS) that can display 2D information work well with light and heavy clients, but the visualization of 3D urban models in CityGML is more complex. This is because the standard is designed for 3D model representation, not its direct visualization (Di Staso et al. 2015). The visualization of CityGML files is difficult due to their size, memory limitations or the lack of supporting features installed in specialized viewers (Arroyo Ohori et al. 2018). Another issue is the storage of the information, which may be in a database or in appropriate models. The former option is more flexible since it permits information to be modified without having to make changes in the urban model.

The language used in CityGML models is based on XML. These files present cross-domain problems for security reasons (Sierra 2013). This makes it difficult to download and use documents from a web source other than the one that hosts the application. To address this problem, it is necessary to use a different format that does not have such a problem.

The 3DTiles format was rejected, as it addresses storage problems but not cross-domain problems. GeoJSON (based on JSON) was the format chosen. This is a geospatial data exchange format based on JavaScript (Carter 2018), which is the language implemented by web browsers. This is why it does not present a cross-domain problem. GeoJSON also generates lighter files because it is not a markup language like XML.

The new version 3.0 of CityGML will include new encoding specifications for other formats in the next future, such as GeoJSON (Kutzner and Kolbe 2018) (Kutzner et al. 2020). The OGC is finalizing the process to include JSON among its encoding extensions (OGC JSON 2019).

In this paper, the design and implementation of a web3D application that allows access to 3D CityGML models—specifically, a 3D urban model of the historic centre of Lorca (Spain) is presented (Álvarez et al. 2018)—. At the same time, the refinement and correction of the system, in order to solve the cross-domain problems encountered in using it, are also explained. The system was improved by implementing a CityGML-to-GeoJSON conversion tool and by modifying part of the system implementation. The aim was to find a solution that combined the ideas of other applications of the employed tools by storing CityGML data and viewing them on the internet, thereby taking a new path through the current types of existing software solutions.

The achievement of the main goal required the fulfilment of the following specific aims: (1) The concept of an urban model and information related to it is adequately presented and explained. (2) Users can access the 3D model, permitting interoperability. (3) The Web3D server is designed and implemented. (4) The 3D viewer is developed. (5) Options complementary to the viewer are included, such as the representation of data layers from different WMS servers.

This paper is divided into the following sections: the “State-of-the-art” section presents the state-of-art technology in related fields; the “Materials and methods” section describes the materials and methods used; the “Development of the system implementation” section outlines the system implementation; and in the “Results” section, the results are ultimately described. Last, a discussion and conclusion are given.

State-of-the-art

At the end of the twentieth century, different organizations greatly developed the field of 3D information. ISO 19115 (ISO 19115 2020) was conceived, and with the Web3D Consortium (Web3D Consortium 2020), founded in 1997, several standards for the publication of 3D graphics on the internet, such as X3D (Extensible3D) (X3D 2020), were developed. The X3D standard arrived after VRML (VRML 2020); it is open, extensible and multi-platform interoperable, and it is relevant to publishing geospatial information on the internet. After that time, work on visualization solutions followed that standard (Yali and Huijie 2018).

At the beginning of the twenty-first century, the 3D Information Management Working Group of the Open Geospatial Consortium (OGC) (OGC 2020) was created, and it included CAD and GIS software providers, administrative agencies and European governments. From its beginnings, this group has worked on developing the necessary standards for forming a 3D SDI (Basanow et al. 2008) and on investigating the interoperability of 3D geospatial information.

In this context, in 2008, the term 3D SDI originated (Peláez 2018). CityGML became an OGC standard, providing a model for describing 3D objects in terms of their geometry, topology, semantics and appearance. That same year, OGC began the creation of a service called W3DS (W3DS 2019) for the distribution of CityGML 3D data, which was possible due to advances in language development, geospatial databases and distribution and visualization services for 3D data. At the same time, the format of Google Earth, KML (KML 2020) became an OGC standard due to the many users and large amount of development related to it.

Spatial databases

Regarding databases, it is worth mentioning, first, that Oracle introduced the 3D Spatial Engine in version 11 g (Oracle Spatial 2020) in 2009. Since then, it has been improved and further developed so that it can store and manage three-dimensional geometric information. In that same year, the database manager PostGree, developed by the OSGeo Foundation, added the PostGIS v2.0 extension (PostGree 2020) to support 3D element storage.

3D City DB then appeared (3DCityDB 2020); it was created by the Geoinformatics Department of TU München. It consists of an open geographic database that allows the storage, representation and management of virtual 3D city models in a standard relational spatial database. It employs the CityGML standard and includes tools to convert CityGML data to KML, COLLADA (COLLADA, wiki 2020) and gTIFF (gTIFF 2020) formats for visualization in Google Earth, ArcGIS and Cesium (Yao et al. 2018).

Data formats

Concerning services for 3D model broadcasting, some formats, such as CityGML, face some problems, such as cross-domain problems. Today, more efficient data formats exist, such as JSON and GeoJSON, for addressing these issues, permitting a document to be downloaded from a web service other than that of the host of the web application used, as previously mentioned.

GeoJSON (GeoJSON 2020) is a format for geospatial data transfer based on JavaScript (JSON). Its usage has been recently extended to cartography applications in web environments, since it permits the transfer of data in a fast, light and simple way (Sierra 2013). It also has the advantages of being simpler to read and code, generating lighter files and being a web- and mobile-friendly format (VRML 2020; OGC 2020). Its most important feature is that it avoids cross-domain problems.

Viewers

Regarding web map viewers, the first developments were made in the 1990s. In 1993, the Xerox Parq Map Viewer was born, and in 1998, TerraServer (TerraServer 2020) was created based on servers of the Windows NT Server type and their related databases of the SQL Server type. The latter model disseminated aerial images along with the first digital graphical raster, thus becoming one of the world’s most popular WMS services at the time.

In the first decade of the 2000s, GeoServer was developed (GeoServer 2020), consisting of an open-code map server in the Java language, and it would achieve interoperability. It was able to read, interpret and publish data and standard services defined by OGC. In a parallel way, GeoTools (GeoTools 2020) was created; it is a free software written in Java that provides a library of utilities and implementations of the standard services proposed by OGC.

In 2005, Google created Google Maps and Google Earth as geospatial information-heavy clients. That same year OpenLayers (OpenLayers 2020) was defined, consisting of a library in Javascript dedicated to the implementation of light clients. In 2012, CartoDB (Carto 2020), later Carto, was founded. It was the first company to transfer GIS processes to the cloud using their own servers to transform data into images. Similarly, MapBox (MapBox 2020) created a new standard for sending geographical information through the net in a quicker and more efficient way.

Concerning 3D web visualization, from 2008 onwards, several viewers and free CityGML tools were developed, such as FZK Viewer (FZK Viewer, KIT 2020), LandXplorer CityGML (LandXplorer, Autodesk 2020), Aristoteles (Aristoteles, koblenz-landau University 2020), 3DGIS cityvu (Cityvu, 3DGIS 2020), libcitygml C++ library and citygml2vrml converter (citygml2vrml converter 2020) and GML Viewer (3DGIS 2020).

In recent years, an increasing amount of research on the net publication of IG 3D information has been performed (Costantino et al. 2019; Büyükdemircioğlu and Kocaman 2018; Blut et al. 2017; Prieto et al. 2016).

Materials and methods

In this work, the development of an operative visor that shows urban 3D models stored on a database, built on a web browser with free access, is described. This system follows the client/server model and permits the optimal management of all the parts employed in the CityGML urban model publication process.

A complete system has been conceived (Fig. 1), which incorporates a CityGML-to-KML conversion tool, a web server and a web client so the geometric and semantic information of the 3D model can be viewed.

Fig. 1
figure 1

Architecture of the system

Full size image

Then, considering the problems identified during its first test, the system was improved (Fig. 2) so that a solution to the cross-domain problem could be installed. A tool for exporting files to GeoJSON was developed, and thus, some modifications to the system implementation needed to be made.

Fig. 2
figure 2

Architecture of the improved system

Full size image

Materials

During the system development, the software and data described below were employed.

Input data

The input data are certain CityGML files generated in the framework of a 3D urban model of an area of Lorca’s city centre based on LiDAR and cadastral data (Spanish Cadastre) (DG Catastro 2020).

Software

The OGC software and open-source software solutions were used: 3DCityDB and MongoDB. 3DCityDB is an open database designed for the storage, representation and management of 3D CityGML urban models. It is based upon PostGIS, the spatial extension of PostGreSQL. It permits conversion between formats and the separation of the geometric and semantic information of the model.

MongoDB (MongoDB 2020) is a NoSQL database system that does not use tables and rows but an architecture of collections and documents that emulate their behaviour. It is the free software that performs queries in JavaScript. The queries are sent and carried out directly on the database. The user has a key to protect the database from unknown accesses. This system is easy to replicate and permits automatic configuration.

The JavaScript programming language was used, as well as the following tools (Farkas 2017): NodeJS (Node 2020) for the service layer and JQuery (JQuery 2020) for client petitions. The JavaScript library permits simplifying interactions with the HTML documents, manipulating the DOM tree, managing events, developing animations and adding interaction with websites by means of AJAX.

Other libraries from npn used are: CesiumJS (Cesium 2020) and Spreadsheet (Spreadscheets 2020). CesiumJS (Cesium 2020) was employed for the development of the viewer. It is an open-source JavaScript library for 3D maps and globes in a web browser without add-ons. It includes other libraries: Leaflet JS (Leaflet 2020) that permits implementing and managing 2D maps and Tree JS (Tree JS 2020) employed in the 3D modelling of various objects. Spreadsheet (Spreadscheets 2020) is a free Google cloud service that permits uploading data (such as tables) to the net.

To convert KML files to GeoJSON was used Kml2Geojson (Kml2Geojson, Python 2020) was used. It is a Python (Python 2020) library that respects every KML and GeoJSON property.

Methods

First, a system design based on the particular features of the 3D CityGML models was developed, and then, it was implemented.

System design

The developed system was based on a certain kind of integrated system employed for image storage in the net, which consists of storing the net image path in the database instead of the image data itself. Thus, a three-level system was designed: Data, Server and Client.

Data

The model data are stored in an external database employed for storing, validating and transforming the CityGML data to other formats compatible with the viewer. After editing the information of the 3D model, the geometric information is exported to a NoSQL database connected at the service level. The semantic data are stored separately so they can be deployed in the viewer.

Server

It ensures access to the 3D information of the models stored in the NoSQL database and their transfer to the viewer. The files should be uploaded to the net by generating logical links through which they can be accessed.

Client

The graphical interface permits access to the model visualization and the semantic information as well as query realization.

The system structure is shown in Fig. 3.

Fig. 3
figure 3

System design

Full size image

The software requirement specification employed here is based on the IEEE 830 (IEEE standard 830 2020) and IEEE 29148 (IEEE standard 29148 2020) standards.

The system functions are spatial data management and navigation. The spatial data management includes data storage, data verification, data deletion and structured data representation. The navigation functions are graphical interfaces, navigation controls and data layer visualization management.

System implementation

The implementation of the system was performed in three phases: (1) data processing, (2) web service creation and (3) web3D creation.

Development of the system implementation

First, the starting data are loaded, which are the previously generated CityGML models of Lorca. Following this, the aforementioned steps are performed.

Data processing

Data processing was performed in four successive steps, described below.

Data import and transformation

To transform the data, the 3DCityDB database was used, which permits CityGML files to be transformed to other formats that are more adequate for web environments, such as KML, COLLADA or gITF (Kilsedar et al. 2019). Since it is based on PostGIS, PostGreSQL’s geographical extension, it needs the previous installation of both tools.

The first step was to create an empty database where the imported CityGML model data were stored and their code’s validity was checked (Fig. 4). The dialogue box shown in Fig. 5 helps to check the validity of the data import and the database modification process. Then, the 3DCityDB importer/exporter tool was used to transform the model’s geometric information to KML.

Fig. 4
figure 4

Example form for CityGML-to-3DCityDB import

Full size image
Fig. 5
figure 5

Dialogue box for database checking

Full size image

Data export

The files resulting from the transformation are exported to the MongoDB database, which is a tool connected to the server that provides 3D information.

Access to semantic information tables

3DCityDB allows the semantic information table of the model data to be accessed (Fig. 6). The information table is exported to a Google spreadsheet so that the information can be directed to Web3D from the cloud. The export is bidirectional, since it is possible to create new SQL tables from the spreadsheet. Therefore, the input data are the logical links to the model and their associated thematic data table.

Fig. 6
figure 6

Thematic data table configuration

Full size image

The table configuration can be saved as a .txt file for future use. The result is an excel file, as shown in Fig. 7. It is worth mentioning that the results vary depending on the choice of data and the kind of thematic data table.

Fig. 7
figure 7

Content of a thematic data table in excel format

Full size image

After this process is complete, the KML files are obtained. Immediately, a double-check of the data transformation process is performed. First, the CityGML data are viewed in Google Earth (Fig. 8), and then, FZKviewer is used to perform the second check (Fig. 9). It is verified that neither errors nor information loss have occurred.

Fig. 8
figure 8

KML files from the Lorca model as seen in Google Earth

Full size image
Fig. 9
figure 9

CityGML files of the Lorca model as seen in FZKviewer

Full size image

Importing data to MongoDB

The last step of data processing is importing the managed data to the MongoDB database, a non-relational database system that permits the fast search of a huge dataset. Therefore, an API Key associated with the user is established so that access to the server data query can be controlled. The system also permits the storage of information related to the IDs associated with the API Key account in addition to information about the location and accessing browser of the last connected device.

Web service creation

The implemented service has to be able to store the locations of the models in its database depending on the employed library. Node.js was chosen for building servers in the design of this system.

After the installation of Node.js, the following tools were used: (1) Express JS (Express JS 2020), (2) Mongoose (Mongoose 2020), because MongoDB is used, (3) The BodyParser libraries (BodyParser, npm 2020), which permit middleware to be built for configuring the format of message bodies, (4) BlueBird (BlueBird 2020), so programming can be simplified and, (5) W3C and the CORS specification (CORS, W3C 2020), which permit inter-domain communication from a web browser.

Web3D creation

CesiumJS was used to develop the presentation layer of the viewer. It is a library containing numerous widgets that can be used in designing the appearance of the site where the viewer is implemented. It also permits behaviours to be configured by means of the prototype attributes (Fig. 10).

Fig. 10
figure 10

Some of the options in Cesium

Full size image

From the client, the database can be accessed with MongoDB Compass. To connect the two, some necessary JavaScript methods were developed to fulfil the base connecting functions with HTML by means of the user-associated API Key.

Results

The home page of Web3D is shown in Fig. 11. It includes a menu where the model to be loaded in the application can be selected. The user can visualize the model and perform other operations using the formula panel for queries and data insertion from the possible 3D models.

Fig. 11
figure 11

Viewer home page

Full size image

Access to the 3D models from the presentation page is obtained by using the query menu, which adds them as layers (Fig. 12). The access routes to the KML files and the corresponding thematic table need to be provided. Additionally, the viewer implements calls to WMS services.

Fig. 12
figure 12

Formula menu

Full size image

Figure 13 shows two layers of the model simultaneously.

Fig. 13
figure 13

Viewer with both layers active simultaneously

Full size image

Although the visualization of the models was correct, some problems were detected. Although the KML format is adequate for publishing 3D models in the net because it is native to Google Earth, the results are very heavy for data exchange. Also, the transformation to KML forces the division of geometric and semantic information. As previously mentioned, the sole usage of the visor presents cross-domain problems. In this context, it acts as a protection mechanism that prevents the downloading of data from a server other than the one hosting the web application used (Sierra 2013).

Considering these problems, it was decided that the files containing 3D models would be exported to another geographic data format. GeoJSON, which is derived from the concepts of other existing spatial standards, was chosen. It simplifies coding in adapting to web environments.

GeoJSON has the following advantages: (1) it generates files of smaller size and less complexity, (2) it is a format for spatial data that reunites spatial and semantic information, (3) it is a more adequate format for the features of web environments, and (4) it is designed in JavaScript. This language is used to implement most of the existing servers and web viewers, so it avoids cross-domain problems.

To solve the aforementioned problems in the integrated system, some modifications were made to its implementation. Specifically, the data processing, web server deployment and Web3D stages were improved.

Data processing

A three-stage process was performed: KML to GeoJSON transformation, file subdivision or splitting and extension modification.

KML to GeoJSON transformation

All the KML files stored in the 3DCityDB were transformed to GeoJSON format by means of Kml2Geojson, a Python library that respects the properties of both formats. The process is automated by applying a batch script that permits the processing of all files with a .kml extension so that they can be transformed to GeoJSON. Only a single script execution is needed.

File splitting

Before importing the files, now in GeoJSON format, they needed to be subdivided into files with a maximum size of 25 KB so the characteristics and restrictions of MongoDB could be met. This process was performed with the Geojsplit tool (Geojsplit 2020), and another script was developed for automating this process.

Extension changes

Last, given that the database accepts files with a .json extension, the names of the split files were modified to end with that extension. The .geojson-to-.json extension replacement was automated in the same manner as the two previous steps, with a script that creates JSON files. The resulting files contain the CityGML model data transformed into JSON format (Fig. 14).

Fig. 14
figure 14

Resulting data from the model data processing

Full size image

Figures 15 and 16 show how some buildings can be seen only partially, with an incomplete volume, due to the file subdivision. This problem is solved when all the files are stored in the database, and thus, the complete model can be represented.

Fig. 15
figure 15

Part of a building

Full size image
Fig. 16
figure 16

Complementary part of the building

Full size image

Next, the divided archives are imported to MongoDB along with a test to verify their correct visualization in the viewer.

Web service improvements

The MongoDB database was stored in the cloud net by Amazon Web Services (AWS) (Amazon Web Service 2020). AWS receives client petitions; therefore, there is no need for the system to store the files locally. The database stores data in GeoJSON format and permits files to be modified and new data to be imported in addition to receiving server petitions (Fig. 17).

Fig. 17
figure 17

Improved system design

Full size image

Web3D improvements

To work with the database in Web3D and easily access the data starting from the home page, the following improvements were added: (1) the access function login() connects to MongoDB with the help of a user’s API key. (2) The file importing function InsertCollection() permits loading a file from the server’s “data_geo” directory and importing it to the database. (3) The data-loading function getcollection() loads the first found element of the database into Web3D.

Additionally, some function access buttons were added in the main window of the viewer for managing the connection to the database. Import button permits loading a file stored in the server. InsertBD function grants access to a selected GeoJSON file so it can be imported into the database. LoadBD function relates to the aforementioned getcollection() function.

Once these modifications are introduced, the home page of Web3D is as displayed in Fig. 18. As can be observed, the viewer has the navigation functionalities of the initial version in addition to the new data accessing functions.

Fig. 18
figure 18

Home page of Web3D

Full size image

Figure 19 shows the interface of Web3 loaded with Lorca’s 3D City Model superimposed on an aerial photograph taken by PNOA (PNOA, IGN 2019), accessed through a connection with the implemented WMS service.

Fig. 19
figure 19

Files of the Lorca urban model transformed to GeoJSON in the developed Web3D

Full size image

Discussion

The designed Web3D system follows a client/server architecture and consists of three levels. The division into three levels is a common structure in the design of 3D web viewers and web-GIS based on geospatial data.

At the first level, the data level, the CityGML Model is stored in a database that allows spatial information to be stored. We used MongoDB, a non-relational database. Non-relational databases can better handle the large volumes of data in Urban 3D Models. (Laksono 2018). The use of these NoSQL databases is increasing compared with the usual PostGIS or 3DCityDB (Laksono 2018) used in many developed geospatial applications (Aleksandrov et al. 2019; Prandi et al. 2015).

In the first design of our system, CityGML files are transformed into KML format, so the geometric and spatial information have to be stored separately.

The splitting of the information at this level has been seen in other Web3D studied (Tang et al. 2019, Prandi et al. 2015, Zhu and Qiao 2013, Rodrigues et al. 2013) (Fig. 20). The Web3D GIS system in the research consulted is primarily used for simulation models, thematic mapping, monitoring and basic spatial analysis. Many of the systems studied (Zhu and Qiao 2013) read CityGML data through a WFS and convert it to X3D for viewing on the internet, and they also provide tools to display and analyse geospatial information in a 3D environment (Fig. 21).

Fig. 20
figure 20

Web3D GIS framework (Rodrigues et al. 2013)

Full size image
Fig. 21
figure 21

Architecture of Web3D GIS (Zhu and Qiao 2013)

Full size image

In the final design of our Web3D viewer, the CityGML files are transformed into GeoJSON format. GeoJSON supports the integration of geometric and semantic information. The data can be integrated into the JSON-based database (MongoDB) (Baralis et al. 2017). Other common databases, such as 3DCityDB, export geometric information to KLM/COLLADA (Prandi et al. 2015), and the semantic information has to be stored in other formats (Zhu and Qiao 2013).

The objectives of the implemented system are to visualize CityGML models optimally and to be able to access information from other agency servers related to city management and maintenance without cross-domain problems. To achieve these objectives, a single server was developed (Fig. 2) that allows all the files to be published—raster, vector and DEM—in an integrated way. The publication of the models would not be optimal using the architecture proposed by Web3D GIS through a WMS for raster data and a server developed with Tomcat (e.g.) or a WFS for vector data (Rodrigues et al. 2013) (Fig. 21).

The user interaction with the model is improved by solving the cross-domain problems of other formats, such as CityGML and KML (Prandi et al. 2015). The application is innovative because it facilitates interoperability with the CityGML model by eliminating the problem of the domain (Sun et al. 2019), which allows access to information from other geospatial data servers.

CesiumJS was used for the Web3D viewer. Today, it is the best option (3D globe map) for 3D geospatial information visualization (Aleksandrov et al. 2019, Prandi et al. 2015). As GeoJSON is compatible with JavaScript (Ledoux et al. 2019), which is the language used by Cesium, the use of this format improves the visualization of the model.

Conclusions

This paper shows the development of an integrated system for publishing 3D urban models of the town of Lorca, allowing them to be visualized via a web browser through accessible data stored in a functioning database. This development, although it does not present any difficulty on a conceptual level, is somewhat complicated to implement in practical terms during some of the necessary processes described, since the system required some modifications during its implementation.

The disadvantages faced in publishing CityGML models on the net required transforming the data used to KML and then to GeoJSON as the final format. The latter is more adequate for web environments and permits faster model data transfer than the CityGML format. In addition, the transformation to JSON allows model data to be downloaded without presenting cross-domain problems.

To store the exported files in KML and GeoJSON, a non-relational database, in this case MongoDB, was used. It admits files from different formats, and it is adequate for very large quantities of data, which is common in 3D City Models.

A web application able to store and visualize data models in GeoJSON was deployed on an Amazon Web Services database. Thus, scalability was taken into account through the infrastructure of cloud services. This allows access to the data from different clients in a safe, secure and concurrent manner, and it allows a register of all queries made in the database to be created. Issues such as security and data access are thereby addressed. This development of diverse implementations did not incur problems and was performed simply, so the adequacy of the chosen software is evident.

The designed Web3D viewer improves the interoperability of the CityGML model by solving cross-domain problems. The developed system allows access to information from other geospatial data servers. In addition, the GeoJSON format allows geospatial information to be stored in an integrated way, which is suitable for geospatial information-based web applications.

In future work, an improvement of the design of Web3D is proposed that augments the precise interface to allow the addition and modification of information, taking into account the newly implemented functions for data management.

As a final conclusion, given the described circumstances, the development of tools allowing access to 3D models is necessary even today. These tools have to enable advanced analytical and processing capabilities in a light, intuitive and easily interactable navigation environment. The proposed work aims to address this need.