Koordinater og srid 4326/25832
Find koordinaterne i svaret, vælg mellem WGS84 og ETRS89/UTM32 med srid, reverse-geokod i begge systemer, og konverter selv med pyproj eller proj4.
Hver adgangsadresse har et adgangspunkt: koordinaten for indgangen til bygningen. API'et kan give den i to koordinatsystemer, og du vælger med parameteren srid. Det er den samme parameter som i DAWA.
De to systemer
srid | System | Enhed | Rækkefølge | Eksempel (Aarhus C) |
|---|---|---|---|---|
4326 (standard) | WGS84, længde- og breddegrad | grader | længde, bredde | [10.20285443, 56.14811374] |
25832 | ETRS89 / UTM zone 32N | meter | øst, nord | [574730.16, 6223215.94] |
WGS84 er det, GPS, Google Maps, Leaflet og de fleste webkort bruger. ETRS89/UTM32 er det officielle danske system, som kommuner, GIS-værktøjer og Klimadatastyrelsens kortdata bruger. Fordelen ved UTM er, at koordinaterne er meter: afstanden mellem to punkter er almindelig Pythagoras.
srid accepterer kun 4326 og 25832. Alle andre værdier giver 400 med type QueryParameterFormatError og teksten "srid skal være 4326 (WGS84) eller 25832 (ETRS89/UTM32)".
Hvor koordinaterne står i svaret
| Svar | Felt |
|---|---|
/adgangsadresser, /adgangsadresser/{id}, /adgangsadresser/reverse (nestet) | adgangspunkt.koordinater |
/adresser, /adresser/{id}, /adresser/reverse (nestet) | adgangsadresse.adgangspunkt.koordinater |
struktur=mini | x, y |
struktur=flad | wgs84koordinat_længde, wgs84koordinat_bredde, etrs89koordinat_øst, etrs89koordinat_nord (begge systemer altid) |
format=csv | wgs84koordinat_længde, wgs84koordinat_bredde, etrs89koordinat_øst, etrs89koordinat_nord (begge systemer altid) |
format=geojson | geometry.coordinates (systemet står i crs) |
/autocomplete | data.x, data.y |
koordinater er en liste med to tal, og rækkefølgen er altid [x, y]: længdegrad før breddegrad, eller øst før nord. En adresse har ingen egen koordinat. En lejlighed på 3. sal har sin adgangsadresses punkt.
/autocomplete følger også srid: med srid=25832 står data.x og data.y i UTM-meter i stedet for grader.
Hent den samme adresse i begge systemer:
import os import requests API = "https://api.danadresse.dk" headers = {"X-Api-Key": os.environ["DANADRESSE_API_KEY"]} adresse_id = "0a3f50ae-b4ee-32b8-e044-0003ba298018" for srid, navn in ((4326, "WGS84"), (25832, "ETRS89/UTM32")): r = requests.get(f"{API}/adresser/{adresse_id}", params={"srid": srid}, headers=headers, timeout=10) r.raise_for_status() x, y = r.json()["adgangsadresse"]["adgangspunkt"]["koordinater"] print(f"{navn:13} x={x} y={y}")
WGS84 x=11.35623868 y=55.40464424 ETRS89/UTM32 x=649189.55 y=6142347.15
Akserækkefølgen: den hyppigste fejl
API'et giver [længde, bredde], som GeoJSON. Mange kortbiblioteker vil have det omvendt:
| Bibliotek | Forventer |
|---|---|
| GeoJSON, OpenLayers, Mapbox GL, Turf | [længde, bredde] |
Leaflet L.marker(), L.latLng() | [bredde, længde] |
| Google Maps | { lat: bredde, lng: længde } |
const [lon, lat] = adresse.adgangsadresse.adgangspunkt.koordinater; L.marker([lat, lon]).addTo(kort); // Leaflet: bredde først
Lander dine markører i Det Arabiske Hav i stedet for i Danmark, er akserne byttet om.
Reverse-geokodning med srid
/adgangsadresser/reverse og /adresser/reverse finder den nærmeste adresse til et punkt. x og y læses i det system, srid angiver, og svaret kommer i samme system:
curl -s "https://api.danadresse.dk/adgangsadresser/reverse?x=12.5683&y=55.6761" \ -H "X-Api-Key: $DANADRESSE_API_KEY"
Med UTM-koordinater skal du sætte srid=25832:
curl -s "https://api.danadresse.dk/adgangsadresser/reverse?x=574730.16&y=6223215.94&srid=25832" \ -H "X-Api-Key: $DANADRESSE_API_KEY"
Glemmer du srid=25832 til UTM-koordinater, eller bytter du om på x og y, er der ingen adresse i nærheden, og du får 404 med "title": "No address within range". Se Ingen resultater?
Det samme gælder cirkel= og polygon= på /adresser og /adgangsadresser: koordinaterne læses i det system, srid angiver. Radius i cirkel er altid meter.
Konverter selv
Har du koordinater i det ene system og skal bruge det andet, så konverter lokalt i stedet for at lave ekstra kald. I Python med pyproj (pip install pyproj):
from pyproj import Transformer # always_xy=True betyder (længde, bredde) ind og (øst, nord) ud, som i API'et. til_utm = Transformer.from_crs("EPSG:4326", "EPSG:25832", always_xy=True) til_wgs84 = Transformer.from_crs("EPSG:25832", "EPSG:4326", always_xy=True) oest, nord = til_utm.transform(10.20285443, 56.14811374) print(f"UTM32: {oest:.2f} {nord:.2f}") lon, lat = til_wgs84.transform(oest, nord) print(f"WGS84: {lon:.8f} {lat:.8f}")
Uden always_xy=True følger pyproj EPSG-definitionen for 4326, som er bredde før længde. Det er en klassisk kilde til byttede akser.
I JavaScript med proj4 (npm install proj4):
import proj4 from "proj4"; proj4.defs("EPSG:25832", "+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs"); // proj4 bruger altid [længde, bredde] / [øst, nord]. const [oest, nord] = proj4("EPSG:4326", "EPSG:25832", [10.20285443, 56.14811374]); console.log(`UTM32: ${oest.toFixed(2)} ${nord.toFixed(2)}`); const [lon, lat] = proj4("EPSG:25832", "EPSG:4326", [oest, nord]); console.log(`WGS84: ${lon.toFixed(8)} ${lat.toFixed(8)}`);
Præcision og højde
- WGS84-koordinater har 8 decimaler (cirka en millimeter). UTM-koordinater har 2 decimaler (en centimeter). Der er ingen grund til at runde dem af, før du gemmer.
adgangspunkt.nøjagtighedfortæller, hvor godt punktet er bestemt:Aer placeret præcist på grundkortet,Ber beregnet, ogUer usikkert.adgangspunkt.højdeer terrænhøjden i meter ved adgangspunktet, når den er kendt.
Næste skridt
Relaterede guides
Markdown-kilde Fejl i guiden? Skriv til os API-reference (Swagger)