1 Commits

Author SHA1 Message Date
8d1d874ad7 Shapefile export: write the format ourselves instead of shp-write
Choosing Shapefile in the Export GIS modal produced no file. shp-write@0.3.2
cannot run in this build, in three separate ways: its dbf dependency assigns an
undeclared variable, which was fine in the browserify bundle it was written for
but is a ReferenceError under the strict mode ES modules always use; its zip.js
branches on process.browser, which does not exist in a browser; and its
download.js delivers the archive by navigating to a data:application/zip URL,
which Chromium blocks in the top frame.

- src/shapefile-write.js writes .shp/.shx/.dbf/.prj/.cpg itself: geometries
  split by type into up to three layers, polygon rings re-wound clockwise as
  the format requires, DBF column types inferred per column, names sanitised
  to DBF's 10 characters and de-duplicated, UTF-8 declared via .cpg.
- src/zip-store.js holds the STORED-ZIP writer that was inside analysis/xlsx.js,
  so both writers share it. Pure-ASCII archives are byte-for-byte as before.
- shp-write, and with it dbf and JSZip 2.5.0, leave the dependency tree; the
  build no longer warns that node's "assert" was externalised.
- Service Worker v26 for the new bundle.

Verified in a browser: the Export GIS modal, driven through its own controls
with Web Mercator features, produced area_analysis.zip holding both layers with
WGS84 coordinates, file code 9994 and the right shape types. The archive reads
back through the application's own shpjs importer with geometries, numeric,
text and boolean attributes intact. The zonal-statistics .xlsx export, which now
shares the zip writer, still opens and reads correctly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-23 13:40:00 +02:00