GIS Code: Why "No Errors" Doesn't Mean "Correct"

Executing a script without a traceback is a dangerous metric for success in geospatial analysis. I've noticed that AI coding agents are incredibly proficient at API syntax for GeoPandas or Rasterio, but they often miss the underlying spatial logic. You can get a perfectly rendered map that is methodologically useless.

The Silent CRS Trap

The most common "invisible" failure is the Coordinate Reference System (CRS) mismatch. An AI might suggest a simple buffer like this:

buffered = gdf.buffer(1000)

If your data is in EPSG:4326, that 1000 isn't meters—it's degrees. The code runs, the geometries are created, but your analysis is fundamentally broken. To build a real-world AI workflow for GIS, you have to force the agent to be explicit about projections.

A more robust approach looks like this:

if gdf.crs is None:
    raise ValueError("The input dataset has no CRS.")

if gdf.crs.is_geographic:
    projected_crs = gdf.estimate_utm_crs()
    if projected_crs is None:
        raise ValueError("A suitable projected CRS could not be determined.")
    gdf = gdf.to_crs(projected_crs)

buffered = gdf.buffer(1000)

Even then, you have to watch out for datasets spanning multiple UTM zones. API correctness $\neq$ spatial correctness.

Spatial Autocorrelation in ML

Another area where AI-generated code leads me astray is in model evaluation. A standard train_test_split is the default suggestion for almost any ML task:

from sklearn.model_selection import train_test_split

X_train, X_test, y_train, y_test = train_test_split(
    X, 
    y, 
    test_size=0.2, 
    random_state=42
)

In GIS, this is often a mistake. Because nearby points are usually similar (spatial autocorrelation), a random split puts neighboring samples in both sets. Your accuracy score looks amazing, but the model is just memorizing local patterns. It’ll likely crash and burn the moment you apply it to a new region.

For a honest deep dive into model performance, you need:

• Spatial blocking or geographic grouping
• Region-level holdouts
• Distance-based separation

Rendering is not Verification

The final gotcha is the "pretty map" fallacy. A map can render perfectly while using a misleading projection or ignoring missing values. Just because the software produced an image doesn't mean the analysis is valid.

When using an LLM agent for GIS, I've found you have to provide explicit operational rules in your prompt engineering, such as "Never calculate area or distance in a geographic CRS" or "Always verify spatial alignment before performing raster math."