I was just tripped up by the fact that rasterio (I'm on 1.2.10) ignores the mask in numpy masked arrays. It simply writes the masked array's data array. If that underlying data array has the same fill value as the one defined in the profile, that works as expected. However, if the fill value in the data array is different from the one in the profile or if there are original brightness values instead of a fill value, the mask is completely ignored.

There's a simple workaround:
```
meta.update(fill_value=masked_img.fill_value)
with open(target, "w", **meta) as dst:
    dst.write(masked_img.filled())
```

But shouldn't that be the default behaviour? That rasterio should call .filled() every time it receives a Numpy masked array?

Cheers,
JOey

Hi all,

I've found rio-calc to be really useful for raster algebra expressions.  I've come up with a few additional functions that are useful in my workflow that seem to work well within rio-calc.

I'm certain, however, that I don't know how to introduce these functions into rio-calc without directly registering these functions with snuggs within calc.py (e.g. https://github.com/rasterio/rasterio/blob/master/rasterio/rio/calc.py#L159-L164). 

Is there a plug-in way of extending rio-calc to bring in additional user-defined functions?

thanks, matt

Heads up. everybody,

I've been wanting to move rasterio to its own GitHub organization for some time and it is finally going to happen. Last week the Mapbox legal team signed off on transferring rasterio to its own GitHub org and today the IT team is going to transfer it to https://github.com/rasterio. I apologize for the short notice. You may want to pause development until the transfer is complete.

I expect the transfer to be nearly seamless. For once, the Python Package Index's lack of project namespaces is a feature, not a bug. As a user, you won't have to change any of your dependency specifications :)

Hi all,

Preface this by saying I know next to nothing about multiprocessing and my debugging skills are failing me.

I'm trying to run a simple rio mbtiles command on Windows (Python 3.8, rasterio 1.2.9, rio_mbtiles 1.6.0) with a small test GeoTiff in Web Mercator using this syntax:

  > rio mbtiles
      --resampling average
      --zoom-levels 5..8
      --format PNG
      -j 4
      --progress-bar
      test.tif
      test.mbtiles

I often get this error stack trace:

  """
  File "c:\users\gregorma\envs\default-38\lib\site-packages\mbtiles\cf.py",
  line 62, in process_tiles
    tile, contents = future.result()
  File "c:\users\gregorma\appdata\local\programs\python\python38\
  lib\concurrent\futures\_base.py", line 432, in result
    return self.__get_result()
  File "c:\users\gregorma\appdata\local\programs\python\python38\
  lib\concurrent\futures\_base.py", line 388, in __get_result
    raise self._exception
  concurrent.futures.process.BrokenProcessPool: A process in the process pool
  was terminated abruptly while the future was running or pending.
  """

I can set up the same environment using WSL (Debian) and run the same command and it works flawlessly.  I don't think it's relevant but I'm using virtualenvs on both Windows and WSL.

I've read numerous posts about including either the if __name__ == "__main__" guard or (with multiprocessing) using freeze_support for helping with these issues on Windows, but have no idea where these would be inserted for this command (either at rio itself or within any of the plugins that use concurrent.futures). 

Has anyone had luck running rio mbtiles on a Windows box?  I obviously have the WSL workaround if needed.  Please let me know if more information is needed.

Thanks for any advice,
matt

I have been reading -> modifying -> writing some GeoTiffs and I got bit by Dataset.transform returning the identity transform. There's a big difference between there being no geotransform and there being the identity geotransform.

The result of this discrepancy is that if if you simply try to copy the transform from the source dataset to the destination dataset, it now has completely incorrect information. There are work arounds; you can detect that it's the identity and set it back to None. But this seems like an unnecessary asymmetry in reading/writing.

I was thinking of raising an issue on GitHub, but I figured I'd ask first. Is there any reason that Dataset.transform should return Affine.identity() instead of None? Is it to match GDAL in some way?

The following Python code...

---

import rasterio
from rasterio.crs import CRS
from rasterio import shutil as rio_shutil
from rasterio.vrt import WarpedVRT
import matplotlib.pyplot as plt

path = 'CORINE/U2018_CLC2018_V2020_20u1.tif'

# Destination CRS is 4326
# dst_crs = CRS.from_epsg(4326) # <--- This one will work...
dst_crs = CRS.from_string('+proj=ob_tran +o_proj=longlat +lon_0=-170 +o_lon_p=-180 +o_lat_p=137') # <--- This one doesn't work

# Output image dimensions
dst_height = dst_width = 1000

# Output image transform
left, bottom, right, top = 10.897971,49.059812, 10.907593,49.064142 # Coordinates in target CRS
xres = (right - left) / dst_width
yres = (top - bottom) / dst_height
dst_transform = rasterio.Affine(xres, 0.0, left,
                              0.0, -yres, top)

vrt_options = {
    'crs': dst_crs,
    'transform': dst_transform,
    'height': dst_height,
    'width': dst_width,
}

with rasterio.open(path) as src:
    with WarpedVRT(src, **vrt_options) as vrt:
        # Read all data into memory and show plot
        data = vrt.read()
        plt.imshow(data.squeeze())

---

fails to run, giving the error message

The PROJ4 dict could not be understood. OGR Error code 5

which doesn't appear if I use a more 'standard' destination CRS, e.g., CRS.from_epsg(4326) . I'll welcome any suggestions! Thanks.