Cdm overhaul

[asinghvi17]

No description provided.

[asinghvi17]

@rafaqz is this ready to merge into the geometry lookup branch from your end?

[rafaqz]

No, heaps more happening. Probably we will merge the other way it's more like "fix all of CF" now

[asinghvi17]

Yea that works too

[rafaqz]

35 CF examples now! - all loading but not all in the optimal way. Rotations are still missing, and I'm not sure how to handle these lookups with a center point and an explicit polygon boundary.

With a regular lookup At would select the center point, and Contains would select anything in the cell (we should have used Coveredby for that, need to DE-I9M-ize DD asap)

So for this it could do the same thing? and maybe for all geometry lookups? At gets the centroid/representative point, and Contains or whatever checks if the point is in the area.

(I'm thinking we might need a DE19M.jl or DE19MPredicates.jl package to hold all of these wrapper types, then we can use them everywhere, like Extents.predicate(Contains(), a, b) and we have the predicate separated from the context.)

[asinghvi17]

At gets the centroid/representative point, and Contains or whatever checks if the point is in the area.

I don't know about that....it seems pretty useless, the representative point must be within the geometry at any rate. At least for At.

[asinghvi17]

DE19MPredicates.jl

That would be nice...but would conflict with GeometryOps operations when we add those. Plus Rasters has Touches which is not DE9IM touches...

[rafaqz]

Yeah swapping DD Touches and Contains is where the idea can from. I don't think it will conflict, are there types in GO? We can just use them there too?

[rafaqz]

Haha then we can select with geometries omg

[asinghvi17]

Haha then we can select with geometries omg

We already can ;)

are there types in GO

No but there will be. And they have to subtype GOCore.Operation. That's so that they fit in the whole declarative API, if not then it's not really feasible...

One thing we can do is that DE9IMPreds.jl depends on GOCore, and Extents, and actually fills in the Extents.predicate method for these predicates. But then DD depends on GOCore, not sure if we want that.

[rafaqz]

it seems pretty useless

Maybe, but I'm not sure what else At would do, probably error.

[rafaqz]

We already can ;)

But like, with all the predicates even on a regular raster

[rafaqz]

No DE19M is a barebones thing that Extents.jl could depend on. I think GO should just depend on it like DD depends on IntervalSets even though its not a selector.

[asinghvi17]

The problem there is again the names will clash

But I don't mind putting func defs there that we specify can only be overloaded by types that the defining package owns. Then we can put the generic GI definitions in Rasters, but allow Extents to overload for Extents.jl types only. (So no (::Extent, ::Any))` in Extents, for example.

My issue is more about the GO end than the DD end to be clear.

[asinghvi17]

But like, with all the predicates even on a regular raster

what does that mean? If I say Intersects(geom), then it can only give me either the bbox or a mergedlookup raster, neither of which are particularly nice.

How do we specify that the raster should be masked? Maybe a new MaskingIndexSet type? But that breaks the implicit promise of dims2indices, that it will return something vaguely sensible.

[rafaqz]

I don't get why we need both predicate objects, the idea was to use the same thing rather than clash...

In simplest form it's a parameterised wrapper struct with default value of nothing.

That can be used for a lot of things. It can have a keyword holding method too like Dimension in DD

[asinghvi17]

I think we're thinking of two different objects. I'm thinking of the GO Operations interface, i.e.

abstract type GeometricPredicate <: Operation end

struct Contains{Alg{M}, Exact, ...} <: GeometricPredicate end

nargs(::Contains) = 2
application_level(::Contains) = GO.TraitTarget{GI.AbstractGeometryTrait}()

function (::Contains)(::GI.PointTrait, p1, ::GI.PointTrait, p2)
end

or something like this

---

My understanding is that you are thinking of more of a DD Dimension or Selector like struct?

The issue that I have is that GO.Contains() != DE9IM.Contains(), which will inevitably lead to name clashes basically everywhere. So we should figure out how to mitigate that. Maybe we just say that predicates are not GO operations? Not sure what the best solution is here. But this is the issue in my mind.

I don't know how the Operation interface will turn out - maybe we can make it semi trait based. Or maybe we don't end up doing it at all? It's kind of tricky.

[asinghvi17]

This apparently points to my vectordatacubes branch right now. Should this PR be closed and we open a new one to point to main?