Every district on the live hydradistrict is missing latitude and longitude, so the geo-proximity feature added in commit 80436f9 does not work at all.
curl -s https://hydradistrict.experiencenet.com/api/v1/nearest?lat=51.21&lon=3.22
{"error":"no districts with coordinates found","code":404}
curl -s https://hydradistrict.experiencenet.com/api/v1/districts/bxl1 | jq '{latitude,longitude}'
{"latitude":null,"longitude":null}
All 6 districts are affected: eu-nbg1, bxl1, bxl1-test, bxl1-test-2, bxl1-test-3, local-dev.
The Latitude and Longitude fields were added to store.District after the districts were created (eu-nbg1 and bxl1 date from 2026-02-18). Existing records were never backfilled, and handleNearest skips any district where both are zero, so it always finds nothing.
This is a data gap, not a code bug. handleNearest and the haversine are correct.
Found while building hydratam (#620), which reads hydradistrict to measure how far each target city sits from the nearest place we can run an experience from. That is the coverage argument for the whole go-to-market map, and it returns nothing today. hydratam now reports the cause explicitly rather than showing silent nulls:
"warning": "none of the 6 districts in hydradistrict carry coordinates, so no distance can be measured; set latitude and longitude on them with PUT /api/v1/districts/{id}"
Backfill the two real districts. PUT is a full replace, so send the existing name, location, provider and services along with the coordinates, or they will be cleared.
The three bxl1-test districts and local-dev can take the same coordinates as their parent or be left alone; they should not be selected for a real coverage answer anyway.
Not done here because it is a write to production infrastructure outside the scope of the hydratam work.
Require coordinates on create. A district without them cannot answer the one question the nearest endpoint exists for, so accepting it silently is what let this sit unnoticed since February.