Tjømes GolfAPI-koordinater erstattet med feltbefarte data (migrasjon 078)

Bruker lastet opp mer presise, feltbefarte koordinater for Tjøme
Golfklubb (180 punkter) til erstatning for GolfAPI.io sin automatiske
cache (167 punkter). Ny poi_type "landmark" (samme mønster som
rock/layup i migrasjon 067) for en fysisk bjelle uten annen match.
Kun tredjeparts-cache i teecup_db berørt, ingen kodeendring.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

078_golfapi_coordinate_landmark_poi_type.sql

@@ -0,0 +1,30 @@
+-- =====================================================================
+--  TeeCup — migrasjon 078
+--  Ny POI-type "landmark" for manuelt registrerte banepunkter
+-- =====================================================================
+--  Konkret anledning: Tjøme Golfklubb sin GolfAPI-cache erstattet med
+--  et nytt, mer detaljert sett feltbefarte koordinater (180 punkter,
+--  CSV lastet opp av bruker 2026-08-17). Ett punkt ("Bjella", hull 5+14)
+--  er en fysisk bjelle spillerne ringer i for å signalisere til gruppen
+--  bak at de kan slå -- ingen av dagens 14 poi_type-verdier (fra
+--  migrasjon 001/067) dekker et rent informasjons-/signal-landemerke
+--  uten hindrings- eller siktepunkt-betydning.
+--
+--  `landmark` er, som `layup`, rent informativt -- IKKE en hindring i
+--  avstandsvisningen (se _HAZARD_LABELS i
+--  frontend/components/hole-target-distance.tsx, som i dag kun
+--  filtrerer på green_bunker/fairway_bunker/water/rock -- landmark
+--  vises ikke der uten fremtidig frontend-arbeid, samme status som
+--  trees/marker_*/dogleg/road/tee_front/tee_back/layup i dag).
+-- =====================================================================
+
+\set ON_ERROR_STOP on
+
+ALTER TABLE golfapi_course_coordinate DROP CONSTRAINT golfapi_course_coordinate_poi_type_check;
+ALTER TABLE golfapi_course_coordinate ADD CONSTRAINT golfapi_course_coordinate_poi_type_check
+    CHECK (poi_type IN (
+        'green', 'green_bunker', 'fairway_bunker', 'water',
+        'trees', 'marker_100', 'marker_150', 'marker_200',
+        'dogleg', 'road', 'tee_front', 'tee_back',
+        'rock', 'layup', 'landmark'
+    ));

CHANGELOG.md

@@ -11813,3 +11813,60 @@ Neste steg:
     deretter `docker compose build teecup_api teecup_frontend && up -d`.
     Rene containerlogger, `https://teecup.golf/logg-inn` bekreftet 200 OK
     etterpå.
+
+97. **Tjømes GolfAPI-koordinater erstattet med feltbefarte data (migrasjon
+    078) — 2026-08-17.** Bruker lastet opp en CSV (`Temp-uploads/Regneark
+    uten navn - Ark 2.csv`, 180 punkter) med koordinater samlet inn på
+    selve banen -- mer presise og mer detaljerte enn GolfAPI.io sin
+    automatiske cache (167 punkter, hentet 2026-08-12, se punkt 79/
+    ADR-064). Berører KUN `teecup_db` sin egen tredjeparts-cache
+    (`golfapi_course_coordinate`, course_id `0121250146602173`) -- ingen
+    kode endret, ingen container-restart nødvendig.
+
+    Egen research (Explore-agent) bekreftet FØRST hvor "eksisterende"
+    koordinater faktisk bor (IKKE teeoff -- Tjøme finnes ikke der, jf.
+    ADR-064) og at skjemaet allerede støtter den detaljerte per-hazard-
+    strukturen CSV-en beskriver. Flere reelle tolkningsspørsmål avklart
+    med bruker (AskUserQuestion) FØR noe ble skrevet:
+    - Ett "Tee"-punkt per hull (ikke to) → lagret som `tee_front` alene.
+    - Hull 4/13 hadde tre kandidat-par for "Forkant/bakkant høyre
+      fairwaybunker" (to i lat/long, ett i UTM/EPSG:25833) -- egen manuell
+      UTM→WGS84-konvertering (ingen `pyproj` tilgjengelig, implementert
+      fra Snyder-formlene) viste ~35 m avstand til nærmeste av de to
+      andre, for langt til å være GPS-støy. Bruker bekreftet: tre reelle,
+      atskilte bunkere, alle beholdt.
+    - "Voll" (steingjerde med gress over, tverrs over fairwayen, hull
+      3+12) → `rock` (samme kategori som fjellknaus).
+    - "Over vei"/"Over tre" (hull 7/8/16/17/18 og 17/18) → bruker
+      bekreftet "carry road"/"carry tree" -- mappet til eksisterende
+      `road`/`trees`, samme `back`/`center`-konvensjon som GolfAPIs egne
+      eksisterende road-punkter på hull 7/8/16/17.
+    - "Bjella" (hull 5+14, en fysisk bjelle spillerne ringer i for å
+      signalisere til gruppen bak) passet ikke noen av de 14 eksisterende
+      `poi_type`-verdiene -- ny verdi `landmark` lagt til (migrasjon 078,
+      samme mønster som `rock`/`layup` i migrasjon 067), rent informativt,
+      ikke en hindring (se `_HAZARD_LABELS` i `hole-target-distance.tsx`
+      -- viser i dag uansett kun green_bunker/fairway_bunker/water/rock,
+      `landmark` er dermed ikke synlig i appen ennå, samme status som
+      trees/marker_*/dogleg/road/tee_front/tee_back/layup allerede har).
+    - "Fairway" (rene referansepunkter uten hindringsbetydning, 6 stk) →
+      `layup` (samme bruk som Nesbyen-importen i punkt 79).
+
+    **Verifisert:** transformasjons-mappingen (Python, ren funksjon --
+    ikke committet, engangsskript samme mønster som Nesbyen-importen i
+    punkt 79) ga 180/180 rader mappet (ingen uidentifiserte navn), talt
+    opp per `poi_type` og kryssjekket for hånd mot CSV-ens egne
+    navnetellinger. `./scripts/run_backend_tests.sh` (95/95, migrasjon
+    078 bekreftet anvendbar). Selve slett+sett-inn-operasjonen KJØRT FØRST
+    mot en egen scratch-database (egen `golfapi_course`-rad seedet,
+    samme engangsskript kjørt der via `teecup_api`-containerens asyncpg),
+    verifisert der (180 rader, riktig `landmark`/UTM-konverterte
+    koordinater, `num_coordinates` oppdatert) FØR noe rørte ekte
+    `teecup_db`. Scratch-databasen droppet etterpå.
+
+    **Rullet ut 2026-08-17.** Migrasjon 078 kjørt mot ekte `teecup_db`.
+    Deretter kjørt mot ekte data: 167 gamle rader slettet, 180 nye satt
+    inn, `golfapi_course.num_coordinates` oppdatert til 180. Bekreftet
+    direkte mot databasen etterpå: riktig `poi_type`-fordeling, `landmark`-
+    punktene og de tre hull-4-bunkerne til stede med korrekte
+    koordinater. Ingen kodeendring -- ingen container-restart nødvendig.