web: NYC-area DZDs render in the water on the multicast map

[armcconnell]

Summary

In the multicast section, several NYC-area DZDs are plotted in the water rather than on land, indicating incorrect geolocation/placement on the map.

Impact

Misplaced markers make the map look broken and make it hard to trust location data when choosing a DZD to connect to.

Steps to reproduce

1. Go to the multicast section on data.malbeclabs.com.
2. View the map with NYC-area DZDs.
3. Observe markers positioned over water.

Expected

DZD markers should be placed at their correct geographic locations on land.

Notes

• Reported during a screen-share recording attempt; not urgent, no action needed until after the offsite.
• May relate to the geolocation explorer work (Geolocation explorer for DZDP #547, geoloc explorer for DZDP issue B: geolocation explorer view #550).
• The reporter is happy to point out the specific DZDs that were misplaced.

[armcconnell]

Triage findings (confirmed against production data)

The original "swapped lat/long in the metro table" hypothesis is wrong — metro and facility coordinates are all correct:

• NYC metro = 40.779, -74.072 (on land).
• NYC facilities EQX-NY5 (40.779, -74.072), EQX-NY2, EQX-NY7, CYX-EWR2, 165H-MMR are all on land.

Root cause: device markers on the map do not use real device or facility coordinates at all. calculateDevicePosition (web/src/components/topology-map.tsx:255-274) scatters a metro's devices on a circle of radius = 0.3 degrees (~20-26 miles) around the metro centroid:

const radius = 0.3 // degrees offset
const angle = (2 * Math.PI * deviceIndex) / totalDevices
const latOffset = radius * Math.cos(angle)
const lngOffset = radius * Math.sin(angle) / Math.cos(metroLat * Math.PI / 180)
return [metroLng + lngOffset, metroLat + latOffset]

devicePositions is built purely from metro.latitude/longitude (topology-map.tsx:928-947); the topology API never sends per-device facility coordinates. NYC is coastal, so the eastward/southward arc of that 0.3° circle lands markers in the Atlantic and the harbor. NYC is the most visible case, but any coastal metro with several devices has the same problem.

Proposed fix

Use real facility coordinates when available, fall back to a smaller, smarter scatter otherwise:

1. API: in the topology handler (api/handlers/topology.go), join devices to dz_facilities_current via location_pk and return latitude/longitude per device when the facility has coordinates.
2. Web: in topology-map.tsx, build devicePositions from the device's facility coordinates when present; only fall back to calculateDevicePosition for devices with no facility coords.
3. Fallback hardening: reduce the fan-out radius (e.g. 0.3 → ~0.05) so synthetic positions stay near the metro rather than offshore. Devices in the same facility should also de-duplicate to a small jitter rather than a wide ring.

Step 1+2 is the real fix; step 3 limits the blast radius for devices that still lack facility coords.

Verification

• Coordinate sanity check (facilities are on land today):

  SELECT code, name, lat, lng FROM dz_facilities_current
  WHERE lat BETWEEN 39 AND 42 AND lng BETWEEN -75 AND -73;

• Unit test for calculateDevicePosition / the new facility-coords path: assert NYC-metro devices resolve to their facility coordinates (on land) and that the synthetic fallback stays within the reduced radius of the metro centroid.
• Visual: load the topology map zoomed to NYC and confirm no device markers sit in the water (before/after screenshot).