Closed jamesgrecian closed 1 year ago
James
Thank you for filing this issue and, especially, for the reprex.
I think I have an answer for what is happening, but I don't fully understand why.
The issue appears tied to your use of a custom proj4string (+proj=merc +units=km +datum=WGS84 +no_defs
). I've seen recent discussions regarding changes in sf
and other spatial packages that, now, support newer versions of PROJ. My understanding was that proj4strings were discouraged for describing crs but would still be supported. Maybe your use of units=km
is no longer supported?? I'll try to so some additional reading and sleuthing to learn more on this topic. There should be a way to specify a custom proj4string as you do.
Regardless, though, the following adjustments to your code seem to work. I'm simply relying on the ESPG code of 3857 for mercator instead of your proj4string. Note, this creates geometry that is the same as your x/y coordinates but in meters.
# load world shapefile for visgraph generation
world_mc <- ne_countries(scale = "medium", returnclass = "sf") %>%
st_transform(., crs = 3857) %>%
sf::st_make_valid()
# convert track to sf for pathroutr
trs_sf <- trs_df %>%
sf::st_as_sf(coords = c("lon", "lat"), crs = 4326) %>%
sf::st_transform(3857)
Thanks @jmlondon that's solved the issue, although as you say it's a strange error given the crs info is the same.
@jmlondon I know this issue was closed, but if it helps at all, I ran into the same issue specifying "crs = 102007" (Hawaii Albers Equal Area Conic). I've used this projection before when running pathroutr but didn't run into any issues regarding crs' until today. Using the ESPG 3857 code solved the problem.
R version 4.0.5 (2021-03-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19041)
Matrix products: default
locale:
[1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252 LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] stplanr_0.8.2 pathroutr_0.1.1 concaveman_1.1.0 janitor_2.1.0 ggspatial_1.1.5 ggplot2_3.3.3 crawl_2.2.3 mapview_2.9.9
[9] sf_0.9-8 purrr_0.3.4 lubridate_1.7.10 dplyr_1.0.6
loaded via a namespace (and not attached):
[1] tidyr_1.1.3 jsonlite_1.7.2 shiny_1.6.0 assertthat_0.2.1 sp_1.4-5 stats4_4.0.5
[7] yaml_2.2.1 pillar_1.6.1 lattice_0.20-41 glue_1.4.2 uuid_0.1-4 digest_0.6.27
[13] promises_1.2.0.1 snakecase_0.11.0 colorspace_2.0-1 leaflet.providers_1.9.0 htmltools_0.5.1.1 httpuv_1.6.1
[19] pkgconfig_2.0.3 raster_3.4-10 xtable_1.8-4 mvtnorm_1.1-1 scales_1.1.1 webshot_0.5.2
[25] brew_1.0-6 svglite_2.0.0 satellite_1.0.2 later_1.2.0 tibble_3.1.1 proxy_0.4-25
[31] farver_2.1.0 generics_0.1.0 ellipsis_0.3.2 withr_2.4.2 cli_2.5.0 magrittr_2.0.1
[37] crayon_1.4.1 mime_0.10 maptools_1.1-1 fansi_0.4.2 foreign_0.8-81 class_7.3-18
[43] tools_4.0.5 geosphere_1.5-10 nabor_0.5.0 lifecycle_1.0.0 stringr_1.4.0 V8_3.4.2
[49] munsell_0.5.0 packrat_0.5.0 compiler_4.0.5 e1071_1.7-6 systemfonts_1.0.2 tinytex_0.31
[55] rlang_0.4.11 classInt_0.4-3 units_0.7-1 grid_4.0.5 leafpop_0.1.0 rstudioapi_0.13
[61] htmlwidgets_1.5.3 igraph_1.2.6 crosstalk_1.1.1 proj4_1.0-10.1 leafem_0.1.6 base64enc_0.1-3
[67] gtable_0.3.0 codetools_0.2-18 curl_4.3.1 DBI_1.1.1 R6_2.5.0 rgeos_0.5-5
[73] fastmap_1.1.0 utf8_1.2.1 KernSmooth_2.23-18 stringi_1.5.3 Rcpp_1.0.6 vctrs_0.3.8
[79] png_0.1-7 leaflet_2.0.4.1 tidyselect_1.1.1 xfun_0.22
Thanks for reporting this, @makratofil ... I'm going to re-open this issue and create a new issue to track progress.
@makratofil one thing to try, in your case, is to specify the CRS as 'ESRI:102007' and see if that works.
@jmlondon just got back to this analysis, and the 'ESRI:102007' works! thanks!
@makratofil and @jamesgrecian ... I just wanted to follow up and let you know that I think the recent updates I've made (now, in version 0.2.1) may have fixed these issues.
I still don't understand why these issues were happening, but I suspect the switch to {sfnetworks} from {stplanr} may have had the added benefit of fixing this issue.
If either of you have a chance to test and confirm on your end, then I'll close this issue.
When using the
pathroutr
package to pull some simulated tracks out to sea I often get the following:Error: arguments have different crs
I can't work out the origin of the error as the land polygon and movement path have the same crs info. Any help would be greatly appreciated!Here's a reprex that should recreate the error using a small sample of my data, sessionInfo below.
Created on 2021-05-20 by the reprex package (v2.0.0)