Geonorge: lokalId regenereres på hver eksport — bytt til romnr som ekstern nøkkel #15

New issue

Open

opened 2026-04-27 16:09:02 +02:00 by olemd · 0 comments

olemd commented

2026-04-27 16:09:02 +02:00

Owner

Bakgrunn

Tilfluktsromdata fra Geonorge (nedlasting.geonorge.no/.../TilfluktsromOffentlige/GeoJSON/...zip) inneholder et felt lokalId som ser ut som en stabil UUID-nøkkel per tilfluktsrom, og som DSB sannsynligvis intenderer skal være stabil. I praksis observerer vi at lokalId regenereres ved hver eksport.

Empirisk bevis

Sammenligning av tre øyeblikksbilder av samme datasett:

Snapshot	romnr=776 (Borre Idrettspark) lokalId
Commit `d0460cd` (~desember 2025)	`87853d43-4dda-4964-96e5-96dffc1cf7f3`
PWA-bundle hentet 2026-04-20	`d4e4fa73-ad97-4ac8-8968-5a83bc420d94`
Direkte fra Geonorge 2026-04-27	`58e696d9-dafd-4b58-baff-5af27e3c08a8`

Resultat på tvers av alle 556 tilfluktsrom:

felt	antall som varierer mellom de tre øyeblikksbildene
`romnr`	0
`plasser`	0
`adresse`	0
`latitude`	0
`longitude`	0
`lokalId`	556 (alle)

Ingen tilfluktsrom er lagt til eller fjernet i perioden. Bare lokalId driver. De to siste snapshottene er kun sju dager fra hverandre, så dette er regelmessig drift, ikke en engangshendelse.

Konsekvens

lokalId er ubrukelig som identifikator for noe som krysser enheter eller bygg:

Delingslenker (https://tilfluktsrom.naiv.no/shelter/{lokalId}) feilet med "Tilfluktsrom ikke funnet" når avsender og mottaker hadde hentet datasettet på forskjellige dager.
En Oppdater data-knapp midt i en valgt-tilfluktsrom-flyt mister markeringen fordi alle UUID-er endrer seg.

Hva vi gjorde

Bytta delingslenkene til å bruke romnr (DSB sin faktiske rom-nummer-nøkkel) i stedet for lokalId:

Verifisert unik på tvers av alle 556 tilfluktsrom
Stabil på tvers av alle tre snapshottene
Kortere URL: https://tilfluktsrom.naiv.no/shelter/776

lokalId beholdes som intern Room-primærnøkkel siden den er stabil innen én datahenting og en migrasjon hadde vært unødvendig destruktiv. Bare den eksterne identifikatoren ble byttet.

Se ARCHITECTURE.md → Deep link identifier — why romnr, not lokalId for full begrunnelse.

Oppfølging

Spørre Geonorge / DSB hvorfor lokalId regenereres ved hver eksport — er dette tilsiktet (gml:id-stil syntetisk eksport-ID) eller en feil i FME/SOSI-pipelinen?
Hvis det er en feil: be om at lokalId blir persistert mellom eksporter slik at feltet faktisk er en stabil primærnøkkel.
Hvis det er tilsiktet: be om at det dokumenteres tydelig at lokalId er per-eksport og at romnr er den persistente nøkkelen — slik at andre konsumenter ikke faller i samme felle.
Sjekke om WFS-endepunktet (wfs.geonorge.no/skwms1/wfs.tilfluktsromoffentlige) returnerer stabile identifikatorer; det kunne i så fall være et bedre valg for kilden.

Kontaktpunkt

Geonorge har en kontaktside og oppgaver i Jira; DSB er datasettets eier.

## Bakgrunn Tilfluktsromdata fra Geonorge (`nedlasting.geonorge.no/.../TilfluktsromOffentlige/GeoJSON/...zip`) inneholder et felt `lokalId` som ser ut som en stabil UUID-nøkkel per tilfluktsrom, og som DSB sannsynligvis intenderer skal være stabil. I praksis observerer vi at `lokalId` regenereres ved hver eksport. ## Empirisk bevis Sammenligning av tre øyeblikksbilder av samme datasett: | Snapshot | romnr=776 (Borre Idrettspark) lokalId | |---|---| | Commit `d0460cd` (~desember 2025) | `87853d43-4dda-4964-96e5-96dffc1cf7f3` | | PWA-bundle hentet 2026-04-20 | `d4e4fa73-ad97-4ac8-8968-5a83bc420d94` | | Direkte fra Geonorge 2026-04-27 | `58e696d9-dafd-4b58-baff-5af27e3c08a8` | Resultat på tvers av alle 556 tilfluktsrom: | felt | antall som varierer mellom de tre øyeblikksbildene | |---|---| | `romnr` | 0 | | `plasser` | 0 | | `adresse` | 0 | | `latitude` | 0 | | `longitude` | 0 | | `lokalId` | **556 (alle)** | Ingen tilfluktsrom er lagt til eller fjernet i perioden. Bare `lokalId` driver. De to siste snapshottene er kun sju dager fra hverandre, så dette er regelmessig drift, ikke en engangshendelse. ## Konsekvens `lokalId` er ubrukelig som identifikator for noe som krysser enheter eller bygg: - Delingslenker (`https://tilfluktsrom.naiv.no/shelter/{lokalId}`) feilet med "Tilfluktsrom ikke funnet" når avsender og mottaker hadde hentet datasettet på forskjellige dager. - En `Oppdater data`-knapp midt i en valgt-tilfluktsrom-flyt mister markeringen fordi alle UUID-er endrer seg. ## Hva vi gjorde Bytta delingslenkene til å bruke `romnr` (DSB sin faktiske rom-nummer-nøkkel) i stedet for `lokalId`: - Verifisert unik på tvers av alle 556 tilfluktsrom - Stabil på tvers av alle tre snapshottene - Kortere URL: `https://tilfluktsrom.naiv.no/shelter/776` `lokalId` beholdes som intern Room-primærnøkkel siden den er stabil innen én datahenting og en migrasjon hadde vært unødvendig destruktiv. Bare den eksterne identifikatoren ble byttet. Se [ARCHITECTURE.md → Deep link identifier — why `romnr`, not `lokalId`](https://kode.naiv.no/olemd/tilfluktsrom/src/branch/main/ARCHITECTURE.md#deep-link-identifier--why-romnr-not-lokalid) for full begrunnelse. ## Oppfølging - [ ] Spørre Geonorge / DSB hvorfor `lokalId` regenereres ved hver eksport — er dette tilsiktet (gml:id-stil syntetisk eksport-ID) eller en feil i FME/SOSI-pipelinen? - [ ] Hvis det er en feil: be om at `lokalId` blir persistert mellom eksporter slik at feltet faktisk er en stabil primærnøkkel. - [ ] Hvis det er tilsiktet: be om at det dokumenteres tydelig at `lokalId` er per-eksport og at `romnr` er den persistente nøkkelen — slik at andre konsumenter ikke faller i samme felle. - [ ] Sjekke om WFS-endepunktet (`wfs.geonorge.no/skwms1/wfs.tilfluktsromoffentlige`) returnerer stabile identifikatorer; det kunne i så fall være et bedre valg for kilden. ## Kontaktpunkt Geonorge har en kontaktside og oppgaver i Jira; DSB er datasettets eier.