[gdal-dev] GDAL 3.10.0 rc2 available (was Re: GDAL 3.10.0 release candidate is available)

[Roger Bivand]

On Thu, 31 Oct 2024, Even Rouault wrote:

> 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.

Thanks, that does help, as sf::st_area() tries to handle geodetic area in 
s2 or using PostGIS code in lwgeom, before defaulting to its CPL_area at:

https://github.com/r-spatial/sf/blob/0d1a48b67d3301cd0e1dffd88e3605af630543a5/R/geom-measures.R#L37-L54

So if the geometries are geodetic, it shouldn't be reaching anything other 
than planar, as in:

https://github.com/r-spatial/sf/blob/0d1a48b67d3301cd0e1dffd88e3605af630543a5/src/gdal_geom.cpp#L9-L27

should it? In https://github.com/holans/ST-COS/issues/2 there is a chunk 
from a backtrace in gdb from CPL_area to 
OGRGeometryCollection::get_GeodesicLength, which CPL_area didn't call 
itself.

I'm fielding for Edzer here.

Roger

>
> 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
>> 
>

-- 
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: Roger.Bivand at nhh.no