internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: rasterio/rasterio

Issue:
Check for "ndarray-like" instead of ndarray in _warp; other places
I want to use `rasterio.warp.reproject` on an `xray.Dataset` with `xray.Dataset.apply` (http://xray.readthedocs.org/en/stable/). xray has a feature to turn the dataset into a `np.ndarray`, but that means losing all my metadata.

At https://github.com/mapbox/rasterio/blob/master/rasterio/_warp.pyx#L249, _warp checks that the source is an `np.ndarray` (whereas the source in my case is an `xray.DataArray` - satisfying the same interfaces as `np.ndarray`), so I get an invalid source error.

It could be a good idea to check for something like

```
def is_ndarray_like(source):
    return hasattr(source, '__array__')
```

instead of

```
isinstance(source, np.ndarray)
```

so other numpy-like arrays can be used.



Discussion:
@raj-kesavan good suggestion; there are a number of places where were are checking if something is a numpy array or not.  Standardizing that would be a win.

I had not heard of xray before; I'm going to have to check it out because we do a lot with NetCDF files.

@sgillies if I can get something out tonight, any chance this can go into 0.26?


Resolving patch:
diff --git a/rasterio/dtypes.py b/rasterio/dtypes.py
--- a/rasterio/dtypes.py
+++ b/rasterio/dtypes.py
@@ -96,3 +96,9 @@ def get_minimum_int_dtype(values):
         return int16
     elif min_value >= -2147483648 and max_value <= 2147483647:
         return int32
+
+
+def is_ndarray(array):
+    import numpy
+
+    return isinstance(array, numpy.ndarray) or hasattr(array, '__array__')


Test patch:
diff --git a/tests/test_dtypes.py b/tests/test_dtypes.py
--- a/tests/test_dtypes.py
+++ b/tests/test_dtypes.py
@@ -1,14 +1,23 @@
 import numpy as np
 
-import rasterio.dtypes
+from rasterio import dtypes, ubyte
+
+
+def test_is_ndarray():
+    assert dtypes.is_ndarray(np.zeros((1,)))
+    assert dtypes.is_ndarray([0]) == False
+    assert dtypes.is_ndarray((0,)) == False
+
 
 def test_np_dt_uint8():
-    assert rasterio.dtypes.check_dtype(np.uint8)
+    assert dtypes.check_dtype(np.uint8)
+
 
 def test_dt_ubyte():
-    assert rasterio.dtypes.check_dtype(rasterio.ubyte)
+    assert dtypes.check_dtype(ubyte)
+
 
 def test_gdal_name():
-    assert rasterio.dtypes._gdal_typename(rasterio.ubyte) == 'Byte'
-    assert rasterio.dtypes._gdal_typename(np.uint8) == 'Byte'
-    assert rasterio.dtypes._gdal_typename(np.uint16) == 'UInt16'
+    assert dtypes._gdal_typename(ubyte) == 'Byte'
+    assert dtypes._gdal_typename(np.uint8) == 'Byte'
+    assert dtypes._gdal_typename(np.uint16) == 'UInt16'
Repository: rasterio/rasterio

Issue:
polygonize method no longer in use / use shapes instead?
Hi,

just going through the examples folders.
If I ran the python interpreter on  `poligonize.py` it complains about a missing attribute:

```
(venv)[] ~/Progetti/pyhton-usergroup/rasterio <master> ✗ python examples/polygonize.py
sys:1: FutureWarning: read_band() is deprecated and will be removed by Rasterio 1.0. Please use read() instead.
Traceback (most recent call last):
  File "examples/polygonize.py", line 10, in <module>
    list(ftrz.polygonize(image)))
AttributeError: 'module' object has no attribute 'polygonize'
```

But, going trough the commits history w/ @ligthyear it seems like instead of poligonize, one should use shapes.  
If I ran it in fact with the new method it works smoothly

```
pprint.pprint(
 list(ftrz.shapes(image)))
```

Cheers



Discussion:

Resolving patch:
diff --git a/examples/polygonize.py b/examples/polygonize.py
--- a/examples/polygonize.py
+++ b/examples/polygonize.py
@@ -1,10 +1,12 @@
 import pprint
 
 import rasterio
-import rasterio._features as ftrz
+from rasterio.features import shapes
 
-with rasterio.open('box.png') as src:
-    image = src.read_band(1)
+with rasterio.open('tests/data/shade.tif') as src:
+    image = src.read(1)
 
+# Print the first two shapes...
 pprint.pprint(
-    list(ftrz.polygonize(image)))
+    list(shapes(image))[:2]
+)


Test patch:
Repository: rasterio/rasterio

Issue:
rio-shapes ids are not unique
This leads to problems downstream.



Discussion:

Resolving patch:
diff --git a/rasterio/rio/features.py b/rasterio/rio/features.py
--- a/rasterio/rio/features.py
+++ b/rasterio/rio/features.py
@@ -330,8 +330,11 @@ def __call__(self):
                 if not with_nodata:
                     kwargs['mask'] = msk
 
+                src_basename = os.path.basename(src.name)
+
                 # Yield GeoJSON features.
-                for g, i in rasterio.features.shapes(img, **kwargs):
+                for i, (g, val) in enumerate(
+                        rasterio.features.shapes(img, **kwargs)):
                     if projection == 'geographic':
                         g = rasterio.warp.transform_geom(
                             src.crs, 'EPSG:4326', g,
@@ -339,9 +342,9 @@ def __call__(self):
                     xs, ys = zip(*coords(g))
                     yield {
                         'type': 'Feature',
-                        'id': str(i),
+                        'id': "{0}:{1}".format(src_basename, i),
                         'properties': {
-                            'val': i, 'filename': os.path.basename(src.name)
+                            'val': val, 'filename': src_basename
                         },
                         'bbox': [min(xs), min(ys), max(xs), max(ys)],
                         'geometry': g


Test patch:
Repository: rasterio/rasterio

Issue:
rio merge error
When running `rio merge` on the latest version (`0.27`), I am receiving this error:

```
Traceback (most recent call last):
  File "/Users/dnomadb/venv/bin/rio", line 11, in <module>
    sys.exit(main_group())
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/click/core.py", line 700, in __call__
    return self.main(*args, **kwargs)
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/click/core.py", line 680, in main
    rv = self.invoke(ctx)
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/click/core.py", line 1027, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/click/core.py", line 873, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/click/core.py", line 508, in invoke
    return callback(*args, **kwargs)
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/click/decorators.py", line 16, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/Users/dnomadb/venv/lib/python2.7/site-packages/rasterio/rio/merge.py", line 54, in merge
    from rasterio.tools.merge import merge as merge_tool
ImportError: No module named tools.merge
```

When reverting back to `0.26`, I don't see it and the operation completes as expected.

cc @sgillies 



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -227,7 +227,7 @@ def copy_data_tree(datadir, destdir):
     url='https://github.com/mapbox/rasterio',
     license='BSD',
     package_dir={'': '.'},
-    packages=['rasterio', 'rasterio.rio'],
+    packages=['rasterio', 'rasterio.rio', 'rasterio.tools'],
     entry_points='''
         [console_scripts]
         rio=rasterio.rio.main:main_group


Test patch:
Repository: rasterio/rasterio

Issue:
Add test coverage for Cython modules
Right now, we are not getting coverage of Cython modules from our test suite.  This would be good to do, especially if it is [pretty straightforward](http://blog.behnel.de/posts/coverage-analysis-for-cython-modules.html).

I'll look into this for #496



Discussion:
I think I've just about got this working.  However, it requires upgrading Cython to 0.23.4 and pytest-cov to 2.2.0

@sgillies Any issues with upping those versions in `requirements-dev.txt`?  Tests are all passing fine for me on Cython 0.23.4.

@brendan-ward None. Please do.


Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -19,12 +19,10 @@
 from setuptools import setup
 from setuptools.extension import Extension
 
+
 logging.basicConfig()
 log = logging.getLogger()
 
-# python -W all setup.py ...
-if 'all' in sys.warnoptions:
-    log.level = logging.DEBUG
 
 def check_output(cmd):
     # since subprocess.check_output doesn't exist in 2.6
@@ -39,6 +37,7 @@ def check_output(cmd):
         out, err = p.communicate()
         return out
 
+
 def copy_data_tree(datadir, destdir):
     try:
         shutil.rmtree(destdir)
@@ -46,6 +45,11 @@ def copy_data_tree(datadir, destdir):
         pass
     shutil.copytree(datadir, destdir)
 
+
+# python -W all setup.py ...
+if 'all' in sys.warnoptions:
+    log.level = logging.DEBUG
+
 # Parse the version from the rasterio module.
 with open('rasterio/__init__.py') as f:
     for line in f:
@@ -135,6 +139,13 @@ def copy_data_tree(datadir, destdir):
     ext_options['extra_compile_args'] = ['-Wno-unused-parameter',
                                          '-Wno-unused-function']
 
+cythonize_options = {}
+if os.environ.get('CYTHON_COVERAGE'):
+    cythonize_options['compiler_directives'] = {'linetrace': True}
+    cythonize_options['annotate'] = True
+    ext_options['define_macros'] = [('CYTHON_TRACE', '1'),
+                                    ('CYTHON_TRACE_NOGIL', '1')]
+
 log.debug('ext_options:\n%s', pprint.pformat(ext_options))
 
 # When building from a repo, Cython is required.
@@ -164,7 +175,7 @@ def copy_data_tree(datadir, destdir):
             'rasterio._err', ['rasterio/_err.pyx'], **ext_options),
         Extension(
             'rasterio._example', ['rasterio/_example.pyx'], **ext_options),
-        ], quiet=True)
+        ], quiet=True, **cythonize_options)
 
 # If there's no manifest template, as in an sdist, we just specify .c files.
 else:


Test patch:
Repository: rasterio/rasterio

Issue:
rio warp null transformer error with bad proj4
Currently, if you pass a bad projection, you get the following behavior:

```
$ rio warp --dst-crs "+proj=foobar" tests/data/warp_test.tif /tmp/foo.tif
ERROR:GDAL:CPLE_NotSupported in Failed to initialize PROJ.4 with `+proj=foobar +wktext'.
Traceback (most recent call last):
...
  File "/Users/mperry/work/rasterio/rasterio/rio/warp.py", line 198, in warp
    resolution=res)
  File "/Users/mperry/work/rasterio/rasterio/warp.py", line 296, in calculate_default_transform
    left, bottom, right, top)
  File "rasterio/_warp.pyx", line 535, in rasterio._warp._calculate_default_transform (rasterio/_warp.cpp:9551)
    with InMemoryRaster(
  File "rasterio/_warp.pyx", line 542, in rasterio._warp._calculate_default_transform (rasterio/_warp.cpp:9261)
    raise ValueError("NULL transformer")
ValueError: NULL transformer
```

The transformer fails to initialize, which is reasonable considering the invalid proj string. Is there any way to catch that error and report back something more meaningful than "NULL transformer"?



Discussion:

Resolving patch:
diff --git a/rasterio/errors.py b/rasterio/errors.py
--- a/rasterio/errors.py
+++ b/rasterio/errors.py
@@ -7,7 +7,7 @@ class RasterioIOError(IOError):
     """A failure to open a dataset using the presently registered drivers."""
 
 
-class RasterioDriverRegistrationError(ValueError):
+class DriverRegistrationError(ValueError):
     """To be raised when, eg, _gdal.GDALGetDriverByName("MEM") returns NULL."""
 
 


Test patch:
diff --git a/tests/test_warp_transform.py b/tests/test_warp_transform.py
--- a/tests/test_warp_transform.py
+++ b/tests/test_warp_transform.py
@@ -3,7 +3,7 @@
 from rasterio.transform import Affine, from_bounds
 
 
-def test_indentity():
+def test_identity():
     """Get the same transform and dimensions back for same crs."""
     # Tile: [53, 96, 8]
     # [-11740727.544603072, 4852834.0517692715, -11584184.510675032, 5009377.085697309]
@@ -36,3 +36,28 @@ def test_gdal_transform_notnull():
             right=-80,
             top=70)
     assert True
+
+
+def test_gdal_transform_fail_dst_crs():
+    with rasterio.drivers():
+        dt, dw, dh = _calculate_default_transform(
+            {'init': 'EPSG:4326'},
+            '+proj=foobar',
+            width=80,
+            height=80,
+            left=-120,
+            bottom=30,
+            right=-80,
+            top=70)
+
+def test_gdal_transform_fail_src_crs():
+    with rasterio.drivers():
+        dt, dw, dh = _calculate_default_transform(
+            '+proj=foobar',
+            {'init': 'EPSG:32610'},
+            width=80,
+            height=80,
+            left=-120,
+            bottom=30,
+            right=-80,
+            top=70)
Repository: rasterio/rasterio

Issue:
Skip local rasterfill.cpp for GDAL >= 2.0
Our local rasterfill.cpp (see #253) is in GDAL 2.+: https://github.com/OSGeo/gdal/pull/47.



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -74,7 +74,8 @@ def copy_data_tree(datadir, destdir):
 library_dirs = []
 libraries = []
 extra_link_args = []
-gdal_output = [None]*3
+gdal2plus = False
+gdal_output = [None]*4
 
 try:
     import numpy
@@ -85,7 +86,7 @@ def copy_data_tree(datadir, destdir):
 
 try:
     gdal_config = os.environ.get('GDAL_CONFIG', 'gdal-config')
-    for i, flag in enumerate(("--cflags", "--libs", "--datadir")):
+    for i, flag in enumerate(("--cflags", "--libs", "--datadir", "--version")):
         gdal_output[i] = check_output([gdal_config, flag]).strip()
 
     for item in gdal_output[0].split():
@@ -99,6 +100,9 @@ def copy_data_tree(datadir, destdir):
         else:
             # e.g. -framework GDAL
             extra_link_args.append(item)
+    # datadir, gdal_output[2] handled below
+    for item in gdal_output[3].split():
+        gdal2plus = not item.startswith("1.")
 
 except Exception as e:
     if os.name == "nt":
@@ -148,6 +152,14 @@ def copy_data_tree(datadir, destdir):
 
 log.debug('ext_options:\n%s', pprint.pformat(ext_options))
 
+if gdal2plus:
+    # GDAL>=2.0 does not require vendorized rasterfill.cpp
+    cython_fill = ['rasterio/_fill.pyx']
+    sdist_fill = ['rasterio/_fill.cpp']
+else:
+    cython_fill = ['rasterio/_fill.pyx', 'rasterio/rasterfill.cpp']
+    sdist_fill = ['rasterio/_fill.cpp', 'rasterio/rasterfill.cpp']
+
 # When building from a repo, Cython is required.
 if os.path.exists("MANIFEST.in") and "clean" not in sys.argv:
     log.info("MANIFEST.in found, presume a repo, cythonizing...")
@@ -170,7 +182,7 @@ def copy_data_tree(datadir, destdir):
         Extension(
             'rasterio._warp', ['rasterio/_warp.pyx'], **ext_options),
         Extension(
-            'rasterio._fill', ['rasterio/_fill.pyx', 'rasterio/rasterfill.cpp'], **ext_options),
+            'rasterio._fill', cython_fill, **ext_options),
         Extension(
             'rasterio._err', ['rasterio/_err.pyx'], **ext_options),
         Extension(
@@ -193,12 +205,11 @@ def copy_data_tree(datadir, destdir):
         Extension(
             'rasterio._warp', ['rasterio/_warp.cpp'], **ext_options),
         Extension(
-            'rasterio._fill', ['rasterio/_fill.cpp', 'rasterio/rasterfill.cpp'], **ext_options),
+            'rasterio._fill', sdist_fill, **ext_options),
         Extension(
             'rasterio._err', ['rasterio/_err.c'], **ext_options),
         Extension(
-            'rasterio._example', ['rasterio/_example.c'], **ext_options),
-            ]
+            'rasterio._example', ['rasterio/_example.c'], **ext_options)]
 
 with open('README.rst') as f:
     readme = f.read()


Test patch:
Repository: rasterio/rasterio

Issue:
rio stack output empty
`rio stack`ing one or more rasters without an explicit band index results in a raster with all nulls

```
$ rio info --tell-me-more tests/data/RGB.byte.tif | jq .stats[0].max
255
$ rio stack tests/data/RGB.byte.tif /tmp/test.tif && \
  rio info --tell-me-more /tmp/test.tif | jq .stats[0].max
null
```



Discussion:

Resolving patch:
diff --git a/rasterio/rio/stack.py b/rasterio/rio/stack.py
--- a/rasterio/rio/stack.py
+++ b/rasterio/rio/stack.py
@@ -1,4 +1,5 @@
 """Commands for operating on bands of datasets."""
+import collections
 import logging
 
 import click
@@ -105,7 +106,7 @@ def stack(ctx, files, output, driver, bidx, photometric, force_overwrite,
                             data = src.read(index)
                             dst.write(data, dst_idx)
                             dst_idx += 1
-                        elif isinstance(index, list):
+                        elif isinstance(index, collections.Iterable):
                             data = src.read(index)
                             dst.write(data, range(dst_idx, dst_idx+len(index)))
                             dst_idx += len(index)


Test patch:
diff --git a/tests/test_rio_stack.py b/tests/test_rio_stack.py
--- a/tests/test_rio_stack.py
+++ b/tests/test_rio_stack.py
@@ -14,6 +14,7 @@ def test_stack(tmpdir):
     assert result.exit_code == 0
     with rasterio.open(outputname) as out:
         assert out.count == 3
+        assert out.read(1).max() > 0
 
 
 def test_stack_list(tmpdir):
Repository: rasterio/rasterio

Issue:
rio warp --like does not consider dtype
The rio warp help text says

```
  --like PATH                     Raster dataset to use as a template for
                                  obtaining affine transform (bounds and
                                  resolution), crs, data type, and driver used
                                  to create the output.
```

But the data type does not appear to be affected. 

```
$ rio info data1.l3a.vnir1.tif | jq .dtype
"uint8"
$ rio info data1.l3a.tir10.tif | jq .dtype
"uint16"
$ rio warp data1.l3a.tir10.tif /tmp/out.tif --like data1.l3a.vnir1.tif
$ rio info /tmp/out.tif | jq .dtype  # dtype is not "like" vnir1, should be uint8
"uint16"
```

This might just be a simple matter of changing the help text to reflect the actual behavior. Or it could be considered a bug. Not sure.



Discussion:
Or perhaps more likely, we are reusing an option that does handle `dtype` in other usages: https://github.com/mapbox/rasterio/blob/master/rasterio/rio/rasterize.py#L32

I think this was the original place we used `--like`.

Cool, so we bring warp up to par with rasterize.

rio warp is slightly different that rasterize. With rasterize, we can safely create a new raster of any dtype. 

But warping an existing raster from one dtype to another involves some care and possibly decisions around rescaling data that are somewhat orthogonal to warping. IOW I don't think we necessarily want `rio warp` to change the dtype.

@perrygeo Agreed.  How about we create another `--like` option that does everything the other one does, except for dtype?


Resolving patch:
diff --git a/rasterio/rio/warp.py b/rasterio/rio/warp.py
--- a/rasterio/rio/warp.py
+++ b/rasterio/rio/warp.py
@@ -48,7 +48,11 @@ def x_dst_bounds_handler(ctx, param, value):
 @files_inout_arg
 @options.output_opt
 @format_opt
-@options.like_file_opt
+@click.option(
+    '--like',
+    type=click.Path(exists=True),
+    help='Raster dataset to use as a template for obtaining affine '
+         'transform (bounds and resolution), and crs.')
 @click.option('--dst-crs', default=None,
               help='Target coordinate reference system.')
 @options.dimensions_opt


Test patch:
Repository: rasterio/rasterio

Issue:
-f does not work as expected in rio-warp
Running on a preexisting file

```
» rio warp tests/data/RGB.byte.tif /tmp/hi.tif
Error: Could not open file : file exists and won't be overwritten without use of the `-f` or `-o` options.
```

Then

```
» rio warp tests/data/RGB.byte.tif /tmp/hi.tif -f
Error: -f option requires an argument
```

But

```
rio warp tests/data/RGB.byte.tif /tmp/hi.tif --force-overwrite
```

Works.



Discussion:

Resolving patch:
diff --git a/rasterio/rio/helpers.py b/rasterio/rio/helpers.py
--- a/rasterio/rio/helpers.py
+++ b/rasterio/rio/helpers.py
@@ -88,7 +88,7 @@ def resolve_inout(input=None, output=None, files=None, force_overwrite=False):
             resolved_output):
         raise FileOverwriteError(
             "file exists and won't be overwritten without use of the "
-            "`-f` or `-o` options.")
+            "`--force-overwrite` or `--output` options.")
     resolved_inputs = (
         [input] if input else [] +
         list(files[:-1 if not output else None]) if files else [])


Test patch:
Repository: rasterio/rasterio

Issue:
Copy colormap when rasters are merged
I'm running `rio merge` over a few single band images that contain a colormap. During the merge, the colormap is not copied to the new raster. Can we modify `rio merge` to preserve the colormap?

I have an initial pass of this change at:

https://github.com/kapadia/rasterio/tree/rio-merge-colormap



Discussion:

Resolving patch:
diff --git a/rasterio/rio/merge.py b/rasterio/rio/merge.py
--- a/rasterio/rio/merge.py
+++ b/rasterio/rio/merge.py
@@ -67,3 +67,10 @@ def merge(ctx, files, output, driver, bounds, res, nodata, force_overwrite,
 
         with rasterio.open(output, 'w', **profile) as dst:
             dst.write(dest)
+
+            # uses the colormap in the first input raster.
+            try:
+                colormap = sources[0].colormap(1)
+                dst.write_colormap(1, colormap)
+            except ValueError:
+                pass


Test patch:
diff --git a/tests/test_rio_merge.py b/tests/test_rio_merge.py
--- a/tests/test_rio_merge.py
+++ b/tests/test_rio_merge.py
@@ -67,6 +67,26 @@ def test_data_dir_2(tmpdir):
     return tmpdir
 
 
+def test_merge_with_colormap(test_data_dir_1):
+    outputname = str(test_data_dir_1.join('merged.tif'))
+    inputs = [str(x) for x in test_data_dir_1.listdir()]
+    inputs.sort()
+
+    # Add a colormap to the first input prior merge
+    with rasterio.open(inputs[0], 'r+') as src:
+        src.write_colormap(1, {0: (255, 0, 0, 255), 255: (0, 0, 0, 0)})
+
+    runner = CliRunner()
+    result = runner.invoke(merge, inputs + [outputname])
+    assert result.exit_code == 0
+    assert os.path.exists(outputname)
+
+    with rasterio.open(outputname) as out:
+        cmap = out.colormap(1)
+        assert cmap[0] == (255, 0, 0, 255)
+        assert cmap[255] == (0, 0, 0, 255)
+
+
 def test_merge_with_nodata(test_data_dir_1):
     outputname = str(test_data_dir_1.join('merged.tif'))
     inputs = [str(x) for x in test_data_dir_1.listdir()]
Repository: rasterio/rasterio

Issue:
Use .dev versioning, pre-releases
With the 1.0 release coming and likely a few PRs with breaking changes, it would be helpful to start doing dev releases so we can maximize the number of eyes.

**Proposal**: Change version to `1.0.dev1` now, as we make changes, cut pre-release wheels and distribute them via on pypi.

We'll also likely want to do a legit `alpha`, `beta`, `rc`, `final` cycle for the 1.0 release.

@sgillies @geowurster @brendan-ward sound good?



Discussion:
Some coordination w/ Christof Grohlke for the [Python Windows Packages](http://www.lfd.uci.edu/~gohlke/pythonlibs/) will likely be necessary to make sure that we are selective about the versions that get pushed out there.  Typically there is just one version available, and we may want to avoid pushing versions w/ breaking API changes until we are solid on those.

If we did it right, they would be treated as [pre-releases](https://packaging.python.org/en/latest/installing/#installing-prereleases) so that you'd have to explictly type `--pre` to get them. Everyone else would get `0.36` until 1.0 was released

@perrygeo Definitely sounds like a good idea, especially for 1.0.


Resolving patch:
diff --git a/rasterio/__init__.py b/rasterio/__init__.py
--- a/rasterio/__init__.py
+++ b/rasterio/__init__.py
@@ -32,7 +32,7 @@ def emit(self, record):
 
 __all__ = [
     'band', 'open', 'copy', 'pad']
-__version__ = "0.36.0"
+__version__ = "1.0.dev1"
 __gdal_version__ = gdal_version()
 
 # Rasterio attaches NullHandler to the 'rasterio' logger and its


Test patch: