1. Upload your raster

A multi-band GeoTIFF (.tif/.tiff) with at least two bands: one you want filled (has real gaps, NoData cells), one that doesn’t. That second band is the covariate: elevation, another spectral band, anything correlated with the first.

2. Why a covariate band helps

If you’ve read the kriging article, you’ve already met the variogram: bin every pair of points by distance, average their squared difference within each bin (half of it, actually, which is why the axis says semivariance, not variance), fit a smooth curve to those bins. That curve’s nugget, sill, and range describe how one variable varies with itself over distance. Cokriging needs one more piece: the cross-variogram, the same idea applied to two variables at once. It asks how much the target’s value at one location tends to differ from the covariate’s value at another location, as a function of the distance between them.

Fitting a target’s variogram, a covariate’s variogram, and their cross-variogram together, consistently enough that the combined system stays mathematically valid (technically: positive definite), is a linear model of coregionalization (LMC). Once fit, predicting the target at a gap uses both: the target’s own nearby known values, and the covariate’s value right there, weighted by how strongly the two actually move together. Where the covariate is missing too, there’s nothing extra to weight in. Cokriging can’t fill that pixel any differently than plain kriging could, which is why this article (and the standalone tool) leaves those cells empty rather than guessing.

3. Shared map

4. Compute: fit the model in R — runnable here; Python — reference only

# Reference only -- not executable in this browser tool, and NOT a
# port of the R cell to the left. GSTools' "collocated cokriging"
# assumes the covariate is known at every point you're predicting
# (true here -- the covariate band has no NoData either, at any pixel
# the target needs filling), and uses that single co-located value
# directly instead of fitting a full cross-variogram between the two
# variables. Simpler, and it asks less of the data, but it's a
# genuinely different method from the fit.lmc() coregionalization
# model the R cell above fits -- see this article's own note on why
# that distinction matters before treating the two as interchangeable.

5. The target’s own variogram

This is the target band’s direct variogram, the same shape as the kriging article’s own chart: half the average squared difference within each distance bin, with the fitted curve’s nugget, sill, and range marked on it. It’s not the whole story. The actual cokriging fit above also needs the covariate’s own variogram and the cross-variogram between the two, neither shown separately here. But it’s the piece that carries over directly from ordinary kriging, and the one place this article’s chart can show something the reader already knows how to read.

Once the model above looks right, predict the gaps themselves:

# Reference only, for the same reason as the fit step above: GSTools'
# collocated cokriging predicts directly from the fitted model and the
# covariate's own values at the target locations, no separate
# "prediction dataset" the way gstat's predict() needs one built by
# hand -- a real structural difference from the R cell to the left,
# not just a syntax one.

6. Why Python takes a different approach here

R’s gstat (built on sp/sf) has no WebAssembly build of its closest Python equivalent, pykrige. That’s the same gap the kriging article already documents, and it’s true again here for the same reason: no pykrige wheel published for Pyodide. But cokriging specifically has a second, more interesting wrinkle worth being precise about instead of glossed over: Python’s own GSTools library does offer cokriging (Simple and Intrinsic Collocated Cokriging), but that’s a genuinely different technique from the fit.lmc() linear model of coregionalization the R cell above fits, not just a different implementation of the same idea. Collocated cokriging assumes the covariate is known at every location you’re predicting, and uses that one co-located value directly, without fitting a full cross-variogram between the two variables the way an LMC does. It asks less of the data and skips a real modeling step, which is reasonable when its own assumption holds but not a drop-in substitute for what this article and the standalone tool actually compute. No verified reference code for it sits on this page: writing some without running it against a real GSTools install would risk teaching a technique this project hasn’t actually checked.

7. Where to next

• Just needed the map? The standalone Raster Gap Filler: upload your own multi-band file, pick the two bands, done.
• Only have one band, no covariate? Ordinary kriging on the raster’s own valid pixels still works: the standalone tool falls back to it automatically when you leave the covariate on “None.” See the kriging article for how that half of the pipeline works on its own.

Second tool in the GeoStatistics family.

1. Upload your file

A point file (.geojson, or a shapefile as a single .zip or as .shp/.dbf/.shx selected together) with a numeric column: soil moisture, pH, anything measured at scattered locations.

2. Why fit a variogram, instead of just averaging nearby points?

The simplest way to fill in the gaps is Inverse Distance Weighting (IDW): average the nearby points, weighting closer ones more, with the weight falling off by some fixed power of distance (usually 2). It’s fast and easy to reason about, and this site’s Buffer/Proximity tool family uses distance the same simple way. It has a real limitation, though: the decay rate is assumed, not measured. Whether moisture actually changes fast or slowly with distance in this field, at this time, is never asked.

Kriging asks it, in three steps this article builds up one at a time:

1. The empirical variogram: for every pair of sample points, compute the squared difference in their values and the distance between them, then average those squared differences within distance bins. This directly measures how different two points tend to be as a function of how far apart they are. Pairs close together should differ less than pairs far apart, if there’s any spatial structure to find at all.
2. Fitting a model: a smooth curve (spherical, exponential, or Gaussian; this article uses spherical) is fit to those binned points by nonlinear least squares. The fitted curve has three numbers worth knowing:
   • Nugget: the curve’s value at distance zero. Two points right on top of each other should be identical, so a nugget above zero means measurement noise or small-scale variability the model can’t (and shouldn’t try to) explain away.
   • Partial sill: how much more the curve rises as distance grows. Nugget plus partial sill gives the total sill: the variance you’d expect between two points so far apart they’re basically unrelated.
   • Range: the distance at which the curve flattens out and reaches that total sill. Beyond the range, two points tell you nothing about each other; within it, they do, more so the closer they are.
3. Kriging itself: using that fitted model as the actual weighting rule instead of an assumed power law, it predicts a value at every point on a grid, as a weighted combination of the sample points where the weights come from the model. Solving for those weights also produces a prediction variance at every grid point: a real “how sure am I,” which IDW has no equivalent for at all.

3. Shared map

4. Compute: fit the model in R — runnable here; Python — reference only

import numpy as np
from pykrige.ok import OrdinaryKriging

# Reference implementation only -- not executable in this browser
# tool. Constructing OrdinaryKriging() already does BOTH R steps
# above in one call: it computes the empirical variogram internally,
# then fits the model to it.
ok = OrdinaryKriging(
    lon, lat, values,
    variogram_model="spherical",
    verbose=False,
    enable_plotting=False,
)
print(ok.variogram_model_parameters)  # [sill, range, nugget]

5. The variogram, and predicting the surface

The empirical bins below are the direct measurement from step 1 above: half the average squared difference within each distance bin (that halving is why the axis says semivariance, not just variance). The line is the spherical model fit to them, with its own nugget, sill, and range marked directly on the chart.

Once the model above looks right, predict the surface itself:

import numpy as np

# Reference implementation only -- not executable in this browser
# tool. `ok` is the OrdinaryKriging object fitted in the step above;
# .execute() is the equivalent of this step's krige() call.
grid_lon = np.linspace(lon.min(), lon.max(), 25)
grid_lat = np.linspace(lat.min(), lat.max(), 25)
z, variance = ok.execute("grid", grid_lon, grid_lat)

6. Why Python is reference-only here

R’s geostatistics ecosystem (gstat, built on sp/sf) has been the standard tool for kriging since long before either language ran in a browser. Python’s closest equivalent, pykrige, has no WebAssembly build anywhere. That’s confirmed directly against this project, not assumed from general knowledge: there is no pykrige wheel published for Pyodide, and none of the usual pure-Python fallbacks (scikit-gstat, hand-rolled numpy) reach feature parity with gstat’s fitting routines without becoming a second, untested implementation of the exact algorithm this article is trying to teach correctly.

This is a different situation from Viewshed, this site’s other R-only article. There, the Python library (GDAL) exists in principle but isn’t in this specific browser runtime’s package index. Here, there is no WebAssembly build of pykrige to load in the first place. That’s a harder, more permanent gap than a narrower one.

The snippet above is real, working pykrige code for a desktop or server Python environment; it just has nowhere to run inside this page.

7. Where to next

• Just needed the map? The standalone Kriging Interpolator: upload your own file, pick the column, choose a model, done.
• Want the simpler distance-only version first? See Buffer/Proximity, which uses no fitted model, just a fixed distance.
• Got a raster with gaps instead of scattered points? Filling Raster Gaps with Cokriging builds on the same variogram fitting to patch an existing grid’s own holes, optionally using a second band as a covariate.

First tool in the GeoStatistics family; more are planned.

1. Upload your data

No file uploaded? Both cells below fall back to the same eight-line example: a closed block (four segments forming one connected loop), a fully separate cluster elsewhere on the map, and a two-segment “spur” whose first endpoint sits about 4m from the block’s corner, not exactly on it. That 4m gap is deliberately part of the example, not a mistake in it: it’s what section 3 below is about.

2. Same lines, two languages

The map above shows where the lines are; the two diagrams below show how they’re connected: same graph the counts above describe, laid out by force instead of geography, colored by connected component. Drawn from whichever language you ran (if you run both, the second one just redraws the same picture, since Python and R agree on the graph, so there’s nothing a second drawing would show differently).

3. Same lines, two different answers

The numbers above describe the built-in fallback specifically. If you uploaded your own file, the counts will differ, but the same effect is what to look for. Both languages ran the exact same two tolerances (0m and 5m) on the exact same eight lines, and got the same shape of answer:

• At 0m, the “spur” (two segments starting about 4m from the block’s corner) counts as its own piece: three components in total, the block, the spur, and the fully separate cluster.
• At 5m, that 4m gap is within tolerance, so the spur’s near endpoint merges into the block’s corner: two components, the now-joined block+spur, and the still-separate cluster.

Nothing about the geometry changed between the two runs: same coordinates, same lines. Only the definition of “the same point” changed, and that alone was enough to change how many pieces the network has. This is why real-world network analysis (road networks, utility networks, hydrology) always involves a noding/snapping step before anything else: the raw geometry rarely already agrees with itself down to the last centimeter, and the tolerance you pick is a real analytical decision, not a technicality to skip past.

4. Where to next

• Want an adjustable tolerance, the graph drawn directly on the map itself, and a way to click a node and see it highlighted in both views at once? → The standalone Network from Lines tool runs the same algorithm with a tolerance you control live, and lets you download the result.
• Wondering why the coordinate system needed picking at all? → Coordinate Reference Systems covers the geographic/projected distinction this article leaned on in section 2.

1. Why the coordinate system matters here

A buffer distance is a real distance: meters, not degrees of longitude/latitude, where the same number of degrees covers very different real distances depending on where on Earth you are. Both languages below pick a working UTM zone from the data’s own bounding-box center and reproject into it first, same reasoning, same formula, as this site’s Viewshed and Spatial Clustering tools: a reasonable default for one local dataset, not a universally correct choice for data spanning multiple UTM zones or very large areas.

2. Upload your data

No file uploaded? Both cells below fall back to the same three fixed features: a point (a shop), a line (a road segment), and a polygon (a building footprint), deliberately different geometry types, chosen to show all three buffer shapes in section 4 with one run. Upload your own point, line, or polygon file to see the same computation on real data instead.

3. Same spatial question, two languages

4. One distance, three different shapes

The numbers below describe the built-in fallback specifically (a point, a line, and a polygon, buffered 30m). If you uploaded your own file instead, the areas will differ, but the same three rules still explain whatever shape came out. Both cards above ran the exact same 30m buffer on the exact same three features. The shapes agree exactly; the areas don’t, by a small, fully explainable margin, not a disagreement about the answer:

• The point’s buffer is a circle: every direction from a single location is equally “within reach.”
• The line’s buffer is a stadium shape (a rectangle with two rounded ends): every point along its length gets its own circle of reach, and they merge into one continuous zone.
• The polygon’s buffer is the original shape, expanded outward, with its corners rounded off: everywhere already inside stays inside, plus a 30m halo all the way around the boundary.

Every geometry type buffers into a polygon, regardless of what it started as: there’s no such thing as a “buffered point” that’s still a point. That’s also why dissolving several overlapping buffers into one shape (the standalone tool’s own checkbox) is meaningful: once everything is already a polygon, merging overlapping ones is a single, well-defined operation, the same one used to answer “what’s the total area within reach of any of these features,” not “within reach of each one separately.”

5. Where to next

• Want adjustable settings, rings, and a download button? → The standalone Buffer & Proximity tool runs the same computation with a distance you control, optional concentric rings, and an optional dissolve, colored on the map, downloadable.
• Wondering why the coordinate system needed picking at all? → Coordinate Reference Systems covers the geographic/projected distinction this article leaned on in section 1.

1. Why the coordinate system matters here

A Random Forest trained directly on longitude/latitude would treat 1 degree of separation as the same “distance” everywhere on Earth, which it isn’t. Both languages below pick a working UTM zone from the data’s own bounding-box center and reproject into it first, same reasoning, same formula, as this site’s Viewshed and Spatial Clustering tools: a reasonable default for one local dataset, not a universally correct choice for points spanning multiple UTM zones or very large areas.

2. Upload your points

No file uploaded, or your file has no column literally named class? Both cells below fall back to the same built-in survey: 30 sites, 5 points recorded close together at each, across three zones (south, centre, north) whose boundaries undulate rather than running straight. One site in five sits on a local patch of a different class, the kind of small inclusion a real survey keeps running into: a wet hollow in a dry field, a stand of a different species. Both tabs build it from the same arithmetic rule instead of a list of coordinates, so the points are identical and the two languages are comparable.

Both details are there on purpose. Surveys really are collected in sites like this, a handful of readings wherever someone stopped. And the patches are what keep the scores honest: with tidy zones and nothing unexpected inside them, any classifier would score close to 100%, which teaches nothing except misplaced confidence. Number of trees and grid resolution are fixed here (100 trees, a 10-cell grid) to keep the focus off tuning; the standalone tool exposes both as adjustable controls and lets you pick any column as the class.

3. Same spatial question, two languages

The filled grid is the predicted surface; the dots on top are the labeled training points, colored the same way. Each language draws onto its own map sources, so running either one on its own is enough to see a result.

Run both and the two surfaces won’t match everywhere. They cover exactly the same ground and start from identical points (the two cells build the survey from the same arithmetic rule), but they don’t label every cell the same way. It’s tempting to read that as Python disagreeing with R. It isn’t: both cells fix a seed so their output is reproducible, and changing that number moves the surface just as much as switching language does. A forest retrained disagrees with itself about as much as the two languages disagree with each other.

4. How good is that surface?

Both cells score the model with 5-fold cross-validation: the points are split into five groups, each group is held out in turn while a forest trains on the other four, and in the end every point has been predicted once by a model that never saw it. The only difference between the two rows of each stat card is how the points are split into groups.

Random folds scatter the held-out points across the whole map. On the built-in survey that scores about 0.76–0.81, in either language, against 0.33 for guessing among three classes. It looks like a usable map.

Spatial blocks cut the area into a 4 × 4 grid and hold out whole blocks at a time. Same points, same forest, same number of trees: about 0.54–0.59. Twenty points lower, in every one of the five seeds tried per language.

Nothing about the model changed between the two rows, only the question being asked. A random fold almost never holds out a whole site: four of a test point’s five site-mates, a few metres away, are still in training, and the forest can simply copy them. Even a point on one of the patches comes out right, because its site-mates on the same patch were seen. Hold out a whole block and the patch goes out with it: now the model has to predict it from the sites around it, which say something else.

So which number describes the map? Neither exactly, and the stat cards’ last row says why. A cross-validated score only holds for predictions made about as far from the data as its test points were. Random test points sit a median 27 m from the nearest training point: a site-mate. Block test points sit about 193 m away. The map’s own grid cells, the places it is actually asked about, sit about 73 m from the nearest sample, in between. The random score answers an easier question than the map faces, the blocks score a harder one.

In a separate run (in Python, on the same points, not on this page), the block grids whose test distances came closest to the map’s, 10 × 10 and 12 × 12 (blocks about 100–120 m across instead of 300), scored 0.61–0.65. That’s roughly the honest figure for this map: the random score overstates it by 10 to 20 points, the 4 × 4 blocks understate it by up to about 10. Other grid sizes in the same run landed anywhere from 0.52 to 0.72, so a fixed grid is a crude way to match distances; dedicated methods for spatial validation (nearest-neighbour distance matching, NNDM and its variants) do it with more care. The 4 × 4 blocks are the safer number to quote, not the exact one.

The per-class numbers show where the gap comes from. Under random folds centre, the narrow middle band squeezed between the other two, looks nearly as well learned as the rest, around 0.7. Under blocks it drops to about 0.35, barely above chance: with its own neighbourhood removed, the forest can’t tell the thin middle band from the wide ones on either side. One overall number, from either scheme, would have hidden that the model has essentially learned two of the three classes.

Both numbers move from run to run, too. The block folds are fixed (the same arithmetic rule in both tabs, so they’re identical), but the forest itself draws random numbers, and the random folds are drawn by each language’s own generator, so Python and R hold out different points there. The ranges above overlap between languages, and five seeds each are nowhere near enough to rank scikit-learn against randomForest. What doesn’t move is the gap: random folds beat blocks by a wide margin every time, in both.

One more thing the folds don’t do: change the map. Every forest trained inside the cross-validation is thrown away once it has been scored. The map comes from a separate forest trained on all 150 points, the usual practice, since cross-validation scores the way the model is fitted rather than one particular fitted forest. The choice of scheme would start changing the map only if it were used to choose something, a smoothing setting say, and random folds would then reward the forest that copies its neighbours most faithfully.

5. A silent switch: classification vs. regression

The disagreements above are a model being unsure. This one is different: a model quietly solving a different problem.

scikit-learn’s RandomForestClassifier and R’s general-purpose randomForest() decide what to do very differently. scikit-learn is unambiguous: you asked for a Classifier, so it classifies, whatever the labels look like. R’s randomForest() instead looks at the type of the target column, and the two ways of getting this wrong fail very differently:

• A plain character column ("north"/"south", never wrapped in factor()) fails loudly. R can’t compute a regression mean on text, so the fit errors out immediately with something like non-numeric argument to binary operator. Annoying, but safe: you find out right away.
• A column of numbers standing in for classes (0/1, or a status code read straight out of a file) is the dangerous one: it fits without complaint and silently runs a regression instead of a classification. No error, no warning, just a different kind of model whose predictions no longer look like class labels at all.

The R cell above already does this correctly (factor(as.character(...)) before the fit): modelType in its stat card reads classification. Here’s the realistic failure case: the exact same points, with class read in as 0/1/2 instead of "south"/"centre"/"north" (exactly what happens if a class column arrives as a numeric status code), and that one factor() step skipped, run live:

model$type reads regression, and predict() on a point whose true class was 0 (south) returns something like 0.044, not the class 0 itself: a regression estimate, an average of the training codes, that happens to land near it. On a point near a boundary it would land somewhere in between, a 0.7 that is no class at all. Nothing in the output says a switch happened; the only way to notice is checking model$type yourself, which is exactly what production code should do.

6. Where to next

• Just needed to classify a file, with adjustable settings and a download button? → The standalone Spatial Classifier runs the same computation on an uploaded point file (or its own example), with any column as the class, adjustable tree count and grid resolution, the same random-vs-blocks comparison with the held-out blocks drawn on the map, and a downloadable classification surface.
• Wondering why the coordinate system needed picking at all? → Coordinate Reference Systems covers the geographic/projected distinction this article leaned on in section 1.
• Curious about the other side of GeoML: finding groups instead of predicting labels? → Finding Spatial Clusters with DBSCAN is this family’s entry point, unsupervised rather than supervised.

1. Why the coordinate system matters here

DBSCAN takes one distance, ε (eps): how close two points need to be to count as neighbors. For that distance to mean anything, it has to be in real units (meters), not degrees of longitude/latitude, where the same number of degrees covers very different real distances depending on where on Earth you are. Both languages below pick a working UTM zone from the data’s own bounding-box center and reproject into it first, same reasoning, same formula, as this site’s Viewshed tool: a reasonable default for one local dataset, not a universally correct choice for points spanning multiple UTM zones or very large areas.

2. Upload your points

No file uploaded? Both cells below fall back to the same small built-in example: two tight groups of six points, and two points far from everything, including each other, chosen to keep the point-by-point label comparison in section 4 readable. ε and the minimum group size are fixed at 100m/4 points here to keep the focus on how the two languages report a result, not on tuning. The standalone tool exposes both as adjustable controls.

3. Same spatial question, two languages

4. A label is not a name

Both cards above found the same thing: two groups of six, and two noise points (with the built-in example; an upload of your own may find something different). But the numbers don’t match, and that’s not a bug in either language.

Two separate reasons, easy to conflate:

• DBSCAN’s own cluster numbering is arbitrary. Nothing about “cluster 0” or “cluster 1” is meaningful on its own: it’s just the order the algorithm happened to visit points in. Run the same algorithm again with the points in a different order (or on a different implementation entirely) and the groupings can come out identical while the numbers attached to them differ.
• scikit-learn and dbscan also disagree on noise, specifically. This one isn’t arbitrary: it’s a real, documented difference between the two libraries: scikit-learn labels noise -1 and starts real clusters at 0; R’s dbscan package labels noise 0 and starts real clusters at 1. Every non-noise label is shifted by exactly one.

Read down the table: every point Python calls 0, R calls 1; every point Python calls 1, R calls 2; every point Python calls -1 (noise), R calls 0. The partition (which points end up together) is identical. The labels attached to it aren’t, and never had to be.

5. Where to next

• Just needed to cluster a file, with adjustable settings and a download button? → The standalone Spatial Clustering Explorer runs the same detection on an uploaded point file (or its own example), with adjustable ε and minimum group size, colored on the map, downloadable.
• Wondering why the coordinate system needed picking at all? → Coordinate Reference Systems covers the geographic/projected distinction this article leaned on in section 1.
• Have labels already, and want to predict them somewhere new instead of finding groups from scratch? → Predicting Spatial Classes with Random Forest is this family’s supervised counterpart to DBSCAN.

1. Upload your file

A single .tif/.tiff with two or more bands: band math has nothing to compute on a single-band file.

2. Why band math?

Four things worth knowing before the first computed raster:

• It’s pixel-by-pixel, not band-by-band. Every output pixel comes from exactly the two input pixels at the same row/column: a computed raster is always the same width, height, and (usually) resolution as its inputs, never a summary or a reduction.
• NoData has to propagate, not get treated as a real number. If either input pixel is NoData, the output pixel has to be NoData too, otherwise a border of sentinel values (often -9999 or 0) quietly drags a mean or a color ramp toward a value that was never a real measurement.
• Division needs a plan for zero. A ÷ B on a pixel where B is 0 isn’t a crash waiting to happen: it’s Inf (or NaN for 0 ÷ 0) in both Python and R, and both are just as “not a real value” as NoData is. Left unhandled, a single such pixel can make an entire color ramp or min/max computation meaningless.
• A very common form has a name: (A − B) / (A + B), the Normalized Difference, bounds the result to roughly -1..1 regardless of the two bands’ original units, which is exactly why it shows up everywhere from vegetation indices to change detection. This article computes a plain difference (A − B) as the running example; try changing the formula in the code below to see how the normalized form differs.

3. Shared map and result

4. Compute: run the same band math in Python or R

Run the same computation on the current data (your file uploaded above, or the built-in example below). Edit band_a/band_b, or the formula itself, and re-run to see the map update.

5. Same spatial question, two languages

Both engines agree on the arithmetic itself (elementwise subtraction is elementwise subtraction), but differ in how NoData and non-finite results are handled:

Python (rasterio + numpy)

src.read(i, masked=True).astype("float32").filled(np.nan)  # NoData -> NaN up front
a - b                                                        # plain numpy arithmetic
result[~np.isfinite(result)] = np.nan                        # Inf/NaN from division -> NaN

R (terra)

r[[i]]                              # one band as its own SpatRaster
a - b                                # terra overloads +-*/ directly on SpatRaster
ifel(is.finite(result), result, NA)  # Inf/NaN from division -> NA

The shape of the fix is identical in both languages: mask out non-finite values after the arithmetic, don’t try to prevent them from occurring. But the mechanism differs: numpy needs an explicit np.errstate context to suppress the runtime warning a division by zero would otherwise print (the computation itself still produces Inf/NaN either way), while terra’s ifel() is a single vectorized call with no equivalent warning to suppress.

7. Where to next

• Just needed the computed raster? The standalone Raster Calculator picks bands and an operator from a dropdown, no editing required.
• Not sure what’s in the file yet? Start with Raster Inspector: dimensions, bands, CRS, NoData, before computing anything.
• Working with vector data instead? See First Look at a Geospatial File.
• Vegetation index specifically? See NDVI: Measuring Vegetation from Two Bands, or the standalone NDVI Calculator: this same Normalized Difference operation, with red/near-infrared band presets and a vegetation color scale.

1. Upload your file

A .tif/.tiff with a Red and a near-infrared band.

2. Why NDVI, and its most common real-world mistake

Three things worth knowing before the first computed map:

• It’s bounded, by construction. Normalizing by NIR + Red (rather than a plain difference) squeezes the result into roughly -1..1 regardless of the sensor’s raw value range: a Landsat scene in reflectance units and a raw-DN Sentinel-2 tile produce NDVI on the same scale, which is exactly why a fixed color scale (not a per-file min/max) makes sense here, unlike the generic Band Math tool.
• Roughly: negative values are usually water, values near zero are bare soil or built surfaces, and increasingly positive values track increasingly dense, healthy vegetation. “Roughly” is doing real work in that sentence: season, sensor, and atmospheric correction all shift the exact thresholds; treat it as a ranking, not a lab measurement.
• The single most common real-world mistake: Red and NIR swapped, or the wrong band picked entirely. A GeoTIFF’s band order isn’t standardized. It’s whatever the sensor or processing pipeline put there, and the file itself never declares “band 4 is Red.” Swap the two bands and NDVI doesn’t error, it just silently inverts: vegetation reads as water-like and vice versa, a wrong answer that looks like a plausible map. Worth a specific check (0.2 <= NDVI <= 0.9 somewhere near obvious vegetation in the image) before trusting a result on an unfamiliar file, not just a general disclaimer to keep in mind.

3. Shared map and result

4. Compute: run NDVI in Python or R

Run the same computation on the current data (your file uploaded above, or the built-in example below). Edit band_red/band_nir to match your file (common conventions: Landsat 8/9 Red=band 4, NIR=band 5; Sentinel-2 Red=band 4, NIR=band 8, but always confirm against the file at hand, not just the sensor name) and re-run.

5. Same spatial question, two languages

Same divergence already documented in Raster Band Math: numpy needs an explicit np.errstate context to suppress the runtime warning a division by zero would otherwise print, while terra’s ifel() is a single vectorized call with no equivalent warning. Nothing about NDVI specifically changes that comparison; the formula is just a Normalized Difference with the bands fixed to Red/NIR.

7. Where to next

• Just needed the map? The standalone NDVI Calculator picks Red and NIR from a dropdown, no editing required.
• Different two bands, or a different operation? Raster Band Math is the general version of this same computation: add/subtract/multiply/divide, any two bands, no vegetation assumption.
• Not sure what’s in the file yet? Start with Raster Inspector: dimensions, bands, CRS, NoData, before computing anything.
• Working with terrain instead of imagery? See Viewshed: what’s visible from a point, accounting for the ground in between.

1. Upload your file

A .tif/.tiff digital elevation model (DEM), one band of elevation values.

2. Why viewshed, and what “visible” actually means here

Four things worth knowing before the first computed map:

• It’s occlusion, not distance. A cell right next to the observer can be invisible (hidden behind a ridge two cells away) while a cell much farther off is perfectly visible across open ground. The algorithm traces the line of sight to every other cell and checks whether the terrain in between rises above that line anywhere along the way.
• A working projection, not a correction. terra::viewshed() requires projected (linear-unit) coordinates. It refuses geographic lon/lat data outright, and rightly so: the algorithm reasons in real distances and angles, which degrees can’t give it directly. A geographic DEM (SRTM tiles, for instance, ship this way) is reprojected internally for the calculation, to a UTM zone picked from the raster’s own centre. The original file is never modified: this is a working projection for the computation, not a claim that webGeoDS found “the correct CRS.” A DEM spanning multiple UTM zones, sitting near the poles, or covering a very large area would need a deliberate projection choice instead; the automatic pick here is a reasonable default for a single local DEM, not a universal answer.
• “Visible” means visible under this terrain model, not “a human would see it.” The result accounts for terrain height, observer and target height above ground, and a curvature/refraction coefficient (terra::viewshed()’s curvcoef, default ≈0.857). It does not account for vegetation, buildings, or atmospheric haze. It answers “is the ground itself in the way,” a real and useful question, just not the complete one.
• The output is boolean, not a gradient. Every other computed map in this Raster family (Band Math, NDVI) is a continuous value shown on a color ramp. A viewshed is yes/no per cell: visible cells are highlighted, everything else is left transparent so the base map shows through underneath.

3. Shared map and result

4. Compute: viewshed in R — runnable here; Python — reference only

from osgeo import gdal

# Reference implementation only -- not executable in this browser
# tool. Exact keyword names can vary slightly by GDAL version; this
# matches the GDAL 3.x osgeo.gdal.ViewshedGenerate() API.
src_ds = gdal.Open("dem.tif")
src_band = src_ds.GetRasterBand(1)

gdal.ViewshedGenerate(
    srcBand=src_band,
    driverName="GTiff",
    targetRasterName="viewshed.tif",
    creationOptions=[],
    observerX=500100.0,       # in the DEM's own (projected) CRS units
    observerY=4600100.0,
    observerHeight=1.8,
    targetHeight=0.0,
    visibleVal=1.0,
    invisibleVal=0.0,
    outOfRangeVal=0.0,
    noDataVal=-1.0,
    dfCurvCoeff=0.85714,       # same default terra::viewshed() uses
    mode=gdal.GVM_Edge,
    maxDistance=0.0,           # 0 = unlimited
)

5. Why Python is reference-only here

Every other article in this Raster family runs Python and R side by side and confirms they agree on the numbers. This one can’t, and it’s worth being precise about why rather than waving at “GDAL isn’t supported”:

The GDAL Python bindings expose ViewshedGenerate(), which provides the corresponding GDAL implementation: the same underlying algorithm terra::viewshed() uses on the R side. However, GDAL is not available in the curated Pyodide package index used by this browser runtime. Attempting to load it returns No known package with name 'gdal', tested directly against this project, not assumed from general knowledge. rasterio itself, this site’s usual Python raster engine, has never had a viewshed function of its own; it’s a thin I/O layer over GDAL, not an analysis library. No actively-maintained pure-Python alternative exists either: the closest candidates (whitebox/WhiteboxTools, richdem) are a standalone compiled executable and a C++ extension respectively, neither usable inside Pyodide.

The Python example above shows the equivalent desktop/server workflow but is not executable in this browser tool.

The rest of this site’s implicit promise has been “Python and R, side by side.” This article refines that to “Python and R, when the browser runtime allows it”: a statement of what’s actually true, not an exception being quietly worked around. Forcing a from-scratch numpy reimplementation just to keep two live panels would have traded a real, tested algorithm for an untested one, on a page whose whole point is trustworthy answers.

6. A DEM with no declared CRS

Unlike the rest of the Raster family, this isn’t a cosmetic “Unknown ⚠️” row: the R cell above refuses to compute at all on a CRS-less file (stop(), not a graceful fallback), because a viewshed genuinely cannot be placed on Earth without knowing where the file already is. Click below to load a DEM with the CRS deliberately omitted, then run the R cell in section 4 to see the refusal itself, surfaced as a normal R error in the cell’s output.

7. Where to next

• Just needed the map? The standalone Viewshed Calculator click a point, no editing required.
• Combining two bands instead (a difference map, NDVI)? See Raster Band Math or NDVI: both run live in Python and R.
• Not sure what’s in the file yet? Start with Raster Inspector.

This closes the Raster family at four tools (Inspect, Calculate, NDVI, Viewshed), covering understand, compute, analyze, model.

1. Upload your file

A single .tif or .tiff, no sidecars, unlike a shapefile.

2. Why start with a summary?

Eight numbers, each answering a question that’s otherwise easy to get wrong by assumption:

• Dimensions: width × height in pixels. Determines how much work any pixel-by-pixel operation actually is, and whether a “small” file is small in bytes but enormous in pixel count (or the reverse).
• Bands: one grid of numbers, or several stacked together (RGB, a multispectral stack, a time series). Some checks and most visualizations only make sense once you know how many there are.
• CRS: same coordinate reference system concept as a vector file. A missing CRS is reported as genuinely unknown, not silently relabeled as WGS84. The map still needs some projection to place the footprint, so that assumption is shown separately, labeled as a display choice rather than folded into the CRS field itself.
• Resolution: the ground distance one pixel actually covers, in the file’s own CRS units. A 30 (Landsat-scale) versus a 0.001 (sub-meter) changes what questions the data can even answer.
• Data type: uint8, int16, float32, … . The single most common source of a “why are all my values 0 or wildly wrong” surprise: an integer type storing values that were meant to be divided by a scale factor, or a float column silently truncated by being written back as an integer type.
• NoData: the sentinel value marking “no measurement here” (often -9999, 0, or a type’s max value), as fundamental to a raster as a null is to a table column, and just as easy to accidentally treat as a real number if it isn’t checked first.
• Bounds: the same bounding-box sanity check as a vector file: numbers wildly outside -180..180 / -90..90 are the CRS-mismatch tell, here too.
• Value range: the per-band min/max/mean, with NoData pixels correctly excluded. The fastest way to catch a unit mistake (a “temperature in Celsius” band whose values run from 200 to 320 is actually Kelvin) before it reaches an analysis.

3. Shared map and summary

4. Inspect: summarize your file

Run the same summary in Python or R on the current data (your file uploaded above, or the built-in example below).

7. Where to next

A summary is a starting point:

• Just needed the numbers? The standalone Raster Inspector has the same summary, no reading required.
• Working with vector data instead? Start with First Look at a Geospatial File, the same idea, for GeoJSON and Shapefile.
• Need to combine two bands into a result (a difference map, a Normalized Difference like NDVI)? See Raster Band Math, or the standalone Raster Calculator.

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. Why a CRS problem is different

A geometry can be perfectly valid, and every feature can be perfectly consistent with every other, and the whole file can still land thousands of kilometers from where it should. GeoJSON, and MapLibre, the map library this whole site draws with, assume every coordinate is WGS84 (plain longitude/latitude). Neither reprojects anything on its own: whatever numbers you hand them, that’s where they land.

• CRS: the coordinate reference system a file declares it’s in, read from its own metadata (a .prj file for a shapefile, a crs object for GeoPandas/sf). Some files declare none at all.
• Geographic vs. projected: a geographic CRS (WGS84 is the common one) uses degrees, roughly -180..180 longitude and -90..90 latitude. A projected CRS (UTM zones, Web Mercator, national grids) uses linear units, usually meters, and the numbers involved are routinely in the hundreds of thousands or millions.
• The mismatch: a file can declare one kind of CRS while its actual coordinate values look like the other. That disagreement is the single most common reason a map “looks wrong” before you’ve touched a single geometry.

