CityJSON in combination with MongoDB, PostgreSQL and GraphQL

Abstract

CityJSON is a JSON-based encoding for a subset of the CityGML data model and an alternative to the CityGML exchange-format. This new encoding reduces the data size and simplifies the usage. These files can be stored in relational and NoSQL databases. Relational and NoSQL databases have integrated JSON. CityJSON has therefore the potential to be stored and perform efficiently in relational and NoSQL databases. The databases are tested as part of a client-server architecture, because JSON is used in web applications and the 3D city models can not entirely be stored on mobile devices. GraphQL is used as the API layer between the database and the client, because it has the ability to optimise the usage of the network. This is necessary for location-based web applications on mobile devices to stay functional. This research attempts based on this use case to answer the following question: How suitable are MongoDB and PostgreSQL for the storage and querying of CityJSON using GraphQL? CityJSON has first been mapped to the relational database PostgreSQL and the NoSQL database MongoDB. CityGML has also been mapped to PostgreSQL with 3DCityDB to clarify the impact of different exchange formats. The databases are after that accessed and queried through GraphQL. The queries are based on the selection process of an AR application. The architecture is tested based on the number of queries between the databases and GraphQL, the request sizes, the response sizes and the retrieval times. The results show that the usage of JSON maps attributes more flexibly than the mapping of 3DCityDB, which can result in less tables and therefore less joins or queries. On the other hand, querying on a JSON attribute might result in higher retrieval times than querying an attribute with a predefined data type, but this is not investigated. Additionally, the usage of JSON makes it possible to store fields with varying data types such as the hierarchy of arrays. A difficulty can be that software such as GraphQL does not support fields with varying data types and is therefore less flexible. The developer has to work around that. In general, there are no real signs yet that MongoDB and PostgreSQL are not suitable for the storage and querying of CityJSON using GraphQL. Possible signs are that the indexing mechanism with the vertices list can not be stored in MongoDB and only to some extent in PostgresQL, but this might not be a problem since the indexes can be resolved to integer or real coordinates. The attribute presentLoDs can not be stored in MongoDB as well, but this might be solved with a small adjustment. The main recommendations of this research are that the SQL/MQL queries should be implemented as efficiently as possible without being connected to GraphQL first. This should be done to understand the performance of the databases and to understand the impact of GraphQL better. Besides this, a more general understanding of the suitability for all use cases could be provided with a framework that tests more types of queries.