Skip to content

Stop a bare-node search box collapsing to a zero-sized extent - #1108

Open
zkWizard wants to merge 2 commits into
mainfrom
codex/geologist-plates-in-boundaries-20260822-2100
Open

Stop a bare-node search box collapsing to a zero-sized extent#1108
zkWizard wants to merge 2 commits into
mainfrom
codex/geologist-plates-in-boundaries-20260822-2100

Conversation

@zkWizard

Copy link
Copy Markdown
Owner

Rung 1 (a defect in wired code). docs/BACKLOG.md Owner's picks is still the
empty placeholder, and no Agent-verified candidate falls in solid Earth — the
study-region and HUD items are filed for the maintainer to call, land-cover
freshness is not due until ~2026-12, and precipitation currency is a
data-sourcing decision.

Visible: search Old Faithful (or Steamboat Geyser) and open
Insights. Before, the volcano and plate sections each read Coordinates inside the search result bounding box, about 0.0 km north–south and 0.0 km east–west at its mid-latitude, and the seismicity section read Epicentres within 0.0 km of the search-extent centre. After, all three read <0.1 km.
No sentence is added, removed, or reworded — only the three numbers change.

The defect

searchExtentSpan.formatSpanKm's doc comment states the guarantee the function
is there to provide, verbatim:

Whole kilometres once an extent is wide enough for a fraction to be noise,
one decimal below that so a monument-sized box does not collapse to "0 km".

One decimal does not deliver that. It moves the collapse threshold from 0.5 km
to 0.05 km rather than removing it, and the geocoder's smallest box is below
the new threshold too.

An OSM object mapped as a bare node carries no extent, so Nominatim returns
a fixed 0.0001-degree square around it. That is 11.1 m north–south, and less
east–west away from the equator — both under the 0.05 km one decimal can
render.

Measured against the live API, not assumed

Six searches through the app's own geocoding endpoint, radius computed with
searchExtentEarthquakeQuery's own formula:

query OSM type bbox radius printed
Old Faithful geyser 0.00683 km 0.0
Steamboat Geyser geyser 0.00682 km 0.0
Kilauea Overlook parking 0.05004 km 0.1
Grand Prismatic Spring water 0.06407 km 0.1
Statue of Liberty attraction 0.06825 km 0.1
Eiffel Tower tower 0.12322 km 0.1

Both geysers return exactly the bare-node box, to within a metre of each
other — this is one fixed geocoder behaviour, not two coincidences. Geological
point features are precisely the class most often mapped as nodes rather than
areas: geysers, vents, fumaroles, craters, springs, and peaks. So this is the
ordinary shape of a landform search in this app's own domain, not an edge case.

For the measured Old Faithful box the span phrase renders 0.0111 km north–south
and 0.0079 km east–west — about 0.0 km north–south and 0.0 km east–west.

Why a printed zero is the wrong claim

Both readouts exist to make the numbers beside them readable, and a zero
defeats each in its own way.

searchExtentSpanPhrase's doc comment already argues the point: without a
stated size the extent counts "carry no scale and are not comparable between
places". A box that prints as having no extent says the count was taken
over nothing — the exact reading the phrase was added to prevent.

The seismicity radius is worse, because it is the qualifier on a negative
result. The panel prints Epicentres within N km of the search-extent centre
and then No M4.5+ events recorded in the feed window. At 0.0 the reader is
shown an empty result qualified by a search with no stated reach, and cannot
tell a 7 m search from no search at all. queryValidationErrors rejects only
radiusKm < 0, so the tiny radius is a fully valid query that really did run
and really could not match.

A rendered 0.0 km is a stronger claim than the number it rounds, in the same
way #1098's rounded 100% and #1105's were. <0.1 reports a box below the
printed precision without asserting it is empty — the same floor guard, and the
same idiom, as snowAveragedSupport.formatDrawnShare's <1%.

An exact zero still prints 0.0

Mirroring #1098's treatment of an exact 1: where the absence of extent is
real — a degenerate box whose edges coincide — the stronger claim is the true
one and it stands. Only a positive value too small to render is redirected.

Scope

Two formatters, one rule, three rendered sections:

formatter feeds
searchExtentSpan.formatSpanKm volcano extent (volcanoExtent), plate extent (plateBoundaryContext)
earthquakeContext.formatRadiusKm seismicity scope line

Both are solid-Earth surfaces; no other specialist's module is touched. Pure
formatting logic, so no bundle delta and nothing new is wired.

Tests

Five added, mutation-checked both ways — forcing the guard off fails only the
two bare-node tests, and forcing it on for every value fails only the
exact-zero and at-threshold tests. Zero collateral.

  • the measured Old Faithful box renders <0.1 on both axes
  • a box whose edges coincide still renders 0.0
  • a span at the 0.05 km threshold still renders 0.1, not <0.1
  • the circumscribed bare-node radius renders Epicentres within <0.1 km
  • an exactly zero radius still renders Epicentres within 0.0 km

Full unit suite green.

🤖 Generated with Claude Code

zkWizard and others added 2 commits August 22, 2026 14:18
`formatSpanKm`'s doc comment promises "one decimal below that so a
monument-sized box does not collapse to '0 km'", but one decimal only
moves the collapse threshold to 50 m. Nominatim returns a fixed
0.0001-degree square for an OSM object mapped as a bare node, which is
11 m north-south — under that threshold.

Measured on the live API, "Old Faithful" and "Steamboat Geyser" both
return exactly that box, so the volcano and plate sections rendered
"about 0.0 km north-south and 0.0 km east-west" and the seismicity
section "Epicentres within 0.0 km of the search-extent centre".

Both readouts exist to give the numbers beside them a scale, and the
seismicity radius is the qualifier on a negative result — at 0.0 a
reader cannot tell a 7 m search from no search. Guard the floor so a
positive value below the printed precision reads "<0.1", mirroring
`snowAveragedSupport.formatDrawnShare`'s "<1%". An exact zero still
prints 0.0, where the absence of extent is real.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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