Extension 12: Extending the GeoSPARQL with functions to handle 3D geometries

[mathib]

Hi!

A note from the construction industry use cases regarding Extension 12: Extending the GeoSPARQL with functions to handle 3D geometries (included in the PDF mentioned in https://github.com/opengeospatial/geosemantics-dwg/issues/6#issue-509061405).

Additional query functions can be added for 3D geometry based on BimSPARQL research and other related work. Furthermore, spatial querying should be possible over geometry descriptions of multiple geometry schemas instead of only (2D) WKT and (2D) GML.

As it’s unlikely that any geospatially-enabled querying engine will support all 2D and 3D geospatial functions or geometry schemes, it might be a good idea to group functions in modules and implementers can indicate to which modules they comply. Implementers can in this way indicate which functions and geometry schemes they support. The OGC could subsequently define a minimum number of open and widely-used geometry schemes that have to be supported in order to be “certified”.

See the following publication on BimSPARQL:

• Zhang, C., Beetz, J., & de Vries, B. (2018). BimSPARQL: Domain-specific functional SPARQL extensions for querying RDF building data. Semantic Web, 9(6), 829–855. https://doi.org/10.3233/SW-180297

[wouterbeek]

@mathib IIUC the current GeoSPARQL functions do not actively prohibit the use of 3D geometries. E.g., a function declaration like geof:sfIntersects(geom1: ogc:geomLiteral, geom2 ogc:geomLiteral): xsd:boolean seems to allow for intersections between 3D geometries.

That being said, I can imagine that many new 3D functions could be added (preferable based on good prior work like BimSPARQL). But that would be more about extending the current collection of 3D-compatible functions.

[mathib]

As far as I know, GeoSPARQL query functions are based on DE-9IM, Egenhofer and RCC8 region calcalus and I think that those only relate to regions (2D geometry) in a 2D or 3D space (but I'm no expert in such mathematical descriptions). As an example, if according to the RCC8 two regions are touching, they share a point or a line (if two 3D geometries would be touching, they share either a point, a line or a surface).

But besides the above, the main thing of raising this request for extending GeoSPARQL is related to a support of geospatial querying over a much wider variety of geometry formats, including both GML and WKT which are already supported by GeoSPARQL 1.0 for 2D querying (BimSPARQL allows 3D querying over 3D WKT geometry) and other types of 2D and 3D geometry formats, e.g. GeoJSON, OBJ, PLY, glTF, STEP, etc.

[wouterbeek]

@mathib Thanks for the added info. I fully agree that this is an important area for improvement.

[jabhay]

Created MoSCoW poll

[AJAY31797]

Hi @mathib and @wouterbeek,

I am looking to use GeoSPARQL to perform checking of intersection between 3D geometries. Now, based on my understanding, GeoSPARQL does not support that. But, based on this discussion, it seems the support is provided to some extent. I am wondering this case how exactly the Z-axis is dealt with? For instance, I have an inverted cone and a cube geometries. The cube height is less than half of the cone and it is placed such that it does not touch the cone, but if you look from the top, they seem to be intersecting. Here is a rough image what I am trying to say:

So, in this case, how exactly the elevation will be dealt with using the existing functions such as geof:sfIntersects?

Best Regards, Ajay