Re: [gdal-dev] Using a "standard" argument parser for command line utilities?

Hi, I've had some success prototyping the below idea on a few utilities. See https://github.com/OSGeo/gdal/pull/9445 for details Even Le 08/03/2024 à 16:40, Even Rouault via gdal-dev a écrit : Hi, Our command line C++ utilities use ad-hoc manual parsing, which means that: -  the usage m

[gdal-dev] GDAL 3.8.4 build on windows failed at linking

GDAL 3.8.4 build on Windows from VS2015 x64 command prompt: “cmake –build .” throws the following error (there are more similar errors): cpl_vsil_az.obj : error LNK2001: unresolved external symbol __imp__curl_slist_append [E:\gdal-3.8.4\build\GDAL.vcxproj] cmake options has: set (GDAL_USE_CURL

Re: [gdal-dev] Open a string (json) as STACIT in python

Works perfectly just had to do myds=gdal.OpenEx("STACIT:/vsimem/temp_stacit.json") Mike On 3/11/24, 2:34 PM, "gdal-dev on behalf of Even Rouault via gdal-dev" mailto:gdal-dev-boun...@lists.osgeo.org> on behalf of gdal-dev@lists.osgeo.org > wrote: Mike, Yes

Re: [gdal-dev] Open a string (json) as STACIT in python

Mike, Yes, the STACIT driver requires either a filename or STACIT:filename, and doesn't support passing the content of the file in the connection string An easy workaround is to do: gdal.FileFromMemBuffer("/vsimem/temp_stacit.json", stac_string) myds=gdal.OpenEx("/vsimem/temp_stacit.json") gd

[gdal-dev] Open a string (json) as STACIT in python

I’m building a stac item collection programmatically and I want to open that item collection in gdal using the python bindings. It all works if I save to a file or from a url (and I prefix with “STACIT:”) but I cannot seem to be able to open a variable containing json as STACIT. I have tried wit

Re: [gdal-dev] Testing the driver

ok, I've looked a bit at the code So I believe the issue is that - https://github.com/OSGeo/gdal/blob/master/apps/test_ogrsf.cpp#L1064 forms a "/foo/test.pol" filename for the miramon driver and call Create() with it - and then https://github.com/AbelPau/gdal/blob/master/ogr/ogrsf_frmts/mir

Re: [gdal-dev] Testing the driver

Hi, going back to the misterious failing test_tiff_write_133 I am not able to understand what is wrong with that. It seems that it would be failing when writing to an unauthorized path. But instead of that it is not failing (and this is the failure, not failing when it should fail). # Test wri

Re: [gdal-dev] New driver on doc index?

Oh, I assumed that it was an internal error and not findable on google, but you’re right that the process is standard. So, thanks for the answer! De: gdal-dev En nombre de Even Rouault via gdal-dev Enviado el: dilluns, 11 de març de 2024 12:50 Para: gdal-dev@lists.osgeo.org Asunto: Re: [gdal-de

Re: [gdal-dev] New driver on doc index?

Abel, Hi, I’m obtaining this error: /__w/gdal/gdal/doc/source/drivers/vector/miramon.rst: WARNING: document isn't included in any toctree The file of the rst is miramon.rst but the name of the driver is MiraMonVector (to make it different from MiraMonRaster, in a future). So, this is a p

[gdal-dev] New driver on doc index?

Hi, I'm obtaining this error: /__w/gdal/gdal/doc/source/drivers/vector/miramon.rst: WARNING: document isn't included in any toctree The file of the rst is miramon.rst but the name of the driver is MiraMonVector (to make it different from MiraMonRaster, in a future). So, this is a problem? or I