Suggestions from Fuhu's Team - Suggestion 1 - replacement/extension of DE-9IM topological model with other models that are not based on point, line, polygon

[geofizzydrink]

According to part 8.3 in the document OGC Abstract Specification Topic 21 v2.0 - Part 1, the elements of Topological Query functions are based on the DE-9IM model. However, we are considering if the DE-9IM model can be fitted well to the DGGS since the model only measures the relationships between any two of point, line, and polygon. We are not sure if the DGGS has the concept of vector elements, points, lines and polygons; in our understanding, it is rasterized on the 2D-plane and voxelized in 3D-space. For instance, the relationship ‘cross’ is only capable when lines exist, but for DGGS, which does not have the concept of lines, how should we interpret this ‘cross’ relationship? And, another problem is, how should we apply the DE-9IM model on a 3D system?

Based on above considerations, we are wondering if we should substitute the DE-9IM model with other topological query method; in other words, if we should abandon the concepts of point, line, or polygon and only consider the concept of discrete grid zones. In the grid system, the zones are hierarchical, encoded, and the difference between points, lines and polygons are pretty blurred. For example, a GeoSOT 1°×1° 2D zone has a length and width of about 100 kilometers on the equator. It is counted as only one zone in quantity, but it is a polygon in terms of geographical coverage. We suggest computing the topological relationship between zones directly. For example, there might be 4 types of topological relationships between zone sets (a single zone(cell) is a zone set with only one zone):
Touch (adjacent, common edges in 2D, and common surfaces in 3D),
Intersects (common surfaces in 2D, and common bodies in 3D),
Disjoint (no common edges or common bodies),
Equal (two zone sets can be completely overlapped),
Contains or Within (One zone set is the subset of another zone set).

[jerstlouis]

My understanding is that the way DE-9IM is applied to Topic 21 is that an operation with DGGS zone is simply replaced by the geometry of that zone, which is normally a 2D polygon or a 3D or 4D prism. Then everything works as usual.

The valid operations between two zones are those valid for e.g., polygon - polygon.

[jerstlouis]

This issue is somewhat related to #35 and #37 .

As far as the API is concerned, the DE-9IM considerations only come into play for Zone Queries and Zone Data used together with the corresponding CQL2 filtering requirements classes, for servers also implementing support for the spatial operator requirements classes of CQL2.

The spatial operations then apply to the data itself, regardless of the internal representation.

I'm not sure I understand how there would be fewer operations with DGGS, because all DE9IM operations are defined as a 3x3 matrix of intersections between the Interior, Boundary and Exterior of geometries, and are defined purely as a function of the resulting relation matrix (all operations can be implemented using the relate() DE9IM/SimpleFeaturesAccess function).

The main particularity of DGGS that I see is related to precision as discussed in #37.

We suggest computing the topological relationship between zones directly.

I believe this is an implementation decision, and as long as it yields correct results is perfectly fine (and might achieve the best performance).

In the grid system, the zones are hierarchical, encoded, and the difference between points, lines and polygons are pretty blurred.

I believe the concepts of simple features and the distinction between points, lines and polygons which are geometries of different dimensionality is quite important and not something that the use of a DGGS should prevent, and not only for obvious interoperability reasons with non-DGGS geospatial software.

I think the internal DGGS-optimized representation of simple features definitely needs to maintain these distinctions, whereas the individual points of the geometries can be represented as zones. See the DGGS-FG-JSON representation for more details on a recommended DGGS-optimized representation of vector data, where geometry coordinates are represented as local sub-zone indices within a coarser parent zone.

For instance, the relationship ‘cross’ is only capable when lines exist, but for DGGS, which does not have the concept of lines, how should we interpret this ‘cross’ relationship?

The concept of lines really should still exist in DGGS representation of vector geometries (see above).

We are not sure if the DGGS has the concept of vector elements, points, lines and polygons; in our understanding, it is rasterized on the 2D-plane and voxelized in 3D-space.

DGGS implementations can support both rasterized and vector data.
The DGGS-optimized encodings of DGGS-JSON and DGGS-FG-JSON illustrate and target each of these respectively.

And, another problem is, how should we apply the DE-9IM model on a 3D system?

I believe that the SimpleFeaturesAccess suggests that the DE-9IM model can be extended to 3D.
In practical terms, you still have a 3x3 matrix of Interior/Boundary/Exterior, but the values within this matrices can also include 3 meaning that the intersection is 3-dimensional. All existing relation functions should still be well-defined based on this since the matching works with False (F), True (T) or Any (*).

@geofizzydrink since we do not define any functionality specific to spatial relation in the API, do you think we can now close this issue ?

[geofizzydrink]

Closing this issue because the functionality of spatial operators is an internal operation of the DGGRS which can be achieved through CQL2 and does not need to be specifically encoded in the OGC API DGGS.