Project

General

Profile

Innmeldte kommentarer #1052

Innspill til standardiseringsarbeidet SOSI ledning 5.0 fra Tore Paulsen

Added by Nils Egil Søvde about 6 years ago. Updated about 6 years ago.

Status:
I prosess
Priority:
Normal
Assignee:
-
Start date:
2015-08-10
Due date:
Standard:
SOSI standard Ledningsnett
Kontaktperson:
Tore Paulsen
Bedrift, etat, virksomhet:
Norconsult Informasjonssystemer AS
E-mail kontaktperson:
Paulsen Tore
Utdyping av beskrivelse:
Ansvarlig arbeidsgruppe:
SOSI AG7b
Type melding:
Innspill
Beslutning:

Description

3D

Jeg tror vi bør satse på en todelt modell for å beskrive objektene i 3D.

En forenklet modell der tverrsnitt/grunnplan i et objekt beskrives av noen få geometriske objekter (sirkel, oval, trekant, firkant og kanskje 5-kant, 6-kant og trapes). Utstrekning i den tredje dimensjonen kan defineres som en 3D Linje eller forenklet som lengde/høyde med retning). For kompliserte objekter vil denne beskrivelsen kunne gi en omsluttende boks/sylinder. Kanskje kan denne utvises med to flater for å kunne beskrive en avkortet pyramide eller kjegle. Denne vil dekke mye av behovet og være enkel å legge inn data for av brukerne. I mange tilfeller kan beskrivelsen lages automatisk ut fra eksisterende egenskaper.

En full modell med komplett 3D beskrivelse av hele objektet. Her må vi benytte et eller flere kjente overførings formater fra DAK-verdenen for å beskrive objektene, og beskrivelsen bør ligge som et vedlegg til SOSI-filen, ikke i selve filen. SOSI-filen må inneholde bare referansen til filen som beskriver objektet.
Begge modellene kan forekomme i samme SOSI-fil.

For ledninger vil de aller fleste behov dekkes av den forenklede varianten. For punktobjektene er det mer komplisert, men en omsluttende boks/sylinder mm vil i alle fall kunne være nok til å avsløre kollisjoner med objekter fra andre disipliner.
Vi har for øvrig en utfordring med hvordan vi skal beskrive en 3D linje. Denne kan beskrives med separat horisontal og vertikal kurvatur som for veg. Alternativet er å beskrive den som en romlig kurve, noe som gjerne er mer komplisert både og beskrive og bruke. En tredje variant er å beskrive den horisontale kurvaturen, samt høyder i alle knekkpunkter og kanskje også for f.eks. gitte intervaller. Noen forenklinger kan vel også være aktuelle, et eksempel: Vertikalkurvaturen for et luftspenn er vel strengt tatt en parabel, men det er vel en så liten del av parabelen som brukes at den kan forenkles til en sirkelbue uten særlig tap av nøyaktighet.

Egenskaper og kodelister.

Vi bør bruke en del tid på å komplettere egenskaper og kodelister. Det er en god del som mangler her. Fagmiljøene må her være aktivt med for å komme med innspill over det de mener mangler.

Dynamiske kodelister må vi få til så snart som mulig. Jeg vil tro det riktige er å lage et sentralt register for slike felles kodelister, og et regime for vedlikehold og godkjenning av innholdet.

Vi bør også diskutere en mulighet for dynamiske egenskaper. Det vil alltid være behov for å kunne legge inn nye egenskaper som ikke er definert fra før. Det bør være mulig å få til en mekanisme her der slike egenskaper kan defineres og f.eks. har en form for midlertidig status inntil de eventuelt går inn i standarden. I noen tilfeller kan det også være behov for midlertidige egenskaper til bruk for en kortere periode. Disse skal kanskje ikke brukes av mere enn noen få, eller kanskje kun for en enkel jobb. Mekanismen for å definere slike bør imidlertid være felles.

Definisjoner

Det bør være en selvfølge at alle objekttyper, alle egenskaper og alle kodelister må ha klare definisjoner. Definisjoner kan eventuelt sløyfes der kodelistene er åpenbart selvforklarende.

Nye komponenttyper (objekttyper)

I noen tilfeller krever disse at det defineres en ny objekttype. I andre tilfeller kan en utvidelse av kodelistene dekke behovet. Vi bør ikke ukritisk legge inn nye komponenttyper for alt nytt, men heller ikke gjøre eksisterende komponenttyper unødvendig kompliserte for å dekke nye behov. Her må det derfor alltid en avveining til.

Kontainer og prosessenhet.

Vi må kvitte oss med tilfeller der samme navn brukes på både kontainer og prosessenhet. (Kum, Overløp mm). Det må gå fint å definere egne navn som skiller disse.

Driftshendelser

Enig med Roy Johansen i at vi må få en standard for overføring av driftshendelser. Det kan imidlertid være store forskjeller på hva som lagres i FDV-systemene (og/eller forenklede tilnærminger til disse), så det kan nok bli en del jobb å lage en komplett utveksling av slike data. Men det går i alle fall an å starte for å få med det mest vesentlige.
Et tilgrensende område er dokumenter knyttet mot ledningsobjektene (Tegninger, bilder, beskrivelse osv.) . En sak er selve referansen til dokumentet, men her hører gjerne en del egenskaper i tilknytning til dokumentet med.

SOSI Ag7a og SOSI Ag7b

Det er fortsatt slik at disse områdene (Ledning og veg/jernbane) har mye til felles:
Jeg mener vi bør jobbe for at den grunnleggende datamodellen for Vegnett og Ledning er mest mulig lik. Hvordan kan vi få til dette?

History

#1 Updated by Tore Johnsen about 6 years ago

  • E-mail kontaktperson changed from Paulsen Tore <Tore.Paulsen@norconsult.com> to Paulsen Tore

Also available in: Atom PDF