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
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 r
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/is
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
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). g
On Thu, 31 Oct 2024, Even Rouault wrote:
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'v
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 wh
Hi,
we are asked to prepare presentation slide(s) for the OSGeo Annual
General Meeting (AGM) during FOSS4G on Friday, December 6 2024 at 20:30h
UTC (https://2024.foss4g.org/en/schedule/).
I've just done one at
https://docs.google.com/presentation/d/1GF2SDBXfEvd3WwvJCVa7ssfLtXnj08w8qF-PUpqwNT
