Aksjonsliste SOSI Ledning Versjon

Transkript

1 Aksjonsliste SOSI Ledning Versjon Status pr 30.januar 2013: Løst opp i enda et par aksjons-punkt, forbedret noen andre, se merknader for hvert enkelt aksjonspunkt det er gjort noe med. Status pr 19.januar 2013: Aksjoner som ikke er gjort noe med ennå, delvis for det er uklart hva som skal gjøres, og delvis fordi det trengs input fra andre: - 1: Generell kommentar om enheter, spesielt på lengde. Ingen massiv-gjennomgang gjort, men retta opp noen funn. - 2: Generell kodleiste-gjennomgang. Forbedra noe. - 34: VA_ Renseanlegg / : OK - 36: VA_Pumpestasjon / : Ikke avklart - 45: Prosesstyper: Ufullstendig modell. / : OK - 67 og 68: Ufullstendig modell på EL_Skjøt og EL_Tamp / : Ingen forslag mottatt. Alle de andre noen-og-sytti har fått en aksjon (dvs er løst)!! Uklarheter som er kommet inn som følge av aksjonene: - Masterkonstruksjons-typer fra Jernbaneverket trenger forklaringer - Håvard - Åktyper for kontaktledningsåk (igjen Jernbaneverket) trenger forklaringer - Håvard : Har fått innspill fra Roy Johansen. Disse er lagt inn, men er usikker på hvor mye av forslagene/utsagnene som kan bli tatt hensyn til så sent i prosessen Det som er kommet fra Roy er merket mørk grått. På slutten av lista er det også tatt inn innspill som er kommet etter at aksjonslista ble lukket. Må finne ut hva vi gjør med disse.

2 Liste som viser hva som må gjennomgås nærmere i stuttredigeringen av SOSI Ledning Sidehenvisning og kapittelnummerering er til dokumentet SOSI Ledning 4.5 datert Tatt hensyn til innspill i Sak 5: Presentasjon av Rene Astad Dupont Sak 6: Presentasjon Roy Johansen Sak 7: Presentasjon Tore Paulsen Sak 8: Presentasjon Håvard Moe Sak 9: Presentasjon Geir Myhr Øien Sak 10: Presentasjon av Vilhelm Børnes Tore Paulsens kommentarer i blå og turkis bakgrunn Også tatt inn kommentarer fra Geir Myhr Øien Fargeforklaring for tabellen under: Grå bakgrunn (som denne) Hvit bakgrunn (som denne) Gul tekst (som denne) Ordnet i UML-modellen Ikke lagt inn i UML-modellen ennå. Noe må avklares. Nr Side Kap Kommentar (begrunnelse for endring) Endringsforslag Kommentar Tiltak 1 0 gen Det er angitt meter som enhet for mange attributter, på tross av at det er millimeter som er fagbetegnelsen. 2 0 gen Det er mange kodelister som trengs å gjennomgås, for å kontrollere at de inneholder det de burde for å kontrollere at de passe rmed resten av Det brukes meter alle steder der lengder skal angis. Det er meter som er SI-enheten. Det brukes samtidig Real som datatype. Det vil åpne muligheten for at en kan angi desimaler, og dermed ha millimeter som presisjon. Alle kodelistene må betraktes som utvidbare. Det vil si at det er muligheter for å legge til nye verdier etter hvert som nye alternativer Dette er en av de mer omfattende og tunge jobbene! Kontrollere at det er brukt meter konsekvent på alle lengde-verdier Gå gjennom alle kodelistene, og finne ut hvilke som

3 modellen dukker opp. overlapper. Det er derfor viktig at alle kodelistene har et klart formål, slik at det er enkelt å avgjøre hva slags kodeverdier som passer inn i hver an dem Dette er to måter å si det samme på, de innholder parvis like attributter: Produsentnavn = fabrikat Produsentkode = type Produktnavn = typebetegnelse Foreslår å kalle den nye Ledn_Produsent, med fire attributter: produsentnavn produktkode produktnavn produsertår Den nye datatypen legges til på Nettverkskomponent i kjernemodellen : Tror det gir bedre mening å kalle dette Typebetegnelse. Det peker mer på produktet og typen, og ikke på produsenten. Definere ny datatype: Ledn_Typebetegnelse, med attributtene: - Produsentnavn - Produsentkode - Produktnavn - ProdusertÅr Bruke denne i stedet for de to andre. Tatt bort - Typebetegnlese på EL_Mast - Typebetegnelse og fabrikat på EL_Kum - Typebetegnlese og frabrikat på EL_Kabelskap - Typebetegnelse på EL_Trekkerør - Typebetegnelse på ELlektrisitetsLedni ng - Typebetegnelse

4 på EL_Node - Tror dette bør dekke behovet /EO/SH/IH: Endret navnet på attributten og datatypen Ingen forandringer. Note fjernet driftsmerking bør flyttes opp på Nettverkskomponent og fjernes på alle subtyper både for punkter og ledning Lagt til i Nettverkskomponent. Fjernet fra: - ElektrisitetsLedning - EL_node - EL_Kum - EL_Kabelskap - EL_Mast - EL_Trekkerør - EL_Transformator

5 Forhold til bygningsmessige anlegg Kan komponentkode brukes for å knytte nettverksstasjoner i lednings-fagområdet til registreringen av bygningen i fagområdet bygg? Må i tilfelle Matrikke-bygnings-identen inn som eget kodesystem i kodelista Komponentkodesystem? Oppdatert Matrikkel til Matrikkel_Bygningsnum mer i Komponentkodesystem /EO/SH/IH: Lagt inn ny kode for BIM. Laget bedre attributtnavn/datatypen avn (referanse) Fra GMØ: Burde Matrikkel_Adresse vært lagt inn som komponent, da en bygning kan ha flere tilknytningspunkt/abo nnenter (for eksempel rekkehus/leilighetsko mplekser og lignende EO: Tar ikke dette inn nå!

6 Indre og ytre diameter passer på mange ledninger. Med å gjøre de frivillige med multiplisitet (0..1), vil de kunne velges bort der de ikke passer inn. Ingen tiltak, Note fjernet. Indre og ytre diameter beholdes som attributter på Ledning Det finnes vel ennå noen coax-ledninger som utgjør rene kabel-tv-nett. For slike er det kanskje ok å ha valg KabelTV. For nyere anlegg, som har ledninger som kan brukes til flere formål, er vel Telekommunikasjon et mer dekkende uttrykk. Men her er det ei kodeliste for fagområde. Fagområdet heter vel kanskje Telekommunikasjon, mens Nettverkstypen kan være KableTV, der lednings-typen tilsier at det kun er kabeltv-signal som formidles. Fra Roy Johansen : Kan ikke coax brukes til mer enn KabelTV? Jeg vil tro at veldig mye KabelTV-kabler inn til /EO: Har lagt til nye koder for Fagområde: -Fjernvarme/kjøling -ekom Sortert litt på rekkefølgen i kodelista, tatt bort en rød note. Tror det er ok å ha inn begreper her som de ulike fagmiljøene kan identifisere seg med. Derfor er det med tre tele - varianter (ekom,

7 boliger fremdeles er coax, og at en både kan få Internett og telefon gjennom disse. Jeg syns uansett at det høres greit ut at dette området dekkes av fagområdet Telekomunikasjon. I kommentarene til dette punktet refereres det til lednings-typen. Hvis det menes egenskapen Ledningstype, så er denne vedtatt fjernet. Men kodelisten ligger fremdeles og flyter et sted. Tanken er, så vidt jeg har forstått det, at vi skal ha den i mente for å se om vi glemmer noe som skal inn i andre lister, men den forvirrer jo. Det refereres også til Nettverkstypen. Det er vel egenskapen Ledningsnettverksbruk det menes? Telekommunikasjon og kabeltv) LedningHøydereferanse for koplinger er ikke tilstrekkelig dekket. Fra Roy Johansen : Er det hensiktsmessig at kodelisten for LedningHøydereferanse også dekker koplinger? Vil da «ToppUtvendig» dekke det tilfellet for kummer at det er senter kumlokk som er målt inn? En annen sak er at for et koplingsobjekt er det ikke bare hvor høyden er målt, som er interessant, men også hvor X og Y er målt. En bør ha en egen egenskap på Kopling som f.eks. heter KoplingPosisjonsreferanse. Her kan vi ha egenskapene «SenterKumlokk» og «SenterBunnInnvendig», som vil være relevante for kummer. Fra GMØ: Her bør følgende koder legges til: PåBakken (Mange ledninger er målt på lukket grøft) Topp Fot (naturlig å bruke for eksempel på master/mas tefundamen ter) Tatt inn PåBakken og Fot. Topp bør være dekket med det to eksistende ToppInnvendig og ToppUtvendig.

8 Det er bruk for flere lengder Lengde i kart Lengde_kart Virkelig/målt lengde Lengde_virkelig Ligger ikke i rett linje i grøft Stolpe opp/ned Høydeforskjeller : Foreslår å lage en datatype Ledn_Lengde med attributtene: - lengde (i meter) - lengdetype, med kodeverdiene: o o kartlengde (2D) fysisk lengde (ledningslengde som må rulles ut dersom ledningen skal byttes. Fra Roy Johansen : Enig i forslaget om datatypen Ledn_Lengde. Diskuteres med Steinar 16/17.januar. lengde : [0..*] da formodentlig. Foreslår kartlengde (3D) i tillegg fra GMØ: God forslag, men Lengde-kart er kanskje ikke nødvendig da dette kan avledes av objektets utstrekning/koordinat er /EO: Lagt inn datatype med kodeliste for ledningslengdetype Holder på en egen LedningsHøydereferan se. Ingen tiltak.

9 Ledn_Vertikalnivå beskriver hvor objektet befinner seg. Navnet beskriver dette greit. Navnet Medium er ikke så lett å koble til vertikal plassering. I tillegg er dette ei noe rotete kodeliste som vi ikke bør bruke. Ledn_Vertikalnivå brukes Ingen tiltak. Note fjernet

10 TRødb: Burde det under kodelisten for ledningstype, også vært en VA-type for avløpsledning? Eller kan man begrense denne listen til kun å ha betegnelsen Ledning Bruken dekkes vel i kodelisten for ledningsbruksområde Hva dekker betegnelsen Trykkrør? er det generelt for pumpeledninger eller er det en annen betegnelse på vannledning? Hvorfor står drensledning her? Dekkes dette ikke i kodelisten for ledningsbruksområde Fra Roy Johansen : Kodelisten for LedningsBruksområde stammer fra SOSI 4.0. Den eneste objekttypen som har denne som egenskap, er Framføringsvei. Dette virker litt rart. Objekttype Framføringsnode, derimot, har egenskapen FramføringsnodeBruk. I stil med dette bør vel Framføringsvei har en egenskap som heter FramføringsveiBruk. Avklares sammen med kodelistegjennomgangen! Flytta det som trengs ove ri kodeliste Ledningsnettverkstype. Fjerna kodelistene Ledningstype og Ledningsbruksområde. Fjerna en rød note.

11 Ledningstype Her ligger Høyspentledning, men ikke Lavspentledning under El. Lavspentledning må inn her. Under Tele ligger Fiberkabel og Signalkabel. Det er jo blanding av funksjon og materiale. Alt er vel signalkabel? Avklares sammen med kodelistegjennomgangen! Mye av dette er nå dekka bedre av flere egenskaper. Har tatt inn noe på Ledningsnettverkstype, og deretter fjerna lista (finnes selvsagt ennå i den gamle SOSI Ledning 4.0) Fra Roy Johansen : Kodelisten for Ledningstype skal ikke være med lenger. Egenskapen Ledningstype er fjernet, i hvertfall på VA. Innholdet i listen er ivaretatt av andre egenskaper. (gjelder også 13) Belysningspunkt-plassering: Endre til Punktplassering (felles for belysning og signal) Utført

12 Det mangler noder i framførings-nettet? Det er likevel definert opp trasenode. Trengs også grøftenode for å kunne markere det grøfter og kanaler møtes? Skal det være topologi i grøftenettet trengs noder, siden det ikke er mulig å kode at to grøfter møtes (grøfter kan starte og ende i koplinger, og dersom flere grøfter ender i samme kopling, henger grøftene sammen) Fra Roy Johansen : Jeg er enig i at Trasenode kan brukes der vi ikke har noe fysiske objekt i noden. Til kommentaren fra Tore: Siden Framføringsnode er en abstrakt objekttype, kan ikke denne instansieres som et eget objekt. Det fins imidlertid noen framføringsobjekter vi ikke har med. Det er vel noe som heter Kabelbrønn, eller bare Brønn, som kan være node i et nett med kanaler eller trekkerør? Vi har jo også Trekkekum. Den sistnevnte kan jo dekkes ved å utvide listen for Kumtyper. Diskuteres med Steinar 16/17.jan :Trasenoden er den generelle noden for alle slags framføringsveier, trenger ikke flere Skal det være et trasenode nettverk må det være en node i endene av både grøft og andre fremføringsveier. Det vil jo ofte være en virtuell node da det ikke er noe fysisk objekt der. Kan man ikke bare bruke Framføringsnode uten subtyping? Og så definere en kode for dette i FramføringsnodeBruk? : Justert forklaringen til Trasenode slik at den blir en generell node for alle framføringsveier.

13 Note fjernet, bør ikke være noe problem å skille disse to Trenger vi dimensjon for kanal? Vi har både indre og ytre bredde/høyde. Menes det noe annet her? Fjernet attributt dimensjon. Fra Roy Johansen : Kanaler kan være støpte konstruksjoner for framføring av forskjellige typer ledninger. I et tverrsnitt vil vi se rader med hull i en eller flere etasjer. Det kan være ønskelig å ha egenskapene AntallRader Hull og AntallKolonnerHull (egenskapsnavnene kan diskuteres). Hvis vi vil gjøre det enklere, kan vi ha f.eks. AntalllHullIKanal. Forslaget antalltrekkerørarmatur skjønner jeg ikke, men det har antakelig noe med lampearmatur å gjøre, som jeg ikke har noe greie på.

14 Trekkerør kanaler med trekkerør Angi antall for å forenkle (lampearmatur, trekkerør) Fra Roy Johansen : Kanaler kan være støpte konstruksjoner for framføring av forskjellige typer ledninger. I et tverrsnitt vil vi se rader med hull i en eller flere etasjer. Det kan være ønskelig å ha egenskapene AntallRader Hull og AntallKolonnerHull (egenskapsnavnene kan diskuteres). Hvis vi vil gjøre det enklere, kan vi ha f.eks. AntalllHullIKanal. Forslaget antalltrekkerørarmatur skjønner jeg ikke, men det har antakelig noe med lampearmatur å gjøre, som jeg ikke har noe greie på. Lagt til antalltrekkerøriarmat ur på Kanal : Skal være antalltrekkerørikanal Ikke gjort noe med lampearmatur ingen tiltak. Note fjernet.

15 Kontaktledningsåk er registert som Mast i 4.5, men som kurve i 4.0 Hva bør benyttes? Åk er betegnelse på master som har et bein på hver side av en veg eller en bane. Registreres som linjeobjekter i FKB. Er dette subtyper av mast; eller er det sidestilt med mast? Fra Håvard Moe, jernbaneverket ( ) Laget ny objekttype Åk, med definisjon og attributter som foreslått av Håvard. Fjernet kode Kontaktledningsåk i kodeliste Mastekonstruksjon. Langt til ny kodeliste Åktype. Denne må suppleres med forklaringer på JBVkodene. Punkt 21 - Kontaktledningsåk I SOSI 4.0 hadde vi åk både som koplingstype (punktobjekt) og som linjeobjekt. Punktobjektet er bruka som node i ledningsnettverk, linjeobjektet for å beskrive geometrien av anlegget. For å presisere i høve til tekst i tiltakslista der det står: "Åk er betegnelse på "master" som har et bein på hver side av en veg eller

16 en bane". Åket er den horisontale delen og går mellom to master, dvs. at "beina" er egne masteobjekt, ikkje ein del av åket. Eg ser i grunnen for meg åk som ein objekttype Kontaktledningsåk sidestilt med mast. Følgjande eigenskapar: - geometri: Kurve - type: Åktype (kodeliste: 1, 2, 3, 11, 12, 13, 14, 15, 16, 17, 18, 19, åkunge, utliggeråk, annet) - lengde: Real Eit åk har normalt assosiasjon til ei eller to master, men bør vel ha mulighet for ingen... Åk som punktobjekt seg eg ikkje noko umiddelbar nytte i. Her vil vi kunne bruke mast. Kontaktledningsåk som eigenskap i kodelista Mastetype kan fjernast.

17 funksjon: Mastefunksjon skal ha kardinalitet (0..1) Ordnet Lagt inn Lagt inn

18 Fra Håvard Moe, jernbaneverket ( ) Punkt 25 - Mastetype/Mastefunksjon Dersom vi skal ha desse to listene må vi bli omforent med kva dei skal innehalde. Ei med form (type) og ei med funksjon burde vere greit. Vi burde ta stilling til om lista med mastetyper skal vere så spesifik som den er no, med variantar saksa m.a. frå REN 2007 og NVDB mm.om så er tilfelle har vi ei lang liste frå Jernbaneverket òg (For kontaktledningsmaster har vi typane 13-20, B1-6, B10, B12, B14, B16, H1-6, HGM, T, TUF samt hengemast). Det bør uansett vere eit sett med "enklare" typer, som den fyrste delen av lista (fagverksmast, betongmast, etc.) Her ville eg òg hatt med Bjelkemast (som er stålmaster, men ikkje fagverk). Endret navn på Mastetype til Mastekontruksjon. Lagt inn noen flere koder (ette rinnspill fra JBV/Håvard). Lagt til definisjon på Mastekonstruksjon og Mastefunksjon Note fjernet Også lagt ut melding i Basecamp, med oppfordring om tilbakemelding

19 Lagt inn SOSI Ledning 4.0: StolpeStor: stolpe i høyspentlinjer StolpeEnkel: frittstående stolpe i lavspentnett, telenett eller langs jernbane Dreneringsledninger noe utydelig. Fra Roy Johansen : Kodelisten VA_Overvannsledningsbuk har elementene Overflatevann Har ikke fått forslag til hvordan dette skal forbedres. Ingen ting gjort : Lagt inn Drensledningsnett

20 Drensvann Sigevann Dette er vel bra nok vektlegging av drens Er det helding/nødvendig å ha to nivå her, eller skaper det mer forvirring? Skal det være to mulig nivå i modellen her, og la det være opp til produktspesifikasjonene å avgjøre hvilket nivå som skal brukes? Fra Roy Johansen : Du fjerner ikke ett nivå i modellen, men vi får ikke lenger to nivåvalg på virkelige objekter på SOSI-fila. Den forrige konstruksjonen har vært kritisert tidligere. Jeg ser at det er gjort det samme med VA_Rørdel (Nr. 40) og VA_Ventil. Bra. Men i modellen er objekttypen som VA_Nettstasjon arver fra, Felleskomponenter::Nettverkstasjon, satt som ikke-abstrakt objekttype (ikke kursiv). Er det noe feil her? Det som er gjort her bør vel også gjøres for EL_Stasjon? RAD: Dette er ikke helt enkelt å svare på. De fleste kummer på nettet er ubetinget "kontainere" men det finns kummer som sett og vis inngår i nettet (fortrinnsvis for avløpsnettet og overvannsnettet): Mitt forslag, som avledes av innholdet i Roys notat er følgende. som en kode i Ledningsnettverkstype /EO/SH: Setter VA_Nettstasjon som abstrakt, og fjerner kodeliste VA_Nettstasjonstype fra VA_Nettstasjon dvs reduserer til ett nivå. Kodelisten (sammensatt av tre delkodelister) brukes på Nettstasjonsomriss, og slettes derfor ikke : EL_Stasjon gjort abstrakt (se kommentar fra RJ) VA_Kum flyttet fra å være en subtype av Felleskomponenter/K um til å være en subtype av VA_Kopling.

21 VA_Kum beholdes som "Kontainer" men samtlige egenskaper herover flyttes til en subtyper av VA-Prosessenhet / VA_Kobling som selvstendige kumtyper på linje med Slamavskiller / oljeutskiller etc.. Fra Roy Johansen : Jeg vet ikke hva Rene sikter til nå han nevner Roy s notat. Men her har vi et problem, som vi jo har vært innom flere ganger før. Rene mener vi skal lage en ny objekttype som arver fra VA_Kopling eller VA_Prosess. Jeg vil foretrekke VA_Kopling. Objekttypen bør ha et navn som inneholder «Kum». I fagmiljøet er dette ubetinget en kum. Har noen et godt navneforslag? Fra RAD : Mitt forslag er: (Dette er ikke i tråd med min tidligere kommentar) a) behold VA_Kum som den er nå, med følgende endringer a. Erstatt trykkkum med pumpekum b. Ta bort featuretypen "VA_Sandfang" fra VA_Kobling Sandfang er 2 ting 1) Det er en del av en kum som vist her. (Da kan det praktisk modelleres som en egenskap i VA_KUM) Tatt med noen av kum-egenskapene fra felleskomponenter/ku m. Lagt til mulighet for å tilknytte kumlokk. Burde flere av de eksisterende VA_Koplingene vært subtyper av denne nye VA_Kummen? Eks: VA_Sandfang? Er usikker hva som skal gjøres med VA_Prosesstype, ref Renes forslag i nabokolonnen : Tatt bort VA_Sandfang som egen objekttype. Lagt til Sandfang som en prosesstype i kodeliste (var det det du mente, Rene?) har ikke skiftet fra rykkum til pumpekum, pga forklaring som da ikke stemmer (trykkum: en kum med ventil som åpner når

22 vannstanden når et bestemt nivå.) 2) Det er en enhetsoperasjon i et avløpsrenseanlegg som vist herunder. Da modelleres det best som en "Enhedsopertasjon" av typen Sandfang Arvet fra VA_Kobling fra Martin O : Ikke enig med René at trykkkum erstattes med pumpekum. Trykkkum er en egen type kum som benyttes for å føre avløpsvann forbi lavpunkt, f.eks kryssing av et vann. Kummen har avstengningsventil ved utløpet. Når den er stengt fylles kummen med avløpsvann. Når vannstanden/trykket bygges tilstrekkelig høyt i kummen åpner ventilen og kummen

23 tømmes. Det er egen kode for dette i Gemini RAD: VA_Utjevningsbasseng kan utgå, det er det samme som VA_Fordrøyningsbasseng. Fjernet

24 RAD: Det kan være en god ide Lagt inn Tatt bort note Øverløp finns både som kontainere og som processenhet. Overløp som kontainer kan evt. skifte navn til Overløpsstasjon Bilder av overløpsstasjoner Lagt inn ny objekttype VA_OverløpStasjon Fjerna VA_Overløp fra diagram VA_Framføringsnoder Lagt til attributter på overløp. Mangler enhet på Kapasitet!!

25 Forslag til modell for koblingen VA_Overløp Fra Martin O :

26 EO: Ikke tatt inn (ennå), krever mer diskusjon RAD: Enig i dette følger av ovenstående kommentarer Flytta VA_Sandfang fra VA_Nettstasjon til VA_Kopling Fra Rene AD : Hadde håpet andre kom på banen her, men her er noen forslag: Fordrøyningsbasseng Kapastitet: real Pumpestasjon Kapasitet: real Antall Pumper: Integer Aggregat: ja/nei Tøroppstilte pumper: Ja/nei Mellomdek: Ja/nei Kapasitet er Lagt til VA_Fordrøyningsa nlegg/kapasistet. Enhet: m3 VA_Pumpestasjon : antallpumper, kapasitet (m3/time), aggregat, tørroppstiltepump er, mellomdekk VA Renseanlegg: kapasitet (m3/år) VA_trykkreduksjo n: utgangstrykk

