8.1.1.  Requirements addressed

In order to define which capabilities GeoSPARQL needs to adopt for full 3D compatibility, we first take a look at GeoSPARQL 1.1 current capabilities with regards to 3D.

8.1.1.3.  Core Module

GeoSPARQL version 1.1 includes a CORE module. This defines the basic classes, relationships, and literals. These classes are suitable for both 2D and 3D.

8.1.1.3.1.  Topology Vocabulary Extension

This extension provides standard definitions for spatial relationships that can exist between one spatial object and another.

Relations between geometries have been defined using three different sets of rules:

• Simple Features Relations

• Egenhofer Relations

• Region Connection Calculus RCC8

These topological definitions specify topological relations in a 2D-context.

8.1.1.3.2.  Geometry Extension

GeoSPARQL 1.1 geometry module defines a class Geometry as a subclass of SpatialObject.

An instance of Geometry is not restricted to two dimensions.

A fine-grained classification of Geometry can use the Simple Feature Vocabulary which extends the class Geometry with further types, such as Point, Polygon etc.

The Simple Features vocabulary allows for the definition of 3D variants of:

• (Multi)Points

• (Multi)LineStrings

• (Multi)Polygons

• Polyhedralsurface

It does not include commons 3D primitives, such as Cube or Mesh surfaces which are integral parts of 3D representations. Nor does it include extruded geometry.

Figure 1 — Possible approaches for representing 3D objects in IFC

Concerning metadata of 3D models, GeoSPARQL 1.1 provides properties which can be reused in 3D contexts. In particular, the properties are:

• geo:hasVolume

• geo:hasMetricVolume

Further 3D-related metadata properties such as projection matrices are not part of the current GeoSPARQL 1.1 standard.

A first requirement for 3D support is the ability to save 3D data in a knowledge graph.

The Geometry extension enables geometries to be defined within the GeoSPARQL framework. Supported geometry formats include RDF literals in WKT, GML, GeoJSON, and KML.

These literals are investigated for the storage of 3D data.

Figure 2 — Difference between 2D, 2D with height attribute 2.5D and 3D geometry

Table 2

Literal Type	Z-Coordinate Supported	Z-Coordinate Supported + height attribute	2.5D	3D
WKT Literal	Yes	Yes	Yes	Yes
GML Literal	Yes	Yes	Yes	Only with extension Schema
KML Literal	Yes	Yes	Yes	As import from COLLADA
GeoJSON Literal	Yes	Yes	Yes	Yes
DGGS Literal

GeoSPARQL 1.1 also does not restrict the usage of coordinate reference systems with 3D support. There are currently almost 300 coordinate reference systems in the database epsg.io which can be used to describe 3D data encoded in the GeoSPARQL graph literals listed above.

GeoSPARQL allready supports linking multiple geometries (e.g., 2D and 2.5D) to a single feature. We aim to extend this with 3D geometries.

For example, a tree in the real world may be represented in databases with both a 2D and a 3D geometry.

This should not require duplication of the tree entity — there can be one tree instance with both geometries linked, avoiding redundancy in the data model.

8.1.2.  Adoption of GeoSPARQL 1.1

The article “A GeoSPARQL Compliance Benchmark”, Jovanovik, Homburg and Spasić [44] describes the results of a GeoSPARQL compliance benchmark. The measure of the extent of GeoSPARQL support in GeoSPARQL-enabled RDF triplestores was done in 2021. The article concludes that the GeoSPARQL standard, almost nine years after its initial release, is often only partially supported by major triplestore vendors. This raises the question of whether adding functionality to a standard increases implementation complexity, or whether new and more powerful capabilities can instead stimulate adoption by enabling new and more valuable use cases for software developers and users.

On the OGC Implementation Database there is no organisation compliant with the OGC GeoSPARQL standard. There are four organisations that are implementing the GeoSPARQL (v 1.0) standard.

8.1.3.  GeoSPARQL Aligments

GeoSPARQL is aligned with a range of established ontologies and vocabularies covering different aspects of geospatial information, metadata, provenance, time, sensors, and linked data. See Annex E of the GeoSPARQL Standard. Alignments with additional ontologies may be relevant for a broader 3D context. As an example, ontologies such as Reloc, BOT and ifcOWL can be interesting.

8.1.4.  GeoSPARQL functionality and geometries comparison

GeoSPARQL functionality can be compared with established spatial database extensions such as PostGIS H2GIS and SpatiaLite. The alligment offers a useful basis for comparing common spatial operations and capabilities with those defined by GeoSPARQL. The selection for spatial databases is not intended to be exhaustive. Other spatial databases, libraries and systems could also be included, depending on the scope of the comparison. The selected systems should therefore be regarded as representative reference implementations rather than a complete overview of available spatial technologies.

The comparison with existing open-source spatial technologies is intended to identify gaps between the functionality currently provided by GeoSPARQL and the capabilities available in established spatial databases. This provides an indication of the development potential of GeoSPARQL. The comparison can therefore be used to identify potential areas for further development and to assess which capabilities could add value to future versions of the standard.

When focusing specifically on 3D functionality, the largest differences in the comparison are found in geometry creation and editing, spatial measurements, and operations related to triangulation and topographic geometry. Also the topological functions shows some gaps between GeoSPARQL and the functionality in the spatial databases. These areas contain functionality available in the compared spatial technologies that is not represented in GeoSPARQL. They therefore provide the clearest areas for investigating potential further development of 3D functionality in GeoSPARQL. See Annex A: Alignment GeoSPARQL and Open Source Relational Databases with Geospatial Support

Besides the available functions, the geometry representations used by GeoSPARQL, such as WKT and GML, can also be compared with geometry representations used in other standards and technologies, such as IFC, STEP and Open CASCADE. The comparison shows that the largest differences in 3D geometry representation occur beyond basic points, curves and surfaces. IFC, STEP and OpenCascade provide more extensive representations for solids, volumes, boolean and constructive geometry, swept and revolved geometry and 3D transformations and spatial operations. These areas therefore provide relevant starting points for investigating potential extensions of GeoSPARQL for more comprehensive 3D geometry representation and processing. See Annex B: Allignment of Geometry

9.1.1.  Standard for the Exchange of Product model data (STEP) and OntoSTEP

STEP (Standard for the Exchange of Product model data) is an ISO standard for representing and exchanging product and engineering information, including CAD models. OntoSTEP translates STEP concepts into an ontology-based representation to support semantic integration and reasoning. OntoSTEP is a research-oriented approach that translates STEP/EXPRESS schemas and instances into OWL to enable semantic integration, querying, and reasoning. Initially developed at NIST, it has been further investigated through later implementations, but it remains a research approach rather than an established standard or widely adopted 3D ontology.

9.1.2.  STereoLithography (STL)

STL files describe only the surface geometry of a three-dimensional object without any representation of color, texture or other common CAD model attributes. The STL format specifies both ASCII and binary representations and was invented by the Albert Consulting Group for 3D Systems in 1987. Nowadays it is mainly used for 3D printing purposes, which makes is a plausible candidate for support in GeoSPARQL 3D settings of movable objects such as in cultural heritage. Since the STL format does not contain a geospatial reference, the reference needs to be provided externally if STL files were to be used in a geospatial context. However, STL objects could be used in local CRS contexts as well.

9.1.3.  Wavefront OBJ Format (OBJ)

The OBJ format is a file format developed by Wavefront Technologies for the Advanced 3D Visualizer animation package. Its roots therefore lie in the world of 3D animation. The format represents vertex coordinates, texture coordinates, as well as vertex normals, parameter space vertices and faces of a 3D model. These are all elements which would need to be considered and supported in an upcoming GeoSPARQL 3D release.

9.1.4.  Polygon File Format (PLY)

The Polygon File Format is a format which was designed to store 3D data from 3D scanning environments, which makes it especially widespread in the Cultural Heritage application area. The format consists of a vertex list and a faces list with optional parameters per vertex. Like the OBJ format, supporting PLY would imply including support for vertices and faces of a 3D model and their relationships in a knowledge graph.

9.2.1.  Geometry Metadata Ontology (GOM)

The Geometry Metadata Ontology (GOM) introduces classes for surfaces which are common in the 3D world, but uncommon for 3D geometries, for instance Meshes or NURBS surfaces. The ontology can serve as an inspiration for extensions in GeoSPARQL 3D and may or may not be fully or partly adopted in the process of standardization.

9.2.2.  Ontology for Managing Geometry (OMG)

The Ontology for Managing Geometry (OMG) describes states and derivation of geometries which may be useful to the description of data in GeoSPARQL 3D. For example. an extrusion in 3D from a 2D geometry template would have a derivation relation from the 2D geometry which one might want to see modeled in GeoSPARQL 3D.

