Merge pull request #27 from opengeospatial/motivation

Added motivation

Author: RolfJonker

document/bibliography.bib

@@ -147,4 +147,43 @@ @Article{yuchen2025ontology
   doi={10.1007/s10845-023-02246-6},
   abstract={The pervasive smart manufacturing is bringing increasing attention to digital twin. As a core part of virtual modeling, 3D virtual modeling is crucial to improve the intuitiveness of state monitoring, enhance human-cyber interactions, visualize conditions and simulations, and provide visual guides in digital twin. However, although 3D virtual modeling in digital twin has many benefits for different applications, its complex characteristics become obstacles for novice engineers to develop and utilize. Besides, research information about 3D virtual modeling in digital twin is too scattered, while there has been no literature review that specially and comprehensively summarizes and analyzes it. To help novice engineers understand and scheme 3D virtual modeling in digital twin for future research and applications, this paper reviews 106 digital twin 3D modeling cases with their characteristics, including deployment targets, purposes \& roles, collaborative models, data flows, the autonomy of 3D modeling, fidelity, twinning rates, enabling technologies, and enabling tools. This paper then discusses and analyzes the review outcomes via statistics. Finally, this paper also proposes a thinking map for scheming the 3D virtual modeling in digital twin. In general, 3D virtual modeling is oriented by the motivation behind different digital twins, engineers hence should reflect on the purposes, scenarios, resources, and long-term visions of their projects. When designing characteristics of 3D virtual modeling, engineers must consider functions, capabilities of data processing and transmission, timeliness of data, applicability, and specialty of each characteristic. For future work, this paper highlights three important research issues to realize the prospect of 3D virtual modeling, including the versatility of autonomous 3D modeling, incremental updates of 3D models, and optimal planning of data collections for 3D modeling. Besides, future work will also investigate the enhancem},
   url={https://ideas.repec.org/a/spr/joinma/v36y2025i1d10.1007_s10845-023-02246-6.html}
+}
+@Whitepaper{Abhayaratna2020wp,
+  author={Joseph Abhayaratna and Linda van den Brink and Nicholas Car and Rob Atkinson and Timo Homburg and Frans Knibbe and Kris McGlinn and Anna Wagner and Mathias Bonduel and Mads Holten Rasmussen and Florian Thiery},
+  title={{OGC Benefits of Representing Spatial Data Using Semantic and Graph Technologies}},
+  year=2020,
+  publisher= "Open Geospatial Consortium",
+  OGCreference= "19-078r1",
+  url={http://www.opengis.net/doc/wp/using-semantic-graph}
+}
+@article{Göbel2024,
+title = {Relative Location Ontology: An ontological model for
+representing directional topological relationships
+between spatial entities in oriented space},
+year = 2024,
+note = {Paper accepted for presentation at the 12th Linked Data in Architecture and Construction Workshop},
+url = {https://linkedbuildingdata.net/ldac2024/files/papers/LDAC2024_Camera_9.pdf},
+author = {Anne Göbels, Jakob Beetz},
+keywords = {Ontology, Linked Data, Natural Language Localisation, Damage Documentation Processing, Bridge
+Maintenance},
+}
+
+@article{Biljecki2019,
+title = {QUALITY OF BIM–GIS CONVERSION},
+year = 2019,
+note = {ISPRS Ann. Photogramm. Remote Sens. Spatial Inf. Sci., IV-4/W8, 35–42p},
+url = {https://filipbiljecki.com/publications/2019_bim_gis_quality.pdf},
+author = {Filip Biljecki, Helga Tauscher},
+keywords = {IFC, CityGML, quality, errors, topology, BIM, GIS, validation},
+}
+
+@article{donkers2016,
+  title={Automatic conversion of IFC datasets to geometrically and semantically correct CityGML LOD3 buildings},
+  author={Donkers, Sjors and Ledoux, Hugo and Zhao, Junqiao and Stoter, Jantien},
+  journal={Transactions in GIS},
+  volume={20},
+  number={4},
+  pages={547--569},
+  year={2016},
+  publisher={Wiley Online Library}
 }

document/figures/3DinIFC_FIG01.png

@@ -0,0 +1,30 @@
+== Motivation
+
+=== Why do we want 3D semantic modeling?
+The white paper: "OGC Benefits of Representing Spatial Data Using Semantic and Graph Technologies" describes the beneficiaries and benefits of representing data, including geospatial data, using semantic and graph technologies <<Abhayaratna2020wp>>. This section describes the motivation of adding 3D functionality to the GeoSPARQL standard. 
+
+While humans can often resolve 3D spatial questions such as “Is cube A inside cylinder B?” — even when the underlying data comes from different systems like GIS and BIM — this typically relies on implicit understanding, conventions, or direct communication between the data creators. For datasets to be meaningfully aligned, the people who created them often need to clarify assumptions, data structures, coordinate systems, or modeling intentions. Without such human-to-human explanation, machines struggle to interpret spatial relationships across heterogeneous sources. A conversion process is required, in which data is made homogeneous for analysis through extraction, transformation, and loading. Based on a homogeneous dataset, conclusions can then be drawn. Performing conversions may result in geometric simplifications, which can limit or even eliminate the functionality of spatial queries <<Biljecki2019>>.
+If one desires digital, automated processing or analysis of 3D spatial questions without requiring conversion, spatial information must be structured in an explicitly machine-readable format. When this is done, initiatives based on federated systems with heterogeneous datasets can obtain computer-generated answers to spatial 3D queries. This requires semantic alignment and standardized geometry processing in machine-driven analysis. <<Göbel2024>> In other words, a common vocabulary is needed to semantically define the 3D objects and its 3D sptatial function. 
+
+Imagine a constructor who wants to use real-time sensor data at a construction site in combination with modelled 3D data and 3D base registration data. By combining this the person wants to visualize the site, perform accurate spatial checks and calculations, and automatically update machine instructions for safe, efficient and autonomous execution" 
+ 
+The system uses 3D GeoSPARQL to integrate the data of the 3D design model, the 3D base registration model and 3D real-time sensor data to: 
+- Spatially associate sensor data with objects in the design and registration model 
+- Calculate the permissible tolerances 
+- Detect the deviations 
+- Dynamic adjust the design model 
+- Instruct the machine with the changes  
+- Visualize the new situation
+
+For both humans and machines, it must be unambiguous what is meant by the queries that are needed to do the job and the resulting answers. It should not matter whether the data is provided in a 3D-GIS, 3D-BIM or 3D-CG standard vocabulary.  
+
+==== A geo-spatial 3D specification would support data consumers by:
+ - access and understanding of 3D-geometry and 3D-topology from multiple sources; 
+ - the integration of 3D-data geospatial and non-geospatial;
+ - data quality evaluation of the given 3D-data;
+ - Geometric and topological description in natural language.
+
+==== A geo-spatial 3D specification would support data providers by:
+ - Maximizing the use of 3D-geometry and 3D-topology data;
+ - Defining multiple 3D topology or geometries;
+ - Assuring the quality of 3D geospatial data.

document/figures/Dimensions_FIG02.png

@@ -11,20 +11,42 @@ According to the standard document, "The OGC GeoSPARQL standard supports represe
 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.
 
 ===== Vocabulary
+GeoSPARQL version 1.1 consists of a Core module, a Topology Vocabulary extension, a Geometry extension, a Geometry Topology extension, an RDFS Entailment extension, and a Query Rewrite extension.
+Each of these modules will be briefly explained below.
 
-GeoSPARQL 1.1 defines a class `Geometry` as a subclass of `SpatialObject`.
+===== 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.
 
-An instance of `Geometry` is not restricted to two dimensions. 
+====== Topology Vocabulary Extension
+This extension provides standard definitions for spatial relationships that can exist between one spatial object and another. 
 
-A fine-grained classification of `Geometry` can use the Simple Features Vocabulary (TODO: add link) which extends the class `Geometry` with further types, such as _Point_, _Polygon_ etc.
+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.
+
+====== 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 https://opengeospatial.github.io/ogc-geosparql/geosparql11/sf_geometries.ttl[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.
+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.  
+
+[#img_core,reftext='{figure-caption} {counter:figure-num}']
+.Possible approaches for representing 3D objects in IFC
+image::../figures/3DinIFC_FIG01.png[align="center"]
 
 Concerning metadata of 3D models, GeoSPARQL 1.1 provides properties which can be reused in 3D contexts.
 In particular, the properties are:
@@ -34,20 +56,16 @@ In particular, the properties are:
 
 Further 3D-related metadata properties such as projection matrices are not part of the current GeoSPARQL 1.1 standard.
 
-===== Geometry Relations
-
-Relations between geometries have been defined using three different sets of rules:
+A first requirement for 3D support is the ability to save 3D data in a knowledge graph.
 
-- Simple Features Relations
-- Egenhofer Relations
-- Region Connection Calculus RCC8
+The Geometry extension enables geometries to be defined within the GeoSPARQL framework. Supported geometry formats include RDF literals in WKT, GML, GeoJSON, and KML.
 
-All geometry relations are only defined for 2D geometries and do not take into account the third dimension.
+These literals are investigated for the storage of 3D data.
 
-===== Literals
+[#img_core,reftext='{figure-caption} {counter:figure-num}']
+.Difference between 2D, 2.5D and 3D geometry
+image::../figures/Dimensions_FIG02.png[align="center"]
 
-A first requirement for 3D support is the ability to save 3D data in a knowledge graph.
-GeoSPARQL 1.1 defines a variety of String literal formats, which are investigated for the storage of 3D data.
 
 [cols="3,3,3,3"] 
 |=== 
@@ -59,9 +77,17 @@ GeoSPARQL 1.1 defines a variety of String literal formats, which are investigate
 |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 https://epsg.io/?q=%20kind%3AGEOG3DCRS[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.
+
+
 ===== Query functions with 3D support
 
 GeoSPARQL 1.1 functions currently do not offer fully-featured 3D support. 
@@ -77,4 +103,12 @@ However, there are functions which may take into account the Z coordinate, if th
 
 These functions check for the presence of Z coordinates or filter out maximum and minimum Z coordinates of the given geometry.
 
-==== Adoption of GeoSPARQL 1.1
+===== Geometry Topology Extension
+Another extension is the Geometry Topology extension. This provides query functions that return relationships between different geometries based on the topology vocabulary extension.
+
+===== RDFS Entailment Extension
+The RDFS Entailment extension provides rules for reasoning over geometries. Based on specific statements, additional information can be inferred.
+This kind of logical inference can also be applied to geometry. GeoSPARQL includes logic for reasoning over simple features geometries.
+
+===== Query Rewrite Extension
+GeoSPARQL allows queries such as whether “Feature A” is located within “Feature B” using its vocabulary. The Query Rewrite extension specifies a RIF rule that enables query rewriting. However, this extension does not support the rewriting of 3D queries.

document/sections/03a-motivation.adoc

@@ -2,12 +2,59 @@
 
 This section describes the beneficiaries and benefits of representing data, including geospatial data, using semantic and graph technologies. Furthermore, a collection of use cases demonstrate how semantic and graph technologies are used together with spatial data to tackle real world problems.
 
-=== Beneficiaries
+=== Semantic-functional value of 3D-GeoSPARQL
+ Value for data reasoning, formal description, and semantic interoperability
+==== 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:
 
-==== Beneficiary 1: Someone who benefits
+ - As a set of bounding points, lines, and faces;
+ - As a base surface with an extrude function;
+ - As an 3D geometric primitive (e.g., the concept of a 'cube' as a spatial figure).
 
-=== Benefits
+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.
 
-The benefits of semantic and graph technologies are outlined below.
+==== Meaningful creation and querying of 3D topological relationships
+ Is “3D Geometry A” inside, touching, overlapping, intersecting or above “3D Geometry B”?
 
-==== Benefit B1: My benefit
+ 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:
+
+ > What is the spatial relationship between 3D Geometry A and 3D Geometry B?
+
+ Such queries should return the appropriate topological result (e.g., "intersects"), which is essential for use cases like clash detection in design validation
+
+==== 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:
+
+ A does not "touch" B, and
+ A does not "overlap" with B,
+
+ 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.
+
+=== Value for user experience, visualization, and application use of 3D-GeoSPARQL
+==== 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.
+==== 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.
+==== 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.
+==== 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.
+==== 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.
+
+=== Added value of the 3D-GeoSPARQL for Organisations
+==== Brings together different domains (GIS, BIM, CG)
+ GeoSPARQL 3D can help in bringing together different domains that work with 3D information. 
+==== 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.
+
+==== 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.