ERROR 4: Unable to open EPSG support file gcs.csv. Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.

[ailich]

I ran through the example in the package installation instructions and got an error when running the line

out = run_qgis(alg = "qgis:polygoncentroids",
               params = params,
               load_output = TRUE)
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.

The code does still produce an output but the proj4 strings are not identical.

crs(ger)
# CRS arguments:
#   +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0 
crs(out)
# [1] "+proj=longlat +datum=WGS84 +no_defs" 

I also get the same error when running qgis_session_info

qgis_session_info()
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# $qgis_version
# [1] "2.18.15"
# 
# $gdal
# [1] "2.2.3"
# 
# $grass6
# [1] FALSE
# 
# $grass7
# [1] "7.2.2"
# 
# $saga
# [1] "2.3.2"

R.version
               _                           
platform       x86_64-w64-mingw32          
arch           x86_64                      
os             mingw32                     
system         x86_64, mingw32             
status                                     
major          3                           
minor          4.4                         
year           2018                        
month          03                          
day            15                          
svn rev        74408                       
language       R                           
version.string R version 3.4.4 (2018-03-15)
nickname       Someone to Lean On 

[pat-s]

Hi, RQGIS is pretty much dead. There is almost no platform on which you can install QGIS2 anymore.

Also you are still running R3.4 on a 32-bit system. I highly recommend you upgrade R and try out RQGIS3.

[ailich]

Thanks. I'll give RQGIS3 with a newer version of R a go and see if things work then. I'm currently running R3.4 on a 64bit system. I also have R 3.6 installed, but have 3.4 set as my default because there's some scripts I have some analyses I'm in the middle of that use sample which is implemented differently in newer versions of R.

[ailich]

I updated R and then installed QGIS 3 via the OSGeo4w installer, but now I get a different error regardless of whether I try RQGIS or RQGIS3.

qgis_session_info() 
Error in py_get_attr_impl(x, name, silent) : 
  AttributeError: module '__main__' has no attribute 'RQGIS3'

qgis_session_info() 
Error in py_run_string_impl(code, local, convert) : 
  NameError: name 'RQGIS' is not defined

[jannes-m]

Please run the following code and report back the output:

library("RQGIS3")
set_env()

set_env() will tell you to specify a path to a QGIS installation (Windows only) in case you have installed multiple QGIS versions or if you have not installed it under C:.