9.2.3.  File Ontology for Geometry Formats (FOG)

The File Ontology for Geometry Formats (FOG) provides a bridge between ontology descriptions of geometries and data file descriptions of 3D contents. Since many 3D datasets are of considerable size, their inclusion into the knowledge graph as String literals might hinder the query performance of said knowledge graph. It therefore stands to reason whether to adopt the same or a similar method of geometry access that FOG provides for GeoSPARQL 3D.

9.3.1.  X3D Ontology

Extensible 3D (X3D) Graphics is an open standard to declaratively representing interactive 3D computer graphics for publishing, viewing, printing and archiving 3D models on the Web. X3D was eventually approved by ISO (ISO/IEC 19775-19777) and become an computer graphics industry standard. It was first proposed in 1997 and has since been subject to various updates. More recently it has been developed towards the Semantic Web, in order to gain interoperability and enable intelligent 3D operations and reasoning. Development has been hosted by the Web3D Consortium.

Currently in its version 4, the X3D Ontology maps the full X3D standard (X3DUOM) into OWL 2, providing classes and properties for nodes, geometry, appearance, animation, and scene graph structure, enabling query and reasoning over X3D scenes [FlotynskiWalczak2017] georgieva2023transforming [41] [39] flotynski2020recent [_975906]. X3D is regarded as a comprehensive and formally grounded 3D ontology, adding fundamental concepts and roles of the 3D modelling industry not originally covered by X3D.

The X3D Ontology has also been used to transform non-semantic 3D file formats into RDF with languages such as RML or XSLT georgieva2023transforming [39].

The X3D format feichtenhofer2020×3d, brutzman2010×3d, X3DOM behr2009x3dom and its Ontology version brutzman2020×3d provide a data format and a blueprint for how 3D data is handled in computer vision approaches. X3D is an interesting format to investigate for 3D components which need to be modeled within a GeoSPARQL 3D specification. It is a likely candidate for a literal format and might be integrated using interlinking approaches to the already existing X3D vocabulary. However, since X3D was invented with computer vision approaches in mind it does not define any geospatial aspects that could be considered by a GeoSPARQL 3D implementation.

9.3.2.  VRML / Java3D spatial ontologies

Application ontologies abstracting VRML & Java3D node types plus a separate spatial ontology for topological, directional and metric relations pacheco2018creating.

9.3.3.  Common Shape Ontology

– represents manifold/non‑manifold shapes, point sets, hierarchical model groups, positions, orientations, keyframe animation [FlotynskiWalczak2017].

9.4.1.  Geospatial and 3D City Model (CityGML)

CityGML and OntoCityGML

CityGML [koble2005citygml] is an open standardized data model for the exchange of 3D models of cities and landscapes. Since its standardization by OGC, CityGML has seen a wide variety of proposed extensions and alignments to other data standards.

CityJSON and CityRDF

[46] proposed the extension of the CityGML and its accompanying serialization CityJSON as an ontology model. Currently, the CityRDF standardization group works towards the standardization of this CityGML data model in RDF.

The proposed CityRDF model, even though focused on CityGML and 3D building contents, contains valuable data descriptions which could be generalized in a GeoSPARQL 3D approach. One such element is the description of the appearance of a 3D-modeled building using colors or textures, so-called surface materials. In addition, CityGML includes relations of 3D primitives between each other, which could serve as an inspiration for similary-named functions or properties in the GeoSPARQL 3D ontology model.

[46] describes the CityGML Ontology, which is an ontology model to formalize the CityGML standard towards a representation in OWL. It shows a workflow of identification, classification and selection of the relevant data points needed to describe 3D city models in OWL as derived from building and city models. In addition, it introduces the concept of Level of Information Need, defining the granularity of the information on the various levels of the building and the types of information retrieval — direct/indirect, i.e. information which is commonly obtained directly from a dataset or using a calculation or reasoning approach. The paper exemplifies the concept in a study case for property unit cost and indoor daylight. The contribution outlined here became the basis of the CityGML ontology which can serve as one broad application area for GeoSPARQL 3D.

Following on this publication [33] presents a system architecture and a set of interfaces that can represent city modeling approaches using dynamic geospatial knowledge graphs. The paper proves the viability of a transition between a SQL based system for 3D building management to a SPARQL based system using a SQL2SPARQL Transformer component. It therefore proves the feasibility of employing linked open data technologies for 3D building data and in particular the CityGML model in practice.

