Can DGGS use DimensionalData vector data cubes

[alex-s-gardner]

As discussed on the JuliaGeo call there was interest in having DGGS use DimensionalData vector data cubes as a common data interface

[danlooo]

Traditional vector data cubes have at least a single spatial dimension that maps to an arbitrary geometry, e.g. one dimension for border polygons of countries. This is a very flexible definition. In a DGGS context, however, the geometry i.e. the cell is way more regular: Instead of storing each vertex of each cell individually like in polygons, we can just define the grid name and use numbers in the geometry dimension to enumerate all cells. Storing all cell polygons individually would be way too much overhead. In order to create a common data interface, we need to define how this enumeration index should look like.

The current implementation of DGGS.jl is based on the DGGRID ISEA4H grid with the Q2DI index:

using DGGS

a = open_dggs_pyramid("data/dggs/datasets/test/")
a[5].cos.data.axes

#(↓ q2di_i Sampled{Int64} 0:1:15 ForwardOrdered Regular Points,
#→ q2di_j Sampled{Int64} 0:1:15 ForwardOrdered Regular Points,
#↗ q2di_n Sampled{Int64} 0:1:11 ForwardOrdered Regular Points,
#⬔ Ti     Sampled{Int64} 1:1:10 ForwardOrdered Regular Points)

This is already based on DimensionalData. To create a common data interface, we need to add the grid name to the dimension.
In addition, we probably need to define functions to convert points to lat/lon and vice versa.

[asinghvi17]

The dream is that at the user level, subsetting with X and Y selectors in addition to the rest should "just work" - then we can do things a lot more easily.

Ideally there would be some way that we translate X and Y selectors to face indices. But this needs the three indices we have now, q2di_i, q2di_j, and q2di_n to be able to be "condensed" to X and Y.

DD vector data cubes have simply had one-dimensional, vector lookups of geometries. As you said, this then becomes a slightly different case.

If you have fast lat/long to cell index, and lat/long extent to vector of cell indices, then we can get something started fairly easily. We already have the infrastructure for arbitrarily coupled array-like lookups that we can get going, since we merged the ArrayLookup stuff in DD. So this just has to be a separate but coupled lookup set, which can be indexed in many dimensions.

[danlooo]

In a strict 2D XY DGGS world, one has to work on a plan in which all faces of the icosahedron are unfolded (see Fig. 3b). This results into intervals of X and Y that are not defined (white in the plot). I think this would be very confusing for the user. The only meaningful definition of X and Y is lat and lon, which is the equivalent of re-gridding the DGGS data cube to geographical space. Unfortunately, this is very slow.

One would rather select a disk (center cell id, radius) instead of a bounding box (xmin,xmax,ymin,ymax) in a DGGS context.