Makie errors when plotting second DD variable with DateTime dimensions

[alex-s-gardner]

Load packages & initialize dimensions

using CairoMakie #v0.15.6
using Dates  #v1.11.0
using DimensionalData #DimensionalData v0.29.24#main

x = X(1:10)
ti = Ti(DateTime(2000, 1, 1):Month(1):DateTime(2025, 1, 1))

Plotting multiple DD arrays with numerical dimensions works fine

f = Figure();
ax = Axis(f[1, 1]);
plot!(ax, rand(x));
plot!(ax, rand(x));

Plotting multiple DD arrays with DateTime dimensions errors

f = Figure();
ax = Axis(f[1, 1]);
plot!(ax, rand(ti));
plot!(ax, rand(ti));

Error output

ERROR: ArgumentError:
Conversion failed for Scatter (With conversion trait PointBased()) with args:
Tuple{DimVector{Float64, Tuple{Ti{DimensionalData.Dimensions.Lookups.Sampled{DateTime, StepRange{DateTime, Month}, DimensionalData.Dimensions.Lookups.ForwardOrdered, DimensionalData.Dimensions.Lookups.Regular{Month}, DimensionalData.Dimensions.Lookups.Points, DimensionalData.Dimensions.Lookups.NoMetadata}}}, Tuple{}, Vector{Float64}, DimensionalData.NoName, DimensionalData.Dimensions.Lookups.NoMetadata}}
Got converted to: Tuple{StepRange{DateTime, Month}, Vector{Float64}}
Scatter requires to convert to argument types Tuple{AbstractVector{<:Union{Point2, Point3}}}, which convert_arguments didn't succeed in.
To fix this overload convert_arguments(P, args...) for Scatter or PointBased() and return an object of type Tuple{AbstractVector{<:Union{Point2, Point3}}}.`

Stacktrace:
[1] argument_error(PTrait::PointBased, P::Type, args::Tuple{…}, user_kw::Dict{…}, converted::Tuple{…})
@ Makie ~/.julia/packages/Makie/4JW9B/src/compute-plots.jl:698
[2] (Scatter)(user_args::Tuple{DimVector{…}}, user_attributes::Dict{Symbol, Any})
@ Makie ~/.julia/packages/Makie/4JW9B/src/compute-plots.jl:746
[3] _create_plot!(::Function, ::Dict{…}, ::Axis, ::DimVector{…})
@ Makie ~/.julia/packages/Makie/4JW9B/src/figureplotting.jl:397
[4] #scatter!#52
@ ~/.julia/packages/Makie/4JW9B/src/recipes.jl:521 [inlined]
[5] scatter!
@ ~/.julia/packages/Makie/4JW9B/src/recipes.jl:519 [inlined]
[6] plot!(ax::Axis, dd::DimVector{…})
@ DimensionalDataMakieExt ~/.julia/packages/DimensionalData/7IbgA/ext/DimensionalDataMakieExt.jl:395
[7] top-level scope
@ Untitled-1:16
Some type information was truncated. Use show(err) to see complete types.

[rafaqz]

Isnt this a Makie.jl bug? Did you try it without the DimArray?

[alex-s-gardner]

This error is specific to DD plotting.

This works fine:

ti = DateTime(2000, 1, 1):Month(1):DateTime(2025, 1, 1)

f = Figure();
ax = Axis(f[1, 1]);
plot!(ax, ti, rand(length(ti)));
plot!(ax, ti, rand(length(ti)));

[DylanMMarques]

This is the same issue as #1103 and is related with how makie handles dimension conversion of struct with custom recipes.

There is a big PR in Makie that hopefully will fix this MakieOrg/Makie.jl#5323. If not, I think it will allow to customise how dimension conversion is done on structs with custom recipes so we could add dimension conversion functions for DDs.

[alex-s-gardner]

Just as an FYI Plotting multiple DD arrays with DateTime dimensions worked in earlier versions of DD/Makie... so something broke the functionality - hopefully MakieOrg/Makie.jl#5323 can get merged soon.

[DylanMMarques]

I looked into this problem some time ago and found a work around which works for me. I will put it here as it could be helpful for you. The work around is to overwrite this function from Makie:

function Makie._register_argument_conversions!(::Type{P}, attr::Makie.ComputeGraph, user_kw) where {P}
    dim_converts = to_value(get!(() -> Makie.DimConversions(), user_kw, :dim_conversions))
    args = attr.args[]
    Makie.add_convert_kwargs!(attr, user_kw, P, args)
    kw = attr.convert_kwargs[]
    args_converted = Makie.convert_arguments(P, args...; kw...)
    status = Makie.got_converted(P, Makie.conversion_trait(P, args...), args_converted)
    force_dimconverts = Makie.needs_dimconvert(dim_converts)
    if force_dimconverts && status == true
        Makie.add_dim_converts!(attr, dim_converts, args)
    elseif (status === true || status === Makie.SpecApi)
        # Nothing needs to be done, since we can just use convert_arguments without dim_converts
        # And just pass the arguments through
        map!(attr, :args, :dim_converted) do args
            return Ref{Any}(args)
        end
    elseif isnothing(status) || status == true # we don't know (e.g. recipes)
        Makie.add_dim_converts!(attr, dim_converts, args)
    elseif status === false
        if args_converted !== args
            # Not at target conversion, but something got converted
            # This means we need to convert the args before doing a dim conversion
            map!(attr, :args, :recursive_convert) do args
                return Makie.convert_arguments(P, args...)
            end
            Makie.add_dim_converts!(attr, dim_converts, args_converted, :recursive_convert)
        else
            Makie.add_dim_converts!(attr, dim_converts, args)
        end
    end
    #  backwards compatibility for plot.converted (and not only compatibility, but it's just convenient to have)

    map!(attr, [:dim_converted, :convert_kwargs], :converted) do dim_converted, convert_kwargs
        x = Makie.convert_arguments(P, dim_converted...; convert_kwargs...)
        if x isa Tuple
            return x
        elseif x isa Union{Makie.PlotSpec, AbstractVector{Makie.PlotSpec}, Makie.GridLayoutSpec}
            return (x,)
        else
            error("Result needs to be Tuple or SpecApi")
        end
    end
    converted = attr[:converted][]
    n_args = length(converted)
    map!(attr, :converted, [Makie.argument_names(P, n_args)...]) do converted
        return converted # destructure
    end

    Makie.add_input!((k, v) -> Ref{Any}(v), attr, :transform_func, identity)

    Makie.add_input!(attr, :f32c, :uninitialized)

    return
end

The difference is the addition of the status===true in the if statement which forces Makie to first convert the DD to normal array and after do the DimConversion. I don't know much about Makie's internal so side effects might appear (I haven't notice any so far).