When the data type is Byte, instead of reading a first time
the red band to deduce the value of the alpha component of
the output image, read the RGB bands first.
avoiding one std::vector memory allocation - NOTE: this works because coordinates are stored in Double: Signed 64-bit IEEE double-precision floating point number (8 bytes) with little endian byte order - ref #2151
between inner and outter rings (Polygon/NultiPolygon) -- ref #2151https://github.com/mapbox/unpacker/issues/324
```txt
A polygon consists of one or more rings. A ring is a connected sequence of four or more
points that form a closed, non-self-intersecting loop. A polygon may contain multiple
outer rings. The order of vertices or orientation for a ring indicates which side of the ring
is the interior of the polygon. The neighborhood to the right of an observer walking along
the ring in vertex order is the neighborhood inside the polygon. Vertices of rings defining
holes in polygons are in a counterclockwise direction. Vertices for a single, ringed
polygon are, therefore, always in clockwise order. The rings of a polygon are referred to
as its parts.
```
refs #2551
Postgis raster_columns view is returning NULL values for raster
overviews with large scale factors. That issue in postgis is described
in http://trac.osgeo.org/postgis/ticket/3006
This causes two main problems:
- The first overview with scale = NULL is wrongly chosen for rendering
always
- The messed up scaling factor causes the render symbolizer to spent
an insane amount of CPU and memory to render a messed up tiles.
The patch in postgis is expected to be released with the new version, a
few months from now.
Conflicts:
plugins/input/pgraster/pgraster_datasource.cpp
refs #2551
Postgis raster_columns view is returning NULL values for raster
overviews with large scale factors. That issue in postgis is described
in http://trac.osgeo.org/postgis/ticket/3006
This causes two main problems:
- The first overview with scale = NULL is wrongly chosen for rendering
always
- The messed up scaling factor causes the render symbolizer to spent
an insane amount of CPU and memory to render a messed up tiles.
The patch in postgis is expected to be released with the new version, a
few months from now.
Conflicts:
plugins/input/pgraster/pgraster_datasource.cpp
image_data_32 -> image_data_rgba8
image_data_8 -> image_data_gray8
image_data_16 -> image_data_gray16
image_data_float32 -> image_data_gray32f
NOTE: currently image_data_gray16::pixel_type = std::int16_t (signed 16 bit int) to match GDAL
should we support unsigned types?
