Opened 9 years ago
Closed 9 years ago
#980 closed enhancement (fixed)
Change default data type for coverages to Float32
Reported by: | Vlad Merticariu | Owned by: | Vlad Merticariu |
---|---|---|---|
Priority: | major | Milestone: | 9.1.x |
Component: | petascope | Version: | development |
Keywords: | Cc: | Peter Baumann | |
Complexity: | Medium |
Description
When a coverage is inserted through WCS-T, with the values being given as tuple list (not from file), and the pixel data type is not specified, a default must be assumed. Until now the default has been Byte, which doesn't catch so many cases.
I'm changing the default to be Float32.
Change History (4)
comment:1 by , 9 years ago
Cc: | added |
---|---|
Milestone: | → 9.1.x |
comment:2 by , 9 years ago
The WCS-T standard doesn't specify what should be default, it's up to the server to decide.
In rasdaman, what happens is:
- if the coverage data is given as file (e.g. as a tif), the data type is read from the file. This happens in most cases.
- else the coverage data is given as tuple list (happens rarely, only suitable for small data). In this case the data type can be specified with a request parameter (pixelDataType). In case this parameter is not given, a default must be used (this is the corner case covered in this ticket).
comment:3 by , 9 years ago
in theory, the server should deduce the type from rangeType. But this will not always be unambiguous, as SWE folks don't mandate classical datatypes. So we need to do some "informed guessing" (with a catchall default of floats), and that's exactly what you do AFAICS. Don't know how we could do better - and it should work I believe.
comment:4 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
So the data type is optional? And the WCS-T standard doesn't specify what should be default? Sounds dangerous if both are true.