I. Keywords
The following are keywords to be used by search engines and document catalogues.
OGC, GeoSPARQL, 3D
II. Preface
To come…
III. Security Considerations
The following security considerations apply…
IV. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Organization one
- Organization two
- Organization three
3. Normative references
There are no normative references in this document.
4. Terms and definitions
No terms and definitions are listed in this document.
5. Abstract
To come…
6. Keywords
To come…
8. Introduction
GeoSPARQL is an open standard that enables storage and exchange of spatial data on the Web, based on the Resource Description Framework (RDF). Although not specifically bound, the current version of GeoSPARQL (1.1) is mainly geared towards spatial objects having zero to two dimensions. In other words, things that can be displayed on a flat surface. However, for three-dimentional spatial objects both supply and demand are increasing.
A future version of GeoSPARQL is expected to have extended capabilities supporting three-dimensional space. Not only would that make GeoSPARQL more useful for 3D geospatial data, it would also help in industries and knowledge domains that are not mainly focused on geospatial data, like Building Information Modelling (BIM) and Computer Graphics (CG). This paper describes which extensions to GeoSPARQL for 3D are most desirable, and how they could be achieved.
The paper consists of three main parts. The first explains the need for additional 3D capabilities in GeoSPARQL. It lists expected benefits, and describes how users and implementers of GeoSPARQL can reap them. The second part describes current capabilities of GeoSPARQL. In its current state, GeoSPARQL does allow modelling three-dimensional objects, but with relevant limitations. The last section describes requirements for extended 3D capabilities in GeoSPARQL. The latter is based on a market consultation, which resulted in a collection of use cases for additional 3D capabilities. By analysing those use cases, as well as current developments within and outside the OGC, insight in the most needed extensions to GeoSPARQL can be obtained. Requirements are then weighed against feasibility; some extensions are easier to achieve than others.
This paper should be interesting for the following audiences:
Current and prospective users of GeoSPARQL;
Current and prospective implementers of GeoSPARQL;
Members of related OGC working groups.
9. Beneficiaries and benefits
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.
9.2. Benefits
The benefits of semantic and graph technologies are outlined below.
10. Current capabilities
10.1. GeoSPARQL
GeoSPARQL is the most common geospatial extension of SPARQL. It was accepted as an OGC standard in 2012 and revised as GeoSPARQL 1.1 in 2024.
According to the standard document, “The OGC GeoSPARQL standard supports representing and querying geospatial data on the Semantic Web. GeoSPARQL defines a vocabulary for representing geospatial data in RDF, and it defines an extension to the SPARQL query language for processing geospatial data”.
10.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.
10.1.1.1. Vocabulary
GeoSPARQL 1.1 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 Features Vocabulary (TODO: add link) 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
It does not include commons 3D primitives, such as Cube or Mesh surfaces which are integral parts of 3D representations.
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.
10.1.1.2. Geometry Relations
Relations between geometries have been defined using three different sets of rules:
Simple Features Relations
Egenhofer Relations
Region Connection Calculus RCC8
All geometry relations are only defined for 2D geometries and do not take into account the third dimension.
10.1.1.3. Literals
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.
Table 1
| Literal Type | Z-Coordinate Supported | 2.5D | 3D |
| WKT Literal | Yes | Yes | Yes |
| GML Literal | Yes | Yes | Only with extension Schema |
| KML Literal | Yes | Yes | As import from COLLADA |
| GeoJSON Literal | 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.
10.1.1.4. Query functions with 3D support
GeoSPARQL 1.1 functions currently do not offer fully-featured 3D support. However, there are functions which may take into account the Z coordinate, if they are available.
Table 2
| GeoSPARQL function | Z-Coordinate Supported | 2.5D | 3D |
| geof:is3D | Yes | Yes | Yes |
| geof:minZ | Yes | Yes | Yes |
| geof:maxZ | Yes | Yes | Yes |
These functions check for the presence of Z coordinates or filter out maximum and minimum Z coordinates of the given geometry.
11. Requirements for GeoSPARQL 3D
This section provides an overview of feedback received on the current version of the GeoSPARQL standard (version 1.1) regarding 3D usage. It helps to identify some of the barriers to use, and to outline requirements that have not been addressed that may encourage greater uptake.
11.1. Proposed extensions for GeoSPARQL 3D
11.1.1. Extension 1: 3D representations
11.1.1.2. Category
Semantic improvement
11.1.1.3. Description
GeoSPARQL should include ways to represent 3D data in a knowledge graph.
3D data should be included in common 3D formats and 3D data should be includable as a text literal and a file representation.
Some common formats which could be considered for inclusion are:
11.1.2. Extension 2: Relations of 3D geometries
11.1.2.2. Category
Semantic improvement
11.1.2.3. Description
GeoSPARQL should include ways to represent relations between 3D geometries and relations between 3D geometries and geometries of lower dimensions. The relations should be expressable in property relations and should be queryable using SPARQL extension functions.
11.1.3. Extension 3: Appearance of 3D geometries
11.1.3.2. Category
Semantic improvement
11.1.3.3. Description
GeoSPARQL should include ways to represent materials and textures of 3D geometries, so that geometries can be styled accordingly.
Materials include:
Colors of surfaces with light diffusion parameters
Images as textures, which are associated with surfaces of the 3D object
11.1.4. Extension 4: Multi-component 3D geometries
11.1.4.2. Category
Semantic improvement
11.1.4.3. Description
GeoSPARQL should include ways to define multi-component 3D geometries, whereas each component expresses its own semantics. For example, parts of a building could have different semantics according to the function of the building components and would be classified as such in an RDF graph.
11.1.5. Extension 5: Positioning of 3D geometries
11.1.5.2. Category
Semantic improvement
11.1.5.3. Description
GeoSPARQL should include ways to position 3D geometries in a 3D space. Commonly 3D geometries are rotated, translated and scaled using commonly defined operators in computer graphics. Similar operations are needed for the relative positioning of 3D objects in GeoSPARQL, as properties and potentially as functions.
11.1.6. Extension 6: Alignments of GeoSPARQL 3D
11.1.6.2. Category
Semantic improvement
11.1.6.3. Description
GeoSPARQL 3D should be aligned to other vocabularies and standard which currently provide 3D support in different knowledge domains. Especially alignments to ifcOWL and the X3D vocabulary would position the GeoSPARQL vocabulary as a link between these different standards.
11.1.7. Extension 7: Alignments of Engineering CRS to Geospatial CRS
11.1.7.2. Category
Semantic improvement
11.1.7.3. Description
GeoSPARQL 3D should provide the opportunity to align a local coordinate system in which most 3D geometries are defined with a coordinate reference. While this work might only be partially done within the scope of GeoSPARQL itself, GeoSPARQL should be aligned with the emerging Ontology CRS developments of OGC and provide necessary functions or properties to create the link.
11.1.8. Extension 8: Geometry Extrusion
11.1.8.2. Category
Semantic improvement
11.1.8.3. Description
GeoSPARQL 3D should provide the opportunity to extrude 2D geometries to 3D geometries and vice versa.
11.1.9. Extension 9: Geometry Attributes
11.1.9.2. Category
Semantic improvement
11.1.9.3. Description
GeoSPARQL 3D should provide functions and properties that describe essential properties of a 3D Geometry such as its minimum and maximum height, width and depth and its CompactnessRatio.
11.1.10. Extension 10: Non-topological Query Functions — 3D Extension
11.1.10.2. Category
Semantic improvement
11.1.10.3. Description
GeoSPARQL 3D should provide the opportunity to execute non-topological query functions on 2D and 3D geometries commonly used in geospatial databases. Proposed extensions include following functions:
geometry extrusion to the specified line segment
geometry extrusion to the specified height
spatiotemporal geometry extrusion to the specified line segment with specific start and end time
Bibliography
RDF
World Wide Web Consortium, RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation (25 February 2014). https://www.w3.org/TR/rdf11-concepts/
TTL
World Wide Web Consortium, RDF 1.1 Turtle Terse RDF Triple Language, W3C Recommendation (25 February 2014). https://www.w3.org/TR/turtle