0

I am experiencing some trouble with a command that used to work in the past to download and use a bounding box from the natural earth website. See this snippet

library(dplyr)
#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union
library(rnaturalearth)
library(sf)
#> Linking to GEOS 3.9.0, GDAL 3.2.2, PROJ 7.2.1; sf_use_s2() is TRUE




bb <- ne_download(type = "wgs84_bounding_box", category = "physical",
                  returnclass = "sf")
#> Warning in utils::download.file(file.path(address),
#> zip_file <- tempfile()): cannot open URL
#> 'https://www.naturalearthdata.com/http/www.naturalearthdata.com/download/110m/physical/ne_110m_wgs84_bounding_box.zip':
#> HTTP status was '404 Not Found'
#> Error in utils::download.file(file.path(address), zip_file <- tempfile()): cannot open URL 'http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/110m/physical/ne_110m_wgs84_bounding_box.zip'


sessionInfo()
#> R version 4.2.2 (2022-10-31)
#> Platform: x86_64-pc-linux-gnu (64-bit)
#> Running under: Debian GNU/Linux 11 (bullseye)
#> 
#> Matrix products: default
#> BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
#> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
#> 
#> locale:
#>  [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C              
#>  [3] LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8    
#>  [5] LC_MONETARY=en_GB.UTF-8    LC_MESSAGES=en_GB.UTF-8   
#>  [7] LC_PAPER=en_GB.UTF-8       LC_NAME=C                 
#>  [9] LC_ADDRESS=C               LC_TELEPHONE=C            
#> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       
#> 
#> attached base packages:
#> [1] stats     graphics  grDevices utils     datasets  methods   base     
#> 
#> other attached packages:
#> [1] sf_1.0-9            rnaturalearth_0.1.0 dplyr_1.0.10       
#> 
#> loaded via a namespace (and not attached):
#>  [1] Rcpp_1.0.9         compiler_4.2.2     pillar_1.8.1       highr_0.9         
#>  [5] class_7.3-20       R.methodsS3_1.8.2  R.utils_2.12.1     tools_4.2.2       
#>  [9] digest_0.6.30      lattice_0.20-45    evaluate_0.18      lifecycle_1.0.3   
#> [13] tibble_3.1.8       R.cache_0.16.0     pkgconfig_2.0.3    rlang_1.0.6       
#> [17] reprex_2.0.2       cli_3.4.1          DBI_1.1.3          yaml_2.3.6        
#> [21] xfun_0.35          fastmap_1.1.0      e1071_1.7-12       withr_2.5.0       
#> [25] styler_1.8.0       stringr_1.5.0      knitr_1.41         generics_0.1.3    
#> [29] fs_1.5.2           vctrs_0.5.1        grid_4.2.2         classInt_0.4-8    
#> [33] tidyselect_1.2.0   glue_1.6.2         R6_2.5.1           fansi_1.0.3       
#> [37] rmarkdown_2.17     sp_1.5-1           purrr_1.0.0        magrittr_2.0.3    
#> [41] units_0.8-0        htmltools_0.5.3    assertthat_0.2.1   KernSmooth_2.23-20
#> [45] utf8_1.2.2         proxy_0.4-27       stringi_1.7.8      R.oo_1.25.0

Created on 2023-01-05 with reprex v2.0.2

The bounding box is available at the link

https://www.naturalearthdata.com/http//www.naturalearthdata.com/download/110m/physical/ne_110m_wgs84_bounding_box.zip

but it seems that the ne_download command generates the wrong link. Two questions to conclude:

  1. is this a bug of the rnaturalearth package?
  2. is there any workaround if I manually download the zip file in the working directory?

Many thanks!

larry77
  • 1,309
  • 14
  • 29
  • 1
    See this github issue: https://github.com/ropensci/rnaturalearth/issues/29, apparently some people still have this issue. However if you just have one zip to download, you can do it by hand: `download.file("https://www.naturalearthdata.com/http//www.naturalearthdata.com/download/110m/physical/ne_110m_wgs84_bounding_box.zip", "foo.zip")` – bretauv Jan 05 '23 at 14:19
  • Does setting the download directory via `ne_download(..., destdir = "path/to/your/dir")` help? – I_O Jan 05 '23 at 14:19
  • Correction: your code works with the github version (`ropensci/rnaturalearth`) – bretauv Jan 05 '23 at 14:21
  • Thanks. Installing the development version is (for now) the solution. I still have an issue as it seems to me that the equator is gone in my maps, but for that I will ask a new question. – larry77 Jan 05 '23 at 16:50
  • One last question about this post: if I download the zip file locally, then how do I load what I need? I tried ne_load, but what should I load exactly? – larry77 Jan 05 '23 at 18:06

0 Answers0