Skip to content

Add abandoned-mine features from USGS USMIN - #2

Merged
scottwmccoy merged 2 commits into
mainfrom
mines-usmin
Aug 15, 2026
Merged

Add abandoned-mine features from USGS USMIN#2
scottwmccoy merged 2 commits into
mainfrom
mines-usmin

Conversation

@scottwmccoy

Copy link
Copy Markdown
Owner

Puts historic mining on the same map as the rain. Post-fire debris flows run out
of steep burned catchments, and in the Great Basin those catchments are full of
it — mine dumps and tailings are loose, often contaminated material sitting on
the channel network, exactly what a convective cell mobilises.

Why USMIN and not an AML hazard database

There is no public point-level abandoned-mine hazard database, by policy.
USGS FS 2025-3003 says the national
abandoned-mine-feature database being assembled under USMIN "will not publish
specific location information of any abandoned mine workings, and the detailed
national abandoned mine feature database will not be publicly available" —
the locations could be used to enter hazardous workings or vandalise historic
structures — and only aggregated derivatives are planned.

Nevada matches. The Division of Minerals' operational AML layers are real and
findable (NVPoints, NVSites, InternFieldDataCaptureLayers, AMLCracForms),
but every one answers 499 Token Required anonymously.

What is public is USMIN's compilation of mine symbols digitised from published
topo sheets, which reveals nothing the printed maps did not. National, uniform,
live; all 11 western states covered. Read it as a historical map compilation,
not a hazard inventory
topo_date runs 1950–1994, no hazard ranking, no
securing status, no confirmation a feature still exists.

Sources are a registry, not a hard-coded URL: NDOM is already entered with
its service URLs and a $STORMSCAPE_NDOM_TOKEN hook, so credentialed access is
--source ndom --token … rather than a code change.

What's here

  • stormscape/mines.py — six feature groups over USMIN's 55-type vocabulary
    (exact map + prefix families, so a later Tailings - X still lands in waste);
    the kind filter pushed into the service query where expressible and re-applied
    locally regardless; equal-area density as both a vector grid and an
    mrms-style raster, cross-checked against each other in tests.
  • CLI mines writes the layer, a per-group tally, a per-km² raster and a map.
    --mines overlays it on map, run, nexrad, zoom, burn, export.
  • 75 offline tests (480 total, no network).

Three findings worth reviewing

Default geometry is both, not points. USMIN records mine waste almost
entirely as polygons — 14,815 against 413 points nationally, 778 against 4 in
Nevada — so a points-only waste query returns nearly nothing and looks exactly
like an AOI with no mining.

A latent paging bug in refdata. ArcGIS reports truncation at the top level
on a MapServer but only under properties on a hosted FeatureServer, so the
old check returned exactly 2,000 of 3,134 USMIN features with no error. The
existing layers are all MapServers and were unaffected — verified by paging
26,037 NHD flowlines correctly — so nothing already published changes. Separately,
an ArcGIS error arrives as HTTP 200 with an {"error": ...} body, which read as
an empty AOI; it now says so on stderr.

drape_i15 accepts i15=None (terrain + overlays, no colour bar). The first
mines figures draped the density raster and drew the features — blocky per-km²
cells under graduated symbols of the same counts, one quantity encoded twice. The
figure now carries the features alone; --density-map drapes the raster on request.

One bug got past the unit tests and was caught only by rendering: _cmd_mines
read args.vmax, which only burn's parser defines, so the command fetched,
wrote three files and then died at the last step. Fixed, plus a test that
AST-walks the command for args.<name> against the parsed namespace.

Note on the second commit

This branch also carries d7d24fd ("Warn that severity_colors bands raw dNBR"),
which was committed to burn-severity after PR #1 was cut and so never reached
main. It is unrelated to this work but would otherwise be stranded on a merged
branch — flagging it rather than dropping it silently.

🤖 Generated with Claude Code

scottwmccoy and others added 2 commits August 15, 2026 15:09
Its BoundaryNorm has its boundaries in dNBR units and does the classing
itself, so handing it class indices is silently wrong rather than an error:
0 falls in the unburned bin and every burned class sits above the top break,
painting the whole scar "high". The result looks like a plausible severity
map, which is the worst failure mode -- hit while drawing a BRISK composite
for the Stallion fire.

Documents the right call and the wrong one side by side, and adds the
reciprocal pointer in classify(), which is where someone reaching for a
classed map lands first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Post-fire debris flows run out of steep burned catchments, and in the Great
Basin those catchments are full of historic mining. Mine dumps and tailings are
loose, often contaminated material sitting on the channel network -- exactly
what a convective cell mobilises. This puts them on the same map as the rain.

There is no public point-level abandoned-mine HAZARD database, by policy: USGS
FS 2025-3003 says the national inventory "will not publish specific location
information of any abandoned mine workings", and Nevada's Division of Minerals
AML layers answer 499 Token Required anonymously. What is public is USMIN's
compilation of mine symbols digitised from published topo sheets, which reveals
nothing the printed maps did not. Sources are a registry, not a hard-coded URL,
so a credentialed NDOM feed drops in without touching call sites.

Read it as a historical map compilation, not a hazard inventory: topo_date runs
1950-1994, with no hazard ranking and no confirmation a feature still exists.

- mines.py: six feature groups over USMIN's 55-type vocabulary (exact map plus
  prefix families, so a later "Tailings - X" still lands in waste), the kind
  filter pushed into the service query and re-applied locally, equal-area
  density as both a vector grid and an mrms-style raster.
- CLI `mines` writes the layer, a per-group tally, a per-km2 raster and a map;
  `--mines` overlays it on map/run/nexrad/zoom/burn/export.
- Default geometry is "both", not points: USMIN records mine waste almost
  entirely as polygons (14,815 vs 413 points nationally, 778 vs 4 in Nevada),
  so a points-only waste query looks like an AOI with no mining.

Two silent failures fixed in refdata along the way. ArcGIS reports truncation
at the top level on a MapServer but only under "properties" on a hosted
FeatureServer, so the old check returned exactly 2,000 of 3,134 USMIN features
with no error; the existing layers are all MapServers and were unaffected
(verified by paging 26,037 NHD flowlines). And an ArcGIS error arrives as HTTP
200 with an {"error": ...} body, which read as an empty AOI -- it now says so.

drape_i15 accepts i15=None (terrain plus overlays, no colour bar). The first
mines figures draped the density raster and drew the features, showing the same
counts twice; the figure now carries the features alone and --density-map
drapes the raster on request.

Tests: tests/test_mines.py, 75 offline cases. One includes an AST walk of
_cmd_mines for args.<name> against the parsed namespace, after a missing --vmax
let the command fetch, write three files and then die at the last step.
@scottwmccoy
scottwmccoy merged commit ac3d22a into main Aug 15, 2026
2 checks passed
@scottwmccoy
scottwmccoy deleted the mines-usmin branch August 15, 2026 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant