[gdal-dev] Python gdal.FileFromMemBuffer problem

[Even Rouault]

Tim,

> It seems like the input "int nBytes" is the problem, as it is passed to
> VSIMalloc whicih takes a size_t type. The int type is signed and 32-bit so
> it can't handle over 2 * 2^30 (2 GB). It's probably rolling over, then when
> cast to size_t it is interpreted as that huge size in the OSX error
> message.

I've fixed the issue per https://trac.osgeo.org/gdal/ticket/6828

> 
> Also, is there any plan to expose the boolean that controls whether it takes
> ownership of the passed in buffer? As it is now, calling this function
> requires 2x the memory because of the malloc and memcpy. Maybe the
> ownership of the buffer is too tricky when dealing with multiple languages
> and reference counting...

Yes ownership might be complicated.

In your above example, you could simplify it a lot by doing :

drv = gdal.GetDriverByName("GTiff")
ds = drv.Create("/vsimem/48000.tif", 48000, 48000, 1, gdal.GDT_Byte)
ds = None

Or if you need to create a "real" file and ingest it into memory, you can do:

drv = gdal.GetDriverByName("GTiff")
ds = drv.Create("48000.tif", 48000, 48000, 1, gdal.GDT_Byte)
ds = None

mem_f = gdal.VSIFOpenL("/vsimem/48000.tif", "wb")
with open("48000.tif", "rb") as f:
    while True:
        membuf = f.read(4096)
        gdal.VSIFWriteL(membuf, 1, len(membuf), mem_f)
        if len(membuf) < 4096:
            break
gdal.VSIFCloseL(mem_f)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170228/196ac105/attachment-0001.html>