Opened 9 years ago
Closed 5 years ago
#1101 closed defect (worksforme)
sdom reports bounds of physical tiles, rather than actual data bounds
Reported by: | Dimitar Misev | Owned by: | Dimitar Misev |
---|---|---|---|
Priority: | major | Milestone: | 10.0 |
Component: | qlparser | Version: | development |
Keywords: | Cc: | Vlad Merticariu, Alex Dumitru, Peter Baumann | |
Complexity: | Medium |
Description
It appears that the sdom function reports the bounds taken by tiles, irrelevant of whether they have real data, whereas it would be preferable if sdom reports only the domain that actual data covers.
This is a tough problem to solve however and requires either inspecting the tile contents, or recording some additional information at insert/update time. Neither option looks like a particularly good solution.
Change History (4)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
We could do a workaround in petascope (to ignore the actual sdom - number of coefficients sync check), but I am not in favor of it as this check makes sure you are given the exact slice you request.
What should petascope consider to be the actual cellDomain of the coverage (right now this is the sdom of the array) in this case? Does it still remain the sdom and we allow that to be gradually filled (i.e. if you define a tile containing 4 slices, should the coverage indicate that it contain 4 slices, even though 3 of them are filled with 0s)?
comment:3 by , 9 years ago
IMHO the exact domain is a contracted feature the database must maintain, even if it is additional effort (such as copying valid parts of a tile first when loading it). A petascope workaround is fine as an interim solution, but not as a final.
comment:4 by , 5 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I'm not very sure in what particular case is this actually a problem. Until a realistic issue comes up I'd close this ticket.
Is there any chance that this can be solved in petascope, where the issue is relevant for irregular timeseries?