[51] introduces CityGML 3.0 with a newly added Core module including a new space concept and Level Of Detail concept. The given publication sets the standard especially for Level of Detail in 3D buildings, which may be considered for adoption as GeoSPARQL 3D concepts too. In addition, CityGML 3.0 proposes the addition of 3D point clouds for the representation of 3D goemetires of physical spaces and space boundaries. A mapping from IFC to CityGML 3.0 is also proposed by these authors.

CityGML 3.0 therefore represents many of the elements that a GeoSPARQL 3D ontology would need to implement on a more abstract level and can give ideas about future query functions to be implemented in the GeoSPARQL query language.

In addition, a master thesis hansson2024citygml proved the feasibility of not only converting CityGML to a knowledge graph representation, but also its application in triple stores such as Ontop or 3DCityDB. The mapping of CityGML to the knowledge graph was tested using a set of SPARQL queries retrieving different components of building parts. While the thesis could construct a knowledge graph representation from CityGML, it points out that the incorporation of sptaial operations is left to future work and could provide a possible field for GeoSPARQL 3D adoption.

Finally, [32] proposed OntoCityGML, an extension go the CityGML ontolog https://www.sciencedirect.com/science/article/pii/S2666546821000574?via%3Dihub Semantic 3D City Database — An enabler for a dynamic geospatial knowledge graph

Other details and history of Onto CityGML.

CityRDF working group https://github.com/ogcincubator/cityrdf

9.4.2.  Cultural Heritage

In the research domain of cultural heritage, 3D models of either cultural heritage artifacts (possibly georeferenced), 3D models of archaeological sites or simply 3D models of ancient buildings are becoming increasinly common.

Building-conservation ontology for 3D annotations. The conservation and restoration of historical monuments require the integration of information from many different disciplines and techniques. This study presents a pipeline that combines semantic, spatial, and morphological data into one 3D information model. The approach was tested on Saint Maurice Church in Caromb, France, allowing conservation experts to better visualize, correlate, and retrieve information about materials, damage, and other conservation observations. [31];

CIDOC CRM–based models for 3D CH objects and provenance. This paper proposes an ontology-based approach for managing and using 3D content without requiring domain experts to have programming or 3D modelling skills. The actual 3D elements can be created by graphic designers and then linked to domain-specific concepts by developers. Ontologies and automated reasoning can subsequently determine which 3D elements are relevant based on the specified domain information, while semantic queries allow the content to be explored and analysed. The focus is therefore on connecting 3D graphics with domain knowledge rather than on creating the 3D models themselves. walczak2019inference amico2106ontological .

Use Cases

Use Cases in the Cultural Heritage domain include, but are not limited to, the following main interests:

Visualization: The visualization of 3D models for the presentation of such 3D models, for example in the context of a museum. 3D models may be styled with a particular set of textures or modeled with a specific set of colours to highlight certain relevant aspects. The visualization of 3D models is currently standardized by the IIIF 3D working group [48], which aims to create viewing parameter descriptions that 3D viewers may implement, similar to the specifications of IIIF 2D for images.

Object Annotation: 3D models are seen as the subject of a research question in absence of the original artifact for political, practical or other restrictive reasons. Out of all known methods of the representation of cultural heritage artifacts, 3D models provide the most detail when being delivered as a digital artifact and are therefore very often preferred in a research context. Researchers mark noteworthy aspects of the cultural artifact as 3D annotations [47] which may include surface descriptions, volumes of the 3D model or 3D models which are created and placed adjacent to the to-be-annotated 3D model [29].

Relation of Objects: Objects of a specific collections always exist in a spatio-temporal context. It is important to relate these representations via meaningful relations, so that relevant objects of a collection can be retrieved more easily

AI Applications in Cultural Heritage: Usage for annotated areas on 3D models or their derivations for machine learning classifications Stotzner_2023_ICCV 10.2312/gch.20231157

Knowledge Graphs as Metadata descriptions: With the advent of more 3D models being published, the relevance of their creation parameters [52], their contents and their object metadata increases for the usecases of filtering them and also for the possibly automated selection of suitable cultural heritage metadata for e.g. machine learning classifications. Currently, many metadata standards fulfil parts of the description chain and a unified vocabulary to described data types seems to be missing.

Research applications making use of 3D models in Cultural Heritage

