| 30 | | **Analysis**: if we look at the [https://trac.osgeo.org/postgis/wiki/WKTRaster/RFC/RFC1_V0SerialFormat Raster specification], the pixeltype is a byte of which the 4 highest bits are flags and the lowest 4 bits are the real pixeltype, but the Django deserialization code only considers one bit-flag: |
| | 30 | **Analysis**: if we look at the [https://trac.osgeo.org/postgis/wiki/WKTRaster/RFC/RFC1_V0SerialFormat Raster specification], the pixeltype is a byte of which the 4 highest bits are flags and the lowest 4 bits are the real pixeltype. Quoting the specification: |
| | 31 | |
| | 32 | {{{ |
| | 33 | Pixel type and storage flag |
| | 34 | --------------------------- |
| | 35 | |
| | 36 | Pixel type specifies type of pixel values in a band. |
| | 37 | Storage flag specifies whether the band data is stored |
| | 38 | as part of the datum or is to be found on the server's |
| | 39 | filesytem. |
| | 40 | |
| | 41 | There are currently 11 supported pixel value types, so 4 |
| | 42 | bits are enough to account for all. We'll reserve |
| | 43 | the upper 4 bits for generic flags and define upmost as |
| | 44 | storage flag: |
| | 45 | |
| | 46 | #define BANDTYPE_FLAGS_MASK 0xF0 |
| | 47 | #define BANDTYPE_PIXTYPE_MASK 0x0F |
| | 48 | |
| | 49 | #define BANDTYPE_FLAG_OFFDB (1<<7) |
| | 50 | #define BANDTYPE_FLAG_HASNODATA (1<<6) |
| | 51 | #define BANDTYPE_FLAG_ISNODATA (1<<5) |
| | 52 | #define BANDTYPE_FLAG_RESERVED3 (1<<4) |
| | 53 | }}} |
| | 54 | |
| | 55 | However, Django deserialization code only considers a single flag (`BANDTYPE_FLAG_HASNODATA`, bit 6, value 64): |