SOSI-forvaltning - logisk modell

Transkript

1 SOSI-forvaltning - logisk modell Forfatter: David Skogan, SINTEF Tele og data Dato: Forord Min oppgave til møte den 22 var å beskrive den logisk modellen med skranker for SOSI-standarden. Jeg skulle prøve å svare på spørsmålet om det er lurt å behandle egenskaper som objekter og videre prøve å beskriv ulike hierarkier mellom objekttyper. I følge modellen som jeg kom fram til er det en vesensforskjell på egenskaper og objekter. Se klassene Objektdefinisjon, Egenskapsdefinisjon og Elementdefinisjon. Objektdefinisjon definerer objekter, mens Elementdefinisjon definerer elementer som kan brukes som egenskaper knyttet til objekter. Det hele kobles sammen med Egenskapsdefinisjon som definerer en egenskap som er knyttet til ett objekt. Først når elementtypen knyttes til objekttypen vil jeg kalle det en egenskap. Dette er altså første utkast som skal diskuteres den 22. januar på NLH. Jeg har forsøkt å begrense antall klasser mest mulig. Mulige utvidelser av dokumentet er: å beskrive operasjoner på de ulike klassene legge mer arbeid i å beskrive skranker (da må vi bli enige om modellen) gi henvisninger til standarden beskrive scenarier m/eksempler 1. Innledning Dette dokumentet beskriver den underliggende logiske modellen i versjon 3.0 av SOSI-standarden. Det er lagt vekt på fange de vesentligste semantiske, syntaktiske og layoutmessige konstruksjoner i SOSI-standarden. I tillegg er styrefilene i KVAKK og utviklingen innen ISO/OGC lagt til grunn. Formålet med arbeidet er å kunne representere og forvalte standarden vha et dataprogram. Noe som vil kunne bidra til å fjerne inkonsistens og gjøre standarden lettere og vedlikeholde og videreutvikle. Modellen er uttrykt i UML (Unified Modeling Language) og kan implementeres en-tilen vha et objekt-orientert programmeringsspråk. For å implementere modellen vha en relasjonsdatabase må det foretas noen avbildninger. Ett problem som ikke er besvart i den logiske modellen er hvordan formatering i beskrivelser og forklarende figurer skal kunne representeres i en database? En løsning kan være å lagre beskrivelser som fritekst, men bruke f eks HTML koder for å angi formatering og referanser til figurer. Figurer må da lagres i en egen tabell. 2. 1

2 Modellen Begrepsdefinisjon subelementer begreper Versjon begreper standardelementer Elementdefinisjon objektkataloger Objektkatalog basiselementer * elementtype grafiskeobjekter objektklasser 1..* Objektdefinisjon verdidomene objektrelasjon representasjonsform egenskaper 1..* Egenskapdefinisjon verdidomene 0..1 Verdidomene * Geometriobjekt geometrirelasjon nødvendige_egenskaper lovlige ikke-lovlige Verdikode 3. Beskrivelse av klassene 3.1 Versjon Dette er det øverste nivået i modellen. Her finner vi et objekt pr. versjon. Versjons objektet holder orden på alle standardelementer, begrepsdefinisjoner, objektkataloger og geometriobjekter som omfattes av denne versjonen. versjonsnr Versjonsnummer. dato Utgivelsesdato standardelementer Liste med referanser til alle standardelementene som brukes i denne versjonen grafiskeobjekter Liste med alle geometriobjektene som er definert i denne versjonen objektkataloger Liste med alle objektkatalogene i denne versjonen. begreper Liste med referanser til alle begreper som er definert i denne versjonen. 2

3 3.2 Geometriobjekt Dette objektet beskriver de mulige geometriske representasjonsobjektene som er lovlige i denne SOSI-versjonen. SOSI skiller mellom to typer: grafiske elementer og grafiske objekter. navn Navn på representasjonsobjektet, eks PUNKT, FLATE,... grafisk-type Tagg som avgjør om dette er et grafisk element eller et grafisk objekt. beskrivelse Nødvendig beskrivelse av objektet koordinater Nærmere beskrivelse av objektets koordinater. Listet opp fortløpende for de viktigste koordinatene eksempel Eksempel på hvordan objektet kodes i SOSI merknad Eventuell merknad elementer En liste med referanser til Elementdefinisjon for å angi hvilke elementer som er nødvendige for å kunne beskrive det geometriske objektet. navn Må være unikt innenfor aktuell Versjon. Layout 5.n Grafisk <grafisk-type>: <navn> beskrivelse 5.n.m elementliste eksempel merknad 3.3 Objektkatalog tittel kortnavn beskrivelse datamodell basiselementer begreper objektklasser Katalogens tittel Kortnavn til bruk i databaser Beskrivelse av formålet og omfanget av objektkatalogen Beskrivelse av datamodell m/figur Liste med referanser til Elementdefinisjoner som benyttes i objekter i denne objektkatalogen. Liste med referanser til Begrepsdefinisjoner som er sentrale for denne objektkatalogen. Liste med referanser til de Objektdefinisjonene som objektkatalogen inneholder. 3

