Nested xarray.DataTree-like containers
Xarray has an arbitrarily nested DataTree structure. Each DataTree is a node that has at most one parent and any number of children, as well as any number of dimensional data arrays. If a dimension is defined in a node, then if one recursively gets the data arrays of all descendants of that node, then any dimension of the same name among the children must share the same indices. DataTrees are natural containers for e.g. NetCDF files that contain multiple datasets.
Is there interest in something like this structure here? I suspect there may also be some graph APIs one could implement in Julia that would make this a little more useful than in Python.
We already have DimTree merged into main from https://github.com/rafaqz/DimensionalData.jl/pull/900, it's meant to be the same thing. Graph APIs would be great in an extension!
There aren't many docs for it and not all of the functionality is fully fleshed out yet. But if you'd like to give it a go then please do.
I'm also interested in dimtree nodes with spatial indices e.g. for STAC catalogs so that is something I will be looking into.
See the tests https://github.com/rafaqz/DimensionalData.jl/blob/main/test/tree.jl for some example usage.
Ah, I had seen it but it wasn't clear that it was more than just a mutable replacement for DimStack. Very cool, I see also that it can store arbitrary DimTrees.
Is there a roadmap for what it would take for it to no longer be experimental? I would probably either replace InferenceOjects.InferenceData with DimTree or make it an AbstractDimTree (depending on whether there's any behavior of DimTree I'd want to customize).
Its kind of meant to do both - a single branch is like a mutable replacement for DimStack, but you can make it nested.
I don't have direct use cases for it right now, and its pretty buggy, but its merged so that people can at least try to use it and help me flesh out the concept.
It will probably remain experimental until someone is actually using it for something with some success... so might be a bit chicken/egg if no-one steps up to do that and I don't find an immediate use-case myself. Eventually Rasters will switch to loading files as trees so theyre faster to load and easier to modify, but thats huge and might be a year or three.