-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Table construction failes when using a custom dimension #459
Comments
Yeah we should just make them equivalent. The problem is converting to Symbol loses the distinction. |
Make what equivalent? |
E.g. Because of |
If we end up making them equivalent, what's the benefit of |
There are a few things. Plotting uses the types to decide plot axes here and in Rasters.jl. So both You can also manually define a dimension with isxdim(::Dim{:X}) = true
isxdim(::Dim{:x}) = true
isydim(::Dim{:Y}) = true
isydim(::Dim{:y}) = true
const X = Dim{:X}
const Y = Dim{:Y} Users could just do: DimensionalData.isydim(::Dim{:MyYDim}) = true For package devs I'm not sure who gets to define behaviors for these dims, e.g. in a package you may want do define plotting. In Rasters.jl that happens for |
I wrote dimension behavior before I realized table keys are all symbols and dims should be columns, and that Probably would have done things differently if those were in place from the start. |
If we use a
Dim{k}
wherek
is a Symbol that matches the name of one of the special dimensions created with@dim
(e.g.X
orTi
), then an error is raised when we use the Tables interface:The text was updated successfully, but these errors were encountered: