[gdal-dev] using an in-memory file as -cutline argument in gdalwarp

Joaquim Manuel Freire Luís jluis at ualg.pt
Wed Mar 31 18:39:38 PDT 2021


Ok, I tried to use the handle like you said but couldn't find how to. That handle is a *void and options to gdalwarp are passed as strings.

Also tried to create a /vismem/filename but the same code that creates the in Memory GDAL datasets errored at line  (when line 285 was uncommented)
https://github.com/GenericMappingTools/GMT.jl/blob/master/src/gdal_utils.jl#L333
(setfeature!(layer, feature))

But it was not all failures. Managed to make it work if using ogr2ogr to write the /vsimem/file (though I might as well write it on disk)

This succeeded

julia> ogr2ogr(ds, dest="/vsimem/lixo.gmt")
julia> gdalwarp("IMG_9106.jpg", ["-cutline", "/vsimem/lixo.gmt", "-to", "SRC_METHOD=NO_GEOTRANSFORM"])

Not the best but also allows me to keep learning this business.


From: Even Rouault <even.rouault at spatialys.com>
Sent: Wednesday, March 31, 2021 8:28 PM
To: Joaquim Manuel Freire Luís <jluis at ualg.pt>; gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp


Ah, is it using the Memory driver ? As I saw a /vsimem/ filename and mention of gmt, I assumed you create a GMT file in /vsimem/, for which my example would have worked. But if you use the Memory driver, there's no way you can't use it as a cutline, since a dataset of the Memory driver can't be re-opened. You can just use the handle returned by the create method.
Le 31/03/2021 à 20:03, Joaquim Manuel Freire Luís a écrit :
This one is resisting. I can't spot any difference from your python example but it still fails.

What you mean by "Make sure that the cutline dataset is properly closed".
If I call GDALClose on it, then it disappears.
(note, I also tried by creating a "/vsimem/cut.shp" Memory cutline but the result was the same)


GDALGetDescription(ds.ptr)
"/vsimem/##280"

GDALClose(ds.ptr)

GDALGetDescription(ds.ptr)
""

From: Even Rouault <even.rouault at spatialys.com><mailto:even.rouault at spatialys.com>
Sent: Wednesday, March 31, 2021 2:43 PM
To: Joaquim Manuel Freire Luís <jluis at ualg.pt><mailto:jluis at ualg.pt>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] using an in-memory file as -cutline argument in gdalwarp


Joaquim,

yes, you should be able to use a /vsimem/ file as a cutline dataset. Here's an example in Python with a shapefile in /vsimem/:

https://github.com/OSGeo/gdal/blob/fec15b146f8a750c23c5e765cac12ed5fc9c2b85/autotest/utilities/test_gdalwarp_lib.py#L1103

The cutlineDSName= is just python syntaxic sugar to format the arguments. There's no reason it shouldn't work in Julia too

Make sure that the cutline dataset is properly closed, before using it with gdalwarp

Even
Le 31/03/2021 à 15:34, Joaquim Manuel Freire Luís a écrit :
I have low hopes on this one but have to confirm.

I have this "ds" dataset with one polygon geometry, which is correctly saved on disk with

ogr2ogr(ds, save="lixo.gmt")

and later correctly "cutlines" with

gdalwarp("IMG_9106.jpg", ["-cutline", "lixo.gmt", "-to", "SRC_METHOD=NO_GEOTRANSFORM"]);

but I wanted to avoid the step of saving to disk and instead using the inMemory file. If I ask its name, I see

GDALGetDescription(ds.ptr)
"/vsimem/##258"

But this fails

gdalwarp("IMG_9106.jpg", ["-cutline", GDALGetDescription(ds.ptr), "-to", "SRC_METHOD=NO_GEOTRANSFORM"])
NULL Dataset

Can this be made to work (would it work with the python bindings?) and I'm just doing it wrong or it just can't?

Thanks

Joaquim




_______________________________________________

gdal-dev mailing list

gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.

--

http://www.spatialys.com

My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210401/98af6749/attachment.html>


More information about the gdal-dev mailing list