Re: [gdal-dev] Official dataset for benchmarking GDAL I/O?

As Even said, this is a really tough topic. I have tried some micro benchmarking for small bits and for short term dev this is sort of ok. The biggest problem is getting a stable test env for benchmarking. Even a single user machine doing only benchmarking is all over the place. And if you are benc

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

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, Feb 25, 2

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

OK, so I guess we might be able to avoid it by upgrading Arrow, as long as that doesn't break something else. I guess you need to do the custom namespace thing too, though. (ab)use of preprocessor functionality makes it easy: https://github.com/OSGeo/gdal/pull/9313 ... I hate computers.

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

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 instead of just returning

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

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 instead of just returning *size_*, and also compare the two and log any mismatch. This also fails, which would seem to discount my thought

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

Not obvious why that change would have broken anything, and certainly still absolutely no idea why it only happens in a full static build. At that point, I would slightly bet on the fact that your whole application would have another component using flatbuffers at a different version, whic

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

I went ahead and did a bisect on the *flatbuffers* code itself. Turns out there were only 63 commits that touched *include/flatbuffers* between the versions that GDAL 3.5.x and 3.6.x use. This is the commit that breaks it, specifically the change to *vector_downward.h* https://github.com/google/f

[gdal-dev] MacOSX arm64 builds available on gdal-master Conda channel

Hi, The gdal-master Conda channel (cf https://gdal.org/download.html#gdal-master-conda-builds) now provides MacOSX arm64 builds of GDAL master. Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing l

Re: [gdal-dev] Possible error in orientation of converted arcs from dxf

Please file an issue with a (as small as possible) .dxf file reproducing the issue Even Le 25/02/2024 à 22:05, Jan Heckman a écrit : Hi Even, all, There might be a slight connection, but my case imo does not involve either a bulgefactor or a smoothing routine; it is the basic conversion/rende

Re: [gdal-dev] Possible error in orientation of converted arcs from dxf

Hi Even, all, There might be a slight connection, but my case imo does not involve either a bulgefactor or a smoothing routine; it is the basic conversion/render of a circular arc where apparently start- and endangle are interchanged sofar without apparent cause. Possibly the dxf has, earlier on, s

Re: [gdal-dev] Official dataset for benchmarking GDAL I/O?

Thanks Even, I think what I'm envisioning is more of an integration test than a unit test. We don't intend to use this in TorchGeo CI on every commit, only on PRs that we know may impact I/O (much less frequent than in GDAL). We would also run it before each release and publish performance metr

Re: [gdal-dev] Possible error in orientation of converted arcs from dxf

Hi, I'm wondering if there woulnd't be a connection with https://github.com/OSGeo/gdal/issues/1839#issuecomment-537185826 ? Even Le 25/02/2024 à 13:32, Jan Heckman via gdal-dev a écrit : Hi all, Sorry for a somewhat long post, but here we go: I am converting a .dxf having a sequence of simpl

[gdal-dev] Possible error in orientation of converted arcs from dxf

Hi all, Sorry for a somewhat long post, but here we go: I am converting a .dxf having a sequence of simple lines and arcs which form a continuous (poly)line, (correctly) ordered by EntityHandle. The arcs are converted (to shp) as well as displayed (Qgis) in the opposite direction as the simple line

Re: [gdal-dev] Official dataset for benchmarking GDAL I/O?

Adam, Automated performance regression testing is probably one of the aspect of testing that could be enhanced. While the GDAL autotest suite is quite comprehensive functionally wise, performance testing has traditionally been a bit lagging. That said, this is an aspect we have improved latel

[gdal-dev] Official dataset for benchmarking GDAL I/O?

Hi, Background: I'm the developer of the TorchGeo software library. TorchGeo is a machine learning library that heavily relies on GDAL (via rasterio/fiona) for satellite imagery I/O. One of our primary concerns is ensuring that we can load data from disk