I just refactored our GDAL init code which required me to add calls to the
init function to the *main()* of several of our unit test executables. Now
they all fail our TSAN tests with the following:
*18:46:51* 29: WARNING: ThreadSanitizer: lock-order-inversion
(potential deadlock) (pid=111437)*18:
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:*
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.geojson.gz
>
> This does not...
>
> ogr
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.geojson.gz
This does not...
ogr2ogr -f "geojson" /vsizip//path/to/output.geojson.zip
It spits a ton of errors (attac
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.
>
___
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
+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
Understood. Thank you.
On Fri, Aug 30, 2024 at 2:54 PM Even Rouault
wrote:
> I can't think of other formats with similar behavior right now, but you
> shouldn't trust my memory. That said, reported block sizes might very well
> change with versions. Like in JPEG2000 drivers where heuristics to
>
Thank you, Even.
Does that whole-image optimization only apply to PNG? I mean, obviously
that particular build option is PNG-specific, but are there other formats
which might exhibit similar differences in presented block size? If it's
just PNG, I'm not worried, as there aren't many geospatial PNG
Dear List,
We are in the process of creating an ARM build of our system, and we have
discovered some differences in GDAL behavior between the two.
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
ResampleAlgdPK15GDALWarpOptions)
> to EPSG:4326 and just take the extent of the warped VRT.
> Le 03/05/2024 à 23:25, Simon Eves via gdal-dev a écrit :
>
> I like it.
>
> On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw
> wrote:
>
>> Now I think I understand what you m
ers.
>>
>> On Fri, May 3, 2024 at 1:09 PM 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, <
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.
> >
> >
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
So we are trying to optimize our raster import process, and particularly
the steps to derive the final WGS84/4326 bounding box for a raster file or
tile thereof.
Obviously in the general case, the transform is from integer pixel
coordinate through the Affine Transformation matrix and then whatever
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
t; Agreed on the rest.
>>>>
>>>> On Fri, Feb 23, 2024 at 3:42 PM Even Rouault <
>>>> even.roua...@spatialys.com> wrote:
>>>>
>>>>> Simon,
>>>>>
>>>>> did you try to update to the latest
>>>>
solve the issue ? If that worked, that would be the best way forward...
>>>>
>>>> Otherwise if the issue persists with the latest flatbuffers release, a
>>>> (admitedly rather tedious) option would be to do a git bisect on the
>>>> flatbuffers code to identi
t;> (admitedly rather tedious) option would be to do a git bisect on the
>>> flatbuffers code to identify the culprit commit. With some luck, the root
>>> cause might be obvious if a single culptrit commit can be exhibited
>>> (perhaps some subtle C++ undefine
lso it is a bit
>> mysterious that it hits only for static builds), or otherwise raise to the
>> upstream flatbuffers project to ask for their expertise
>>
>> Even
>> Le 23/02/2024 à 23:54, Simon Eves via gdal-dev a écrit :
>>
>> I was able to create a fork of 3.7
t; cause might be obvious if a single culptrit commit can be exhibited
> (perhaps some subtle C++ undefined behaviour triggered? also it is a bit
> mysterious that it hits only for static builds), or otherwise raise to the
> upstream flatbuffers project to ask for their expertise
>
>
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:
I was able to create a fork of 3.7.3 with just the *flatbuffers* replaced
with the pre-3.6.x version (2.0.0).
This seemed to only require changes to the version asserts and adding an
*align* parameter to *Table::VerifyField()* to match the newer API.
https://github.com/heavyai/gdal/tree/simon.eve
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 version we
were on before) still works. I also confirmed that builds against 3.7.3 and
3.8.4 still failed even with no additional library depen
at 0x61900062cf70 thread T0
>>
>> ...but it's still not obvious what exactly is going wrong. The code and
>> data flow makes perfect sense when you step through it in a dynamic build
>> that doesn't fail.
>>
>> Like I said, the frustrating part is tha
e 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 <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> We still have one VERY st
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 <
&
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
28 matches
Mail list logo
