EPSG:25832 eller EPSG:4326? Sådan vælger du koordinatsystem til danske luftfotos

De tre systemer, du reelt møder

Reglen, der holder i praksis

Gem data i det system, de blev målt i. Konverter i kanten af dit system, så tæt på brugeren som muligt, og aldrig to gange.

For danske luftfotos betyder det 25832. Det er det native system, og hver gang et rasterbillede omprojiceres, bliver pixels gensamplet — værdierne bliver interpoleret, kanter bliver en anelse blødere, og det kan ikke gøres om. Vektorer har ikke det problem på samme måde: dér transformeres koordinaterne, og du kan regne tilbage.

Omvendt: kræv aldrig 25832 af den, der skal bruge dit API. Den prospekt, der har koordinaterne fra en telefon eller et CRM-felt, har dem i bredde og længde. Beder du om UTM i første skridt, har du tabt vedkommende inden for det første halve minut.

Akserækkefølgen, der vender om

Det her er den fejl, der koster flest timer, fordi den ikke giver nogen fejlmeddelelse. Den giver et gyldigt resultat det forkerte sted.

I WMS 1.1.1 skrives en bbox i EPSG:4326 som længde,bredde. I WMS 1.3.0 følger den koordinatsystemets egen definition, og den er bredde,længde. Samme tal, samme kode, forskellig version — andet sted på kloden.

GeoJSON har til gengæld ét svar, som ikke kan diskuteres: længde,bredde, altid, uanset hvad. Det står i RFC 7946, og det er et af de få steder i geodata, hvor der ikke er en undtagelse.

I projicerede systemer som 25832 er rækkefølgen øst,nord — altså x,y, som du selv ville skrive det. Det er endnu en grund til, at det er behageligt at blive i 25832, så længe du er inden for Danmark.

Højder er et fjerde system, og det bliver glemt

Danske højder opgives normalt i DVR90, som er knyttet til middelvandstanden. Den højde, en GNSS-modtager giver dig råt, er en ellipsoidehøjde, som er knyttet til en matematisk model af jorden.

Forskellen mellem de to er i Danmark i størrelsesordenen nogle og tredive meter. Den er ikke konstant over landet, og den forsvinder ikke, fordi din software ikke nævner den. Blander du de to i samme datasæt, får du ikke små fejl — du får tag- og terrænhøjder, der er helt ved siden af.

Hvis du arbejder med højdemodeller eller med droneleverancer, så skriv eksplicit i leveranceaftalen, hvilket højdesystem der gælder. Det er en linje tekst, og det er den linje, der afgør om to leverancer kan lægges oven på hinanden.

Hvad vi selv gør, og hvorfor

Vores API tager imod EPSG:4326 som standard, fordi det er det, folk har. Det tager også imod EPSG:25832, fordi enhver dansk landinspektør og enhver professionel GIS-bruger arbejder i det, og fordi at afvise det ville se amatøragtigt ud.

Vi konverterer aldrig i det stille: du får koordinater tilbage i det system, du selv brugte. Tiles leveres i EPSG:3857, fordi det er det ethvert webkort forventer. Vælger du 25832 på et billede, får du dataene i deres oprindelige projektion, helt uden gensampling — det er den tabsfrie udgave, og den findes netop til dem, der kan se forskellen.

Og vi skriver altid i metadata, hvilket system pixels ligger i, og at kilden er 25832. Du skal ikke gætte på vores vegne.

Videre læsning

• Sådan henter du et dansk ortofoto over WMS i EPSG:25832 Selve GetMap-kaldet, hvor du sætter koordinatsystemet — og de tre fejl, der ligner en serverfejl, men er dine egne.
• Dataforsyningen-token: opret, navngiv, forny Tokenen, kaldet kræver: hvor den skal stå, hvorfor du skal have flere af dem med navn og udløbsdato, og hvad du gør, når en udløber.
• Ortofotos i Leaflet, MapLibre og OpenLayers Hvad valget mellem 25832 og 3857 betyder, når kortet skal tegnes — og hvilket bibliotek der kan hvad.