Open ES-Alexander opened 1 month ago
In case it's relevant / of interest, I was playing with some vaguely related stuff a little while ago, which may indicate some other potential failure cases, generation algorithms, and possible future expansions / improvement ideas :-)
I agree concavity thing is a problem, but I'm curious on how could we handle that. Maybe just warning the user?
I'm curious on how could we handle that.
This video discusses some potentially viable approaches in terms of algorithms, although I'm sure we can also find others that are intended for similar purposes (including ones extra relevant to ours).
For simple concavity we could also maybe try a few different survey angles to see if any avoid the issue.
Maybe just warning the user?
That definitely seems like a good starting point 👍 Users should be able to see that the path goes outside the polygon beyond just the turns, but it's also possible to check for automatically, and could be used to warn the user to make sure their path is not going somewhere problematic.
FWIW, QGC has the same issue, and I don't believe it provides a warning about it.
FWIW, QGC has the same issue, and I don't believe it provides a warning about it.
Yup. That was my reference when I started the survey implementation.
When I saw that they, which has polygon surveys for more than 10 years, didn't solve this problem, I understood it was not worth dealing with on the first PR.
PS: nice video.
Current behaviour
Current survey generation generates paths straight through regions outside the survey polygon in concave regions:
Problematically:
It's sometimes possible to work around the issue by changing the survey orientation, or creating multiple separate survey polygons if necessary, but there's no feedback to the user that there's a problem other than their own judgement from seeing the path going where they didn't intend it to.
Path generation is also completely cooked if the polygon has self-intersections:
but that's at least not behaviour we expect to support.
Expected or desired behaviour
Ideally valid polygons should generate valid paths, and invalid polygons/paths should provide warnings to the user (e.g. turning red, and potentially asking for extra confirmation before performing generation).
One possible validity check would be to determine whether the path goes outside the polygon borders (perhaps with a warning about reorienting the path or creating multiple polygons instead), although ideally the generation would be designed in such a way that that doesn't happen to start with.
It is likely worth adding a validity check for polygon self-intersection.
Prerequisites