[R-sig-Geo] Error in MtrxSet ... polygons not (all) closed

Zivan Karaman z|v@n@k@r@m@n @end|ng |rom gm@||@com
Tue Aug 20 10:27:33 CEST 2024


Hi Micha,
Thank you for sharing the file.
I’ve noticed that this polygon has only 5 vertices, while the one in the previous message has 40, so this is not exactly the same object. Both seem OK, and I was able to download and crop satellite images with CDSE without problems.
Difficult to say more without a reproducible example raising the error. 
Best,
Zivan


On 20 Aug 2024, at 09:25, Micha Silver <tsvibar using gmail.com> wrote:

Hi Zivan, Roger:
Thanks for the quick response.Here's the RDS of the polygon:
https://filebin.net/pdrazh0e4ej7el9f

and sessionInfo, etc:

> sessionInfo()
R version 4.2.2 Patched (2022-11-10 r83330)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 12 (bookworm)

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so <http://libblas.so/>.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.21.so <http://libopenblasp-r0.3.21.so/>

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_IL.UTF-8       
 [4] LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_IL.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
[10] LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] tidyr_1.3.1       sf_1.0-16         dplyr_1.1.4       lubridate_1.9.3  
 [5] RSQLite_2.3.7     CDSE_0.2.0        rOPTRAM_0.3.0.000 ggplot2_3.5.1    
 [9] knitr_1.47        terra_1.7-78      devtools_2.4.5    usethis_2.2.3    

loaded via a namespace (and not attached):
 [1] pkgload_1.3.4      bit64_4.0.5        jsonlite_1.8.8     here_1.0.1        
 [5] shiny_1.8.1.1      askpass_1.2.0      blob_1.2.4         remotes_2.5.0     
 [9] sessioninfo_1.2.2  pillar_1.9.0       glue_1.7.0         digest_0.6.35     
[13] promises_1.3.0     colorspace_2.1-0   htmltools_0.5.8.1  httpuv_1.6.15     
[17] pkgconfig_2.0.3    s2_1.1.6           purrr_1.0.2        xtable_1.8-4      
[21] scales_1.3.0       processx_3.8.4     later_1.3.2        openssl_2.2.0     
[25] timechange_0.3.0   tibble_3.2.1       proxy_0.4-27       generics_0.1.3    
[29] ellipsis_0.3.2     cachem_1.1.0       withr_3.0.0        cli_3.6.3         
[33] lutz_0.3.2         magrittr_2.0.3     mime_0.12          memoise_2.0.1     
[37] ps_1.7.6           fs_1.6.4           fansi_1.0.6        class_7.3-22      
[41] geojsonsf_2.0.3    pkgbuild_1.4.4     httr2_1.0.1        profvis_0.3.8     
[45] tools_4.2.2        lifecycle_1.0.4    stringr_1.5.1      munsell_0.5.1     
[49] callr_3.7.6        compiler_4.2.2     e1071_1.7-14       rlang_1.1.4       
[53] classInt_0.4-10    units_0.8-5        grid_4.2.2         rstudioapi_0.16.0 
[57] rappdirs_0.3.3     htmlwidgets_1.6.4  miniUI_0.1.1.1     wk_0.9.2          
[61] gtable_0.3.5       codetools_0.2-20   DBI_1.2.3          curl_5.2.1        
[65] R6_2.5.1           fastmap_1.2.0      bit_4.0.5          utf8_1.2.4        
[69] rprojroot_2.0.4    KernSmooth_2.23-24 desc_1.4.3         stringi_1.8.4     
[73] Rcpp_1.0.12        vctrs_0.6.5        tidyselect_1.2.1   xfun_0.45         
[77] urlchecker_1.0.1  
> sf_extSoftVersion()
          GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
      "3.11.1"        "3.6.2"        "9.1.1"         "true"         "true" 
          PROJ 
       "9.1.1" 

This error occurs, during a longer analysis, when I begin downloading imagery , and only with the above aoi polygon. So I'm trying to strip out all the steps in the code to identify what the cause is. No luck yet... Note: I don't think that the CDSE package is the cause.

Best regards, Micha


On 19/08/2024 21:29, Roger Bivand wrote:
> Adding the output of sessionInfo() and sf_extSoftVersion() might also help. The difficulty Zivan points out is that the structure as read is valid, but before conversion to text by dput() may have actually had non-identical first and last coordinates, because of the number of digits used. Also try putting the file created by saveRDS(aoi, ...) on a website with a link here. It would be useful to see the code in the workflow at the point of failure (you point to Error in MtrxSet, maybe also run traceback() after the failure to give more precision in where this is occurring, maybe in stars?
> 
> Hop this helps,
> 
> Roger
> 
> --
> Roger Bivand
> Emeritus Professor
> Norwegian School of Economics
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
> Roger.Bivand using nhh.no <mailto:Roger.Bivand using nhh.no>
> 
> ________________________________________
> From: R-sig-Geo <r-sig-geo-bounces using r-project.org> <mailto:r-sig-geo-bounces using r-project.org> on behalf of Zivan Karaman <zivan.karaman using gmail.com> <mailto:zivan.karaman using gmail.com>
> Sent: 19 August 2024 18:40
> To: Micha Silver
> Cc: R-sig-Geo using r-project.org <mailto:R-sig-Geo using r-project.org>
> Subject: Re: [R-sig-Geo] Error in MtrxSet ... polygons not (all) closed
> 
> Could you please provide an example of code that actually raises this error?
> Best regards,
> Zivan
> 
> 
> On 19 Aug 2024, at 16:23, Micha Silver <tsvibar using gmail.com> <mailto:tsvibar using gmail.com> wrote:
> 
> Searching for the error in the subject line returns some discussions from a few years ago. But I'm not able to overcome this error.
> 
> Here's the polygon in question:
> 
>> dput(aoi)
> structure(list(x =
> 
> structure(list(structure(list(structure(c(11.0127043, 11.0127061, 11.0134526, 11.0134554, 11.0134626, 11.0134692, 11.0134776, 11.0134813, 11.0157343, 11.0157373, 11.0157437, 11.0157495, 11.0157546, 11.0157585, 11.015761, 11.0157617, 11.0157616, 11.0157613, 11.0153992, 11.0153983, 11.0153956, 11.0153922, 11.0153869, 11.0153804, 11.0153729, 11.0153694, 11.0127478, 11.0127447, 11.0127379, 11.012732, 11.0127269, 11.0127232, 11.0127212, 11.01272, 11.0127197, 11.0126956, 11.0126958, 11.0126965, 11.0126978, 11.0127004, 11.0127043, 46.8484069, 46.8484048, 46.8476584, 46.847656, 46.8476511, 46.8476481, 46.8476461, 46.8476456, 46.8475213, 46.8475214, 46.847522, 46.8475235, 46.8475266, 46.8475311, 46.8475365, 46.8475425, 46.8475489, 46.8475519, 46.8495623, 46.8495656, 46.8495729, 46.8495788, 46.8495833, 46.8495856, 46.849587, 46.8495874, 46.8496081, 46.8496079, 46.8496069, 46.849605, 46.8496014, 46.8495965, 46.8495906, 46.8495839, 46.8495808, 46.8484309, 46.8484282, 46.8484218, 46.8484166, 46.848412, 46.8484069), dim = c(41L, 2L), dimnames = list( NULL, c("X", "Y")))), class = c("XY", "POLYGON", "sfg"))), class = c("sfc_POLYGON", "sfc"), precision = 0, bbox = structure(c(xmin = 11.0126956, ymin = 46.8475213, xmax = 11.0157617, ymax = 46.8496081), class = "bbox"), crs = structure(list( input = "EPSG:4326", wkt = "GEOGCRS[\"WGS 84\",\n ENSEMBLE[\"World Geodetic System 1984 ensemble\",\n MEMBER[\"World Geodetic System 1984 (Transit)\"],\n MEMBER[\"World Geodetic System 1984 (G730)\"],\n MEMBER[\"World Geodetic System 1984 (G873)\"],\n MEMBER[\"World Geodetic System 1984 (G1150)\"],\n MEMBER[\"World Geodetic System 1984 (G1674)\"],\n MEMBER[\"World Geodetic System 1984 (G1762)\"],\n MEMBER[\"World Geodetic System 1984 (G2139)\"],\n ELLIPSOID[\"WGS 84\",6378137,298.257223563,\n LENGTHUNIT[\"metre\",1]],\n ENSEMBLEACCURACY[2.0]],\n PRIMEM[\"Greenwich\",0,\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n CS[ellipsoidal,2],\n AXIS[\"geodetic latitude (Lat)\",north,\n ORDER[1],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n AXIS[\"geodetic longitude (Lon)\",east,\n ORDER[2],\n ANGLEUNIT[\"degree\",0.0174532925199433]],\n USAGE[\n SCOPE[\"Horizontal component of 3D system.\"],\n AREA[\"World.\"],\n BBOX[-90,-180,90,180]],\n ID[\"EPSG\",4326]]"), class = "crs"), n_empty = 0L)), row.names = 1L, class = c("sf", "data.frame"), sf_column = "x", agr = structure(integer(0), class = "factor", levels = c("constant", "aggregate", "identity"), names = character(0)))
> 
> This polygon is used as area of interest to crop Copernicus imagery that I am downloading using the {CDSE} package. (I have run this workflow successfully many times with several other aoi polygons)
> 
> I have tried:
> 
> 1- sf::st_make_valid()
> 
> 2- transforming to a UTM CRS
> 
> 3- extracting coordinates and recreating the polygon (i.e.:
> aoi_p <- st_polygon(list(st_coordinates(aoi)[,1:2]))
>     aoi3 <- aoi_p |>
>       st_sfc() |>
>       st_as_sf()
>     st_crs(aoi3) <- "EPSG:4326"
> 
> 4- buffering by a small amount
> 
> 
> The above error recurs in all cases (only with this problem polygon). Any suggestions?
> 
> 
> Thanks
> 
> 
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
> https://orcid.org/0000-0002-1128-1325
> 
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
> 
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo using r-project.org <mailto:R-sig-Geo using r-project.org>
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> 
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo using r-project.org <mailto:R-sig-Geo using r-project.org>
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
-- 
Micha Silver
Remote Sensing Lab, Sde Boker
Ben Gurion University
+972-523-665918


	[[alternative HTML version deleted]]



More information about the R-sig-Geo mailing list