Utilgjengelig kilde
Tjenesten svarer ikke, og informasjonen mangler i kartet.
Geodata × Norsk Luftambulanse TeknologiVarde.
Varde.
Et vakttårn
for kartdata.
- Problem
- Systemansvarlige trenger oversikt over feil i kartdata.
- Hva jeg gjorde
- Bygget den felles synkroniseringsprosessen i studentteamet.
- Resultat
- Teamet leverte og demonstrerte løsningen for Norsk Luftambulanse.
Utvikler · ansvar for den felles synkroniseringsflyten
I seks uker som sommerstudent hos Geodata jobbet jeg med et dashbord som samler overvåking og oppdatering av kartdata for Norsk Luftambulanse Teknologi (NLA).
- Periode
- 15. juni–24. juli 2026
- Arbeidsgiver
- Geodata AS · Oslo
- Kunde
- Norsk Luftambulanse Teknologi
- Team
- Fem utviklere og én UX-designer
Bakgrunn
NLA bruker digitale kart i planleggingen av luftambulanseoppdrag. Kartene kombinerer informasjon fra flere kilder, blant annet vær og hindringer. Når en flyging planlegges, er det viktig å vite om dataene er tilgjengelige og oppdaterte.
Kraftlinjer og andre menneskeskapte hindringer er en del av bildet. Nasjonalt register over luftfartshindre (NRL) er en av kildene bak kartene. Oppgaven var å hjelpe dem som vedlikeholder kildene, med å oppdage problemer og holde dataene oppdaterte. Varde samler kontroller, statushistorikk og støttede oppdateringer.
Feil i innholdet
Kilden svarer, men poster kan mangle eller være duplisert.
Utdatert informasjon
Kartet lastes inn, men dataene beskriver en tidligere situasjon.
Hvem trenger oversikten?
Systemansvarlige
Et sted å kontrollere kildenes tilstand, starte støttede oppdateringer og undersøke statushistorikken.
Brukerstøtte
Bedre oversikt over problemer og leverandørinformasjon når en sak skal følges opp.
Piloter og redningsmannskap
De er avhengige av karttjenestene bak dashbordet når oppdrag planlegges. Behovet for pålitelige kilder var utgangspunktet for prosjektet.
Mitt bidrag
Jeg satte opp den felles prosessen som holdt kartdataene oppdaterte. Den samordnet planlagt og manuell synkronisering, kjørte oppdateringer for hver kilde og gjorde utfallet synlig i Varde.
Dette var et sentralt krav fra kunden. Hovedansvaret mitt var den felles flyten, tidsplanene og kontrollene. Jeg bidro også på tvers av løsningen og til deler av Nasjonalt register over luftfartshindre (NRL). Dashbordet og den samlede NRL-integrasjonen var teamleveranser.
Én felles prosess
Koble oppstart, kildekontroller, oppdateringsjobb og registrert resultat, slik at alle stegene hører til samme flyt.
Planlagte oppdateringer
Kjør regelmessige jobber med intervaller som passer hvert kartlag, uten at noen må starte hver oppdatering manuelt.
Kontroller og tilbakemelding
Gi mulighet for manuell kjøring på støttede kartlag og vis siste synkroniseringsstatus i dashbordet.
Løsningen
Dashbordet knytter kontrollene og oppdateringene til menneskene som er ansvarlige for dataene. Skjermene viser grensesnittet teamet leverte.
Se hva som må følges opp
Åpningsvisningen samler tilstanden til kartlagene, slik at systemansvarlige kan begynne med kildene som trenger oppfølging.
- Kritiske kartlag kommer øverst i listen.
- En oppsummering viser kritisk status, advarsel og OK.
- Søk og et kartutsnitt hjelper brukeren å finne et kartlag.
Undersøk et kartlag og oppdateringene
Åpne et kartlag for å se kontroller, synkroniseringsinformasjon og historikk samlet. Her blir den felles oppdateringsprosessen synlig for brukeren.
- Se siste kontroller og synkroniseringsstatus.
- Finn kildedatoer, leverandørinformasjon og identifikatorer for kartlaget.
- Filtrer tidligere meldinger for å undersøke en periode eller status.
Følg en status inn i detaljene
En oppsummering er utgangspunktet. Når en statusmelding åpnes, vises enkeltkontroller gruppert etter kilde, slik at systemansvarlige kan undersøke hva som skjedde.
- Se kontrollresultatene sammen med riktig kilde.
- Finn kjøringen bak en tidligere melding.
- Undersøk enkeltkontroller for flere detaljer.
Synkronisering
Synkronisering betyr å oppdatere et kartlag fra kilden. Velg et steg for å følge prosessen jeg satte opp.
Oppdateringsløpet
Illustrert flyt
01 / Start
En tidsplan eller en støttet handling i dashbordet starter oppdateringen. Ulike kilder kan bruke ulike intervaller.
Systemarkitektur
Teamet delte regelmessige jobber, tjenerlogikk og grensesnitt i tre tjenester. Det ga oppdateringsprosessen et sted å kjøre og brukeren et sted å se resultatet.
Systemet i korte trekk
Illustrert flyt
Tidsplanlegger
Python · APSchedulerStarter regelmessige kontroller og synkroniseringsjobber etter tidsplanen for hvert kartlag.
Backend
FastAPI · ArcGIS API for PythonSamordner kontroller og oppdateringer. Oppsett og status for kartlag lagres i ArcGIS Online-tabeller.
Frontend
React · TypeScript · ArcGIS Maps SDKGjør systemets tilstand til en brukbar oversikt med kartvisning, kontroller og statushistorikk.
PythonFastAPIAPSchedulerArcGISReactTypeScriptDockerAzure DevOps
Se de tekniske valgene
Kontroller før oppdatering
Kildekontrollene kommer før notatboken kjøres. De avklarer om kilden er klar for synkronisering, slik at en planlagt oppstart ikke automatisk regnes som en vellykket oppdatering.
Gjør resultatet etterprøvbart
Når utfallet lagres, er prosessen nyttig også etter at jobben er ferdig. Systemansvarlige kan se siste status og gå tilbake til tidligere meldinger når et problem skal undersøkes.
Felles prosess, tilpasset oppdatering
Flyten håndterer tidsplaner og samordning. Egne notatbøker tar seg av oppdateringen for hver kilde, slik at ansvaret holdes atskilt.
Bidra til en større teamleveranse
For NRL leverte teamet både nedlasting av hele datasettet og oppdateringer via revisjonshistorikken i API-et. Jeg bidro til deler av integrasjonen ved siden av hovedansvaret for synkronisering. Docker pakket tjenestene, og Azure DevOps støttet utvikling og bygging.
Sommerjobben
Fra 15. juni til 24. juli 2026 var jeg sommerstudent hos Geodata i Oslo. Teamet besto av fem utviklere og én UX-designer, med veiledning fra Geodata og tett kontakt med NLA.
Et tidlig besøk hos NLA hjalp meg å forstå menneskene og teknologien bak kartene. Hos Geodata jobbet jeg i korte sprinter med daglige møter, planlegging, gjennomgang og evaluering. Sammen med teamet viste jeg kunden fremdriften og forbedret løsningen underveis.
Resultatet
Sommeren ble avsluttet med en demonstrasjon på Norsk Luftambulanses base i Lørenskog. Jeg presenterte Varde sammen med teamet og fikk lære mer om redningsmannskapenes arbeidsdag.
Teamet leverte overvåking, automatiske kontroller, synkronisering, historikk og varsling i ett dashbord. Jeg tok ansvar for den felles synkroniseringsprosessen, fra tidsplaner og kontroller til samordning av oppdateringene.
Møt teamet og se prosjektet i Geodatas film. Se prosjektfilmen ↗
Mer om prosjektetGeodatas historie om prosjektet ↗
Å Studios by Aaban
Ta kontakt Trenger du noe lignende?
Fortell kort hva du ønsker å få til. Du trenger ikke ha en ferdig plan.
Geodata × Norsk Luftambulanse TeknologiVarde.
Varde.
A watchtower
for map data.
- The problem
- Systems teams need to see faults in map data.
- What I did
- Built the shared synchronisation process within the student team.
- Result
- The team delivered and demonstrated the system to Norsk Luftambulanse.
Developer · shared synchronisation pipeline
A six-week summer internship at Geodata, building a monitoring and synchronisation dashboard for Norsk Luftambulanse Teknologi (NLA).
- When
- 15 June–24 July 2026
- Employer
- Geodata AS · Oslo
- Client
- Norsk Luftambulanse Teknologi
- Team
- Five developers + one UX designer
Background
NLA uses digital maps to help plan air-ambulance missions. Those maps combine information from different sources, including weather and obstacles. Knowing whether the data is available and current matters when planning a flight.
Power lines and other human-made obstacles are part of that picture. The National Register of Aviation Obstacles (NRL) is one of the sources behind the maps. The task was to help the people maintaining those sources spot problems and keep data current. Varde brings checks, status history and supported updates together.
Unavailable source
The service cannot be reached, so its information is missing from the map.
Incorrect content
The source responds, but records may be missing or duplicated.
Outdated information
The map loads, but the data describes an earlier state rather than current conditions.
Who needed this?
System administrators
A place to inspect source health, run supported updates and investigate status history.
Support
A clearer overview of problems and supplier information when following up an issue.
Pilots and rescue crews
They rely on the map services behind the dashboard when planning missions. Keeping those sources trustworthy was the reason for the project.
My contribution
I set up the shared process that kept map data updated. It coordinated scheduled and manual synchronisation, ran source-specific updates and made the outcome visible in Varde.
This was one of the client’s central requirements. My main responsibility was the common pipeline, scheduling and controls; I also helped across the stack and with parts of the National Register of Aviation Obstacles (NRL). The dashboard and the complete NRL integration were team deliveries.
One shared process
Connect the trigger, source checks, update job and recorded result, so each stage belongs to one flow.
Scheduled updates
Run recurring jobs at intervals suited to each layer, rather than requiring someone to start every update.
Controls and feedback
Support manual runs for eligible layers and make the latest synchronisation state visible in the dashboard.
The solution
The dashboard connects the underlying checks and updates to the people responsible for the data. These screens show the team’s delivered interface.
Spot what needs attention
The opening view brings map-layer health together, so administrators can begin with the sources that need attention.
- Critical layers appear at the top of the list.
- A summary shows critical, warning and OK states.
- Search and a map preview help locate a layer.
Inspect a layer and its updates
Open a layer to see its checks, synchronisation information and history in one place. This is where the shared update process becomes visible to the user.
- See the latest checks and synchronisation state.
- Find source dates, provider details and layer identifiers.
- Filter historical messages to investigate a period or status.
Follow a status into the details
A summary is the starting point. Opening a status message exposes individual check results, grouped by source, so administrators can investigate what happened.
- Keep check results associated with their source.
- Identify the run behind a historical message.
- Inspect individual checks for more detail.
Synchronisation
Synchronisation means bringing a map layer up to date with its source. Select a stage to follow the process I set up.
The update journey
Illustrated flow
01 / Start
A recurring schedule or a supported dashboard action starts the update. Different sources can use different intervals.
System architecture
The team separated recurring jobs, backend logic and the interface into three services. That gave the shared update process a place to run and the user a place to see its result.
System at a glance
Illustrated flow
Scheduler
Python · APSchedulerStarts recurring checks and synchronisation jobs using each layer’s configured schedule.
Backend
FastAPI · ArcGIS API for PythonCoordinates checks and updates. Layer configuration and status are stored in ArcGIS Online tables.
Frontend
React · TypeScript · ArcGIS Maps SDKTurns system state into a usable overview, with map previews, controls and status history.
PythonFastAPIAPSchedulerArcGISReactTypeScriptDockerAzure DevOps
Explore the engineering decisions
Check before updating
The source checks come before the notebook run. They establish whether the source is ready for synchronisation, rather than treating every scheduled trigger as a successful update.
Keep the result inspectable
Recording the outcome makes the process useful after the job finishes. Administrators can see the latest state and return to historical messages when investigating a problem.
Share the process, specialise the update
The pipeline handles scheduling and coordination. Source-specific notebooks handle the update itself, keeping those responsibilities separate.
Contribute to a wider team delivery
For NRL, the team delivered both a full-dataset download and updates using the API’s revision history. I contributed to parts of this integration alongside my main synchronisation responsibility. Docker packaged the services, and Azure DevOps supported the team’s development and CI/CD workflow.
The internship
From 15 June to 24 July 2026, I worked as a summer intern at Geodata in Oslo. The team combined five developers and one UX designer, with guidance from Geodata and close contact with NLA.
An early visit to NLA helped me understand the people and technology behind the maps. Back at Geodata, I worked in short sprints with daily standups, planning, reviews and retrospectives. I shared progress with the client alongside the team and refined the solution as the project developed.
The result
The summer ended with a demonstration at Norsk Luftambulanse’s base in Lørenskog. I presented Varde with the team and spent time learning about the rescue teams’ working day.
The team delivered monitoring, automated checks, synchronisation, history and alerts in one dashboard. I took responsibility for the shared synchronisation process, from scheduling and controls to coordinating the updates.
Meet the team and see the project in Geodata’s film. Watch the project film ↗
More about the projectGeodata’s project story ↗
Å Studios by Aaban
Get in touch Need something similar?
Tell me briefly what you want to achieve. You don’t need a finished plan.