README: add "Does it work?" section (addresses #46); drop "honest"

- Move the geospatial-suite pointer out of "What is this?" into a new
  "Does it work?" section, placed between "How does it work?" and "Why does
  this work?", reframed to answer that question with a findings summary
  (validated operations, real datasets, the GraphCast-beats-Pangu result).
  Addresses #46.
- Reword the two remaining uses of "honest" in docs/geospatial.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AWvrZYAT2NbuETBqNAN3o9

Author: alxmrs

README.md

@@ -108,12 +108,6 @@ _(A runnable version of this example lives at
 Succinctly, we "pivot" Xarray Datasets to treat them like tables so we can run
 SQL queries against them. 
 
-For worked examples of common geospatial operations expressed in SQL — NDVI,
-climatology, anomalies, zonal statistics, forecast skill (Pangu-Weather and
-GraphCast vs ERA5), reprojection, and regridding, each checked against an xarray
-reference — see [`benchmarks/geospatial/`](benchmarks/geospatial/) and the
-[Geospatial operations are relational operations](docs/geospatial.md) write-up.
-
 ## Why build this?
 
 A few reasons:
@@ -148,6 +142,33 @@ that lets the DB engine translate the underlying Dataset arrays into DataFusion
 Ultimately, the initial insight of the `pivot()` function -- that any ndarray can be
 translated into a 2D table -- underlies this performant query mechanism. 
 
+## Does it work?
+
+Yes. The recurring worry is that the SQL interface is a toy — fine for `SELECT`s,
+but not for the operations geoscience actually runs. So we wrote a suite that
+takes the staples of geospatial and climate analysis — the ones we assume *need*
+an array library — and expresses each one in SQL, then **checks the SQL answer
+against an xarray/array reference** to floating-point tolerance:
+
+* **Spectral indices** (NDVI) — column arithmetic over a real Sentinel-2 scene.
+* **Climatology, anomalies, zonal means** — `GROUP BY` and self-`JOIN` over the
+  full 0.25° **ARCO-ERA5** archive (≈1.3M hourly steps), read lazily with
+  partition pruning and column pushdown.
+* **Forecast skill** — scoring the **Pangu-Weather** and **GraphCast** ML models
+  against ERA5 (WeatherBench 2) as a `JOIN` on `valid_time = init + lead`; it
+  reproduces the published result that GraphCast beats Pangu at every lead.
+* **Raster × vector zonal stats** — a range `JOIN` of the ERA5 grid against a
+  table of regions.
+* **Reprojection and regridding** — a scalar PROJ UDF (validated against Earth
+  Engine's own geodesy via [Xee](https://github.com/google/Xee)) and a
+  sparse-weight-table `JOIN` (regridding real SRTM terrain).
+
+Every case matches its array reference. The headline finding: these operations
+are not really "array" operations at all — they are `GROUP BY`, `JOIN`, window
+functions, and `CASE` in disguise, and a query engine runs them at scale. See
+[`benchmarks/geospatial/`](benchmarks/geospatial/) and the write-up,
+[Geospatial operations are relational operations](docs/geospatial.md).
+
 ## Why does this work?
 
 Underneath Xarray, Dask, and Pandas, there are NumPy arrays. These are paged in

docs/geospatial.md

@@ -192,10 +192,10 @@ this against **Earth Engine itself**: it opens a UTM grid through
 [Xee](https://github.com/google/Xee) carrying `ee.Image.pixelLonLat()`, so EE's
 own geodesy engine reports the true lon/lat of every pixel — an *independent*
 reprojection reference, not PROJ-vs-PROJ. The SQL UDF and EE agree to sub-metre
-precision. Two honest caveats, both documented in the script: PROJ's context is
-not thread-safe (so the UDF returns both coordinates from *one* call and runs on
-a single partition), and reprojection moves coordinates without resampling onto
-a grid — which is the next operation.
+precision. Two caveats, both documented in the script: PROJ's context is not
+thread-safe (so the UDF returns both coordinates from *one* call and runs on a
+single partition), and reprojection moves coordinates without resampling onto a
+grid — which is the next operation.
 
 **Regridding is not** row-independent: each output cell is a weighted blend of
 several input cells. That is a *many-to-many* relationship — and a many-to-many
@@ -216,7 +216,7 @@ it is the most relational operation of all.
 
 ## Where the array paradigm still earns its keep
 
-The honest boundary is **weight generation**. Applying a regridding is a join;
+The boundary is **weight generation**. Applying a regridding is a join;
 *computing* the weights — cell overlaps for conservative remapping, stencils and
 spherical geometry for bilinear, the whole machinery of xESMF/ESMF — is genuinely
 geometric work that arrays (and specialized libraries) do well. The relational