This section discusses research projects with 3D contents based on the technologies they use as elaborated in the previous section.

9.4.3.  ChgOnto

Grottoes & heritage ontology. This paper focuses on enhancing 3D models of Chinese grottoes by adding semantic information. It develops a knowledge graph that links 3D elements—such as caves, Buddha statues, walls, and decorations—to their properties and spatial relationships, making the 3D models more meaningful, understandable, and useful for cultural heritage documentation and analysis.for grotto components, spatial relations, with GeoSPARQL + CIDOC CRM yang2023knowledge.

9.4.4.  OntPreHer3D

OntPreHer3D is an extension of the CIDOC CRM ontology. It is designed to support the FAIR preservation and documentation of 3D cultural heritage models. The ontology captures relationships between 3D models, their components, and real-world counterparts, while also documenting the reasoning, uncertainties, and decisions behind hypothetical reconstructions. A case study of the Speyer Synagogue demonstrates how differences in modelling processes can affect final 3D models, highlighting the importance of detailed documentation for the long-term preservation, reproducibility, and reuse of digital cultural heritage. OntPreHer3D: Ontology for Preservation of Cultural Heritage 3D Models

9.4.5.  BIM and Buildings

9.4.6.  BIMSPARQL

This initiative proposes extending SPARQL with functions for querying IFC building data to simplify queries and derive information from 3D geometry for BIM requirement checking. The functions are represented as RDF vocabularies and implemented using a combination of declarative rules and procedural programming. Evaluation with realistic requirement-checking scenarios demonstrates that the approach supports spatial and logical reasoning and can combine building and regulatory data from multiple sources. [42]

Figure 3 — IMSPARQL.

9.4.7.  stSPARQL

In Modeling and Querying Metadata in the Semantic Sensor Web: the Model stRDF and the Query Language stSPARQL [49], Koubarakis and Kyzirakos describe the extension of SPARQL with temporal information. These paterns can also be used for GeoSPARQL.

9.4.8.  OntoBREP and OntoSTEP

OntoBREP is an ontology that can be used to describe CAD by representing boundary representations (B-Rep) using OWL. Geometric entities are represented semantically. For example, a circle is described by its coordinate frame and radius instead of a set of polygons. The ontology represents geometric constraints between objects and their individual faces or edges, enabling CAD geometry to be linked with additional knowledge and used for applications such as shape recognition and robot task planning. [36]

OntoSTEP translates STEP schemas and their instances, originally defined using EXPRESS, into OWL. This creates a semantically representation of product and CAD information. The approach enables reasoning, inference, and querying over existing CAD data and provides a way to combine information represented using different modeling languages. ontostep

OntoBREP and OntoSTEP represent approaches in which geometry are brought into the Semantic Web at a relatively deep semantic level. This results in potentially large and complex knowledge graphs.

Different approaches for representing geometry in the Semantic Web have been investigated [30] ranging from integrating geometric structures into the knowledge graph to linking semantic resources to external geometry representations or files

Figure 4 — Approaches_of_Geometry_in_Linked_Data.

Figure 5 — Implementation_of_approach_1.

9.4.9.  ENVON

Robotics / manufacturing ontology that integrates contextual, topologic, geometric info for 3D environments; BFO‑based 3D shape ontology; BREP/CSG distinctions [43].

Use of domain specific ontologies Domain-specific 3D ontologies are typically expressed using RDF/OWL, defining concepts and relationships that capture the semantics of a particular application domain [FlotynskiWalczak2017] pittarello2006semantic walczak2019inference.

Geometry, topology, scene structure, and domain semantics are often represented by separate but complementary ontologies that can be combined at query time for integrated queries, such as BOT with geometry and sensor (SOSA/SSN or SAREF) ontologies in building applications [43] [34].

9.4.10.  Location ontologies

9.4.11.  Medicine and Chmistry

9.5.1.  Topological Relationships and Their Use

The book chapter Topological Relationships and Their Use highlights that topological relationships are well established for simple 2D objects, while 3D topological operations remain less developed. It identifies the need to support more complex 3D objects, including solids with holes and tunnels, and suggests reusing existing spatial operators as a starting point for extending topological analysis to 3D.

9.5.2.  Extension of RCC*-9 to Complex and Three-Dimensional Features and Its Reasoning System

The work described in the paper Extension of RCC*-9 to Complex and Three-Dimensional Features and Its Reasoning System, defines semantics of 3D bodies, regions, and lines, which can support the definition and interpretation of 3D spatial relations and operations. It provides a formal topological foundation that can be interesting for GeoSPARQL 3D.

9.6.1.  CGAL → SFCGAL → PostGIS

CGAL (Computational Geometry Algorithms Library) provides data structures and algorithms for computational geometry, including operations on geometric objects that can serve as a computational foundation for spatial processing. SFCGAL builds on CGAL to provide additional support for 3D and volumetric geometries and operations, including Boolean operations and geometric predicates. SFCGAL is integrated with PostGIS, a spatial database extension for PostgreSQL, allowing such geometry-processing capabilities to be used within a database environment. Together, these technologies illustrate how 3D geometric representations can be connected to computational geometry algorithms and exposed through a spatial database system, providing a relevant implementation perspective for 3D spatial operations in GeoSPARQL.

9.6.2.  OpenCASCADE

OpenCASCADE is an open-source software platform for 3D geometric modelling and CAD applications. It provides data structures and algorithms for representing and processing geometric and topological entities, including points, curves, surfaces, solids, and B-Rep models. The platform supports operations such as geometric transformations, Boolean operations, intersections, and shape analysis. Its explicit representation of geometry and topology makes OpenCASCADE relevant for the computational processing of 3D solids and for investigating how B-Rep-based geometry could be supported by a GeoSPARQL 3D implementation.

9.6.3.  BRep vs mesh/polyhedron

BRep - Curved surfaces - Topology: connected components as shells, solids with inner voids, etc. - Clean APIs due to inheritance: e.g fn extrude(Topo) -> Topo, for vertex → edge; edge → face; face → solid; solid → solid - Extra indirections: edge → vertex[] → point - Depending on implementation can be inefficient, e.g outer wire of face not explicitly marked need to be checked wrt infinite point - Data integrity and validation a bit harder

Mesh/polyhedron - Potentially fewer indirections - Triangle meshes robust and well understood - Many different data models though, e.g half-edge (only manifold), indexed faceset (no adjacency info), winged/quad/radial edge

B-Rep and mesh/polyhedron representations differ in how 3D geometry and topology are modelled. B-Rep explicitly represents curved surfaces and topological relationships between vertices, edges, faces, shells, and solids, making it suitable for complex solid models, but it can involve more complex data structures and validation requirements. Mesh and polyhedral representations generally use simpler discrete geometries, often based on triangles, with several possible data structures for representing adjacency and topology, such as half-edge, winged-edge, and indexed face sets. For GeoSPARQL 3D, this distinction is relevant because the underlying representation can affect the precision, robustness, and implementation of spatial operations.

9.8.1.  BOT (Building Topology Ontology)

The Building Topology Ontology distinguishes zones and elements. It also has topological relations as bot:containsZone and bot:hasElement. Any bot:Zone or bot:Element can be assigned a 3D Model using some existing data format for 3D models. Two properties are defined for this. The bot:hasSimple3DModel datatype property links a bot:Zone or bot:Element to a 3D Model encoded as a literal. If the data format is textual, then the lexical form of the 3D Model literal SHOULD be encoded as a Unicode [UNICODE] string, which SHOULD be in Normal Form C [NFC]. If the data format is binary, then the lexical form of the 3D Model literal SHOULD be encoded using a base32 encoding [rfc4648]. The bot:has3DModel object property links a bot:Zone or bot:Element to some IRI that identifies a 3D Model. This 3D Model can then be described using some dedicated RDF vocabulary. Else, the 3D Model IRI could be dereferenceable, and when looking up the IRI one could retrieve a representation of the 3D Model with some existing data format for 3D models.

Figure 6 — Example of a graphical feedback from a request for all wall elements adjacent to a particular space using BOT terminology. The 3D model is described as an OBJ-formatted mesh.

source: https://journals.sagepub.com/doi/pdf/10.3233/SW-200385

9.8.2.  OMG (Ontology for Managing Geometry)

The Ontology for Managing Geometry (OMG) is an ontology for attaching geometry descriptions to their corresponding things (e.g. building objects). The OMG is designed to provide three levels of adding the geometry descriptions which can be used and combined flexibly. The levels are designed to enable the attachment of metadata and comprise of the following functionalities:

