Closed jeffreyhanson closed 6 years ago
@mdsumner had the great idea of using sf::st_simplify
, and it would appear that it can resolve the problem when simplifying the data to 100 m.
y <- x %>% sf::st_set_precision(1e+10) %>%
lwgeom::st_make_valid() %>% # attempt to fix geometries
sf::st_transform(3395) %>% # transform to Mercator crs
sf::st_simplify(dTolerance = 100) %>% # simplify to 100 m tolerance
lwgeom::st_make_valid() %>%
sf::st_difference()
So, I'm not sure if this pull request is still warranted. I'll leave this PR open until someone else has looked at this, but I'm happy to close it.
Thank you very much for merging this and fixing the integration problems!
Thanks for contributing this, Jeffrey.
Yeah, it's a bit a tricky one: lwgeom_grid
or lwgeom_grid_in_place
are not "exported" by liblwgeom, so if you depend on liblwgeom to be a system library (e.g. coming with ubuntugis-unstable, or with PostGIS installation) it's "not there": header file missing, not in the compiled code (on my ubuntu 17.04). This may have to do with liblwgeom not having such a clear status as autonomous library, the way gdal, geos and proj.4 are for instance - it's essentially a PostGIS component we've pulled out. This might improve over time.
Hi,
I'm submitting this pull request to add the functionality for snapping geometries to grids (using the proposed function
st_snap_to_grid
). This function aims to mimic theST_SnapToGrid
function in PostGIS. It is merely a thin wrapper to thelwgeom_grid_in_place
function in lblwgeom.The motivation behind this pull request is two-fold. Firstly, geometries with high precision can cause problems during geoprocessing, which may not necessarily be resolved using
lwgeom::st_make_valid
, and so snapping geometries to a grid can be an effective strategy for resolving these issues (see below for example, note that this has also been observed in equivalent PostGIS functions: 1, 2, 3). Secondly, snapping geometries to a grid might be a computationally cheap method for simplifying complex geometries (though, as far as I know, this remains to be tested).Below is an example showing the primary motivation for this function. First, we will fetch some particularly messy spatial data from Protected Planet.
Now, we will attempt to clean the data by (i) fixing invalid geometries using existing sf and lwgeom functions, and (ii) removing overlapping geometries.
As we can see, this attempt to clean the data did not work. Now, we will try adding in the proposed
lwgeom::st_snap_to_grid
function to the data cleaning process.This approach is not ideal, given that we had to snap the data to a 15 meter grid and introduce a potentially non-negligible level of spatial error into the data set. I had tried smaller grid sizes but this did not resolve the error encountered in
sf::st_difference()
. Despite this limitation, however, the data is now "clean" and can actually be used for subsequent processing.I would love to hear if anyone has any suggestions for improving this pull request or for cleaning this data set using the existing functionality provided by sf or lwgeom.