4 tittel og kortnavn må være unike innenfor aktuell Versjon. Layout 1. Historikk og status 1.1. Endringslogg 2. Innledning 2.1. Spesifikasjonen omfatter 2.2. Formål 2.3. Ambisjonsnivå og fremtidige påbygninger 3. Definisjoner og presisering av begreper 4. Datamodell (figur) 4.1. SOSI-basisnavn definisjoner (Elementnavn, beskrivelse, (tabell: definisjon, kodeverdi, forklaring), merknad) 5. Objektbeskrivelse 5.1. Definisjon og presisering av objektklassene (objektklasse, definisjon) 5.2. Kodeliste og detaljeringsgrad for objektene (tabell: objektklasse, grafisk e/o, SOSI-navn, verdi, std/opsjon, merknad) 5.3. SOSI-gruppedefinisjoner (tabell: grafisk e/o, m/egenskaper og kompaktifiseringsregler?) 6. Eksempler (tabell: 3.4 Objektdefinisjon Objekter av denne typen definerer en objekttype. typenavn Objektets typenavn (Brukes i..objtype) beskrivelse Nærmere beskrivelse av objekttypen dimensjon Tagg som angir om objektet bør ha 2D koordinater, 3D objekt koordinater eller valgfritt. Tagg som sier om dette kan representeres som et geometriløst objekt (.OBJEKT). egenskaper En liste med egenskaper som objektet må og kan ha for å være av denne typen. En lovlig egenskap beskrives av forekomster av klassen Egenskapsdefinisjon. representasjonsform Forekomster av denne objekttypen kan realiseres vha null eller flere Geometriobjekter. 1. typenavn må være unik for aktuell versjon. 2. Hvis objekdefinisjonen ikke har relasjoner til Geometriobjekt skal objekt være sann. Objekthierarkier og -relasjoner: Objekttyper innenfor en objektkataloger kan ha ulike relasjoner seg imellom. De eksplisitte relasjonene defineres datamodellen i objektkatalogen og realiseres vha enkelte egenskapene tilhørende de respektive objekttypene. 4

5 I dagens SOSI-standard kan man finne følgende implisitte relasjoner: Subtyping: Man definerer en ny objekttype på bakgrunn av en annen (supertype) ved å legge til en eller flere egenskaper utover de egenskaper supertypen har. Vi sier at supertypen er mer generisk enn subtypen, som er en spesialisering av supertypen. Klassifisering: Man definerer ulike objekttyper på bakgrunn av enkelte egenskapsverdier eller verdiområder. Her antas at antallet egenskaper er det samme. Objekttypen avgjøres ved å sammenligne verdier på enkelte egenskaper. Andre relasjoner som kan være ønskelig å representere er: Gruppering: Man lager mer generelle objekttyper ved å slå sammen (gruppere) ulike objekttyper. Et annet navn på dette er komplekse objekter. Det er mange måter å konstruere hierarkier og relasjoner mellom forskjellige objekttyper. Spørsmålet er om hvor mye av dette som skal eksplisitt angis fra brukerens side. 3.5 Egenskapsdefinisjon En egenskapsdefinisjon definerer en egenskap som tilhører en objektdefinisjon. Det er i dagens SOSI-standard tre ulike typer egenskapsdefinisjoner: standard- / basiselement, objektrelasjon og geometrirelasjon. serienr Nr. som angir anbefalt rekkefølge opsjon Tagg som angir om denne egenskapen er en opsjon eller om den skal være standard. type Tagg som angir om hvilken egenskapstype dette er, elementtype, objektrelasjon eller geometrirelasjon. kompaktifisering Tall som hvis dette er en standard- / basiselement, angir hvilket nivå man bør kompaktifisere på. objektrelasjon Referanse til null eller en objektdefinisjoner geometrirelasjon Referanse til null eller en geometriobjekter elementtype Referanse til null eller en elementdefinisjon verdidomene Mulig verdidomene som begrenser de lovlige verdiene som en elementtype vil kunne ta. NB! Denne overstyrer verdidomenen som er angitt av elementtypen. 1. Kun en av relasjonene objektrelasjon, geometrirelasjon og elementdefinisjon kan referere til et objekt til enhver tid. Spørsmål: 5

6 1. Fra syntaks på side 1-33 kan en <egenskapsdefinisjon> ha <elementnavn> <ikke-verdi> eller <veridintervall> eller <verdiliste>. Gir det mening å bare ha verdiintervall uten elemetnnavn. Hva betyr <ikke-verdi> i denne sammenhengen, det samme som ved en basisdefinisjon? 2. Hva er kardinaliteten på en relasjonsdefinisjon? 3.6 Elementdefinisjon En elementdefinisjon representerer både basis- og gruppedefinisjoner. logisk_navn Logisk navn elementnavn Elementnavnet (forkortet) beskrivelse Beskrivelse av formål og bruksmåte av denne elementtypen gruppe Tagg som angir om dette er et gruppe element eller et basiselement nivå Tall som angir hvilket nivå denne elementdefinisjonen tilhører verditype Tagg som angir hvilken verdi type dette elementet har. Lovlige verdier er: H, D, T, DATO, REF, *, <tom> feltlengde Tall som angir feltlengden hvis verditypen er H, D eller T. (tilsvarer verdistørrelse i syntaksen) konkatenering Tagg som angir om dette elementet kan konkateneres (fjerning av elementer). Kun hvis dette er subelement. kompaktifisering Tall som angir hvilket nivå (relativt fra denne gruppedefinisjonen) som det er hensiktsmessig å kompaktifisere på (utelatelse av elementnavn). eksempel Beskrivelse av eksempel på bruk av elementet. merknad Felt for å angi eventuell merknad til hvordan bruke elementet. subelementer For gruppedefinisjon er dette en liste med elementdefinisjoner som angir neste nivå i gruppen. For basiselementer skal denne listen vær tom. verdidomene Mulig begrensning i verdiområdet til elementtypen av basistype. Verdidomene representerer eventuelle kodeverdier. 1. Alle elementnavn av gruppetype må være unike. 2. Ved konkatenering må alle etterfølgende subelementer også kunne konkateneres. Layout - DEL 1: Kap. 8 Generelle egenskaper overskrift (logisk navn) beskrivelse definisjon (.DEF...) kodeverdier 6

7 eksempel merknad KVAKK syntaks DEFFILER: (samme som definisjon, men hvordan skal det deles opp i filer?) KODEFILER: (bør revideres, på bakgrunn av kodeverdier mhp nye valgmuligheter) Krav ut over Layout og KVAKK Muligheter for å spesifisere lovlige kodeverdier i intervaller, enkeltverdier, utelatelse og kombinasjoner av disse (OG / ELLER / IKKE) 3.7 Verdidomene Et verdidomene inneholder lister over lovlige og ikke lovlige verdier og verdiområder som denne elementtypen kan ta. Dette inkluderer en kodeverdier og forklaringer på de ulike verdiområdene. lovlige ulovlige sjekkverdi Liste med lovlige verdier. Liste med ulovlige verdier. Hvis egenskapen er lik en av de lovlig verdiene og ikke er lik en av de ulovlige verdiene er egenskapen innen verdidomenet. Hvis den er lik en av de ulovlige verdiene er den utenfor verdidomenet. 3.8 Verdikode Her angis ulike verdier med valgfri forklaring på den aktuelle verdien. Det er to typer verdier som kan angis. Enkeltverdi eller intervall. For intervall angivelse er tolkningen fra og til hvor hver av endeverdiene er inkludert. kodeverdi tolkning forklaring til-verdi Her angis en kodeverdi. (For intervallverdier er dette startverdien) Tagg som angir om dette er en enkeltverdi, intervallverdi, større-enn eller mindre-enn angivelse. Felt for å angi forklaring på kodeverdien eller intervallet. Hvis intervall er sann angir denne verdien til verdien i intervallet. 7

8 3.9 Begrepsdefinisjon Her defineres de sentrale begrepene i SOSI-standarden. term definisjon synonymer eksempel Selve termen Selve definisjon Liste med mulige synonymer Beskrivende tekst for å forklare definisjonen 8