[Bug 898] UDP (local) spots can show an incorrect location of the spotter

[alanhargreaves]

What does this PR do?

When using Local UDP for a DX Cluster source, some programs do not list a lat/lon or grid square. When this happens, s.spotterGrid is set to null and the hooks code tries to find the location based purely on the callsign prefix, which can be preoblematical.

This fix uses CONFIG.gridSquare instead of just defaulting to null if no gridSquare is offered.

We should also not offer "UDP Spots(local)" as an option for DX Cluster Source unless isLocalInstall is true. Otherwise we could have random people setting up UDP listeners on servers like OHC.

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

1. If using Local UDP for DX Cluster, curl localhost:3000/api/dxcluster/paths
2. Verify that the spotterGrid is set to the local grid square

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

[accius]

Review — UDP spotter location fallback (draft)

Minimal, targeted fix. The one-line change is sensible for the local-UDP case: the "spotter" in a local UDP feed is effectively the operator themselves, so falling back to the server's CONFIG.gridSquare (which in self-hosting mode = the operator's grid) is reasonable when the upstream program doesn't supply one.

Concerns / questions

1. CONFIG.gridSquare semantics in a multi-tenant deployment. On the public server at openhamclock.com, CONFIG.gridSquare is the server operator's grid, not the individual user's — if this code path is ever reached in the hosted deployment, we'd be tagging every UDP spot with the server's location. Can you confirm this udpSession code path is only hit in self-hosted mode? If there's any chance it runs for hosted users, please guard with an isLocal / isSelfHosted check or pass the user's own grid in via the session.

2. CONFIG in scope: please double-check that CONFIG is imported/available at the top of this route, and that CONFIG.gridSquare is the field name (vs CONFIG.locator — the frontend config uses locator). A grep for other CONFIG.gridSquare references in server/ would be reassuring.

3. Nit: consider falling back to CONFIG.locator if CONFIG.gridSquare isn't set — same source, different name on the frontend config, and either could be the canonical field depending on how the server reads the user's config.

4. PR description typos ("teh", "preoblematical", "gris") — tidy up before marking ready.

Happy to re-review when out of draft.

[alanhargreaves]

Hmmm, I was under the apparently mistaken impression that this could only run for a local session.

OK, a better approach might be to where we have the setting selection for this to have it also request a default grid square where it defaults to the users DE, and pass that when we configure the session.

I can see this will need a bit more work and thought.

Thank you for picking up on that.

[alanhargreaves]

as to locator, it looks like we set it in config.js, but read it in to gridSquare

alan@Alans-MacBook-Pro openhamclock % find server -type f -exec grep -i config.locator {} +
server/config.js:  gridSquare: locator || jsonConfig.locator || '',
alan@Alans-MacBook-Pro openhamclock %

If I just look for locator I get

alan@Alans-MacBook-Pro openhamclock % find server -type f -exec grep  locator {} +
server/config.js:  console.log('[Config] ⚠️  Please edit .env with your callsign and locator, then restart');
server/config.js:// Convert Maidenhead grid locator to lat/lon (used only during config init)
server/config.js:// Get locator from env (support both LOCATOR and GRID_SQUARE)
server/config.js:const locator = process.env.LOCATOR || process.env.GRID_SQUARE || '';
server/config.js:// Calculate lat/lon from locator if not explicitly set
server/config.js:if ((!Number.isFinite(stationLat) || !Number.isFinite(stationLon)) && locator) {
server/config.js:  const coords = gridToLatLon(locator);
server/config.js:  gridSquare: locator || jsonConfig.locator || '',
server/routes/callsign.js:  // Convert Maidenhead grid locator to lat/lon (center of grid square)
server/routes/callsign.js:  // Try to extract grid locators from a comment string
server/routes/config-routes.js:      locator: CONFIG.gridSquare,
server/routes/pskreporter.js:  // Topic format: pskr/filter/v2/{band}/{mode}/{sendercall}/{receivercall}/{senderlocator}/{receiverlocator}/{sendercountry}/{receivercountry}
server/routes/pskreporter.js:      // Validate grid: 4 or 6 character Maidenhead locator
server/routes/rbn.js:        const url = `https://retrieve.pskreporter.info/query?mode=WSPR&flowStartSeconds=${flowStartSeconds}&rronly=1&nolocator=0&appcontact=openhamclock&rptlimit=2000`;
server/utils/grid.js: * Grid locator (Maidenhead) and frequency/band utilities.
server/utils/grid.js: * Convert Maidenhead grid locator to lat/lon.
server/utils/grid.js: * @param {string} grid - Grid locator (e.g., 'DM79' or 'DM79lv')
server/utils/grid.js: * Convert lat/lon to Maidenhead grid locator (6-character).

[alanhargreaves]

I think that with making it so you can't set the dxcluster type to 'udp' unless isLocalInstall is true, that I've addressed your concerns.

[alanhargreaves]

It just occurred to me, ...

In the settings, should I check to see if it's not a local install and the "udp" option is selected, and change it to the recommended?