To implement a choropleth, I looked back to some prompt code which I found on the Internet and read how to use the 'maptools' library to fortify a SpatialPolygonsDataFrame object.
The premise that I have to make is that I installed recently R 3.6.0, also because the new version of 'sp' (necessary to make 'maptools' running correctly) requires it.
From the exploration I did, it turns out that the library 'gpclib' is not anymore available for R, and got substituted by 'rgeos'.
Now, I installed the most recent versions of 'maptools', 'rgeos' and 'rgdal', and in my code I am calling them in the sequence (for some security reasons related to my company, I had to specify a local path for the library):
library(sp)
library(rgdal)
library(ggplot2)
library(rgeos)
library(maptools)
The output for the rgeos library load looks like:
"rgeos version: 0.4-3, (SVN revision 595)
GEOS runtime version: 3.6.1-CAPI-1.10.1
Linking to sp version: 1.3-1
Polygon checking: TRUE "
However when I call maptools, it says:
"Checking rgeos availability: FALSE
Note: when rgeos is not available, polygon geometry computations in maptools depend on gpclib, which has a restricted licence. It is disabled by default;
to enable gpclib, type gpclibPermit()"
So looks like maptools is not connected to rgeos. Consequently, when I try to fortify a SpatialPolygonDataFrame, I would get the error:
"Error in maptools::unionSpatialPolygons(cp, attr[, region]) :
isTRUE(gpclibPermitStatus()) is not TRUE"
Then I am not understanding, neither finding related resources, how to solve this issue.
Related
I have several issues with terra and it's connection to GDAL.
I installed terra v. 1.6.7 in R v. 4.2.1 on a Mac running Big Sur v. 11.6.8
I installed GDAL 3.2.2 from www.kyngchaos.com, located in HD/Library/Frameworks/GDAL.Framework
Issue 1: terra reports wrong GDAL version
gdal()
#[1] "3.4.2"
There is no GDAL 3.4.2 on my system (afaik).
Relatedly, gdal(lib = "proj") gives "8.2.1" but I have PROJ 7.2.1 installed.
Issue 2: terra cannot read NetCDF files
r1 <- rast("~/Downloads/soiltemp1.nc")
#Error: [rast] cannot read from /Users/db/Downloads/soiltemp1.nc
#Warning message:
#'/Users/db/Downloads/soiltemp1.nc' not recognized as a supported file format. (GDAL error 4)
whereas in terminal gdalinfo ~/Downloads/soiltemp1.nc
gives correct information on file contents.
Issue 3: terra does not list NetCDF drivers in GDAL
In R
gdal(drivers = TRUE)
the resulting report does not include NetCDF drivers
Issue 4: Cannot install terra from Github
remotes::install_github("rspatial/terra")
exits with error configure: error: proj_api.h not found in standard or given locations.
whereas proj_api.h is present in HD/Library/Frameworks/PROJ.framework/Headers/
Issue 5: sf also finds wrong Framework versions
Relatedly, library(sf) reports Linking to GEOS 3.10.2, GDAL 3.4.2, PROJ 8.2.1; sf_use_s2() is TRUE
Any clues as to what is going on, much appreciated!
Issue 1: terra reports wrong GDAL version
You have installed a binary package from CRAN. The versions of GDAL/PROJ that the package was built with are reported (and used). It does not matter what version of GDAL you may have installed on your system (if any).
I have installed "terra" on MacOS, using R 4.2.1 and the "r-release (x86_64)" CRAN binary version of terra 1.6-7 (that is, I am not using the "arm64" version). Can you confirm that you are using that version? As expected, I get the same version numbers as you do:
library(terra)
#terra 1.6-7
gdal(lib="")
# gdal proj geos
#"3.4.2" "8.2.1" "3.10.2"
Issue 2: terra cannot read NetCDF files
Issue 3: terra does not list NetCDF drivers in GDAL
I also see that
d <- gdal(drivers=TRUE)
d[d$name=="netCDF", ]
#[1] name type can vsi long.name
#<0 rows> (or 0-length row.names)
Where I would expect what I get on windows:
d[d$name=="netCDF", ]
# name type can vsi long.name
#91 netCDF raster read/write FALSE Network Common Data Format
So the package was built without the netCDF plug-in. netCDF is a fundamentally important file format for spatial data and this is a major problem that should be brought to the attention of CRAN.
A work-around is to install the development version of terra from the R universe, like this:
install.packages('terra', repos='https://rspatial.r-universe.dev’)
Issue 4: Cannot install terra from Github
See the suggestions for installing from source (using brew) on the github sites of terra and sf or elsewhere. Problems mostly arise if dependencies are not in the expected path (note the use of "configure.args" to deal with that); or if there are multiple installations of GDAL.
I am on MacOSX 11.4 Big Sur.
I have just installed on my computer https://postgresapp.com, which bundles PostgreSQL together with the needed libraries for PostGIS (proj, geos, and gdal).
I am able to use command line functions like ogr2ogr, gdalinfo etc. from my terminal, indicating that gdal is successfully installed.
I now want to install the "sf" package for R version 4.1.0. I am able to successfully install "sf", but the PostgreSQL driver is missing when I use the native installation
install.packages("sf")
According to the sf documentation and things I have read elsewhere on stack, this is a known issue for MacOSx, and the recommended workaround for this problem is to separately install gdal using homebrew or the kyngchaos binaries. However, I would like to use the gdal installation used by the postgresapp binary mentioned earlier so that there is only one installation on my computer..
According to the postgresapp installation documentation (https://postgresapp.com/documentation/install.html), the relevant paths are:
Binaries: /Applications/Postgres.app/Contents/Versions/latest/bin
Headers: /Applications/Postgres.app/Contents/Versions/latest/include
Libraries: /Applications/Postgres.app/Contents/Versions/latest/lib
Therefore, when combined with the "sf" documentation my assumption is that the following should work.
install.packages("sf", configure.args = "--with-gdal-lib=/Applications/Postgres.app/Contents/Versions/latest/lib/"
Although I receive no errors or warnings, this does not fix the problem for me as sf::st_drivers() still does not list the PostgreSQL driver as an option. Can someone please help me figure out what additional configuration arguments, if any, are needed to get sf to recognise the Postgres driver?
In my shinyapp I try to transform a sf feature (with EPSG:4326) sf::st_transform(sf_feature, crs = sf::st_crs(4839)), but when deploying on shinyapps.io an error occurs:
GDAL Error 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed.
On the shinyapps.io server the geolibraries are as follows:
GEOS 3.5.1, GDAL 2.2.2, PROJ 4.9.2
With a free account shinyapps.io blocks connections to other servers. As far as I know the sf package depends on GEOS, GDAS and other services to provide support for certain features (see the web site). That is most likely the reason, why it does not work on a free shinyapps.io account.
Solutions are obvious:
use other packages
get a paid account
Aside from that I do not think there is much you can do.
I am very new to R and so what does this mean? Does this tell me that I need to install some package named "ReadOGR"
I am following along using code written by someone else in an effort to generate a heat map. here is the current section to give some context.
setwd("C:/Users/Someone/Documents/R")
dsn <- "cb_2017_us_state_20m.shp"
layer <- "cb_2017_us_state_20m"
cb5 = readOGR(dsn, layer)
Installed rgdal to no success. Tried library(rgdal)
library(rgdal)
Loading required package: sp
rgdal: version: 1.3-9, (SVN revision 794)
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/trwilcox/Documents/R/win-
library/3.5/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/someone/Documents/R/win-
library/3.5/rgdal/proj
Linking to sp version: 1.3-1
Warning messages:
1: package ‘rgdal’ was built under R version 3.5.2
2: package ‘sp’ was built under R version 3.5.2
> cb5 = readOGR(dsn, layer)
Error in ogrInfo(dsn = dsn, layer = layer, encoding = encoding, use_iconv =
use_iconv, :
Cannot open data source
Try:
setwd("C:/Users/Someone/Documents/R")
dsn <- "cb_2017_us_state_20m.shp"
cb5 = readOGR(dsn)
Also, you can find the original files here: https://www.census.gov/geo/maps-data/data/cbf/cbf_state.html. Maybe there are some extra info there you want to use.
You have to use the one with .shp not the shp.xlm If you do not have it, download from the link above!!!
It should work now, if not, happy to help you!
I have problems installing rgdal in windows 8.1, i installed OSGeo4W (is it mandatory btw?), understood that I have to install proj4, but do not really understand what to install on page, I read some documentation, but I feel really ignorant and can't get it to work properly.
I want to access rgdal through R-studio through rgdal, but how can i tell r-studio where to look for gdal and proj4?
I am really confused, clearly need some documentation but do not understand where to look for it, because all I read did not seem useful.
rgdal is installed according to R but when I use spTransform it says
Error in spTransform(locations, CRS("+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs")) :
load package rgdal for spTransform methods
moreover in the system requirements GDAL and proj4 are needed I know that because I already installed all this in Ubuntu, with a lot of effort.
EDIT: I re-started R, now doing library(rgdal) I get this:
Carico il pacchetto richiesto: sp
rgdal: version: 0.8-16, (SVN revision 498)
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 1.11.0, released 2014/04/16
Path to GDAL shared files: C:/R/i686-pc-linux-gnu-library/3.0/rgdal/gdal
GDAL does not use iconv for recoding strings.
Loaded PROJ.4 runtime: Rel. 4.8.0, 6 March 2012, [PJ_VERSION: 480]
Path to PROJ.4 shared files: C:/R/i686-pc-linux-gnu-library/3.0/rgdal/proj
Warning message:
package ‘rgdal’ was built under R version 3.0.3
is it all ok?
EDIT 2: I updated R, just to see if that could have been the reason. Absolutely no changes in the error message.
Any help is appreciated :)
The problem solved itself after updating R and turning the pc on and off twice. no idea why but it works.