/ Developers / Boundary Correction

Boundary Correction

Field boundaries rarely arrive perfect. Launch Pad runs every boundary through an automatic geometry correction pipeline that detects invalid shapes and repairs them before planning, so path plans are always generated from clean, valid geometry.

Most boundary problems are invisible

Invalid geometry is surprisingly common in real-world boundary data, and most of it cannot be seen on a map: a self-intersection can hide in a single vertex. Most customers never know their boundaries have these issues because Launch Pad corrects them automatically. If you are integrating with the API and wondering why a boundary you read back differs slightly from the one you sent in, this page explains what happened and why.

Where invalid geometry comes from

Manual editing

Drawing a polygon on the map, then appending, deleting, or dragging vertices can introduce self-intersections and overlaps without any visible sign.

Third-party services

Boundaries altered by connected platforms (for example John Deere Operations Center) can come back topologically malformed.

Mixed-content files

Uploaded files sometimes carry stray points, lines, or geometry collections instead of clean polygons.

More than a basic "make valid"

Most GIS stacks repair broken geometry with a single make-valid operation. That resolves the topology error, but it is a blunt instrument with no opinion about what a usable field boundary looks like afterwards. Launch Pad instead applies a sequence of targeted corrections and keeps a general make-valid repair as the fallback for cases the targeted fixes cannot resolve.

Filtering

Points, lines, and other non-area geometry are removed so only polygons move forward.

Splitting

Self-intersecting outer boundaries are split into separate valid polygons instead of discarding part of the field.

Merging

Overlapping or intersecting holes are unioned into a single hole, as the spec requires.

Buffering

Rings are buffered by a small tolerance so holes never share an edge with the outer boundary.

Reconstruction

Holes are subtracted from outer boundaries to rebuild a clean MultiPolygon, clipping any hole that strays outside its shell.

Sliver removal

Stray fragments below a minimum area are dropped, unless they are the only piece of the field.

Normalization

Ring winding follows the GeoJSON right-hand rule and coordinates are flattened to 2D, with any elevation values stripped.

Fallback repair

A general-purpose make-valid repair handles self-intersections and other errors that survive the targeted steps.

What "valid" means

The output of the pipeline is always a valid MultiPolygon, following the polygon and MultiPolygon validity rules of the OGC Simple Features Specification:

• Every polygon has exactly one exterior ring, and that ring is a valid polygon: a closed line with at least 3 distinct points and no self-intersections.
• Interior rings, if any, are valid polygons that lie fully inside their exterior ring.
• Interior rings do not intersect one another; rings that do are merged into one.

Exterior ring (shell)

The outer boundary of a polygon. There is exactly one per polygon.

Interior ring (hole)

An inner boundary cut out of the polygon, such as a slough or rock pile. A polygon can have many holes.

MultiPolygon

A collection of polygons. A field with two separate parcels is one MultiPolygon with two polygons.

Merge

A geometry union operation: combining overlapping shapes into a single shape.

How the pipeline works

1
Normalize the input. Only polygonal geometry is kept. Points, lines, and other non-area members of geometry collections are dropped, and exterior rings are extracted.
2
Validate every ring. Each exterior polygon is validated in turn, then each interior ring.
3
Repair self-intersections. Self-intersecting exterior rings are split into separate polygons. Intersecting interior rings are merged. If a merge does not resolve an intersection inside the main shell, the polygon falls back to a general make-valid repair.
4
Buffer the rings. Every ring is buffered by a small tolerance so interior rings never end up sharing an edge with an exterior ring.
5
Rebuild the result. Interior rings are subtracted from exterior rings to form the final valid MultiPolygon. Holes that fall outside a shell are clipped to the shell that contains them, and a hole that lies entirely outside every shell is kept as its own polygon rather than discarded.

If the input cannot be salvaged, for example when nothing remains once the invalid parts are removed, Launch Pad reports the failure instead of inventing a shape, and every correction step is logged so the outcome can be audited.

Note: Processing happens in a projected coordinate system so distances are in meters, and the result is converted back to WGS84. That is why buffer tolerances are expressed in meters rather than degrees.

Before and after examples

Five representative cases of malformed input geometry (blue) and the corrected output (yellow). Expand the WKT to see the exact coordinates.

Case 1: Mixed geometry types

The input is a GeometryCollection rather than a MultiPolygon, and it contains a LineString and a Point alongside the actual polygon. The line and point are removed, and the exterior ring is extracted from the polygon.

Input geometry containing a polygon plus a stray line and point — Input

Result geometry: a single clean polygon with the line and point removed — Result

Case 2: Self-intersecting boundary

The exterior ring crosses itself, forming a bowtie. This is not a valid polygon, and many planners would reject it or silently drop one lobe. The cleaner splits the ring at the crossing point into two valid polygons, preserving the whole drawn area.

Input polygon whose outline crosses itself, forming a bowtie shape with the intersection point highlighted — Input

Result geometry: the bowtie split into two valid polygons meeting at a single point — Result

Case 3: Overlapping holes

Two interior rings intersect each other, which the spec forbids. The holes are merged into one, and the polygon is recreated with the single combined hole.

Input geometry with two overlapping holes inside the field boundary — Input

Result geometry: the overlapping holes merged into a single hole inside the boundary — Result

Case 4: Overlapping outer rings

Several exterior rings overlap and self-intersect, together enclosing an empty pocket. The rings are buffered and merged into a single outline, and the enclosed pocket is preserved as a proper hole.

Input geometry with several overlapping rectangles arranged in a loop — Input

Result geometry: the rectangles merged into one outline enclosing a single hole — Result

Case 5: Holes outside the shell

The field has two separate outer rings, and the holes do not respect them: one hole spans the gap between the two shells and others poke past the edges. Each shell is rebuilt separately and every hole is clipped to the shell that contains it, with a small buffer so no hole shares an edge with its shell.

Input geometry with two separate outlines and holes that cross or fall outside them — Input

Result geometry: two clean polygons with every hole clipped to fit inside its own outline — Result

Developer docs Path Plan Structure API Docs