Import av hjertestarterdata fra Hjertestarterregisteret til OpenStreetMap

Communities Norge (Norway)
1

Heio!

Jeg ønsker å høre hva fellesskapet mener om en import og fast synkronisering av hjertestartere fra det norske Hjertestarterregisteret til OpenStreetMap.

Litt av tanken bak det er at Hjertestartere kan redde liv, men det hjelper lite hvis vi ikke har oppdatert og riktig informasjon.
Det er også per i dag er det et stort gap mellom antall registrerte hjertestartere i Hjertestarterregisteret som myndighetene drifter og det som finnes i OSM:

Kilde Antall
OpenStreetMap 295
Hjertestarterregisteret 11 322

Så her har vi mulighet til over 11 000 nye hjertestartere som vi kan få inn i OSM-data :grin:

Hjertestarterregisteret har gitt OSM tillatelse til å bruke dataene deres under lisen som OSM bruker (Open Database License (ODbL) 1.0).
Siden de har gitt meg API-tilgang har jeg raskt utviklet et synkroniseringsverktøy som:

  • Importerer nye hjertestartere fra registeret som ikke finnes i OSM

  • Oppdaterer eksisterende noder hvis dataene har endret seg (f.eks. åpningstider, lokasjon, etc.)

  • Fjerner noder for hjertestartere som ikke lenger finnes i registeret

Verktøyet har noen sjekker som:

  1. Unngår duplikater: Før en ny node opprettes, sjekkes det om det finnes en eksisterende AED-node innen 20 meter. I så fall hoppes opprettelsen over og logges som en advarsel.

  2. Bevarer eksisterende data: Ved sletting bekreftes det at noden kun inneholder AED-relaterte tags. Hvis noden har andre tags (f.eks. butikk, bygg), slettes den ikke.

  3. Sporer importerte noder: Alle importerte noder tagges med ref:hjertestarterregister= for å tydelig identifisere hvilke noder som er administrert av synkroniseringsverktøyet.

  4. Oppdaterer kun ved endringer: Noder oppdateres bare hvis det faktisk er endringer i dataene (lokasjon > 10m forskjell, eller endrede tags).

  5. Håndterer duplikate refs: Hvis flere OSM-noder har samme ref:hjertestarterregister-verdi, rapporteres dette som et problem.

  6. Batcher: Alle endringerinnen 20 kilometer kommer som en changeset. Dette er for å unngå store changesets som dekker hele landet.

Verktøyet mapper data fra registeret til standard OSM-tags:

  • emergency=defibrillator

  • emergency:phone=113

  • name=* (navn på lokasjon)

  • opening_hours=* (basert på registrerte åpningstider fra eier)

  • defibrillator:location=* (beskrivelse av plassering)

  • level=* (etasje)

  • ref:hjertestarterregister=*

Tenker planen er å kjøre synkroniseringsjobben daglig for å holde dataene oppdatert. Men en liten nettside for å følge med på import-status og eventuelle problemer på https://hjertestarterregister2osm.johand.dev/

Koden vil bli publisert på GitHub etter at det er oppnådd konsensus i fellesskapet, men jeg trenger bare å rydde opp litt først :face_with_peeking_eye:
Her er en .geojson eller en osc med hva som den har greit å mappe hvis dere ønsker å ta en titt på output

Så spørsmålet mitt til felleskapet er om det er det støtte for denne importen? Er det noen andre bekymringer eller forslag?

Er første gang jeg ser på automatiserte redigeringer, så jeg setter stor pris på all tilbakemelding! Har jeg skjønt det riktig så skal det vel også lages noen wiki inlegg om importeringen etc?

1 Like
2

Fint tiltak og bra strukturert. Noen innspill:

  • Importplanen må dokumenteres i en egen wiki-side, ref import guidelines. Et eksempel her.
  • Tillatelsen fra dataeier må lagres og vises slik at den er permanent tilgjengelig for OSM, f.eks. her i community-tråden.
  • Koden for oppdateringsskriptet bør vises.
  • Flere her bør se på geojson-filen som du har lenket til for å sjekke datakvaliteten. Jeg syntes det så ok ut der jeg er kjent. Ikke alle lokasjonene stemte innenfor bygget, med de få jeg kjente til var akseptable. Andre brukere vil nok flytte litt på nodene.
  • Jeg vil anbefale at skriptet har som regel at hjertestarterne skal ha egne noder, dvs. ikke la samme node angi office, shop osv. Grunnen er at andre bruker vil flytte slike noder til andre steder i bygningen.
  • Det er lagt opp til en del manuell behandling (advarsler ved duplikat etc). Jeg tviler på at man i mange år fremover vil klare å håndtere slike manuell behandling, så kanskje bedre å bare velge noen regler.
  • Det blir ofte diskutert her hva som skal skje dersom det finnes en eksisterende node (her hjertestarter) i nærheten. Skal den slettes eller beholdes? Hva skal nøyaktig regel være? F.eks. erstatte dersom nærmere enn 20 meter.
  • Og tilsvarende, om en OSM-bruker har flyttet en node til en riktigere plassering, hvordan skal skriptet håndtere dette (det er da et avvik fra datakilden)? F.eks. akseptere flyttinger inntil maks. 50 meter.
  • Import guidelines krever at en bruker skal kunne unngå automatiserte endringer dersom ønsket. Dette løses ofte ved at brukerne kan legge til en bestemt note tag.
  • Flere andre slike oppdateringer for Norge har endringssett som dekker hele landet eller et helt fylke om gangen. Jeg synes ikke det er et problem så lenge det fremgår av endringssettet at oppdateringen gjelder Norge. Dersom det oppstår systematiske feil kan det være en fordel å ha noen få store endringssett, med tanke på tilbakerulling.
2 Likes
3

Takk for et veldig utfyllende og konstruktivt svar!

Importplanen må dokumenteres i en egen wiki-side, ref import guidelines. Et eksempel her.
Koden for oppdateringsskriptet bør vises.

Det skal jeg få på plass :grin: Det er en litt travel helg, men målet er å få både wiki-side og kode publisert så snart som mulig.

Flere her bør se på geojson-filen som du har lenket til for å sjekke datakvaliteten. Jeg syntes det så ok ut der jeg er kjent. Ikke alle lokasjonene stemte innenfor bygget, med de få jeg kjente til var akseptable. Andre brukere vil nok flytte litt på nodene.

Det finnes 3-4 ekstreme tilfeller der noder lå på Nordpolen, eller der lat/lon var byttet om og havnet ute i Stillehavet. Disse er filtrert bort ved kun å inkludere punkter innenfor Norges grenser.

Jeg kontaktet Hjertestarterregisteret om disse feilene. De rettet de på dagen, men to gjenstår. Det gjelder Rotaid-skap der selve skapet rapporterer posisjonen automatisk hver natt, og eier måtte da selv korrigere dette i sitt dashboard. (Eier er kontaktet av Hjertestarterregisteret)

Jeg vil anbefale at skriptet har som regel at hjertestarterne skal ha egne noder, dvs. ikke la samme node angi office, shop osv. Grunnen er at andre bruker vil flytte slike noder til andre steder i bygningen.

Det er jeg i utgangspunktet enig i. Tenker du en tilnærming tilsvarende addr2osm, der man fjerner emergency=defibrillator fra eksisterende node og oppretter en egen AED-node?

Det er lagt opp til en del manuell behandling (advarsler ved duplikat etc). Jeg tviler på at man i mange år fremover vil klare å håndtere slike manuell behandling, så kanskje bedre å bare velge noen regler.

Enig. Her burde jeg ha forklart tydeligere hvordan jeg ser for meg første import og videre drift.

osm_node_missing_ref
Tanken her var å manuelt gå gjennom de ~200 eksisterende hjertestarterne i OSM og legge til korrekt ref:hjertestarterregister.

Lite notat: Et personlig mål er også å kontakte eiere av hjertestartere som ikke finnes i Hjertestarterregisteret og få dem registrert der, slik at AMK kan bruke dem i 113-samtaler.

osm_duplicate_register_ref
Planen var å slette noden som ikke matcher plasseringen i Hjertestarterregisteret. Jeg ønsket imidlertid å unngå automatisk sletting i første omgang for å avdekke eventuelle feil i skriptet.

skipped_create_nearby
Her var tanken at man i startfasen manuelt legger til ref, slik at nodene blir koblet riktig. Over tid kan jeg vurdere automatisk sammenslåing dersom eksisterende noder ligger innenfor X meter. Jeg er imidlertid usikker på robust merge logikk som ikke risikerer å slå sammen ulike hjertestartere som tilfeldigvis er nærme hverandre (for eksempel i kjøpesentere).

skipped_delete_not_aed_only
Denne henger sammen med det i kommentaren over. Eventuelt kan man gjøre tilsvarende som addr2osm og flytte AED-informasjonen ut fra f.eks. amenity=shop til en egen node.

Det blir ofte diskutert her hva som skal skje dersom det finnes en eksisterende node (her hjertestarter) i nærheten. Skal den slettes eller beholdes? Hva skal nøyaktig regel være? F.eks. erstatte dersom nærmere enn 20 meter.

Her har jeg config verdien nearbyAedDistanceMeters med 20 . Tanken var at dersom man fjerner ref:hjertestarterregister, så betyr det at objektet ikke lenger skal oppdateres automatisk (en form for opt-out).

Etter første import ser jeg for meg noe manuelt arbeid med de ~200 eksisterende nodene. Samtidig er det kanskje bedre å definere en tydelig opt-out-tag og heller slå sammen noder der det er forsvarlig, for å redusere manuelt vedlikehold over tid som du nevner.

Og tilsvarende, om en OSM-bruker har flyttet en node til en riktigere plassering, hvordan skal skriptet håndtere dette (det er da et avvik fra datakilden)? F.eks. akseptere flyttinger inntil maks. 50 meter.

Her har jeg satt changedLocationDistanceMeters til 10 meter. Tanken er å ignorere små avvik (1-5 meter) som skyldes avrunding i lokasjon-data fra skapene, eller mindre manuelle justeringer.

Du har mer erfaring her enn meg, tror du 50 meter er en mer fornuftig terskel?

Import guidelines krever at en bruker skal kunne unngå automatiserte endringer dersom ønsket. Dette løses ofte ved at brukerne kan legge til en bestemt note tag.

Min tanke var at fravær av ref:hjertestarterregister skulle fungere som opt-out. Men jeg kan like gjerne implementere en eksplisitt note- eller opt-out-tag dersom det er mer i tråd med vanlig praksis.

Flere andre slike oppdateringer for Norge har endringssett som dekker hele landet eller et helt fylke om gangen. Jeg synes ikke det er et problem så lenge det fremgår av endringssettet at oppdateringen gjelder Norge. Dersom det oppstår systematiske feil kan det være en fordel å ha noen få store endringssett, med tanke på tilbakerulling.

Det høres fornuftig ut. Jeg var usikker på hva som er beste praksis, men historikken viser at landsdekkende endringer ikke er uvanlig. Færre, større endringssett kan også være en fordel ved eventuell tilbakerulling.

Beklager om svaret ble litt rotete, ikke lett med ganske liten mobil :sweat_smile:

1 Like
4

Da ligger wiki siden ute på Import/Catalogue/AED import for Norway - OpenStreetMap Wiki

Så er koden på github GitHub - Johannes-Andersen/Hjertestarterregister2OSM: Importing and syncing of AEDs (Automated External Defibrillator) into OpenStreetMap

1 Like
5

Stilig! Kult arbeid. Stiller meg positiv!

6

Ja, tar vare på andre eventuelle tagger dersom de finnes.

Ikke la være å opprette ny node med hjertestarter dersom det allerede finnes en nærheten. Brukere vil etter hvert oppdage flette dem sammen og plassere på riktig sted.

Test fletting av de eksisterende 200 nodene med datasettet med Conflation plugin, så får du en følelse med hva som kan være hensiktsmessig verdi. Verdien vil avhenge av normal “bredde” på bygninger der hjertestartere finnes.

Opt-out må nok være eksplisitt, siden alle som legger inn hjertestartere uten å vite om importen ikke vil ha med ref.

7

Wiki ser fin ut, bare noen få kommentarer:

The underlying drive for getting this import is to help save lives. If a user of OpenStreetMap data relies on outdated or wrong data they may spend important minutes looking for a nonexistent AED when a life is in dager. Also missing AEDs could cause people to waste time going to a AED that is farther away.

Foreslår å ta bort dette. Man kan generelt ikke stole på OSM for slike formål.

Changeset Tags

Det bør være tekst i changeset som beskriver hva som gjøres på en enkel måte, f.eks. “Update defibrillator import in Norway”.

1. Kildehenvisning og ny-registreringer.
Det skal opplyses at kilden for opplysningene er Hjertestarterregisteret ved
NAKOS på nettstedet www.113.no

Må legges inn her i samme format som de andre: Contributors - OpenStreetMap Wiki

8

Heio!

Satt og jobbet litt med koden igjen i går, så har implementert en del av det du nevnet :grinning_face_with_smiling_eyes:

Smart, da fjerner jeg logikken som sier “hvis nærmere en X, men for lengere unna en X, ikke merge eller legg til”, men som nevnt under finne en OK verdi for auto merge.

Skal ta og leke meg litt i JOSM i dag for å finne en god terskel. :smiley:

edit: ser ut som 175m er en god balanse :smiling_face:

La til en sjekk som opter ut alt med et notat, eller fixme

Enig, fjernet.

Oppdatert. Den sender også med disse taggene:

{    
    "created_by": "hjertestarterregister2osm v${version}",
    "source": "Hjertestarterregisteret",
    "source:url": "https://hjertestarterregister.113.no",
    "source:date": "new Date().toISOString()",
    "import:page":
      "https://wiki.openstreetmap.org/w/index.php?title=Import/Catalogue/AED_import_for_Norway",
    "bot": "yes"
}

Tenkte å legge inn så snart vi var ferdig med å avklare om importering var greit for folk :grinning_face_with_smiling_eyes:

Har lagt det til nå

1 Like
9

@NKA Hva tenker du om at jeg prøver å skru det på i en ukes tid i Fredrikstad? Det er i nærområdet der jeg bor og redigerer mye i.

Så kan vi vurdere om en ukes tid om det fortsatt er noe vi som fellesskap ønsker å utvide til resten av landet :grinning_face_with_smiling_eyes:

Tenker i tillegg at det kan være greit å teste i et mindre område først, så det er lettere å rulle tilbake og finne eventuelle bugs.

2 Likes
10

Ser ut som det funker greit så langt :smiley:
Kjørt automatisk 2 ganger daglig for fredrikstad for å se om den gjør noe uforventet. Så kun 3 endringer blitt oppdaget i Fredrikstad området på den uken som har gått.

Liten oppsumering av de 3 endringene den kjørte:

Hvis ingen har noe mot det, så tenker jeg å utvide til hele Østfold, og lar det kjøre en ukes tid for å se etter eventuelle feil før videre utrulling til hele landet.

11

Ser bra ut. Hjertestarteren som lå på St1-noden burde vel få den koordinaten som er i registeret? Nå ligger den på nøyaktig samme koordinat som St1-noden over bensinpumpene, bare fordi noen registrerte hjertestarteren der St1-noden tilfeldigvis lå. (Tenkte dette som en regel når man flytter ut hjertestarter-tagger til ny node).

Ellers ser det greit for meg å teste videre med Østfold.