Level 1: Direct connections between things and their geometry descriptions using either an object property for RDF-based geometry descriptions or a datatype property for non-RDF-based geometry descriptions resp. links to external files. Level 2: Introduction of an intermediate node between the things and their geometry descriptions. By reifying the geometry description, handling of multiple geometry descriptions of the same things is empowered, metadata (as tags) can be added and dependencies between geometries can be modelled. Level 3: Introduction of an intermediate node between the reified geometry and the geometry description to add geometry states. Thus, the version history of a geometry description can be described and stored.

9.8.3.  FOG (File Ontology for Geometry formats)

The File Ontology for Geometry formats (FOG) provides geometry schema specific relations between things (e.g. building objects) and their geometry descriptions. These geometry descriptions can be (1) RDF-based (e.g. using specific ontologies such as GEOM, OntoBREP, etc.), (2) RDF literals containing embedded geometry of existing geometry formats and (3) RDF literals containing a reference to an external geometry file.

such as OBJ, glTF and STEP, to be embedded in RDF or referenced as external files. Thus, while GeoSPARQL primarily describes geospatial geometry, BOT, OMG and FOG provide approaches that are more focused on building and construction geometry and the use of existing geometry formats.

the File Ontology for Geometry formats (FOG), a method for embedding and exchanging different 2D and 3D geometry formats within RDF graphs. FOG allows geometry data to be stored, referenced, and automatically identified, making it easier to exchange building geometry between different software and stakeholders.

9.8.4.  LBD Server, IFC2LBD and IFC2LBD-NEO

To make BIM data accessible on the web, the Linked Building Data (LBD) initiative applies Linked Data principles, using RDF, vocabularies, and ontologies to represent building information. To make this information practically accessible, a platform is needed that combines semantic building data with 3D visualisation. The LBD Server addresses this need by allowing users to upload building data, visualise its 3D geometry, and link geometric objects to their underlying semantic information. This enables users to explore both the physical and semantic aspects of a building within a web-based environment.

Figure 7 — LBD_Server_connectivity_GLTF_LD.

source: [_3e4260b3605459b8ce220cfb42a3525]

IFC2LBD makes the semantic transformation itself a central component. It converts IFC into RDF using LBD ontologies such as BOT, PRODUCT and PROPS. The result is a graph representation that can be queried and linked on the web. The original IFC-to-LBD work explicitly aimed to produce a simpler, modular representation than directly using the full ifcOWL structure. IFC2LBD-Neo takes this further by redesigning the converter as a modular, staged pipeline. It additionally uses ontologies as BEO, bSDD and OMG/FOG. The geometry is generated separately as glTF, Fragments or Parquet outputs.

Figure 8 — IFC2LBD Pipeline.

source: https://github.com/ISBE-TUe/IFC2LBD-Neo

Figure 9 — Demo Application with use of File Ontology for Geometry Formats FOG

source: https://ec-3.org/wp-content/uploads/2025/10/EC32019_166.pdf

9.8.5.  Routing using LADM and IndoorGML

IndoorGML (OGC) models indoor environments as cells, such as rooms, corridors and stairwells, and derives a navigation graph in which spaces are nodes and their connections, such as doors and openings, are edges. The Land Administration Domain Model (LADM, ISO 19152) describes the rights, restrictions and responsibilities attached to spaces. The combined LADM-IndoorGML model uses these legal aspects to define which indoor spaces are accessible to which users.

[50] applied this combined model to building evacuation. They showed that access rights depend on time (normal hours, off-hours and crisis situations) and on the type of user, such as visitors, employees or students, and that these rights determine which routes users can take to the nearest emergency exit or safe zone.

11.1.1.  Meaningful creation and querying of 3D geometry

Whether manually or programmatically defining 3D geometries in BIM, GEO or CG environments, the GeoSPARQL standard could provide or connect to vocabulary to represent 3D structures. A 3D cube, for example, can be represented in multiple ways:

Once GeoSPARQL offers the means to define and link 3D geometries in these different ways, it will allow both humans and machines to interpret and interact with the data effectively.

11.1.2.  Meaningful creation and querying of 3D topological relationships

Is “3D Geometry A” inside, touching, overlapping, intersecting or above “3D Geometry B”?

Being able to describe and use such topological relationships is crucial for conducting spatial analyses, formulating rules, and deriving knowledge from different heterogeneous datasets.

Beyond describing topological relationships, one should be able to query them:

Such queries should return the appropriate topological result (e.g., “intersects”), which is essential for use cases like clash detection in design validation

11.1.3.  Derivation of geometric and topological knowledge

