bump build number

[ocefpaf]

Test the Windows failures.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ocefpaf]

The 23 failing tests on Windows and gdal 3.0 are:

test_empty_crs_str
test_clip_bounds_geographic
test_info_lnglat
test_mo_info
test_transform_point
test_transform_point_dst_file
test_transform_point_src_file
test_transform_point_2
test_transform_point_multi
test_bounds_obj_bbox
test_bounds_compact
test_bounds_seq
test_bounds_seq_rs
test_warp_reproject_dimensions
test_warp_reproject_src_bounds_res
test_warp_reproject_src_bounds_dimensions
test_transform
test_transform_bounds
test_transform_bounds__esri_wkt
test_transform_bounds_densify
test_transform_geom_polygon_cutting
test_transform_geom_polygon_offset
test_issue_1446

@sgillies is rasterio tested on Windows upstream? If so do you have any clue for us on what may be the differences between our gdal 3.0 and yours?

[ocefpaf]

B/c Azure Pipelines delete the logs here are the full log with all the error on Windows and gdal 3.0 for future reference:

164.txt

[snowman2]

I wonder if this is related? rasterio/rasterio#1787

[ocefpaf]

I wonder if this is related? mapbox/rasterio#1787

The errors I'm investigating here are Windows only. We can add your test case to this PR and investigate it during the build but I disagree with rasterio/rasterio#1787 (comment), you got the right set of packages and it was built with gdal 3.

[snowman2]

I disagree with mapbox/rasterio#1787 (comment), you got the right set of packages and it was built with gdal 3.

Needs more investigation for sure.

[ocefpaf]

Needs more investigation for sure.

Just did,

conda create --name TEST rasterio libgdal=3 proj4

to get proj4 6.1.1 and libgdal 3.0.1, got:

libgdal                   3.0.1                hf47eb90_8    conda-forge
proj4                     6.1.1                hc80f0dc_1    conda-forge

and I was able to run

>>> import rasterio
>>> from rasterio.crs import CRS
>>> 
>>> cc = CRS.from_epsg(6933)
>>> 
>>> import rasterio
>>> from rasterio.crs import CRS
>>> 
>>> with rasterio.Env():
...     cc = CRS.from_epsg(6933)

without gcs.csv :-/

[snowman2]

Same for me:

$ rio --version
1.0.28
$ rio --gdal-version
3.0.1
$ python
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 21:52:21) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from rasterio.crs import CRS
>>> cc = CRS.from_epsg(6933)
>>> cc
CRS.from_epsg(6933)

[snowman2]

Wonder if a recent rebuild of GDAL fixed it? I cannot reproduce the issue anymore.

[ocefpaf]

Wonder if a recent rebuild of GDAL fixed it? I cannot reproduce the issue anymore.

Could be. Or even a conda update and how it handles the env variable.

[snowman2]

Could be. Or even a conda update and how it handles the env variable.

Maybe. But the env var was fine on the version with the issue.

[ocefpaf]

Could be. Or even a conda update and how it handles the env variable.

Maybe. But the env var was fine on the version with the issue.

Indeed. But the gdal build is also the same in my test.