-
Notifications
You must be signed in to change notification settings - Fork 15
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
Reject/clean non-simple polygons #407
Comments
In the case of your first example, I'd say that the users are responsible if they produce "incorrect" annotations. But you have a point with the magic wand tool (and possibly the polygon brush?). These tools should definitely avoid this issue. We should add a check that "cleans" the automatically generated polygons. |
Just as a note on relative impact here - in summary whilst this does affect area value calculations in BIIGLE, at a technical level, it's less likely to have a large scale real world impact. As far as I can see (which is consistent with how this issue interacts with other geometry applications), with self intersecting polygons, one part of the self-intersecting polygon becomes an "negative-area" in effect that deducts its own area from the overall calculations. Generally it is the smaller area that is deducted, though I'm not sure if this would be consistently the case in BIIGLE. In the case of the large bowtie in the top image in the initial comment, this has a large impact as both parts of the polygon are relatively similar in area and so when one is deducted from the other the "total" area is small. However, in the real world, I'd expect such self-intersections to be relatively small (at the edges of the polygon as in the magic wand tool), and thus contribute a relatively low area to deduct from the much larger "correct" polygon. Thus impact on area calculations should hopefully be pretty low! |
I also experienced some of these problems. In python this can be achieved using the shapely library. However, this is unfeasible to do. In JS we could try to use jsts (https://github.com/bjornharrtell/jsts), which does the same thing (I guess). There is also an example using OpenLayers (https://openlayers.org/en/latest/examples/jsts.html). In shapely I implemented a heuristic:
|
JTS recently implemented a GeometryFixer class I believe (locationtech/jts#704) , but it doesn't look like it has (yet) been ported into jsts. |
There are also reported cases of identical subsequent coordinates (for line strings), possible because of double clicks. Maybe we can clean these up as well. I'll add a summary to the first post. |
@mzur These would be automatically cleaned up by jsts if used. |
The following error occurred on an annotation created with the magic wand when the polygon eraser tool should be applied to it: "Each LinearRing of a Polygon must have 4 or more Positions." This is probably related to this issue. I'll classify this as a bug. |
It is possible to create nonsensical annotations, e.g. a polygon annotation with four identical vertices (by clicking four times on the same spot). The line string shape is probably also affected by this. Also check the other shapes.
Implement a client-side check that disallows annotations with all identical coordinates (except point, circle). Just remove such an annotation without sending it to the backend.
Edit: "pinch points" and "dangling lines" (see below) could be removed automatically before the annotation is created. The backend should reject these but the frontend could clean these up before sending. "bow-ties" are more problematic.
Summary:
The text was updated successfully, but these errors were encountered: