[gdal-dev] TSAN lock-order-inversion on moving GDAL init to main()

2025-04-10 Thread Simon Eves via gdal-dev
the failure until we are past the GDAL update. -- Simon Eves Senior Rendering Engineer +1 (415) 902-1996 simon.e...@heavy.ai ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] writing parquet to /vsiaz/ fails when chunked

2025-04-05 Thread Simon Norris via gdal-dev
Thanks Even. I didn't scroll down far enough in the google results - this blogger had the same symptoms. https://dzone.com/articles/azure-blob-storage-specified > On Apr 5, 2025, at 4:12 AM, Even Rouault wrote: > > The error is: > > URL_INFO_HEADER_OUT: PUT > /bcfishpass/crossings.parquet?se

Re: [gdal-dev] writing parquet to /vsiaz/ fails when chunked

2025-04-04 Thread Simon Norris via gdal-dev
nked below... but this must be an Azure issue. https://gist.github.com/smnorris/427ab56914b5bd55ad8f797c107aea73 > On Apr 4, 2025, at 2:52 PM, Even Rouault wrote: > > > > Le 04/04/2025 à 20:40, Simon Norris via gdal-dev a écrit : >> Perhaps another hapless user quest

[gdal-dev] writing parquet to /vsiaz/ fails when chunked

2025-04-04 Thread Simon Norris via gdal-dev
if it was a bug I'd think it would have already have been found by other users? thanks Simon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Zarr BLOCKSIZE in gdalmdimtranslate with variables of varying dimension

2025-03-15 Thread Simon Lyngby Kokkendorff via gdal-dev
rs afterwards. Best regards, Simon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Zarr BLOCKSIZE in gdalmdimtranslate with variables of varying dimension

2025-03-12 Thread Simon Lyngby Kokkendorff via gdal-dev
Thanks Even, That does the trick :) Cheers, Simon On Wed, Mar 12, 2025 at 9:54 AM Even Rouault wrote: > > Simon, > > see the ARRAY:IF(DIM=2):BLOCKSIZE=256,256 example of > GDALGroup::CopyFrom() mentioned at > https://gdal.org/en/stable/doxygen/c

Re: [gdal-dev] Masked VRT

2025-03-03 Thread Simon Wright via gdal-dev
Hi Daniel Many thanks for taking a look at my dilemma and providing a solution that works. Best wishes, Simon. Simon Wright GISMO Scrum Master and RML Head of Software -- e: simon.wri...@jbarisk.com d:+44 (0)1756 587258 t: +44 (0)1756 799919 www.jbarisk.com All JBA Risk

[gdal-dev] Masked VRT

2025-02-24 Thread Simon Wright via gdal-dev
m tiles that overlap the mask tiles. My question is: Do I need to provide mask tiles covering the entire extent of the raster mosaic, or is there an alternative approach that allows me to use mask tiles only where I want to mask specific areas (e.g., to reduce redundancy)? I’d appreciate any guidanc

Re: [gdal-dev] Zip-Compressed GeoJSON Files?

2025-02-23 Thread Simon Eves via gdal-dev
tput.zip' > > using driver `GeoJSON' successful. > > 1: test (3D Multi Polygon) > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* gdal-dev *Puolesta *Simon > Eves via gdal-dev > *Lähetetty:* lauantai 22. helmikuuta 2025 3.31 > *Vastaanottaja:*

Re: [gdal-dev] Zip-Compressed GeoJSON Files?

2025-02-21 Thread Simon Eves via gdal-dev
Same with 3.10.1. On Fri, Feb 21, 2025 at 3:12 PM Simon Eves wrote: > Revisiting our geo export options after several years and hit something > weird. > > Testing with the command-line tools, this works... > > ogr2ogr -f "geojson" /vsigzip//path/to/output.g

[gdal-dev] Zip-Compressed GeoJSON Files?

2025-02-21 Thread Simon Eves via gdal-dev
pits a ton of errors (attached) and while the zip file is created, it has no files in it. Am I doing something silly, or is this a bug? Does anyone really use or expect individually-zipped GeoJSON files anyway? This is with GDAL 3.7.3. We are updating to 3.11 so I'll try that too. -- Simon Eves

Re: [gdal-dev] debugging ogr/libcurl 302 redirect failure

2025-02-11 Thread Simon Norris via gdal-dev
Open of `transportation.gdb.zip' > using driver `OpenFileGDB' successful. > > Sorry for all the usage questions to the dev list - I'd be happy to take this > somewhere else. > > thanks > > Simon > > > On Aug 27, 2024, at 3:33 PM, Even Roua

Re: [gdal-dev] debugging ogr/libcurl 302 redirect failure

2025-02-11 Thread Simon Norris via gdal-dev
Sorry for all the usage questions to the dev list - I'd be happy to take this somewhere else. thanks Simon On Aug 27, 2024, at 3:33 PM, Even Rouault wrote: Hi, will be fixed per https://github.com/OSGeo/gdal/pull/10663 Workaround with existing versions: $ ogrinfo "/vsizip/{/vsic

[gdal-dev] config option to directly read zipped .gdb directories with file.zip extension?

2025-02-10 Thread Simon Norris via gdal-dev
rl -o Parks.gdb.zip https://maps.kamloops.ca/OpenData/zipfiles/ParksGDB.zip $ ogrinfo Parks.gdb.zip INFO: Open of `Parks.gdb.zip' using driver `OpenFileGDB' successful. thanks! Simon ___ gdal-dev mailing list gdal-dev@lists.osgeo.

Re: [gdal-dev] libkml: providing more information about builds that include LIBKML to steer users away from security pitfalls and questions for packagers who may build with libkml

2024-10-04 Thread Simon Eves via gdal-dev
Even Rouault wrote: > @SimonEves I was confused by your mention of autogen.sh and stuff. I > presume you're still using google/libkml. You'd probably have a slightly > better experience with libkml/libkml which has only a CMake build system. > Thanks. I'll pass that on. > ___

Re: [gdal-dev] libkml: providing more information about builds that include LIBKML to steer users away from security pitfalls and questions for packagers who may build with libkml

2024-10-03 Thread Simon Eves via gdal-dev
We include *libkml* in our GDAL build. We are still using v1.3.0 from August 12, 2015. It still works fine for our requirements with GDAL 3.7.3 (current production) and 3.9.2 (imminent deps bump). The build script for it predates me, but it appears we also had issues with *uriparser*. We build tha

Re: [gdal-dev] Motion: Renew Even Rouault GDAL Maintainer Contract

2024-09-12 Thread Simon Eves via gdal-dev
+100 On Thu, Sep 12, 2024 at 6:15 AM Sean Gillies via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Absolutely yes +1 > > On Wed, Sep 11, 2024, 8:24 PM Howard Butler via gdal-dev < > gdal-dev@lists.osgeo.org> wrote: > >> PSC, >> >> I am motioning to renew Even's maintainer contract through the GD

Re: [gdal-dev] x86/ARM Differences

2024-08-30 Thread Simon Eves via gdal-dev
where heuristics to > determine which block size to expose may be tuned, although this hasn't > changed much recently. > Le 30/08/2024 à 23:43, Simon Eves a écrit : > > Thank you, Even. > > Does that whole-image optimization only apply to PNG? I mean, obviously > that

Re: [gdal-dev] x86/ARM Differences

2024-08-30 Thread Simon Eves via gdal-dev
many geospatial PNGs... :) On Fri, Aug 30, 2024 at 1:24 PM Even Rouault wrote: > Simon, > > One is the declared block size of a simple RGB PNG image, which we use for > some raster import tests. The image is 320x225 and gdalinfo on x86 > reports that for the block size of the three

[gdal-dev] x86/ARM Differences

2024-08-30 Thread Simon Eves via gdal-dev
xt release. (repost after canceling original post held for moderation due to attachment size) -- Simon Eves Senior Rendering Engineer +1 (415) 902-1996 simon.e...@heavy.ai <http://www.heavy.ai> ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https:/

[gdal-dev] debugging ogr/libcurl 302 redirect failure

2024-08-27 Thread Simon Norris via gdal-dev
it presumably uses the token without issue because it reports on the correct attachment: CURL_INFO_HEADER_IN: Content-Disposition: attachment; filename="transportation.gdb.zip"; size=307145 I can download without issue using `curl --location-trusted` but would prefer to use ogr

[gdal-dev] Mosaic of multidimensional datasets of varying resolution

