Closed russelldj closed 1 week ago
For internal collaborators, the file can be found at /ofo-share/repos-derek/str-disp-experiments/scripts/MVMT/5_analysis_80m/5_analysis_valley_debugging.ipynb
. The error is GEOSException: TopologyException: Ring edge missing at 527307.302348 4296860.2430250002
.
Resolved by 8d5889e by setting the precision of the geodataframe prior to doing the dissolve
operation. This is controlled by the dissolve_precision
argument of label_polygons
. For some reason, it seems like if you lower the precision too much (increase the value for set_precision) it errors. So maybe the precision at this step needs to be more precise than in the previous steps, where it is set to 10^-6
This is still coming up with different input data. I'm not quite sure how to make a more robust solution to this. In the worst case, it might involve testing a variety of dissolve_precisions
within this method and catching the errors as needed.
I wonder if there is a "quick fix" solution like a small positive buffer followed by a negative buffer of the same amount, or a python equivalent of sf
's st_make_valid()
.
Pandas implements make_valid
as well and it's used here. The buffering might work, but the issues is this object is a collection of potentially millions of triangles so it might be slow.
I think this might be due to approximately-colinear lines in these triangles. Fortunately, we compute the ratio of 2d-3d area, so it might be possible to just filter them out. Would you be interested in taking on this issue?
I'd be happy to try to address this. I probably won't get to it for about a month though, unfortunately, due to prioritizing the data catalog and field season prep.
@youngdjn are you still interested in working on this? I'm actually not sure if the issue is still around, so we can table it until we find another dataset where it's an issue if you'd like.
OK, let's table it until we see if it comes up again.
Closed for the time being
This issue was brought up by @youngdjn when trying to label polygons on the Valley (internal) dataset. It likely stems from near-parallel lines when aggregating the 2D projection of mesh faces. It might be helpful to use some of the numerical stability logic from
batched_unary_union
or consider directly using this function.This issue should be replicated and further documented before we put any work toward it.