Veiledere i bruk av standarder

Versjon 2019-01-16

Hvis du opplever problemer med disse veilederne er det fint om du kan sende en tilbakemelding til standardiseringssekretariatet@kartverket.no
Send oss også gjerne en beskrivelse av hva du savner veiledning om.

Dette er en veiledning i hvilke programpakker og konfigureringer som må utføres for arbeid mot SOSI-modellregister.


Installasjon_av_nødvendig_programvare_for_arbeid_med_SOSI_produktspesifikasjoner.pdf

.

Dette er en løype for å lage informasjonsmodellen i en SOSI-produktspesifikasjon som et utplukk av objekttyper fra fagområdene i SOSI del 2.


Veileder_i_å_modellere_produktspesifikasjon_som_utplukk_fra_SOSI_fagområder.pdf

.

Koder i kodelister skal ha navn etter samme mønster som alle andre UML-modellelementer, slik at lesere intuitivt forstår meningen med koden. Kodelister med veldig mange koder er vanligvis ikke godt egnet til å vises i sin helhet i et UML-diagram.


eksempel på lang kodeliste

Slike kodelister er best realisert som eksternt forvaltede kodelister, dette vil si at kodelisten forvaltes utenfor modellen og kan endres levende.

For å oppnå dette må kodelisten merkes som en eksternt forvaltet kodeliste, og den må brukes til å generere kodelistefiler på standardisert format.

Dette gjøres i UML-modellen ved å legge inn to tagged values med navn asDictionary og codeList på kodelisten. Verdiene skal være henholdsvis true og en http-URI til stedet der kodelisten finnes.


to tagged values for kodelister

Skript kan benyttes til å generere eksterne filer på ulike standardformat.

I filen fra SOSI-modellregister finnes skriptet listGMLDICTfraKodeliste som lager ei fil på standardisert GML-Dictionary-format. Høyreklikk på kodelista og kjør skripetet.

I filen fra SOSI-modellregister finnes skriptet listSKOSfraKodeliste som lager ei fil med underkatalog på SKOS/RDF/xml-format. Høyreklikk på kodelista og kjør skripetet.


I modeller som skal benytte eksternt forvaltede kodelister må man lage en egen tom kodeliste med det samme navn som den eksterne.
Denne kodelisten må kun ha tagged value asDictionary = true.

Egenskaper som har eksternt forvaltede kodelister som type skal kobles opp mot denne tomme i din egen modell.
Da vil modellvalidering ikke melde feil om manglende egenskapstype.

Det skal også legges inn en tagged value defaultCodeSpace på egenskapen, med stien til kodelista.


egenskapens sti til kodelista

I ei generert GML 3.2.1 applikasjonsskjemafil vil denne beskrivelsen se slik ut:

Ei GML 3.2.1 datafil vil bruke formen:


Generering av egenskapsverdier fra database utføres likt som interne kodelistekoder, og datafilene vil se like ut.
Validering vil derimot ikke utføres i vanlige XML-editorer og må derfor testes i spesialverktøy som SOSI-kontroll eller Inspire ETF (Esdin Test Facility).

SOSI-kontroll som validerer GML-filer kan lastes ned fra TBD.

Tjenerbasert validering (med ETF) kan kjøres mot nettsted TBD.

Ved modellering av en egenskap som inneholder eksternt forvaltede kommunenummer må det gjøres et valg mellom en spesifikk versjon av lista, eller den til enhver tid gjeldende liste. Den gjeldende lista vil oppdateres sentralt på et planlagt tidspunkt.

Velges spesifikk versjon vil datasettet alltid være gyldig, men kan bli foreldet i forhold til de fleste brukstilfeller.

Velges gjeldende versjon vil datasettet kunne bli ugyldig ved validering mot oppdatert liste, og dataeier må derfor alltid holde datasettet levende oppdatert og følge alle oppdateringer i kodelista.

Det er viktig å kjenne endringsmønsteret og planlegge hvordan endringer i kommuneinndelingen detekteres, og når og hvordan innholdet i datasettet skal oppdateres. Det vil si om det kan kjøres skript i datasettet, eller om full omlasting må gjøres, og presist når dette må skje.


Spesifikk versjon angis ved å la versjonsinformasjonen (2019) ligge med i stien, som vist under:


tagged value defaultCodeSpace = http://skjema.geonorge.no/SOSI/kodeliste/AdmEnheter/2019/Kommunenummer


egenskapens sti til kodelista

Dersom meningen er å holde et datasett levende oppdatert bør stien kun inneholde produktnavnet, som vist under:


tagged value defaultCodeSpace = http://skjema.geonorge.no/SOSI/kodeliste/AdmEnheter/Kommunenummer


Produktspesifikasjoner kan angi at de kun benytter et navnet subsett av geometrityper i den fulle GML 3.2.1 standarden. (I kapittel 11) Dette kan verifiseres ved å validere mot en SOSI-GML-profil som beskrevet i standarden: SOSI del 1 - Realisering i GML-format - versjon 5.0.

Der beskrives profilene:
SOSI-GML-heleid2Dgeometri
SOSI-GML-heleid3Dgeometri
SOSI-GML-delt2Dgeometri
SOSI-GML-delt3Dgeometri

Automatisk validering bør kunne kjøres fra alle vanlige norske valideringsprogrammer for GML-datafiler, men her beskrives en mer manuell metode for validering.

Velg en GML-datafil som skal verifiseres at er i henhold til en bestemt SOSI-GML-profil.
Identifiser hvilken GML-applikasjonsskjemafil som beskriver produktets navnerom. sti til skjemafil som beskriver dataene

Hent ned og lagre en lokal kopi av GML-applikasjonsskjemafila, og modifisér importen av GML til å koble navnerommet med prefiks gml: til en SOSI-GML-profil. sti til skjemafil som beskriver GML-skjema

Til: sti til skjemafil som beskriver en SOSI-GML-profil

Modifisér GML-datafila til å bruke den lokale GML-applikasjonsskjemafila ved å rette i xsi:schemaLocation. (Bør kunne bruke absolutt eller relativ sti.) sti til lokal editert kopi av skjemafil som beskriver dataene

Åpne GML-datafila i en profesjonell XML-editor (oxygen, xmlspy, eclipse, ...) og start validering.
Merk at denne skjemavalideringen ikke også sjekker logikken med at 2D geometrier forholder seg til 2D koordinatreferansesystem, og 3D geometrier krever et 3D koordinatreferansesystem.
Dette må gjøres ved å inspisere GML-datafilas verdier i xml-egenskapen srsName og manuelt sammenligne denne med verdiene i de to listene for 2D- og 3D-koordinatreferansesystemer.

Najonalt anbefalt subsett av koordinatreferansesystemkoder finnes i SOSI del 1 - Realisering i SOSI-format - versjon 5.0.

2D:
EPSG/0/4258 EUREF 89 Geografisk (ETRS 89)
EPSG/0/4326 WGS84 geografisk
EPSG/0/32629 UTM 29 basert på WGS84 (etc.)
EPSG/0/25829 UTM 29 basert på EUREF89 (etc.)
EPSG/0/5105 NTM 5 basert på EUREF89 (etc.)
EPSG/0/3035 EUREF89 LAEA Lambert asimut
EPSG/0/3034 EUREF89 LCC Lambert konisk
EPSG/0/27391 NGO 1948


3D:
EPSG/0/6144 ETRS89 + NN54
EPSG/0/5942 ETRS89 + NN2000
EPSG/0/4937 WGS84 + ellipsoidehøyde
EPSG/0/6169 UTM 29 basert på EUREF89 + NN54 (etc.)
EPSG/0/5973 UTM 29 basert på EUREF89 + NN2000 (etc.)
EPSG/0/6145 NTM 5 basert på EUREF89 + NN54 (etc.)
EPSG/0/5945 NTM 5 basert på EUREF89 + NN2000 (etc.)
EPSG/0/4896 ITRF 2005
EPSG/0/... (Hva med ITRF 2014?)


NB: Mange visningsverktøy for GML-datafiler handterer akserekkefølge og akseenhet korrekt basert på EPSG-koden. Men de har ikke (2018) implementert at akseantall også er en entydig funksjon av EPSG-koden, så det anbefales i tillegg å legge inn srsDimension eksplisitt på 3D-data.