Date   
Implementing -scale functionality of gdal_translate

linden.kyle@...
 

Is there any way to replicate the -scale functionality of gdal_translate in Rasterio to scale the input pixels of a geotiff to a different range?

Re: Implementing -scale functionality of gdal_translate

Sean Gillies
 

Hi,

Rasterio's rio-convert program can linearly scale pixels and apply offsets:

$ rio convert --help
Usage: rio convert [OPTIONS] INPUTS... OUTPUT

  Copy and convert raster datasets to other data types and formats.

  Data values may be linearly scaled when copying by using the --scale-ratio
  and --scale-offset options. Destination raster values are calculated as

    dst = scale_ratio * src + scale_offset

  For example, to scale uint16 data with an actual range of 0-4095 to 0-255
  as uint8:

    $ rio convert in16.tif out8.tif --dtype uint8 --scale-ratio 0.0625

  Format specific creation options may also be passed using --co. To tile a
  new GeoTIFF output file, do the following.

    --co tiled=true --co blockxsize=256 --co blockysize=256

  To compress it using the LZW method, add

    --co compress=LZW

Options:
  -o, --output PATH               Path to output file (optional alternative to
                                  a positional arg).
  -f, --format, --driver TEXT     Output format driver
  -t, --dtype [ubyte|uint8|uint16|int16|uint32|int32|float32|float64]
                                  Output data type.
  --scale-ratio FLOAT             Source to destination scaling ratio.
  --scale-offset FLOAT            Source to destination scaling offset.
  --rgb                           Set RGB photometric interpretation.
  --co, --profile NAME=VALUE      Driver specific creation options.See the
                                  documentation for the selected output driver
                                  for more information.
  --help                          Show this message and exit.

Different forms of scaling are possible if you use the Python API, numpy, and scikit-image.

Hope this helps,

On Fri, Jan 25, 2019 at 10:44 AM <linden.kyle@...> wrote:
Is there any way to replicate the -scale functionality of gdal_translate in Rasterio to scale the input pixels of a geotiff to a different range?



--
Sean Gillies

Re: Implementing -scale functionality of gdal_translate

linden.kyle@...
 

Thanks, Sean. I apologize for not clarifying this, but even though I referenced the gdal translate tool I was looking to do this through the Rasterio API. I was able to take a look at the code for rio convert, and I think I'll be able to figure it out from there.

Rasterio 1.0.14

Sean Gillies
 

Hi all,

Rasterio 1.0.14 is on PyPI now: https://pypi.org/project/rasterio/1.0.14/.

The changes are listed here: https://github.com/mapbox/rasterio/blob/master/CHANGES.txt#L4-L17. We've attempted to overhaul and improve the CRS class without breaking anything, Let me know if we've succeeded.

There are a couple changes in the OS X and Linux wheels. We now include GDAL 2.4.0 (skipping over 2.3.3) and have added HTTP/2 support.

--
Sean Gillies

Re: Rasterio 1.0.14

Madhav Desetty
 

Wow! This is awesome! I made similar changes to add GS support locally. I will pull 1.0.14 and see if all GCS related workflow works as expected in my Kubernetes cluster.

Thanks!

Madhav

Rasterio and pip 19

Sean Gillies
 

Hi all,

I was tripped up by the release of pip 19 and want to share what I learned so that you can avoid the same bruises.

Rasterio has a pyproject.toml file since version 1.0. This file specifies the build requirements of Rasterio, the packages you must have to build working modules from the source. These include Cython, because Rasterio is largely written in the Cython language, and Numpy, because Cython needs Numpy's C headers.

When pip 10 was released, it began to use this pyproject.toml file and you may have noticed that the old two-step build of Rasterio

  pip install numpy cython
  pip install --no-binary rasterio rasterio

wasn't necessary anymore. Pip would check the pyproject.toml file and install numpy and cython before moving on to Rasterio's own setup script. Note well that pip 10 would install numpy and cython into the site-packages folder of the currently active Python environment. Pip 19 changes this.

