Mer entydig definisjon og beskrivelse av koordinatsystem M043

[petterreinholdtsen]

---

       Prosjekt  Noark 5 standard
       Kategori  Noark git 2021-03-18
Brukerreferanse  pere@hungry.com

---

Dette er relatert til #77 .

Metadataelement M043 har følgende definisjon og beskrivelse:

  Definisjon: Geografiske koordinaters referansesystem

  Kommentarer: Koordinatsystem for geografisk punkt, flate
           etc. Normalt en kode angitt som EPSG:nnnnn hvor nnnnn
           er 32632 (Sør-Norge), 32632 (Nord-Norge, Norge
           generelt) og 32635 (Finnmark). Kan også være en kode
           som EUREFSonenn der nn normalt er 32, 33 eller 35.

Er det en skrivefeil at 32632 er oppgitt to ganger?

Tilsvarende verdi i tjenestegrensesnittet har følgende beskrivelse:

  Identifikator for referansekoordinatsystem som definert av `EPSG
  <http://www.epsg.org/>`__. Formatet på kodeverdiene er
  «EPSG:{nummer}», der {nummer} er EPSG-koden.

  Denne kodelisten er relatert til KoordinatsystemKode i
  GeoIntegrasjon.  Koordinatsystem-verdier kan hentes fra registeret
  til GeoNorge, tilgjengelig fra
  [https://register.geonorge.no/epsg-koder].

I tjenestegrensesnittet er det kun en kilde til verdier, EPSG, for å forenkle jobben til de som skal snakke med API-et. Jeg tror det er en veldig dårlig ide å ha flere verdier som representerer samme koordinatsystem, og oppfordrer til å droppe bruken av EUREFSone##-verdier.

Jeg merker meg at hverken EUREFSone32, EUREFSone33 eller EUREFSone35 kan søkes opp i geonorges register, men mistenker disse tilsvarer UTM sone 32, 33 og 35 nord, dvs. samme koordinatsystem som EPSG:32632, EPSG:32633, og EPSG:32635. Hva er planlagt kilde for disse EUREFSone##-definisjonene?

En kan lese mer om aktuelle UTM-soner på https://epsg.io/32632 , https://epsg.io/32633 og https://epsg.io/32635 .

[sturtzel]

EUREFSonexx kommer fra matrikkelen (søk på nettet). Men internt opereres det med integer i form av epsgKode og sosiKode (SOSI har andre numre, 21 for sone 31). Antagelig har denne gått ut av bruk. Den var aktuell da GI 1.1 ble laget. Et dokument som inneholder disse: https://kurs.matrikkel.no:7004/matrikkel/docs/DataelementerOgKodelisterVer.2.0.htm

EPSG har flere koder for de enkelte sonene, f.eks. 25832 i tillegg til 32632. https://register.geonorge.no/epsg-koder/euref89-utm-sone-32-2d/ff3704f7-8259-4988-a3be-e35076228ea9 https://register.geonorge.no/epsg-koder/wgs84-utm-sone-32-2d/bf6c78aa-55a1-43f0-9b5f-d6c6f79d388e Den første er basert på EUREF89, den andre på WGS84.

Her foreslår jeg en prat med Kartverket, samt kartleverandører som Norkart og Norconsult. Koordinatene kommer fra matrikkelen eller fra kartoppslag.

[petterreinholdtsen]

[Ragnar Sturtzel]

EUREFSonexx kommer fra matrikkelen (søk på nettet). Men internt opereres det med integer i form av epsgKode og sosiKode (SOSI har andre numre, 21 for sone 31). Antagelig har denne gått ut av bruk. Den var aktuell da GI 1.1 ble laget. Et dokument som inneholder disse: https://kurs.matrikkel.no:7004/matrikkel/docs/DataelementerOgKodelisterVer.2.0.htm

Ah, takk. Der fant jeg nok informasjon til å forstå forskjellen.

De er basert på et annen datum og geoide enn WGS84, og vil dermed gi litt forskjellige koordinater og høydeverdier enn WGS84-baserte (som for eksempel GPS-koordinater). Slike ting påvirker jo resultatet for posisjoner, og der har EPSG-katalogen sikret at alt er entydig definert.

Fant EURef89 i <URL: https://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 > for de som er nysgjerrig.

EPSG har flere koder for de enkelte sonene, f.eks. 25832 i tillegg til 32632. https://register.geonorge.no/epsg-koder/euref89-utm-sone-32-2d/ff3704f7-8259-4988-a3be-e35076228ea9 https://register.geonorge.no/epsg-koder/wgs84-utm-sone-32-2d/bf6c78aa-55a1-43f0-9b5f-d6c6f79d388e Den første er basert på EUREF89, den andre på WGS84.

Det er uklart for meg hvilket datum kartverket og matrikkelen mener når de skriver EUREFSone##, men jeg mistenker det er disse EPSG-koordinatsystemene.

• EUREFSone32 = EPSG:25832, <URL: https://epsg.io/25832 >
• EUREFSone33 = EPSG:25833, <URL: https://epsg.io/25833 >
• EUREFSone35 = EPSG:25835, <URL: https://epsg.io/25835 >

Det er flere muligheter med andre parameter, så det hadde vært fint å få det entydig avgjort. Det er klart at hvis for eksempel EUREFSone32 ikke har noen EPSG-oppføring, så trengs det flere ulike kataloger.

Søk på for eksempel <URL: https://register.geonorge.no/search/?register=All+registers&municipality=&text=EUREFSone33 > gir ingen treff, så lite hjelp der.

Her foreslår jeg en prat med Kartverket, samt kartleverandører som Norkart og Norconsult. Koordinatene kommer fra matrikkelen eller fra kartoppslag.

Enig, både for å finne ut om det holder med en type referanser og for å finne ut hva slags EPSG-koder disse EUREFSone##-verdiene egentlig har.

Jeg vet kartverket bruker systemet <URL: https://proj4.org/ > internt, hvilket er fri programvareverktøyet for å omforme posisjoner mellom koordinatsystemer jeg tenkte på. Denne spiser EPSG-referanser direkte. :)

-- Vennlig hilsen Petter Reinholdtsen

[petterreinholdtsen]

Jeg spurte OpenStreetmap-IRC-kanalen, og fikk følgende tilbakemelding:

"Alle koordinatsystemer brukt i Norge har en EPSG kode. Også historiske. EUREF89, UTM 32 sone uten et høydesystem har ESPG koden 25832.

Den praktiske forskjellen mellom EUREF89 og WGS84 er at euref følger kontientaltdriften til den europeiske kontinentalplaten, men WGS84 ikke gjør det."

Hvis det stemmer, så bør det holde med ESPG-katalogen for verdier i dette feltet.

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

I praksis betyr det at referanser etter WGS84 er øyeblikksbilder. Men der man ikke trenger millimeterangivelse vil det vel ikke bety så mye.

[petterreinholdtsen]

[Ragnar Sturtzel]

I praksis betyr det at referanser etter WGS84 er øyeblikksbilder. Men der man ikke trenger millimeterangivelse vil det vel ikke bety så mye.

Nja, det gjelder egentlig alle koordinatsystemer og datum, da kloden endrer seg over tid. Det er jo bare et spørsmål om tidshorisont. :)

Ble forøvrig tipset på IRC-kanalen om at navnet "EUREFSone32" riktig nok ikke finnes i geonorges katalog, men hvis en deler inn litt mellomrom og søker etter for eksempel "EUREF89 UTM sone 32", så får en opp hva det konkret betyr. En kan da se fra <URL: https://register.geonorge.no/epsg-koder?register=EPSG+koder&municipality=&text=euref89+UTM+sone+32 > at EUREFSone32 er et system uten høydedefinisjon med EPSG-kode 25832.

Det virker dermed å ikke være noe tilfelle identifisert så langt der EPSG-koder ikke er tilstrekkelig for å entydig bestemme en posisjon. EUREFSone33 er da 25833 og EUREFSone35 er 25835.

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Det er noen år siden jeg testet GI 1.1 med funksjonen for å hente kartreferanse. Det er mulig kartene har blitt bedre til å angi referanse enn den gangen. For arkivene er det en fordel å kunne ta imot data uten å måtte transformere. Og da er vi tilbake til hva kartleverandørene og matrikkelen m.fl. leverer som referanse.

Men det beste hadde selvfølgelig vært om alle returnerte med EPSG-kode.

[petterreinholdtsen]

[Ragnar Sturtzel]

Det er noen år siden jeg testet GI 1.1 med funksjonen for å hente kartreferanse. Det er mulig kartene har blitt bedre til å angi referanse enn den gangen. For arkivene er det en fordel å kunne ta imot data uten å måtte transformere. Og da er vi tilbake til hva kartleverandørene og matrikkelen m.fl. leverer som referanse.

Ser den, men for de som skal bruke arkivene, og de som skal finne ting i arkivene, så er det en stor fordel om de kan tolke informasjonen som er arkivert. Og for kartposisjoner, så er det vesentlig å ha en klar og entydig definisjon av hva x, y og z betyr for noe, hvilket EPSG-kode gir oss. Den er til og med så klar og entydig at de andre verdiene for koordinatsystemer er koblet til EPSG-koder. Jeg antar dermed at de som har et posisjonskoordinat og ønsker å koble det til et arkivdokument, enten vet hva de har og er i stand til å knytte det til EPSG-kode, eller ikke vet hva de har. Og hvis de som i utgangspunktet har koordinatet ikke vet hva de har, så vil ikke de som arkiverer det heller vite hva de har, og de som skal bruke informasjonen til å finne ting i arkivet i fremtiden vite hva de har. For å unngå en slik situasjon så bør det kreves av de som arkiveres at de finner ut EPSG-kode før de sender koordinatet til arkivet, og i hvert fall før koordinatene deponeres.

Men det beste hadde selvfølgelig vært om alle returnerte med EPSG-kode.

Godt å høre at vi er helt enige der.

Bevepnet med EPSG-kode og x/y/z-koordinater, så blir det mulig å søke med posisjon både som avstand fra et utgangspunkt og innenfor et areal. Uten blir det svært vanskelig å vite hvor på kloden et gitt x/y/z-koordinat konkret befinner seg.

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Ja, hele hensikten med å registrere dette er at man i en kartvisning skal kunne få opp georefererte saker i kartet. Derfor ble det også laget et BBOX-søk i GeoIntegrasjon 1.1. Noen ønsket seg vilkårlig polygon, men det fordrer langt mer logikk enn å hente ut noe innenfor en firkant.

[petterreinholdtsen]

Forresten, det slo meg at i XML bør en vel i stedet for <koordinatsystem>EPSG:32632</koordinatsystem>, bruke noe ala <koordinatsystem type="EPSG">32632</koordinatsystem> eller <koordinatsystem><type>EPSG</type><value>32632</value></koordinatsystem>. Er det en grunn til å ikke skille type og verdi på XML-måten?

[sturtzel]

I tilfelle det siste. Det ble felles felt fordi det er slik det kommer fra kartsystemene. Det blir som for internasjonale enhetsnumre og personidentifikatorer. Arkivmessig er det vel enklere å få felt inn slik de er og også for klienter som da må bruke de på samme måte.

[petterreinholdtsen]

[Ragnar Sturtzel]

I tilfelle det siste. Det ble felles felt fordi det er slik det kommer fra kartsystemene. Det blir som for internasjonale enhetsnumre og personidentifikatorer. Arkivmessig er det vel enklere å få felt inn slik de er og også for klienter som da må bruke de på samme måte.

Hvis noen velger å lagre disse to verdiene (type og kode) internt som en streng er det jo ikke spesielt vanskelig å hente d dem ut i XML-format oppdelt i type og verdi. Her er et eksempel fra Python 3:

!/usr/bin/env python3

import xml.etree.ElementTree as ET

koordinatsystem = "ESRI:1234"

tree = ET.Element('arkiv') t, v = koordinatsystem.split(':', 1) k = ET.SubElement(tree, 'koordinatsystem', attrib={'type':t}) k.text = v

print(ET.tostring(tree))

b'1234'

Arkivmessig er det vel en fordel å få dem levert med informasjon om hva de ulike delen er for noe, i stedet for som en kombinasjonsstreng?

Enig i at samme argumentasjon også gjelder for organisasjonsid og personid. Mistenker de også burde ha XML-representasjon som gjør det klart hva de ulike delen er.

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Ser den, antagelig fornuftig å fjerne tolkning fra arkivkjernen og la det være opp til servicer som f.eks. kan liste systemer / land eller splitte/slå sammen til/fra arkivet. Koden må være streng for å støtte systemer som måtte finne på å ha noe annet enn numerisk kode. Det gjelder for så vidt også for ID-er for personer og enheter (og for postnummer som typisk har landkode i tillegg for utenlandsadressering).

[petterreinholdtsen]

[Ragnar Sturtzel]

Ser den, antagelig fornuftig å fjerne tolkning fra arkivkjernen og la det være opp til servicer som f.eks. kan liste systemer / land eller splitte/slå sammen til/fra arkivet. Koden må være streng for å støtte systemer som måtte finne på å ha noe annet enn numerisk kode.

Gitt at arkivkjernen skal kunne søke etter mapper og dokumentsamlinger koblet til geografisk posisjon innenfor et område (boks, sirkel), så må arkivkjernen være i stand til å forstå verdien av koordinatsystem og kunne gi det til sitt bibliotek for koordinat-omforming slik at et punkt i UTM-32 blir gjenkjent som innenfor en boks med koordinater oppgitt i UTF-33. Det ønsket om å håndtere og omforme ulike projeseringer fordrer standardisering av verdiene i koordinatsystem, og er årsaken til at jeg tar opp behovet for entydig beskrivelse av M043.

Det gjelder for så vidt også for ID-er for personer og enheter (og for postnummer som typisk har landkode i tillegg for utenlandsadressering).

Akkurat slik omforming av projesering / koordinatsystem for søk er nok i mye mindre grad mulig å standardisere for ID-er for personer, enheter og postnummer. Det nærmeste eksemplet ville vel være at en person har ulike type ID, som svensk og norsk personnummer, og en kan søke på begge ved å oppgi bare en av dem. Det kan ikke gjøres med offentlig tilgjengelig informasjon, slik en kan gjøre med koordinater med tilhørende EPSG-kode, så det er nok utenfor Noark 5 å håndtere.

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

I praksis må det gjøres transformering både av data og av søkeargumenter for at søkene skal fungere. Jeg la inn det da GI 1.1 kom med koordinater for snart 10 år siden. Men der la jeg også inn mapping mellom det som jeg fant ble benyttet av koder fra klientene og hva det betød som sone. I dag burde det nok holde med EPSG, ja. Men jeg tror det går helt greit å støtte koordinatsystem som ett felt (som EPSG:32633).