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: [email protected]
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