2024-07-05 Thread Simon Lyngby Kokkendorff via gdal-dev
he element of in a multidimensional VRT (https://gdal.org/drivers/raster/vrt_multidimensional.html#vrt-multidimensional). Am I right in assuming that this is not possible "out of the box" with the current options provided by VRTDataset, so that I would need to write some code to cover the use cas

Re: [gdal-dev] Efficient raster bounding box transformation?

2024-05-03 Thread Simon Eves via gdal-dev
Wow. Can't believe I missed the middle one, at least. Thank you, Even, as always! Simon On Fri, May 3, 2024 at 3:03 PM Even Rouault wrote: > ==> GDALCreateApproxTransformer(): > https://gdal.org/api/gdal_alg.html#_CPPv427GDALCreateApproxTransformer19GDALTransformerFuncPvd > &g

Re: [gdal-dev] Efficient raster bounding box transformation?

2024-05-03 Thread Simon Eves via gdal-dev
nding box. > The idea is not mine. Even Rouault mentioned it last year in FOSS4G. IIRC, > it is used by gdalwarp to not reproject every single point; once the > subdivision is enough, then it does linear interpolation. > > On Fri, 3 May 2024 at 22:18, Simon Eves wrote: > >>

Re: [gdal-dev] Efficient raster bounding box transformation?

2024-05-03 Thread Simon Eves via gdal-dev
wrote: > The bbox is created using the xmin,ymin,xmax,ymax found in the geometry. > Assuming every pixel can be represented as a geometry, that's your bbox. > > On 5/3/24 13:18, Simon Eves via gdal-dev wrote: > > Yes, but that's just the corners. > > > >

Re: [gdal-dev] Efficient raster bounding box transformation?

2024-05-03 Thread Simon Eves via gdal-dev
Javier Jimenez Shaw wrote: > Maybe I don't understand your question, but in gdalinfo you have the four > corners as lat-lon > > On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, < > gdal-dev@lists.osgeo.org> wrote: > >> So we are trying to optimize our raste

[gdal-dev] Efficient raster bounding box transformation?

2024-05-03 Thread Simon Eves via gdal-dev
cient. Thanks in advance, Simon -- Simon Eves Senior Rendering Engineer +1 (415) 902-1996 simon.e...@heavy.ai <http://www.heavy.ai> ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Reading DXF block attributes

2024-04-29 Thread Simon Gröchenig via gdal-dev
own issues at Github, writing block attributes is not yet supported) Any ideas why the field BlockAttributes (also BlockScale, BlockOCSNormal, BlockOCSCoords) is set to "" in the GPKG? BlockName and BlockAngle are set correctly. Best regards Simon ___ Ver

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-25 Thread Simon Eves via gdal-dev
As we're not ready to upgrade Arrow just yet, I also did the namespace change as a pre-build code patch on the regular 3.7.3 bundle. Apologies to Bjorn and anyone else on that team for any inference that this was a flatbuffers bug. Not my intention. Glad we worked it out. Simon On Sun, F

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-25 Thread Simon Eves via gdal-dev
Arrow moved to using a custom namespace in v10.0.0 On Sun, Feb 25, 2024 at 5:26 PM Simon Eves wrote: > Ooh, good call! > > That also corresponds with what I just tried, which was to leave the > change in, but have the *size()* method return a value derived the old > way

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-25 Thread Simon Eves via gdal-dev
ak something else. I guess you need to do the custom namespace thing too, though. I hate computers. Simon On Sun, Feb 25, 2024 at 3:43 PM Even Rouault wrote: > > > Not obvious why that change would have broken anything, and certainly > still absolutely no idea why it only happens in

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-25 Thread Simon Eves via gdal-dev
on to the *size()* method, although it only seems to avoid a couple of subtractions. I guess it must get called a lot. Not obvious why that change would have broken anything, and certainly still absolutely no idea why it only happens in a full static build. Simon On Sat, Feb 24, 2024 at 5:

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-24 Thread Simon Eves via gdal-dev
get any longer! :) Simon On Fri, Feb 23, 2024 at 3:46 PM Simon Eves wrote: > Our emails crossed. I am indeed testing with the latest flatbuffers now > too. > > Agreed on the rest. > > On Fri, Feb 23, 2024 at 3:42 PM Even Rouault > wrote: > >> Simon, >&

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-23 Thread Simon Eves via gdal-dev
Our emails crossed. I am indeed testing with the latest flatbuffers now too. Agreed on the rest. On Fri, Feb 23, 2024 at 3:42 PM Even Rouault wrote: > Simon, > > did you try to update to the latest > https://github.com/google/flatbuffers/releases to see if that would solve >

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-23 Thread Simon Eves via gdal-dev
I'm also testing a build that uses the latest *flatbuffers* 23.5.26, which is a drop-in replacement and does not require the *VerifyField* change, just in case the issue has been fixed since 2.0.6. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https:

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-23 Thread Simon Eves via gdal-dev
fully come up with a better solution. Yours hopefully, Simon On Thu, Feb 22, 2024 at 10:22 PM Simon Eves wrote: > Thank you, Robert, for the RR tip. I shall try it. > > I have new findings to report, however. > > First of all, I confirmed that a build against GDAL 3.4.1 (the

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-22 Thread Simon Eves via gdal-dev
y have would be very welcome. I am of course happy to describe my debugging findings in more detail, privately if you wish, rather than spamming the list. Simon On Tue, Feb 20, 2024 at 1:49 PM Robert Coup wrote: > Hi, > > On Tue, 20 Feb 2024 at 21:44, Robert Coup > wrote: >

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-20 Thread Simon Eves via gdal-dev
_loc = 8, max_voffset_ = 0, nested = false, finished = false, minalign_ = 8, force_defaults_ = false, dedup_vtables_ = true, string_pool = 0x0} On Tue, Feb 20, 2024 at 1:10 PM Simon Eves wrote: > Here's the stack trace for the original assert. Something is stepping on > scratch_ to make

Re: [gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-20 Thread Simon Eves via gdal-dev
Here's the stack trace for the original assert. Something is stepping on scratch_ to make it 0x10 instead of null, which it starts out as when the flatbuffer object is created, but by the time it gets to allocating memory, it's broken. On Tue, Feb 20, 2024 at 1:05 PM Simon E

[gdal-dev] Assert due to stack corruption in FlatGeoBuf export

2024-02-20 Thread Simon Eves via gdal-dev
ild that doesn't fail. Like I said, the frustrating part is that a simple test program (attached) compiled against the same set of static libs works fine. S On Tue, Feb 20, 2024 at 12:33 PM Robert Coup wrote: > Hi Simon, > > On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev < &

Re: [gdal-dev] Build static GDAL-Lib and static GDAL-Apps

2024-02-20 Thread Simon Eves via gdal-dev
One of our build variants is a fully-static (or as-static-as-possible) done on CentOS 7 for old-Linux compatibility. In reverse-dependency order we have static builds of SQLite 3450100 Expat 2.5.0 KML 1.2.0 HDF5 1.12.1 NetCDF 4.8.1 TIFF 4.5.1 Proj 9.3.0 GeoTIFF 1.7.1 LittleCMS 2.15 WebP 1.3.2 Zst

[gdal-dev] netCDF geo file problems

2023-07-28 Thread Simon Eves
the output is empty. Our geo import code supports multi-layer files (e.g. FileGDB) but we don't get as far as being able to call *GetLayers()* on the DS. If they do require specific opening with the full SDS name (like with raster) then I would expect *ogrinfo* to at least dump the SDS names. Ple

Re: [gdal-dev] Issue with sub-dataset suffix

2023-07-21 Thread Simon Eves
our prompt assistance! Simon On Fri, Jul 21, 2023 at 3:35 PM Even Rouault wrote: > > > This seems like a bug. It should still be able to recognize and open the > file without the type hint, whether or not you provide a sub-dataset suffix. > > This is not a bug. This is intended.

[gdal-dev] Issue with sub-dataset suffix

2023-07-21 Thread Simon Eves
GDAL's usually-reliable ability to recognize file types and load anything without such hints, so having to provide that as well will be undesirable. -- Simon Eves Senior Rendering Engineer +1 (415) 902-1996 simon.e...@heavy.ai <http://www.heavy.ai> __

[gdal-dev] Problem opening new format ECMWF grib files

2023-07-11 Thread Simon Proud - STFC UKRI via gdal-dev
ARS Am I correct in this assumption and, if so, is there a way around it in GDAL? Otherwise, any clues what could be the problem with this grib? Thanks, Simon -- Dr Simon Proud (he/him) Senior Remote Sensing Scientist RAL Space | National Centre for Earth Observation Science and Tech

Re: [gdal-dev] building against external tiff/geotiff sources ?

2023-03-04 Thread Simon Eves
I've also been looking at this, because we were previously using internal TIFF and GeoTIFF but also other libraries with their own TIFF, plus another one that needed TIFF, so we presumably ended up with four linked versions! I have reworked everything so that we use one external TiFF and GeoTIFF f

Re: [gdal-dev] OpenJPEG JPEG2000 Driver

2023-02-15 Thread Simon Eves
Thanks, everyone. On Wed, Feb 15, 2023 at 10:44 AM Even Rouault wrote: > > > In theory, BUILD_SHARED_LIBS=ON could/should cascade to all dependencies > > - you want static GDAL, good, we will assume you link it against > > static OpenJPEG, etc. > > That's indeed just theory. No such thing is imp

Re: [gdal-dev] OpenJPEG JPEG2000 Driver

2023-02-15 Thread Simon Eves
that's not an option for now on 3.4.1. On Tue, Feb 14, 2023 at 10:25 PM Mateusz Loskot wrote: > On Wed, 15 Feb 2023 at 01:34, Simon Eves wrote: > > > > I tried adding -DCMAKE_CPP_FLAGS="-fPIC" -DCMAKE_CXX_FLAGS="-fPIC" to > the OpenJPEG build CMake

Re: [gdal-dev] OpenJPEG JPEG2000 Driver

2023-02-14 Thread Simon Eves
OK, I'm an idiot. It's *CMAKE_C_FLAGS* not *CMAKE_CPP_FLAGS*. It works now. However, I am still surprised at the need to hack the *configure* script to make the test work. On Tue, Feb 14, 2023 at 4:33 PM Simon Eves wrote: > I recreated the compile/link test that *configure* is

Re: [gdal-dev] OpenJPEG JPEG2000 Driver

2023-02-14 Thread Simon Eves
t;-fPIC"* to the OpenJPEG build CMake invocation, but that made no difference. Any help with this would be greatly appreciated, as we're code-freezing end of this week and I'd really like to get this in. On Sun, Feb 12, 2023 at 6:44 PM Simon Eves wrote: > Is there some trick to

[gdal-dev] OpenJPEG JPEG2000 Driver

2023-02-12 Thread Simon Eves
rather not bump the GDAL & PROJ and data files versions at this time anyway, as we're very close to a release. I just wanna minimally add JPEG2000 to what we have... TIA -- Simon Eves Senior Rendering Engineer +1 (415) 902-1996 simon.e...@heavy.ai <ht

Re: [gdal-dev] Bad GDB performance

2023-01-27 Thread Simon Gröchenig
d as EPSG:31255 Yes, that is the correct code. > Which version of ArcMap / ArcGIS was used to produce this GDB ? ArcGIS Desktop 10.8.1 Simon Von: Even Rouault Gesendet: Freitag, 27. Jänner 2023 15:23 An: Simon Gröchenig Cc: gdal-dev@lists.osgeo.org Betreff: Re: AW: [gdal-dev] Bad GDB perf

Re: [gdal-dev] Bad GDB performance

2023-01-27 Thread Simon Gröchenig
Hi Even, great, thank you! Is the GDB itself fine? Or is there something I can do to fix the database? Simon Von: Even Rouault Gesendet: Freitag, 27. Jänner 2023 13:38 An: Simon Gröchenig ; gdal-dev@lists.osgeo.org Betreff: Re: [gdal-dev] Bad GDB performance Hi Simon, fix queued in https

[gdal-dev] Bad GDB performance

2023-01-26 Thread Simon Gröchenig
QGIS project containing this GDB (layer Kataster/GST) results in a layer loading time of 5+ seconds according to the QGIS Debugging/Development Tools. I expect less than 1 second to load this dataset. I appreciate any help to find if it is a GDAL or a dataset issue? Simon

[gdal-dev] GetAreaOfUse() and EPSG:29902

2023-01-03 Thread Simon Wright
is there another reason why the values differ to those listed at epsg.io. Many thanks, best wishes, Simon. Simon Wright JBA Risk Management Limited -- e: simon.wri...@jbarisk.com d:+44 (0)1756 587258 t: +44 (0)1756 799919 www.jbarisk.com All JBA Risk Management's email messages contai

Re: [gdal-dev] best tiff tag names for start and end datetimes?

2022-05-13 Thread Simon (Vsevolod) Ilyushchenko
third category, climatologies <https://climatedataguide.ucar.edu/climate-data> , when the data represent averages over multiple years - eg, the January data are not for any specific January, but for averages of all Januaries between 1960 and 1990. But this is a fairly niche case. Best, Simon On

[gdal-dev] best tiff tag names for start and end datetimes?

2022-05-12 Thread Simon (Vsevolod) Ilyushchenko
to use two different time tags for start and end. What would be the most standards-compliant way of setting datetimes? Thanks, Simon ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem reading Sentinel-1 GeoTIFFs

2021-12-13 Thread Simon Eves
lenced in https://github.com/OSGeo/gdal/pull/4975 > Le 11/12/2021 à 00:05, Simon Eves a écrit : > > After also finding this thread... > > https://github.com/OSGeo/gdal/issues/2321 > > ...I installed geotiff-bin and ran listgeo on the file. > > It also spits the same message

Re: [gdal-dev] Problem reading Sentinel-1 GeoTIFFs

2021-12-10 Thread Simon Eves
After also finding this thread... https://github.com/OSGeo/gdal/issues/2321 ...I installed geotiff-bin and ran listgeo on the file. It also spits the same message (three times). The output is attached. S On Fri, Dec 10, 2021 at 2:56 PM Simon Eves wrote: > Further to my earlier post ab

[gdal-dev] Problem reading Sentinel-1 GeoTIFFs

2021-12-10 Thread Simon Eves
d even mentions a patch to libGeoTIFF by Even. I checked, and that patch IS in the (internal, as configured in the build) GeoTIFF in our GDAL. This is with GDAL 3.4.0 and Proj 7.2.1. Thanks in advance, Simon -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer,

Re: [gdal-dev] Transforming Raster Points from GeoTIFF with GCPs

2021-12-10 Thread Simon Eves
Thanks. The code to which I was referring in my original mail was that used by gdaltransform. I just hadn't found the API part. On Fri, Dec 10, 2021 at 12:45 PM wrote: > and https://gdal.org/programs/gdaltransform.html > > > > -Matt > > > > *From:* gdal-dev *On

Re: [gdal-dev] Transforming Raster Points from GeoTIFF with GCPs

2021-12-10 Thread Simon Eves
Aha! That's the bit I hadn't found. Thank you! :) On Fri, Dec 10, 2021 at 10:38 AM Yann-Sebastien Tremblay-Johnston < yanns.tremb...@gmail.com> wrote: > Simon, > > See the Transformer API, in particular > https://gdal.org/api/gdal_alg.html?highlight=transformer#_CPPv

[gdal-dev] Transforming Raster Points from GeoTIFF with GCPs

2021-12-10 Thread Simon Eves
le so we can just import it with no transformation required, but that seems ugly unless it's gonna be WAY more efficient? Thanks, Simon -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA Email

Re: [gdal-dev] netCDF multi-dimensional support

2021-12-09 Thread Simon Eves
dependencies and correct options here, as I will need to get this working in our production dependencies bundle build too. Thanks! Simon On Thu, Dec 9, 2021 at 11:32 AM Simon Eves wrote: > I am trying to build GDAL 3.4.0 with "full" netCDF support, but getting > different results on

[gdal-dev] netCDF multi-dimensional support

2021-12-09 Thread Simon Eves
her not send it to you at this time. I can find out, if that would help, although I doubt the file itself is the issue. Please advise. Thanks! :) Simon -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 941

Re: [gdal-dev] Throwing exceptions in GDAL Error Handler

2021-12-06 Thread Simon Eves
OK, thanks for confirming. On Sat, Dec 4, 2021 at 3:59 PM Even Rouault wrote: > You shouldn't throw C++ exceptions, as this is a callback of the C API. > This will cause all sort of issues, most of the time memory leaks, etc. > Le 05/12/2021 à 00:49, Simon Eves a écrit : > &

[gdal-dev] Throwing exceptions in GDAL Error Handler

2021-12-04 Thread Simon Eves
s for CPLSetErrorHandler() don't explicitly say anything about not throwing in the callback. Please advise. SE -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA Email: simon.e...@omnisci.com | Cel

[gdal-dev] Problem with TopoJSON in 3.4.0 c/w 3.2.2

2021-12-03 Thread Simon Eves
orts due to the duplicate name. Below is the link to a TGZ with the JSON file and the output of "ogrinfo" for 3.2.2 and 3.4.0. The extra line in the field list at the top is obvious. https://drive.google.com/file/d/1ImBAmXz6XLW6NXheE2lKQTWpcFDKiQUZ/view?usp=sharing SE -- <http://

Re: [gdal-dev] Intermittent memory-corruption crashes in GRIB2 import

2021-11-16 Thread Simon Eves
ranch. Can we assume, therefore, that it will be in 3.4.1, which appears to be scheduled for the end of December? Simon On Tue, Nov 16, 2021 at 12:57 PM Simon Eves wrote: > Hi Even, > > Sorry for the slow response. I was out yesterday and this morning. Testing > your fix now. > >

Re: [gdal-dev] Intermittent memory-corruption crashes in GRIB2 import

2021-11-16 Thread Simon Eves
Hi Even, Sorry for the slow response. I was out yesterday and this morning. Testing your fix now. Simon On Mon, Nov 15, 2021 at 4:59 AM Even Rouault wrote: > Simon, > > unfortunately there are a number of places in the degrib library which > aren't thread-safe, and you just

[gdal-dev] Intermittent memory-corruption crashes in GRIB2 import

2021-11-14 Thread Simon Eves
with GDAL 3.2.2 on Ubuntu 20.04 LTS with GCC 9. -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA Email: simon.e...@omnisci.com | Cell: +1 (415) 902-1996 libc.so.6!raise (Unknown Source:0) libc.so.6!abort

Re: [gdal-dev] Strange behavior opening CSVs

2021-11-09 Thread Simon Eves
dalinfo makes GDAL to try XYZ > https://gdal.org/drivers/raster/xyz.html?highlight=xyz. It is not a bad > guess at all. Ogrinfo tries CSV and finds the x, y, and val fields. I can’t > say anything about the second part. > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* gd

Re: [gdal-dev] Driver DCAP flags

2021-11-08 Thread Simon Eves
Heh. Right. On Mon, Nov 8, 2021 at 2:24 PM Even Rouault wrote: > > Le 08/11/2021 à 21:44, Simon Eves a écrit : > > Quick question... > > Is it a definitive check for whether a GDALDriver is a Vector or Raster > driver to look for either DCAP_VECTOR=YES or DCAP_RASTER=YES

[gdal-dev] Strange behavior opening CSVs

2021-11-08 Thread Simon Eves
to. I can reproduce the first part with gdalinfo. This is with GDAL 3.2.2 on Ubuntu 20.04 with GCC 9. I'll poke at the GDAL code myself when I have a bit more time. -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San F

[gdal-dev] Driver DCAP flags

2021-11-08 Thread Simon Eves
Quick question... Is it a definitive check for whether a GDALDriver is a Vector or Raster driver to look for either DCAP_VECTOR=YES or DCAP_RASTER=YES in the default meta-data? Is every (vector or raster) driver guaranteed to have one or other of those? TIA Simon -- <http://www.omnisci.

Re: [gdal-dev] Multi-threading GDALRasterBand::RasterIO() ?

2021-11-01 Thread Simon Eves
More specifically, I'm guessing the MOST efficient is to read whole blocks from one band, which presumably avoids crossing compression boundaries etc. A block may be a scanline, or it may be a tile, depending on the format. On Mon, Nov 1, 2021 at 2:29 PM Simon Eves wrote: > Band by ba

Re: [gdal-dev] Multi-threading GDALRasterBand::RasterIO() ?

2021-11-01 Thread Simon Eves
ll-bands-of-a-line > Le 01/11/2021 à 21:58, Simon Eves a écrit : > > You can ignore this. > > I have rather belatedly found the documentation that says that one must > open a GDALDataset per thread, even if it's on the same file. > > The multi-threading now works just fine

Re: [gdal-dev] Multi-threading GDALRasterBand::RasterIO() ?

2021-11-01 Thread Simon Eves
ss it's OK because we're pulling the OGRFeatures out with the process thread, and only converting and loading them with the child threads. I guess I really ought to rewrite that code too now. Sigh. As you were... Simon On Sun, Oct 31, 2021 at 4:27 PM Simon Eves wrote: > We are writing

[gdal-dev] Multi-threading GDALRasterBand::RasterIO() ?

2021-10-31 Thread Simon Eves
th a local static build of GDAL 3.2.2 on Ubuntu 20.04 with GCC 9. Yours, Simon Eves -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA Email: simon.e...@omnisci.com | Cell: +

Re: [gdal-dev] Large GeoJSONs and aborting file opening

2021-07-29 Thread Simon Eves
> Not exactly what you asked, but can you simply avoid opening the file at > all if it's too large rather than start the process and then abort? > > On Wed, Jul 28, 2021 at 7:10 PM Simon Eves wrote: > >> Agreed. Unfortunately, we're looking for a quick solution to a c

Re: [gdal-dev] Large GeoJSONs and aborting file opening

2021-07-29 Thread Simon Eves
ingly) stuck in GDAL calls. Simon __ OGRFeature(fl_parcels):0 CNTYNAME (String) = ESCAMBIA LINK (String) = 27-083S321301060003 PARCELID (String) = 083S321301060003 NPARNO (String) = 12-033-083S321301060003 DORUC (String) = 000 PAUC (String) = 1 PARUSEDESC (S

Re: [gdal-dev] Large GeoJSONs and aborting file opening

2021-07-28 Thread Simon Eves
Agreed. Unfortunately, we're looking for a quick solution to a customer complaint. I'll ponder it some more. On Wed, Jul 28, 2021 at 12:28 PM Even Rouault wrote: > Simon, > > I don't think that killing a thread is a safe practice in general. It > would likely result i

[gdal-dev] Large GeoJSONs and aborting file opening

2021-07-28 Thread Simon Eves
ssary? Mainly I would be concerned that killing the thread might trash some global GDAL state that might then not be recoverable, or that the open relies on some TLS for the process thread and therefore might not work properly. We're going to try it anyway, but opinions welcomed, than

Re: [gdal-dev] gdalbuildvrt files not recognized

2021-02-04 Thread Simon Shak
e the file. Thanks for the quick help. On Thu, Feb 4, 2021 at 4:17 PM Mateusz Loskot wrote: > On Thu, 4 Feb 2021, 23:02 Simon Shak, wrote: > >> >> If I do it straight via commandline as: >> for %f in (input\*.ecw) do (gdalbuildvrt output.vrt %f) >> I wind up with a

[gdal-dev] gdalbuildvrt files not recognized

2021-02-04 Thread Simon Shak
I'm working on using the gdal2tiles to convert a mosaic of ECW files into TMS format. Since the gdal2tiles command needs a single input file, I'm building VRT's to use as the input. I have gotten this to work on ons set of files. When I do the same commands for the second set of files, gdalbuildvr

[gdal-dev] Expected behavior wrt .properties files with /vsigzip/

2020-09-08 Thread Simon Eves
t (in region us-west-1) if you want to try it yourself: s3://omnisci-import-test/example.geojson.tar.gz with subpath /example/example.geojson Thanks in advance! -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, C

Re: [gdal-dev] mosaicking is very slow

2020-01-27 Thread Simon
Hi, Okay, thank you. By the way, while making copy of gtiffs, is not it good idea to increase GDAL_CACHEMAX? Simon ‐‐‐ Original Message ‐‐‐ On Monday, January 27, 2020 9:04 PM, Rahkonen Jukka (MML) wrote: > Hi, > > If your source images are 4 GB then their size is at least

Re: [gdal-dev] mosaicking is very slow

2020-01-27 Thread Simon
; I would suggest to remove --config GDAL_CACHEMAX 8000 first. Then I would > check if the source images are tiled. If they are not it could be worth an > extra step to make tiled copies. > > -Jukka Rahkonen- > > Simon-4 wrote > > > Hello everyone, > > I am stiching ar

[gdal-dev] mosaicking is very slow

2020-01-27 Thread Simon
Hello everyone, I am stiching aroung 100 geotiff images each of around 4gb. However, translating the vrt file into geotiff is going on for days. gtranslate --config GDAL_CACHEMAX 8000 -co TILED=YES -co COMPRESS=LZW -co BIGTIFF=YES infile.vrt outfile.tif How can I speed up it? Thank you. Simon__

[gdal-dev] Speeding up gdalwarp process

2020-01-23 Thread Simon
> Hi gdal-devs, > I have a question, if there is some way to use gdalwarp in a clustering > system (e.g., Sparks) or with GPU to speed up the process? My task involves > re-projection and re-sampling of hundreds of high-resolution images. Any > ideas to make use of Sparks or GPU is welcomed. Tha

[gdal-dev] Speeding up gdalwarp process

2020-01-22 Thread Simon
Hi gdal-devs, I have a question, if there is some way to use gdalwarp in a clustering system (e.g., Sparks) or with GPU to speed up the process? My task involves re-projection and re-sampling of hundreds of high-resolution images. Any ideas to make use of Sparks or GPU is welcomed. Thank you. Si

Re: [gdal-dev] 3.1 release?

2019-10-16 Thread Simon Eves
Oh, OK. Not sure where I got the idea it was imminent. We'll go with 3.0.1. Thank you! On Wed, Oct 16, 2019 at 2:45 PM Even Rouault wrote: > On mercredi 16 octobre 2019 13:26:20 CEST Simon Eves wrote: > > Just wondering about the timescale of this, please? > > pr

[gdal-dev] 3.1 release?

2019-10-16 Thread Simon Eves
Just wondering about the timescale of this, please? We want to move to 3.x, but if 3.1 is imminent, we will wait for it. -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA Email: simon.e...@omnis

Re: [gdal-dev] ogr2ogr to convert one CSV row of MULTIPOLYGON to many CSV rows of POLYGON

2019-10-14 Thread Simon Eves
best way for getting fast and usable help. > > > > -Jukka Rahkonen- > > > > > > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html > ___ > gdal-dev mailing list > gdal-dev@lists.

[gdal-dev] ogr2ogr to convert one CSV row of MULTIPOLYGON to many CSV rows of POLYGON

2019-10-10 Thread Simon Eves
e have the magic incantation, please? Simon -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA Email: simon.e...@omnisci.com | Cell: 415.902.1996 ___

Re: [gdal-dev] Bogus GeoJSON file or am I doing something wrong? (re-post)

2019-09-26 Thread Simon Eves
To wrap this up, I got in touch with HighCharts, and they confirmed that this file is from them, but not a real GeoJSON, and not expected to be usable outside their software ecosystem. Thanks again. SE On Wed, Sep 25, 2019 at 8:47 AM Simon Eves wrote: > I concur. > > That said, I

Re: [gdal-dev] Bogus GeoJSON file or am I doing something wrong? (re-post)

2019-09-25 Thread Simon Eves
ault wrote: > On mercredi 25 septembre 2019 08:27:56 CEST Simon Eves wrote: > > OK, so it's a weird file. > > > > I'll leave it to you to decide whether it's worth making GDAL/Proj deal > > with it. I suspect not, and that's fine with us. > > Would onl

Re: [gdal-dev] Bogus GeoJSON file or am I doing something wrong? (re-post)

2019-09-25 Thread Simon Eves
OK, so it's a weird file. I'll leave it to you to decide whether it's worth making GDAL/Proj deal with it. I suspect not, and that's fine with us. Thanks! Simon On Tue, Sep 24, 2019 at 12:22 PM Even Rouault wrote: > On mardi 24 septembre 2019 11:52:22 CEST Simon Eves

[gdal-dev] Bogus GeoJSON file or am I doing something wrong? (re-post)

2019-09-24 Thread Simon Eves
inate system correctly? This is all using GDAL 2.4.2, btw. We haven't made the leap to 3.x yet. Sorry. -- <http://www.omnisci.com/> Simon Eves Senior Graphics Engineer, Rendering Group OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA Email: simon.e...@omnisci.com | Cell: 4

Re: [gdal-dev] Lame question, but failing to build GDAL 3.0.0RC2 against Proj 6.0.0

2019-05-28 Thread Simon Eves
NSTALL_DIR}/lib -Wl,-rpath,${INSTALL_DIR}/lib" > ./configure \ > --prefix="${INSTALL_DIR}" \ > --with-proj="${INSTALL_DIR}" > > I'm not sure if it matters, but I also set > CMAKE_INSTALL_RPATH=$INSTALL_DIR when I build proj. >

  1   2   3   >