Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

circles() fails when polygons cross the antimeridian #4

Closed
nbtjaden opened this issue Mar 8, 2019 · 2 comments
Closed

circles() fails when polygons cross the antimeridian #4

nbtjaden opened this issue Mar 8, 2019 · 2 comments

Comments

@nbtjaden
Copy link

nbtjaden commented Mar 8, 2019

When points lie close to +/-180° of longitude, it may happen that a polygon created by circles() has to cross the antimeridian. Depending on how "dissolve" is set, the command then either fails with

Error in rgeos::gUnaryUnion(ci@polygons) :
TopologyException: Input geom 0 is invalid: Self-intersection at or near point X Y

or the resulting polygons are broken. I hope the following example illustrates the issue:

library(dismo)
library(maptools)
data("wrld_simpl")

# example locations
locations <- SpatialPoints(coords=cbind(c(0,0,0,0, 175, -160), c(10, 30, 50, 70,0,-10)),
                    proj4string = CRS("+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0"))

plot(wrld_simpl)
points(locations, pch=19, col="blue")

# this gives an error because of self-intersection
buffer <- circles(p = locations, d = 1500000, lonlat=TRUE)

# this exercutes:
buffer <- circles(p = locations, d = 1500000, lonlat=TRUE, dissolve=FALSE)
# but looks weird:
plot(wrld_simpl)
plot(buffer, add=TRUE, col="red")
points(locations, pch=19, col="blue")
# ... and leads to problems later on
gUnaryUnion(buffer@polygons)

I've spend numerous hours now trying to find an alternative, somehow work around the issue, or manually clean up the broken output. But it's always one step forward and two steps back, so I hope this can somehow be fixed at the source …

@nbtjaden
Copy link
Author

Just for the record: A viable work-around using st_wrap_dateline() from the sf package has been provided at stackoverflow, so personally I'm good for now.

@rhijmans
Copy link
Member

I am sorry that it took me so long, but this has now been fixed in the development version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants