-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
st_union and floating point coordinates #1855
Comments
|
seems to work; using |
This is super helpful! RTFM but properly! I was setting the precision with a negative exponent... having somehow or other misread or misinterpreted the details. My bad. It would be nice if there was a package setting like I have a hard time imagining situations where (say) 1e8 would not be a sensible default precision (see: https://xkcd.com/2170/), but as you note this is a GEOS thing not But I can completely understand if a package option/switch doesn't make sense for general architectural reasons of some kind. My current use-case is rather off the wall. |
I like the idea of a globally settable precision value different from zero; feel free to raise it as an issue, or propose a PR. |
Apologies in advance for how long this post became, when it is really just a non-urgent request for clarification
Not so much an issue as a question about how floating point affects
st_union
(and I guess other spatial operations) insf
. Normally for 'dissolve' or union, I would use (and have used) thegroup_by() %>% summarise()
pipeline, but I'm working on a project where I am making a lot ofsf
geometries from scratch, translating, rotating, intersecting, unioning them and so on.Today I came across a situation where
st_union
fails to dissolve two simple polygons that (at least mathematically!) are touching. Here's some code that reproduces the problem.Now when I union these polygons I get a MULTIPOLYGON which when plotted is clearly two polygons
For what it's worth integer coordinate squares dissolve as expected.
So is this purely a floating point numbers issue? Inspection of the coordinates of corresponding points in
p1
andp2
reveals they do indeed not overlap:but... well... the differences in the coordinates are ~1e-16, And for what it's worth the same operation in
rgeos::gUnion
dissolves the two squares as I would hope.I can't find a way to change the tolerance that
st_union
applies. I poked around withst_set_precision()
a bit but this didn't seem to get me any closer to fixing my problem. I've experienced presumably related issues when for example I close the square above by generating coordinates at 45, 135... 405 degrees where the error that the polygon is not closed is raised. Presumably because:I get it that floating point is unsafe for high-precision operations like these, but is there no tolerance setting I can use to avoid having to round coordinates to arbitrary precision as I go along? Or why does
sf
not apply the machine epsilon?I know I can use
st_snap
but it's not obvious to me how to use this to union a set of polygons (keep in mind I am making and manipulating geometries not working with datasets much of the time, so the
group_by() %>% summarise()
option is not in play). I've had fewer problems when dealing with projected coordinates insf
datasets, so I wonder if there is some under-the-hood magic happening in such cases? I don't usually work withsf
for handling 'pure geometry` in this way, so perhaps my inexperience is showing and there is a switch I can flip to fix things?The text was updated successfully, but these errors were encountered: