Veiledere i bruk av standarder

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.


Nyeste versjon av installasjonsveilederen

.

Denne veilederen beskriver de vanligste UML-modellelementene som brukes i SOSI-standarder og SOSI-produktspesifikasjoner.


Veileder i å lese UML-modeller

.

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

Og utkast til en variant:


Veileder_i_å_revidere_produktspesifikasjon

.

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.

Der en objekttype (FeatureType) har en navigerbar assosiasjon til en annen objekttype skal den navigerbare assosiasjonsenden ha en tagged value inLineOrByReference med verdien byReference.

Tagged value inLineOrByReference er beskrevet i standarden regler for UML-modellering versjon 5.1 kapittel 13, og bruken av verdien byReference er for GML beskrevet (noe indirekte) i standarden Realisering i GML-format versjon 5.0 kapittel 7.2.

Hvis tagged value inLineOrByReference ikke er lagt inn sier standarden iso19136-1 (GML) kapitter E.2.4.11 at default encoding skal brukes.

Forøvrig åpner GML for at for to objekter av samme objekttype i samme datasett kan det ene legges inn inline mens det andre kan refereres.

tl;dr - Nye klasser bør lages med EA Toolbox og SOSI-UML-Profil-5.1. Eksisterende klasser kan gjerne bytte til SOSI-UML-Profil-5.1, men da må tagged values kontrolleres.

Lengre forklaring:

Alle klasser skal ha standardiserte stereotyper, og alle modellelementer kan ha et sett med standardiserte tagged values.

Fra tidligere tider har stereotype vært en enkel tekststreng på modellelementene, og modellelementene har eid sitt eget sett av tagged values. Dette gjelder for eksempel for klasser med tekstlig stereotype «featureType».

I en periode har modellelementer også kunnet bruke stereotyper fra en standardisert UML-profil, som for eksempel stereotypen «FeatureType» fra UML-profilen "SOSI-UML-Profil-5.0". Stereotypene i denne profilen eier ingen tagged values.

Dersom man kun vil ha den anbefalte skrivemåten på stereotypene på gamle klasser uten profil kan man bytte til UML-profil "SOSI-UML-Profil-5.0" uten å endre at alle tagged values er eid av klassene.

Denne profilen kan ikke brukes via EA 15 sin Toolbox, så endringen må legges inn manuelt (under Properties -> Tags).

Disse gamle metodene kan fortsatt videreføres som de er i EA 15, og det kan fortsatt legges til nye tagged values rett på modellelementene.

-

En med framtidsretta løsning er å bytte til stereotyper fra en mer moderne UML-profil. Hvis man bytter fra gamle modeller vil standardiserte tagged values overføres fra klassen til å bli eid av stereotypen.

Den nyeste UML-standarden (ISO 19505:2012) har som hovedbeskrivelse at stereotyper skal tilhøre UML-profiler, og stereotypene skal eie settet med tagged values.

Nyere versjoner av Enterprise Architect (EA 14/EA 15) har tatt dette til følge mer og mer, og man kan for eksempel ikke lenger skrive inn et stereotypenavn som tekststreng.

Vi har dessverre observert at når vi bytter fra en slik stereotype i en UML-profil til en stereotype fra en annen UML-profil vil vi miste eksisterende verdier i de beskrevne tagged values !!!

Vi må derfor alltid ha god kontroll på verdiene i de beskrevne standardiserte tagged values.

Vi har i dag tre moderne UML-profiler:

"GML" som kommer med EA "native" - denne har noen viktige begrensninger og dekker IKKE norske behov og standarder (behandler ikke underpakker etc.). Vi anbefaler derfor å "disable MDG-technology GML" slik at denne ikke vises.

"SOSI" er en UML-profil som kommer med SOSI-plugginn og er i hovedsak utviklet for å følge reglene i SOSI 4.0. Den har en blanding der noen tagger eies av stereotyper og noen eies av klassene, og den dekker fortsatt norske behov.

"SOSI-UML-profil-5.1" som kommer med SOSI-Verktøykasse 1.0 og er en realisering av profilen i standarden Regler for UML-modellering versjon 5.1. Den dekker norske behov.

Vi anbefaler nå at hvis man bytter til andre UML-profiler må man klarlegge hvordan dette kan gjøres uten å miste informasjon. Alle de beskrevne variantene har til nå fungert likt i alle eksisterende MDA-løyper (som ShapeChange etc.).

Det er også ofte vanskelig å se tagger fra stereotyper som kommer fra eldre uml-profiler (for eksempel uml-profil SOSI). Disse taggene kan vises ved å velge elementet, høyreklikke på Properties og så velge Properties…. Da vil en i vinduet som kommer opp kunne se flipper helt til høyre som kan vise resten av elementets tagged values.

Andre konfigurasjoner som påvirker hvilke tagger man ser er å enable/disable under menyene Specialize: Manage-Tech (for MDG) og Manage-Addin (for Addins).

Brukstilfellene vil indikere hvilken type geometri som er nødvendig, enklest mulig geometritype bør alltid velges.

Tidligere ble norske klassenavn benyttet i modellene, Punkt, Kurve, Flate og Sverm. Dette er fortsatt støttet, og disse skal automatisk mappes til moderne og realiserbare typer.

Eksempel på klasser med nasjonal og internasjonal geometritype:

Modell som viser forholdet mellom eldre nasjonale geometrityper og geometrityper i internasjonale standarder:

Det anbefales nå å modellere med de moderne internasjonale typene direkte. De vanligste av disse er GM_Point, GM_Curve, GM_Surface og GM_Solid.

Her er listene over geometrityper i geometriprofilen SOSI-GML-delt3Dgeometri:

Listene over geometrityper i geometriprofilen SOSI-GML-heleid3Dgeometri er like, bortsett fra at klassene med GM_CompositeXxx mangler.

Eksempel på modell med bruk av internasjonale geometrityper:

Eksempelfigur med naboflater og enklaver

Eksempel på datasett med naboflater og enklaver:

KlasseMgeometriegenskaper3.gml GML-eksempelfil med naboflater og enklaver

Modellering av egenskaper med heterogene geometrityper

Egenskaper med geometri som kan være enten punkt, kurve, flate eller legeme kan modelleres med typen GM_Object. Dette vil generere GML_Applikasjonsskjema som tillater gml:Point, gml_Curve og gml:Surface (og gml:Solid). OGC Simple Feature støtter dette, og Oracle, PostGIS og QGIS kan handtere slike heterogene geometriegenskaper. TBD:-diagram--eksempelfigur--eksempelfigur-

Modellering og utveksling av objekters topologiske egenskaper gjøres i henhold til aktuelle standarder.

Dersom brukstilfellene krever utveksling av topologiegenskaper må UML-modellen angi dette eksplisitt. Denne modelleringen er beskrevet i Regler for UML-modellering versjon 5 i kapittel 11.4.3.4 Topologi. Realisering er beskrevet i standarden Realisering i GML-format versjon 5 i kapittel 8.5 Realisering av toplologi.

Nettverkstopologi kan alternativt modelleres som topologiske assosiasjoner i applikasjonsskjemaet. (Ledning, vegnett.)

TBD:-diagram

Modeller bør uansett beskrive topologiske restriksjoner som krav om full flatedekkning innen et område, eller krav om ingen overlapp mellom objekter.

TBD:-diagram--eksempelfigur-

Den vanligste praksis er at data modelleres og utveksles med heleide geometriegenskaper, og at topologien bygges opp i mottakersystemet i etterkant. Oppbygging av topologistrukturer på mottakersiden er en omfattende prosess, spesielt med data fra flere kilder, med behov for identifisering av overlappende kurver og naboflater etc.

TBD:-diagram--eksempelfigur-

Delt geometri er der en geometri kan beskrives i et objekt, og deles/refereres fra andre objekter. Bruk av dette kan ved spesielt nøye bruk unngå noen vanlige effekter som glipper og overlapp, spesielt ved avrunding av koordinater. Dette gjøre at data med delt geometri vil kunne være mer topologiklare for mottakeren. Men mottakerens topologioppbygging må ta høyde for at den delte geometrien også kan være bygget opp på en ikke-topologiklar måte. Delt geometri må modelleres spesielt i UML, med geometriklasser av typen "Composite", for å kunne arve mekanismen med pekere til andre geometrier.

TBD:-diagram--eksempelfigur--eksempelfigur-

Normalisert geometri betyr at hver posisjon beskrives kun en gang, og at det kun refereres til fra andre geometrier av høyere orden. Mottakeren må da bygget opp fullstendig geometri for hvert objekt. I SOSI-format og gml (og geojson?) er det ikke vanlig praksis å referere til endepunkter på kurver, men geometrityper av typen "Composite" kan benyttes til å angi at man kan/skal bruke pekere til andre geometrier av lavere orden.

TBD:-diagram--eksempelfigur--eksempelfigur-