Regarding your first issue. The gcs.csv issue is well-known and can just be ignored or resolved by setting manually the GDAL_DATA environment variable (see r-spatial/RQGIS#80 and r-spatial/RQGIS#113).

By default, QGIS uses "+proj=longlat +datum=WGS84 +no_defs", which is st_crs(4326).

[ailich]

The code currently outputs this

set_env()
Trying to find QGIS in C:/OSGEO4~1
$root
[1] "C:/OSGeo4W64"

$qgis_prefix_path
[1] "C:/OSGeo4W64/apps/qgis"

$python_plugins
[1] "C:/OSGeo4W64/apps/qgis/python/plugins"

$platform
[1] "Windows"

I do have both QGIS 2 and 3 installed so it may be an issue regarding finding the path to the correct version. Also I don't know if this is relevant, but OsGeo4w installed several different versions of QGIS2 and QGIS3 (stable, developer, with GRASS), some of which open fine as a standalone program and some of which won't open, so it might be connecting to a version that failed to install correctly.

[jannes-m]

And both QGIS2 and QGIS3 can be found under C:/OSGeo4W64? If this is the case, I would suggest to remove QGIS2 since it is not worth the effort to update the RQGIS3 code accordingly since pretty soon nobody will use QGIS2 anymore.

[ailich]

Thank you for your help so far. I deleted the OsGeo4w folder and did a fresh express install with QGIS, GDAL, and GRASS checked. This fixed the "Error in py_run_string_impl(code, local, convert) : NameError: name 'RQGIS' is not defined" issue and allowed me to run through the example, though I did still get that same "ERROR 4" message as well as several warning messages. Additionally although GRASS is installed an located at "C:\OSGeo4W64\apps\grass\grass76" RQGIS3 fails to detect its existence.

# attach packages
library("raster")
library("rgdal")

# download German administrative areas 
ger = getData(name = "GADM", country = "DEU", level = 1)
# ger is of class "SpatialPolygonsDataFrame"

# attach RQGIS
library("RQGIS3")

# set the environment, i.e. specify all the paths necessary to run QGIS from 
# within R
set_env() #set_env tries to find all the paths necessary to run QGIS from within R.

# Trying to find QGIS in C:/OSGEO4~1
# $root
# [1] "C:/OSGeo4W64"
# 
# $qgis_prefix_path
# [1] "C:/OSGeo4W64/apps/qgis"
# 
# $python_plugins
# [1] "C:/OSGeo4W64/apps/qgis/python/plugins"
# 
# $platform
# [1] "Windows"

qgis_session_info()

# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\qgis\python\qgis\utils.py:737: DeprecationWarning:
#   
#   Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
# 
# $gdal
# [1] "2.4.1"
# 
# $grass7
# [1] FALSE
# 
# $qgis_version
# [1] "3.10.0-A Coruña"
# 
# $saga
# [1] "2.3.2"

R.version
# platform       x86_64-w64-mingw32          
# arch           x86_64                      
# os             mingw32                     
# system         x86_64, mingw32             
# status                                     
# major          3                           
# minor          6.1                         
# year           2019                        
# month          07                          
# day            05                          
# svn rev        76782                       
# language       R                           
# version.string R version 3.6.1 (2019-07-05)
# nickname       Action of the Toes 

find_algorithms(search_term = "centroid", name_only = TRUE)
# [1] "native:centroids"                               
# [2] "qgis:generatepointspixelcentroidsalongline"     
# [3] "qgis:generatepointspixelcentroidsinsidepolygons"
# [4] "saga:polygoncentroids" "

get_usage(alg = "native:centroids")
# Centroids (native:centroids)
# 
# This algorithm creates a new point layer
# with points representing the centroid of the geometries in an input layer.
# 
# The attributes associated to each point in the output layer are the same ones associated to the original features.
# 
# 
# ----------------
#   Input parameters
# ----------------
#   
#   INPUT: Input layer
# 
# Parameter type:   QgsProcessingParameterFeatureSource
# 
# Accepted data types:
#   - str: layer ID
# - str: layer name
# - str: layer source
# - QgsProcessingFeatureSourceDefinition
# - QgsProperty
# - QgsVectorLayer
# 
# ALL_PARTS: Create point on surface for each part
# 
# Parameter type:   QgsProcessingParameterBoolean
# 
# Accepted data types:
#   - bool
# - int
# - str
# - QgsProperty
# 
# OUTPUT: Centroids
# 
# Parameter type:   QgsProcessingParameterFeatureSink
# 
# Accepted data types:
#   - str: destination vector file
# e.g. d:/test.shp
# - str: memory: to store result in temporary memory layer
# - str: using vector provider ID prefix and destination URI
# e.g. postgres:… to store result in PostGIS table
# - QgsProcessingOutputLayerDefinition
# - QgsProperty
# 
# ----------------
#   Outputs
# ----------------
#   
#   OUTPUT:  <QgsProcessingOutputVectorLayer>
#   Centroids

params<- get_args_man(alg = "native:centroids")
params
#>$INPUT
#>[1] "None"
#>
#>$ALL_PARTS
#>[1] "False"
#>
#>$OUTPUT
#>[1] "None"

params$INPUT = ger
params$OUTPUT = file.path(tempdir(), "ger_coords.shp")
out = run_qgis(alg = "native:centroids",
               params = params,
               load_output = TRUE)
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# $OUTPUT
# [1] "C:/Users/socce/AppData/Local/Temp/RtmpWWjLo9/ger_coords.shp"

[ailich]

Additionally, the error seems to break rgdal's functionality as well as limiting qgis operations to data with coordinates in terms of unprojected WGS84 coordinates.

library(rgdal)
head(rgdal::make_EPSG())
# code                                               note
# 1 3819                                           # HD1909
# 2 3821                                            # TWD67
# 3 3824                                            # TWD97
# 4 3889                                             # IGRS
# 5 3906                                         # MGI 1901
# 6 4001 # Unknown datum based upon the Airy 1830 ellipsoid
# prj4
# 1 +proj=longlat +ellps=bessel +towgs84=595.48,121.69,515.35,4.115,-2.9383,0.853,-3.408 +no_defs
# 2                                                         +proj=longlat +ellps=aust_SA +no_defs
# 3                                    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
# 4                                    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
# 5                            +proj=longlat +ellps=bessel +towgs84=682,-203,480,0,0,0,0 +no_defs
# 6                                                            +proj=longlat +ellps=airy +no_def

library(RQGIS3)
set_env()
head(make_EPSG()) #Works after loading RQGIS3 and running set_env
# code                                               note
# 1 3819                                           # HD1909
# 2 3821                                            # TWD67
# 3 3824                                            # TWD97
# 4 3889                                             # IGRS
# 5 3906                                         # MGI 1901
# 6 4001 # Unknown datum based upon the Airy 1830 ellipsoid
# prj4
# 1 +proj=longlat +ellps=bessel +towgs84=595.48,121.69,515.35,4.115,-2.9383,0.853,-3.408 +no_defs
# 2                                                         +proj=longlat +ellps=aust_SA +no_defs
# 3                                    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
# 4                                    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
# 5                            +proj=longlat +ellps=bessel +towgs84=682,-203,480,0,0,0,0 +no_defs
# 6                                                            +proj=longlat +ellps=airy +no_defs

qgis_session_info()
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\qgis\python\qgis\utils.py:737: DeprecationWarning:
#   
#   Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
# 
# $gdal
# [1] "2.4.1"
# 
# $grass7
# [1] FALSE
# 
# $qgis_version
# [1] "3.10.0-A Coruña"
# 
# $saga
# [1] "2.3.2"

head(rgdal::make_EPSG())
# Error in make_EPSG() : Error opening epsg file

# attach packages
library("raster")
library("rgdal")

# download German administrative areas 
ger = getData(name = "GADM", country = "DEU", level = 1)
# ger is of class "SpatialPolygonsDataFrame"

# attach RQGIS
library("RQGIS3")
set_env() #set_env tries to find all the paths necessary to run QGIS from within R.

ger2<- spTransform(ger, CRS("+init=epsg:32631")) #Transform to UTM 31N

out<- run_qgis(alg = "native:centroids",
                INPUT = ger2,
                OUTPUT = file.path(tempdir(), "ger2_coords.shp"),
                load_output = TRUE)
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\qgis\python\qgis\utils.py:737: DeprecationWarning:
#   
#   Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
# 
# Error: invalid crs: +init=epsg:32631 +proj=utm +zone=31 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0, reason: no system list, errno: 22

ls() #out variable not created
# [1] "ger"  "ger2"

[jannes-m]

Thanks for reporting back! Unfortunately, I don't have a Windows installation right now on my system, but probably will have one next week, so that I can take a look. Can you report back the following:

library("rgdal")
Sys.getenv("GDAL_DATA")
# then attach RQGIS3 and check again
library("RQGIS3")
qgis_session_info()
Sys.getenv("GDAL_DATA")

Can you also try the following starting a new R session:

library("RQGIS3")
qgis_session_info()
rgdal::make_EPSG()

If this still results in an error, one could try to set the GDAL_DATA environment variable manually. @raff-k have you set the GDAL_DATA variable locally within R using Sys.setenv() or have you done so globally via system settings or the command line?

[jannes-m]

I will also transfer this issue to the https://github.com/jannes-m/RQGIS3 repository.

[ailich]

The error or connecting to QGIS does seem to change the path of GDAL_DATA

library("rgdal")
Sys.getenv("GDAL_DATA")
# [1] "C:/Users/socce/Documents/R/win-library/3.6/rgdal/gdal"

# then attach RQGIS3 and check again
library("RQGIS3")
qgis_session_info()
# Trying to find QGIS in C:/OSGEO4~1
# ERROR 4...
Sys.getenv("GDAL_DATA")
# [1] "C:/OSGeo4W64/share/gdal;C:/Users/socce/Documents/R/win-library/3.6/sf/gdal"

#Restarting R session...
library("RQGIS3")
qgis_session_info()
# Trying to find QGIS in C:/OSGEO4~1
# ERROR 4...
rgdal::make_EPSG()
# Error in rgdal::make_EPSG() : Error opening epsg file

[ailich]

Manually resetting GDAL_DATA via Sys.setenv() in R does reset the path, but rgdal functions still fail to execute.

library("rgdal")
Sys.getenv("GDAL_DATA")
# [1] "C:/Users/socce/Documents/R/win-library/3.6/rgdal/gdal"
gdal_path<- Sys.getenv("GDAL_DATA") #Store original path

# then attach RQGIS3 and check again
library("RQGIS3")
qgis_session_info()
# Trying to find QGIS in C:/OSGEO4~1
# ERROR 4...
Sys.getenv("GDAL_DATA")
# [1] "C:/OSGeo4W64/share/gdal;C:/Users/socce/Documents/R/win-library/3.6/sf/gdal"

Sys.setenv(GDAL_DATA=gdal_path) #Reset to original path
Sys.getenv("GDAL_DATA") #Works
# [1] "C:/Users/socce/Documents/R/win-library/3.6/rgdal/gdal"

head(rgdal::make_EPSG())
# Error in make_EPSG() : Error opening epsg file

[jannes-m]

Yes, RQGIS3 modifies environmental variables as does rgdal. Run Sys.getenv("GDAL_DATA") before attaching RQGIS3 or rgdal and this will return most likely "". When being attached, rgdal reads the environment variable if already set but seems to have problems if more than one path is stored. So to make make_EPSG() work again, you would have to reset the environmental variables again. However, in doing so, it is quite likely that RQGIS3 won't work after this:

library("rgdal")
#> Loading required package: sp
#> rgdal: version: 1.4-7, (SVN revision 845)
#>  Geospatial Data Abstraction Library extensions to R successfully loaded
#>  Loaded GDAL runtime: GDAL 2.2.3, released 2017/11/20
#>  Path to GDAL shared files: C:/Users/jannes.muenchow/Documents/R/win-library/3.6/rgdal/gdal
#>  GDAL binary built with GEOS: TRUE 
#>  Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493]
#>  Path to PROJ.4 shared files: C:/Users/jannes.muenchow/Documents/R/win-library/3.6/rgdal/proj
#>  Linking to sp version: 1.3-1
proj = Sys.getenv("PROJ_LIB")
gdal = Sys.getenv("GDAL_DATA")
library("RQGIS3")
#> Loading required package: reticulate
qgis_session_info()
#> Trying to find QGIS in C:/
#> $gdal
#> [1] "2.4.1"
#> 
#> $grass7
#> [1] FALSE
#> 
#> $qgis_version
#> [1] "3.4.13-Madeira"
#> 
#> $saga
#> [1] "2.3.2"
# running make_EPGS will fail now
head(make_EPSG())
#> Error in make_EPSG(): Error opening epsg file

# Resetting the environmental variables, makes it work again
Sys.setenv("PROJ_LIB"=proj)
Sys.setenv("GDAL_DATA"=gdal)
head(make_EPSG())
#>   code                                               note
#> 1 3819                                           # HD1909
#> 2 3821                                            # TWD67
#> 3 3824                                            # TWD97
#> 4 3889                                             # IGRS
#> 5 3906                                         # MGI 1901
#> 6 4001 # Unknown datum based upon the Airy 1830 ellipsoid
#>                                                                                            prj4
#> 1 +proj=longlat +ellps=bessel +towgs84=595.48,121.69,515.35,4.115,-2.9383,0.853,-3.408 +no_defs
#> 2                                                         +proj=longlat +ellps=aust_SA +no_defs
#> 3                                    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
#> 4                                    +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
#> 5                            +proj=longlat +ellps=bessel +towgs84=682,-203,480,0,0,0,0 +no_defs
#> 6                                                            +proj=longlat +ellps=airy +no_defs

^{Created on 2019-11-08 by the reprex package (v0.3.0)}

Any thoughts on this @rsbivand?

[rsbivand]

Because rgdal and sf (and maybe lwgeom) are built using static linking on Windows, it is necessary to ship metadata files in the CRAN binary packages, not relying on any external binary installs of GDAL or PROJ. The code run on startup is:

  assign(".rgdal_old.PROJ_LIB", Sys.getenv("PROJ_LIB"), envir=.RGDAL_CACHE)
  assign(".rgdal_old.GDAL_DATA", Sys.getenv("GDAL_DATA"), envir=.RGDAL_CACHE)
  assign(".rgdal_old.NEEDED", FALSE, envir=.RGDAL_CACHE)
  if (file.exists(system.file("proj/nad.lst", package = "rgdal")[1])) {
    Sys.setenv("PROJ_LIB"=system.file("proj", package = "rgdal")[1])
    Sys.setenv("GDAL_DATA"=system.file("gdal", package = "rgdal")[1])
    assign(".rgdal_old.NEEDED", TRUE, envir=.RGDAL_CACHE)
  } else if (.Platform$OS.type == "windows") {
    assign(".rgdal_OSGeo4W", Sys.getenv("OSGEO4W_ROOT"), envir=.RGDAL_CACHE)
  }

and on unloading:

  if (get(".rgdal_old.NEEDED", envir=.RGDAL_CACHE)) {
    Sys.setenv("PROJ_LIB"=get(".rgdal_old.PROJ_LIB", envir=.RGDAL_CACHE))
    Sys.setenv("GDAL_DATA"=get(".rgdal_old.GDAL_DATA", envir=.RGDAL_CACHE))
  }

If RQGIS could set an extra environment variable on load, and rgdal/(sf, others) could do the same, we'd "know" who had set what. My guess would be that load order matters. The OSGEO4W_ROOT environment variable is not actually used anywhere else in rgdal. rgdal etc. probably behave as though they are free-standing. Possibly the logic for rgdal on Windows should test for Sys.getenv("OSGEO4W_ROOT") first, then if found check that the metadata directories look sane, otherwise point to the metadata directories bundled with the package. What do you think?

[jannes-m]

@rsbivand Sounds good! In fact, RQGIS3 is setting the OSGEO4W_ROOT variable. So this would work, if rgdal is being attached after RQGIS3 but not the other way round. Additionally, the metadata directories have to look sane. If rgdal overwrites GDAL_DATA and PROJ_LIB set by RQGIS3, I pretty much doubt that (R)QGIS3 still works. But I can try it when I am sitting again in front of a Windows machine, i.e., on Monday :-)

