Open kapple19 opened 3 days ago
This makes me think refdims
should also be table columns (just the same value repeated), so you could be setting refdims
instead of reshaping.
It's pretty much what they are meant for - tracking where in a larger array a slice comes from.
We could even add a DimNestedArray object that holds other DimArray/DimStack that updates refdims
automatically on indexing?
Oh I see. I'll check out refdims
then.
This makes me think
refdims
should also be table columns
Are you saying it doesn't implement the Tables.jl interface so it won't work out-of-the-box with AoG? I'm about to check it out now and see what it can do.
We could even add a DimNestedArray object that holds other DimArray/DimStack that updates
refdims
automatically on indexing?
I see. From my superficial understanding, DimArray
already has the features for nesting multiple layers, but you have an idea for a new object that would work better?
The automatic refdims
update upon indexing would indeed simplify the syntax for passing to AoG.data
.
I also found eachslice
.
TL; DR
I'm looking to simplify code for managing nested
DimArray
s andDimStack
s. E.g. feeding nested data toAlgebraOfGraphics
. Maybe aadd_dims
function? I've prototyped one below that I'm happy to PR.Motivating Example
My work typically involves exploring nested data structures that are best not laid out as a long-format data table. A (non-obvious) example is visualised in the following plot:
where the titles are bearings [deg], the horizontal axis is sound speed [m/s], the vertical axis is depth [m] and the colour is range [m].
And this is still a simplified version of the type of data I manage probably half my days at work.
The data plotted above is generated by the following code:
I can show the nested structures of
env
by:Each bearing
Dim{:θ}
has a collection of rangesDim{:r}
whose values aren't shared between eachθ
. Likewise eachDim{:r}
has a collection of depth-sound speedDim{:z}
-Dim{:c}
pairs whosez
values aren't shared between eachr
.(In other words, vector data I guess 😅 but with structures resembling raster data,
DimensionalData
is the best I've found so far for managing such data.)I've played around with ways to efficiently and flexibly visualise the above in different ways. My current preference involves the auxiliary function
add_dims
I've defined, which behaves likereshape
but forDimArray
s.The idea for
add_dims
is that when you access aDimArray
inside anotherDimArray
, that innerDimArray
doesn't hold information on theDim
(s) you used to call it.I'll define the compass bearing relationships:
and then plot like so:
Okay so, what's your question?
My question is, does anyone know any better ways to manage/handle this data, including interaction with
AlgebraOfGraphics
? The above is still only a simplified example of the type of data I handle about half by work days. Re AoG I'll be looking into pagination next as well, excited to see what it can do.If you guys like
add_dims
I'm happy to PR it with docs and example of course.I'm partially open to alternatives. I'd like to avoid
pregrouped
, it makes my soul hurt and in my opinion goes against the whole declarative syntax idea AoG was made for (but I still understand whypregrouped
exists).Are there other packages of storage structures that work better on this type of vector data but allows dimensional names and indexing, including grammar-of-graphics interoperability like what AoG provides?