rgdal release candidate 1.5-9 rev. 1000 ready for testing

I am not sure if the part with

use --with-proj_api="proj_api.h" for deprecated API

Is of much help since c/p won?t work but the text let?s people assume that 
c/p could/should work.
In fact, a full path to ?proj_api.h? is required?
No. If proj.pc is found by pkg-config, the path to the relevant include 
directory is obtained there. If proj.pc is not availble, on Linux 
platforms, the usual include directories are tried (often 
/usrlocal/include is the right place). If proj.pc is not available and the 
include directory cannot be found automatically, use the 
--with-proj-include=DIR configure argument to point to the location of 
proj header files.

This is a different configure argument. If PROJ is >= 6, rgdal will choose 
"proj.h" by default. In PROJ 5-7, proj.h and proj_api.h (the legacy 
interface) have been available. In PROJ 5, proj.h was experimental, and 
proj_api.h was used by default. PROJ 6 uses proj.h (with very different 
structures and functions) by default, but proj_api.h can be used by 
setting -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H. PROJ 7 (March 2020) 
extended the grace period for the use of proj_api.h until PROJ 8 (March 
2021) - originally PROJ 7 was going to block proj_api.h.

So setting the path to the directory where both proj.h and proj_api.h are 
present (and project.h for the archeologically interested, happily gone 
now!) does not solve the problem. Seeing the PROJ version, the configure 
script seeing >= 6 chooses proj.h, but GDAL < 3 does not support proj.h. 
Consequently, sf says - ok, degrade the PROJ headers to the deprecated 
version without needing user intervention, rgdal says - user: either use 
PROJ < 6 with GDAL < 3, or explicitly use configure argument 
--with-proj_api="proj_api.h" to change the default, which is "proj.h" for 
PROJ >= 6. In 9 months, we need to make sure that all affected packages 
and workflows are migrating smoothly to PROJ >= 6 with GDAL >= 3, and 
stand-outs only risk unintended and possibly silent degradation of 
workflows.

See 
http://rgdal.r-forge.r-project.org/articles/CRS_projections_transformations.html

for details of why the migration is needed. PROJ had stood still until 
2017, and was slowly ceasing to be fit for purpose. Projections were fine, 
including ellipsoid changes in some cases, but datum shifts were always a 
cludge. GDAL and PROJ had separate *.csv files to hold projection and 
datum shift specifications; these were not as such authorised, and were 
hard to maintain. PROJ 5 brought the introduction of transformation 
pipelines, offering to avoid transformation from source to WGS84 and then 
to target. PROJ 6 and GDAL 3 brought the harmonisation of projection and 
transformation specifications as an SQLite database (proj.db) shipping 
only with PROJ, and the deep integration of GDAL and PROJ coordinate 
operation functionality. GDAL 2 simply doesn't know how to use the proj.db 
database directly, so some temporary code has been provided to bridge back 
from old GDAL to new PROJ. In particular, the new database structure 
supports conceptualisations, such as area of interest and epoch, which are 
crucial for finding coordinate operations efficiently, but which are not 
available to GDAL 2.

Work can still be done with PROJ 6 or 7 and GDAL 2, but PROJ 8 and GDAL 2 
will not work together. Most likely, accuracy is already less when using 
GDAL 2 and PROJ 6 or 7, compared to upgraded use of GDAL >= 3 and PROJ >= 
6, especially if WKT2 strings are used instead of legacy Proj4 strings in 
the current setting.
I still do not like this blocker and I still do not know if this 
combination causes serious issues in production or just limits new 
features.
Both problems as described above. The positions may end up being off by 
about 125m.
For the time being, using and linking osgeo-gdal (3.0.1) and osgeo-proj 
(7.0.1) works and can be used as a workaround until homebrew-core 
formulas catch up.

 checks OK on PROJ 7.0.1 and GDAL 2.2.4
Again, since it was maybe caused by my typo a few mails ago: The 
homebred-core gdal version is at 2.4.4 and not 2.2.4.

Really not my problem, as you should have seen, I also checked PROJ 5.2.0 
and GDAL 2.4.2. This does not impinge on the use of the deprecated API.

I see that you have posted again, I will respond to that in-thread.

Roger
On 5 Jun 2020, at 13:29, Roger Bivand wrote:

 The release candidate of rgdal_1.5-9 is ready for testing on R-forge:

 https://r-forge.r-project.org/R/?group_id=884

 Those insisting on installing on PROJ >= 6 and GDAL < 3 must use configure
 argument --with-proj_api="proj_api.h"; with this used, this version builds
 with --no-build-vignettes and installs and checks OK on PROJ 7.0.1 and
 GDAL 2.2.4 with --with-proj_api="proj_api.h".

 Otherwise checked OK with PROJ 4.8.0, 4.9.2, 4.9.3 and 5.2.0 with GDAL
 1.11.4; with PROJ 5.2.0 and GDAL 2.2.4, 2.3.2 and 2.4.2; with PROJ 6.3.2
 and GDAL 3.0.4; with PROJ 7.0.1 and GDAL 3.0.4 and 3.1.0.

 All who have indicated issues with source installs are asked to try the
 release candidate and to report back here by midnight CEST Monday 8 June.
 If no indications are forthcoming, I'll assume that problems with 1.5-8
 are resolved.

 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.Bivand at nhh.no
 https://orcid.org/0000-0003-2392-6140
 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

 _______________________________________________
 R-sig-Geo mailing list
 R-sig-Geo at r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en

rgdal release candidate 1.5-9 rev. 1000 ready for testing

Thread (23 messages)