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
building the successive static libraries, very likely the link order will
matter too, so some patience is needed.
Hope this helps,
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
> dimnames(values(b))
[[1]]
NULL
[[2]]
[1] "0[-] SFC (Ground or water surface)"
> all.equal(values(a), values(b), check.attributes=FALSE)
[1] TRUE
Reading both into R shows that the input GRIB data and the GTiff data converted
by gdal_translate are identical.
By the way, bette
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
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
No negative impacts seen in reverse dependency checks of 1100 R packages,
3.5.0 looks very promising, thanks!
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https
No issues/problems for 1000+ R packages in reverse dependency checks.
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https
No problems attributable to 3.3.1 built with PROJ 8.1.0 in R spatial
package reverse dependency checks, looks good!
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: roger.biv...@nhh.no
install.packages("rgdal", repos="http://R-Forge.R-project.org";)
can be used now to check rev. 1101 handling PJ_WKT2_2019/PJ_WKT2_2018
defensively.
-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GD
PROJ >= 6.3. Please
report back to confirm that the issue is resolved.
-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-de
"\tFAILED") writef(e$output) }) 6:
> renv_install_package_local(record) 5:
> renv_install_package_local_impl(package, path, library) 4:
> r_cmd_install(package, path, library) 3: r_exec(package, args, "install")
> 2: r_exec_error(package, output, label) 1: stop(
=/usr/proj71/include','--with-proj-lib=/usr/proj71/lib’))
>
> Many thanks for any assistance with this!
>
> Doug
> _______
> gdal-dev mailing list
> gdal-dev@.osgeo
> https://lists.osgeo.org/mailman/listinfo/gdal-de
grind, or
other CI variants. My feeling is often that CI is strewn with lots of false
positives and negatives, and that manual testing (the old way) is actually
effective.
-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDA
Thanks. I've been testing on master, but last built a month ago. Installing
RC2 now.
Roger
-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gda
On Thu, 7 Nov 2019, Even Rouault wrote:
On jeudi 7 novembre 2019 11:10:26 CET Roger Bivand wrote:
On Thu, 7 Nov 2019, Even Rouault wrote:
On jeudi 7 novembre 2019 15:24:44 CET Nyall Dawson wrote:
On Wed, 30 Oct 2019 at 06:16, Even Rouault
wrote:
I realise this too, but to permit legacy
this likely to continue,
or should we move away from Proj4 anyway?
Thanks!!
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-239
ialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93
t
available. Grid handling may help, but we're likely to see trouble with
dropped datum strings for some time (as long as R FAQ 7.31 [1]?), people
do re-use older files.
Roger
[1]https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
Eve
s
help, inserting a +towgs84 tag, but I do not have a clear view how to make
the migration process for users easier. In any case, they will need to
provide an EPSG or urn or similar look-up string in the future, but this
isn't predictably stored or retrievable.
Grateful for input
On Fri, 24 Nov 2017, Even Rouault wrote:
On vendredi 24 novembre 2017 22:19:08 CET Roger Bivand wrote:
On Fri, 24 Nov 2017, Even Rouault wrote:
I would have (perhaps) hoped that
pj_release.c is the runtime version, but mileage may
vary ...
It is. I just missed pj_get_release()
Thanks, I
a bit fragile, because the string is entered manually, rather than
coming from "above" in the build tree, but at least is there. Making sure
programatically that proj knows itself what its version is whould simplify
things a lot.
Roger
--
Roger Bivand
Department of Economics, Norw
On Fri, 24 Nov 2017, Even Rouault wrote:
On vendredi 24 novembre 2017 02:37:11 CET Roger Bivand wrote:
I've looked in ogr/ogrct.cpp, but cannot see that the proj4 version that is
detected internally is exposed for reporting through a function in the API.
It would be convenient if GDAL
orthcoming
release of proj4 5.0.0, which uses a different API. There is going to be a
lot of muddle, so being able to check will be helpful for many. Should I
file a trac request?
Roger
-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.
ld/gdal-2.1.3-obj/libgdal.dylib
(compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current
version 216.4.0)
and anyway the ID is invalid (it's the build location, not the target)."
--
Roger Bivand
Department of Economics, Norw
reading it with
rgdal/GDAL 2.2, and the reverse.
Best regards,
Even
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
Editor-in-Chief of The R Journal, https://journal.r-project.org/i
poFeature->SetField( CHAR(STRING_ELT(fld_names, j)),
NUMERIC_POINTER(VECTOR_ELT(ldata, j))[i] );
that is jumping over features for which the field value coming from R is
missing?
We'd need to condition on GDAL version here (too), I guess.
Was this regressio
On Sat, 28 May 2016, Even Rouault wrote:
On Saturday 28 May 2016 09:02:49 Roger Bivand wrote:
Blumentrath, Stefan nina.no> writes:
Hi,
And thanks Even and Jukka for your answers!
Based on the info you provided I investigated a bit more and it seems to
be an issue "downstreams
Blumentrath, Stefan nina.no> writes:
>
> Hi,
>
> And thanks Even and Jukka for your answers!
>
> Based on the info you provided I investigated a bit more and it seems to
be an issue "downstreams" indeed.
>
> gdalsrsinfo epsg:25832 gave the same result for me than for Jukka (the
result from li
Even Rouault spatialys.com> writes:
>
> Le vendredi 29 janvier 2016 15:20:07, Bas Couwenberg a écrit :
> > Even Rouault wrote:
> > > It is not definite how long the team will still maintain the 1.11 branch,
> > > so users are strongly encouraged to migrate to 2.0.2.
> >
> > Because not all reve
On Fri, 12 Jun 2015, Even Rouault wrote:
Selon Roger Bivand :
Hi,
In adapting rgdal for GDAL 2.0.0, it would be useful to know that
clamping, etc, and workarounds for integers in Integer64 fields that
exceed INT_MAX or INT_MIN actually work. Which of the autotest vector
files include
I see mostly test error trapping, so an indication of where to
look would be very valuable. Best with common drivers.
Thanks in advance,
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91
Even Rouault mines-paris.org> writes:
>
> Le jeudi 13 février 2014 22:17:40, Tim Keitt a écrit :
> > On Thu, Feb 13, 2014 at 12:55 PM, Tim Keitt utexas.edu> wrote:
> > > I've been updating my R bindings to GDAL/OGR. The repo is at
> > > https://github.com/thk686/rgdal2.
> > >
> > > There is st
On Mon, 2 Dec 2013, Even Rouault wrote:
Le lundi 02 décembre 2013 11:22:11, Roger Bivand a écrit :
On Tue, 5 Nov 2013, Roger Bivand wrote:
On Tue, 5 Nov 2013, Even Rouault wrote:
Even,
Thanks as always for getting back quickly! Yes, the relevant code is
(line
475 in rgdal/src/gdal
On Tue, 5 Nov 2013, Roger Bivand wrote:
On Tue, 5 Nov 2013, Even Rouault wrote:
Even,
Thanks as always for getting back quickly! Yes, the relevant code is (line
475 in rgdal/src/gdal-bindings.cpp):
GDALDataset *pDataset =
(GDALDataset *) R_ExternalPtrAddr(sxpHandle);
if
ould zombie the
dataset if applied too early. Initial tests on Linux and Windows are
promising ...
Thanks again,
Roger
Best wishes,
Roger
--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47
On Tue, 5 Nov 2013, Even Rouault wrote:
Selon Roger Bivand :
Hi,
This is probably my muddle, but we have an unresolved problem in rgdal on
Windows:
https://stat.ethz.ch/pipermail/r-sig-geo/2013-October/019667.html
https://stat.ethz.ch/pipermail/r-sig-geo/2013-November/019701.html
where
or GDAL utilities, where the "owning" process itself
terminates quickly, freeing the lock. In gcore/gdaldriver.cpp, I don't see
platform-specific fixes; we've been trying mainly with GTiff, but other
drivers seem to show the same behaviour.
Grateful for any input,
ary?
> Any help with this?
> I've uploaded test.kml in case someone could help:
> http://dl.dropbox.com/u/3180464/test.kml
>
> Thanks!
> Agus
> ___
> gdal-dev mailing list
> gdal-dev@.osgeo
> http://lists.osgeo.org/mailman/li
On Wed, 19 Dec 2012, Even Rouault wrote:
Selon Roger Bivand :
Hi,
I can get and set ConfigOptions using functions in port/cpl_conv.cpp, but I
have not found a way of unsetting a ConfigOption, only CPLFreeConfig() which
NULLs them all. I can also not see how to query which keys are set, so
away all
options. In the long-running setting of rgdal in R, when GDAL/OGR may be
running for a whole session, it would be useful to have better control of
the ConfigOptions on the GDAL side. Am I missing something?
Grateful for pointers,
Roger
-
Roger Bivand
NHH Norwegian School of Economics
rn up | Frank Warmerdam,
> warmerdam@
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Software Developer
>
> ___
> gdal-dev mailing list
> gdal-dev@.osgeo
On Sat, 3 Nov 2012, Even Rouault wrote:
Selon Roger Bivand :
On Sat, 3 Nov 2012, Even Rouault wrote:
Selon Roger Bivand :
Even,
I've opened #4880 on this - it is problematic in the R-spatial setting
because the CRS (coordinate reference system) object recorded in each
Spatial object
On Sat, 3 Nov 2012, Even Rouault wrote:
Selon Roger Bivand :
Even,
I've opened #4880 on this - it is problematic in the R-spatial setting
because the CRS (coordinate reference system) object recorded in each
Spatial object uses the PROJ.4 string to represent spatial reference. A use
Even,
I've opened #4880 on this - it is problematic in the R-spatial setting
because the CRS (coordinate reference system) object recorded in each
Spatial object uses the PROJ.4 string to represent spatial reference. A user
can create a CRS, write out a raster (which expands the description to
inc
ggests that I may use GDALCheckVersion(GDAL_VERSION_MAJOR,
GDAL_VERSION_MINOR, NULL); to get something that might help users debug
performance failures, but that GDAL_VERSION_REV is too fine-grained.
Yes.
Good, implemented and committed to SVN.
--
Roger Bivand
Department of Economics, NHH Norwegia
On Thu, 16 Aug 2012, Even Rouault wrote:
Selon Roger Bivand :
gcore/gdal_version.h gives us the hard-wired compile-time version string.
GDALVersionInfo("--version") gives us the version known by the runtime. We
can
use GDALCheckVersion() to check that the two match (in rgdal/R).
gcore/gdal_version.h gives us the hard-wired compile-time version string.
GDALVersionInfo("--version") gives us the version known by the runtime. We can
use GDALCheckVersion() to check that the two match (in rgdal/R). But is the SVN
revision number exposed in the same way? A rgdal user on OpenSUSE
d help see what could be done.
I realise that ESRI are probably stretching what may be put into a DBF,
but if they are doing this, it might be reasonable to do the same.
Best wishes,
Roger
--
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Berge
s; 4. very often are, like retrieving field
values or geometries.
Grateful for any suggestions beyond those already given. If it has to be
4, we'll have to take the performance hits involved.
Roger
Bob
On Fri, Feb 18, 2011 at 12:58 AM, Roger Bivand wrote:
On Fri, 18 Feb 2011,
ndler
just forwards CE_Fatal, CE_Warning and CE_Debug to the previous error handler
(or the default one if there's none). After the GDAL call, it just looks at
CPLGetLastErrorType() and if it is CE_Failure, it triggers a Python exception
with the error messages fetched with CPLGetLastErrorMsg().
wishes,
Roger
Best regards,
Even
Le mardi 14 décembre 2010 19:41:42, Roger Bivand a écrit :
Hi,
Agus Lobo has drawn my attention to an oddity (here using GADM Tunisia
shapefiles) introduced between 1.7.3 and current(ish) trunk:
$ ogr2ogr --version
GDAL 1.7.3, released 2010/11/10
$ ls TUN*
TUN_adm
It looks like line 509 in
trunk/gdal/ogr/ogrsf_frmts/shape/ogrshapedatasource.cpp
with:
EQUAL(CPLGetBasename(pszName), pszLayerName))
being the smoking gun change? The DSN is TUN, not TUN.shp, but is being
mistaken for TUN.shp, isn't it?
Best wishes,
Roger
--
Roger Bivand
Economic Geograph
eo.org] On Behalf Of Roger Bivand
Sent: Friday, March 26, 2010 11:09 AM
To: Ivan Lucena
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Re: rgdal source code
On Fri, 26 Mar 2010, Ivan Lucena wrote:
Roger,
Yes, you are right. The source code is on rgdal_0.6-25.tar.gz, I know,
but the instr
Ivan
---Original Message---
From: Roger Bivand
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Re: rgdal source code
Sent: Mar 26 '10 09:31
The root cause of the sourceforge issue is in a message posted 2010-03-25
from their admin:
"Update on the current CVS outa
solve. We’re
working to resolve this with alacrity and assure maximum stability and
performance."
So access should be back by the end of March.
Roger
Roger Bivand wrote:
>
> On Thu, 25 Mar 2010, Ivan wrote:
>
>> Roger,
>>
>> I in fact did my homework, but I&#
at the zip
archive as an archive - it is just a frozen binary version of the source
for Windows.
Roger
Thanks you so very much Roger. Have a nice day.
Ivan
Roger Bivand wrote:
Please, do your homework!
Google on "R rgdal" gives:
http://cran.r-project.org/web/packages/rgdal/ind
epend on some old version of
> gdal_fw.dll. Does anybody have any clue?
>
> Regards,
>
> Ivan
>
>
> [1] - http://sourceforge.net/scm/?type=cvs&group_id=84716
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.o
e. My MSYS and MinGW should be very up to
date.
Ari
Roger Bivand kirjoitti:
Hi,
I've probably missed something, but while 1.6.3 builds OK with EXPAT for
GPX on MSYS, 1.7.0 revision 18238 doesn't. The problem is in:
libtool: compile: g++ -O2 -Wall -I.. -I../.. -I/usr/local/include
On Thu, 10 Dec 2009, Roger Bivand wrote:
On Thu, 10 Dec 2009, Even Rouault wrote:
Roger,
this is weird indeed as I use daily MSYS on trunk... I'd bet that you have
an
installed version of cpl_string.h in /usr/local/include that corresponds to
the
1.6.3 version that didn'
ly to switch between different
versions to avoid installing stuff in "system" directories.
Even,
Thanks, removing the 1.6.3 headers in local/include resolved the problem.
Would re-ordering the directories included be a safety-first policy?
Best wishes,
Roger
Best regards,
Even
--
R
ngs.h.
These are recent changes - has anyone else seen the problem?
Motivation - trying to build an rgdal Windows binary using MSYS in the
usual way to let R/SAGA people try out the GDAL SAGA driver. I could drop
expat for now, but I'll need it again when 1.7.0 is released for GPX and
KML
On Fri, 4 Dec 2009, Frank Warmerdam wrote:
Roger Bivand wrote:
Hi,
In trying to build GDAL 1.6.3 and 1.7.0 on an RHEL 5 64-bit box, I'm seeing
that libtool in linking is inserting -L/usr/lib /usr/lib/libexpat.so and
provoking:
/usr/lib/libexpat.so: could not read symbols: File in
Has anyone seen similar
behaviour and does anyone have a fix?
This hurts because this is my main development box, but I have to use a
distant 32-bit RHEL 5 box with very similar binary installs instead for
work now on the coming SAGA driver.
Best wishes,
Roger
--
Roger Bivand
Economic Ge
On Thu, 27 Aug 2009, Roger Bivand wrote:
On Mon, 24 Aug 2009, Frank Warmerdam wrote:
Roger Bivand wrote:
(reverting to list)
Correction, the user reported that:
Apparently, gdalinfo retrieves the correct min, max, and statistics,
despite the use of GDT_Int16.
on his Windows platform
On Mon, 24 Aug 2009, Frank Warmerdam wrote:
Roger Bivand wrote:
(reverting to list)
Correction, the user reported that:
Apparently, gdalinfo retrieves the correct min, max, and statistics,
despite the use of GDT_Int16.
on his Windows platform. The different GDAL versions ought to explain
On Fri, 21 Aug 2009, Roger Bivand wrote:
On Fri, 21 Aug 2009, Frank Warmerdam wrote:
Roger Bivand wrote:
Hi,
The code for the LAN/GIS driver uses GDT_Int16 for Pixel type 2, rather
than GDT_UInt16. Is this justified? A user of rgdal has a case of unsigned
16-bit data stored by "a f
d/unsigned flag.
Is this a problem of ambiguity in use of a (closed?) specification, or
should the driver be using GDT_UInt16?
I'm asking on the list first, because this may be ambiguity, not a bug.
Best wishes,
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norw
On Sat, 8 Aug 2009, Roger Bivand wrote:
On Sat, 8 Aug 2009, Even Rouault wrote:
- Original Message - From: Jason Roberts
To: gdal-dev@lists.osgeo.org
Cc: 'Roger Bivand'
Sent: Saturday, August 08, 2009 12:05 AM
Subject: [gdal-dev] With 1.6.2,still can't read ArcInfo bin
On Sat, 8 Aug 2009, Even Rouault wrote:
- Original Message - From: Jason Roberts
To: gdal-dev@lists.osgeo.org
Cc: 'Roger Bivand'
Sent: Saturday, August 08, 2009 12:05 AM
Subject: [gdal-dev] With 1.6.2,still can't read ArcInfo binary grids: GDAL
Error 3:Attempt to rea
rect?
>>
>> The workaround is still there, but yeah, the latest change in trunk makes
>> it
>>
>> more or less useless.
>>
>> > Just as long as the user doesn't call GetDefaultRAT()?
>>
>> There's no point trying to read the RAT u
anyway. If you want the projection information out too, look in
create2GDAL for the .Call() you need. Note that passing unchecked
variables through .Call may crash your session - going through
GridTopology should make sure that they are stored correctly.
Hope this helps,
Roger
--
72 matches
Mail list logo
