Blocking invalid (self-intersecting) polygons in Collect

[Aly_Blenkin]

Data collectors sometimes create invalid polygons due to GPS drift or user error, crossing over an already mapped area. Collect doesn’t provide real-time validation or guidance for fixing these geometry issues, so errors are often discovered after submission, requiring time-consuming rework.

Based on feedback from users and the scenarios you’ve shared in the forum, we’ve identified 4 common situations that lead to invalid polygons:

4 common scenarios

• Slight cross over at the corner

  • May happen if the data collector pauses and an extra point is captured

  • Could also occur when going around obstacles (e.g., a fence)

  • In manual mode, may result from an accidental double long press

• Cross over due to GPS spike

  • Can occur when GPS signal drifts, especially if the user walks slowly

  • May be reduced by setting an accuracy threshold

• Crossover in narrow or connecting areas

  • Can occur when mapping narrow sections or when segments connect

  • User can move to a better position or manually place a non-overlapping point

• Cross over when polygon is closed

  • Happens when the shape overlaps as it’s completed

  • Can be detected at save time, once the shape is finished

  • Best fix is to move the first point (PMs need to be fine with 0 accuracy)

Proposal

We’re exploring adding an opt-in continuous constraint evaluation for Collect's geopoint/trace/shape questions and a function to detect line intersections. Constraints would be evaluated every time the user makes a change. If the constraint is violated, the user would be blocked from adding more points until they delete or move existing points such that the constraint is no longer violated.

Blocking the addition of new points makes it clear to the user that they have to take action. It also means that the functionality is only appropriate for failed constraints that can be fixed by deleting or moving points such as checking for self-intersections.

For example:

• If self-intersections aren't allowed, creating a self-intersection causes a constraint violation and the user would be blocked from adding more points

• If a constraint requires at most 4 points, adding a 5th causes a constraint violation and the user would be blocked from adding more points

User goals

For project managers

• Ensure all submissions have valid geometry

• Errors are fixed immediately for more accurate data

• Flows remain simple and require minimal training

For data collectors

• Guided capture experience with clear feedback

• Easy-to-follow prompts for fixing invalid polygons

User flow

Example flow using placement mode

1. The user begins adding points to create a polygon

2. They accidentally create a crossover, which breaks the constraint

3. A snackbar message appears, using the constraint message defined to explain why the shape is invalid

4. The user can tap the action in the snackbar to open a short guide explaining how to fix the issue in placement mode

5. The user modifies the map based on the guidance (e.g., long press to move or undo last point)

6. The error is resolved, and the polygon can be saved successfully

XLSForm

Full example

Add a key/value pair of constraint-eval=on-change to the parameters column which is only accepted for geopoint/trace/shape. Any value other than on-change is rejected.

Next steps

We will be discussing this proposal in more detail with the @Insiders on Nov 5th! Free free to add reactions and thoughts here or bring them to the call.

[LN]

This functionality has been available since Collect v2026.1.0, learn more in the documentation.

Some of you have identified that the combination of not(intersects(.)) as a constraint and incremental=true doesn't work well for shapes that have an irregular projection in the direction of winding. For example, see what happens if you try to outline the non-green shape starting at point 1 and then adding points in incrementing order:

As soon as point 4 is placed, there will be an intersection detected between the closing segment [1, 4] and segment [2, 3]. There's still an intersection when point 5 is added, then it would go away if the next point were added south of point 2.

Currently, this shape is impossible to capture with an intersects constraint and incremental=true because adding points beyond point 4 would be blocked. There's probably a point order that would make it work but data collectors can't be expected to do that kind of planning ahead of time, especially when walking a boundary.

We are considering two possible changes to address this and we would really like to hear from you what you think would best meet your needs. @mathieubossaert @Baptiste_Monnier @dast @seewhy @ahblake you've already given great feedback, please share if you have thoughts on this.

1. Omit closing point from value passed to constraint during entry

For a constraint of not(intersects(.)), that would mean a self-intersection with the closing segment would not be considered a constraint violation while building up the shape. When the save button is tapped, the constraint expression would be evaluated with the closing point included.

We think this works well with most constraints that users would want to express. The only that feels not quite right is distance (used to compute a perimeter) but as long as the constraint is evaluated again when the shape is saved, it seems ok. area implicitly closes the shape so would continue to work as expected.

2. Remove blocking the addition of new points when constraint fails

We blocked addition of new points when the constraint fails to make the issue really apparent to users. It's generally appropriate for intersects but is the root of the problem in this case. It also means incremental=true is only appropriate for functions/expressions that can be satisfied by removing/moving points. We have somewhat awkward documentation for this.

We could instead allow addition of new points when a constraint is violated during an editing section. The shape/trace would then be red and the constraint message would be displayed but the user could continue building up their shape/trace. Then, the last check when the user taps "save" could block saving.

[ahblake]

Caveat: My geo use is currently all manually placed points and I haven't used intersects yet, so I don't have field feedback at this point.

I think showing the shape is invalid (red) but not preventing further point addition/modification is a nice compromise between blocking and informing - you don't get prevented from completing your shape, but you also know it's going to fail before saving and trying to proceed and so must adjust it, but are free to continue if you know the cause of failure is the closing segment.

I can see the benefit of evaluating over all but the closing segment to prevent users from causing intersections throughout collection, but for the case of walking a shape and autocollecting, is that still going to be a painful interaction compared to collecting all the points, then seeing it is red (due to crossing path / GPS accuracy / hopping around obstacles / capture frequency) and having to tweak some before saving?

[LN]

Thanks for the feedback here and privately! We are planning to allow the addition of new points when the constraint is violated during capture. That way data collectors can decide whether it's something they need to fix right away (e.g. because there's a real cross over and they must have points with accuracy so can't manually adjust) or can wait until it either fixes itself or they have a chance to make micro adjustments.

We'll share a beta before releasing to give a couple more days for feedback and expect to release early next week.

[LN]

We have now published v2026.2.2-beta.0 which allows adding points when a constraint with incremental=true is violated during geotrace/shape entry. You can learn more about beta testing Collect here.

We don't typically do betas for point releases but we decided to this time because it changes the behavior to recently-released functionality in a subtle way. If you've started using incremental=true, please give it a try and let us know if you have any feedback.

[LN]

Starting in Collect v2026.2.2, end users can continue adding points after a constraint violation with incremental=true. Documentation has been updated. Thank you!