3. Shared map and detection

5. Convert to a different CRS

Once you know the CRS, changing it is one call: to_crs() in GeoPandas, st_transform() in sf. Reuses exactly the data just diagnosed above (gdf in Python, data in R stay in the session between one cell and the next), no new reading of the file.

6. Where to next

• Geometry looks fine, dataset doesn’t? → Topology errors covers overlaps, gaps, slivers, duplicates and dangles: relationships between features, a different problem from CRS entirely.
• Not sure where to start? → The GeoSpatial File Inspector gives a five-second summary of a file (feature count, geometry type, CRS, bounds, attributes) before you dig into any one check.
• Just needed the check? → The standalone CRS Inspector & Converter runs the same detection and lets you convert and download directly.

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. Why start with a summary?

Eight numbers, each answering a question you’d otherwise have to dig for:

• Features: how many rows. Determines whether an O(n²) check (like the Topology Checker’s pairwise overlap/gap detection) is even practical to run.
• Geometry type: Point, Line, Polygon, or a mix. Some checks only apply to one family; a “mixed” result is itself useful information.
• CRS: the coordinate reference system the file claims to be in. Not verified against the actual coordinates here: that mismatch detection is a distinct, more involved check, covered in Coordinate Reference Systems and the standalone CRS Inspector.
• Bounds: the bounding box, in the file’s own CRS units. A bounding box in the thousands or millions instead of the -180..180 / -90..90 range is usually the first hint of a CRS problem, before any dedicated check runs.
• Attributes: how many non-geometry columns, and their names. How much there is to a feature beyond its shape.
• Invalid: geometries that fail the Simple Features validity rules. See Geometry validity for what that actually means and how to fix it.
• Empty: geometries with no coordinates at all. Easy to miss in a raw file, and something naive code (yours or a library’s) can choke on silently.
• Duplicates: exact repeats (identical coordinates), detected by comparing binary geometry representations, not a full topological equality check. Fast enough for a large file; the Topology Checker has the slower, more thorough version if you need it.

3. Shared map and summary

4. Inspect: summarize your file

Run the same summary in Python or R on the current data (your file uploaded above, or the example already loaded below).

7. Where to next

A summary is a starting point, not an endpoint:

• CRS looks off? → Coordinate Reference Systems covers the mismatch heuristic above in depth, with conversion, or use the standalone CRS Inspector directly.
• Invalid geometries? → Geometry validity explains why, and how make_valid()/st_make_valid() fix it, or use the standalone Validator directly.
• Everything valid, but the dataset still looks wrong? → Topology errors covers overlaps, gaps, slivers, duplicates, and dangles: relationships between features, not properties of any one of them, or use the standalone Topology Checker.
• Just needed the numbers? The standalone Inspector has the same summary, no reading required.

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:

3. Shared map and table

Python and R draw to separate layers here too, and both stay visible at once (in their own language tab below), so you can compare them directly. Running one language doesn’t clear or “correct” the other’s result; if the default example below looks unchanged after running the second language, that’s usually because both languages are checking the exact same coordinates and landing on the exact same shapes, not because anything failed.

Pick a language, then what to look at: the original geometries (with errors highlighted) or just the gaps found between them.

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.

Can a polygon look normal and still be invalid?

flowchart LR
    A["🗺️ Looks fine on the map"] --> B{"Validity check"}
    B --> C["❌ INVALID: 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 six 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. The two languages draw to two separate layers: running one doesn’t clear or change what the other already drew, so both stay visible together (and in their own tab in the table below) for a direct comparison. Running R doesn’t “correct” or replace Python’s result, and vice versa. If you want to see a language’s result change, re-run that language’s own cell.

Diagnose: validate your geometry

Run the same check in Python or R on the current data: your file uploaded above, or, if you haven’t uploaded one, the bowtie example below (the diagnosis cells load it automatically when there’s no upload). No repair yet, just diagnosis: is the geometry valid? If not, why?

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:

Gallery of geometric errors

GEOS reports one of a small, closed set of validity failures, not a free-text description: an exact list, verified against TopologyValidationError.cpp in the GEOS source itself. The diagnose cells above match every message to one of these names, shown in the “category” column; a message that matches none of them shows up as “Other” rather than being forced into the closest one.

* Valid under R’s default S2 engine, invalid under GEOS: see Where R and Python actually disagree, past Repair.

Of the rows without an example, “Interior is disconnected” belongs to the same family as the crossing cases below, “Nested shells” needs two full polygons to set up, and “Too few points” and “Invalid Coordinate” are rarely produced by a real file. The last three are worth being honest about: they’re real GEOS categories the classifier still recognizes if they ever show up, but none of them could be reproduced through an actual upload here. As of GEOS 3.11+, a repeated point is reported as “Too few points” instead (verified live, not assumed from the changelog). Every duplicate-ring construction tried got caught as “Self-intersection” first, before that check ever ran. And both GeoJSON and Shapefile close every ring at the file format level, before geopandas or sf ever see it, so an unclosed ring never reaches GEOS.

Each example below loads its own data into the diagnosis cell pair above. No repair here, that’s in the Repair section further down.

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), with 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.