The growing complexity of many projects and applications require methods that help integrate vasts amounts of data coming from different sources. In all cases, semantic interoperability plays an important role - the meaning of content should be organized logically, as to allow machines to interpret it. The Semantic Web vision has been developing standards to support this idea, with the goal of creating a 'web of data', were pieces information can be accessed and linked to one another consistently. The ideas behind Linked Data have been explored in different areas of study. The geospatial domain presents an interesting challenge, as geospatial data offers many different views on the same physical universe. This is especially the case with geo-registries - collections of official geospatial data used by governments. This data already contains links in the form of spatial relations. However, there is no consensus on how these links should take form. Thus, this research will explore how linkable geospatial data from registries actually is by answering the following question:"To what extent can ontology-based solutions using semantic web technologies contribute to the integration and use of data from geo-spatial registries?". This question is broken down in three sub-questions that address ontology-based integration techniques (including tools and languages), the impact of dataset characteristics and the added value of semantic relations. The research includes a literature study to provide a theoretical background, a case study of two Dutch geo-registries (Basisregistratie Grootschalige Topografie and Basisregistrie Topografie) and a conceptual framework that is applied to the case study as a way to explore the main question. The results of this framework reinforce the importance of using instance-level data to understand the connections between different conceptual models and show the unavoidable subjectivity that is involved in the process - from the conceptualization of the data (model) to the creation of query rules. The findings indicate that the capabilities of ontology languages (such as OWL) are not necessarily practical for data from registries, and that custom processes might be necessary depending on the application envisioned by data users. Country-wide registries managed by different data owners and different interpretations of data acquisition rules will lead to inevitable variations in the registration of objects in datasets. And more efforts could be invested in providing quality indicators for alignments.

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.