With pip 19, the default is to create a new temporary environment and install numpy and cython into it. And because I didn't specify versions in pyproject.toml, this means the latest numpy (1.16.0 as I type this). Extension modules compiled using the 1.16.0 headers aren't compatible with older versions of numpy. Importing them will result in a ValueError and a message about mismatched struct sizes.

In Rasterio's wheel-building system we have a different way of satisfying the build-time dependencies, but the new temporary environment snuck in, entailed a dependency on numpy 1.16.0 and then when we tested the wheels with versions of numpy that *should* have been compatible, we had failed tests. It was rather perplexing until I reminded myself to check the pip change log. The problem was easy enough to solve: we use the --no-build-isolation option of pip install and our builds go on as they did with earlier pip versions.

You'll see the same thing if you build wheels for production and then try to use them with an older version of numpy.

I'm hesitant to pin numpy in pyproject.toml because the right version sort of depends on your Python version. However, there's a potential stumbling block here that needs to be addressed. If anybody has more experience and wisdom to share about the new features of pip, I'm all ears.

--
Sean Gillies

Re: Rasterio and pip 19

Joris Van den Bossche
 

Op vr 25 jan. 2019 om 22:45 schreef Sean Gillies via Groups.Io <sean=mapbox.com@groups.io>:
I'm hesitant to pin numpy in pyproject.toml because the right version sort of depends on your Python version. However, there's a potential stumbling block here that needs to be addressed. If anybody has more experience and wisdom to share about the new features of pip, I'm all ears.

You can (nowadays) specify the numpy version depending on the python version in pyproject.toml, which should make this possible. Something like:
    "numpy==1.8.2; python_version<='3.4'",
    "numpy==1.9.3; python_version=='3.5'",
    "numpy==1.12.1; python_version=='3.6'",
    "numpy==1.13.1; python_version>='3.7'",
In principle we should always pin the numpy version to the oldest supported version (if using build isolation), as otherwise using the built package in an environment with another numpy version breaks, as you explained.

