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): |