Re: [gdal-dev] resampling algs warp vs translate

That should be relatively straightforward to adapt GDALResampleChunk_AverageOrRMS_T to do sum. Reuse the average code path, but just don't divide the sum by dfTotalWeight at lines 1418, 1473, 1688, 1700 and 1712. And error out if applied to a band with a color table (cf line 4361) For other a

[gdal-dev] resampling algs warp vs translate

Can we aspire to translate having the same set of resampling algorithms as the warper? I see the warper adds min, max, mod, q1, q3, sum I especially wanted sum for OVERVIEW_RESAMPLING in COG, and I can see where it's done and ... can maybe see my way through that ... but the 600 lines of code i

Re: [gdal-dev] Call for 4.0 ideas

| But I have more troubles to understand why breaking code that use spatial_ref for decades without any real need Have you ever looked at the mess in the netcdf driver? Aligning with recommendations from standards, especially on the write side, and helping to reduce a bit code bloat (although

Re: [gdal-dev] Call for 4.0 ideas

Hi Joaquim, There have been other similar changes... for example, GDAL added an aspatial extension[1] to GeoPackage v1.0 to support non-geo tables... the GeoPackage standard added support for such tables in v1.2; so our extension is no longer needed: GDAL still reads it, but no longer writes it [2

Re: [gdal-dev] GeoTIFF and concurrent block reads

On Thu, Sep 21, 2023, at 18:05, Even Rouault wrote: > >> Of course, but I'm asking if it's worth calling ReadBlock on multiple >> threads (if it always takes a lock, it's not, and I should use RasterIO >> instead). > Not on the same dataset object, otherwise you'll get crashes as no lock is >

Re: [gdal-dev] GeoTIFF and concurrent block reads

Of course, but I'm asking if it's worth calling ReadBlock on multiple threads (if it always takes a lock, it's not, and I should use RasterIO instead). Not on the same dataset object, otherwise you'll get crashes as no lock is taken (*) I think these can also be implemented at VSI level by w

Re: [gdal-dev] Call for 4.0 ideas

Even, I understand that. Specially because not all nc files are created with GDAL 😊 But I have more troubles to understand why breaking code that use spatial_ref for decades without any real need. Sorry, and I know it's not decided yet, but it looks so much the Linux culture of *easy breaking*.

Re: [gdal-dev] GeoTIFF and concurrent block reads

Hi, On Thu, Sep 21, 2023, at 17:02, Even Rouault wrote: > Laurentiu, > >> >> GDAL 3.6 added support for multi-threaded reading using PRead, but I >> couldn't spot ReadBlock using the same code path. > If you read one single block at a time, the multi-threaded optimization > cannot kick in, sin

Re: [gdal-dev] GeoTIFF and concurrent block reads

Laurentiu, GDAL 3.6 added support for multi-threaded reading using PRead, but I couldn't spot ReadBlock using the same code path. If you read one single block at a time, the multi-threaded optimization cannot kick in, since the elementary decoding unit is a block. You must call RasterIO()

Re: [gdal-dev] Creation of a new driver from scratch

Hello again! I need to know that some shared code is being compiled in GDAL project. I can see that GDAL_COMPILATION (at Preprocessor definition i Visual Studio Project) is everywhere. It's apropiate to use that variable to know if I am compiling in GDAL or not? #ifdef GDAL_COMPILATION I'm in

[gdal-dev] GeoTIFF and concurrent block reads

Hello, GDAL 3.6 added support for multi-threaded reading using PRead, but I couldn't spot ReadBlock using the same code path. On the other hand, I didn't see it taking a lock either, so I'm a little confused :-). My question is whether ReadBlock supports concurrent reads or not (*). (*) I thin

Re: [gdal-dev] layer.GetSpatialRef() fails on linux for shapefiles

Run ogrinfo on one shapefile to see if some more interesting error message is displayed Also check if the environment isn't messed up regarding PROJ and the PROJ_LIB/PROJ_DATA environment variable Le 21/09/2023 à 14:34, Jonathan Moules via gdal-dev a écrit : Yeah, I'm afraid the error messa

Re: [gdal-dev] layer.GetSpatialRef() fails on linux for shapefiles

Yeah, I'm afraid the error message is pretty much non-existent: Traceback (most recent call last):   File "/home/name/Code/DSHub/PoC/Extract-Transform-Load-POC/Metadata/AME/src/info_vector.py", line 119, in get_layer_metadata     tmp_projection = layer.GetSpatialRef()   

[gdal-dev] Invitation for the Open Standards Code Sprint 🚀

*** Good morning, ** The Open Standards Code Sprint, will run from October 30 - November 1, in Geovation (London, UK). All OGC standards are in scope for this code sprint and various Standards Working Groups already confirmed their participation

Re: [gdal-dev] adding metadata -mo in a domain?

cool thanks, I'll deal with that 😃 On Thu, 21 Sept 2023, 18:48 Even Rouault, wrote: > > > > > which don't seem to exist. Is that just an outdated comment? > > yes, as far as I can see from history those functions have never > existed. This comment dates back to the initial commit and they didn

Re: [gdal-dev] adding metadata -mo in a domain?

which don't seem to exist. Is that just an outdated comment? yes, as far as I can see from history those functions have never existed. This comment dates back to the initial commit and they didn't even exist at that time. -- http://www.spatialys.com My software is free, but my time gene