- When is the invalid point created?
- The most common intersecting polygons I see are where they're technically invalid but approximately correct in the eyes of the data collector
- 1: using a crossing to indicate a very narrow section or a point intersection instead of having >=2 vertices at the isthmus or two polygons
- 2: trying to create a very thin section to bridge to another area, resulting in a crossing (should be reported separately)
- 3: slight overlaps with detailed geometry due to time constraints / difficulty placing accurately. depending on shape could result in intersection due to any point
- The most common intersecting polygons I see are where they're technically invalid but approximately correct in the eyes of the data collector
- How do users decide which recording method to use?
- I request placement by tapping in almost all cases and have a constraint to ensure that elevation or precision are 0
- During automatic mode, what are your data collectors typically doing with their phone? For example, is it in their hand and they are looking at it the entire time, or in a pocket?
- not applicable in almost all cases
- If they are using placement or manual mode, where is their phone?
- tablet is handheld in front of user
- What strategies have helped you and the data collectors reduce these errors?
- counselling user when bad geometry uploaded
I ran 'check validity' over almost 10000 polygons from a project to see the sorts of errors that QGIS found, looks to be ~1-2% error rate in field geometry.
Duplicate nodes: Don't think these are actual Collect polygon issues, included for interest
- 21x "2 duplicate node(s) starting at vertex 1" due to first = second. (In the analysis output, all had 17 DPs of precision, generally as 8DPs of values, 6-7 0s or 9s, then 2-3 values at the end - the source geometry didn't have values like this, they were 7-8DPs if desktop created and not modified, and 14-15DPs if modified in Collect so appears to be a conversion issue in the check.)
- 24x "2 duplicate nodes" "at vertex !=1" occurs when there are consecutive duplicate points elsewhere in the polygon.
- Not sure how either of these these duplicates occurred - desktop duplicate or Collect (I couldn't intentionally create a duplicate in Collect even at max Mapbox zoom). Checking the source, most of the geometries with duplicate vertices had 7-8DP precision - assume these were desktop and not modified. 3x of the 24 that errored had 14DP precision, so appear to be Collect modified, but perhaps only the non duplicates were adjusted. I'm going to assume these came about from an errant extra clicks with geometry snapping or similar in desktop
- source geometry for polygon with 14DP that returned 'duplicate vertices at vertex 5' but only a match to 7DP:
geometry
SRID=4326;POLYGON ((-10.18806845920256 -10.596776664266088 0, -10.188079265162 -10.59677407029217 0, -10.18808165801846 -10.596777987775411 0, -10.18807025260708 -10.596780962257768 0, -10.18806846016878 -10.596776671971696 0, -10.18806845920256 -10.596776664266088 0))
- 1x ring 0 not closed - first != last and there is a crossing (possibly a desktop goof from the DPs but the user also didn't check/correct if so):
unclosed ring geometry and details
SRID=4326;POLYGON ((-10.2209927 -10.2306696 0, -10.2209833 -10.2306667 0, -10.2209871 -10.2306509 0, -10.2209745 -10.2306521 0, -10.220976 -10.2306425 0, -10.2209954 -10.2306454 0, -10.2209833 -10.2306696 0))
- 165x 'segments x and y of line 0 intersect at ...', 152x of which have 13-14DP so appear to be Collect created/modified.
- worst is one poly with 6&8, 6&9, 7&9, 13&15, 18&20
Looks ok until you zoom in
- worst is one poly with 6&8, 6&9, 7&9, 13&15, 18&20
Again, ok from afar
Trying to create two areas that meet at a point
Trying to create three separate areas in one polygon with intersections in the links
