-
-
Notifications
You must be signed in to change notification settings - Fork 262
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
C/F ordering in naming #232
Comments
@constantinpape, do you know if this is still relevant? This came up in relation to Zarr/N5 compatibility, but don't know if this is still an issue cc @joshmoore (for vis) |
And further cc @d-v-b |
Thinking about the pros and cons of expanding the configuration surface area to cover this. As a "pro", it would erode some of the differences between n5 and zarr, as n5 uses F order for the chunk IDs. Although other differences would still remain, like the concrete names of the metadata files, I think progress towards unification is nice. I can't really think of any cons right now besides the added burden on implementations and the generic cost of expanding what a config covers. So I'm +1 on this idea. |
I also still think this is relevant and I like your initial proposal from #232 (comment). |
In the process of investigating an analogous format ( https://github.com/zarr-developers/zarr/issues/231 ), one of the points raised was the current chunk naming uses C-ordering. Though others have used F-ordering. Given this, was wondering if it would be reasonable to make the chunk naming order configurable.
As a possible proposal, would it be reasonable to add an optional parameter to
.zarray
, which specifies the naming order, but simply have this default to the existing C-order for compatibility. As such this should hopefully be a compatible (i.e. non-breaking) change to the format.The text was updated successfully, but these errors were encountered: