Opened 9 years ago
Closed 9 years ago
#1100 closed defect (fixed)
Test aligned tiling with 3D schemes
Reported by: | Dimitar Misev | Owned by: | Dimitar Misev |
---|---|---|---|
Priority: | major | Milestone: | 9.2 |
Component: | rasodmg | Version: | development |
Keywords: | Cc: | Peter Baumann, Vlad Merticariu, Alex Dumitru | |
Complexity: | Medium |
Description
It appears that aligned tiling doesn't quite work as expected, creating more tiles than expected when using a 3D scheme.
Change History (8)
comment:1 by , 9 years ago
Cc: | added |
---|
comment:2 by , 9 years ago
I'm guessing wcst_import.sh specifies by default the tiling scheme domain, but not tile size?
comment:3 by , 9 years ago
WCSTImport supports any tiling that rasdaman supports, it basically sends the string mentioned in the tiling parameter directly to rasdaman. Usually the parameter is set to something like "ALIGNED [0:1000, 0:1000, 10]"
We can indicate to our users that they need to specify the tile size as well or any other option if we come to the conclusion that this is the expected behavior in rasdaman.
comment:4 by , 9 years ago
Best if it is "ALIGNED .. TILE SIZE 2097152" I guess.
I don't even get it where is the default 131072 coming from though (no references in the code), must be something dynamically calculated.
comment:5 by , 9 years ago
So the ingredients specify by default
"tiling": "ALIGNED [0:500, 0:500]"
I'd suggest to change it to
"tiling": "ALIGNED [0:1023, 0:1023] TILE SIZE 4194304"
comment:6 by , 9 years ago
I will do this as a first step to alleviate the problems. Thanks for investigating. I'm assuming no solution for 3D objects using ALIGNED tiling, right?
comment:7 by , 9 years ago
Yes, and I have to figure out where is the 131072 coming from.
Then I'll look at making it work right for 3D objects, but this will have to be similar to the regular tiling where the full tiles are initialized as soon as any pixel is touched.
comment:8 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I think this has nothing to do with dimension, but with the tile size. If it is not specified, by default it is
which takes precedence and restricts the tiling domain given. So for a 1000x1000x1 floating point array with default tile size we get this:
This tileSize is misleading, because it's not really size as in bytes, but number of cells covered by the domain.. as such we have no way to specify a default limit of 4MB for example that is independent of the cell type. We could set a default limit of
2^20
which would translate to 1MB tiles for char arrays, 2MB for short, 4MB for floats, etc.