Re: [gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests

2022-11-17 Thread Even Rouault
Hi Mateusz, TUT was a very sensible choice at the time you implemented it, and it has been very useful up to now ! Even Le 17/11/2022 à 18:02, Mateusz Loskot a écrit : On Wed, 16 Nov 2022 at 19:42, Even Rouault wrote: Text at https://github.com/OSGeo/gdal/pull/6720 The document proposes a

Re: [gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests

2022-11-17 Thread Mateusz Loskot
On Wed, 16 Nov 2022 at 19:42, Even Rouault wrote: > > Text at https://github.com/OSGeo/gdal/pull/6720 > > The document proposes and describes conversion of the existing C/C++ > autotest suite to use the `GoogleTest > framework `__. > > GoogleTest is a popular

Re: [gdal-dev] Specify Grid Rotation for gdal.Warp() with Geolocation Arrays

2022-11-17 Thread Alan Snow
This may be a helpful resource: https://github.com/rasterio/affine On Thu, Nov 17, 2022, 9:08 AM Even Rouault wrote: > > Le 17/11/2022 à 16:01, Brendan Heberlein a écrit : > > Thank you, Mike & Even. > > Supposing I wanted to have the output grid origin & dimensions computed > automatically, but

Re: [gdal-dev] Specify Grid Rotation for gdal.Warp() with Geolocation Arrays

2022-11-17 Thread Even Rouault
Le 17/11/2022 à 16:01, Brendan Heberlein a écrit : Thank you, Mike & Even. Supposing I wanted to have the output grid origin & dimensions computed automatically, but with a specified rotation angle, is that possible? There's no API in GDAL for it. You indeed have to set something like the

Re: [gdal-dev] Specify Grid Rotation for gdal.Warp() with Geolocation Arrays

2022-11-17 Thread Brendan Heberlein via gdal-dev
Thank you, Mike & Even. Supposing I wanted to have the output grid origin & dimensions computed automatically, but with a specified rotation angle, is that possible? Anyway I can calculate these parameters myself, so it is not a big issue. Your suggestion worked for me. Cheers! Brendan __

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

2022-11-17 Thread Jon Morris
I concur that signed byte data is fairly common and we have to handle it in our Python application. The recent addition of Int64 types actually broke the dictionary-based way we were converting between numpy and GDAL datatypes and we had to implement a more robust solution. Is it the case that

Re: [gdal-dev] A CSW query that seems to me works badly

2022-11-17 Thread Even Rouault
Le 17/11/2022 à 11:50, andy a écrit : Hi Even, another question. On Wed, 16 Nov 2022 at 14:17, Even Rouault wrote: No, title is not in the lists of hardcoded fields by the OGR CSW driver. Probably a fix/improvement to do in the driver. What's the list  of the hardcoded fields that

Re: [gdal-dev] A CSW query that seems to me works badly

2022-11-17 Thread andy
Hi Even, another question. On Wed, 16 Nov 2022 at 14:17, Even Rouault wrote: > No, title is not in the lists of hardcoded fields by the OGR CSW driver. > Probably a fix/improvement to do in the driver. > What's the list of the hardcoded fields that I can use in OGR? Thank you -- ___

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

2022-11-17 Thread Idan Miara
Just adding my two cents... I highly support adding the signed int8 datatype - this would probably lead to downstream projects that support different raster datatypes to eventually fully support int8 rasters as a first class citizen. Yes - downstream projects would need to invest some time adaptin