As of sf version 0.9.0, st_write_db() and st_read_db() got defunct. The functions had the nice argument geom_name = 'wkb_geometry' which allowed a user to set the name of the simple feature column of the newly created table.
Can I still do this somehow with st_write() or do I have to do this in a separate call? E.g. for Postgres: ALTER TABLE x REANAME COLUMN geometry TO geom;
Maybe with the layer_options = argument? However I don't know where to look up its possibilities?
Local machine
sf_0.9-7 with GEOS 3.8.0, GDAL 3.0.4, PROJ 7.0.0.
Server
PostgreSQL 9.6.20
PostGIS
POSTGIS="2.3.3 r15473" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.3, released 2017/11/20" LIBXML="2.9.4" LIBJSON="0.12.1" TOPOLOGY RASTER
sf uses GDAL to read and write data. The GDAL documentation contains for every driver the list of possible layer creation options. For Postgres this can be found under https://gdal.org/drivers/vector/pg.html#layer-creation-options
Based on this layer_options="GEOMETRY_NAME=wkb_geometry" should do the trick for you.
Related
I am trying to read a shapefile
library(sf)
wards <- read_sf("Shape_files/benguluru_ward_boundaries_reprojected.shp")
and I am getting this error
Error in CPL_get_z_range(obj, 3) : z error - expecting three columns;
I googled it and it seems it has to do with z-dimension but I couldn't find a solution. How to solve this? Thanks in advance.
Edit:
This is what I am getting when I load the sf package
> library(sf)
Linking to GEOS 3.9.3, GDAL 3.5.2, PROJ 8.2.1; sf_use_s2() is TRUE
you can get the files here
Edit2: I was able to solve this by running extract z values as mentioned here and there dropping it while exporting the layer. I am able to read that new layer without any issues.
MOTIVATION
I am wanting to build a PACKAGE-RANKING algorithm based on various measures of optimality.
I was reading something today [tidyverse], that pointed to the following command:
ELEMENT
tools::package_dependencies(package="liteq", recursive=TRUE)[["liteq"]]
Which could easily be wrapped into a function (WORK IN PROGRESS):
help.packageInfo = function(package, key="dependencies", ...)
{
# number of authors
# function to PARSE DESCRIPTION FILE
tools::package_dependencies(package=package, recursive=TRUE)[[package]];
}
EXAMPLE [GOOD]
help.packageInfo("digest");
EXAMPLE [BAD]
help.packageInfo("tidyverse");
HOW to extract DESCRIPTION file data
Package: tools
Version: 4.2.1
Priority: base
Title: Tools for Package Development
Author: R Core Team
Maintainer: R Core Team <do-use-Contact-address#r-project.org>
Contact: R-help mailing list <r-help#r-project.org>
Description: Tools for package development, administration and documentation.
License: Part of R 4.2.1
Suggests: codetools, methods, xml2, curl, commonmark, knitr, xfun,
mathjaxr
NeedsCompilation: yes
Built: R 4.2.1; x86_64-w64-mingw32; 2022-06-23 09:27:10 UTC; windows
ExperimentalWindowsRuntime: ucrt
The description file can tell me lots of things (number of authors, number of suggests, imports, requires) even for NON-CRAN repositories I have installed onto my system. I am trying to ask, is their a library/function that you have seen that parses the DESCRIPTION file into a list object?
In the comments it is pointed out that
pkg <- "stats"
packageDescription(pkg)
is even shorter.
If what you have is not an installed package but rather just a DESCRIPTION file then use the read.dcf shown below.
Assuming that the package is installed get the path to the DESCRIPTION file and then use read.dcf giving a one row matrix whose columns hold the data.
pkg <- "stats"
desc_path <- system.file("DESCRIPTION", package = pkg)
m <- read.dcf(desc_path)
That could be used as is or converted into various forms depending on what you want.
DF <- as.data.frame(m) # one row data.frame
stack(DF) # 2 column data.frame
as.list(DF) # named list
unlist(DF) # named character vector
I'm in R v 4.0.4 - sp v 1.4-5, and rgdal 1.5-23. I'm loading a shapefile using the rgdal package and then trying to simply apply spTransform() but I'm getting a ridiculous set of warnings that I can't get rid of. Anyone have any insight on this?
options("rgdal_show_exportToProj4_warnings"="none")
library(rgdal)
library(sp)
## Shapefile has a projection of WGS84
X <- readOGR(dsn=".", layer="myshapefile.shp")
UTM30 <- sf::st_crs(32630)$proj4string
transf <- spTransform(X,UTM30)
############################################################
### This warning gets repeated tens to hundreds of times ###
proj_as_proj_string: C:\PostgreSQL\13\share\contrib\postgis-3.1\proj\proj.db lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It comes from another PROJ installation.
proj_as_wkt: C:\PostgreSQL\13\share\contrib\postgis-3.1\proj\proj.db lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It comes from another PROJ installation.
proj_create: C:\PostgreSQL\13\share\contrib\postgis-3.1\proj\proj.db lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It comes from another PROJ installation.
Anyone come across this yet and managed to squash it?
Cheers
Found this explanation from rgdal:
The 'GDAL' and 'PROJ' libraries are external to the package, and, when installing the package from source, must be correctly installed first; it is important that 'GDAL' < 3 be matched with 'PROJ' < 6. From 'rgdal' 1.5-8, installed with to 'GDAL' >=3, 'PROJ' >=6 and 'sp' >= 1.4, coordinate reference systems use 'WKT2_2019' strings, not 'PROJ' strings.
I'm trying to transform the CRS of polygons that cross the dateline using the sf package following the example here, but get the warning
Warning message:
In CPL_wrap_dateline(x, options, quiet) :
GDAL Error 6: GEOS support not enabled.
which causes the final part of the code to fail:
library(sf)
#Linking to GEOS 3.6.1, GDAL 2.1.3, proj.4 4.9.3
point1 <- st_point(c(-179.5, -50))
point2 <- st_point(c(0, -30))
points <- st_sfc(point1, point2, crs = 4236)
points_trans <- st_transform(points, 32621)
circles <- st_buffer(points_trans, 100000)
circles_latlon <- st_transform(circles, 4326)
circles_latlon2 <- st_wrap_dateline(circles_latlon, options = c("WRAPDATELINE=YES"))
I've looked online on how to enable GEOS support (or perhaps just updating GDAL), but can't find a simple explanation. Any suggestions?
I'm running MACOS 10.13.6; R 3.5.0 (checked also with 3.5.1, but same issue).
I finally solved this by
downloading and installing the updated GDAL and GEOS libraries from here
downloading the source file of sf from cran
(re)installing sf using R CMD INSTALL sf_0.6-3.tar.gz --configure-args='--with-gdal-config=/Library/Frameworks/GDAL.framework/Versions/2.2/unix/bin/gdal-config -with-geos-config=/Library/Frameworks/GEOS.framework/Versions/3B/unix/bin/geos-config'. Note that I needed to (re)add the .gz extension as apple conveniently hides it.
I am receiving a sporadic error message with importShapefile in PBSmapping (version 2.63.37) in RStudio (0.97.318), running R version 2.15.2, platform: i386-w64-mingw32/i386 (32-bit). I also received the error while running previous versions of R and RStudio.
> ST6 = importShapefile("Data/pvi_stat_2002_utm.shp", projection="UTM", readDBF = TRUE)
Error in 1:nrow(dbf) : argument of length 0
> traceback()
2: cbind(1:nrow(dbf), dbf)
1: importShapefile("Data/pvi_stat_2002_utm.shp", projection = "UTM",readDBF = TRUE)
I only receive this error occasionally - perhaps 1 in every 10 times that I run the code. But once the error occurs in a session, it occurs repeatedly and will not successfully implement the command until I have closed R completely and reopened it. On one occasion I had to reboot the computer for it to work, as successive reopening of R did not help.
I thought it might be a memory issue but sometimes I will get the error when no objects are in the workspace. And usually the code runs fine even if I have large objects loaded. In response to the error I have removed all objects from the workspace and even followed with gc(), but to no avail.
This is the only shapefile with which I have received the error but as it is the only one that I use with regularity and since I can not predict when the error will occur, my efforts with other shapefiles are inconclusive. Not sure about uploading a shapefile to Stack Overflow. The zipped file is about 9MB.
Have a look in the folder where your shapefile is. Is there actually a .dbf file? If there is, it sounds like it is empty or corrupted, or misnamed. Are you expecting your shapefile to have polygons with attributes. Can you try importShapefile(... readDBF = FALSE )? Maybe you can make our data available through a dropbox link or something?
Alternatively have you tried rgdal:::readOGR or, my personal favourite, maptools:::readShapePoly(). I personally find readShapePoly() to be extremely robust and there are methods for coercing a SpatialPolygonsDataFrame from sp to a PolySet from PBS.
If you really must use PBS have you tried...
require( maptools )
require( sp )
myshp <- readShapePoly("Data/pvi_stat_2002_utm")
myshpPBS <- SpatialPolygons2PolySet( myshp )
I am assuming that there is a .prj file with your shapefile, describing the projection information?
I'm using R-3.0.1 and PBS Mapping 2.66.53 with the NAVO Divisions shapefile from http://www.nafo.int/about/overview/gis/Divisions.zip. On Windows 7 x86_64 and OS X Snow Leopard (using macports R built for x86_64), the .dbf is being read properly, but it
sometimes fails using RHEL 5.9:
> library("PBSmapping", lib.loc="/home/gwhite/R/x86_64-unknown-linux-gnu-library/3.0")
-----------------------------------------------------------
PBS Mapping 2.66.53 -- Copyright (C) 2003-2013 Fisheries and Oceans Canada
[...]
-----------------------------------------------------------
> library("rgeos", lib.loc="/home/gwhite/R/x86_64-unknown-linux-gnu-library/3.0")
rgeos version: 0.2-19, (SVN revision 394)
GEOS runtime version: 3.3.8-CAPI-1.7.8
Polygon checking: TRUE
> layer='Divisions'
> divs = importShapefile(layer, projection='LL')
Error in 1:nrow(dbf) : argument of length 0
Using readDBF=F does allow the shapefile data to be read:
> divs = importShapefile(layer, projection='LL', readDBF=F)
So far, importShapefile() has been working in a freshly started R session.