Last year, we added a pyproject.toml to pandas, but it gave a lot of problems (https://github.com/pandas-dev/pandas/issues/20775), related to the fact that the above python-dependent numpy version was not possible yet (environment markers in pyproject.toml files were not yet supported at that time) + build dependencies needed to be installed as wheels instead of from source (which can give problems on certain platforms for which there are no wheels; this is also fixed in the meantime in pip I think). So in the end we decided to remove it again for the next release.
But it seems we should maybe look into adding it again.

Joris

 

Re: Rasterio 1.0.14

Madhav Desetty
 

I setup rasterio 1.0.14 and try to do a rasterio.open with gs:// url and I get following error. I did set GOOGLE_APPLICATION_CREDENTIALS to json key file. What am I missing?

>>> import rasterio
>>> import rasterio as rio
>>> fp = rio.open("gs://pdd-stac/disasters/hurricane-harvey/0831/20170831_172754_101c_3b_Visual.tif")
Traceback (most recent call last):
  File "rasterio/_base.pyx", line 198, in rasterio._base.DatasetBase.__init__
  File "rasterio/_shim.pyx", line 64, in rasterio._shim.open_dataset
  File "rasterio/_err.pyx", line 205, in rasterio._err.exc_wrap_pointer
rasterio._err.CPLE_OpenFailedError: gs://pdd-stac/disasters/hurricane-harvey/0831/20170831_172754_101c_3b_Visual.tif: No such file or directory
 
During handling of the above exception, another exception occurred:
 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/madhavdesetty/.pyenv/versions/3.6.5/envs/venv365/lib/python3.6/site-packages/rasterio/env.py", line 421, in wrapper
    return f(*args, **kwds)
  File "/Users/madhavdesetty/.pyenv/versions/3.6.5/envs/venv365/lib/python3.6/site-packages/rasterio/__init__.py", line 216, in open
    s = DatasetReader(path, driver=driver, **kwargs)
  File "rasterio/_base.pyx", line 200, in rasterio._base.DatasetBase.__init__
rasterio.errors.RasterioIOError: gs://pdd-stac/disasters/hurricane-harvey/0831/20170831_172754_101c_3b_Visual.tif: No such file or directory
>>> rio.__version__
'1.0.14'
 
 

Re: Rasterio and pip 19

Sean Gillies
 

Thanks, Joris! I'm going to capture this in a rasterio ticket.

On Fri, Jan 25, 2019 at 3:28 PM Joris Van den Bossche <jorisvandenbossche@...> wrote:
Op vr 25 jan. 2019 om 22:45 schreef Sean Gillies via Groups.Io <sean=mapbox.com@groups.io>:
I'm hesitant to pin numpy in pyproject.toml because the right version sort of depends on your Python version. However, there's a potential stumbling block here that needs to be addressed. If anybody has more experience and wisdom to share about the new features of pip, I'm all ears.

You can (nowadays) specify the numpy version depending on the python version in pyproject.toml, which should make this possible. Something like:
    "numpy==1.8.2; python_version<='3.4'",
    "numpy==1.9.3; python_version=='3.5'",
    "numpy==1.12.1; python_version=='3.6'",
    "numpy==1.13.1; python_version>='3.7'",
In principle we should always pin the numpy version to the oldest supported version (if using build isolation), as otherwise using the built package in an environment with another numpy version breaks, as you explained.

Last year, we added a pyproject.toml to pandas, but it gave a lot of problems (https://github.com/pandas-dev/pandas/issues/20775), related to the fact that the above python-dependent numpy version was not possible yet (environment markers in pyproject.toml files were not yet supported at that time) + build dependencies needed to be installed as wheels instead of from source (which can give problems on certain platforms for which there are no wheels; this is also fixed in the meantime in pip I think). So in the end we decided to remove it again for the next release.
But it seems we should maybe look into adding it again.

Joris

 



--
Sean Gillies

Re: Rasterio 1.0.14

Madhav Desetty
 

@Sean
I think something is not right with the PyPI distribution of rasterio 1.0.14. I did pip install rasterio into a clean virtualenv and it installed rasterio. See the pip show rasterio output:

rio
---
Metadata-Version: 2.1
Name: rasterio
Version: 1.0.14
Summary: Fast and direct raster I/O for use with Numpy and SciPy
Home-page: https://github.com/mapbox/rasterio
Author: Sean Gillies
Author-email: sean@...
Installer: pip
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: cligj, snuggs, click, enum34, attrs, affine, numpy, click-plugins
Classifiers:
  Development Status :: 4 - Beta
  Intended Audience :: Developers
  Intended Audience :: Information Technology
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Programming Language :: C
  Programming Language :: Cython
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
....

However, when I look at site-packages at /usr/local/lib/python2.7/dist-packages/rasterio/ and code for path.py session.py there is no GSSession class or no gs:// paths in the remote schemes in path.py. I got around by git pull source from mapbox/rasterio and doing a local pip install -e . and the above code I pasted works. I don't know if something is wrong with PyPI package distribution. I am curious if others have had success with the latest rasterio 1.0.14 and the new features.
pip show rasterio

pip show rasterio

Re: Rasterio 1.0.14

Sean Gillies
 

Yes, you are absolutely right. Google cloud support landed in master and I failed to cherry pick it before 1.0.14 as I'd intended. Sorry! I'm going to release a 1.0.15 to fix this tonight.


On Sun, Jan 27, 2019 at 3:09 PM <madhav@...> wrote:
@Sean
I think something is not right with the PyPI distribution of rasterio 1.0.14. I did pip install rasterio into a clean virtualenv and it installed rasterio. See the pip show rasterio output:

rio
---
Metadata-Version: 2.1
Name: rasterio
Version: 1.0.14
Summary: Fast and direct raster I/O for use with Numpy and SciPy
Author: Sean Gillies
Author-email: sean@...
Installer: pip
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: cligj, snuggs, click, enum34, attrs, affine, numpy, click-plugins
Classifiers:
  Development Status :: 4 - Beta
  Intended Audience :: Developers
  Intended Audience :: Information Technology
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Programming Language :: C
  Programming Language :: Cython
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
....

However, when I look at site-packages at /usr/local/lib/python2.7/dist-packages/rasterio/ and code for path.py session.py there is no GSSession class or no gs:// paths in the remote schemes in path.py. I got around by git pull source from mapbox/rasterio and doing a local pip install -e . and the above code I pasted works. I don't know if something is wrong with PyPI package distribution. I am curious if others have had success with the latest rasterio 1.0.14 and the new features.
pip show rasterio

pip show rasterio



--
Sean Gillies

Re: Rasterio 1.0.14

Madhav Desetty
 

Great! I am good for now through local rasterio 1.0.14 packaging but happy to test out GS support  again once rasterio 1.0.15 is out.


On Sun, Jan 27, 2019 at 6:15 PM Sean Gillies via Groups.Io <sean=mapbox.com@groups.io> wrote:
Yes, you are absolutely right. Google cloud support landed in master and I failed to cherry pick it before 1.0.14 as I'd intended. Sorry! I'm going to release a 1.0.15 to fix this tonight.

On Sun, Jan 27, 2019 at 3:09 PM <madhav@...> wrote:
@Sean
I think something is not right with the PyPI distribution of rasterio 1.0.14. I did pip install rasterio into a clean virtualenv and it installed rasterio. See the pip show rasterio output:

rio
---
Metadata-Version: 2.1
Name: rasterio
Version: 1.0.14
Summary: Fast and direct raster I/O for use with Numpy and SciPy
Author: Sean Gillies
Author-email: sean@...
Installer: pip
License: BSD
Location: /usr/local/lib/python2.7/dist-packages
Requires: cligj, snuggs, click, enum34, attrs, affine, numpy, click-plugins
Classifiers:
  Development Status :: 4 - Beta
  Intended Audience :: Developers
  Intended Audience :: Information Technology
  Intended Audience :: Science/Research
  License :: OSI Approved :: BSD License
  Programming Language :: C
  Programming Language :: Cython
  Programming Language :: Python :: 2.7
  Programming Language :: Python :: 3.3
  Programming Language :: Python :: 3.4
....

However, when I look at site-packages at /usr/local/lib/python2.7/dist-packages/rasterio/ and code for path.py session.py there is no GSSession class or no gs:// paths in the remote schemes in path.py. I got around by git pull source from mapbox/rasterio and doing a local pip install -e . and the above code I pasted works. I don't know if something is wrong with PyPI package distribution. I am curious if others have had success with the latest rasterio 1.0.14 and the new features.
pip show rasterio

pip show rasterio



--
Sean Gillies



--
Madhav Desetty
Chief Software Architect
Airbus Aerial
(404) 918-0481

Rasterio 1.0.15

Sean Gillies
 

Hi all,

1.0.15 is available on PyPI now and fixes two problems with 1.0.14 and its binary wheels. The first is that 1.0.14 didn't have the advertised Google cloud storage support. The second is that the wheels lacked the advertised HTTP/2 support.

--
Sean Gillies

Re: Rasterio 1.0.15

Madhav Desetty
 

@Sean
Just tested 1.0.15, GS support works great! Thanks...

Madhav

Re: Rasterio 1.0.15

Sean Gillies
 

Hi again,

If you've installed a 1.0.15 rasterio wheel for Linux and are wondering where the HTTP/2 support is, it's in the new 1.0.15-1 wheels on PyPI now.

Contrary to what I announced earlier today, we don't have HTTP/2 support in the OS X wheels. We're relying on the system's libcurl for SSL reasons and it does not have the nghttp2 module.

Thanks for your understanding,

On Mon, Jan 28, 2019 at 9:38 AM Sean Gillies <sean@...> wrote:
Hi all,

1.0.15 is available on PyPI now and fixes two problems with 1.0.14 and its binary wheels. The first is that 1.0.14 didn't have the advertised Google cloud storage support. The second is that the wheels lacked the advertised HTTP/2 support.

--
Sean Gillies


--
Sean Gillies

Re: Rasterio 1.0.15

Madhav Desetty
 

@Sean
I am building a Docker image with the requirements.txt file set to rasterio==1.0.15. Do I have to do anything specific to get the 1.0.15-1 wheels for Docker image running on Linux? 

Re: Rasterio 1.0.15

vincent.sarago@...
 

Hi @Madhav, 
On linux it should work with `rasterio==1.0.15` 

Re: Rasterio 1.0.15

Sean Gillies
 

Correct, there is no need to specify the build tag. There is also no way to override the build tag other than to specify the entire URL of the wheel, but that's a good thing.

On Tue, Jan 29, 2019 at 9:18 AM <vincent.sarago@...> wrote:
Hi @Madhav, 
On linux it should work with `rasterio==1.0.15` 



--
Sean Gillies

New rasterio versions don't handle blank SRS gracefully

nicholas.maxwell@...
 

Short version:

The following causes errors, in rasterio 1.0.15,  but is fine in rasterio 1.0.9. 

from rasterio.crs import CRS
print(CRS())
The following are the only tests in rasterio to check blank CRSs.

def test_null_crs_equality():
assert CRS() == CRS()
a = CRS()
assert a == a
assert not a != a


def test_null_and_valid_crs_equality():
assert (CRS() == CRS(init='epsg:4326')) is False

I feel like print(CRS()) should not cause errors - CRS().__str__ should just return an empty string, for example.

Longer version:

We work with pre-orthorectified sat imagery, which have blank geotransforms (but may have GCPs set), eg,

gdalinfo /data/16APR27183709-P1BS-502376654080_01_P009.tif 
Driver: GTiff/GeoTIFF
Files: /data/16APR27183709-P1BS-502376654080_01_P009.tif
Size is 3201, 3281
Coordinate System is `'
GCP Projection = 
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
...

This causes problems on newer rasterio versions (presumably due to the switch to WKT representation for CRS). Example:

import rasterio
with rasterio.open('/data/16APR27183709-P1BS-502376654080_01_P009.tif') as src:
print("CRS:", src.crs)

On rasterio 1.0.9, this is fine, src.crs evaluates to None:

python ~/test.py
/home/nick/venvs/ras9/lib/python3.6/site-packages/rasterio-1.0.9-py3.6-linux-x86_64.egg/rasterio/__init__.py:217: NotGeoreferencedWarning: Dataset has no geotransform set. The identity matrix may be returned.
  s = DatasetReader(path, driver=driver, **kwargs)
CRS: None

The NotGeoreferencedWarning is fine, we explicitly ignore it. The point is that src.crs is None.
On 1.0.15, however,

python ~/test.py
/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/__init__.py:216: NotGeoreferencedWarning: Dataset has no geotransform set. The identity matrix may be returned.
  s = DatasetReader(path, driver=driver, **kwargs)
CRS: Traceback (most recent call last):
  File "rasterio/_crs.pyx", line 274, in rasterio._crs._CRS.to_dict
  File "rasterio/_err.pyx", line 194, in rasterio._err.exc_wrap_ogrerr
rasterio._err.CPLE_BaseError: OGR Error code 7

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nick/test.py", line 3, in <module>
    print("CRS:", src.crs)
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 245, in to_string
    return self.to_wkt() or self.to_proj4()
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 106, in to_proj4
    return ' '.join(['+{}={}'.format(key, val) for key, val in self.data.items()])
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 170, in data
    self._data = self.to_dict()
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 164, in to_dict
    return self._crs.to_dict()
  File "rasterio/_crs.pyx", line 277, in rasterio._crs._CRS.to_dict
rasterio.errors.CRSError: The WKT could not be parsed. OGR Error code 7

Interestingly, the GDAL Python API handles this in a different way:

from osgeo import gdal
ds = gdal.Open('/data/16APR27183709-P1BS-502376654080_01_P009.tif')
prj = ds.GetProjection()
print(prj)

which prints

GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]]
I guess GDAL assumes the GCP projection, in case of blank geotransform.

In any case, I think the src.crs is None behavior is good, since we can just look at src.gcps for the gcps.

I will add a workaround on our side, since
print(CRS().is_valid)
works, (that is, CRS().is_valid evaluates to False, without throwing exceptions.

Re: New rasterio versions don't handle blank SRS gracefully

Sean Gillies
 

Hi Nicholas,

Thanks for the explanation. We have at least one more related regression in 1.0.15 and I intend to fix both of these in 1.0.16.


On Fri, Feb 1, 2019 at 10:36 AM <nicholas.maxwell@...> wrote:
Short version:

The following causes errors, in rasterio 1.0.15,  but is fine in rasterio 1.0.9. 

from rasterio.crs import CRS
print(CRS())
The following are the only tests in rasterio to check blank CRSs.

def test_null_crs_equality():
assert CRS() == CRS()
a = CRS()
assert a == a
assert not a != a


def test_null_and_valid_crs_equality():
assert (CRS() == CRS(init='epsg:4326')) is False

I feel like print(CRS()) should not cause errors - CRS().__str__ should just return an empty string, for example.

Longer version:

We work with pre-orthorectified sat imagery, which have blank geotransforms (but may have GCPs set), eg,

gdalinfo /data/16APR27183709-P1BS-502376654080_01_P009.tif 
Driver: GTiff/GeoTIFF
Files: /data/16APR27183709-P1BS-502376654080_01_P009.tif
Size is 3201, 3281
Coordinate System is `'
GCP Projection = 
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
...

This causes problems on newer rasterio versions (presumably due to the switch to WKT representation for CRS). Example:

import rasterio
with rasterio.open('/data/16APR27183709-P1BS-502376654080_01_P009.tif') as src:
print("CRS:", src.crs)

On rasterio 1.0.9, this is fine, src.crs evaluates to None:

python ~/test.py
/home/nick/venvs/ras9/lib/python3.6/site-packages/rasterio-1.0.9-py3.6-linux-x86_64.egg/rasterio/__init__.py:217: NotGeoreferencedWarning: Dataset has no geotransform set. The identity matrix may be returned.
  s = DatasetReader(path, driver=driver, **kwargs)
CRS: None

The NotGeoreferencedWarning is fine, we explicitly ignore it. The point is that src.crs is None.
On 1.0.15, however,

python ~/test.py
/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/__init__.py:216: NotGeoreferencedWarning: Dataset has no geotransform set. The identity matrix may be returned.
  s = DatasetReader(path, driver=driver, **kwargs)
CRS: Traceback (most recent call last):
  File "rasterio/_crs.pyx", line 274, in rasterio._crs._CRS.to_dict
  File "rasterio/_err.pyx", line 194, in rasterio._err.exc_wrap_ogrerr
rasterio._err.CPLE_BaseError: OGR Error code 7

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nick/test.py", line 3, in <module>
    print("CRS:", src.crs)
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 245, in to_string
    return self.to_wkt() or self.to_proj4()
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 106, in to_proj4
    return ' '.join(['+{}={}'.format(key, val) for key, val in self.data.items()])
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 170, in data
    self._data = self.to_dict()
  File "/home/nick/venvs/ras15/lib/python3.6/site-packages/rasterio/crs.py", line 164, in to_dict
    return self._crs.to_dict()
  File "rasterio/_crs.pyx", line 277, in rasterio._crs._CRS.to_dict
rasterio.errors.CRSError: The WKT could not be parsed. OGR Error code 7

Interestingly, the GDAL Python API handles this in a different way:

from osgeo import gdal
ds = gdal.Open('/data/16APR27183709-P1BS-502376654080_01_P009.tif')
prj = ds.GetProjection()
print(prj)

which prints

GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4326"]]
I guess GDAL assumes the GCP projection, in case of blank geotransform.

In any case, I think the src.crs is None behavior is good, since we can just look at src.gcps for the gcps.

I will add a workaround on our side, since
print(CRS().is_valid)
works, (that is, CRS().is_valid evaluates to False, without throwing exceptions.



--
Sean Gillies