[gdal-dev] GDAL 3.10.0 rc2 available (was Re: GDAL 3.10.0 release candidate is available)
Even Rouault
even.rouault at spatialys.com
Thu Oct 31 06:53:16 PDT 2024
Roer,
I'm afraid I can't make much sense of
https://github.com/r-spatial/sf/issues/2466 and the linked reports.
(I've never used R). Anyway to reproduce that in a more unitary way
using the C or Python GDAL API ? Or at least having stack traces of
where this segfaults ?
There was indeed a related commit in
https://github.com/OSGeo/gdal/commit/5738f7094afed715ccd44fee1865051c2b2aba2a
by the way you mention "anything changed on the GDAL side in
OGRGeometryCollection::get_GeodesicLength(),
OGRCurvePolygon::get_GeodesicLength(),
OGRLineString::get_GeodesicLength() or thereabouts?" : well, they are
*new* to 3.10.0. So you shouldn't get into those methods, unless you
explicitly call them.
Even
Le 31/10/2024 à 14:31, Roger Bivand via gdal-dev a écrit :
> I've listed four R packages depending on R package sf which show
> errors in checks with 3.10.0 rc1 and rc2, but which are clean with
> 3.9.3, tested on Fedora 40 standard GCC (both 3.9.3 and 3.10.0), GDAL
> built locally from source. The list is an sf github issue:
> https://github.com/r-spatial/sf/issues/2466.
>
> Two are worrying, both failing in sf CPL_area(), one at
> OGRSpatialReference::GetSemiMajor(int*) const () called from
> GetGeodesicAreaOrLength(). I'm assuming that the these failures are
> more likely to be on the sf side, but has anything changed on the GDAL
> side in OGRGeometryCollection::get_GeodesicLength(),
> OGRCurvePolygon::get_GeodesicLength(),
> OGRLineString::get_GeodesicLength() or thereabouts? Assuming any
> change was intended, the fix probably needs to be on the sf side, but
> insight would be useful.
>
> On the positive side, sf, terra and 1019 of their strong reverse
> dependencies (packages which cannot work without sf/terra and GDAL)
> passed without remark with 3.10.0rc1, which is good!
>
> Best wishes,
>
> Roger
>
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
More information about the gdal-dev
mailing list