Work around for rnaturalearth package crashing in Linux #34
Comments
Closed
|
@John-R-Wallace-NOAA sorry VASTWestCoast is not working on tantalus. Did you try to debug the installation of rnaturalearth first before making a work around? I am getting the packages from CRAN and it might be that we just need to get them using a remote in the description file that points to github. I say this because others are successfully using the package on linux, see here. |
|
I installed 'rnaturalearth' from GitHub with the same result (see
below). The issue you linked to is for installing the 'hires' add-on.
The CRAN version of the 'hires' add-on did work fine for me under Win 10.
Using returnclass = "sp" doesn't crash R, but that doesn't work in the
plot_westcoast() function.
…--------------------------------------------------------------------
world <- rnaturalearth::ne_countries(scale = "medium", returnclass =
"sf")
*** caught segfault ***
address (nil), cause 'unknown'
Traceback:
1: CPL_crs_from_input(x)
2: make_crs(x)
3: st_crs.character(x@projargs)
4: st_crs(x@projargs)
5: st_crs.CRS(x@proj4string)
6: st_crs(x@proj4string)
7: append(lst, list(crs = st_crs(x@proj4string), precision = precision))
8: do.call(st_sfc, append(lst, list(crs = st_crs(x@proj4string),
precision = precision)))
9: structure(sfc, bbox = bb)
10: handle_bbox(do.call(st_sfc, append(lst, list(crs =
st_crs(x@proj4string), precision = precision))), x)
11: st_as_sfc.SpatialPolygons(sp::geometry(x), ...)
12: st_as_sfc(sp::geometry(x), ...)
13: st_as_sf.Spatial(x)
14: st_as_sf(x)
15: ne_as_sf(spdf[filter, ], returnclass)
16: rnaturalearth::ne_countries(scale = "medium", returnclass = "sf")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
On 10/30/2020 12:39 PM, Kelli Johnson wrote:
@John-R-Wallace-NOAA <https://github.com/John-R-Wallace-NOAA> sorry
VASTWestCoast is not working on tantalus. Did you try to debug the
installation of rnaturalearth first before making a work around? I am
getting the packages from CRAN and it might be that we just need to
get them using a remote in the description file that points to github.
I say this because others are successfully using the package on linux,
see here <ropensci/rnaturalearthhires#1>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUJPWMX3JKK2DIZOUAQ2ATSNMI5LANCNFSM4S2OA5AA>.
|
|
I just linked the issue b/c they were using linux, not because it was the exact same problem. But the output that you provided is really helpful. Thank you. Do you think that this should be reported to the package authors so that they know there is an issue, or maybe it is something that we can solve? |
|
Seems it's up to them to fix, if they can. I made an issue. |
|
I am not certain why this is an issue on the linux server when this example / question indicates that the same call on their linux computer ran just fine. @John-R-Wallace-NOAA do you think that it has to do with R version 4.0? I would like to find an actual fix to this using the rnaturalearth package b/c VAST itself uses this package. So any work around means that VAST plotting functions would not work, which seems poor practice on our part. |
|
Looking at this again, I am re-seeing this warning on Tantalus:
library(sf)
Linking to GEOS 3.7.2, GDAL 2.4.1, PROJ 4.8.0
WARNING: different compile-time and runtime versions for GEOS found:
Linked against: 3.7.2-CAPI-1.11.2 b55d2125 compiled against:
3.4.2-CAPI-1.8.2
It is probably a good idea to reinstall sf, and maybe rgeos and
rgdal too
When I first saw this warning I tested 'sf' with some examples and it
worked fine, but perhaps that is the culprit.
VAST works fine on Tantalus. From what I see, VAST doesn't have <
returnclass = "sf" > as an argument in the
rnaturalearth::ne_countries(). It doesn't need the return class to be
'sf' since the plotting is done with sp::plot() and not ggplot().
Here is the West Coast using sp::plot():
map_data = rnaturalearth::ne_countries(scale = 'medium')
# map_data = sp::spTransform(map_data, CRSobj =
sp::CRS("+proj=longlat +datum=WGS84"))
sp::plot(map_data, col = 'green', xlim = c(-127.15, -116.50), ylim
= c(31.90, 49.50) )
I get no warnings on Tantalus with those 2 or 3 lines of code, but I do
get warnings under Win 10.
Using ggplot2() is nice though and does work fine on Tantalus.
Getting sf, GEOS, and GDAL to work on Tantalus was a real pain, and
wouldn't be changed for at least a year I would say.
Although, the 'world' generated under Win 10 is not changing that fast
and doesn't affect anything running under Win 10, I'm fine with leaving
the work-around in a branch for the next year.
…On 11/5/2020 9:19 AM, Kelli Johnson wrote:
I am not certain why this is an issue on the linux server when this
example / question
<https://stackoverflow.com/questions/59808375/how-to-get-ride-of-polygon-borders-using-geom-sf-in-ggplot2>
indicates that the same call on their linux computer ran just fine.
@John-R-Wallace-NOAA <https://github.com/John-R-Wallace-NOAA> do you
think that it has to do with R version 4.0? I would like to find an
actual fix to this using the rnaturalearth package b/c VAST itself
uses this package. So any work around means that VAST plotting
functions would not work, which seems poor practice on our part.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUJPWKBNPT2Z6YTPRRG4Z3SOLNDZANCNFSM4S2OA5AA>.
|
|
@John-R-Wallace-NOAA perhaps this issue about sf and geos will be helpful. I would much rather fix the installation for required packages rather than have multiple threads of code to maintain. |
|
Nothing worked from that issue, but I did find the function that the
trace-back stops at:
CPL_crs_from_input <- function(input)
{
.Call("_sf_CPL_crs_from_input", PACKAGE = "sf", input)
}
Traceback:
1: CPL_crs_from_input(x)
2: make_crs(x)
3: st_crs.character(x@projargs)
4: st_crs(x@projargs)
5: st_crs.CRS(x@proj4string)
6: st_crs(x@proj4string)
7: append(lst, list(crs = st_crs(x@proj4string), precision = precision))
8: do.call(st_sfc, append(lst, list(crs = st_crs(x@proj4string),
precision = precision)))
9: structure(sfc, bbox = bb)
10: handle_bbox(do.call(st_sfc, append(lst, list(crs =
st_crs(x@proj4string), precision = precision))), x)
11: st_as_sfc.SpatialPolygons(sp::geometry(x), ...)
12: st_as_sfc(sp::geometry(x), ...)
13: st_as_sf.Spatial(x)
14: st_as_sf(x)
15: ne_as_sf(spdf[filter, ], returnclass)
16: ne_countries(scale = "medium", returnclass = "sf")
It makes sense that it is a call to run C code. So it looks like
rnaturalearth is not setting something up correctly, under Linux, in the
object they are sending to have sf make a CRS (Coordinate Reference System).
…-J
On 11/6/2020 7:40 AM, Kelli Johnson wrote:
@John-R-Wallace-NOAA <https://github.com/John-R-Wallace-NOAA> perhaps
this issue <r-spatial/sf#844> about sf and
geos will be helpful. I would much rather fix the installation for
required packages rather than have multiple threads of code to maintain.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUJPWLGYEFR6ZIWM52ROKLSOQKHVANCNFSM4S2OA5AA>.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using:
in plot_westcoast() crashes Linux, so I created the 'world' data in R under Win 10 and loaded that into Linux.
Then I got this error:
The solution to this error is to set the coordinate reference system while in Linux:
The coordinate reference system solution is here:
I created the 'Linux' branch with an option in plot_westcoast() to load 'world_hires.RData' from the package's 'Data' folder when not running under Windows and to set the coordinate reference system. There is no change when running under Windows.
If using a Linux server with R-MKL don't forget to limit the number of threads to a reasonable number using:
The text was updated successfully, but these errors were encountered: