mapsmith 0.5.0__tar.gz → 0.6.0__tar.gz

{mapsmith-0.5.0 → mapsmith-0.6.0}/.zenodo.json

@@ -1,7 +1,7 @@
 {
   "upload_type": "software",
   "title": "MapSmith: geospatial processing over MCP, with verifiable provenance",
-  "version": "0.5.0",
+  "version": "0.6.0",
   "creators": [
     {"name": "The MapSmith project"}
   ],

{mapsmith-0.5.0 → mapsmith-0.6.0}/CHANGELOG.md

@@ -8,6 +8,180 @@ All notable changes to MapSmith are documented here, in the format of
 
 Nothing yet.
 
+## [0.6.0] - 2026-09-25
+
+The reason to upgrade is in **Fixed**: five operations stop reading a zone drawn
+across the 180th meridian as the rest of the planet, `nearest_join` stops
+measuring distances there 5-6% too long, and 28 writers stop leaving a dataset
+with no manifest when they fail. The reason to read before upgrading is in
+**Changed**: one manifest key is renamed.
+
+### Added
+
+- **Two cases on [mapsmith.dev](https://mapsmith.dev/#step-through) that a reader
+  steps through**, both executed while the page is built. One is a whole
+  analysis: the question in plain words, the catalogue narrowing with the counts
+  it produced, a plan refused before anything ran, five steps with their engine,
+  CRS decision and checks read from the manifests, the answer, and the chain
+  recovered from the final file alone. The other is a refusal — a GeoTIFF that
+  opens in every viewer, carrying its georeferencing twice and disagreeing with
+  itself, declined with a message naming both readings and how to choose.
+
+  Nothing in the installable product changed. The script is progressive: every
+  beat ships as ordinary HTML and the script only hides them and adds a button,
+  so the page reads in full with JavaScript off.
+
+  You pick the question, not the data, and that is a security decision rather
+  than a limitation: an upload box would mean running GDAL on files from
+  strangers, which is the assumption `SECURITY.md` is built on refusing.
+
+- **`summarize_points_in_polygons`**: a numeric attribute of the points in each
+  polygon — count, sum, mean, median, min, max, stdev, range. "Average pH by
+  field block" used to take two operations, which to somebody searching is an
+  operation that does not exist. Three decisions about the number are in the
+  record: a polygon with no points is kept with its statistics null, because
+  the mean of no values is not zero; a point with no value is placed and not
+  summarised, so `<field>_count` can be smaller than `point_count` and says so;
+  and the boundary rule is the caller's, with the number of points it counted
+  twice or dropped. A check reads the output back and verifies the counts add
+  up to what the join found. Points only: a MultiPoint is refused rather than
+  carried whole into every polygon it touches, and a Shapefile output is
+  refused where the driver would truncate a column into the attribute's own
+  name. Reached through `run_operation`; the tool count is unchanged.
+
+### Changed
+
+- **Records declare `spec_version` `1.0.0-draft.6`, and `x-mapsmith:round_trip`
+  is now `round_trip`.** Breaking for anyone who reads that key. The
+  specification gained a core key for "computed in another CRS and written back
+  in the caller's", with the two legs MapSmith already recorded, and draft.6
+  forbids recording that fact under a prefixed name: two producers naming the
+  same fact differently is two facts to a consumer. The shape is unchanged —
+  `transformation` for the way out, `return_transformation` for the way back —
+  so a reader needs to change the key it looks up and nothing else.
+
+### Fixed
+
+- **`count_in_polygons(predicate="contains")` never placed a point, and said it
+  had verified.** `sjoin(points, polygons, predicate)` evaluates the predicate
+  as `predicate(point, polygon)`, so `contains` asked whether a point contains
+  a polygon — false for any polygon with area. Every count came back zero, the
+  record said `verified: true`, and the one check that noticed was
+  non-critical and blamed the points for lying outside every polygon. Even the
+  reading that was meant, the polygon containing the point, is exactly
+  `within`. `contains` is refused now, with the two predicates that mean
+  something for points; a caller using it was getting zeros, so nothing that
+  worked stops working. Found while building its sibling above, which had
+  inherited the same line.
+- **`count_in_polygons` counted a MultiPoint once in every polygon it touched,
+  and blamed the polygons for points that had no position.** Both measured
+  before the fix: a MultiPoint straddling two squares came back as one point in
+  each, and a null and an empty geometry were reported as "2 of 3 points fall
+  in no polygon" with a hint about checking the boundaries. Multi-part and
+  areal geometries are refused now, with the way out; points without a
+  geometry are counted apart as `points_without_geometry` and no longer fail
+  the placement check.
+- **A zone drawn across the 180th meridian as one ring counted the wrong
+  points, and the total could be right.** Every planar library reads such a
+  ring as its complement, the rest of the planet. Measured with two points, one
+  at 175°E inside the zone and one at 0°: the first was dropped, the second
+  counted, and the total was 1 — the same as the truth. Both point-in-polygon
+  operations now refuse that ring with the way out (split it at 180, as RFC
+  7946 §3.1.9 prescribes, which then places correctly). The detector is in
+  `antimeridian.naive_crossings` and only looks at layers in degrees.
+  Measured the same way on the other region operations before extending it:
+  `clip_layer`, `spatial_join` and `overlay_layers` each returned the feature
+  on the far side of the world instead of the one inside the zone, and
+  `nearest_join` returned nothing; all four refuse that ring now, on either
+  input, and `spatial_join` on every engine — GeoParquet in one CRS is routed
+  to DuckDB or SedonaDB, which read the ring the same planar way. `measure_area`
+  is not affected — its geodesic area follows the edge the short way — and is
+  left alone.
+
+  What is **not** refused, because it is not the defect: an edge that runs
+  from -180 to 180 along the edge of the plane. That is how a rectangle
+  covering the world, a latitude band, a polar cap and Antarctica in the
+  Natural Earth countries file close their rings, and a first version of the
+  detector refused all four — so "points per country" would have been refused.
+  Found by the pre-release review, and the Natural Earth file is a test now.
+- **`nearest_join` measured distances 5-6% too long across the antimeridian,
+  with no warning.** It works in an estimated UTM zone, and GeoPandas centres
+  that estimate on the mean of `minx` and `maxx`: for data straddling 180 that
+  is about 0, so two points at 175°E and 175°W were given EPSG:32630, centred on
+  3°W. Their distances to a zone three degrees away came back as 351.7 and
+  354.0 km where the truth is 334.0. `antimeridian.estimate_utm_crs` centres on
+  the true extent instead (here UTM 1N, within one per cent), and returns
+  exactly what GeoPandas does for data that `describe_dataset` does not report
+  as crossing. That definition is wider than touching 180: points at 100°E and
+  170°W are closer going across it, and now get UTM 55N, centred on 147°E,
+  where GeoPandas gave 25N, centred on 33°W. A layer split at 180 as a single MultiPolygon, the
+  form the refusal above asks for, is read part by part and counts as crossing.
+  `buffer_layer`, `simplify_layer` and `centroid_layer` use it too; a 1 km
+  buffer had measured correctly even in the far zone, so for them it is the
+  right zone rather than a fix.
+
+- **Five operations wrote a fact into the manifest before it happened.** The
+  record survives a crash, which is the point of it, and on these paths it
+  survived carrying a sentence that had become false.
+  - `simplify_layer`, `centroid_layer` and `nearest_join` recorded the round
+    trip before the way back ran, and the way back runs inside the block that
+    writes the record on failure. A return leg that raised left a manifest
+    asserting a trip that never finished. `buffer_layer` had the right order
+    by accident. The trip is recorded only once the output is home, and
+    draft.6 now requires exactly that of every producer.
+  - `reproject_layer` and `reproject_raster` recorded `target_crs` and the
+    transformation before any coordinate moved, so a failed reprojection said
+    where the data had been put and by which operation — with a seven-metre
+    datum shift, on a NAD27 input, beside geometry that had not gone anywhere.
+  - Three `reason` strings said "output geometries are returned in the input
+    CRS", written before the work and surviving on the failing path while the
+    key correctly disappeared. The key says it now, when it is true.
+- **`reproject_raster` could leave a raster with no manifest beside it.** A
+  warp that raised on the second of three bands left a 19608-byte file on disk
+  — band one warped, two and three zero-filled — and nothing describing it.
+  The write is inside the failure audit now, and a partial file carries a
+  record that says `x-mapsmith:operation_completed: false`.
+- **The same defect was in 28 of the 58 writers 0.5.1 shipped, found by
+  looking for it everywhere instead of where it had last been seen.** A write
+  that died halfway, or a check that raised after the output reached the disk,
+  left the dataset with nothing beside it: in `resample_raster` — the twin of
+  the operation above — and in the thirteen Whitebox operations, `run_sql`,
+  five more raster operations (`reproject_raster` among them, whose write was
+  covered and whose reading-back was not), both sampling operations and six
+  vector ones. Every writer now holds the net from its first byte to its
+  manifest, and `tests/test_failure_manifest.py` injects both failures into
+  every writing operation the catalogue lists. Run against the code just
+  before this change, it fails on those 28 and on one more,
+  `summarize_points_in_polygons`, which had inherited the shape before it ever
+  shipped — and on no other.
+
+### Security
+
+- **No workflow job that runs this repository's code can mint an OIDC token.**
+  The MCP Registry grants `io.github.mapsmith-ai/*` to a token from any
+  workflow of this owner. The site workflow granted `id-token: write` to all
+  its jobs, including the one that runs `pip install` and our own build
+  scripts; only the deploy job, which runs one pinned action, holds it now.
+  The new registry workflow publishes a tag only if its commit is on `main` and
+  its own CI run passed — a dry run on `v0.5.0`, whose CI failed, stops there.
+
+## [0.5.1] - 2026-09-21
+
+### Fixed
+
+- **0.5.0 is yanked on PyPI, and the reason is its own page.** The release
+  procedure builds and uploads only after the tag's CI is green, because that
+  run is the one that checks the README against the release it claims to
+  describe. The upload went first: PyPI took the sdist whose front page says
+  *"This page describes 0.4.0"* and *"`main` is ahead of 0.4.0 today"*, and a
+  PyPI page cannot be edited afterwards. The code in 0.5.0 is the code here;
+  what is wrong is the artefact describing itself as the previous version, on
+  a product whose argument is that records describe what they say they do.
+  0.5.1 is 0.5.0 with that paragraph correct.
+
+  Nothing else moved: records still declare `spec_version` `1.0.0-draft.5`, the
+  tool surface is the same, and the entries below are this release's.
+
 ## [0.5.0] - 2026-09-21
 
 Everything here was on `main` and not in a release. It is almost entirely

{mapsmith-0.5.0 → mapsmith-0.6.0}/CITATION.cff

@@ -12,8 +12,8 @@ identifiers:
     value: "10.5281/zenodo.22213091"
     description: "Concept DOI — always resolves to the latest release"
 license: AGPL-3.0-or-later
-version: "0.5.0"
-date-released: "2026-09-21"
+version: "0.6.0"
+date-released: "2026-09-25"
 keywords:
   - GIS
   - geospatial