Closed courtiol closed 3 years ago
In passing, I noticed that the content of union_sf
and union_s2
are equivalent (beyond the differences shown in red in the plot), but interestingly the polygons are not sorted in the same order.
I have no idea if that matters for some people or not... (it does not for me).
> str(union_s2)
Classes ‘sf’ and 'data.frame': 1 obs. of 1 variable:
$ geometry:sfc_MULTIPOLYGON of length 1; first list element: List of 13
..$ :List of 1
.. ..$ : num [1:880, 1:2] 17.1 17.1 17.1 17.1 17.1 ...
..$ :List of 1
.. ..$ : num [1:126, 1:2] 56.1 56.1 56.1 56.1 56 ...
..$ :List of 1
.. ..$ : num [1:6244, 1:2] -2.8 -2.81 -2.81 -2.81 -2.82 ...
..$ :List of 1
.. ..$ : num [1:4, 1:2] 0.108 0.108 0.112 0.108 53.632 ...
..$ :List of 1
.. ..$ : num [1:4, 1:2] -4.55 -4.55 -4.55 -4.55 52.79 ...
..$ :List of 1
.. ..$ : num [1:1670, 1:2] 18.8 18.8 18.8 18.8 18.8 ...
..$ :List of 1
.. ..$ : num [1:20803, 1:2] 11.8 11.8 11.8 11.8 11.8 ...
..$ :List of 1
.. ..$ : num [1:4, 1:2] 14.3 14.3 14.3 14.3 56 ...
..$ :List of 1
.. ..$ : num [1:6649, 1:2] 21.7 21.7 21.7 21.7 21.7 ...
..$ :List of 1
.. ..$ : num [1:7, 1:2] 21.8 21.8 21.8 21.8 21.8 ...
..$ :List of 1
.. ..$ : num [1:7, 1:2] 11.8 11.8 11.8 11.8 11.8 ...
..$ :List of 1
.. ..$ : num [1:7, 1:2] 17.6 17.6 17.6 17.6 17.6 ...
..$ :List of 1
.. ..$ : num [1:3927, 1:2] 20.9 24.6 29.7 33.8 48.3 ...
..- attr(*, "class")= chr [1:3] "XY" "MULTIPOLYGON" "sfg"
- attr(*, "sf_column")= chr "geometry"
- attr(*, "agr")= Factor w/ 3 levels "constant","aggregate",..:
..- attr(*, "names")= chr(0)
> str(union_sf)
sfc_MULTIPOLYGON of length 1; first list element: List of 12
$ :List of 1
..$ : num [1:9, 1:2] -4.71 -4.7 -4.7 -4.7 -4.7 ...
$ :List of 1
..$ : num [1:6246, 1:2] -2.79 -2.79 -2.79 -2.78 -2.78 ...
$ :List of 1
..$ : num [1:7, 1:2] 11.8 11.8 11.8 11.8 11.8 ...
$ :List of 1
..$ : num [1:20804, 1:2] 17.6 17.6 17.6 17.7 17.7 ...
$ :List of 1
..$ : num [1:131, 1:2] 12.5 12.5 12.5 12.5 12.5 ...
$ :List of 1
..$ : num [1:880, 1:2] 17.1 17.1 17.1 17.1 17.1 ...
$ :List of 1
..$ : num [1:7, 1:2] 17.6 17.6 17.6 17.6 17.6 ...
$ :List of 1
..$ : num [1:1670, 1:2] 18.8 18.8 18.8 18.8 18.8 ...
$ :List of 1
..$ : num [1:3927, 1:2] 20 20 20 19.9 19.9 ...
$ :List of 1
..$ : num [1:7, 1:2] 21.8 21.8 21.8 21.8 21.8 ...
$ :List of 1
..$ : num [1:6649, 1:2] 21.8 21.8 21.8 21.8 21.8 ...
$ :List of 1
..$ : num [1:126, 1:2] 56.1 56.1 56.1 56.1 56.1 ...
- attr(*, "class")= chr [1:3] "XY" "MULTIPOLYGON" "sfg"
Yes, being valid on R2 doesn't mean something is valid on S2. This might help:
> st_is_valid(st_make_valid(st_set_precision(mask_future, 1e6)))
[1] TRUE TRUE TRUE TRUE TRUE TRUE
close?
I have not check it yet, but yes let's close this for now. Many thanks!
@courtiol Did you check it?
I have a similar issue. st_is_valid(st_make_valid(st_set_precision(mydata, 1e6)))
does not solve it. It worked fine on 0.9-8.
I did and on the data above it does work:
unzip("~/Downloads/mask_future.zip", exdir = "~/Downloads/")
library(sf)
#> Linking to GEOS 3.9.1, GDAL 3.3.1, PROJ 8.1.0
mask_future <- st_read("~/Downloads/mask_future.shp")$geometry
#> Reading layer `mask_future' from data source
#> `/home/alex/Downloads/mask_future.shp' using driver `ESRI Shapefile'
#> Simple feature collection with 6 features and 22 fields
#> Geometry type: MULTIPOLYGON
#> Dimension: XY
#> Bounding box: xmin: -5.185555 ymin: 17.47994 xmax: 56.09433 ymax: 63.4352
#> Geodetic CRS: WGS 84
st_union(st_make_valid(st_set_precision(mask_future, 1e6)))
#> Geometry set for 1 feature
#> Geometry type: MULTIPOLYGON
#> Dimension: XY
#> Bounding box: xmin: -5.185555 ymin: 17.47994 xmax: 56.09433 ymax: 63.4352
#> Geodetic CRS: WGS 84
#> MULTIPOLYGON (((17.10703 57.33286, 17.09697 57....
Created on 2021-08-16 by the reprex package (v2.0.0)
I have noticed that
st_union()
no longer works with some of the polygons I have when s2 is on.This seems to be because the polygons have some genuine glitches, which make the internal call to
st_as_s2.sfc()
crash.Using
st_as_s2()
with the argumentrebuild = TRUE
seems to avoid the problem (see below), butst_union()
won't forward the parameters till that call.They probably is a better way altogether to fix polygons (ideally a warning or the doc could suggest what to do), but I thought it could be useful to point to somewhat unexcepted behaviours caused by activating S2.
I am attaching the files used here: mask_future.zip