Support DataAPI metadata as GeoInterface name agreements

[rafaqz]

It's very cool that storing geometry column name metadata like this works:

https://github.com/evetion/GeoDataFrames.jl/pull/47

I just realised it should also work in Rasters.jl, and probably lots of other places. Maybe we can we state that "crs" and "geometrycolumns" are our blessed metadata keys somewhere in the GeoInterface.jl docs, then we can use them everywhere and GeoDataFrames.jl will already be compliant.

[evetion]

Yeah, I've thought about this when I implemented it in GeoDataFrames, but it's actually a bit complex.

• With metadata, there's now two sources of crs. What if they don't agree? Ideally, the Geointerface API just takes it from the metadata, as defined in the custom geometry package.
• What should the key and values be named and look like? The best example is actually GeoParquet, but that uses its own namespaced keys, and the rest under column metadata.

[rafaqz]

Yeah namespacing is an issue. @bkamins is there a standard way of namespacing metadata for DataAPI? We could prefix it with "GeoInterface_" or something?

[bkamins]

We thought about it, but decided we can add a standard later after some experience with it.

I understand this metadata will mostly not be accessed by the user directly, but rather programmatically via API. Is this right? Then the length of the key is not important.

Apache Arrow has the following standard: https://arrow.apache.org/docs/format/Columnar.html#extension-types. I would propose to use the same style, so it would be:

GEOINTERFACE:name

[rafaqz]

Yes its mostly for programatic use.

"GEOINTERFACE:crs" and "GEOINTERFACE:geometrycolumn" seem reasonable to me.

[asinghvi17]

I started an implementation of this in https://github.com/evetion/GeoDataFrames.jl/pull/70. That being said, it does seem like GeoInterface would need to take on Tables.jl and DataAPI.jl as dependencies - is this something that we can do here? Package extensions would be pretty annoying given the need to support older versions of Julia, even if we do use an include trick.

[asinghvi17]

The next step here is to have GeoInterface natively figure this stuff out - a direct dependency on DataAPI shouldn't be too bad, it's 500 lines of function stubs and documentation.

[evetion]

A package extension can work, 1.10 will be LTS very soon from what I gathered.

[asinghvi17]

How would that work, though? Just defining GI.crs(::Nothing, item) = GI.crs(nothing, DataAPI.hasmetadatasupport(item), item) and then defining various methods for that last function in the extension? I can't see another way to do this cleanly without resorting to piracy.

[evetion]

I was merely answering your

Package extensions would be pretty annoying given the need to support older versions of Julia, even if we do use an include trick.

I haven't thought out the design just yet, but it would be good to document our "reserved" namespace and keys already.