On mercredi 29 avril 2020 08:40:07 CEST Guillaume Lostis wrote: > Like Ciaran I'm not very familiar with GDAL's python bindings, but I've > tried running a little snippet which I believe does the

This looks like an oversight when we implemented bounds(). Rasterio currently supports FeatureCollection or individual geometry objects in this operation. Logged here:

Like Ciaran I'm not very familiar with GDAL's python bindings, but I've tried running a little snippet which I believe does the same thing as what was done with rasterio: it writes a JP2 to a vsimem

Would you say it's worth raising an issue on GDAL then? I'm also not familiar with the Python GDAL bindings, Rasterio is my window in that haha.

Hi, Dataset files can be accessed from multiple threads, but the dataset objects returned by rasterio.open can only be used by a single thread at a time. This is a constraint that we get from GDAL.

Since there's no JP2 specific code in MemoryFile and things work with the GeoTIFF driver, I suspect there's a subtle bug involving the vsimem system and one of the JP2 drivers. It would be useful to

I'm attempting to isolate areas in a rasterio raster object, using Fiona to open a geojson and then window the parts I want to look at. Where a geojson entry is a geometry collection

Hello, I have an application that calls rasterio to open rasters in its main process. This application allows me to parallelize the process, so it will call the function where rasterio open is many

I have already fixed it. One of the main problems was that the tiled tiff was configured with size 256 and I was reading with windows of sizes 224. From here comes the disparity of the times of

As with Guillaume's answer, it's a Sentinel 2 band and has no side-car file, when I write straight to a file, the georeferencing is maintained.

Hi, I guess the B01.jp2 file mentioned is a Sentinel-2 band, which is standalone, there is no side-car file attached to it. I have tried downloading a single B01.jp2 file from a SAFE and running

Hi, To confirm: you're right, there's no need to seek after writing using mem.write() because the dataset API doesn't change the MemoryFile's stream position. It remains at 0, the beginning of the

I tried this with GDAL 2.4.2 and GDAL 3.0 too If anyone can point me to where I might look further to diagnose this, I can create an issue with some useful info, whether that's in Rasterio/GDAL :)

I would also like to add that the first tiled read is not necessarily slow...

So, do you think it should be a good idea to increase the cache memory? If so, how to do it? I have plenty of ram so that should not be a problem. On the other side I checked I there is some relation

I can confirm that writing a Jpeg2000 from memory losses the geo information

Revised: Don't require the seek call:s3_r = boto3.resource('s3')profile = source_image.profile.copy()with rasterio.io.MemoryFile() as stack: with stack.open(**profile) as stack_out:

Hi, I can't say for sure about the time differences because I don't know much about your data files or your computer. However, know this: GDAL's I/O system caches blocks of raster data in memory, the

On further inspection, when I switched to saving my outputs as GeoTIFF, the resultant images are both geo-coded fine (Disk vs. In Memory to S3). I'm guessing something is going wrong when .jp2 is

Hi there, I'm currently re-writing a process that was stacking .jp2 bands into one image and writing the resultant stack to disk. I'm moving this up to AWS so want to use MemoryFile's instead. My