[ailich]

It seems like if you convert an object from sp to sf you can use QGIS operations for projected data (instead of just WGS84 lat/long) albeit with some error messages. RQGIS3 doesn't break all rgdal functions. It seems to mess with the rgdal::make_EPSG function's ability to properly autodetect the file argument.

library("raster")
library("rgdal")
library("sf")

ger = getData(name = "GADM", country = "DEU", level = 1)

library("RQGIS3")
set_env() 

ger_reproj_sp<- spTransform(ger, CRS("+init=epsg:32631")) #projected sp object
ger_reproj_sf<- st_transform(st_as_sf(ger), 32631) #projected sf object

out_sp<- run_qgis(alg = "native:centroids",
               INPUT = ger_reproj_sp,
               OUTPUT = file.path(tempdir(), "ger_sp_coords.shp"),
               load_output = TRUE)
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\qgis\python\qgis\utils.py:737: DeprecationWarning:
#   
#   Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
# 
# Error: invalid crs: +init=epsg:32631 +proj=utm +zone=31 +datum=WGS84 +units=m +no_defs +ellps=WGS84 +towgs84=0,0,0, reason: no system list, errno: 22

exists("out_sp") #FALSE (operation fails)

out_sf<- run_qgis(alg = "native:centroids",
                INPUT = ger_reproj_sf,
                OUTPUT = file.path(tempdir(), "ger_sf_coords.shp"),
                load_output = TRUE)
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# $OUTPUT
# [1] "C:/Users/socce/AppData/Local/Temp/RtmpUzv8O1/ger_sf_coords.shp"

exists("out_sf") #TRUE
crs(out_sf) #"+proj=utm +zone=31 +datum=WGS84 +units=m +no_defs"

rgdal::make_EPSG() #Error in rgdal::make_EPSG() : Error opening epsg file
rgdal::writeOGR(obj = ger_reproj_sp, dsn = getwd(), layer = "test", driver = "ESRI Shapefile") #Works

[ailich]

There also is still an issue of connecting with grass7 as mentioned in issue #13. Grass commands work from QGIS (when the "with grass" version is opened), and the path to grass7 exists. I'm wondering if this is potentially related to the new behavior of QGIS.

library("RQGIS3")
set_env()
# Trying to find QGIS in C:/OSGEO4~1
# $root
# [1] "C:/OSGeo4W64"
# 
# $qgis_prefix_path
# [1] "C:/OSGeo4W64/apps/qgis"
# 
# $python_plugins
# [1] "C:/OSGeo4W64/apps/qgis/python/plugins"
# 
# $platform
# [1] "Windows"

qgis_session_info()
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# ERROR 4: Unable to open EPSG support file gcs.csv.  Try setting the GDAL_DATA environment variable to point to the directory containing EPSG csv files.
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\Python37\lib\importlib\_bootstrap.py:219: RuntimeWarning: numpy.ufunc size changed, may indicate binary incompatibility. Expected 192 from C header, got 216 from PyObject
# return f(*args, **kwds)
# C:\OSGeo4W64\apps\qgis\python\qgis\utils.py:737: DeprecationWarning:
#   
#   Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
# 
# $gdal
# [1] "2.4.1"
# 
# $grass7
# [1] FALSE
# 
# $qgis_version
# [1] "3.10.0-A Coruña"
# 
# $saga
# [1] "2.3.2"

dir.exists("C:/OSGeo4W64/apps/grass/grass76") #TRUE
dir.exists("C:/OSGeo4W64/apps/qgis/python/plugins/processing/algs/grass7") #TRUE

[rsbivand]

Because of ongoing important development work involving rgdal, no patches for this trivial issue will be forthcoming any time soon. If you need to use rgdal on Windows with OSGEO4W, you might try installing from source against the OSGEO4W PROJ and GDAL libraries, but nobody has tried that as far as I know for a decade. The underlying problem is that the CRAN rgdal binary package makes defensive assumptions about users, and bundles the PROJ and GDAL data files for the provided PROJ 4 and GDAL 2 libraries.

Your problem then appears to be that your rgdal is built with a different version of GDAL, where gcs.csv is present in the GDAL_DATA directory, but most likely the GDAL version in OSGEO4W is GDAL 3, which no longer uses this file. If so, you are collateral in major changes taking place in all software using PROJ & GDAL, and you have to stay on the PROJ < 6 and GDAL < 3 side in any running session. I don't think that released QGIS expects PROJ >= 6 and GDAL >= 3, but I have built QGIS from source, and the development version (in August) did use them. Until the dust settles, maybe there is no way forward.

[ailich]

@rsbivand that's reasonable. Initially I thought that all of rgdal's functionality was breaking and that was preventing using any sort of projections, which is important for my work since I use a UTM grid, but that was not the case. There still does appear to be an issue with RQGIS and using projections for sp objects and linking to grass7 libraries though.