From explicitly modeled geometric and topological data, one should be able to infer implicit knowledge.

For instance, if 3D Geometry A is 3D inside 3D Geometry B, then we can infer that:

even if these facts are not explicitly stated.

For entailment an application that is compliant with the geo-spatial 3D specification would be able to answer queries like: “Does this tree have a 3D geometry?”

If the tree is defined using a MultiSolid geometry, then the answer should be “yes,” even if this is not explicitly declared as such.

11.2.1.  Visualization

There is a growing need to visualize how 3D data in BIM and GIS relate to one another. Stakeholders want to see BIM and/or 3D Geo data of a newly planned structure visualized within the 3D Geo and/or BIM context of the existing digital city. A shared vocabulary that can present both domains in an integrated way supports this goal.

11.2.2.  Calculation and analysis

Semantic modelled 3D-model enables powerful computation and analysis. Analytical results can be displayed in dashboards operating within the GeoBIM domain. This creates a bridge between asset management (typically GIS-oriented) and project management (typically BIM-oriented), allowing for cross-domain collaboration and decision-making.

11.2.3.  Spatial querying

Spatial querying is a key function within a federated GeoBIM Network. Questions such as “What material is located in this area?” or “Where is space available for new cables and pipelines?” are examples of 3D spatial queries that can be answered when GeoSPARQL 3D is functioning effectively across systems and semantics.

11.2.4.  Machine control

A shared semantic GeoBIM Network also supports machine control. The GIS domain typically describes the existing situation, while the BIM domain describes the intended or future situation. This combination can be used to automatically instruct and guide machines in the built environment.

11.2.5.  Modeling, simulation and planning

A network of datasets with 3D-data should support the modeling, simulation and planning of future changes to the built environment. Users — whether human or machine — can use the network and GeoSPARQL 3D to propose and model modifications in either BIM or GIS formats. A well-functioning 3D semantic GeoBIM Network enables this kind of forward-looking spatial planning and design.

11.3.1.  Brings together different domains (GIS, BIM, CG)

GeoSPARQL 3D can help in bringing together different domains that work with 3D information.

11.3.2.  Enables extension to vocabularies from other domains

The vocabulary can have the possiblity to extend to vocabulaires with 3D geometry or topology from other domains, for example the Building Ontology Topology (BOT) or RELOC Ontology. Multi-domain models with georeferenced 3D and 2D city models could be also linked by CityRDF ontology based on CityGML 3.0 standard. GeoSPARQL 3D would be important enabler for data retrieval, update and analysis for such models. In addition to ontologies, it can also establish relationships to 3D file formats from other domains, such as glTF.

11.3.3.  Facilitates better interoperability between knowledge domains with spatial components (geography, aerospace, architecture, product design, (bio)chemistry, IoT, …)

A unified geometric language can help by migrating ideas and methods across fields, accelerating innovation. For example a parametic design algoritm, rule, or llm making use of geometry and topology originated in aerospace, can be re-used in the architecture domain.

11.3.4.  Integrated spatial analysis in digital twins

Digital twins combine data from multiple sources, including building models, geospatial datasets, infrastructure and regulatory information. These sources may use different data formats, data models, and vocabularies. Integrating them for spatial analysis can require dedicated software, data transformations, and application-specific connections.

Many spatial analyses, such as construction height verification, clearance analysis, distance calculation, and clash detection, can already be performed using existing GIS, BIM, and 3D processing software. The benefits of 3D-GeoSPARQL is therefore not necessarily to introduce these analyses, but to make them accessible through a common semantic and query framework.

By providing a common framework for representing and querying 3D spatial information, 3D-GeoSPARQL could enable spatial operations to be combined with semantic queries across heterogeneous datasets. For example, a building permit checking process could identify a building’s relevant components from an BIM-derived knowledge graph, retrieve the applicable spatial regulations, and evaluate the geometry of the proposed building against existing urban assets.

This approach could make spatial analysis processes more reusable across datasets and applications, reduce dependence on application-specific integrations, and improve the traceability of the spatial information used in decision-making.

Regulatory compliance and design validation — building height, underpasses, overhangs and distances to the waterfront.

Building safety and evacuation — escape routes, compartmentalisation and accessibility of emergency exits.

Infrastructure coordination and construction planning — cables, pipes, foundations and clashes.

Urban planning and environmental risk assessment — flooding, clearance, shadow and spatial integration.