N5 requires that the dimension ordering of chunk keys be reversed. I.e., for a chunk key foo/bar/0.1.2, invert_chunk_coords will return foo/bar/2.1.0.
Pre-2.81, chunk keys used two delimiters: "/" delimits the hierarchy, and "." delimits the chunk indices. After 2.8.1, chunk keys can take the form foo/bar/0/1/2, and suddenly there is no distinction between hierarchy and chunk index delimiters. "/"-separated chunk keys can arise if the array's chunk store has a key_separator property: Array._chunk_key(). N5Store has a dimension_separator property but not a key_separator property, so for N5Store chunk keys will use the default "." separator, and invert_chunk_coords will work fine.
But FSStore uses the key_separator property for determining how to write keys to storage. Arrays created using FSStore will read the key_separator property of the store adapt chunk keys accordingly. Thus, attempts to extend FSStore to work for N5 (where key_separator is "/") will run into issues where chunk keys look like foo/bar/0/1/2 and it becomes impossible for invert_chunk_coords to parse this into (array_prefix, chunk_coordinate)
Zooming out, it seems like a leaky abstraction if the format of chunk keys changes as a function of the implementation details of the storage layer. Chunk keys should have a consistent, parseable format, and it is the job of the store to convert chunk keys into the names of objects in storage.
N5 requires that the dimension ordering of chunk keys be reversed. I.e., for a chunk key
foo/bar/0.1.2, invert_chunk_coords will returnfoo/bar/2.1.0.Pre-2.81, chunk keys used two delimiters: "/" delimits the hierarchy, and "." delimits the chunk indices. After 2.8.1, chunk keys can take the form
foo/bar/0/1/2, and suddenly there is no distinction between hierarchy and chunk index delimiters. "/"-separated chunk keys can arise if the array's chunk store has akey_separatorproperty:Array._chunk_key().N5Storehas adimension_separatorproperty but not akey_separatorproperty, so forN5Storechunk keys will use the default "." separator, andinvert_chunk_coordswill work fine.But
FSStoreuses thekey_separatorproperty for determining how to write keys to storage. Arrays created usingFSStorewill read thekey_separatorproperty of the store adapt chunk keys accordingly. Thus, attempts to extendFSStoreto work for N5 (wherekey_separatoris "/") will run into issues where chunk keys look likefoo/bar/0/1/2and it becomes impossible forinvert_chunk_coordsto parse this into (array_prefix,chunk_coordinate)Zooming out, it seems like a leaky abstraction if the format of chunk keys changes as a function of the implementation details of the storage layer. Chunk keys should have a consistent, parseable format, and it is the job of the store to convert chunk keys into the names of objects in storage.