Work around for rnaturalearth package crashing in Linux

[John-R-Wallace-NOAA]

Using:

  rnaturalearth::ne_countries(..., returnclass = "sf")  

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:

  R GDAL Error 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed.

The solution to this error is to set the coordinate reference system while in Linux:

 sf::st_crs(world) = 4326

The coordinate reference system solution is here:

 https://github.com/r-spatial/sf/issues/1386

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:

 blas_set_num_threads(6)
 blas_get_num_procs()

[kellijohnson-NOAA]

@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.

[John-R-Wallace-NOAA]

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 https://github.com/ropensci/rnaturalearthhires/issues/1.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nwfsc-assess/VASTWestCoast/issues/34#issuecomment-719757548, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUJPWMX3JKK2DIZOUAQ2ATSNMI5LANCNFSM4S2OA5AA.

[kellijohnson-NOAA]

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?

[John-R-Wallace-NOAA]

Seems it's up to them to fix, if they can.

I made an issue.

[kellijohnson-NOAA]

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.

[John-R-Wallace-NOAA]

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 https://github.com/nwfsc-assess/VASTWestCoast/issues/34#issuecomment-722518235, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUJPWKBNPT2Z6YTPRRG4Z3SOLNDZANCNFSM4S2OA5AA.

[kellijohnson-NOAA]

@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.

[John-R-Wallace-NOAA]

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 https://github.com/r-spatial/sf/issues/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 https://github.com/nwfsc-assess/VASTWestCoast/issues/34#issuecomment-723147171, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUJPWLGYEFR6ZIWM52ROKLSOQKHVANCNFSM4S2OA5AA.