Function to project to a lower dimension

[situx]

We need a toproject function to project to lower dimensions

[rggibb]

OGC AS DGGS 2.0 defines a projectTo parameter that can be applied to any of the ZoneQuery functions defined at https://docs.ogc.org/as/20-040r3/20-040r3.html#tab-ZoneQuery. projectTo is defined as follows in 8.3.3.1.

projectTo

• type directPosition[4], optional, default ⇐ (0,0,0,1) for relatePosition and relativePosition, otherwise (1,1,1,1) projectTo specifies an optional reference direction, surface or volume for an operation. Allowed values for each direction are 0 and 1, and n.
• projectTo defines a vector whose starting point is inferred as the point with each projectTo direction whose value is 1 set to 0. It takes one of three forms:
  1. In its one-dimensional form for specifying a reference direction, one direction has a value of 1. For example (0,0,0,1) projects to the temporal axis, and (0,0,1,0) projects to the vertical axis.
  2. In its two-dimensional form for specifying a reference surface, two directions have a value of 1. For example a surface at height n is specified by a projectTo value of (1,1,n,0) representing the vector [ (0,0,n,0), (1,1,n,0) ].
  3. In its three-dimensional form for specifying a reference volume, three directions have a value of 1. For example (1,1,1,0) projects to a spatial volume without reference to time, and (1,1,n,1) projects to a surface spanning all time at height n.
• Only the one-dimensional form is supported by relativePosition and relatePosition.

While this construct could be used to implement more complex spatio-temporal queries, that isn’t the intent of Query2D, and isn’t specified for ZoneQuery either.

[situx]

@rggibb How can this projectTo function deal with measurement coordinates like in POINT M representations in WKT? The third dimension of a point may be the z coordinate or the m coordinate depending on the definition.

[rggibb]

@situx In DGGS the dimensionality doesn't include a linear referenencing dimension, so they are out of scope. The premise of projectto is that the operation removes axes, rather than changing them. So by analogy in a traditional CRS coordinate space, if your initial dimensionality was defined as (lat,long,ht), projectTo is designed to reduce the dimensionalty to (lat, long) or (lat,ht) but isn't designed to achieve a projection change to a planar (x,y) coordinate space.

So what would it mean if a more general projectTo were applied in a (x,y,m) coord space? If we apply the same logical thinking then projectTo(1,1,0) would perform the operation in (x,y) space and projectTo(1,0,1) would perform the operation in (x,m) space .. is this the outcome we are looking for?

[situx]

I believe that would work. Then the only question for me is accessibility, i.e. whether to adopt this function or to define several functions like to2D, to2DM or sth. like that for clarity or for non-clarity because these are maybe too many functions?

[rggibb]

I would caution against splitting it out into multiple functions, primarily because if you did would you distinguish between 2D representing two spatial dimensions vs one spatial and one temporal, which of course could equally be 2D such as vertical and temporal - is calling all of those 2D itself a tad confusing?

What I think does have merit is retaining a single function or method but maybe improving the way it is parametised. I'd be happy to engage with the group on whether using a single 4D coord to represent the space being projected to, is over simplifying it and as a result introducing some potential confusion/complexity. For instance if you wanted to project to a (x,y) at a ht of 2, the notation is projectTo(1,1,2.0,0), but if you want to projectTo a ht of 1, there is some potential for confusion because we then have to distinguish between 1 representing a boolean 1 and 1 representing a ht of 1.0. OR to put it another way, if instead we specified it as projectTo(a,b,c,d) where a,b,c,d are each one of [T,F,n] with n a real number. That actually better represents the concept but also makes it plain that each variable can be either a boolean or a real. What does this mean for programming it? Any ideas/thoughts?