Date   
Re: Adding resampling option to rasterio.merge

Sean Gillies
 

Hi Guillaume,

I'm so sorry I lost track of this email. Your proposal sounds fine to me.

Best wishes,


On Tue, Apr 14, 2020 at 10:49 AM Guillaume Lostis <g.lostis@...> wrote:

Hi,

I am using rasterio.merge to merge several datasets and downsample them in a single call thanks to the res argument of merge().

However I would like to control the resampling method that is being used in the call to read(), by exposing a resampling argument in the merge() function, which would default to Resampling.nearest.

Would that be fine? I prefer asking here before opening a PR on Github.

Thanks,

Guillaume Lostis



--
Sean Gillies

rasterio 1.1.4

Sean Gillies
 

Hi all,

Rasterio 1.1.4 has been released. Here are the changes:


Here are the distributions on PyPI


Please note that there is no wheel for Python 2.7 and OS X. We've lost the ability to build them and I'm not sure why. We may need help from the Travis CI team to get that particular build job unstuck. But as we're moving on from supporting Python 2.7, I'm not super concerned about this right now.

The biggest changes in the wheels on PyPI aren't mentioned in rasterio because they are outside the project scope. See https://github.com/rasterio/rasterio-wheels/blob/master/CHANGES.md#2020-05-06 for details. In a nutshell, we're upgrading NetCDF to 4.6.2, patching GDAL 2.4.4 to fix two different bugs, and are using a patched version of auditwheel to add a rasterio-specific tag, "rasterio", to the SONAME of shared libraries in the linux wheels. In rasterio.libs you will see shared libraries with names like libcurl-rasterio-ea538880.so.4.4.0 instead of libcurl-ea538880.so.4.4.0.

These wheels include 2.4.4. I felt like upgrading to 3.0 or 3.1 while also trying to fix the SONAME collision problem was too much for me, so we'll tackle the GDAL/PROJ upgrades in a future release.

Thanks for your help, everyone!

--
Sean Gillies

Re: ability to auto-level when building overviews

David Hoese
 

Ah ok, so in my case I should probably just add a call to that in my own package's code before I call build_overviews instead of modifying build_overviews. Sounds good.

Dave

On 5/5/20 2:49 PM, vincent.sarago@... wrote:
Hi David,
I for my own project added the function https://github.com/cogeotiff/rio-cogeo/blob/452edc1a90f87fe1fa7bbe597c6bf346b3be7366/rio_cogeo/utils.py#L95 but has since be added in Rasterio code based https://github.com/mapbox/rasterio/pull/1782/files Guillaume Lostis

Re: ability to auto-level when building overviews

vincent.sarago@...
 

Hi David, 
I for my own project added the function https://github.com/cogeotiff/rio-cogeo/blob/452edc1a90f87fe1fa7bbe597c6bf346b3be7366/rio_cogeo/utils.py#L95 but has since be added in Rasterio code based https://github.com/mapbox/rasterio/pull/1782/files Guillaume Lostis 

ability to auto-level when building overviews

David Hoese
 

Hi,

I'm currently updating some code in the Satpy library that uses rasterio to write geotiffs and optionally build overviews. One thing I noticed in the "gdaladdo" documentation is that since GDAL 2.3 you can leave out the list of levels and it will auto-calculate them for you. This is nice helper functionality so that the user doesn't have to calculate things themselves.

https://gdal.org/programs/gdaladdo.html#cmdoption-gdaladdo-arg-levels

I'm wondering if anyone would have a problem with me making a pull request to add this to `build_overviews`? I think a lot of it could be copied from the C++ code in gdaladdo and it isn't that complicated of logic anyway:

https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdaladdo.cpp#L288-L299

I'd have to add a `min_size` keyword argument (or maybe `minsize`?) and then allow the user to indicate that they want this behavior (empty list of factors?).

Any problems with this?

Dave

Re: Question regarding URIs

Sean Gillies
 

Hi Justin,

On Mon, Apr 27, 2020 at 1:29 PM Justin Polchlopek <jpolchlopek@...> wrote:
Hi,

