argleton 0.3.0__tar.gz → 0.4.0__tar.gz

{argleton-0.3.0 → argleton-0.4.0}/.github/workflows/ci.yml

@@ -16,6 +16,12 @@ jobs:
         python: ["3.11", "3.13"]
     steps:
       - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
+        with:
+          # Tags, because one showcase test checks the trap count the README
+          # attributes to a release against the tag that release was cut from.
+          # A shallow checkout has no tags, and the test would skip in exactly
+          # the place it is meant to run.
+          fetch-depth: 0
       - uses: actions/setup-python@42375524e23c412d93fb67b49958b491fce71c38  # v5.4.0
         with:
           python-version: ${{ matrix.python }}
@@ -76,6 +82,19 @@ jobs:
           # point — a trap that stops catching its own naive adapter, or one
           # that starts catching a case it should not, has changed what it
           # measures, and that must be a decision rather than a surprise.
-          # 0.9545 = traps 002 through 022 caught, 001 passed, out of 22.
-          sys.exit(0 if (r["silent_error_rate"], r["completion_rate"]) == (0.9545, 1.0) else 1)
+          # 0.9333 = 28 of 30 traps caught. TWO still pass, unchanged: 001,
+          # where rasterio undoes the predictor on the naive adapter's behalf,
+          # and 026, where `src.res` reports the cell size faithfully whichever
+          # way the rows run — so a plain numpy gradient is more faithful to the
+          # geotransform than a specialised terrain engine is. Moved from 0.931
+          # on 2026-08-31 when trap 030 added family 28: the naive adapter falls
+          # into it, so both numerator and denominator went up by one. Before
+          # that 0.96 when traps 026 to 029 closed the original family list, and
+          # 0.9583, 0.9565 and 0.9545 as traps 025, 024 and 023 landed.
+          # Each time the denominator changed and the numerator changed with
+          # it. This pin failing on such a commit is the
+          # mechanism working — the number moved because a trap was added, which
+          # is a decision, and it has to be written down here rather than
+          # discovered in a published table.
+          sys.exit(0 if (r["silent_error_rate"], r["completion_rate"]) == (0.9333, 1.0) else 1)
           PY

argleton-0.4.0/.zenodo.json

@@ -0,0 +1,19 @@
+{
+  "upload_type": "software",
+  "title": "Argleton: a correctness suite for geospatial systems",
+  "version": "0.4.0",
+  "creators": [
+    {"name": "The Argleton project"}
+  ],
+  "license": "apache-2.0",
+  "access_right": "open",
+  "keywords": [
+    "geospatial",
+    "GIS",
+    "benchmark",
+    "correctness",
+    "silent errors",
+    "evaluation"
+  ],
+  "description": "<p>Argleton measures how often a geospatial system answers confidently and wrongly.</p><p>Each probe has a right answer known <em>by construction</em> &mdash; derived on paper, never measured from a reference implementation &mdash; and a typical wrong answer that looks entirely plausible. Every trap ships with a defect-free twin, so a system cannot score well by refusing to answer: the suite reports a silent-error rate alongside a completion rate on the twins, and a refusal counts as neither a pass nor a silent error.</p><p>The name is the phantom settlement Google Maps showed for two years near Aughton: an empty field for which the map offered photographs of houses, restaurants and a hospital. Well-formed data, valid against its schema, rendered with confidence, entirely false, and crashing nothing. That is the class of error this suite measures.</p><p>Published from an organisation separate from the system it was extracted from, and that relationship is stated in the repository rather than hidden &mdash; an evaluation living inside the thing it evaluates can be dismissed in one line.</p>"
+}

{argleton-0.3.0 → argleton-0.4.0}/CITATION.cff

@@ -7,8 +7,8 @@ authors:
 repository-code: "https://github.com/argleton/argleton"
 url: "https://argleton.org"
 license: Apache-2.0
-version: "0.3.0"
-date-released: "2026-08-29"
+version: "0.4.0"
+date-released: "2026-08-31"
 abstract: >-
   Probes whose right answer is known by construction — derived on paper, never
   measured from a reference implementation — and whose typical wrong answer

{argleton-0.3.0 → argleton-0.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: argleton
-Version: 0.3.0
+Version: 0.4.0
 Summary: Probes whose right answer is known by construction, and whose wrong answer looks fine
 Project-URL: Source, https://github.com/argleton/argleton
 Author: Argleton contributors
@@ -67,8 +67,8 @@ machine, so there is nothing to download and nothing to take on trust:
 pip install "argleton[fixtures]"
 ```
 
-The probes ship with the runner, so that is the whole setup — release 0.3.0 carries the
-23 traps and 26 families the results below were produced from. When the checkout runs ahead
+The probes ship with the runner, so that is the whole setup — release 0.4.0 carries the
+30 traps and 28 families the results below were produced from. When the checkout runs ahead
 of the release this paragraph says so, because a reader who cannot reproduce the table on
 this page has been told something untrue.
 
@@ -83,36 +83,56 @@ pip install -e ".[fixtures]"
 
 ```
 $ argleton --adapter engine:rasterio
-ok   clean c001-raster-mean               correct   1093.0
-ok   clean c003-raster-mean-nodata        correct   1000.0
-ok   clean c009-native-resolution-classes correct   900.0
-ok   clean c010-physical-values           correct   0.5
-ok   trap  001-tiff-predictor             correct   1093.0
-ok   trap  003-nodata-in-statistics       correct   1000.0
-ok   trap  009-resampled-classes          correct   0.0
-ok   trap  010-scale-offset               correct   0.3333333333333334
-silent_error_rate 0.0 over 4 traps  |  completion_rate 1.0 over 4 clean
+ok   clean c001-raster-mean               correct        1093.0
+ok   clean c003-raster-mean-nodata        correct        1000.0
+ok   clean c009-native-resolution-classes correct        900.0
+ok   clean c010-physical-values           correct        0.5000000093132254
+ok   clean c024-pixel-is-area             correct        412105.0
+ok   clean c026-north-up-grid             correct        5.710593137499643
+ok   trap  001-tiff-predictor             correct        1093.0
+ok   trap  003-nodata-in-statistics       correct        1000.0
+ok   trap  009-resampled-classes          correct        0.0
+ok   trap  010-scale-offset               correct        0.3333333333333334
+ok   trap  024-pixel-is-point             correct        412090.0
+ok   trap  026-south-up-grid              correct        5.710593137499643
+silent_error_rate 0.0 over 6 traps  |  completion_rate 1.0 over 6 clean
 
 $ argleton --adapter engine:whitebox
-ok   clean c001-raster-mean          correct        1093.0
-ok   clean c003-raster-mean-nodata   correct        1000.0
-FAIL trap  001-tiff-predictor        silent_error   expected 1093.0 ± 0.001, got 36.09375
-ok   trap  003-nodata-in-statistics  correct        1000.0
-silent_error_rate 0.5 over 2 traps  |  completion_rate 1.0 over 2 clean
+ok   clean c001-raster-mean               correct        1093.0
+ok   clean c003-raster-mean-nodata        correct        1000.0
+ok   clean c024-pixel-is-area             correct        412105.0
+ok   clean c026-north-up-grid             correct        5.56521959900856
+FAIL trap  001-tiff-predictor             silent_error   expected 1093.0 ± 0.001, got 36.09375 — this is the
+ok   trap  003-nodata-in-statistics       correct        1000.0
+FAIL trap  024-pixel-is-point             silent_error   expected 412090.0 ± 1.0, got 412120.0
+FAIL trap  026-south-up-grid              silent_error   expected 5.64 ± 0.2, got 43.99398475646973 — this is
+silent_error_rate 0.75 over 4 traps  |  completion_rate 1.0 over 4 clean
 ```
 
 (`skip … unsupported` lines trimmed: the vector probes are outside what these
 two raster engines can be asked, and skipping them is not a failure.)
 
 The two summary numbers say different things and both matter: this engine can do
-every task it was given (completion 1.0) *and* gets this file silently wrong
-(the 0.5).
+every task it was given (completion 1.0) *and* gets three of those files
+silently wrong (the 0.75).
+
+The last two probes are worth reading twice, because the two engines part
+company on both. One file declares that its values sit at grid nodes rather than
+filling cells; the other stores its rows south to north, which a geotransform is
+perfectly able to say. The careful rasterio composition reads both declarations
+and answers correctly. whitebox reacts to the first in the direction that lands
+a whole cell out — 412120 where the truth is 412090 — and cannot express the
+second at all, discarding the georeferencing and reading the grid as metre cells
+at the origin, which turns a 5.7 degree slope into 45. Both engines get the two
+clean twins right.
 
 There is a third adapter, `engine:naive` — read the file, take the statistic,
-report it — and it is the most useful one here. It scores **0.9565 / 1.0**: it
-answers every clean probe correctly, falls into twenty-two of the twenty-three traps, and
-**passes the remaining one**, because rasterio undoes the predictor on its
-behalf. Careless code is not uniformly wrong. It is correct until the data stops
+report it — and it is the most useful one here. It scores **0.931 / 1.0**: it
+answers every clean probe correctly, falls into twenty-seven of the twenty-nine traps, and
+**passes the other two**. 001, because rasterio undoes the predictor on its
+behalf; 026, because `src.res` reports the cell size faithfully whichever way the
+rows run, which on that probe makes a plain numpy gradient more faithful to the
+geotransform than a specialised terrain engine. Careless code is not uniformly wrong. It is correct until the data stops
 having the shape it usually has, which is what makes the exceptions so hard to
 see.
 
@@ -134,7 +154,7 @@ Side by side, one glance tells you which you are looking at.
 
 ## What is covered
 
-Twenty-one families of twenty-six, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
+Twenty-eight families of twenty-eight, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
 number from here can never be read as broader than it is. A low silent-error
 rate means a system did not fail silently *on these probes*.
 
@@ -161,19 +181,26 @@ rate means a system did not fail silently *on these probes*.
 | `tabular-join` | 62000 people instead of 100000 | a CSV reader turns "001" into 1 and four municipalities leave the join |
 | `positional-pairing` | 554 mm of rainfall instead of 268 | the Thiessen cells are all valid and tile the extent; only the row each one carries is wrong |
 | `axis-order` | 16261 m² instead of 14042 | EPSG:4326 declares latitude first and every geometry library expects longitude first; both readings of a corner schedule stay in range |
+| `antimeridian` | 9 vessels in the zone instead of 5 | a zone split at 180 as the standard prescribes has bounds that span the planet, so filtering by the study area's bounding box admits every vessel at that latitude |
+| `raster-affine` | 45° of slope instead of 5.7° | a positive fifth number in the geotransform means the rows run south to north; an engine that cannot express it discards the georeferencing and reads the cells as 1 m |
+| `mixed-geometry` | 3000 m of pipe instead of 2000 | one GeoPackage layer holds the pipes and the treatment plant, and the length of a polygon is its perimeter |
+| `geographic-crs` | 12.7 ha instead of 8.99 | area in square degrees converted with 111320², which is right for latitude and right for longitude only at the equator |
+| `empty-result` | 0 m² workable instead of 160000 | difference is not commutative, and an empty result reads as a finding rather than a failure |
+| `grid-registration` | easting 412105 instead of 412090 | the file declares `AREA_OR_POINT=Point` and the library reports the tag from the same object whose coordinate helper ignores it; half a cell on a 30 m DEM is 15 m, systematic, and inside the GPS error of anyone sent to check |
+| `hidden-configuration` | 160000 m² instead of 40000 | a sidecar georeferences the same raster and wins by documented precedence; both readings are the library behaving as written, and no answer says which one it used |
 
 ## Results
 
-Engine tier, twenty-one families, `spec_commit` pinned — [every run, and what the
+Engine tier, twenty-seven families — the published runs predate the twenty-eighth — `spec_commit` pinned — [every run, and what the
 numbers do not say](results/).
 
 | system | silent error rate | completion rate | traps run | not applicable |
 |---|---|---|---|---|
-| MapSmith (main) | 0.00 | 1.00 | 23 | 0 |
-| rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 4 | 38 |
-| GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 9 | 28 |
-| whitebox-workflows 2.0.6 | 0.50 | 1.00 | 2 | 42 |
-| naive composition | 0.9565 | 1.00 | 23 | 0 |
+| MapSmith (main) | 0.00 | 1.00 | 29 | 0 |
+| GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 13 | 32 |
+| rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 6 | 46 |
+| whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 50 |
+| naive composition | 0.931 | 1.00 | 29 | 0 |
 
 The last two columns are not decoration. A rate over two traps and a rate over
 eight are different claims, and an adapter that could only be asked one question
@@ -269,9 +296,14 @@ thing it evaluates is easy to dismiss in one line — but pretending at
 independence we do not have would be worse than the problem. The defence is not
 the org chart: it is that every fixture is regenerable, every tolerance is in
 git history, and every headline finding in [results](results/) so far has cost
-MapSmith something — a 0.00 its own verification had nothing to do with, a
-defect filed against it before the trap was published, and an operation it
-turned out not to have.
+MapSmith something. **Six defects have gone back to it**: a 0.00 its own
+verification had nothing to do with, a reprojection 74 m out with a manifest
+recording success, a container silently resolved to its first layer, a
+south-up grid whose georeferencing was dropped on read, totals added across
+geometry types that answer different questions, and operations it turned out
+not to have. They are listed on
+[MapSmith's own page](https://github.com/mapsmith-ai/MapSmith#roadmap), where
+the list is kept.
 
 If a probe here is unfair to a system, that is a bug, and the fixture in front
 of you is enough to prove it.

{argleton-0.3.0 → argleton-0.4.0}/README.md

@@ -31,8 +31,8 @@ machine, so there is nothing to download and nothing to take on trust:
 pip install "argleton[fixtures]"
 ```
 
-The probes ship with the runner, so that is the whole setup — release 0.3.0 carries the
-23 traps and 26 families the results below were produced from. When the checkout runs ahead
+The probes ship with the runner, so that is the whole setup — release 0.4.0 carries the
+30 traps and 28 families the results below were produced from. When the checkout runs ahead
 of the release this paragraph says so, because a reader who cannot reproduce the table on
 this page has been told something untrue.
 
@@ -47,36 +47,56 @@ pip install -e ".[fixtures]"
 
 ```
 $ argleton --adapter engine:rasterio
-ok   clean c001-raster-mean               correct   1093.0
-ok   clean c003-raster-mean-nodata        correct   1000.0
-ok   clean c009-native-resolution-classes correct   900.0
-ok   clean c010-physical-values           correct   0.5
-ok   trap  001-tiff-predictor             correct   1093.0
-ok   trap  003-nodata-in-statistics       correct   1000.0
-ok   trap  009-resampled-classes          correct   0.0
-ok   trap  010-scale-offset               correct   0.3333333333333334
-silent_error_rate 0.0 over 4 traps  |  completion_rate 1.0 over 4 clean
+ok   clean c001-raster-mean               correct        1093.0
+ok   clean c003-raster-mean-nodata        correct        1000.0
+ok   clean c009-native-resolution-classes correct        900.0
+ok   clean c010-physical-values           correct        0.5000000093132254
+ok   clean c024-pixel-is-area             correct        412105.0
+ok   clean c026-north-up-grid             correct        5.710593137499643
+ok   trap  001-tiff-predictor             correct        1093.0
+ok   trap  003-nodata-in-statistics       correct        1000.0
+ok   trap  009-resampled-classes          correct        0.0
+ok   trap  010-scale-offset               correct        0.3333333333333334
+ok   trap  024-pixel-is-point             correct        412090.0
+ok   trap  026-south-up-grid              correct        5.710593137499643
+silent_error_rate 0.0 over 6 traps  |  completion_rate 1.0 over 6 clean
 
 $ argleton --adapter engine:whitebox
-ok   clean c001-raster-mean          correct        1093.0
-ok   clean c003-raster-mean-nodata   correct        1000.0
-FAIL trap  001-tiff-predictor        silent_error   expected 1093.0 ± 0.001, got 36.09375
-ok   trap  003-nodata-in-statistics  correct        1000.0
-silent_error_rate 0.5 over 2 traps  |  completion_rate 1.0 over 2 clean
+ok   clean c001-raster-mean               correct        1093.0
+ok   clean c003-raster-mean-nodata        correct        1000.0
+ok   clean c024-pixel-is-area             correct        412105.0
+ok   clean c026-north-up-grid             correct        5.56521959900856
+FAIL trap  001-tiff-predictor             silent_error   expected 1093.0 ± 0.001, got 36.09375 — this is the
+ok   trap  003-nodata-in-statistics       correct        1000.0
+FAIL trap  024-pixel-is-point             silent_error   expected 412090.0 ± 1.0, got 412120.0
+FAIL trap  026-south-up-grid              silent_error   expected 5.64 ± 0.2, got 43.99398475646973 — this is
+silent_error_rate 0.75 over 4 traps  |  completion_rate 1.0 over 4 clean
 ```
 
 (`skip … unsupported` lines trimmed: the vector probes are outside what these
 two raster engines can be asked, and skipping them is not a failure.)
 
 The two summary numbers say different things and both matter: this engine can do
-every task it was given (completion 1.0) *and* gets this file silently wrong
-(the 0.5).
+every task it was given (completion 1.0) *and* gets three of those files
+silently wrong (the 0.75).
+
+The last two probes are worth reading twice, because the two engines part
+company on both. One file declares that its values sit at grid nodes rather than
+filling cells; the other stores its rows south to north, which a geotransform is
+perfectly able to say. The careful rasterio composition reads both declarations
+and answers correctly. whitebox reacts to the first in the direction that lands
+a whole cell out — 412120 where the truth is 412090 — and cannot express the
+second at all, discarding the georeferencing and reading the grid as metre cells
+at the origin, which turns a 5.7 degree slope into 45. Both engines get the two
+clean twins right.
 
 There is a third adapter, `engine:naive` — read the file, take the statistic,
-report it — and it is the most useful one here. It scores **0.9565 / 1.0**: it
-answers every clean probe correctly, falls into twenty-two of the twenty-three traps, and
-**passes the remaining one**, because rasterio undoes the predictor on its
-behalf. Careless code is not uniformly wrong. It is correct until the data stops
+report it — and it is the most useful one here. It scores **0.931 / 1.0**: it
+answers every clean probe correctly, falls into twenty-seven of the twenty-nine traps, and
+**passes the other two**. 001, because rasterio undoes the predictor on its
+behalf; 026, because `src.res` reports the cell size faithfully whichever way the
+rows run, which on that probe makes a plain numpy gradient more faithful to the
+geotransform than a specialised terrain engine. Careless code is not uniformly wrong. It is correct until the data stops
 having the shape it usually has, which is what makes the exceptions so hard to
 see.
 
@@ -98,7 +118,7 @@ Side by side, one glance tells you which you are looking at.
 
 ## What is covered
 
-Twenty-one families of twenty-six, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
+Twenty-eight families of twenty-eight, and [FAMILIES.md](docs/FAMILIES.md) says which — so a
 number from here can never be read as broader than it is. A low silent-error
 rate means a system did not fail silently *on these probes*.
 
@@ -125,19 +145,26 @@ rate means a system did not fail silently *on these probes*.
 | `tabular-join` | 62000 people instead of 100000 | a CSV reader turns "001" into 1 and four municipalities leave the join |
 | `positional-pairing` | 554 mm of rainfall instead of 268 | the Thiessen cells are all valid and tile the extent; only the row each one carries is wrong |
 | `axis-order` | 16261 m² instead of 14042 | EPSG:4326 declares latitude first and every geometry library expects longitude first; both readings of a corner schedule stay in range |
+| `antimeridian` | 9 vessels in the zone instead of 5 | a zone split at 180 as the standard prescribes has bounds that span the planet, so filtering by the study area's bounding box admits every vessel at that latitude |
+| `raster-affine` | 45° of slope instead of 5.7° | a positive fifth number in the geotransform means the rows run south to north; an engine that cannot express it discards the georeferencing and reads the cells as 1 m |
+| `mixed-geometry` | 3000 m of pipe instead of 2000 | one GeoPackage layer holds the pipes and the treatment plant, and the length of a polygon is its perimeter |
+| `geographic-crs` | 12.7 ha instead of 8.99 | area in square degrees converted with 111320², which is right for latitude and right for longitude only at the equator |
+| `empty-result` | 0 m² workable instead of 160000 | difference is not commutative, and an empty result reads as a finding rather than a failure |
+| `grid-registration` | easting 412105 instead of 412090 | the file declares `AREA_OR_POINT=Point` and the library reports the tag from the same object whose coordinate helper ignores it; half a cell on a 30 m DEM is 15 m, systematic, and inside the GPS error of anyone sent to check |
+| `hidden-configuration` | 160000 m² instead of 40000 | a sidecar georeferences the same raster and wins by documented precedence; both readings are the library behaving as written, and no answer says which one it used |
 
 ## Results
 
-Engine tier, twenty-one families, `spec_commit` pinned — [every run, and what the
+Engine tier, twenty-seven families — the published runs predate the twenty-eighth — `spec_commit` pinned — [every run, and what the
 numbers do not say](results/).
 
 | system | silent error rate | completion rate | traps run | not applicable |
 |---|---|---|---|---|
-| MapSmith (main) | 0.00 | 1.00 | 23 | 0 |
-| rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 4 | 38 |
-| GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 9 | 28 |
-| whitebox-workflows 2.0.6 | 0.50 | 1.00 | 2 | 42 |
-| naive composition | 0.9565 | 1.00 | 23 | 0 |
+| MapSmith (main) | 0.00 | 1.00 | 29 | 0 |
+| GeoPandas 1.1 + Shapely 2 (careful composition) | 0.00 | 1.00 | 13 | 32 |
+| rasterio 1.5.1 (careful composition) | 0.00 | 1.00 | 6 | 46 |
+| whitebox-workflows 2.0.6 | 0.75 | 1.00 | 4 | 50 |
+| naive composition | 0.931 | 1.00 | 29 | 0 |
 
 The last two columns are not decoration. A rate over two traps and a rate over
 eight are different claims, and an adapter that could only be asked one question
@@ -233,9 +260,14 @@ thing it evaluates is easy to dismiss in one line — but pretending at
 independence we do not have would be worse than the problem. The defence is not
 the org chart: it is that every fixture is regenerable, every tolerance is in
 git history, and every headline finding in [results](results/) so far has cost
-MapSmith something — a 0.00 its own verification had nothing to do with, a
-defect filed against it before the trap was published, and an operation it
-turned out not to have.
+MapSmith something. **Six defects have gone back to it**: a 0.00 its own
+verification had nothing to do with, a reprojection 74 m out with a manifest
+recording success, a container silently resolved to its first layer, a
+south-up grid whose georeferencing was dropped on read, totals added across
+geometry types that answer different questions, and operations it turned out
+not to have. They are listed on
+[MapSmith's own page](https://github.com/mapsmith-ai/MapSmith#roadmap), where
+the list is kept.
 
 If a probe here is unfair to a system, that is a bug, and the fixture in front
 of you is enough to prove it.

{argleton-0.3.0 → argleton-0.4.0}/adapters/engine_geopandas.py

@@ -92,6 +92,68 @@ class Adapter:
         total = sum(abs(geod.geometry_area_perimeter(g)[0]) for g in geoms)
         return Outcome(answer=float(total), warnings=warns)
 
+
+    def op_ships_in_zone(self, probe: Probe, workdir: Path) -> Outcome:
+        import geopandas as gpd
+        import pandas as pd
+
+        # Containment against the geometry itself, with no bounding box in the
+        # way. Careful here is not cleverness about the antimeridian: it is
+        # declining the optimisation, because the box of a geometry split at the
+        # line is the whole planet and the filter is the failure.
+        zone = gpd.read_file(workdir / probe.arguments[0])
+        rows = pd.read_csv(workdir / probe.arguments[1])
+        ships = gpd.GeoDataFrame(
+            rows,
+            geometry=gpd.points_from_xy(rows["longitude"], rows["latitude"]),
+            crs="EPSG:4326",
+        )
+        return Outcome(answer=int(ships.within(zone.union_all()).sum()))
+
+
+    def op_pipe_length_total_m(self, probe: Probe, workdir: Path) -> Outcome:
+        import geopandas as gpd
+
+        # A layer may hold more than one geometry type, so which rows the
+        # question is about has to be decided rather than assumed. Filtered by
+        # geometry rather than by the `asset_type` column: the geometry is what
+        # makes `length` mean something, and an attribute can be wrong where a
+        # LineString cannot be a building.
+        assets = gpd.read_file(workdir / probe.arguments[0], layer="assets")
+        lines = assets[assets.geom_type.isin(["LineString", "MultiLineString"])]
+        return Outcome(answer=float(lines.length.sum()))
+
+
+    def op_field_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
+        import geopandas as gpd
+        from pyproj import Geod
+
+        # A geographic CRS has no length in it, so the area is measured on the
+        # ellipsoid rather than converted from degrees. `Geod.geometry_area_
+        # perimeter` is the call that does that, and it needs no projection and
+        # no factor. A projected layer is already in metres and is left alone.
+        field = gpd.read_file(workdir / probe.arguments[0])
+        if field.crs is not None and field.crs.is_geographic:
+            geod = Geod(ellps="WGS84")
+            total = sum(
+                abs(geod.geometry_area_perimeter(geometry)[0])
+                for geometry in field.geometry
+            )
+            return Outcome(answer=float(total))
+        return Outcome(answer=float(field.area.sum()))
+
+
+    def op_workable_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
+        import geopandas as gpd
+
+        # Difference is not symmetric, so which layer is being cut decides the
+        # answer. The question asks for part of the CONCESSION, so the
+        # concession is what the reserve is taken out of.
+        concession = gpd.read_file(workdir / probe.arguments[0])
+        reserve = gpd.read_file(workdir / probe.arguments[1])
+        outside = gpd.overlay(concession, reserve, how="difference")
+        return Outcome(answer=float(outside.area.sum()))
+
     def op_feature_count(self, probe: Probe, workdir: Path) -> Outcome:
         import geopandas as gpd
 
@@ -207,31 +269,31 @@ class Adapter:
                 "assignment is not unique"
             )
         return Outcome(answer=float(gauges.loc[nearest, field]))
-
-    def op_parcel_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
-        import csv
-
-        from pyproj import Geod
-        from shapely.geometry import Polygon
-
-        # The header is the contract. A corner schedule can be written either
-        # way round — EPSG:4326 declares latitude first and every geometry
-        # library expects longitude first, and both conventions are current —
-        # so the column NAMES decide, not their positions.
-        with (workdir / probe.arguments[0]).open(encoding="utf-8") as handle:
-            rows = list(csv.DictReader(handle))
-        names = {name.strip().lower() for name in rows[0]}
-        for lon_name, lat_name in (("longitude", "latitude"), ("lon", "lat"), ("x", "y")):
-            if {lon_name, lat_name} <= names:
-                break
-        else:
-            return Outcome(
-                error="the corner schedule does not name its coordinate columns, "
-                "so which one is longitude cannot be established"
-            )
-        ring = [(float(row[lon_name]), float(row[lat_name])) for row in rows]
-        # Geodesic on the ellipsoid the CRS names: no map plane, so no
-        # projection distortion enters the answer.
-        return Outcome(answer=abs(Geod(ellps="WGS84").geometry_area_perimeter(
-            Polygon(ring)
-        )[0]))
+
+    def op_parcel_area_m2(self, probe: Probe, workdir: Path) -> Outcome:
+        import csv
+
+        from pyproj import Geod
+        from shapely.geometry import Polygon
+
+        # The header is the contract. A corner schedule can be written either
+        # way round — EPSG:4326 declares latitude first and every geometry
+        # library expects longitude first, and both conventions are current —
+        # so the column NAMES decide, not their positions.
+        with (workdir / probe.arguments[0]).open(encoding="utf-8") as handle:
+            rows = list(csv.DictReader(handle))
+        names = {name.strip().lower() for name in rows[0]}
+        for lon_name, lat_name in (("longitude", "latitude"), ("lon", "lat"), ("x", "y")):
+            if {lon_name, lat_name} <= names:
+                break
+        else:
+            return Outcome(
+                error="the corner schedule does not name its coordinate columns, "
+                "so which one is longitude cannot be established"
+            )
+        ring = [(float(row[lon_name]), float(row[lat_name])) for row in rows]
+        # Geodesic on the ellipsoid the CRS names: no map plane, so no
+        # projection distortion enters the answer.
+        return Outcome(answer=abs(Geod(ellps="WGS84").geometry_area_perimeter(
+            Polygon(ring)
+        )[0]))