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

> 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.Bivand at nhh.no