On Thu, 31 Oct 2024, Even Rouault wrote:
By the way the logic in CPL_area is slightly incorrect. It assumes that if
getDimension() == 2 and the type is not wkbMultiSurface or wkbMultiPolygon,
then you can cast to OGRSurface*
Actually this is incorrect if you have a GeometryCollection with a Polygon
(and potentially points, lines). getDimension() will return 2 in that case,
but it is incorrect to cast a OGRGeometryCollection* as a OGRSurface*
I'd suggest instead something along the following (obviously untested):
OGRwkbGeometryType gt = OGR_GT_Flatten(g[i]->getGeometryType());
if (OGR_GT_IsSubClassOf(gt, wkbGeometryCollection)) { /* will
match OGRMultiPolygon, OGRMultiSurface and OGRGeometryCollection */
OGRGeometryCollection *gc = (OGRGeometryCollection *) g[i];
out[i] = gc->get_Area();
} else if (OGR_GT_IsSurface(gt)) {
OGRSurface *surf = (OGRSurface *) g[i];
out[i] = surf->get_Area();
} else {
out[i] = 0; // not supposed to happen, but who knows...
}
Even,
Thanks! Replacing lines 13-23 in sf/src/gdal_geom.cpp with the above
resolved both the segfaults in the packages using sf, and sf continued to
pass all its own checks.
The other two problems seem to be a change in handling of option strings
for a long query passed to vectortranslate (osmextract) and a missing
expected warning (sgapi), but the segfaults are I think now accounted for.
Roger
Le 31/10/2024 à 15:40, Even Rouault via gdal-dev a écrit :
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.
This is fishy. As you use the C++ API, I assume you've rebuilt the sf
package against the GDAL 3.10.0 headers ... ? Because currently it smells
like not, and some virtual method mixup. Or the stack-trace isn't reliable
(which might happen sometimes because of optimizations)
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
