[Git][debian-gis-team/rasterio][master] 4 commits: New upstream version 1.1.8
Bas Couwenberg
gitlab at salsa.debian.org
Wed Oct 21 05:22:08 BST 2020
Bas Couwenberg pushed to branch master at Debian GIS Project / rasterio
Commits:
aad9cd8d by Bas Couwenberg at 2020-10-21T05:53:26+02:00
New upstream version 1.1.8
- - - - -
0eea7f15 by Bas Couwenberg at 2020-10-21T05:54:00+02:00
Update upstream source from tag 'upstream/1.1.8'
Update to upstream version '1.1.8'
with Debian dir 11ab69b99864d0f52a4256821d802ee5115fbaac
- - - - -
fe58b3a1 by Bas Couwenberg at 2020-10-21T05:57:34+02:00
New upstream release.
- - - - -
7b135aa6 by Bas Couwenberg at 2020-10-21T05:59:07+02:00
Set distribution to unstable.
- - - - -
10 changed files:
- CHANGES.txt
- CONTRIBUTING.rst
- debian/changelog
- docs/topics/masks.rst
- docs/topics/memory-files.rst
- docs/topics/switch.rst
- rasterio/__init__.py
- rasterio/_warp.pyx
- rasterio/features.py
- tests/test_features.py
Changes:
=====================================
CHANGES.txt
=====================================
@@ -1,6 +1,15 @@
Changes
=======
+1.1.8 (2020-10-20)
+------------------
+
+- Multipolyons passed to rasterize are flattened to avoid holes in output
+ (#2014).
+- If the certifi package can be imported, its certificate store location will
+ be passed to GDAL during import of rasterio._env unless CURL_CA_BUNDLE is
+ already set (#2009).
+
1.1.7 (2020-09-29)
------------------
=====================================
CONTRIBUTING.rst
=====================================
@@ -97,7 +97,7 @@ Cython language is a superset of Python. Cython files end with ``.pyx`` and
Rasterio supports Python 2 and Python 3 in the same code base, which is
aided by an internal compatibility module named ``compat.py``. It functions
-similarly to the more widely known `six <https://pythonhosted.org/six/>`__ but
+similarly to the more widely known `six <https://six.readthedocs.io/>`__ but
we only use a small portion of the features so it eliminates a dependency.
We strongly prefer code adhering to `PEP8
=====================================
debian/changelog
=====================================
@@ -1,3 +1,10 @@
+rasterio (1.1.8-1) unstable; urgency=medium
+
+ * Team upload.
+ * New upstream release.
+
+ -- Bas Couwenberg <sebastic at debian.org> Wed, 21 Oct 2020 05:58:58 +0200
+
rasterio (1.1.7-1) unstable; urgency=medium
* Team upload.
=====================================
docs/topics/masks.rst
=====================================
@@ -18,7 +18,7 @@ Consider Rasterio's RGB.byte.tif test dataset. It has 718 rows and 791
columns of pixels. Each pixel has 3 8-bit (uint8) channels or bands. It has a
trapezoid of image data within a rectangular background of 0,0,0 value pixels.
-.. image:: https://www.dropbox.com/s/sg7qejccih5m4ah/RGB.byte.jpg?dl=1
+.. image:: ../img/RGB.byte.jpg
Metadata in the dataset declares that values of 0 will be interpreted as
invalid data or *nodata* pixels. In, e.g., merging the image with adjacent
=====================================
docs/topics/memory-files.rst
=====================================
@@ -79,7 +79,7 @@ Reading MemoryFiles
Like ``BytesIO``, ``MemoryFile`` implements the Python file protocol and
provides ``read()``, ``seek()``, and ``tell()`` methods. Instances are thus suitable
-as arguments for methods like `requests.post() <http://docs.python-requests.org/en/master/api/#requests.post>`__.
+as arguments for methods like `requests.post() <https://requests.readthedocs.io/en/latest/api/#requests.post>`__.
.. code-block:: python
=====================================
docs/topics/switch.rst
=====================================
@@ -296,7 +296,7 @@ metadata namespace is represented as a dict.
{'INTERLEAVE': 'PIXEL'}
The semantics of the tags in GDAL's default and ``IMAGE_STRUCTURE`` namespaces
-are described in http://www.gdal.org/gdal_datamodel.html. Rasterio uses
+are described in https://gdal.org/user/raster_data_model.html. Rasterio uses
several namespaces of its own: ``rio_creation_kwds`` and ``rio_overviews``,
each with their own semantics.
=====================================
rasterio/__init__.py
=====================================
@@ -41,7 +41,7 @@ import rasterio.enums
import rasterio.path
__all__ = ['band', 'open', 'pad', 'Env']
-__version__ = "1.1.7"
+__version__ = "1.1.8"
__gdal_version__ = gdal_version()
# Rasterio attaches NullHandler to the 'rasterio' logger and its
=====================================
rasterio/_warp.pyx
=====================================
@@ -135,7 +135,7 @@ cdef GDALWarpOptions * create_warp_options(
# get the defaults.
cdef char **warp_extras = psWOptions.papszWarpOptions
- # See http://www.gdal.org/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08
+ # See https://gdal.org/doxygen/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08
# for a list of supported options. Copying unsupported options
# is fine.
@@ -444,7 +444,7 @@ def _reproject(
cdef char **imgProjOptions = NULL
imgProjOptions = CSLSetNameValue(imgProjOptions, "GCPS_OK", "TRUE")
- # See http://www.gdal.org/gdal__alg_8h.html#a94cd172f78dbc41d6f407d662914f2e3
+ # See https://gdal.org/doxygen/gdal__alg_8h.html#a94cd172f78dbc41d6f407d662914f2e3
# for a list of supported options. I (Sean) don't see harm in
# copying all the function's keyword arguments to the image to
# image transformer options mapping; unsupported options should be
@@ -486,7 +486,7 @@ def _reproject(
if init_dest_nodata:
warp_extras = CSLSetNameValue(warp_extras, "INIT_DEST", "NO_DATA")
- # See http://www.gdal.org/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08
+ # See https://gdal.org/doxygen/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08
# for a list of supported options. Copying unsupported options
# is fine.
for key, val in kwargs.items():
@@ -696,7 +696,7 @@ cdef class WarpedVRTReaderBase(DatasetReaderBase):
The working data type for warp operation and output.
warp_extras : dict
GDAL extra warp options. See
- http://www.gdal.org/structGDALWarpOptions.html.
+ https://gdal.org/doxygen/structGDALWarpOptions.html.
Returns
-------
=====================================
rasterio/features.py
=====================================
@@ -295,7 +295,9 @@ def rasterize(
if is_valid_geom(geom):
shape_values.append(value)
- if geom['type'] == 'GeometryCollection':
+ geom_type = geom['type']
+
+ if geom_type == 'GeometryCollection':
# GeometryCollections need to be handled as individual parts to
# avoid holes in output:
# https://github.com/mapbox/rasterio/issues/1253.
@@ -304,6 +306,11 @@ def rasterize(
for part in geom['geometries']:
valid_shapes.append((part, value))
+ elif geom_type == 'MultiPolygon':
+ # Same issue as above
+ for poly in geom['coordinates']:
+ valid_shapes.append(({'type': 'Polygon', 'coordinates': poly}, value))
+
else:
valid_shapes.append((geom, value))
=====================================
tests/test_features.py
=====================================
@@ -490,6 +490,30 @@ def test_rasterize_geomcollection_no_hole():
)
+def test_rasterize_multipolygon_no_hole():
+ """
+ Make sure that bug reported in
+ https://github.com/mapbox/rasterio/issues/1253
+ does not recur. MultiPolygons are flattened to individual parts,
+ and should result in no holes where parts overlap.
+ """
+
+ poly1 = (((0, 0), (0, 5), (5, 5), (5, 0), (0, 0)),)
+ poly2 = (((2, 2), (2, 7), (7, 7), (7, 2), (2, 2)),)
+
+ polys = [{'type': 'Polygon', 'coordinates': poly1},
+ {'type': 'Polygon', 'coordinates': poly2}]
+
+ multipoly = {'type': 'MultiPolygon', 'coordinates': [poly1, poly2]}
+
+ expected = rasterize(polys, out_shape=DEFAULT_SHAPE)
+
+ assert np.array_equal(
+ rasterize([multipoly], out_shape=DEFAULT_SHAPE),
+ expected
+ )
+
+
@pytest.mark.parametrize("input", [
[{'type'}], [{'type': 'Invalid'}], [{'type': 'Point'}], [{'type': 'Point', 'coordinates': []}], [{'type': 'GeometryCollection', 'geometries': []}]])
def test_rasterize_invalid_geom(input):
View it on GitLab: https://salsa.debian.org/debian-gis-team/rasterio/-/compare/eadf201f67396c6b57291ef29f1437055157334a...7b135aa64e978263d685add219684b5fefd09513
--
View it on GitLab: https://salsa.debian.org/debian-gis-team/rasterio/-/compare/eadf201f67396c6b57291ef29f1437055157334a...7b135aa64e978263d685add219684b5fefd09513
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20201021/ad610be4/attachment-0001.html>
More information about the Pkg-grass-devel
mailing list