27 stasjonens samlede kapasitet Kapasitet: real Vannbehandling (enhet??) vannbehandlingst asjon/kapasitet (m3/år) Takk bort rød note Renseanlegg Kapasitet: Real Trykkreduksjon Utgangstrykk: Real Kapasiteter i m 3 /år Fra Martin O : Foreslår «Vannbehandlingsanlegg» i stedet for «Vannbehandling» Foreslår «Avløpsrenseanlegg» i stedet for «Renseanlegg». Evt Vannbehandling og Avløpsrensing : Døpt om Fordroyningsbasseng/ kapasistet til volum (etter forslag fra Martin O) Endret VA_Vannbehandlingss tasjon til VA_Vannbehandling Endret VA_Renseanlegg til VA_Avløpsrensing

28 RAD: Jeg mener listen kan fjernes det er dobbelt opp og tar vek muligheten for å ha egenskaper på nettstasjoner nå og i fremtiden. Fra Roy Johansen : Er kodelisten fjernet (se nr. 28) eller er den det ikke? Hvis VA_Nettstasjon settes abstrakt, er vi avhengig av subtypede objekttyper som dekker det samme som kodelisten for VA_Nettstasjonstype, og da er kodelisten overflødig. Fra RAD : Kodeliste: Nettverkstasjonstype : Vi trenger ikke følgende attributter: VA_Høydebasseng, VA_Trykkøkningsstasjon, VA_Trykkreduksjon, VA_Målekum, VA_Ventilkammer, VA_Renseanlegg, VA_Pumpestasjon, VA_Overløp, VA_Sandfang; VA_Utjevningsbasseng (Skall bort uansett) og VA_Fordrøyningsanlegg. Se 28 over. Kodleisten lever inntil videre. Note fjernet, og de to kodelistene tatt bort fra diagrammet. Finnes likevel i modellen, og i andre diagram : Ordnet i kodelista: Tatt bort VA_Sandfang og VA_Utjevningsbasseng. (Dette er ei kodeliste som kan brukes dersom en bruker objekttypen Nettverkstasjon (fra Felleskomponenter) Pumpestasjon styring. Hvor hører dette hjemme

29 RAD: Uten å være skråsikker, mener jeg at dette egentlig ikke ler ledningsnett, men drift, og at det derfor ikke hører med i denne modell. Slettet - VA_Hendelse - VA_HendelsesType VA_Prosess er ennå med Bra! Fra Roy Johansen : Det er kanskje ufruktbart å diskutere om Drifthendelse hører med til nettet eller ikke. Men for den som ønsker å skifte system, tror jeg det er viktig å få med markeringene av driftshendelsene. Disse har ingen betydning ved f.eks. utveksling av data til beregningssystemer o.l., men de hører med i en dokumentasjon av nettet. Da er det viktig både med den opprinnelige hendelsen, f.eks. Brudd, samt dato for denne, og hva som er

30 gjort for å fjerne problemene som hendelsen medførte, f.eks. Utskifting av rørdel, og dato for dette RAD: Forslag til modell: Døpt om VA_Inntak til VA_Vanninntak. Lagt til attributter: - kildenavn - kildekapasitet - inntaksdybde Fjernet note - NB: Mangler enhet kapasitet, se også 32 Fra Roy Johansen : Hos oss fra det vært en del forvirring om hva Inntak er. Kan det brukes på annet enn et vanninntak fra en drikkevannskilde? Jeg oppfatter forslaget om forandring til VannInntak som en presisering på at det er drikkevann det gjelder. Det er bra : m3/år (ref Rene) Lagt til VA_Bekkeinntak med attributter - bekkenavn - rist

31 Note fjernet Er det helding/nødvendig å ha to nivå her, eller skaper det mer forvirring? Skal det være to mulig nivå i modellen her, og la det være opp til produktspesifikasjonene å avgjøre hvilket nivå som skal brukes? Omdefinert VA_Rørdel til abstrakt, dvs slik at den ikke kan brukes i et datasett. Alle datasett må da bruke suptypene til VA_Rørdel. Det betyr også at kodelista VA_Rørdeltype er overflødig, og dermed fjernet.

32 Se over (41) Lagt til attributtene diametermin og diametermaks. Attributt lengde dekka av mer generelle typer.

33 Er det helding/nødvendig å ha to nivå her, eller skaper det mer forvirring? Skal det være to mulig nivå i modellen her, og la det være opp til produktspesifikasjonene å avgjøre hvilket nivå som skal brukes? Gjort VA_Ventil til abstrakt type, dvs ikke mulig å bruke denne direkte i datasett. Kodeliste VA_Ventiltype er fjernet Note fjernet Ulik kodeliste for Stengeventiler i SOSI 4.0 og ny SOSI 4.5. Er det noen flere som skal inn i SOSI 4.5? : Er ikke stengeventiltypene - Sluseventil det samme som Stengeventil sluse SVA? - Spjeldventil det samme som Stengeventil spjeld SVB) - Hva med Liggende sluseventil m/o : Rene: VA_Ventilbetjening: Enten: { Automatisk; Manuel } Eller: { Manuel, Motor, Hydraulisk, Pneumatisk, Fallvekt } Heller vel til det siste forslag. Lagt til i VA_Ventilbetjening: - Motordrevet - Hydraulisk Skal da kode Automatisk fjernes? : Justert kodeliste VA_Ventilbetjening til eller -forslaget til Rene. Lagt til Nåleventil som Stengeventiltype. VA_Stengeventiltype: Tilføy: Nåleventil

34 RAD : Lidt raffinering til Prosess. Skift navn: Prosess -> Enehtsoperasjon EO: Lagt til objekttype VA_Tank (som foreslått av Rene) Endret navn på VA_Prosess til VA_Enhetsoperasjon Endret navn på VA_Prosesstype til VA_Enhetsoperasjonst ype Supplert kodelista (Ikke kopiert inn figurer som viser renseanlegg.)

35 Fra Roy Johansen : I VA_Rørkonstruksjon bør det være mulig å få med om ledningen er dobbeltvegget. Dette har vi mast om før. F.eks. «Dobbeltvegget: Ja/Nei.». Avhengighetene beskrives kum med merknader i notefeltene for hver enkelt Note fjernet Rene: Som Roy nevner bør vi nok ha med en egenskap for "Oppbygning" i datatypen VA_Rørkonstruksjon. VA_Oppbyggning: Dobbelvegget; Korrugert; Varmetråd; (Mangler navn for isolering mot olje) : Lagt til egenskap oppbygging som fritekst-felt (vanskelig å modellere alle kombinasjoner, ufullstendig kodeliste) Slå sammen Elektrisitetskobling og EL_Node Utført EL_Node er en abstrakt type, og trenger da vel ikke type? HeOp opprydding. Fjern i alle fall alt som har med nettnivå, spenning og effekt å gjøre. Nettnivå fjernes fra alle containere Fjernet nettnivå på følgede objekttyper: - EL_Kum - EL_Kabelskap - EL_Mast

36 Fjernet attributt spenning fra - EL_Mast - EL_Kabelskap - EL_Kraftstasjon - EL_Transformator stasjon Slettet egenskaper som alt er stereotypet <<slettes>> - EL_Mast - EL_Kum På Mast fjernet alle HeOp-attributter som allerede er flyttet oppover i arverekka. Mer å gjøre?? Fra GMØ: Fjerne stereotypen <<HeOp>> fra - EL_Kum - EL_Kabelskap Slik at disse blir standard attributter på egenskapene OK, utført-

37 TP: Kraftstasjon og EL_Vindturbin: Ytelse, effekt og spenning fjernes herfra Kommentar: Disse to objekttypene er kontainerobjekttyper som består av generatorer. Attributtene på disse er derfor å forstå som en summering av tilsvarende attributter på hver av generatorene som inngår. De bør derfor beholdes. Ingen tiltak Spenning kan da vel ikke være en summering vel??? Det øvrige kan jeg til en viss grad forstå Fra Håvard Moe, jernbaneverket ( ) Punkt 51 - FramføringsnodeBruk Denne - som ligg i pakka for felleskomponentar - bør vel samkjørast med LedningsBruksområde som ligg i kjernemodellen? Det er òg ei kodeliste EL_Ledningbruk i fagmodellen på El. To codelister og en note fjernet fra figuren. Ligger i modellen i Felleskomponenter/K odelister : Kodelista Framføringsnodebruk har er svært lik Lendingsnettverkstype (tidl

38 Er Bruksområde overordna medan Bruk er meir spesifikt? Det er slik eg har tolka det, jfr. den siste kodelista under El, som vel i hovudsak er våre (JBV) ting. Alt under KL og banestrøm her er høyspent, men har ulik bruk... Ledningsnettverksbru k). For ikke å ha to så like kodelister å vedlikeholde, er Ledningsnettverkstype tat tinn i stedet for FramføringsnodeBruk, selv om den ene primært er for nettverk og den andre for enkeltnoder. Dette medfører at kode Ingen i Framføringsnodebruk ikke lenger er tilgjengelig : Også brukt Ledningsnettverkstype som datatype på attributten Framføringsnode/hov edbruk

39 El_Belysningspunkt Effekt bør ut herfra Dette er i prinsippet en avleda egenskap som kan beregnes som summen av effekten av alle tilknytta EL_Armatur-objekter. Kan i de tilfeller en ikke har detaljert ned til EL_Armaturer, brukes som originalkilde. Ikke tatt bort.

40 Fra Håvard Moe, jernbaneverket ( ) Punkt 53 - KL-mast/åk Denne er vel i hovudsak dekt av punkta 21 og 25 over. Løsning beskrevet i pkt 21 over. Note fjernet. Mastetyper foreslått i note er med å kodelista Mastekonstruksjon.

41 EL_Koblingsbruk kodeliste. Flyttes til EL-ledning EL_KoplingBruk fjernet fra diagrammet. 148) (se s

42 Trekkerør diameter er unødvending. Ligger på Kjernemodell:Ledning Attributt diameter fjernet fra Trekkerør El_Trekkerør fullt er vel like aktuelt på alle trekkerør og kanaler. Bør flyttes opp? attributt fullt flytta til Trekkerør Lagt til attributt fullt på Kanal Typebetegnelser for kabel og luftlinje Typebetegnelse Her må det en del avklaringer til Foreslår å fjerne datatypen, flytte fabrikat ut som eget felt og legge inn en tekst med typebetegnelse i alle objekter som skal ha denne med navn typebetegnelse_<komponentt ype>. Eks.: typebetegnelse_kabel, typebetegnelse_luftlinje, typebetegnelse_elskap osv. Så lages en kodeliste for hver av disse Typebetegnelse for kabel eller luftlinje inneholder Type ledning/kabel (konstruksjon) Typebetegnelse er tatt inn hel t på toppen (som attributt til Nettverkskomponent). OK tror jeg Ingen ting gjort med dette. Kodelistene da???

43 Materiale (noen ganger gir typen også materiale) Antall ledere Dimensjon (areal i mm2) Eks: PFSP Al 3x95, EX 3x95 Typebetegnelse for kabler og luftlinje bør skilles i to kodelister Alternativ for typebetegnelse for kabler og luftlinjer I stedet for å lagre typebetegnelsen som en streng kan vi dele den i 4 felter: Kabeltype, materiale, antall ledere og dimensjon (areal i mm2). Disse kan settes sammen til en streng ved behov. Ved valg i kodelister med hele typebetegnelsen må da det som velges der gjøres om til de 4 feltene. Kodelisten er for så vidt like aktuell Fordelen med å gjøre det på denne måten er at man kan enklere bruke hver enkel del av typebetegnelsen. Det trengs noen ganger, for eksempel ved nettberegning. NB! Kabler og ledninger har en rekke egenskaper ut over dette, for eksempel motstand pr. m, kapasitans mellom ledere, kapasitans til skjerm, jord etc. NB! Se kommentar vedr

44 Fabrikat/typebetegnelse (kommentar til side 36) Fra Håvard Moe, Jernbaneverket ( ): Punkt 59 - El_Node/Punkt 72 - El_Koplingstype Her mangler det ein måte å handtere ulike formar for "utstyr", både det som NVE og vi har meldt inn. Som eg har nemnt bør det vere ein objekttype for koplingspunkt eller liknande med ei kodeliste for type. Denne kan fange inn alt det som ikkje har mange eigenskapar men som mangler i dag. Begge desse listene som er nemnt må inn ein plass... (her burde jo den tomme kodelista El_Koplingstype passe utmerket...?) Lagt inn i kodeliste EL_KoplingType. 2 noter fjernet Gjenstår: Mangler også foreslåtte attributter på EL_Ledning : Legges inn på Elektrisitetsledning Bryter/brytersystem: dekket av brytertype??

45 El_Installasjon må ut EL_Installasjon fjernet Note fjernet El_Armatur Egenskapen antallarmaturer bør ut fordi andre egenskaper ellers vil være tvetydig (Selv om den er slik i NVDB) Trekkerør kanaler med trekkerør Angi antall for å forenkle (lampearmatur, trekkerør) NVDB-eksempel: Antall armatur i en tunell er tilstrekkelig, ikke nødvendig å ha med alle punktene. Attributtten AntallArmaturer er flytta til objekttypen EL_Belysningspunkt.

46 Lar den ligge. Tatt bort noten. Fortsatt helt uenig. Hadde dette oppe på møte hos NOIS og de var like uenig Burde denne hete EL_Koplingspunkt? Håvard Moe, jernbaneverket ( ): Punkt 64 - El_Koblingspunkt Endret navn til EL_Koplingspunkt Dersom vi bruker kopling bør det vere det over alt og ikkje blanding av kopling/kobling...

47 Tilknytningspunkt: CosinusPhi må inn for å kunne kjøre beregninger i nettet Lagt inn ny attributt og forklaring fra Wikipedia: effektfaktoren, brukes for å angi hvor stor aktiv effekt vi kan utnytte Bra! matestasjon ligger på EL_Node og mateinformasjon på for eksempel EL_Tilknytningspunkt. Kan ikke ha begge. Mateinformasjon må i alle fall ut av alle Framføringsnoder /EO: Mateinformasjon tatt ut av EL_Tilknytningspunkt matestasjon tat tut fra EL_Node, bør være tilstrekkelig med mateinformasjon mateinformasjon tatt bort fra framføringsnodene

48 - EL_Stasjon - EL_Kabelskap Fra GMØ: Det må ryddes opp i stereotypen <<HeOp>>, og de attributtene som allerede er arvet fra høyere nivå fjernes EO: tatt bort mateinformasjon, nettnivå og konsesjon fra EL_Transformator Det mangler egenskaper på en del objekttyper (El_Skjøt, EL_Feilindikator). Det finnes mange typer skjøt. Kan dekkes av Typebetegnelse_Skjøt. Tatt bort nettnivå og spenning på EL_Tilknytningspunkt Det mangler egenskaper på en del objekttyper (El_Skjøt, EL_Feilindikator).

49 EL_Material bør brukes som felleskodeliste. Har derfor bytta datatype for attributtene - Elekktrisitetsledni ng/materiale Har ikke funnet andre steder den er brukt. Kodeliste EL_LedningMateriale er slettet Kodelista EL_LedningType som dette er slutten på, virker å være ei liste som inneholder en sammensetning av Material (finnes som egen kodleiste), tverssnitt (finnes også som egen kodleiste) og antallledere (ikke

50 definert som egen kodeliste) Attributt type og tverrsnitt mangler på Elektrisistetsledning. Lagt til Bytter navn på kodelista til EL_LedningFunksjon for å tilpasse til VAspråkbruk. Ingen forandring i kodelisteverdier Endrer også attributten på Elektrisitetsledning fra bruk til funksjon (side 122 / Kodelisten El_KoplingType på Elektrisitetskopling er tom Bør vel inneholde navnet på subtypen? Fra Håvard Moe, Jernbaneverket ( ): Punkt 59 - El_Node/Punkt 72 - El_Koplingstype Her mangler det ein måte å handtere ulike formar for "utstyr", både det som NVE og vi. Lagt til en ny objekttype EL_Node_Generell, flytta kodelista EL_Koplingstype inn her og fjernet den fra EL_Node Til Håvard/JBV: Trenger kodeverdier i EL_KoplingType

51 har meldt inn. Som eg har nemnt bør det vere ein objekttype for koplingspunkt eller liknande med ei kodeliste for type. Denne kan fange inn alt det som ikkje har mange eigenskapar men som mangler i dag. Begge desse listene som er nemnt må inn ein plass... (her burde jo den tomme kodelista El_Koplingstype passe utmerket...?) OK, to nye koder lagt inn.

52 Bruk av Ledingsnettverk: Brukt på TeleSignal, men ikke på andre Uhelding (feilaktig/ulovlig?) å subtype Ledningsnettverk? Avklare om det er mulig i UML å gjøre det på denne måten: Tror at komposisjonen fra Nettverkskomponent til Ledningsnettverk også gjelder til TeleSignalNettverk Diskuteres med Steinar 16/17 jan Kodelista TeleSignalNettverksan leggtype lagt til som supertype for genrell kodeliste Ledningsnettverksbru k. Subtyping av Ledningsnettverk fjernet. NB! Ennå brukt på Belysningsanlegg Skal være med, brukes der abonneter er tilknytta Ingen ting tas bort Kodelista som brukes for attributten skal være Signal_KoplingspunktType. Note fjernet fra diagram. OK, ordnet Skal det modelleres med subtyper på Ledningsnettverk? Nei, se 74.

53 Jordingsledning: Felles med EL_Jordingsledning Slettet denne, og vist EL_Jordingsledning i stedet. Døpt om EL_Jordingsledning til Jordingsledning Materialliste: Felles med andre materiallister?? (ut av TeleSignal) Diskuteres med Steinar 16/17 jan Er med for å kunne avgjøre om ledninger lar seg peile med normalt peileutstyr Ingen ting forandres

54 Skjøt: Felles for EL og Tele/Signal? Diskuteres med Steinar 16/17 jan Slås ikke sammen Ingen tiltak for dette. Merknaden blir stående i endelig versjon Ingen tiltak for dette. Merknaden blir stående i endelig versjon

55 Ikke med i aksjonslisten Fra Roy Johansen : Borehull Det er ifg. vårt Bergenskontor populært på Vestlandet å bore hull gjennom fjell for å trekke ledninger. Dette får da samme funksjon som et trekkerør under en vei. Kan en bruke objekttypen Tunnel på dette? Eller er Tunnel noe mer og større? EO: Har lagt inn kommentar i definisjonen på tunnel som sier at den også kan brukes til borehull. EL_Node En burde ha litt mer samkjøring mellom de ulike fagområdene. EL_Node bør hete EL_Kopling. Dette vil stå i stil med at objekttypen arver fra Kopling. Under andre fagområder heter det TeleSignalKopling, FjernvarmeKopling og OljeGassKopling EO: Døpt om fra EL_Node til EL_Kopling Framføringsnoder I modellen for VA_Framføringsnoder, EL_Framføringsnoder er Felleskomponenter::Framføringsnode satt som abstrakt objekttype (kursiv). Under denne har vi flere nivåer med ikke-abstrakte objekttyper. Betyr dette at vi har en valg når det gjelder hvilket nivå vi vil stoppe på? Felleskomponenter::Nettverkstasjon er ikke-obstrakt (ikke kursiv), men har en subtypet objekttype, VA_Nettstasjon som er abstrakt, og igjen subtypet til ikke-abstrakte objekttyper EO: Enig i at dette ikke er helt ryddig modellering. Men mener likevel at det må være en viss frihet her til å velge detaljeringsnivå. Prinsippet er at det i fellesdelen er en ikke-abstrakt objekttype. I de enkelte ledningsfagområdene er det også en ikke-abstrakt objekttype som kan brukes, dersom objekttypen trenger å vinkles mot det enkelte ledningsfagområdet. Framføringsvei

56 Under den abstrakte objekttypen Felleskomponenter::Framføringsvei er det for EL-området to nivåer med ikke-abstrakte objekttyper, bl.a. Felleskomponenter ::Trase og EL_trase. Dette må en jo ha siden Felleskomponenter ::Trase ikke er subtypet for VA. Men tenker en her at en har to nivåer å velge mellom? : Se kommentar til forrige punkt. Fra Jørn Petter Wittbank, Avinor Jeg har ikke klart å følge med på alle mailene som går ut fra deg om dagen Erling, men jeg har gjort en oppsummering av det jeg fant i Ledning 4.5. Håper det er ok at jeg sende det inn slik. 7.3 Felleskomponenter: her savner jeg Slisse. I Avinor benytter vi Slisser som Trase/Fremføringsvei til El kabler, men jeg vil tror at en slisse også kan benyttes for signalkabeler. Da hører den vel inn under kap 7.3 Det er uheldig for oss hvis denne skulle falle ut. Slissing er oppført under kap (det eneste stedet jeg finner den). Jeg finner ikke igjen det som gikk på kabeltv/ekom. Men når det er sagt så kan vi klare oss med dokumentasjon på Felleskomponentnivå. Trase/Fremføringsvei-(variantene), Skap og Kum. KTV komponeter vil bli håndtert i andre systemer. Jeg finner ikke igjen VareRør. VareRør skiller seg fra TrekkeRør ved at de har dobbel vegg og benyttes som oftest som trekkerør for rør som fører væske (VA, drivstoff ol), ref Brødrene Dahl as på tlf tidligere i dag. For kap OljeGass har vi følgende behov med tanke på dokumentasjon: (håper det er mulig å få det med) EO/ Har lagt til ny underpakke under Olje/Gass, gitt den nye pakken navn Lufthavn_Fuel

57 Tank (Fueltank). Er som regel stor og bør dokumenteres som en flate/polygon EO: Ny objekttype FuelTank, subtype av OljeGassKopling, med ny egenskap omriss (Kurve)

58 Kabinett: påfyllingsenhet som enten står i forbindelse med tanken eller står fritt nær oppstillingsplass for fly. Et kabinett kan innholde pumpe og påfyllingsenhet. Et kabinett dokumenteres som et punkt. Egenskap vi bør ha med er Dimensjon

59 EO: Lagt til dimmensjons-egenskaper til Skap i felles-delen. Ny objektype FuelKabinett (subtype av Skap), uten egne egenskaper. Har også definert opp FuelPumpe og FuelPåfyllingsenhet, begge som subtyper av OljeGassKopling (Grunn: forklaringen over: Et kabinett kan inneholde pumpe og påfyllingsenhet), men er usikker på om disse to siste trengs. FuelLedning: mellom tank og kabinett. Dokumenteres som linje.

60 Egenskap i tillegg til ordinære er Dimensjon på rør EO: Lagt til ny objekttype FuelLedning som subtype av OljeGassLedning. Dimensjon bør være dekket av egenskapene denne arver (indre/ytre diameter, ) (TrekkeKum: FuelTrekkekum - Her kan vi vel benytte Trekkekum under felleskomponenter. Dette er en kum som sitter i hver ende av et Varerør og som blir benyttet til å trekke frem fuelrør.

61 /EO: Har lagt til en kode på Kumtype: Trekkerør/Varerør: Her kan vi vel benytte Trekkerør under felleskomponenter eller bør Varerør være et valg på lik linje med Trekkerør???) /EO: Lagt til ny attributt på trekkerør: EO: Fullt diagram fra pakke Lufthavn_Fuel blir da:

62

63 Til slutt: Jeg har ikke hatt tid til å følge med på alle innleggene som går, men var det ikke enighet om å videreføre begrepet Trase og Trase node istedenfor Fremføringsvei og fremføringsnode? Fra Geir Myhr Øien og Svein Arne Rakstang, des 2012: Hei Har fått de vedlagte bildene fra Svein Arne av underjordiske nettstasjoner. Han ønsker å få dette inn som objekter i FKB-Ledning prod.speken. Underjordiske nettstasjoner mangler i kodelisten EL_stasjonstype. Fint om du kan legge til Underjordisk her.

64 Fra Svein Arne Rakstang Jeg har hatt FKB ledningel i tanken her. Da er det den synlige delen som jeg tenkte burde være med. Siden dette er objekter som (kun) finnes i tettbygde strøk så snakker vi om de områdene med mest detaljert kartverk (A). Det er i disse områdene viktig å få med «Adkomsten» -dvs «tårnet som vises på bildet (som jeg håper du har fått oversendt fra Geir ). I tillegg er det gjerne en «heisesjakt» som ikke skal tildekkes ( når man skal heise ned f.eks ny transformator) og utluftingsgitter. Jeg er ganske sikker på at første dekkes med «nettstasjons adkomst» og er i tvil om vi skal ta med de to andre synlige delene i et underjordisk kioskanlegg. Jeg er ikke helt stø i benevnelsene på slike nettstasjoner. Vi har nettstasjoner totalt i Eidsiva men bare en underjordisk med tårn. Den kaller vi u-båten og ligger sentralt Hamar. Dette er mye mer vanlig i «stor»byer EO: Har laget en ny objekttype NettverkstasjonAdkomst i felles-delen, med kodeliste for å dekke de typene som er antydet i teksten over.

65 Fra Rene Astad Dupont Kodeliste: VA_Målertype "Venturimåler" er en mengdemåler, og skal derfor fjernes Tilføy "Annen målertype"

66 : Fjernet Venturimåler, lagt til annen målertype. Kodeliste: VA_Sluktype Gategutt er en kumlåkktype og bør flyttes dit. (Kanskje til kodelisten: Kumlokkform) : Gategutt flytta fra Sluktype til Kumlokkform Fra Roy Objekttypen VA_Kum (kanskje opp et nivå til til Kum) burde ha egenskaper som forteller hvilket materiale som kummen består av, og hvordan den er konstruert. Hos oss har vi en materialkodeliste som ser slik ut (antakelig rappet fra Gemini): Prefabr. betong Prefabr. PEH/PEM Prefabr. uspesifisert Murt Støpt PP polypropylen Vi kunne imidlertid gjort som for objekttypen Mast, og delt dette inn i Konstruksjon og Materiale EO: Har sett på forslaget til Roy (se over) om kum-koding, og synes dette forbedrer modellen.derfor lagt til ny kodeliste Kumkonstruksjon (med kodene prefabrikert, murt, plass-støpt). Har supplert kodelista Konstruksjonsmaterial (som også er brukt på mast) med kodene PEH/PEM og Polypropylen. Lagt til to nye attributter på Kum: konstruksjon og konstruksjonsmaterialehar for å holde "masteparallellen" også døpt om Kumtype til Kumfunksjon. Ikke gjort noe med VA_Kum, og siden den ikke arver fra Kum, forblir den uten konstruksjon/materiale/funksjon. Men dette er tross alt kummer med bestemte hensikter.

67