o more of the context is under our control.
Roger
Even
Le 11/02/2025 à 21:00, Roger Bivand via gdal-dev a écrit :
R-spatial for macOS static builds have run into a serious roadblock at
3.10.1, so maybe an early 3.10.2 could assist us.
Until recently, static macOS builds of GDAL wer
R-spatial for macOS static builds have run into a serious roadblock at
3.10.1, so maybe an early 3.10.2 could assist us.
Until recently, static macOS builds of GDAL were using 3.5.3. Simon
Urbanek (https://github.com/R-macos/recipes) has just converted the recipe
for GDAL to cmake, and things
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
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
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
d3301cd0e1dffd88e3605af630543a5/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
Even,
On Wed, 30 Oct 2024, Even Rouault wrote:
Roger,
Tomas also pointed to hot-fixes needed with 3.9.3 in pkg-config in that
setting to remove ".lib" from "-lshell32.lib" and "-lole32.lib" - towards
end of:
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_
On Tue, 29 Oct 2024, Roger Bivand wrote:
On Tue, 29 Oct 2024, Even Rouault wrote:
We'll try, but GDAL 3.9 needs to be more stable than 4 3.9 releases in
five months suggests for it to be easy to ask for.
3.9.3 will be the the last in the 3.9 series, with whatever bugs it has.
Thanks! Th
On Tue, 29 Oct 2024, Even Rouault wrote:
We'll try, but GDAL 3.9 needs to be more stable than 4 3.9 releases in
five months suggests for it to be easy to ask for.
3.9.3 will be the the last in the 3.9 series, with whatever bugs it has.
Thanks! That'll be enough, I think; I just need to try t
Abel:
You write:
>I am working on a Windows 10 or 11 system (though I
> believe this detail is not particularly relevant). I am looking
> for the simplest method to install GDAL, as RStudio
> requires it as a dependency for the "sf" package.
Windows (or macOS) as compared to all other systems
Further to the previous reply (copied below), Windows x86_64 sf, terra and
other packages built with GDAL have GDAL 3.8.3. The 3.9 series has been a bit
jumpy, but hopefully has now found the worst regressions, so we can try
proposing 3.9.3, but initally only for drivers not requiring additiona
The key distinction is between installation on systems for which CRAN builds
static packages - Windows and macOS - and others installed from the sf source,
and dynamically linking to the system-provided GDAL version.
In the latter case, the user may choose to install GDAL from source instead. I
No adverse impacts of GDAL 3.9.0 beta1 on reverse dependency checks of 935 R
packages depending on R packages sf and/or terra, both linking to GDAL. I had
to wait a bit to transition to Fedora 40, gcc 14.0.1, and R 4.4.0 released
yesterday, but all good as far as I can tell.
Roger
--
Roger Biv
You may find the listings used to build static libraries for R Windows packages
using MXE as the basis to be helpful:
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/
These are targeted at Windows, but the dependency tree logic should be similar.
In
>From the R code snippet I see: "Surprisingly, the value 9.75 is shifted to
>106, 86 = 105,85 in Python indexing", but R is 1-base and Python 0-base. In R:
> library(terra)
terra 1.7.71
> gdal()
[1] "3.8.3"
> a <- rast("attachment.obj")
> b <- rast("st4_pr.2017092016.01h.tif")
> a
class : S
Unfortunately, upgrading to 3.0.1 failed in October:
https://bugzilla.redhat.com/show_bug.cgi?id=2166459. I hope my (duplicate)
report may nudge the build team.
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@
https://bugzilla.redhat.com/show_bug.cgi?id=2256228
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.o
3.7.3 RC1 OK for 630 R packages using GDAL through released versions of R
packages sf, terra, gdalcubes, gdalraster and/or vapour; no observed test
failures related to GDAL.
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norwa
18 matches
Mail list logo
