I'm working with satellite tracked animals and have a load of relocation data.
So I have my map data and relocations as SpatialPointsDataFrames and when I ask
if proj4string(map)==proj4string(locs) I get TRUE.
But when I try the count.points function as follows
cp <- count.points(locs, map)
I get the following error
Error in count.points(SpatialPoints(x), w) :
different proj4string in w and xy
Does anyone have any ideas on why this is the case?
Edit Code:
load("mydata")
map = mydata$map
map
mimage(map)
locs= mydata$relocs
locs
image(map)
points(locs, col=as.numeric(slot(locs, "data")[,1]), pch=16)
cp <- count.points(locs, map)
Reproducible example would go a long, long way here. But generally speaking R's comparison of projection strings is approximately verbatim. So if there's an extra space or so forth, it will fail.
Given the out for proj4string(map), proj4string(locs), proj4string(SpatialPoints(locs)) in the comment, particularly that proj4string(SpatialPoints(locs)) is NA, I'd say that count.points is dropping the proj4string when it changes to a SpatialPoints object. I think the way to coerce a SPDF to SP while keeping the projection string is via as(x,"SpatialPoints").... Try using trace to insert that into count.points?
Related
I always get error to this
# polygon that to be window
neighborhoods <- st_read("neighborhoods/neighborhoods.shp")
# convert CRS to planar projection as recommended by (https://stackoverflow.com/questions/59597078/use-sf-polygon-object-as-window-in-spatstat)
neighborhoods_3857 <- st_transform(neighborhoods, crs = 3857)
# point that to be PPP spatstat
trees <- st_read("trees/trees.shp")
# convert to planar projection
trees_3857 <- st_transform(trees, crs = 3857)
The problems, the "trees_3857" doesn't have dataframe columns that represent in EPSG3857 coordinates, so Feature column of "trees_3857" doesn't have x and y columns that respect to EPSG 3857
q <- ppp(x=?, y=?, win=neighborhoods_3857)
what I have done but error
z <- as.ppp(trees_3857, win=neighborhoods_3857)
Error in as.ppp.sf(trees_3857, win = neighborhoods_3857): unused argument (win = neighborhoods_3857)
Traceback:
You can get the data freely from datacamp.
https://assets.datacamp.com/production/repositories/738/datasets/96a72364e69d872645038b3a6dc7c0dbcb1114d6/neighborhoods.zip
https://assets.datacamp.com/production/repositories/738/datasets/08a3684dc4d538d59ba051a64a834166883ab5d1/trees.zip
Although you're wanting to transform your data into an object of class "ppp" from the spatstat package, the error message indicates that the problem originated in the function as.ppp.sf which is part of the sf package.
The error message says unused argument: win which means that the function did not recognise or accept the argument win.
Just to make it more challenging, the function as.ppp.sf is not documented and is not visible... By typing sf:::as.ppp.sf we can see the function body and figure out that the function has only one argument, so it does not accept any window information.
This is not the way the generic function as.ppp is designed to work in the spatstat package, so if you looked for help(as.ppp) in spatstat, it's not surprising that you got confused.
The best solution is (as Ege Rubak suggests) to convert the point coordinates and then add the window information:
z <- as.ppp(trees_3857)
Window(z) <- as.owin(neighborhoods_3857)
The conversions as.ppp and as.owin will be executed using code in sf so I can't guarantee they will work. The assignment Window(z) <- will be executed in spatstat code, see help("Window<-.ppp").
I was trying to follow this kriging exercise and ended up going on a 6 hour adventure in an attempt to create a grid file like meuse.grid in the link. I'm very new to R and geostats in general so I'd really appreciate any help. I managed to create a SpatialPolygonsDataFrame using a shapefile to get: this
cishape <- st_read("data/files/cishape.shp")
map <- as_Spatial(cishape)
plot(map)
I then managed to get this which seems to be closer to correct although the shape is now more off:
grd <- makegrid(poly, n=10000); colnames(grd) <-c("x", "y");
grd_pts <- SpatialPoints(coords=grd, proj4string = CRS(proj4string(poly)));
grd_pts_in <- grd_pts[poly,];
gdf <- as.data.frame(coordinates(grd_pts_in));
ggplot(gdf) + geom_point(aes(x=x, y=y))
I can't seem to make this work following the kriging exercise though. When I make it to the bit where:
grd <- as(grd, "SpatialPixelsDataFrame
plot(grd), I get the error: Error in .subset2(x, i, exact = exact) : subscript out of bounds. I read that it is because my spdf is actually has no data and should use SpatialPixels instead, but then I get the error Error in matrix(FALSE, ncells[2], ncells[1]) : invalid 'nrow' value (too large or NA). So then I tried SpatialPoints instead and got this chunk.
Please help, I don't know what I'm doing wrong and I feel like I'm losing my sanity.
I am working with shapefiles in R that I need to convert from polygon to raster. While the vectors look perfect when plotted, when converted to raster using 'rasterize' they produce erroneous horizontal lines. Here is an example of the problem:
Here is a generic example of the code that I am using (sorry that I cannot upload the data itself as it is proprietary):
spdf.dat <- readOGR("directory here", "layer here")
# Plot polygon
plot(spdf.dat, col = 'dimgrey', border = 'black')
# Extract boundaries
ext <- extent(spdf.dat)
# Set resolution for rasterization
res <- 1
# determine no. of columns from extents and resolution
yrow <- round((ext#ymax - ext#ymin) / res)
xcol <- round((ext#xmax - ext#xmin) / res)
# Rasterize base
rast.base <- raster(ext, yrow, xcol, crs = projection(spdf.dat))
# Rasterize substrate polygons
rast <- rasterize(spdf.dat, rast.base, field = 1, fun = 'min', progress='text')
plot(rast, col = 'dimgrey')
Does this seem to be a problem with the source data or the rasterize function? Has anyone seen this sort of error before? Thank you for any advice that you can provide.
To make it official so the question is considered answered, I'll copy my commented responses here. You can therefor accept it.
When I look at your figure, it seems to me that the problematic appearing lines in the raster are situated at the same latitude of some islands. Try to removes these islands from your dataset. If the problem disappear, you'll know that your data is the problem and where in your data the problem lies.
An other option is to try the gdalUtils package which has a function: gdal_rasterize. Maybe gdal is less exigent in the input data.
I had a similar problem rasterizing the TIGER areal water data for the San Juan Islands in Washington State , as well as for Maui - both of these spatial polygon data frames at the default resolution returned by package Tigris using a raster defined by points 1 arc-second of lat/lon apart. There were several horizontal stripes starting at what appeared to be sharp bends of the coastline. Various simplification algorithms helped, but not predictably, and not perfectly.
Try package Velox, which takes some getting used to as it uses Reference Classes. It probably has size limits, as it uses the Boost geometry libraries and works in memory. You don't need to understand it all, I don't. It is fast compared to raster::rasterize (especially for large and complicated spatial lines dataframes), although I didn't experience the hundred-fold speedups claimed, I am not gonna complain about a mere factor of 10 or 20 speedup. Most importantly, velox$rasterize() doesn't leave streaks for the locations I found where raster::rasterize did!
I found that it leaves a lot of memory garbage, and when converting large rasterLayers derived from velox$rasterize, running gc() was helpful before writing the raster in native R .grd format (in INT1S format to save disk space).
Just as a follow up to this question based on my experiences.
The horizontal lines are as a result of these 'islands' as described above. However, it only occurs if the polygon is 'multi-part'. If 'islands' are distinct polygons rather than a separate part of one polygon, then raster:rasterize() works fine.
I am trying to use a modified version of the R code found in the following link:
Latitude Longitude Coordinates to State Code in R
To test the code, I created the following formal arguments:
mapping = "state"
pointsDF = data.frame(x = c(-88.04607, -83.03579), y = c(42.06907, 42.32983))
latlong2state(pointsDF, mapping)
The code returned the following:
[1] "Illinois" NA
The first coordinate set returns a correct answer, i.e. "Illinois". However, when I input the 2nd coordinate set (i.e. -83.03579, 42.32983) into an online converter, I get the following:
Downtown, Detroit, MI, USA
(http://www.latlong.net/Show-Latitude-Longitude.html)
Running the code again but changing the second coordinate from 42.32983 to 43.33 puts the point in the state of Michigan.
When using the "world" map as my formal argument for the "mapping" variable, the code returns "USA". I have been struggling for days to figure this out and have had no luck. I have played around with SpatialPointDataFrames, various projections, and looked into the state polygon objects themselves. I am using R version 3.3.1 on a Windows 7 system. I think the data point in question may be falling on a border line. In which case, I think an "NA" would be expected. The code I used is below.
Code Used:
library(sp)
library(maps)
library(maptools)
library(rgdal)
latlong2state = function(pointsDF, mapping) {
local.map = map(database = mapping, fill = TRUE, col = "transparent", plot = FALSE)
IDs = sapply(strsplit(local.map$names, ":"), function(x) x[1])
maps_sp = map2SpatialPolygons(map = local.map, ID = IDs,
proj4string = CRS("+proj=longlat +datum=WGS84"))
pointsSP = SpatialPoints(pointsDF,
proj4string = CRS("+proj=longlat +datum=WGS84"))
indices = over(x = pointsSP, y = maps_sp)
mapNames = sapply(maps_sp#polygons, function(x) {x#ID})
mapNames[indices]
}
I am only two months in to learning R and love the language thus far. This has been the first time I could not find an answer. I would really appreciate an help provided on the matter!!!
Firstly, the issue is not due to the point lying on a border. In fact, over() would not return NA for a point on a border, but rather "if a point falls in multiple polygons, the last polygon is recorded."
NA denotes a point that does not fall in a polygon. We can zoom in on your map to see this is the case
plot(local.map, xlim = c(-83.2, -82.8), ylim=c(42.2,42.6), type="l")
polygon(local.map, col="grey60")
points(local.map)
points(pointsDF[2,], col="red")
The point falls outside the contiguous USA in Canada, according to the polygons provided by maps::map(). Why would this be the case when other maps, as you say, locate this point on the USA side of the border? I do not think this is a projection issue, because we are using the same WGS84 geographic coordinates for the polygons and the points. It seems, therefore, that the polygons themselves that are provided by maps::map() may be wrong.
We can check this by comparing to polygons from another source. I downloaded the US census departments highest resolution state boundaries from http://www2.census.gov/geo/tiger/GENZ2015/shp/cb_2015_us_state_500k.zip. Then,
shp.path <- "C:/Users/xxx/Downloads/cb_2015_us_state_500k/cb_2015_us_state_500k.shp"
states <- readOGR(path.expand(shp.path), "cb_2015_us_state_500k")
plot(states, xlim = c(-83.2, -82.8), ylim=c(42.2,42.6))
points(pointsDF[2,], col="red")
gets us this map in which we see that the point is inside the US boundary:
The solution I recommend therefore, is to use these better resolution, more reliable boundary polygons, particularly if you are interested to accurately resolve points close to borders.
I am working with shapefiles in R, one is point.shp the other is a polygon.shp.
Now, I would like to intersect the points with the polygon, meaning that all the values from the polygon should be attached to the table of the point.shp.
I tried overlay() and spRbind in package sp, but nothing did what I expected them to do.
Could anyone give me a hint?
With the new sf package this is now fast and easy:
library(sf)
out <- st_intersection(points, poly)
Additional options
If you do not want all fields from the polygon added to the point feature, just call dplyr::select() on the polygon feature before:
library(magrittr)
library(dplyr)
library(sf)
poly %>%
select(column-name1, column-name2, etc.) -> poly
out <- st_intersection(points, poly)
If you encounter issues, make sure that your polygon is valid:
st_is_valid(poly)
If you see some FALSE outputs here, try to make it valid:
poly <- st_make_valid(poly)
Note that these 'valid' functions depend on a sf installation compiled with liblwgeom.
If you do overlay(pts, polys) where pts is a SpatialPointsDataFrame object and polys is a SpatialPolygonsDataFrame object then you get back a vector the same length as the points giving the row of the polygons data frame. So all you then need to do to combine the polygon data onto the points data frame is:
o = overlay(pts, polys)
pts#data = cbind(pts#data, polys[o,])
HOWEVER! If any of your points fall outside all your polygons, then overlay returns an NA, which will cause polys[o,] to fail, so either make sure all your points are inside polygons or you'll have to think of another way to assign values for points outside the polygon...
You do this in one line with point.in.poly fom spatialEco package.
library(spatialEco)
new_shape <- point.in.poly(pts, polys)
from the documentation: point.in.poly "intersects point and polygon feature classes and adds polygon attributes to points".