webgeods https://webgeods.com/ Bilingual (Python/R) spatial data science — interactive articles and tools running entirely in your browser via WebAssembly. quarto-1.7.29 Mon, 31 Aug 2026 00:00:00 GMT Topology Errors in a GeoJSON: Detect Without Fixing https://webgeods.com/posts/topology-errors.html In Geometry validity of a GeoJSON we repaired polygons that were individually invalid with make_valid()/st_make_valid(). Here the problem is different: every single feature’s geometry can be perfectly valid, and the dataset can still be broken — two polygons that overlap, a gap between two areas that should touch, a line that ends a millimeter from another without connecting.

This tool doesn’t fix anything. It detects, describes and locates the errors — closing a gap or assigning an overlap is a semantic decision (which polygon is the “correct” one?) that no algorithm can make for you. It’s a data-quality report, not an automatic repair tool.

On load, the code detects whether your data is polygons or lines and runs only the checks that make sense for that type:

  • Polygons → overlap, gap, sliver, duplicates
  • Lines → dangle, duplicates

Just want to quickly check a file, without the rest of the reading? Use the standalone tool — same engine, less prose.

1. Upload your file

A .geojson, or a shapefile: either as a single .zip, or as the individual .shp/.dbf/.shx files (and optionally .prj) selected together.

2. What we look for

Five recurring categories, drawn from the USGS catalog and from the QGIS Topology Checker:

  • Overlap — two polygons that should be adjacent instead overlap over a portion of surface.
  • Gap — a gap remains between polygons that should continuously cover an area.
  • Sliver — a leftover polygon, thin and with no real geographic meaning, often the result of an overlay.
  • Duplicates — two features with identical geometry (applies to both polygons and lines).
  • Dangle — the end of a line that should connect to another line stays isolated.

3. Shared map and table

3.1 First run (once only)

Defines all the detection functions — no Python/R map here, that’s already ready above and knows nothing about these calculations. Run it once before the examples below.

3.2 Reusable cell pair

The code below changes with every “Load this example” button further down.

4. Five errors, five examples

4.1 Overlap

Two polygons that should be adjacent instead overlap over a portion of surface — the example already loaded by default in the cell pair above.

4.2 Gap

Two aligned polygons that should cover a single continuous area instead leave a gap between them — detected by comparing the union of the polygons with the convex hull containing both.

Note

The gap is shown as its own feature (a synthetic geometry, not one of yours), colored like the other error rows. The check only looks at polygon pairs that are close and not already overlapping, using the convex hull of the single pair — not of the whole dataset, which would flag as “gap” even the simple fact that two distant or overlapping shapes aren’t aligned with each other. For a real dataset with a known study area, that area is still the more correct reference, not a convex hull.

4.3 Sliver

An extremely thin polygon — 0.1° wide, 0.001° tall — a typical leftover from an overlay between nearly coincident boundaries. Detected with the Polsby-Popper compactness index (4π·area/perimeter²): below 0.15 is considered a sliver.

4.4 Duplicates

Two features with identical geometry — happens often during merges or repeated imports. The check applies the same way to polygons and lines (topological equality), shown here on polygons.

4.5 Dangle

A line network where three segments form a closed loop — each end touches exactly the next segment’s end, no dangle — and a fourth stays isolated, with both ends “dangling”. Notice how the layer on the map switches from fill to line: the code itself decides that, based on the geometry type you feed it.

5. Apply to your file

The cells below try to read /uploaded.geojson, then an uploaded shapefile (/uploaded.shp), then a zipped shapefile (or, without an upload, use the overlap example as test data), detect the geometry type and automatically apply only the relevant checks — same detect_and_check() function as every example above, no duplicated logic.

6. Knowing what’s broken is already a result

A report that says “23 overlaps, 8 gaps, 4 slivers” isn’t half a tool: it’s a legitimate, complete quality-assurance step in its own right. Fixing these errors almost always requires a human decision — which polygon to move, who to assign a gap to, whether a 2 m² sliver is noise or a real island. A future article may cover repair strategies; this one deliberately stops before that, where geometry alone can no longer answer the question.

]]> tool geometry bilingual https://webgeods.com/posts/topology-errors.html Mon, 31 Aug 2026 00:00:00 GMT Geometry validity: find and understand invalid geometries https://webgeods.com/posts/geometry-validity.html Upload a GeoJSON, find out which geometries are invalid and why, and run the same diagnosis in Python and in R on the same map — repair (make_valid()/st_make_valid()) is a separate, optional step, at the bottom of the page.

A .geojson, or a shapefile (either as a single .zip, or as .shp/.dbf/.shx selected together) — see the section below.

Just want to quickly validate or fix a file, without the rest of the reading? Use the standalone tool — same engine, less prose.

Can a polygon look normal and still be invalid?

flowchart TD
    A["Looks fine on the map"] --> B["Polygon"]
    B --> C["Geometry validator"]
    C --> D["❌ INVALID"]
    D --> E["Why?"]

Yes — a polygon can have a boundary that crosses itself, a hole that extends outside the outer boundary, or two holes that overlap, and it’s not uncommon for the shape on the map to look perfectly fine. Below you can find out exactly what to look for, in your own file or in one of the four ready-made examples further down.

Shared map and table

A single map and table, shared by every example on the page: run the same diagnosis in Python or R and compare the result here.

Geometry validity — feature, valid, invalid.

Diagnose: validate your geometry

Run the same check in Python or R on the current data (your file uploaded above, or the example already loaded below) — no repair yet, just diagnosis: is the geometry valid? If not, why?

Same spatial question, two languages

Python and R answer the same question with one line each:

Python

gdf.geometry.is_valid

R

sf::st_is_valid(data)

Both go through the same geometry engine, GEOS, for this calculation — but don’t expect the exact same text when you ask why a geometry is invalid: explain_validity() in Python includes the coordinates of the problem (e.g. "Self-intersection[12.5 41.9]"), while st_is_valid(reason = TRUE) in R describes the edges involved without coordinates (e.g. "Edge 0 crosses edge 2") — same calculation, different vocabulary. It’s exactly the kind of detail that distinguishes one spatial ecosystem from the other, not a bug in either one.

Valid according to whom?

“Valid” isn’t absolute: it depends on the geometric model and the engine checking it.

  • Python → shapely → always GEOS.
  • R → sf → GEOS or S2, depending on sf::sf_use_s2().

For the diagnosis above the difference doesn’t show. It becomes concrete in the repair, below:

Important

Why sf_use_s2(FALSE) before st_make_valid()? With geographic coordinates (lon/lat) and sf_use_s2(TRUE) (the default), st_make_valid() in R dispatches to s2::s2_rebuild() instead of GEOS — a different algorithm that, on these cases, fixes nothing, returning the geometry unchanged without an error. Verified not just on webR but also on real R 4.3.3 with sf 1.0.15: this isn’t a bug in this project, it’s documented sf behavior (see issues #1985 and #1771 on r-spatial/sf). Forcing sf_use_s2(FALSE) routes the call through GEOS, which works correctly here; it’s turned back on right after, because other operations (distances, areas) on geographic coordinates benefit from S2. shapely in Python doesn’t have this problem because it has no alternative S2 engine: it always goes through GEOS.

Repair (optional)

The diagnosis tells you what’s wrong. Repair changes the data — make_valid()/st_make_valid() rebuild the geometry into an equivalent, valid form. Requires having run the diagnosis above at least once: it reuses exactly the same data just diagnosed (gdf in Python, data in R stay in the session between one cell and the next, like in a notebook) — no new reading of the file.

The table and the report above update themselves — the valid_before/valid_after columns automatically appear next to the diagnosis ones.

What about relationships between geometries?

A geometry can be perfectly valid on its own and still be wrong in relation to other geometries — two valid polygons overlapping when they shouldn’t, a gap between areas that should touch. That’s a different problem: topology. It’s covered in Topology Errors in a GeoJSON.

]]> tool geometry bilingual https://webgeods.com/posts/geometry-validity.html Sat, 29 Aug 2026 00:00:00 GMT