Mobile: create/select a Wavelog station location per unique GPS location for logging

[Reid-n0rc]

Summary

Add an option for FT8AF to automatically create and select a Wavelog/Cloudlog/Nextlog station location per unique set of location information when operating mobile (GPS location updating enabled), so that each logged QSO is attributed to a station location whose data actually matches where the operator physically is at the moment of the contact.

This closes the gap where a moving/mobile station logs every QSO under a single fixed station location, causing Wavelog to record the wrong grid, DXCC, zones, etc. for QSOs made from other locations.

Background / why this is needed

FT8AF already tracks the operator's current location from GPS (GridLocationUpdater → GeneralVariables.setMyMaidenheadGrid) and already sends <my_gridsquare> in the ADIF uploaded to Wavelog (ThirdPartyService.QSLRecordToADIF, uploaded via /api/qso with a fixed station_profile_id).

The problem is entirely server-side and cannot be fixed from the ADIF payload. Wavelog (and upstream Cloudlog/Nextlog) discards the ADIF MY_GRIDSQUARE on import and substitutes the grid from the station_profile_id the QSO is uploaded against. The /api/qso endpoint has no parameter to override this. So when mobile, every QSO gets stamped with the fixed station location's grid/DXCC/zones regardless of the GPS-derived location we send.

Proposed feature

Add a "mobile / per-location logbook" option (off by default). When enabled:

1. Before logging each QSO, look at the current location information and compute a "location signature" from a user-selectable set of fields:

   • Gridsquare
   • State
   • DXCC
   • County
   • City
   • CQ Zone
   • ITU Zone

   (These are all derivable from / configured on the GPS location.) The user picks which of these fields participate in the signature so they can control location granularity (e.g. grid-only vs. grid+county for POTA-style precision).

2. POTA: when a POTA operation is active, the POTA reference must be part of the uniqueness key for the location, so a QSO run at a park gets its own station location tied to that park reference rather than being merged with a nearby non-POTA location.

3. Look up or create the matching station location in Wavelog:

   • If a station location with that exact signature already exists, select and reuse it — do not create a new one.
   • If not, create it via POST /api/create_station/[key] (station_gridsquare, station_callsign, station_city, station_dxcc, link_active_logbook, etc. — Wavelog ≥2.1.2; link_active_logbook ≥2.3.1).
   • Capture the resulting station_profile_id and upload the QSO against that id (instead of the single fixed getCloudlogStationID() used today).

Location reuse — never duplicate a location on revisit (required)

A new station location must be created only the first time a given location signature is seen. Every subsequent QSO whose signature matches an already-known location must reuse that existing location's station_profile_id — it must not create another one.

Concretely: if you drive back and forth between Town A and Town B, FT8AF should end up with exactly one station location for Town A and one for Town B, no matter how many times you cross between them. Re-entering Town A after being in Town B selects the previously-created Town A location and logs against it.

Implementation implications:

• FT8AF should maintain a local cache mapping each seen location signature → its station_profile_id, persisted across sessions, so revisits resolve to the existing id without needing a server round-trip.
• On a cache miss, resolve against the server (list existing station locations / rely on create_station's de-dup on matching references/call) before creating, so a location created in a previous run/app-reinstall is also reused rather than duplicated.
• The signature (see step 1, plus the POTA reference in step 2) is the sole key for reuse — two physical spots that produce the same selected-field signature are intentionally treated as the same location and share one logbook.

4. Defaults for newly-created locations: when FT8AF creates a new station location, it must apply a set of user-defined default third-party/QSL settings so all auto-created locations behave consistently. These settings are configured once in FT8AF and applied to every new location:

   • eQSL
   • QRZ
   • Clublog
   • HRDLog
   • OQRS

   (i.e. FT8AF holds the "template" values for these, and stamps them onto each new station location it creates.)

Why not fix this upstream in Wavelog instead?

We deliberately are not pursuing a change to the Wavelog repository to let /api/qso accept location fields and overwrite the station location's values. Reasoning:

• The Wavelog maintainers have already rejected this. In Cloudlog discussion #1228 the maintainer stated explicitly that MY_GRIDSQUARE comes from Station Locations and "this will not be changed" — they may add validation but will not alter the core precedence behavior. Building FT8AF's mobile support on a rejected upstream change would create a fork/maintenance dependency we don't control.
• Grid is not a standalone field in Wavelog's data model — it's the key to a cluster of derived data. A Station Location carries DXCC, CQ/ITU zone, state/county, lat-lon, and is the unit Wavelog groups statistics, awards, and the map by. Letting a single QSO override just the grid while still pointing at another station location would produce internally inconsistent records (grid says one place; DXCC/zones/awards/stats say another). That's arguably worse than today's wrong-but-consistent behavior, and it's exactly why the maintainer guards it.
• The station-location approach is the model Wavelog is actually built for. Creating a real station location per operating location makes all derived fields correct and makes "operated from N locations on this trip" a real, queryable, awards-correct thing. It also matches the existing community pattern (e.g. the waverover rover import helper).

So the correct place to solve this is inside FT8AF, working with the Wavelog data model, with no upstream dependency.

Open questions / implementation notes

• Confirm create_station returns the new station_profile_id (or list stations and match by signature) so uploads can be routed to it — today FT8AF uses a single fixed getCloudlogStationID().
• Where the "ensure location → get id → upload" hook slots into ThirdPartyService / the upload path.
• Minimum server version handling (Wavelog ≥2.1.2 / ≥2.3.1); Cloudlog/Nextlog may differ since the uploader targets all three — feature may need to be Wavelog-gated.
• UI for: enabling the feature, choosing which fields form the location signature, and configuring the eQSL/QRZ/Clublog/HRDLog/OQRS defaults template.

References

• Cloudlog Discussion #1228 — ADIF import ignores MY_GRIDSQUARE
• Wavelog API docs (/api/qso, /api/create_station)
• Wavelog Station-Locations deep dive
• waverover — rover import helper