Skip to content
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

Open
jakirkham opened this issue Jan 25, 2018 · 4 comments
Open

C/F ordering in naming #232

jakirkham opened this issue Jan 25, 2018 · 4 comments

Comments

@jakirkham
Copy link
Member

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.

@jakirkham
Copy link
Member Author

@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)

@joshmoore
Copy link
Member

And further cc @d-v-b

@d-v-b
Copy link
Contributor

d-v-b commented May 26, 2022

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.

@constantinpape
Copy link

I also still think this is relevant and I like your initial proposal from #232 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants