Veiledere i utvikling og bruk av standarder

En produktspesifikasjon som både følger standarden for SOSI produktspesifikasjoner, og styrende dokument for standardisering med kvalitetssikring gjennom en åpen konsensusprosess.

SOSI Standarden for produktspesifikasjoner setter krav til struktur og innhold, og til godkjenning. Den skal følge en fast disposisjon, og inneholde faste elementer som identifikator, ansvarlig, temakategori o.l. Den skal også inneholde kvalitetskrav, geografisk utstrekning, formatrealiseringer og nødvendige metadata. Kartverket skal godkjenne alle SOSI produktspesifikasjoner. Dette er beskrevet i dokumentet https://register.geonorge.no/standarder/sosi/del-1-generell-del/sosi-produktspesifikasjoner-krav-og-godkjenning

Støtteverktøy finnes på stien https://www.geonorge.no/verktoy/verktoy-for-produktspesifikasjon/

SOSI standarder utvikles etter klare prosessprinsipper. Enhver part eller person i geomatikkmiljøet kan sende inn prosjektforslag til standardiseringssekretariatet. Etter kvalitetssikering av forslaget sendes dette til standardiseringskomiteen for geomatikk (SKG) for klarsignal. Det etableres et prosjekt med åpen invitasjon til deltakelse, samt at nøkkeletater vil bli bedt om å delta. Når prosjektet er enige om at de har et ferdig utkast sendes dette ut for åpen høring, vanligvis i fire uker. Etter avsluttet høring innarbeider prosjektet kommentarene i utkastet, og kvalitetssikrer innholdet. Til slutt sendes det ferdige utkastet SKG for godkjenning. Standardiseringssekretariatet publiserer den godkjente standarden og merker tidligere versjon som erstattet.

Dette er beskrevet i dokumentet https://www.geonorge.no/globalassets/geonorge2/standardisering/dokumenter/styrende-dokument---prosess-for-utvikling-av-nasjonale-bransjestandarder-geografisk-informasjon.pdf og ytterligere i prosessmodellen https://sosi.geonorge.no/temp/prosesser/

Forrige versjon av denne veilederen fra 2021-07-09

Dette er en variant av løypa for å lage informasjonsmodellen i en SOSI-produktspesifikasjon som et utplukk av objekttyper fra fagområdene i SOSI del 2. https://sosi.geonorge.no/veiledere/Veileder_i_å_modellere_produktspesifikasjon_som_utplukk_fra_SOSI_fagområder.pdf

Se https://sosi.geonorge.no/veiledere/UML/

Dette er ei 29-punkts løype for å lage informasjonsmodellen i en SOSI-produktspesifikasjon basert på fagområdestandarder.

https://sosi.geonorge.no/veiledere/Veileder_i_å_modellere_produktspesifikasjon_som_utplukk_fra_SOSI_fagområder.pdf

Utkast til en mer moderne variant, der flere produktspesifikasjoner bygger på hverandre:

Tradisjonell modellering av produkt er med kun et applikasjonsskjema med et felles applikasjonsskjema for alle brukstilfeller
Denne løypa er godt innarbeidet i infrastrukturen og dekker godt brukstilfeller som har fokus på leveranser av forvaltningsdata.
Dette dekker oftest også alle enklere brukstilfeller, om enn med å måtte få en del unødvendige data med på lasset.

Se https://sosi.geonorge.no/veiledere/installasjonsveileder/

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.

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.

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.

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.

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.

<img src="img/defaultCodeSpace.png" alt="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:

<kommunenummer>0101</kommunenummer>

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

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:

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.

Til:

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

2D:

3D:

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.

<gml:Curve srsName="http://www.opengis.net/def/crs/epsg/0/6173" srsDimension="3">

I GML (som i XML) er det krav på å følge samme rekkefølgen på elementene som de som er beskrevet i GML-Applikasjonsskjemafila (.XSD). Rekkefølgen på egenskaper kontrolleres i Enterprise Architect, husk å ta vekk alfabetisk sortering under Start→Preferences→Objects. Rekkefølgen på assosiasjonsroller kan kontrolleres ved å legge inn en tagged value med navn sequenceNumber på alle assosiasjonsrollene og gi disse unike serienummer.

Der en geografisk 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. Noen åpen-kildekode-systemer (deegree) forventer at denne taggen er satt eksplisitt så det anbefales da å sette den til byReference.

Grensesnittstandarden WFS (ogc.org/standards/wfs) gir føringer for hvordan man via en parameter i et spørregrensesnitt kan styre i detalj hva responsen skal inneholde. Dersom parameteren resolveDepth er satt til 0 skal lenker til assosierte objekter være fulle url-er til de refererte objektene. Dersom parameteren er satt til 1 skal tjenesten nøste ned en gang (o.s.v.), da skal tjenesten også legge inn de assosierte objektene i returen, og endre lenkene til lokale pekere (#). Forøvrig må man ved lesing av GML-filer ta høyde for at full GML åpner for at for to objekter av samme objekttype i samme datasett kan det ene objektet legges inn inline mens det andre objektet kan refereres.

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.

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

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

Eksempel på datasett i GML-format med naboflater og enklaver: http://skjema.geonorge.no/SOSITEST/produktspesifikasjon/Kommunefusjon5/2019/eksempel/KlasseMgeometriegenskaper3.gml

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-

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. image::img/Topologiegenskaper.png 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-

Eksisterende klasser kan gjerne bytte til SOSI-UML-Profil-5.1, men da må tagged values kontrolleres.

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 standardiserte UML-profiler, 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 mer framtidsretta løsning er å bytte til stereotyper fra en 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 beskrives i 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 der. 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 kunne miste noen eksisterende verdier i de beskrevne tagged values !!! Vi må derfor alltid ha god kontroll på verdiene i de beskrevne standardiserte tagged values.

"GML" som kommer med EA "native" - denne har noen viktige begrensninger og dekker IKKE norske behov og standarder (underpakker behandles ikke 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).