I've been looking at the use of URI's in Rasterio, specifically how URIs get formatted into VSI paths, and I ran into a question regarding the use of '+' in the scheme portion.  Though it is allowable to use the + in a URI scheme, it doesn't appear that this is a standard usage.  The only similar usage that appears to exist (that I have found) are jar: URIs (https://docs.oracle.com/javase/6/docs/api/java/net/JarURLConnection.html), which are quite similar.  These appear to use a recursive parsing style where one can strip out the location of the archive as the URI between the first ":" and last "!".  It's not clear in the case of the "+" style if "zip+s3" is identical to "s3+zip".

We've used the "+" method in the past as a model for URIs (https://github.com/locationtech/geotrellis/blob/master/store/src/main/scala/geotrellis/store/GeoTrellisPath.scala), but I now wonder if the decision to format your URIs in this fashion was a choice informed by some broader convention that I'm not aware of, or if it was a convenient decision.

Thanks for all your great work!

You're welcome :) And thank you for the question. I've found it almost impossible to engage geospatial folks on the subject of how we address datasets on the web.

Rasterio's schemes are based on http://commons.apache.org/proper/commons-vfs/filesystems.html, but I've opted for, e.g., "zip+https:" instead of "zip:https:". The "+" comes from npm and pip and their conventions for installing packages directly from version control systems like "pip install git+https://github.com/Toblerity/Fiona.git". An advantage of "zip+https:"
over "zip:https:" is that the former is suited to the standard Python URL parser (and Node's, last time I checked) and the latter is not.

>>> from urllib.parse import urlparse
>>> urlparse("zip:https://example.org/file.zip")
ParseResult(scheme='zip', netloc='', path='https://example.org/file.zip', params='', query='', fragment='')
>>> urlparse("zip+https://example.org/file.zip")
ParseResult(scheme='zip+https', netloc='example.org', path='/file.zip', params='', query='', fragment='')

--
Sean Gillies

Question regarding URIs

Justin Polchlopek
 

Hi,

I've been looking at the use of URI's in Rasterio, specifically how URIs get formatted into VSI paths, and I ran into a question regarding the use of '+' in the scheme portion.  Though it is allowable to use the + in a URI scheme, it doesn't appear that this is a standard usage.  The only similar usage that appears to exist (that I have found) are jar: URIs (https://docs.oracle.com/javase/6/docs/api/java/net/JarURLConnection.html), which are quite similar.  These appear to use a recursive parsing style where one can strip out the location of the archive as the URI between the first ":" and last "!".  It's not clear in the case of the "+" style if "zip+s3" is identical to "s3+zip".

We've used the "+" method in the past as a model for URIs (https://github.com/locationtech/geotrellis/blob/master/store/src/main/scala/geotrellis/store/GeoTrellisPath.scala), but I now wonder if the decision to format your URIs in this fashion was a choice informed by some broader convention that I'm not aware of, or if it was a convenient decision.

Thanks for all your great work!

-Justin

Adding resampling option to rasterio.merge

Guillaume Lostis
 

Hi,

I am using rasterio.merge to merge several datasets and downsample them in a single call thanks to the res argument of merge().

However I would like to control the resampling method that is being used in the call to read(), by exposing a resampling argument in the merge() function, which would default to Resampling.nearest.

Would that be fine? I prefer asking here before opening a PR on Github.

Thanks,

Guillaume Lostis

Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Sean Gillies
 

Hi Yann-Sebastien,

Thanks for writing this up. I like the approach and look forward to working on this with you.


On Fri, Dec 20, 2019 at 4:22 PM Yann-Sebastien Tremblay-Johnston <yanns.tremblay@...> wrote:

Hi Sean,

Thanks for taking a look at this!

I guess I can see a couple of ways of enhancing rasterio's transform functionality. I'll just point out the two main goals I'd want rasterio to be able to do:

  1. Perform coordinate transformations for source datasets that are georeferenced with RPCs.
  2. Be able to pass optional parameters to GDAL objects i.e. WarpOptions or RaterizeOptions so that they may make use of the to perform warping/rasterization on datasets with RPC georeferencing.

So towards (1): Currently the rowcol and xy methods of the transforms.py module accept an affine transformation as argument. The mixin methods call the module methods and pass the instance attribute self.transform as the transform argument. I do like this existing functionality and the flexibility it provides (not needing to necessarily open a dataset in order to do coordinate transformations). The _general_transformer implementation I have currently takes rasterio dataset objects as arguments, in order to pass the underlying GDALDatasetH to GDALCreateImgProjTransformer2. What kind of transformer is returned depends on the metadata associated with the dataset and the options passed to GDALCreateImgProjTransformer2. Perhaps it would be better implement a simpler RPC transformer using GDALCreateRPCTransformer and GDALRPCTransformer which only requires the RPC metadata. I have not tried this yet, but I will soon. All this to say, I think this would mean that making coordinate transformations with rowcol and xyusing RPCs would minimize changes to the signatures of those methods. The transform argument could be either an affine transformation or a dict containing RPC metadata. I'm not sure what the likelihood of a dataset having both a geotransform and RPC metadata is, but the mixin methods could have an additional keyword argument to indicate which type of metadata to use. I don't want to clutter up function signatures too much though, and I'm fine with keeping affine transformations as first class citizens in rasterio. A quick mockup of what one of the transform methods might look like I included below:

def rowcol(transform, xs, ys, op=math.floor, precision=None):
    """
    Returns the rows and cols of the pixels containing (x, y) given a
    coordinate reference system.

    Use an epsilon, magnitude determined by the precision parameter
    and sign determined by the op function:
        positive for floor, negative for ceil.

    Parameters
    ----------
    transform : (Affine or dict)
        Coefficients mapping pixel coordinates to coordinate reference system. 
        Optionally can also be a dictionary containing RPC metadata.
    xs : list or float
        x values in coordinate reference system
    ys : list or float
        y values in coordinate reference system
    op : function
        Function to convert fractional pixels to whole numbers (floor, ceiling,
        round)
    precision : int, optional
        Decimal places of precision in indexing, as in `round()`.

    Returns
    -------
    rows : list of ints
        list of row indices
    cols : list of ints
        list of column indices
    """
    affine_transformation = True
    single_x = False
    single_y = False
    if not isinstance(xs, Iterable):
        xs = [xs]
        single_x = True
    if not isinstance(ys, Iterable):
        ys = [ys]
        single_y = True

    if precision is None:
        eps = 0.0
    else:
        eps = 10.0 ** -precision * (1.0 - 2.0 * op(0.1))

    if isinstance(transform, dict):
        affine_transformation = False

    rows = []
    cols = []

    if affine_transformation:
        invtransform = ~transform
        for x, y in zip(xs, ys):
            fcol, frow = invtransform * (x + eps, y - eps)
            cols.append(op(fcol))
            rows.append(op(frow))
    else:
        # simpler cython function that only does RPC transformation, not general one like GDALCreateGenImgProjTransformer2
        rows, cols = _rpc_transformer(transform, xs, ys)

    if single_x:
        cols = cols[0]
    if single_y:
        rows = rows[0]

    return rows, cols

Towards (2): I haven't done a lot of reprojecting with rasterio, but from what I've seen it seems like you can pass kwargs to the underlying WarpOptions. However I think the current function signature requires arrays with associated crs and geotransforms or dataset with those as well. I think I just need to do some testing to see what would need to change in the case of reprojecting with a dataset that has no crs.


Sorry for the wall of text. Does this seem like a reasonable first step? Focusing on just the additions to the rowcol and xy should be small change, perhaps opening up reprojection and rasterization to use RPC metadata would be better suited in a separate push.

_._,_._

--
Sean Gillies

Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Yann-Sebastien Tremblay-Johnston
 

Hi Sean,

Thanks for taking a look at this!

I guess I can see a couple of ways of enhancing rasterio's transform functionality. I'll just point out the two main goals I'd want rasterio to be able to do:

  1. Perform coordinate transformations for source datasets that are georeferenced with RPCs.
  2. Be able to pass optional parameters to GDAL objects i.e. WarpOptions or RaterizeOptions so that they may make use of the to perform warping/rasterization on datasets with RPC georeferencing.

So towards (1): Currently the rowcol and xy methods of the transforms.py module accept an affine transformation as argument. The mixin methods call the module methods and pass the instance attribute self.transform as the transform argument. I do like this existing functionality and the flexibility it provides (not needing to necessarily open a dataset in order to do coordinate transformations). The _general_transformer implementation I have currently takes rasterio dataset objects as arguments, in order to pass the underlying GDALDatasetH to GDALCreateImgProjTransformer2. What kind of transformer is returned depends on the metadata associated with the dataset and the options passed to GDALCreateImgProjTransformer2. Perhaps it would be better implement a simpler RPC transformer using GDALCreateRPCTransformer and GDALRPCTransformer which only requires the RPC metadata. I have not tried this yet, but I will soon. All this to say, I think this would mean that making coordinate transformations with rowcol and xyusing RPCs would minimize changes to the signatures of those methods. The transform argument could be either an affine transformation or a dict containing RPC metadata. I'm not sure what the likelihood of a dataset having both a geotransform and RPC metadata is, but the mixin methods could have an additional keyword argument to indicate which type of metadata to use. I don't want to clutter up function signatures too much though, and I'm fine with keeping affine transformations as first class citizens in rasterio. A quick mockup of what one of the transform methods might look like I included below:

def rowcol(transform, xs, ys, op=math.floor, precision=None):
    """
    Returns the rows and cols of the pixels containing (x, y) given a
    coordinate reference system.

    Use an epsilon, magnitude determined by the precision parameter
    and sign determined by the op function:
        positive for floor, negative for ceil.

    Parameters
    ----------
    transform : (Affine or dict)
        Coefficients mapping pixel coordinates to coordinate reference system. 
        Optionally can also be a dictionary containing RPC metadata.
    xs : list or float
        x values in coordinate reference system
    ys : list or float
        y values in coordinate reference system
    op : function
        Function to convert fractional pixels to whole numbers (floor, ceiling,
        round)
    precision : int, optional
        Decimal places of precision in indexing, as in `round()`.

    Returns
    -------
    rows : list of ints
        list of row indices
    cols : list of ints
        list of column indices
    """
    affine_transformation = True
    single_x = False
    single_y = False
    if not isinstance(xs, Iterable):
        xs = [xs]
        single_x = True
    if not isinstance(ys, Iterable):
        ys = [ys]
        single_y = True

    if precision is None:
        eps = 0.0
    else:
        eps = 10.0 ** -precision * (1.0 - 2.0 * op(0.1))

    if isinstance(transform, dict):
        affine_transformation = False

    rows = []
    cols = []

    if affine_transformation:
        invtransform = ~transform
        for x, y in zip(xs, ys):
            fcol, frow = invtransform * (x + eps, y - eps)
            cols.append(op(fcol))
            rows.append(op(frow))
    else:
        # simpler cython function that only does RPC transformation, not general one like GDALCreateGenImgProjTransformer2
        rows, cols = _rpc_transformer(transform, xs, ys)

    if single_x:
        cols = cols[0]
    if single_y:
        rows = rows[0]

    return rows, cols

Towards (2): I haven't done a lot of reprojecting with rasterio, but from what I've seen it seems like you can pass kwargs to the underlying WarpOptions. However I think the current function signature requires arrays with associated crs and geotransforms or dataset with those as well. I think I just need to do some testing to see what would need to change in the case of reprojecting with a dataset that has no crs.


Sorry for the wall of text. Does this seem like a reasonable first step? Focusing on just the additions to the rowcol and xy should be small change, perhaps opening up reprojection and rasterization to use RPC metadata would be better suited in a separate push.

Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Sean Gillies
 

Hi Sebastian,

I'm in favor of enhancing rasterio's transform features. Can you provide a little more detailed example usage? Specifically, how do you propose that we change the rowcol and xy methods of rasterio.transform to surface this new feature?

On Tue, Dec 10, 2019 at 6:19 AM Guillaume Lostis <g.lostis@...> wrote:

Hi Sebastien,

It's definitely not my call to say if this is worthwhile in rasterio or not, but I just wanted to chime in to say that this new interface could be very useful to my colleagues and me.

We work with optical imagery, both non-orthorectified ("georeferenced" through RPCs), and orthorectified (georeferenced through the typical Affine transforms).

For RPC-based datasets, we use rasterio for all I/O and raster-related tasks, but we need to use external tools to handle the projection/localization transformations (to/from geodetic coordinates/image coordinates):

  • either we use the python gdal package through its Transformer.TransformPoint method, but installing the python gdal bindings on different platforms with different GDAL versions is a pain
  • or we use a custom package that was made internally (https://github.com/cmla/rpcm), which is pure python.

None of these options are very satisfactory, and we would definitely prefer to have all of this abstracted out with our familiar rasterio workflow. On the other hand, RPCs are not that common for most rasterio users I assume, so I would understand if this was out of scope for rasterio.

Thanks,

Guillaume



--
Sean Gillies

Re: Expose driver specific creation option in profile

Sean Gillies
 

Hi,

We have thought about this and you can see some evidence of previous steps in this direction, such as the block size, "compress", "photometric", and "interleave" items in a GeoTIFF dataset's profile. The problem is that GDAL doesn't consistently record the use of creation options and they generally must be diagnosed from characteristics of the data. In some cases (like NBITS) that would be easy, we can check the value of a TIFF tag (I assume), but more often it will be complicated. Some creation options aren't worth tracking at all, such as GeoTIFF's NUM_THREADS.

We're going to leave it up to users to track the creation options that matter to their applications. On my team at work, we use named profiles from a private package to make sure that we're using creation options consistently.

On Wed, Dec 18, 2019 at 3:59 PM <thomas.maschler@...> wrote:
I was wondering if you already considered to expose driver specific creation options (other than blockxsize/ bockysize) in the profile.
I can for example create a raster like this:

with rasterio.open('test_bit.tif', 'w', nbits=1, **profile) as dst:
    dst.write(data)
but if i would read the same raster, I am not able to verify, if the nbits option was applied:
with rio.open('test_bit.tif', 'r') as src:
    print(src.profile["nbits"])

>>> KeyError: 'nbits'

--
Sean Gillies

Expose driver specific creation option in profile

Thomas Maschler
 

I was wondering if you already considered to expose driver specific creation options (other than blockxsize/ bockysize) in the profile.
I can for example create a raster like this:

with rasterio.open('test_bit.tif', 'w', nbits=1, **profile) as dst:
    dst.write(data)
but if i would read the same raster, I am not able to verify, if the nbits option was applied:
with rio.open('test_bit.tif', 'r') as src:
    print(src.profile["nbits"])

>>> KeyError: 'nbits'


Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Yann-Sebastien Tremblay-Johnston
 

Ok good to know!


On Tue., Dec. 10, 2019, 7:12 a.m. Guillaume Lostis, <g.lostis@...> wrote:

Sorry for the quick aside, but actually on Linux and MacOS, it is much simpler to install rasterio than it is to install gdal.

Since the rasterio wheels come packed with their own GDAL, a simple pip install rasterio on a brand new machine does the trick.

pip install gdal, on the other hand, requires you to have GDAL already installed, and to install a version of the python package compatible with your local GDAL as well, so it's much more of a hassle in my opinion.

Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Guillaume Lostis
 

Sorry for the quick aside, but actually on Linux and MacOS, it is much simpler to install rasterio than it is to install gdal.

Since the rasterio wheels come packed with their own GDAL, a simple pip install rasterio on a brand new machine does the trick.

pip install gdal, on the other hand, requires you to have GDAL already installed, and to install a version of the python package compatible with your local GDAL as well, so it's much more of a hassle in my opinion.

Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Yann-Sebastien Tremblay-Johnston
 

That's good to hear that you have interest in this. I suspect that it won't really help you in avoiding installing GDAL since you'll need it for rasterio anyway. And this method is very similar to using the gdal.Transformer. But hopefully if it's integrated in rasterio then there will be less need to have multiple solutions to the problem in your workflow.

Sebastien 

On Tue., Dec. 10, 2019, 5:19 a.m. Guillaume Lostis, <g.lostis@...> wrote:

Hi Sebastien,

It's definitely not my call to say if this is worthwhile in rasterio or not, but I just wanted to chime in to say that this new interface could be very useful to my colleagues and me.

We work with optical imagery, both non-orthorectified ("georeferenced" through RPCs), and orthorectified (georeferenced through the typical Affine transforms).

For RPC-based datasets, we use rasterio for all I/O and raster-related tasks, but we need to use external tools to handle the projection/localization transformations (to/from geodetic coordinates/image coordinates):

  • either we use the python gdal package through its Transformer.TransformPoint method, but installing the python gdal bindings on different platforms with different GDAL versions is a pain
  • or we use a custom package that was made internally (https://github.com/cmla/rpcm), which is pure python.

None of these options are very satisfactory, and we would definitely prefer to have all of this abstracted out with our familiar rasterio workflow. On the other hand, RPCs are not that common for most rasterio users I assume, so I would understand if this was out of scope for rasterio.

Thanks,

Guillaume

Re: Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Guillaume Lostis
 

Hi Sebastien,

It's definitely not my call to say if this is worthwhile in rasterio or not, but I just wanted to chime in to say that this new interface could be very useful to my colleagues and me.

We work with optical imagery, both non-orthorectified ("georeferenced" through RPCs), and orthorectified (georeferenced through the typical Affine transforms).

For RPC-based datasets, we use rasterio for all I/O and raster-related tasks, but we need to use external tools to handle the projection/localization transformations (to/from geodetic coordinates/image coordinates):

  • either we use the python gdal package through its Transformer.TransformPoint method, but installing the python gdal bindings on different platforms with different GDAL versions is a pain
  • or we use a custom package that was made internally (https://github.com/cmla/rpcm), which is pure python.

None of these options are very satisfactory, and we would definitely prefer to have all of this abstracted out with our familiar rasterio workflow. On the other hand, RPCs are not that common for most rasterio users I assume, so I would understand if this was out of scope for rasterio.

Thanks,

Guillaume

Thoughts on coordinate transformer using GDALGenImgProjTransformer2

Yann-Sebastien Tremblay-Johnston
 

Hi all,

I wanted to ask for some feedback on whether this functionality belongs in rasterio.

I'm looking to be able to calculate line/pixel coordinates for a Rational Polynomial Coefficient (RPC) georeferenced SAR image from geodetic coordinates. I had been looking for functionality in rasterio to be able to do this and found https://github.com/mapbox/rasterio/issues/410. After some excitement, I realized that this was mostly pertaining to using RPC metadata for warp/reprojecting. So I've attempted to do this by adding an interface to create a `GDALGenImgProjTransformer2` object in rasterio. This is captured in https://github.com/mapbox/rasterio/pull/1845

Changes include a new method in rasterio._base called _general_transformer which after a couple of iterations is basically an analogue of rasterio._base._transform. The latter is a coordinate transform method between spatial refs, whereas the former using `GDALGenImgProjTransformer2` is typically meant for pixel/line coordinate transforms between datasets. This is essentially 3 transforms rolled into one (pixel/line src -> geodetic coordinates src, geodetic coordinates src -> geodetic coordinates dst, geodetic coordinates dst -> pixel/line coordinates dst). By passing a NULL dst you can avoid also just transform between pixel/line and geodetic coordinates of a single dataset. 

If this seems worthwhile, I'd envision some method(s) could then use _general_transformer to provide a cleaner, higher level interface to this kind of coordinate transform for rasterio users. So I guess my question to you is, does this seem worthwhile in rasterio? Also this implementation basically lets GDAL handle all the transformation and reading/parsing of metadata for simplicity. For example by passing the 'METHOD=RPC' as a kwarg (method='RPC') this option is passed down to the GDAL object and an RPC transformer is created. You can specify other options according to https://gdal.org/api/gdal_alg.html#_CPPv432GDALCreateGenImgProjTransformer212GDALDatasetH12GDALDatasetHPPc

If we don't want to have something so general, we could also implement a specific RPC transformer in pure python, though then this might be hard to integrate into warp/reprojection.

Anyway, just to re-iterate my question: Does anything of this seem useful? 

Thanks,

Sebastien


Re: Access to dataset overviews for Rasterio 1.1

Sean Gillies
 

Excellent, Vincent. Count on me for help.

On Sat, Nov 30, 2019 at 11:42 AM <vincent.sarago@...> wrote:
Hi Sean, 
During the next few weeks, I might try to work on this subject because we need it for https://github.com/cogeotiff/rio-tiler/pull/132.

I might need assistance, so if someone else is interested, feel free to answer here :-) 

Vincent

--
Sean Gillies

Re: Access to dataset overviews for Rasterio 1.1

vincent.sarago@...
 

Hi Sean, 
During the next few weeks, I might try to work on this subject because we need it for https://github.com/cogeotiff/rio-tiler/pull/132.

I might need assistance, so if someone else is interested, feel free to answer here :-) 

Vincent