DANVA INFORMATIONSMODEL DANDAS 3.0

Relaterede dokumenter
3 Geometriske begreber Knude Linie Flade 13

DANVA DATAMODELLER JKJ, TRKS, HEMA

DANVA INFORMATIONSMODEL KABLER, FREMMEDRØR OG FLADER 1.0

DANVA INFORMATIONSMODEL BRUDREGISTRERING 1.0

DANVAs nye datamodeller Danvand 2.0 og Dandas 3.0

DANVA INFORMATIONSMODEL TV-INSPEKTION OG BRØNDRAPPORT 3.0

ugraph Anders Vittrup og Henrik Madsen

VandGraf VarmeGraf ElGraf Brugermøde

Registreringsvejledning for Nyanlæg i Spildevand. Bilag - Knuder

Bilag. Opmåling af Kloak

Anvendelse af dobbelthistorik i GD2

DanDas STANDARD. DanDas DATA LEVERING AF OPMÅLINGSDATA OG DATA FRA TV-INSPEKTION SØNDERBORG FORSYNING LEVERING AF ELEKTRONISKE DATA

Registreringsvejledning for afløb opmåling af nyanlæg og renovering

Kravspecifikation Ledningsregistrering

Vejle Spildevand. Registreringsvejledning for nyanlæg Til opmålingsdata

Krav til DanDas xml-filer for levering af filer til Vejle Spildevand

Athena DIMENSION Varmeanlæg 4

Registreringsvejledning for Nyanlæg i Spildevand. Bilag - Knuder

Registreringsvejledning for nyanlæg Opmålingsdata. Ver April 2017

N Y E D A T A M O D E L L E R

Vejledning til modellering af vandløb

Begreber og arbejdsprocesser. v. Bent Guldager og Karina Topp Aarhus Vand. DDV, Kick-off, 25 jan. 2012

Referencedatamodelprojektet. Overblik over DDV Governance-modellen

DanDasGraf Brugermøde

Registreringsvejledning for Nyanlæg i Spildevand. Bilag - Ledninger

B R A N D S O F T. Vejledning til opmåling af kirkegårdskort for landinspektører.

CCS Formål Produktblad December 2015

Identifikation af planer der ikke findes i PlansystemDK vha. datasættet... 9

Oversigtskort. Forsyningsarten Varme er ikke fundet.

Ejerfortegnelse Løsningsarkitektur Bilag C Processer Grunddataprogrammet under den Fællesoffentlig digitaliseringsstrategi

Fra vision til daglig drift. Hvordan kan IT-anvendelse understøtte forretningen?

Notat 11. maj Retningslinjer for overtagelse af kloakker. Kloakering af nye større udstykninger og nye samlede bebyggelser. Nye kloakledninger

Introduktion til deljordstykker

VandCenter Syd REGISTRERINGSVEJLEDNING BILAG

Bilag 3 - Beregning af det alderskorrigerede netvolumenmål Bilaget indeholder en teknisk gennemgang af beregning af det alderskorrigerede

21. OKTOBER 2014 TRYK OG TRYKKOTER. En kort forklaring om begreberne meter vandsøjle og meter over havet. Lejre Vandråd

ST Sortiment Informationsmodel

v. Kurt Brinkmann Kristensen, Århus Vand A/S

Spildevandsplan Bilag 5. Indhold. Kloakfornyelse. Vedtaget 27. maj 2014

KRAVSPECIFIKATION OPMÅLING BILAG 7 SPILDEVAND ØVRIGE KONSTRUKTIONER

CCS klassifikation og identifikation

DANDAS DATAMODEL FOR AFLØBSSYSTEMER

Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

Krav til TV-inspektioner og brøndrapporter i DanDas. TV-inspektion udført for Odense Kommune skal overholde nedenstående.

Erfaringer med CPR-replikering

FORMAT - DXF - EKSPORT

VANDFORVALTNINGSSTRATEGI LOKALPLAN 404 VED RODSKOVVEJ I RODSKOV

UML til kravspecificering

Der tages forbehold overfor de på tegningen angivne mål, herunder koter. Alle mål skal kontrolleres på stedet.

1 Klassifikation-version2.0

Vejledning for koordinering af bygningselementer (Kollisionskontrol)

Sortiment Informationsmodel

DATAMODEL FOR VANDFORSYNING

Anvisning i aflevering af bitemporale data

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database

Vejledning VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL. Februar 2015 (VERSION 1.4 AF FEBRUAR 2015)

Sortiment Informationsmodel

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Guide til integration med NemLog-in / Signering

EDI. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1. Copyright: Naddon version

Notat om metadata om grunddata

Performance benchmarking

NBS Organisatoriske begreber

VANDFORVALTNINGSSTRATEGI LOKALPLAN 404 VED RODSKOVVEJ I RODSKOV

Athena DIMENSION Varmeanlæg 4, Eksempel

Att: Mads Ellehammer:

KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.

PROJEKTBESKRIVELSE DIGITALE TILBUDSLISTER

Guide til VandData for kommuner

Niveauangivelse for Regionale SOR koder gennem hierarki/type attribut

Sortimentet angiver de mulige klasser, som er tilladte at benytte i en registrering, med andre ord en værdiliste over tilladte koder.

Indholdsfortegnelse. Systembeskrivelse kapitel 3 Forretningslogik

Grafdage Feltregistrering

vejman.dk Brugerdokumentation - kortmodul 14. marts 2012 Version 1.9

DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

Introduktion til MeMo

Hvordan finder og håndterer man deljordstykker i Plandata.dk praktisk guide

Notat. 1. Bygherrekrav digitalt byggeri

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Danvand Brugermøde. Henrik Madsen, Trine Schultz, Niels Peter Evind-Poulsen & Thomas Mørk

Introduktion til matrikulære data

Transkript:

DANVA INFORMATIONSMODEL DANDAS 3.0 Beskrivelse Version 1.4 November 2016 I

Oplæg udarbejdet af: Trine Schultz & Henrik Madsen Review: Lars Gadegaard Version: 1.4 Dato: 29. november 2016 Indholdsfortegnelse DANVA INFORMATIONSMODEL Beskrivelse I I 1 Introduktion 6 1.1 Formål 6 1.1.1 Mulighed for at interagere med andre ITsystemer 8 1.1.2 Fælles forståelse af ledningsnetværk 8 1.1.3 Afgrænsning: 8 1.2 Læsevejledning / kontekst 9 1.3 Migreringskommentar 10 1.4 Uddybning pr. forsyningsart 10 2 Forenklet model 12 3 Generelt om kernemodellen 17 3.1 Kernemodellens struktur 17 3.1.1 Forskel på kodelister og kataloger 17 3.1.2 Niveau 1: Geometriske begreber 18 3.1.3 Niveau 2: Fysiske elementer i virkeligheden 19 3.1.4 Niveau 3: Administrative puljer (Grupperinger) 19 3.1.5 Niveau 4: Supplerende begreber og kataloger 20 3.1.6 Niveau 5: Referencer og relationer 21 3.2 Moduler 21 3.2.1 Selvstændige datamodeller 21 3.2.2 Modulkandidater 22 4 Geometriske begreber 23 4.1 Knude 23 4.2 Linie 24 4.3 Flade 25 5 Begreber for fysiske elementer i virkeligheden 26 5.1 Bestykning 26 5.2 Funktion 27 5.2.1 Reservoir 28 5.2.2 Regulering 29 II

5.2.3 Forbindelse 29 5.2.4 Tilslutning 30 5.3 Ledning 31 5.4 Konstruktion 31 6 Administrative begreber 33 6.1 Gruppering 33 6.1.1 Projekt 34 6.1.2 Område 35 6.1.3 Strækning 36 6.2 Aktivering 36 6.3 Føringsvej 37 6.4 Opmålingspunkt 38 6.5 Note 38 6.6 Referencesystem 38 6.7 ReservoirGeometri 39 7 Supplerende begreber og kataloger 40 7.1 Aktiveringtype 40 7.2 Ejer 41 7.3 Firma og Firmatype 41 7.4 ProjektÅrsag, Anlægstype og Procestype 42 7.5 Link og Linktype 43 7.6 Materiale 44 7.7 MaterialeGruppe 44 7.8 Områdekategori og Områdekategoriniveau 45 7.9 Oprindelse 46 7.10 ReservoirKotetype 46 7.11 ReservoirVolumentype 47 7.12 Rør 47 7.13 Strækningtype 47 8 Livscyklus og historik 48 8.1 Livscyklus 48 8.1.1 Formål med at holde styr på status 49 8.2 Databasehistorik 50 8.2.1 Databasehistorik eksempler 51 8.3 Datofejlkonstateret 56 9 Dandas 3.0 modelspecifikke supplementer til kernemodellen 57 9.1 Relationer, Attributter og Kodelister 58 9.2 Modelspecifikke begreber 60 10 Bestykninger 63 III

10.1 KnudeBestykning 63 10.1.1 Servicekote 63 10.1.2 KnudeSanering 63 10.1.3 Dæksel 63 10.1.4 Rottespærre 64 10.1.5 Sandfangsbund 64 10.1.6 AnlægBestykning 64 10.1.7 AnlægBestykningType 64 10.2 LinieBestykning 64 10.2.1 LiniePunktSanering 64 11 Funktion 65 11.1 Reservoir 65 11.1.1 Udskiller 65 11.1.2 Sandfang 65 11.2 Regulering 66 11.2.1 Separator 66 11.2.2 Overløbskant 66 11.2.3 Afspærring 66 11.3 Forbindelse 67 11.3.1 Brønd 67 11.3.2 Udsparing 67 11.3.3 Udløb 67 11.4 Tilslutninger 68 11.4.1 Tilslutningspunkt 68 12 Konstruktioner 69 12.1 Udskillerbygværk 69 12.2 Reguleringsbygværk 69 12.3 Brøndbygværk 69 12.4 Tryktårn 69 12.5 Overløbsbygværk 69 12.6 Samlekonstruktion 70 12.7 Renseanlæg 70 12.8 Nedsivningsanlæg 70 12.9 Etagebrønd 70 12.10 Bassin 70 13 Knude 71 13.1 Brøndopland 71 13.2 LabelKnude 71 14 Ledning 72 IV

14.1 DeltaLedningKote 73 14.2 LedningPlanParameter 73 14.3 LabelLedning 73 15 Rør 74 15.1 Profilbeskrivelse 74 15.1.1 ProfilPunkt 74 16 Supplerende begreber og værdilister 75 16.1 Område 75 16.1.1 Områdekategori 75 16.1.2 Områdekategoriniveau 75 16.2 Projekter 75 16.2.1 Projektårsag 75 16.3 Materiale 75 16.3.1 Materialegruppe 75 16.4 Strækning 75 16.4.1 Strækningtype 75 V

1 Introduktion DANVA kernemodellen er blevet udviklet i overensstemmelse med Det digitale Vandselskabs (DDV s) OIO EAreol (DDVreolen) som en logisk modelkerne, der skal være fælles for modellerne for DANVA s standard for GISbaseret ledningsregistrering; hhv. DANDAS på afløbsområdet og DANVAND på vandforsyningsområdet. Kernemodellen er kernen i DANDAS og DANVAND, som er de nationale standarder for registrering af ledningsanlæg. Kernemodellen indeholder begreber, der er fælles for Vand og Kloakforsyninger, og som understøtter de besluttede forretningsprocesser. DANDAS standarden er etableret i 2002 og DANVAND er etableret i 2005. Ved frigivelsen af denne version af kernemodellen foreligger følgende versioner af de tilknyttede datamodeller: DANDAS version 3.0 DANVAND version 2.0 Kabler, Fremmedrør og Flader version 1.0 TV og Brøndrapporter version 3.0 Brudregistrering version 1.0 Disse modeller kan udvikles selvstændigt med nyere versioner, men der refereres blot til modelnavnet uden versionsangivelse i dokumentationen for Kernemodellen, hvorved revisioner af modellernes dokumentation kan ske uafhængigt af hinanden. DANVA, Dansk Vand og Spildevandsforening, har det fulde ejerskab af alle de ovenfor nævnte modeller. Udviklingen foregår i DANVA regi i henholdsvis en styregruppe og en række modelopdateringsgrupper, som er et netværk af deltagere fra hhv. DANVA, forsyningsselskaber, applikationshuse og rådgivere. Styregruppen har det overordnede ansvar for drift, vedligehold og udvikling af DANDAS og DANVAND, og dermed også af kernemodellen. Modelopdateringsgrupperne fremsætter forslag til opbygning, ændringer og udbygning af modellerne til styregruppen. 1.1 Formål Formålet med dette dokument er at dokumentere den fælles kernemodel. Dokumentet er frit tilgængeligt via DANVA s informationskanaler. Dokumentet er en del af grundlaget for forståelsen af, hvordan de logiske datamodeller for hhv. DANDAS og DANVAND er udformet. Den fælles kernemodel er en del af DDVreolen og placeret som logisk model i informationssøjlen. DDVreolen er gengivet i Figur 1 nedenfor hhv. skematisk og som en kopi af online versionen, der kan findes under Det Digitale Vandselskabs hjemmeside. Side 6 af 75

Perspektiv\ Klasse Strategi Forretning Information Applikation Teknologi Konceptuelt Logisk Kernemodellen Fysisk Styringsrammer Figur 1 DANVA's DDVreol, som kan findes på http://www.detdigitalevandselskab.dk/files/files/ddvreol/ddvreol.html Da kernemodellen er en logisk model, beskriver den de informationer, der skal være indeholdt samt disses indbyrdes relationer. Som en logisk model beskriver den ikke, hvilke tabeller og databaseformater der skal anvendes. Formålet med at have en fælles kernemodel mellem DANDAS og DANVAND er følgende: At sikre mulighed for at interagere med andre ITsystemer Definition af fælles informationer og principper mellem forsyningsarterne At skabe fælles forståelse af et ledningsnetværk Side 7 af 75

1.1.1 Mulighed for at interagere med andre ITsystemer Det er vigtigt at kernemodellen (og DANDAS / DANVAND i det hele taget) indeholder de informationer og nøgler, som skal bruges for at kunne gennemføre en fyldestgørende og entydig dataudveksling med andre systemer og brugere af dataene. Til DANDAS og DANVAND er der knyttet et fælles udvekslingsformat. Dataudvekslingen sikres gennem brugen af XMLformatet defineret i XSDskemaer, som ikke er beskrevet yderligere i dette dokument. Der findes en række ITsystemer, som understøtter forskellige forretningsprocesser inden for forsyningsverdenen. Er der et behov for at koble nogle af disse systemer til DANDAS/DAN VAND kan der udarbejdes dedikerede snitfladebeskrivelser hertil. Nedenfor er til inspiration anført en ikkeudtømmende liste over disse forretningsprocesser: Tegningsudveksling i henhold til LER Værdiopgørelser Benchmarking Hydraulisk modellering Udførelse af TV og brøndinspektion Opmåling 1.1.2 Fælles forståelse af ledningsnetværk Det er hele grundtanken, at de begreber, der bruges på tværs af forsyningsarter, defineres og forstås ens i alle grene af forsyningsselskaberne. Det betyder således, at der i de nuværende versioner af DANDAS og DANVAND (baseret på kernemodellen) er sket et skift i brug af nogle af begreberne og koderne i forhold til de hidtil gældende versioner. Kernemodellen beskriver det fysiske netværk (punkter, linier og flader) og dertil nært knyttede begreber. Datamodellen indeholder de informationer, der er relevante for ledningsejerne at udveksle med eksterne parter. 1.1.3 Afgrænsning: Kernemodellen indeholder kun de informationer, der er opnået enighed om at være fælles mellem hhv. kloak og vand. Beskrivelsen af forsyningsartspecifikke informationer kan findes i informationsmodellerne for hhv. DANDAS og DANVAND. Der er således i nødvendigt omfang inkluderet nøgler til brug for udveksling og relationer til andre systemer til f.eks. værdiansættelse, koblingsnøgle til SROdata samt nem opstilling af beregningsmodeller. Kernemodellen eksisterer i en helhed, men dele heraf kan på et senere tidspunkt blive udskilt i moduler for begreber, der ikke opfattes som netværkskerne (f.eks. projekter, der er opmærket som modulkandidat). Desuden er modellerne allerede i dag suppleret af moduler, som beskriver selvstændige informationsmodeller (f.eks. TV og Brøndrapporter samt Brudregistrering). Side 8 af 75

Modulariseringen vil bl.a. kunne sikre, at videreudvikling inden for et afgrænset område af informationsmodellen ikke medfører krav om en helt ny version af datamodellen men blot af de elementer, som har relevans for det pågældende modul. Det er ikke en del af en logisk datamodel at beskrive den visuelle repræsentation i GIS dog er labels understøttet som et begreb i DANDAS, men ikke DANVAND, hvorfor det ikke er en del af kernemodellen. 1.2 Læsevejledning / kontekst Dokumentet er opbygget således: Generel indledning, Konceptuel beskrivelse af kernemodellen i 5 niveauer Kapitel 4 til 6.7 indeholder en mere detaljeret beskrivelse af alle begreber inddelt i hvert af de øverste 4 niveauer. Niveau 5 i kernemodellen indeholder relationerne mellem de øvrige 4 niveauer og er derfor beskrevet integreret i kapitel 4 til 6.7 Beskrivelse af livscyklus og databasehistorik Fra kapitel 9 vil hhv. DANDAS eller DANVAND forretningsprocesser, begreber, relationer og attributter blive beskrevet som supplement til Kernemodellens fælles begreber Forståelsen af DDV datamodellerne erhverves gennem hhv. dette dokument og følgende yderligere informationskanaler: UML netværksdiagram (indlejret i figurer i dokumentet) Informationsmodellen under DDV (http://www.detdigitalevandselskab.dk/files/files/ddvreol/ddvreol.html) Indeholder bl.a. en liste over de enkelte attributter til hvert begreb. Informationsmodellen indeholder i kildefeltet til attributterne en kode for de forretningsprocesser, som understøttes af den pågældende attribut. Det står på formen Spildevand 1.0: 7(STIKPRGR) hhv. Vand 1.0:3(HMO), 3(HMO/HMD). Det svarer til at forretningsproces nr. (findes i DDVreolens under Den enkelte proces udefra) skrives uden for parentesen, og selve datastrømmen(e) skrives inde i parentesen). Snitfladebeskrivelser, til brug for de applikationer, der gør brug af / leverer input til ledningsregistreringen Registreringsvejledninger Side 9 af 75

Begrebsdiagrammerne benytter sig af en række standardiserede visninger. For yderligere information henvises til DDVIntegrationsmetoden, der forefindes på DDVReolen. De væsentlige nævnes her: Diagramtekst Relation 0 til mange 0 til 1 1 Netop 1 1..* 1 til mange Knytter sig til Påvirker Indeholder Har Relationer mellem to begreber eller mellem elementer af samme begreb 1.3 Migreringskommentar Der er et selvstændigt migreringsdokument fra den seneste foregående version af hhv. DANDAS og DAN VAND. Det er vigtigt at forstå, at der er nogle tidligere begreber, som stiller krav om oprettelse af både Bestykninger, Funktioner og Konstruktioner med dertil hørende over og underbegreber. Endvidere er der kataloger, som bliver til koder og vice versa. Endelig er der nogle begreber og værdier, som alt efter registreringspraksis hos den enkelte forsyning kan migreres til forskellige koder og forskellige begreber. Migreringsdokumentationen forsøger at ramme de fleste generelle regler, men skal således fortolkes med varsomhed. Endvidere gøres opmærksom på at koden Uoplyst skal migreres til null (ingen værdi) for kodelister fra DANDAS 2.6.2 og DANVAND 1.1. 1.4 Uddybning pr. forsyningsart Dette dokument er en del af en samlet dokumentation af hhv. kernemodellen, DANDASspecifikke begreber og DANVANDspecifikke begreber. Kernemodellens begreber er således overbegreber, som kan forklare nogle fælles karakteristika. Disse overbegreber indeholder de informationer, der er fælles mellem begge forsyningsarter. De underordnede (operationelle) begreber indeholder modelspecifikke informationer. Endvidere er der nogle kernemodelbegreber med fælles attributter og/eller relationer, der også indeholder attributter og koder, som kun anvendes i enten DANDAS eller DANVAND. Disse attributter og koder bliver i så fald kun vist i den respektive forsyningsarts informationsmodel. Grunden til at disse begreber ikke blot er skilt ud i modelspecifikke begreber er, at man derved har en fælles begrebsdannelse på begrebs og relationsniveau. Med henblik på at sikre overskueligheden i UMLdiagrammerne er det besluttet, at der ikke skal Side 10 af 75

opbygges underbegreber med nedarvning fra kernemodellen for de modelspecifikke attributter på disse begreber. Kernemodellen er således en selvstændig model, der SKAL suppleres med enten en DANVAND eller en DANDAS model. Side 11 af 75

2 Forenklet model Nogle af begreberne anvendt i den fælles kernemodel ligger langt fra de termer, som bruges i daglig tale blandt personer, som beskæftiger sig med ledningsregistrering eller ledningsnetværket. Det skyldes bl.a. hensynet til at kunne finde nogle begreber, som både er gældende for spildevand og vandforsyning. Disse fællesbegreber kan anvendes af systemdesignere, som går på tværs af forsyningsarter, mens datamodellens forsyningsspecifikke operationelle begreber i højere grad anvender mere alment genkendelige termer. Målgruppen for den logiske datamodel er således fortrinsvis systemdesignere og ansvarlige for ledningsregistreringssystemet, som i samråd med de forsyningstekniske medarbejdere og registranterne skal sikre, at alles behov bliver tilgodeset i forhold til de forretningsprocesser, som datamodellen skal understøtte. Som beskrevet i foregående kapitel er det en logisk datamodel, der skal beskrive begreberne, disses attributter og relationer imellem disse. Disse sammenhænge vil ikke nødvendigvis være identiske med den fysiske datamodel dvs. hvilke tabeller og attributter, der vil ligge i en implementeret ledningsregistreringsdatabase. Endvidere beskrives hvert enkelt af virkelighedens fysiske elementer af en lang række logiske begreber i en sammenhæng. Begreberne og sammenhængene er dermed logiske i en systemteknisk forstand, men ikke nødvendigvis logiske for en driftsmedarbejder, som er vant til at omtale de fysiske elementer fra den virkelige verden. For at hjælpe med at bygge bro mellem den virkelige verden og den logiske datamodel er nedenfor angivet et par forenklede modeller for ledningsnetværket og de meget overordnede begreber, som den logiske model bygger på. Side 12 af 75

Helt grundlæggende består netværket af nogle ledninger, nogle punktbaserede elementer og nogle forsyningsanlæg, som har en udstrækning. De har ovenstående relationer til hinanden. Anlæg og bygværker er i den logiske model repræsenteret ved begrebet Konstruktion. Ledning betegnes via samme notation i den logiske datamodel. Punktelement er repræsenteret ved hhv. Bestykning og Funktion i den logiske datamodel. Side 13 af 75

Det er centralt for mange forsyninger at håndtere projekter. Det er et administrativt begreb, hvor der kan indgå mange af de førnævnte 3 fysiske elementer i hvert projekt. Endvidere kan det enkelte fysiske element indgå i flere projekter gennem sin livscyklus, hvorfor der reelt er en mangetilmange relation til projekt. Projekt betegnes via samme notation i den logiske datamodel. Side 14 af 75

Den forenklede model kan også udvides med at betragte områder, som f.eks. kan være spildevandsoplande eller sektioner i et vanddistributionssystem. Både ledninger, punktelementer og anlæg kan tilknyttes områder. Egentlig er det tilstrækkeligt at lade et anlæg repræsentere ved et punkt (en Knude), som også kan være den geografiske repræsentation for et eller flere punktelementer, og som endelig kan være endepunkter for en ledning. Dermed er det en helt grundlæggende forudsætning for DANDAS og DANVAND (og dermed kernemodellen), at en ledning SKAL starte og slutte i et knudepunkt. Hvis en lednings ene endepunkt tilknyttes ét område og det andet ledningsendepunkt tilknyttes et andet område, så er ledningen dermed forbindelsesled mellem to forskellige områder, og man kan rent konceptuelt tilknytte halvdelen af ledningen til hvert område. Område og Knude betegnes via samme notation i den logiske datamodel. Der kan på tilsvarende vis føjes en lang række yderligere begreber fra den virkelige verden til den forenklede model, hvilket i sidste ende et blevet beskrevet i den logiske datamodel som anført i næste kapitel. Det er blot vigtigt at forstå, at det er en måde at omsætte de simple konceptuelle modeller til en datamæssigt korrekt men også relativt kompleks datamodel, hvor de overordnede begreber ovenfor er nedbrudt i detaljerede begreber og relationer. Side 15 af 75

Figur 2 UMLdiagram af kernemodellen Side 16 af 75

3 Generelt om kernemodellen 3.1 Kernemodellens struktur Figur 2 viser et UMLdiagram for hele Kernemodelmodellen. Der henvises til DDVreolen for en mere læsbar udgave af diagrammet. I de følgende afsnit vises udsnit af ovenstående model evt. reorganiseret eller forenklet for at understrege specifikke forhold. Kernemodellen er fastlagt ud fra et princip om at kunne forstå begreberne i en geometrisk kontekst og en fysisk / hydraulisk / topologisk kontekst. Dvs. den bygger på en generel (universel) forståelse af et ledningsnetværk uden hensyn til forsyningsart. For alle begreberne gælder en række relationer, som fremgår af både informationsmodellen og UML diagrammet. Disse relationer vil som hovedregel ikke blive gentaget i dette dokument. Der er dog medtaget en uddybende forklaring i de tilfælde, hvor der kan være tvivl, eller hvor de ønskede regler ikke er afspejlet tilstrækkeligt tydeligt gennem standard relationer. Når der er en nedarvning (specialisering) fra et begreb til et andet, så markeres det med en lukket ikkeudfyldt pil i UMLdiagrammet. Det betyder, at man f.eks. skal læse, at en Funktion arver fra en Knude, da Funktion er en specialisering af det generelle begreb Knude. Med andre ord, arver Funktion alle relationer og attributter fra Knude, men Knude har ingen af relationerne og attributterne fra Funktion. 3.1.1 Forskel på kodelister og kataloger Som supplement til disse objekter og deres indbyrdes forhold findes der også hhv. koder og kataloger. I dette dokument bruges herefter betegnelsen katalog. Alle koder har en foruddefineret kodeliste, som er fastlagt af standarden. Koder og kodelister kan ikke ændres af en bruger eller systemadministrator. Skal der ændres på denne liste, må det således kun ske i DANVAregi. Der henvises til informationsmodellen på DDVreolen for en visning af de anvendte kodelister og koder i relation til de enkelte begreber. Koder er ikke obligatoriske attributter. Der kan dermed undlades at angive en kode, der kan angives en reel kodeværdi eller der kan for de fleste kodelister angives koden Ukendt, som betyder at man har taget stilling. For attributterne Datoetableret, Statuskode og Datostatus opfordres kraftigt til, at de udfyldes med en værdi (Statuskode <> Ukendt) ved ajourføring og registrering, da livscyklusfastlæggelsen er central for alle elementer. Side 17 af 75

For katalogerne er datastrukturen fastlagt af standarden. Antallet af valgmuligheder heri kan ændres af den enkelte forsyning / bruger. Der er for nogle kataloger givet et forslag fra DANVA s side for at hjælpe standardiseringen og med en fælles forståelse på tværs af forsyningsselskaber og øvrige brugere. Katalogerne beskrives i øvrigt yderligere under afsnit 3.1.5. Det er ikke et krav, at der implementeres kataloger i den fysiske datamodel. Men det er et krav, at man benytter kataloger i forbindelse med udveksling. Hvis der ikke benyttes kataloger i den fysiske datamodel, skal de således oprettes med udvekslingsnøgler i forbindelse med udvekslingen for bl.a. at reducere mængden af redundante data i udvekslingsøjemed. Niveau opdeling I den følgende detaljerede beskrivelse af Kernemodellen er der foretaget en opdeling i følgende strukturelle niveauer: 1. Geometriske begreber [røde i UML diagrammet] 2. Begreber for fælles fysiske elementer, som kan genfindes i virkeligheden [blå]. Disse fælles begreber for fysiske elementer kan suppleres i hhv. DANDAS og DANVAND med fysiske elementer, der ikke er fælles 3. Administrative begreber, som definerer samhørende fysiske eller geometriske elementer (for strækningers vedkommende) [gråblå] 4. Supplerende begreber og kataloger [grønne] 5. a: Referencer og relationer [gule] b: Virtuelle referencer og relationer. Se detaildiagrammer. [hvide] Alle begreber på niveau 14 indeholder en obligatorisk GUID (Global Unique Identifier), enten direkte eller nedarvet. Alle fysiske begreber samt begrebet Område oprettes som standard med informationer om status jf. livscyklusmodellen, som er beskrevet i kapitel 8. Endvidere angives for alle begreber, hvornår elementet er oprettet, opdateret og af hvem. Endelig er der til nogle af begreberne også knyttet databasehistoriske informationer for bl.a. at lette sporbarhed af objekter ved udveksling med eksterne systemer. Status og andre tilsvarende fælles attributter er som grundregel knyttet til begreberne på det første strukturelle niveau (fra niveau 1 og stigende) med mulighed for nedarvning til underliggende niveauer. 3.1.2 Niveau 1: Geometriske begreber Følgende begreber beskriver den grundlæggende geometri i netværket (punkt, linie, flade): Knude Linie Flade Side 18 af 75

Den grundlæggende del af kernemodellen består af Knuder og Linier med en indbyrdes sammenhæng. Således har en Linie en Knude i hver ende. En ringforbindelse i DANVAND kan dog benytter en Linie, der er defineret som startende og sluttende i samme Knude med mindst en vertex imellem. Desuden findes Flader, der bl.a. beskriver udbredelsen af Konstruktioner i netværket. Flade eksisterer som et begreb, der via grupperingreference kan være knyttet til begrebet gruppering på niveau 2, men det er ikke en del af den grundlæggende geometri i ledningsnetværket. 3.1.3 Niveau 2: Fysiske elementer i virkeligheden Disse begreber er de fysiske elementer der kan findes i virkeligheden. Netværket (Knuder og Linier) består af Funktioner, (der stammer fra Knude) og Ledninger (der stammer fra Linie). Funktion er overbegrebet for et punktobjekt, som beskriver de hydrauliske karakteristika inddelt i følgende fire begreber efter deres hydrauliske virkemåde: Reservoir Volumen Regulering Aktiv mulighed for ændring af strømning Forbindelse Hydraulisk forbindelse / forgrening Tilslutning Hydraulisk tilslutning uden opsplitning af Linie Bestykning er et punktobjekt, der ikke har nogen hydraulisk betydning og ikke indgår i netværket, men som er knyttet til netværket i en Knude eller i en Linie. Begrebet Konstruktion definerer bygningsanlæg, der kan indeholde en gruppering af et eller flere fysiske elementer. Konstruktion kan have tilknyttet et eller flere fladeobjekter via grupperingreference. Derved kan en Konstruktion have referencer til flere flader. Det kan være én af flere måder at beskrive en Konstruktion geografisk, som består af flere usammenhængende eller hullede objekter. 3.1.4 Niveau 3: Administrative puljer (Grupperinger) Følgende begreber er konceptuelt forskellige typer af Grupperinger af fysiske elementer; Knuder, Linier (og derigennem Bestykninger) og Konstruktioner: Projekt Område Strækning De forskellige Grupperinger indeholder væsentligt forskellige informationer, relationer og geografiske repræsentationer (flader, intet objekt eller gruppering af linieobjekter). Projekt og Område har de samme relationer Side 19 af 75

til og regler for fladeobjekter som Konstruktion. Strækning har normalt ikke tilknyttet nogen geometri, men kan f.eks. beskrives geometrisk ved en kombination af de tilknyttede Linier. Desuden findes følgende øvrige administrative begreber: Aktivering Opmålingspunkt Note Føringsvej ReservoirGeometri 3.1.5 Niveau 4: Supplerende begreber og kataloger Følgende begreber kan opfattes som kataloger; dvs. datamæssigt samhørende informationer, som begreberne på niveau 2 og 3 kan relatere til. Derved er det muligt med enkelte nøgler at angive en række informationer, som kan være fælles med mange elementer i netværket. Disse begreber kan opfattes som værende en normalisering af informationerne i en databaseterminologi, hvilket betyder at man ikke behøver at skrive samme værdi gentagne gange, men kun behøver at vælge fra en liste med ønskede værdier. Antallet af poster i de tabeller, der kan repræsentere begreberne, er brugerdefinerede. Informationerne knyttet til begreberne er derimod fastlagt af standarden. For en række af disse begreber gælder, at DANVA har fastlagt en standardiseret liste fra starten, der ikke må slettes, men som det dog er tilladt at udvide. Aktiveringtype Ejer Firma Firmatype Link Linktype Materiale MaterialeGruppe Områdekategori Områdekategoriniveau Oprindelse Projektårsag Anlægstype Procestype ReservoirKotetype ReservoirVolumentype Rør Strækningtype Side 20 af 75

3.1.6 Niveau 5: Referencer og relationer Følgende begreber markeret med hvid eller gul farve i UML oversigtsdiagrammet repræsenterer underordnede begreber, referencer og relationer mellem de øvrige begreber. Begreberne markeret med hvid baggrund angiver, at det reelt er en gruppe af selvstændige referencer, som det vil være for uoverskueligt at angive i det samlede diagram. Derfor er de vist enkeltvis på underdiagrammer hhv. i figurer i nærværende modeldokumentation. Når der er en reference, skyldes det, at der er en mangetilmange relation mellem flere end to begreber. Hvis der er en entilmange eller entilen relation, er det blot udtrykt ved en simpel relation. Tilsvarende; hvis mangetilmange relationen kun er internt på samme begreb eller mellem 2 begreber bruges ikke en gul kasse til referencen. Derfor er der f.eks. intet referencebegreb i UMLdiagrammet mellem Materiale MaterialeGruppe og Firma Firmatype. Da de opfattes som underordnede begreber, beskrives disse ikke selvstændigt. De bliver gennemgået i nødvendigt omfang (hvis der kan være tvivl om, hvordan de skal bruges og hvilke regler, der gælder for relationerne) i sammenhæng med beskrivelsen af det første begreb, som de knytter sig til. Aktiveringreference Ejerandel Firmareference Grupperingreference Linkreference Områdehierarki Oprindelsereference En reference kan kun eksistere, hvis der er netop én relation til hhv. hovedbegrebet og mindst et underbegreb. Det betyder f.eks. at der kun kan eksistere en Grupperingreference, hvis der er en relation mellem én Gruppering og mindst én Flade, Line, Knude eller Konstruktion. 3.2 Moduler 3.2.1 Selvstændige datamodeller Ud over DANDAS og DANVAND, der som tidligere nævnt er datamodellerne for ledningsregistreringsdata for kloak og vand, er der følgende selvstændige datamodeller: Kabler, Fremmedrør og Flader er et modul med sin egen datamodel, som knytter sig til hhv. DANDAS og DANVAND via nogle snitflader til begreberne i Kernemodellen. Side 21 af 75

TVinspektion og Brøndrapport er et modul med sin egen datamodel, som knytter sig til DANDAS via nogle snitflader til begreberne i Kernemodellen. Brudregistrering er et modul med sin egen datamodel, som knytter sig til DANVAND via nogle snitflader til begreberne i Kernemodellen. 3.2.2 Modulkandidater Følgende begreber er blevet markeret med et M i UML diagrammet: Område (samt Områdehierarki, Områdekategori og Områdekategoriniveau) Projekt (samt Projektårsag, Anlægstype og Procestype) Aktivering (samt Aktiveringtype og Aktiveringreference) Disse begreber er identificeret som kandidater til eventuelt at blive udskilt i selvstændige moduler ved efterfølgende modelopdateringer. Der stilles ikke krav fra DANVA s side om, at applikationshuse skal understøtte begreber, der er modulkandidater. Side 22 af 75

4 Geometriske begreber De geometriske objekter i kernemodellen, markeret med rødt i UMLdiagrammet, er hhv. punkt, linie og fladeobjekter. De udveksles i WKT formatet. Det skal særligt bemærkes, at liniernes geometri indgår i sit fulde forløb i det geometriske objekt, dvs. både start, knæk og slutpunkter, hvilket er en ændring i forhold til de foregående versioner af DANDAS / DAN VAND. Men disse punkter skal være sammenfaldende med knudernes (endeknudernes) (X,Y)koordinater, da der skal være overensstemmelse mellem geometri og topologi i 2D. Kernemodelmodellen er rent geografisk en 2½D model. Det betyder i praksis, at man kan udveksle koordinater i 3 dimensioner. Hvis Z ikke kendes, så er det vedtaget, at der i forbindelse med udveksling skrives Z=99, som repræsentant for en ukendt værdi (dvs. ikke angivet Z). Det skyldes, at det er vedtaget, at man ved udveksling af geometrier bruger wellknown text (WKT). Den håndterer ikke null i et koordinat. Der er ikke krav om topologisk sammenhæng i den 3. dimension (Z). Der er mulighed for at angive (og dermed udveksle) en lang række koter som informationer knyttet til de enkelte begreber, hvorved applikationer vha. de udvekslede data f.eks. kan danne profiler af ledningstracéer ud fra disse informationer. Hvis gruppering er repræsenteret af et objekt, skal det være et fladeobjekt. Det må gerne være et multipolygonobjekt med huller men uden overlap. 4.1 Knude Begrebsforklaring: Knude er en abstraktion af et punkt. Linier starter og slutter i knuder, men en Knude kan også knyttes til en Linie uden at bryde den (ikke brydende Knude). Den ikkebrydende Knude (Tilslutning) har da en anden relation til linien. En Knude repræsenterer et punkt i planen, der også kan indeholde en kote og en terrænkote. På spildevand skal koten i knuder være lig med den indvendige bundkote i brønden (eller ledningen, såfremt der ikke er en brønd). Udløbskoten kan både være over og under bundkoten. For vand skal koten i knuder være lig med topkoten af ledningen En Knude behøver ikke være relateret til en Linie. En eller flere Bestykninger kan være knyttet til knuden. En Knude, der repræsenterer en Konstruktion, kaldes Konstruktionens hovedknude. En Knude skal indeholde Side 23 af 75

netop én Funktion. I den logiske model repræsenterer knuden lokaliteten og Funktionen repræsenterer de fysiske forhold såsom status, ejerforhold, materiale og hydrauliske karakteristika. Disse karakteristika kan i den logiske model være placeret på begrebet Funktion eller på nogle af de underordnede begreber, hvis det ikke er en fælles information for alle Funktioner. En Knude har som primær nøgle en unik GUID, der skal udveksles. Derudover har Knude også et unikt (og dermed obligatorisk) navn. Uddybning af relation bliver til : Denne relation anvendes i forbindelse med databasehistorik, som tages i anvendelse ved ændringer af knudefunktioner, hvor snitfladen til andre systemer skal sikres. Det må ikke forveksles med en fysisk erstatning, der håndteres som en livscyklusproblematik. 4.2 Linie Begrebsforklaring: En Linie er en geometrisk / topologisk forbindelse, der forbinder to knuder. Linien skal ved udveksling beskrives i et 3D objekt, hvor koten ikke er obligatorisk, og hvor koten ikke har betydning for topologien af netværket. Derudover kræves sammenhæng i det vandrette plan men ikke i det lodrette plan. Der er en 1..1 relation fra Linie til Knude. Det betyder, at det er obligatorisk at oprette en Knude i hver ledningsende. En Linie har som primær nøgle en unik GUID, der skal udveksles. Men samtidig udveksles også en unik nøgle, som er en kombination af de to relationer til Knudenavn1 og Knudenavn2 samt attributten Løbenr. Dette sikrer, at der i forbindelse med dataudveksling kan sikres entydighed i ledningsregistreringen ved evt. konflikter ved sammenfald af knudenavne og løbenr. Forsyningen kan selv opstille regler for konflikthåndtering, hvis der udveksles Linier, hvor der ikke er overensstemmelse mellem de oplysninger, der findes i ledningsregistreringen hhv. de udvekslede (modtagne) oplysninger. Uddybning af relation er inden i : En Linie kan være inden i en Linie. En indre Linie skal være på det umiddelbart lavere niveau end den omsluttende (ydre) Linie. Denne relation svarer (med modsat fortegn) til relationerne består af under som findes på begreberne Projekt og Strækning. Det svarer til, at der er et rør, som er inden i et andet rør. På spildevand har man traditionelt opfattet et foringsrør (strømpeforing) som et rør, der er inden i et andet rør typisk omtalt som sanering. På vandforsyning har man traditionelt opfattet et foringsrør som en beskyttelse eller en føringsvej f.eks. under jernbaner hvori der føres et vandrør, men også i forbindelse med renovering. Begge disse rørirør relationer kan stadig finde anvendelse i kernemodellen. Det vil dog kun være rør, der er etableret som medierør (vandrør eller kloakrør), der skal oprettes som en Linie. Fremmedrør og dermed Side 24 af 75

også f.eks. førnævnte beskyttelsesrør skal oprettes i modulet Kabler, Fremmedrør og Flader. Der er ingen regler for, hvor mange indre rør, der må være inden i omsluttende rør. Uddybning af relation samlet til og delt fra : Disse relationer anvendes i forbindelse med databasehistorik, som tages i anvendelse ved fejlregistrering eller ved deling og samling af Linier. Ved snitflader til andre systemer (f.eks. værdihåndtering) vil der være behov for at kende deres oprindelige ID. Databasehistorik må ikke forveksles med en fysisk erstatning, som håndteres som en livscyklusproblematik. Der henvises i øvrigt til kapitel 8 for en mere uddybende forklaring af databasehistorik inkl. illustrative eksempler. 4.3 Flade Begrebsforklaring: En flade er et geometrisk objekt, som kan beskrives i et 3D objekt, hvor koten ikke er obligatorisk, Flader er som sådan ikke en del af netværket, men kan repræsentere grupperinger via grupperingreference. Derigennem kan Flade således beskrive den geografiske udstrækning af alle typer af Områder, Projekter og Konstruktioner. Side 25 af 75

5 Begreber for fysiske elementer i virkeligheden Nedenstående begreber repræsenterer ting, som man kan se og røre i virkeligheden. Derfor betegnes de her som fysiske elementer ikke at forveksle med en fysisk datamodel. De er markeret med blå farve i UMLdiagrammet. Ud over Kernemodellens begreber for fysiske elementer, som er fælles for vand og kloak, er der yderligere sporspecifikke operationelle begreber for fysiske elementer, som behandles særskilt under DANDAS og DANVAND beskrivelserne. 5.1 Bestykning Begrebsforklaring: Bestykninger er elementer, som ikke påvirker hydraulikken, men som alligevel er knyttet til netværket i en Knude eller til en Linie. Målere og dæksler er eksempler på Bestykninger. En Knude og en Linie kan bestykkes med en eller flere Bestykninger. En Bestykning skal være knyttet til enten en Linie eller en Knude. Side 26 af 75

En Bestykning har en selvstændig geometrisk beskrivelse af (x, y, kote), da den ikke nødvendigvis sidder i samme punkt som en Knude eller på en Linie, men blot skal referere til mindst én af disse. Underbegreber: KnudeBestykning, KnudeLinieBestykning og LinieBestykning. En KnudeBestykning SKAL knyttes til netop én Knude. En LinieBestykning SKAL knyttes til netop én Linie. En Samling er et operationelt begreb for en LinieBestykning. Det hed tidligere Enkelsamling_Van i DANVAND, men disse fysiske elementer er nu fordelt på hhv. Samling og nogle operationelle begreber under Forbindelse hhv. Tilslutning. Samling begrebsforklaring: Indeholder oplysninger om hvorledes 2 ledninger er koblet til hinanden. Der er tale om godkendte samlingsmetoder. Samling er simple ikkebrydende samlinger, hvor de knyttes til én ledning. Der er således ikke tale om samlinger mellem to ledninger. Er det denne type samling, der skal registreres, så vil det være som Funktionen Forbindelsespunkt. Se også afsnit 0. En KnudeLinieBestykning SKAL knyttes til netop én Knude ELLER Linie. En Måler er et operationelt begreb for en KnudeLinieBestykning. Måler begrebsforklaring: Indeholder oplysninger om måler monteret i netværket. Der kan eksempelvis være monteret flowmåler, som måler hvor meget vand, der passerer forbi flowmåleren; eller en iltmåler, som måler iltindholdet i vandet inden udledning til recipient. Uddybning af relation Bliver til : Denne relation anvendes i forbindelse med databasehistorik dvs. hvis én Bestykning erstattes af en anden Bestykning grundet fejlregistrering. Det må ikke forveksles med en fysisk erstatning, som håndteres som en livscyklusproblematik. Denne relation findes også for Knude og Konstruktion, og der henvises til kapitel 8, for en nærmere beskrivelse heraf. Uddybning af relation Har måleretning fra : En Måler skal være knyttet til enten en Knude eller en Linie. Hvis det er en retningsbestemt måling (f.eks. flow) knyttet til en Knude, skal den også have en relation til den af de tilknyttede Linier, som den måler fra, så der er en retningsangivelse på måleren / de resulterende målinger. 5.2 Funktion Begrebsforklaring: En Funktion beskriver et fysisk element i netværket, der som grundregel har en hydraulisk betydning. En Funktion er et nedarvet begreb fra Knude (En Funktion er en Knude). En Knude har dermed til enhver tid én hydraulisk Funktion. Side 27 af 75

I den logiske model repræsenterer knuden lokaliteten og Funktionen repræsenterer de fysiske og administrative forhold såsom status, ejerforhold, materiale og hydrauliske karakteristika. Der kan også oprettes en Funktion af administrativ karakter. Det bryder med princippet om, at en Funktion skal have hydraulisk betydning, men er nødvendig for at kunne beskrive hovedknuder for Konstruktioner hhv. de mange ukendte hhv. ikkeeksisterende forbindelser mellem ledningsender, hvor der sker skift i ejerforhold undervejs på en ledningsstrækning. Knuden skal da oprettes med en ikkehydraulisk Funktion, som en AdministrativOvergang. Knuden har da alene en administrativ betydning. I forbindelse med udveksling skelnes mellem Knude og Funktion. Men en Funktion er en Knude. Derfor skal man ved validering være opmærksom på, at der kan være specificeret en Funktion, der peger på en Knude, som først senere i udvekslingsfilen bliver defineret. Funktionen kan erstattes af en ny Funktion grundet fejlregistrering. I den forbindelse skal den nye Funktion pege på den oprindelige Knude, og der oprettes en ny databasehistorisk Knude til den oprindelige Funktion, som også gøres databasehistorisk. Der kan også ske et skift i Funktion på en Knude ved en fysisk erstatning af en Funktion med en anden (fornyelse). Der er, som nævnt i afsnit 3.1.3, fire hydraulisk forskellige Funktioner, som er generaliserede funktionelle elementer for fysiske elementer, der hver især er karakteriseret ved en specifik hydraulisk virkemåde. De er konkretiseret og underinddelt i selvstændige begreber i hhv. DANDAS og DANVAND, hvor de hydrauliske virkemåder bliver respekteret. 5.2.1 Reservoir Begrebsforklaring: Et reservoir er et element med et volumen, som bliver repræsenteret af et punkt i netværket. Der knytter sig en lang række koter til reservoirer, og der kan også knytte sig en tabel med sammenhæng mellem kote, overflade og tværsnitsareal samt volumen til reservoirer. Der kan således ske en opmagasinering af vand/spildevand i et reservoir evt. med nogle konsekvenser for trykket i det tilsluttede netværk som dermed har betydning for en hydraulisk modellering af netværket. Underbegreber: Tank og Magasin Tank begrebsforklaring: Tank er et reservoir; ofte en (standard)beholder, hvor opmagasineringsevnen er mindre væsentlig end Funktionen. Side 28 af 75

Magasin begrebsforklaring: Et magasin knytter sig altid til et givent Reservoir, hvilket betyder, at det er muligt at angive, hvor meget vand der kan tilbageholdes i magasinvolumenet inden det sendes videre i ledningsnettet. Forskellen er, at en Tank har et fast volumen, mens et Magasin har et variabelt volumen. 5.2.2 Regulering Begrebsforklaring: En Regulering er en Knude i netværket, hvor der kan ske en ændring af strømningen uden mulighed for opmagasinering af vand. Dvs. summen af flow i Ledninger før og efter en Regulering er det samme til alle tider. Reguleringen kan rent fysisk ske ved hjælp af pumper og ventiler/spjæld, hvorved vandstrømmen både kan løftes og begrænses i en Regulering. Nogle af de fysiske Reguleringer er retningsbestemte (f.eks. Pumpesteder og kontraventiler / trykreduktionsventiler), hvorved der skal angives en definitionsretning i forhold til de Ledninger, der er tilsluttet Knuden med Reguleringen. Underbegreber: Pumpested, Ventil og RetningsRegulering Pumpested begrebsforklaring: Pumpested er der, hvor vandet pumpes fra af en eller flere pumper. Selve pumperne registreres ikke i Kernemodellen. En evt. pumpesump registreres særskilt som reservoir type. Flere pumpesteder kan samles i en Konstruktion af typen Pumpestation. I kernemodellen registreres det sted, hvor pumperne sidder som et pumpested. I DANVAND kan selve pumpen også registreres. Ventil begrebsforklaring: Ventiler med afspærringsformål o.lign., som ikke er retningsbestemte. RetningsRegulering begrebsforklaring: Retningsbestemt regulering af strømningen; typisk i en trykledning. Styret manuelt, hydraulisk, elektrisk eller uden styring. Uddybning af relation Regulerer flow fra : For retningsbestemte Funktioner, som altid vil være reguleringer af typen RetningsRegulering eller Pumpested, kan der ændres på hydraulikken ved ændring af Funktionen. Denne relation beskriver således, fra hvilken Ledning reguleringen kan ske, hvilket er særligt vigtigt at angive, hvis der er flere end 2 Ledninger forbundet til Reguleringen. 5.2.3 Forbindelse Begrebsforklaring: Et sted i netværket, hvor ledninger forbindes hydraulisk, uden at det reguleres aktivt. Side 29 af 75

En Forbindelse sikrer, at der kan løbe vand mellem ledninger, hvis endepunkter er knyttet til Forbindelsen. I tilfælde, hvor Forbindelsen kun må knyttes til netop én Ledning, angiver Forbindelsen et udløb, indløb eller et endepunkt i ledningsnettet. Der kan ikke ske en opmagasinering eller regulering af vandstrømmen ud over de almindelige hydrauliske regler for enkeltmodstande i den givne Forbindelse. Eksempler på Forbindelser er afgreninger. En Forbindelse på en Knude knyttet til en Lednings Linie vil altid være brydende for Ledningens Linie og dermed sidde i en start eller slutknude. En Forbindelse har kun lille hydraulisk effekt i form af f.eks. opbremsning af strømningen ved samlinger. I DANVAND er Forbindelser ofte Tstykker eller FysiskOvergang, hvorimod simple muffesamlinger vil være en LinieBestykning. I DANDAS vil ca. 80% af alle forbindelser være simple brønde. Underbegreber: AdministrativOvergang, FysiskOvergang og Forsyningspunkt. AdministrativOvergang begrebsforklaring: Punkt UDEN hydraulisk og betydning og UDEN fysisk skift, som beskriver en administrativ forbindelse mellem netop to ledninger. Det kan således f.eks. være skift i ejerforhold eller etableringsdato. FysiskOvergang begrebsforklaring: Punkt med hydraulisk betydning, som beskriver en forbindelse mellem netop to ledninger. Hvis der både er en AdministrativOvergang og en FysiskOvergang, registreres det som en FysiskOvergang. Forsyningspunkt begrebsforklaring: Punkt som beskriver et endepunkt i det registrerede ledningsnet, hvorfra forbrugere (Forbrugssteder) forsynes. Har ud over forbruget IKKE hydraulisk betydning. Installation. 5.2.4 Tilslutning Begrebsforklaring: Objekt, der gør det muligt at koble en ledning på en anden ledning uden at bryde den anden ledning. En Tilslutning sidder i den ene ende af en Ledning (som oftest en stikledning) og har en reference til en ubrudt Ledning, hvor der i DANDAS er mulighed for at angive et offset til den ubrudte ledning. Tilslutningen repræsenterer den hydrauliske forbindelse mellem de to Ledninger. Der er således oftest tale om en stikledningskategori i endeknudens tilsluttende Linie. Endeknuden er samtidig en ikkebrydende Knude på den tilsluttede Linie. Der er således ved tilslutninger en påvirkning af hydraulikken gennem enten et forbrug eller et bidrag fra/til en Linie, som ikke er brudt ved Tilslutningen. Side 30 af 75

Den tilsluttede Linie angives gennem relationen sidder på. Underbegreb: TilslutningsPunkt. Begrebsforklaring: Ikkebrydende tilslutning af (stik)ledning. Et Tilslutningspunkt beskriver den fysiske komponent, der oftest anvendes ved stikledningers tilslutning til hovedledninger. Det kan dog forekomme, at der er én hovedledning, som ikke er tilsluttet som en afgrening / Tstykke til en anden hovedledning. I så fald registreres forbindelsen også som et Tilslutningspunkt. Det understreges dermed, at det er den fysiske Forbindelse, der bestemmer, om man registrerer forbindelsen som en Tilslutning eller en Forbindelse. 5.3 Ledning Begrebsforklaring: Fysiske oplysninger om ledninger, der forbinder Funktioner (komponenter) i et sammenhængende netværk. En Ledning er den fysiske beskrivelse af den geometriske Linie. Forhold omkring geometriske sammenhænge mellem Ledninger er beskrevet under begrebet Linie, idet Ledning er en specialisering af Linie. I forbindelse med udveksling skelnes mellem Linie og Ledning. Men en Ledning er en Linie. Derfor skal man ved validering være opmærksom på, at der kan være specificeret en Ledning, der peger på en Linie, som først senere i udvekslingsfilen bliver defineret. En Linie må ikke eksistere uden en Ledning og vice versa. Ledninger i kernemodellen er lukkede rør. Grøfter, kanaler og åbne rør håndteres i DANDAS sporet. Disse begreber beskrives i Rør hhv. knyttes til Rør som bl.a. profilbeskrivelser. En Ledning kan bl.a. beskrives gennem sin ledningskategori, ledningsfunktion og mediekode (det medie den fører). Uddybning af relation erstatter : Ved fornyelse kan angives, hvilke(n) nye(e) Ledning(er), der erstatter nedlagte Ledninger, så modelleringsdata og driftsopgaver kan overføres automatisk. Denne relation bruges således ved fysisk fornyelse. 5.4 Konstruktion Begrebsforklaring: "Bygningsanlæg, der kan indeholde en eller flere Funktioner, Bestykninger og ledninger samt evt. andre Konstruktioner. Udbredelsen kan beskrives med et fladeobjekt. En Konstruktion er en Gruppering. Gruppering beskrives som fællesbegreb for Konstruktion, Projekt, Område og Strækning i afsnit 6.1. Side 31 af 75

En Konstruktion kan være repræsenteret af en hovedknude, som bruges til at repræsentere Konstruktionens placering med et (x,y) punkt. Underbegreber: Bassin og Pumpestation Bassin begrebsforklaring: Et bassin tilbageholder vand med henblik på senere videreledning eller rensning (f.eks. ved udfældning). Et Bassin skal dermed knyttes til en hovedknude med Funktionen Magasin, da der er knyttet en opmagasineringsmulighed til Bassin. Der kan indgå overløb og regulering af videreledningen af vand i bassiner. Pumpestation begrebsforklaring: Anlæg, hvis primære funktion er at løfte eller trykke vandet videre i ledningssystemet. Hovedknudens Funktion bør være et pumpested (DANVAND) eller pumpesumpen (DAN DAS). Der kan tilknyttes et eller flere pumpesteder til en pumpestation. Pumpestationer er større Konstruktioner, hvor hovedfunktionen er pumpning (Regulering) af vand videre i netværket. Pumpestationer består typisk af en til flere Pumpesteder, samt Magasin, pumpesump og nødoverløb. Side 32 af 75

6 Administrative begreber De administrative begreber kan både bestå af ét eller flere elementer, men det vil typisk være flere (mange). Disse begreber er markeret med gråblå farve i UMLdiagrammet. Disse begreber (samt Konstruktion) er alle Grupperinger, der beskrives i detaljer nedenfor. 6.1 Gruppering Begrebsforklaring: En Gruppering definerer samhørende fysiske objekter; eksempelvis ledninger, Bestykninger, Funktioner og/eller Konstruktioner. En Gruppering kan også definere samhørende grupperinger. Med sidstnævnte sætning menes, at Konstruktioner, som er en Gruppering, kan indeholde en eller flere Konstruktioner og de øvrige grupperingsbegreber kan bestå af underelementer. Mere herom nedenfor. Grupperingreference er en mangetilmange relation mellem Gruppering og de objekter, der kan indgå i / tilknyttes Grupperingen. I realiteten vil man opfatte relationen som gående mellem f.eks. Projekt og de fysiske elementer Ledning, Funktion og Konstruktion, men da en Funktion er en Knude og Ledning er en Linie, er relationerne i UMLdiagrammet sat på det første niveau. Grupperingen identificeres med den primære nøgle GUID, men vil i udvekslingsøjemed også inkludere den obligatoriske men ikke unikke nøgle Navn. Det er derfor GUID, der officielt benyttes som reference, hvorved man skal være opmærksom på, at der kan forekomme redundans i forhold til navnet. Uddybning af relation består af under : Der er mulighed for at bruge den selvrefererende relation består af under for hhv. Projekt og Strækning. Områder har en tilsvarende relation via består af under relationen mellem Område og Områdehierarki. I Side 33 af 75

alle disse tilfælde skal der angives et niveau for begreberne. Relationerne må endvidere kun oprettes fra elementer på et højere niveau til elementer på det umiddelbart underliggende niveau. Et overprojekt på niveau 2 kan således kun bestå af underprojekter på niveau 1. Der må ikke springes niveauer over. Uddybning af relation Grupperingreference indeholder Konstruktion: Denne relation udtrykker, at der er mulighed for (men ikke krav om) en mangetilmange relation mellem på den ene side Konstruktion, Projekt og Område og på den anden side en Konstruktion. Et Projekt kan indeholde mange Konstruktioner, som på den anden side også kan indgå i flere Projekter hhv. i flere Områder og Konstruktioner. En Strækning må dog ikke bruge denne relation. Den vil normalt kun relatere til Ledninger via Linier (men kan også relatere til Funktioner og Bestykninger via hhv. Knuder og Linier) gennem Grupperingreferencen. Uddybning af relation Gruppering har Grupperingreference: En Grupperingreference findes kun, hvis der er netop én Gruppering og mindst én relation til enten Linie, Knude eller Flade. For Projekt, Område og Strækning er det kun elementer på niveau 1, der må have Grupperingreferencer til begreberne Linie / Knude. Tilsvarende er det kun Projekter og Områder på niveau 1, der må have en Grupperingreference til Konstruktion via relationen indeholder mellem Grupperingreference og Konstruktion. Relationen består af under sikrer, at overordnede niveauer også indeholder relationerne fra de underordnede elementer. Relationen Udbredelse : En Gruppering kan have en udbredelse defineret ved et eller flere fladeobjekter Det er dermed ikke et krav at en Gruppering har en udbredelse (er repræsenteret af et fladeobjekt). 6.1.1 Projekt Begrebsforklaring: Beskriver både planlagte, igangværende og udførte projekter. Indeholder oplysninger for en samling af elementer (Konstruktioner, Ledninger, Funktioner og Bestykninger) der indgår i projektet. Der kan også tilknyttes en flade, der definerer udstrækningen. Side 34 af 75

6.1.2 Område Begrebsforklaring: Beskriver et administrativt eller geografisk element, som kan være en gruppering af elementer i netværket hhv. andre områder på et lavere hierarkisk niveau. Det kan være repræsenteret ved et geografisk fladeobjekt. Områder er en speciel gruppering grundet deres indbyrdes relationer. Formål: Områder giver mulighed for at visualisere en geografisk afgrænsning hhv. gruppere nogle elementer, så man kan opsummere eller behandle en gruppe af Konstruktioner, Funktioner, Bestykninger (via relationen til Linie og/eller Knude) samt Ledninger med hinanden via Gruppering. Til begrebet Område knytter sig følgende begreber: Områdehierarki Områdekategori Områdekategoriniveau Område og de relaterede begreber er modulkandidater. Områder skal kategoriseres i én af de brugerdefinerede Områdekategorier, og hvis der ønskes mulighed for at arbejde med Områder i flere niveauer, skal disse niveauer for den pågældende kategori først defineres i Områdekategoriniveau begrebet. Derefter kan hvert Område tildeles en gyldig kategori hhv. niveau. Der foreligger forslag til standardværdier for Områdekategorier og Områdekategoriniveauer. De fleste Områdekategorier forventes oprettet uden niveaudefinitioner. Der er en selvrefererende relation mellem Område og Områdehierarki, som knytter sig til muligheden for (ved Områder med flere niveauer) at kunne angive en relation mellem et Område på et overordnet niveau med et eller flere Områder på det umiddelbart underliggende niveau. I begrebet Områdehierarki kan defineres en periode, hvor den angivne relation er gældende. Derved kan den tidslige dynamik i forbindelse med sektionering eller f.eks. udvidelse af forsyningsområdet defineres. Eksempler på anvendelse af Område og Områdehierarki: 1. Fire geografiske kommunegrænser fra før kommunesammenlægningen er nu blot en del af samme kommune. Der vil da være et bestående af geografiske grænser på niveau 1 og kommuner på niveau 2, hvor kommunerne før kommunesammenlægningen nu har status sløjfet, mens den gældende kommune har status I drift, og Områdehierarkiet oprettes med de tilhørende gyldighedsperioder og relationer. 2. På tilsvarende måde kan tre geografiske områder med dertil hørende ledninger og forbrugere nu være knyttet til én fælles sektion, som om to år vil blive opdelt i separate sektioner med hver sin flowmåling. 3. Tre tidligere forsyningsselskaber, som indtil for to år siden var selvstændige selskaber. Nu er deres forsyningsområder slået sammen til ét fælles forsyningsområde. Side 35 af 75

6.1.3 Strækning Begrebsforklaring: Et forløb af ledninger der kan starte og slutte i to angivne knuder. En Strækning er normalt en kombination af Ledninger (repræsenteret ved geometriske Linier), hvortil der kan være knyttet nogle Knuder, Funktioner og Bestykninger. Det er dog også muligt at knytte Flader og Funktioner til Strækning via Grupperingreference såvel som Bestykninger via disses relationer til enten Linie eller Knude. En Strækning kan bestå af en række ubrudte Linier, hvorved der rent logisk er en start og slutknude. Men den kan også bestå af en række opdelte Linier eller forgreninger af Ledninger. I de to sidstnævnte tilfælde giver det ikke nødvendigvis mening at definere en start og slutknude. Se også afsnit 7.13. 6.2 Aktivering Begrebsforklaring: Beskriver værdi af aktiver og datoer for værdiaktivering og straksafskrivning heraf. Formål: Aktivering giver mulighed for at angive værdived hhv. etablering og ved evt. levetidsforlængelse af fysiske elementer. Dermed kan man håndtere den særlige situation forlledninger, som på et tidspunkt straksafskrives med status død men senere genbruges som Føringsvej. Da vil DatoStatus ikke være lig med aktiveringsdatoen og ledningen vil være fuldt afskrevet. Se også kapitel 8. Til begrebet Aktivering knytter sig følgende begreber: Aktiveringtype Aktiveringreference (virtuel reference for 4 referencebegreber) Aktivering og de relaterede begreber er modulkandidater. Side 36 af 75

Uddybning af relation Aktivering har Aktiveringreference: Aktivering har en mangetilmange relation til hvert af de 4 fysiske begreber, som anført på nærværende figur. Den unikke nøgle fra hvert af de relaterede begreber angives således på hvert af de fire referencebegreber dvs. hhv. Aktivering på den ene side og de fysiske elementers primære nøgler på den anden side: Bestykning.GUID, Funktion.Knude.GUID, Ledning.Linie.GUID og Konstruktion.Gruppering.GUID. 6.3 Føringsvej Begrebsforklaring: Angivelse af, at en ledning bruges eller kan bruges som Føringsvej for en anden ledning og/eller et kabel/fremmedrør. Kun ledninger, der er/har været medierør i DANDAS eller DANVAND kan bruges som Føringsvej. Dvs. det er kun de Ledninger, der efterfølgende (også) har funktion som Føringsvej, fordi der enten er lagt et andet medierør ind i dette, eller fordi der er tilknyttet et kabel til denne Ledning udenpå eller inden i. Rør med varmekabler opfattes ikke som Føringsvej, da begrebet Føringsvej bruges for at fremhæve, at Ledningen ikke kan fjernes uden konsekvenser for et kabel/fremmedrør, hvorimod varmekablet kun er der af hensyn til selve medierøret. Det er dermed vigtigt at forstå, at hvis det er et kabelrør eller tilsvarende Føringsvej, som aldrig har været eller ikke bliver til et medierør, så hører det til i modulet Kabler, Fremmedrør og Flader. Side 37 af 75

Dette begreb hed tidligere foringsrør i DANVAND, men det er blevet ændret og omdøbt grundet risiko for forveksling med begrebet foring, som relaterer sig til lægningsmetoder. 6.4 Opmålingspunkt Begrebsforklaring: Opmålingspunkt modsvarer en fysisk opmåling i marken af et punkt. Linier og flader kan have opmålingspunkter med sine egne oprindelser for knækpunkterne. Der bør være et vertex på linien eller fladen ved gældende opmålingspunkter. Opmålingspunkt forudsætter således, at der er en Oprindelse knyttet til punktet. Det forudsætter endvidere, at det er en anden Oprindelse end den generelt gældende for resten af Linien hhv. Fladen. 6.5 Note Begrebsforklaring: Tekstnote eller link til ekstern information, som kan knyttes til de fysiske elementer, og som vises med et indsætningspunkt i kortet til information. Note er ikke det samme som label, der er et selvstændigt begreb i DANDAS. Note bruges til at knytte beskrivende tekst eller link til de fysiske elementer. 6.6 Referencesystem Begrebsforklaring: Angivelse af kote og koordinatsystem samt modelversion for den aktuelle forsynings datamodel. Følgende plansystemer understøttes: Kode Beskrivelse 0 Ukendt 1 kp2000j, Kortprojektion 2000, Jylland 2 kp2000s, Kortprojektion 2000, Sjælland 3 kp2000b, Kortprojektion 2000, Bornholm 4 s34j, System 34, Jylland 5 s34s, System 34, Sjælland 6 s45b, System 45, Bornholm 7 UTM, zone 32, European 1950 8 UTM, zone 33, European 1950 9 UTM, zone 32, ETRS89 Side 38 af 75

Kode Beskrivelse 10 UTM, zone 33, ETRS89 11 DKTM Zone 1 12 DKTM Zone 2 13 DKTM Zone 3 14 DKTM Zone 4 100 Lokalt system Der er, som det fremgår ovenfor, mulighed for at angive hhv. Ukendt og Lokalt system som plansystem, men det bør kun være en nødløsning i en opstarts/overgangsperiode eller hvis der arbejdes uden for Danmarks grænser. Følgende kotesystemer understøttes: Kode Beskrivelse 0 Ukendt 1 DVR90, Dansk Vertikal Reference 2 DNN, Jylland 3 DNN, Fyn, Sjælland og LollandFalster 4 KN, Københavns Nul 5 MSL, øer uden forbindelse til DVR90 100 Lokalt system Der er, som det fremgår ovenfor, mulighed for at angive Ukendt og Lokalt system som kotesystem, men det bør kun være en nødløsning i en opstarts/overgangsperiode eller hvis der arbejdes uden for Danmarks grænser. Det er i øvrigt de samme referencesystemer, der understøttes i datamodellerne for DANDAS, DANVAND samt for modulerne Kabler, Fremmedrør og Flader, TV og Brøndrapport og Brudregistrering. 6.7 ReservoirGeometri Begrebsforklaring: Tabel med samhørende værdier af volumen, vandspejlsniveau, samt overfladeareal ved forskellige koter (bundkote, vandspejlskote, maxvandspejl etc.). Der er tilknyttet hhv. et katalog med ReservoirKotetyper og et katalog med ReservoirVolumentyper til ReservoirGeometri. Se afsnit 7.10 og 7.11. Side 39 af 75

7 Supplerende begreber og kataloger Disse begreber på det strukturelle niveau 4 er markeret med grønt i UMLdiagrammet. 7.1 Aktiveringtype Begrebsforklaring: Aktiveringstype dvs. typen af / årsagen til aktivering. Indeholder standardværdier. Der er defineret følgende standardværdier til Aktiveringtype, som svarer til POLKAkategorierne (Pris og levetidskataloget fra Forsyningssekretariatet benyttet til opgørelse af åbningsbalancen pr. 1/1 2010): Uoplyst Ledningsnet Konstruktion Mek./EL SRO I forbindelse med opstilling af tilsvarende kategorier ved overgang til TOTEX opgørelsesmetode bør der etableres supplerende standardværdier for Aktiveringtype. Side 40 af 75

7.2 Ejer Begrebsforklaring: Firma eller gruppe, der har ejendomsretten over de fysiske elementer i ledningsnettet. Da der er en mangetilmange relation mellem Ejere og Firmaer, er der indsat en Ejerandelrelation mellem de to begreber. Ejerandel beskriver den andel i procent, som Firmaet indgår i ejerskabet med. Det er obligatorisk, at der både er mindst én Ejer og ét Firma. 7.3 Firma og Firmatype Begrebsforklaring: Betegnelse for en virksomhed eller en offentlig/privat institution (Den juridisk ansvarlige). Indeholder standardværdier. Side 41 af 75

Firma kan via firmareference have relationer til en lang række andre begreber i kernemodellen. Endvidere kan et firma være firmatyper, som er en brugerdefineret liste over mulige valg med bl.a. følgende værdier: Entreprenør, Fabrikant, Leverandør, Rådgiver, Vandforsyning etc. Nedenfor er angivet de begreber og attributter herpå, der kan have relationer til Firma og dermed firmareference. Firmareference er således et virtuelt begreb, som dækker over selvstændige begreber mellem nedenstående begreber og Firma. Relateret begreb Relaterede attributter Bestykning Driftsansvarlig, Entreprenør, Fabrikant, Projekterende, Tilsyn Funktion Driftsansvarlig, Entreprenør, Fabrikant, Projekterende, Tilsyn Ledning Driftsansvarlig, Entreprenør, Projekterende, Tilsyn Konstruktion Driftsansvarlig, Entreprenør, Fabrikant, Projekterende, Tilsyn Projekt Entreprenør, Planlægning, Projekterende, Tilsyn Oprindelse Opmåler Rør Fabrikant Endvidere har Ejer også en reference til firma via mangetilmange relationen Ejerandel. 7.4 ProjektÅrsag, Anlægstype og Procestype Begrebsforklaring ProjektÅrsag: Brugervalgt liste med evt. kategorisering af årsager til oprettelse af et projekt. Indeholder standardværdier. Der er bl.a. følgende standardværdier: Infrastruktur Vandplan Vandforsyningsplan Begrebsforklaring Anlægstype: Brugervalgt liste med angivelse af, hvilken type anlægsprojekt der er registreret. Indeholder standardværdier fra kerneprocesser i DANVA forretningsprocesdiagrammet. Begrebsforklaring Procestype: Katalog med angivelse af, i hvilken del af vandcyklussen projektet og dets elementer hører til. Indeholder standardværdier. Side 42 af 75

Alle disse kataloger bruges i forbindelse med Projekt, og danner samlet en mulighed for at gruppere / kategorisere et projekt dvs. hvorfor projektet skal gennemføres, hvilken primær anlægstype det gælder for med dertil hørende tilknytning til hvilken del af vandcyklussen, som projektet primært relaterer sig til. 7.5 Link og Linktype Begrebsforklaring: Link er et link/sti til en fil (alle typer) Dvs. det er ikke selve dokumentet der gemmes, men en beskrivelse af, hvor der kan findes en form for dokumentation med en mangetilmange relation til et eller flere af følgende begreber: Side 43 af 75

Bestykning Ejer Funktion Gruppering Ledning Note Oprindelse Et Link skal endvidere relatere sig til begrebet Linktype, som er en brugerdefineret kategorisering af typen af Links. Denne relation er obligatorisk. Et Link kan indgå i Linkreferencer. Hver Linkreference skal indeholde netop ét Link. Linkreference er et virtuelt begreb, som dækker over selvstændige begreber med mangetilmange relationer mellem Link på den ene side og hvert af de 7 ovenfor nævnte begreber på den anden side. Begrebsforklaring Linktype: En evt. kategorisering af typen af dokumenter, hyperlinks, SROtags etc. Indeholder standardværdier. 7.6 Materiale Begrebsforklaring: Almindeligt anvendte materialer til Rør, Funktioner og Bestykninger. Indeholder standardværdier. Der kan vælges fra en liste over materialer, som den enkelte forsyning kan vedligeholde. Modelopdateringsgruppen har leveret et forslag til ca. 50 standardværdier i Materiale samt til disses tilknytning til Materiale Gruppe. Der henvises til DDVreolen for en liste med disse værdier. 7.7 MaterialeGruppe Begrebsforklaring: Gruppering af materialer efter fælles fysiske karakteristika fortrinsvis til brug for benchmarking og statistisk bearbejdning. Indeholder standardværdier. Der kan vælges fra en liste over materialegrupper, som den enkelte forsyning kan vedligeholde. Modelopdateringsgruppen har leveret et forslag til værdier i MaterialeGruppe, som dermed er en del af standardiseringen. Det samme materiale kan tilknyttes flere forskellige MaterialeGrupper, idet disse grupperinger kan oprettes med vidt forskellige formål. F.eks. vil der være forskel på de grupperinger, som skal anvendes til benchmarking for DANVAND og de grupperinger, som en TVoperatør benytter. Nedenfor er en liste med eksempler på standard MaterialeGrupper: Øvrige Side 44 af 75

Bonna Beton Eternit Jern PE PVC Stål Plast 7.8 Områdekategori og Områdekategoriniveau Begrebsforklaring: Områdekategori er en gruppering af områder i kategorier, som hver især kan være defineret ved ét eller flere gyldige områdekategoriniveauer. Indeholder standardværdier. Nedenfor er en liste med eksempler på standard Områdekategorier: Trykzone Indvindingsopland Forsyningsområde Spildevandsopland Brøndopland Skybrudsopland Begrebsforklaring Områdekategoriniveau: Underordnet inddeling af områdekategorier i navngivne hierarkiske niveauer. Vandbalancezoner er det mest oplagte eksempel herpå. Indeholder standardværdier. De fleste Områdekategorier har kun defineret ét niveau. I så fald oprettes er det ikke nødvendigt at oprette poster i Områdekategoriniveau. Men som et eksempel på flere niveauer i Områdekategoriniveau kan nævnes Vandbalancezoner (DANVAND): GISZone Sektion HovedZone SuperZone Forsyningsområde Disse niveauer kan sammenlignes med de administrative niveauer og grænser i Danmark: Kommune, region og stat. Der er ingen overlap mellem de enkelte kommuner, regioner og stater (lande), men der kan over tid være flyttet rundt på grænserne lige som der er nogle kommuner, der kun har været gældende i afgrænsede perioder. Derfor er der i Områdehierarki mulighed for at definere disse relationer hhv. gyldighedsperioder for relationerne. Side 45 af 75

7.9 Oprindelse Begrebsforklaring: Oprindelse beskriver oplysninger om, hvordan, hvornår og med hvilken nøjagtighed informationerne i netværket er indsamlet. Det drejer sig bl.a. om den geometriske nøjagtighed og om, hvordan man har fremskaffet oplysningerne i en række af attributterne. Da der er tale om en mangetilmange relation mellem oprindelse og de relaterede begreber, oprettes relationen som en oprindelsereference. Hver oprindelsereference skal indeholde netop én oprindelse. Nedenfor er angivet de begreber og attributter herpå, der kan have en oprindelse og dermed en oprindelsereference. Relateret begreb Knude Linie Flade Bestykning Ledning Konstruktion Funktion ReservoirGeometri Relaterede attributter XY, Kote og Terrænkote XY og Kote XY og Kote Datoetableret, Handelsmål, Kote, Materiale, XY Datoetableret, Handelsmål, Materiale og DiameterIndvendig Datoetableret Datoetableret, Handelsmål, Materiale og Vandspejlskote Kote og Volumen Der henvises til informationsmodellen for flere detaljer om Oprindelse og Oprindelsereference, hvoraf det også fremgår, at Oprindelsereference er et virtuelt begreb for de detaljerede mangetilmange relationer mellem Oprindelse og ovenstående begreber. Vær særligt opmærksom på, at der er forskel på, hvordan koter opmåles i hhv. DANDAS og DANVAND se afsnit 4.1. 7.10 ReservoirKotetype Begrebsforklaring: Valgliste med navngivning af relevante koter i ReservoirGeometri. Indeholder standardværdier. Der er bl.a. følgende standardværdier: Side 46 af 75

Bundkote Vandspejlskote Max vandspejlskote 7.11 ReservoirVolumentype Begrebsforklaring: Valgliste med navngivning af relevante volumener i ReservoirGeometri. Indeholder standardværdier. Der er bl.a. følgende standardværdier: AktivVolumen MaxVolumen Vær opmærksom på, at ReservoirVolumentype også kan beskrive arealer i ReservoirGeometri, idet man i nogle sammenhænge udregner volumen ud fra samhørende værdier af arealer og koter. 7.12 Rør Begrebsforklaring: De fysiske objekter, som en ledning kan bestå af. Rør er dermed en standardiseret fortegnelse over attributter, som kan bruges til at beskrive rør f.eks. de oplysninger, som en rørfabrikant kan oplyse om de Rør, man har anvendt i ledningsnetværket. For at hjælpe med standardiseringen er der endvidere mulighed for at angive et Materiale pr. rørtype. 7.13 Strækningtype Begrebsforklaring: Valgliste med mulige typer af strækninger indeholder DANVA forslag til standardværdier. Der er bl.a. følgende standardværdier: Pumpestrækning Transportstrækning Brøndstrækning Side 47 af 75

8 Livscyklus og historik Håndtering af livscyklus og databasehistorik bliver med Kernemodellen for første gang håndteret ensartet på tværs af forsyningsarterne. Det medfører, at der er defineret nye koder for livscyklus hhv. nye navne og betydninger for nogle af attributterne. Det er helt centralt at kunne skelne og håndtere begge disse begreber korrekt i den daglige brug af informationerne for at kunne udveksle og bruge informationerne i tråd med intentionerne bag Kernemodellen. 8.1 Livscyklus Figur 3 Livscyklus forløb Side 48 af 75

Begrebsforklaring: Beskriver fysisk status af elementer i netværket. Alle fysiske elementer skal have angivet en status med tilhørende Datostatus. Datoetableret må ikke ændres ved skift af status, med mindre et objekt skifter status fra Planlagt til Anlagt eller I drift. Det er vigtigt, at der IKKE MÅ SLETTES undtagen ved fejlregistreringer, hvor de oprindelige registreringer med sikkerhed ikke er udvekslet endnu. Ved ændring af status i livscyklussen, skal der blot ændres Statuskode og Datostatus. Et fysisk element kan starte livet med at være Planlagt i DANDAS/DANVAND, gennemløbe alle livsstadier og ende som Fjernet. Objekterne skal dog ikke nødvendigvis gennemløbe alle stadier. Det kan f.eks. starte som I brug og derefter overgå til Død. Et objekt kan dermed oprettes forskellige steder i livscyklus som Planlagt, som Anlagt eller som I brug. Herefter kan det tages ud af drift igen enten som: 1. Ikke i brug, hvis der er planer om at tage det i brug igen på et senere tidspunkt. 2. Død, dvs. at anlægget stadig findes i jorden, men det kan ikke blive taget i brug igen på et senere tidspunkt som selvstændigt aktiv. 3. Fjernet, dvs. anlægget er gravet op og findes ikke længere i jorden. Et anlæg, som har status Død, kan dog senere reaktiveres som et rør, hvori der er et indre medierør. Det oprindelige rør skifter så status fra Død til I brug, så det kan betragtes som nyregistrering i forhold til aktivering. 8.1.1 Formål med at holde styr på status Det er vigtigt at holde styr på objekternes status (Statuskode) i livscyklus, og hvornår de skifter status (Dato Status) af følgende årsager: 1. Driften har brug for at vide, hvilket anlæg de skal drifte og hvilke de ikke skal drifte. 2. Der må ikke kunne tilknyttes driftstiltag i et driftsprogram til anlæg, der ikke er i brug. 3. Ved tegningsudlevering har vi brug for at vide, hvilke anlæg der findes i jorden, og om det er i brug/ikke i brug (må ikke skades, da det evt. skal tages i brug på et senere tidspunkt) eller dødt og dermed evt. kan fjernes ved lejlighed. 4. Af hensyn til regnskaber har vi brug for at vide, hvis der etableres anlæg, som ikke sættes i brug med det samme. Da må anlægget ikke aktiveres økonomisk. Når det tages i brug skal aktivering af anlægget ske, således at afskrivning kan påbegyndes. 5. Af hensyn til regnskaber skal vi vide, hvis et anlæg skal straksafskrives, når det enten ikke længere skal anvendes eller bliver fjernet. 6. Både DANDAS og DANVAND kan indeholde anlæg, der enten kun er planlagt eller projekteret. Disse anlægsobjekter skal kunne adskilles i forhold til alle øvrige formål. Side 49 af 75

Livscyklussen håndteres i kodelisten K_Statuskode: Kode Beskrivelse Forklaring Sortering Aktiv 0 Uoplyst Objektets status er ukendt. Kan benyttes som en midlertidig 1 J registrerings tilstand 21 Planlagt Objektet eksisterer ikke endnu, men er planlagt eller 2 J projekteret 22 Anlagt Objekt er anlagt, men ikke taget i brug 3 J 23 I brug Objekt er taget i brug/drift 4 J 24 Ikke i brug Objekt bliver ikke brugt, men kan tages "i brug" 5 J 25 Død Objekt bliver ikke brugt, og kan ikke tages "i brug" 6 J 26 Fjernet Objektet er fjernet det findes ikke 7 J Forklaring til relationen Ledning erstatter Ledning: Erstatter er en reference, som man kan vælge at bruge ved fornyelse, hvor en ny Ledning overtager funktionen fra en dødlagt eller fjernet ledning i forbindelse med fornyelsen. Derved lettes arbejdsgangen ved udveksling af oplysninger med driftssystemer, hydraulisk modellering og i forbindelse med strukturel planlægning. 8.2 Databasehistorik Ændringer i ledningsnettet kan bedst dokumenteres ved at bevare databasehistoriske data. Databasehistoriske data håndteres på Knude, Bestykning, Linie og Konstruktion. Formålet med at bevare de databasehistoriske data er f.eks.: At bevare muligheden for, at eksterne systemer kan relatere til Knude/Funktion, Bestykning, Linie og Konstruktion, der er fjernet eller erstattet af en anden Knude, Bestykning, Linie eller Konstruktion. At bevare grundlaget for statistisk behandling af bl.a. brud. Der er forskellige former for historik: 1. Objekt status f.eks. i brug, planlagt, død, fjernet m.v. 2. DatabaseHistorik på de enkelte poster bl.a. af hensyn til referenceintegritet i databasen. 3. Historik på attributniveau, der svarer til versionering af de enkelte databaseposter. Den første form er behandlet under Livscyklus, så det er kun den anden form for historik, der håndteres her. Den tredje form for historik er mere avanceret, da man stadig skal tage hensyn til referenceintegriteten. Visse databasesystemer kan dog selv håndtere denne form for historik. Side 50 af 75

Ved håndtering af historik bevarer man de oprindelige data efter en Funktion, Bestykning eller Konstruktion er fjernet grundet fejl eller Linie er blevet delt eller samlet. Dette er nødvendigt, da referenceintegritet i databasen skal overholdes og tilknyttede data skal bevares. De oprindelige data bliver markeret som værende databasehistoriske, og disse data skal ikke vedligeholdes fremover. Der er således ikke tale om redundante data. Følgende attributter bliver brugt og kan anvendes til databasehistoriske analyser: DatoDBhistorisk, der angiver hvornår elementet er blevet databasehistorisk. Hvis feltet er tomt (null), så er elementet ikke databasehistorisk. Et element, som indeholder en værdi i DatoDBhistorisk, kan ikke anvendes til nye relationer. F.eks. Endvidere findes der i begrebet Linie følgende referencer, der angiver forbindelsen mellem de databasehistoriske Linier og de nye Linier: Delt fra, der angiver den oprindelige Linie, der er erstattet af den aktuelle Linie og en eller flere andre Linier. Samlet til, der angiver den nye Linie, der er en samling af bl.a. den aktuelle Linie med en anden/andre Linier. De to referencer skal give mulighed for sporbarhed via snitflader til eksterne systemer, når Linier bliver erstattet af nye Linier. I nedennævnte afsnit præciseres med nogle eksempler, hvorledes databasehistorik rent praktisk implementeres. 8.2.1 Databasehistorik eksempler I eksemplerne er omtalt flere attributter (fx Datoetableret, StatusKode og DatoStatus) som i princippet intet har med databasehistorik at gøre. De er medtaget for at tydeliggøre hvad der er nyt og hvad der er gammelt. Desuden er anvendt følgende farvekoder: Side 51 af 75

Deling af en Linie (og dermed af Ledning) A Delt fra: DatoDBHistorisk: 10 B Tidspunkt 1 Delt fra: DatoDBHistorisk: Tid2 10 Tidspunkt 2 A Delt fra: 10 DatoDBHistorisk: C Delt fra: 10 DatoDBHistorisk: 101 102 B Tidspunkt 2 Figur Deling af en Linie. Deling af en Linie forekommer, hvis der indsættes en Knude et sted på Linien (Figur Deling af en Linie). Den oprindelige Linie 10 gøres databasehistorisk, og der oprettes to nye Linier 101 og 102. De nye Linier får i referencen Delt fra en reference til den oprindelige Linie 10. Endvidere får de tilsvarende Ledninger overført relevante attributter (fx Datoetableret, men i princippet alle attributter) fra den oprindelige Ledning. Side 52 af 75

Udskiftning af en del af en Linie (og dermed en del af en Ledning) A Delt fra: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoDBHistorisk: 10 B Tidspunkt 1 Delt fra: DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoDBHistorisk: Tid2 10 Tidspunkt 2 A Delt fra: 10 DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoDBHistorisk: C Delt fra: 10 DatoEtableret: Tid1 StatusKode: Fjernet DatoStatus: Tid2 DatoDBHistorisk: 101 102 103 Delt fra: DatoEtableret: Tid2 StatusKode: I brug DatoStatus: Tid2 DatoDBHistorisk: D Delt fra: 10 DatoEtableret: Tid1 StatusKode: I brug DatoStatus: Tid1 DatoDBHistorisk: B Tidspunkt 2 104 Figur Udskiftning af en del af en Linie. Udskiftning af en del af en Linie forekommer f.eks. i forbindelse med en reparation. På Linien indsættes to nye Knuder C og D. Den oprindelige Linie 10 gøres databasehistorisk. Der oprettes i første omgang tre nye Linier (101,102 og 103), da det svarer til 2 delinger af en Linie, som beskrevet tidligere. De får alle tre overført egenskaberne fra den oprindelige Linie 10 herunder div. datoer samt en reference (Delt fra) til den oprindelige Linie 10. Dernæst bruges Livscyklus til at udskifte Ledningen til 102 ved at sætte Status til Fjernet (medfører en ændring i DatoStatus) og oprette en ny 104. Denne udskiftning har dog ikke noget med Databasehistorik at gøre, hvorfor 104 ikke får nogen reference til 102. Ovenstående handling kan sjældent udføres med standardværktøjerne i et GISsystem ved blot at indsætte de to nye Knuder. Det nye Liniestykke skal indsættes ved en samlet operation. Det anvendte værktøj skal sørge for, at det kun er Ledning 102, der får den nye Statusværdi og ikke Ledningerne 101 eller 103. Endvidere skal værktøjet sørge for, at de tre første nye Linier peger på den oprindelige Linie 10. Side 53 af 75

Udskiftning af en Funktion Udskiftning af en Funktion kan skyldes 2 ting: 1) Ændring i den fysiske verden dette håndteres alene af livscyklus 2) Ændring som følge af fejlregistrering håndteres her Funktion F10 Bliver til: DatoDBHistorisk: Øvrige attributer: Oprindelige data Tidspunkt 1 F10 Bliver til DatoDBHistorisk: Øvrige attributer: Nye data Tidspunkt 2 F101 Bliver til: F10 DatoDBHistorisk: Tid2 Øvrige attributer: Oprindelige data Tidspunkt 2 Figur Udskiftning af en Funktion. Da Funktion er en Knude og Knuden er med til at definere en Ledning, er det her nødvendigt at flytte data frem for kun at indlægge ny data. En ny Funktion F101 oprettes. Alle data (undtagen Navn og GUID, der skal være unikke) overføres fra den oprindelige Funktion F10. Herefter kan F10 få ændret de attributter, der er nødvendige. F101 gøres databasehistorisk ved at udfylde Knude DatoDBhistorisk samt få en Knude relation (Bliver til) til F10. Det sidste for at sikre, at hvis eksterne systemer relaterer til F10 kan de finde videre til F101, der jo holder de oprindelige data. Alle Bestykninger, Linier, grupperinger og strækninger med relation til F10, bibeholder denne relation. Da der ikke må knyttes nye relationer til Funktioner/Knuder, som er databasehistoriske, knyttes ingen relationer til F101. Hvis ændring af en Funktion giver ændring af en Knude fra at være brydende til at være ikkebrydende, er der endvidere tale om en samling af 2 Linier (se afsnit herom). Hvis ændring af en Funktion giver ændring af en Knude fra at være ikkebrydende til at være brydende, er der endvidere tale om en deling af en Linie (se tidligere afsnit herom). Side 54 af 75

Udskiftning af en Bestykning eller Konstruktion For at gøre princippet så enkelt som muligt, håndteres udskiftning af en Bestykning eller Konstruktion på samme måde som udskiftning af en Funktion, dvs. der indsættes en ny Bestykning/Konstruktion, som får alle data (der ikke skal være unikke) overført fra den oprindelige Bestykning/Konstruktion samt sat DatoDBhistorisk. Til gengæld får den oprindelige Bestykning/Konstruktion de nye data samt en relation (Bliver til) fra den nye Bestykning/Konstruktion (med de gamle data). Sammenlægning af Linier To eller flere topologisk sammenhængende Linier kan sammenlægges som vist nedenfor, hvis de(n) mellemliggende Knude(r) ikke har øvrige relationer eller har en værdi i DatoDBHistorisk. A Samlet til: DatoDBHistorisk: B Samlet til: DatoDBHistorisk: 10 11 C Tidspunkt 1 Samlet til: 101 DatoDBHistorisk: Tid2 B 10 11 Samlet til: 101 DatoDBHistorisk: Tid2 Tidspunkt 2 A Samlet til: DatoDBHistorisk: 101 C Tidspunkt 2 Figur Sammenlægning af to Linier. De oprindelige Linier 10 og 11 gøres databasehistoriske. Begge de oprindelige Linier får i attributten Samlet til en reference til den nye Linie 101. Den nye Ledning får attributter (herunder etableringsdato), der kan svare til én af de oprindelige Ledninger. Side 55 af 75

8.3 Datofejlkonstateret Attributten Datofejlkonstateret findes på følgende begreber: 1. Bestykning 2. Flade 3. Gruppering 4. Knude 5. Linie 6. Note Denne attribut bruges til at markere, hvornår et af ovennævnte elementer er markeret til at kunne slettes fra databasen. Det vil primært være i forbindelse med at data, som er sendt ud til en ekstern part, returneres med besked om at et element er blevet ændret så grundlæggende, at det måske kan slettes fra ledningsregistreringen. Det kan f.eks. være fordi man har konstateret, at det ikke findes alligevel, eller at det faktisk er en helt anden elementtype. Men det kan også bruges til at markere, at nogle attributter, som findes væsentlige for det pågældende element er blevet rettet. Der foreligger ikke en DANVAregel for, hvornår dette felt skal tages i anvendelse. Side 56 af 75

9 Dandas 3.0 modelspecifikke supplementer til kernemodellen Dandas 3.0 er en informationsmodel på DDV s OIO EAreol (DDVreolen), som supplerer DANVA s fælles kernemodel med vandforsyningsspecifikke aspekter. Formålet med Dandas 3.0 er at beskrive det fysiske ledningsnet for spildevandsforsyningsinstallationer med de data, der er nødvendige for at understøtte en række udvalgte ydre forretningsprocesser. Procesoverblik, en kopi fra DDVreolen, er vist herunder. Figur 4 Den enkelte proces udefra. Spildevand 1.0. Som det bl.a. fremgår af Figur 4 ovenfor, så er der nogle af forretningsprocesserne, som ikke er understøttet endnu (markeret med gråt). Det er udtryk for at de ikke er blevet beskrevet endnu, men at de ønskes under Side 57 af 75

støttet fremadrettet. Derfor vil det også være således, at der er inkluderet nogle attributter og begreber i Dandas 3.0 (og den fælles Kernemodel) som ikke er understøttet af en forretningsproces endnu. De er inkluderet under den forudsætning, at de har været i en af de tidligere gældende datamodeller (for Dandas 3.0 eller Danvand 2.0) og med en forventning om at de vil understøtte nogle af de ikkebehandlede forretningsprocesser. Desuden er der ønsket den generelle afgrænsning i modellen, at den kun skal indeholde data, som skabes og vedligeholdes af forsyningerne. Kernemodellen er suppleret med egne operationelle begreber og kodelister for afløbssporet. Kernemodellen er således udvidet med: Afløbsspecifikke bestykninger, Funktioner, Konstruktion, Knude og Ledning Udledningstilladelse Recipienter QH relation beskrivelse af pumpekarakteristik Sporspecifikke attributter i kernemodel begreber Sporspecifikke koder i kernemodel kodelister Der er ligeledes suppleret begreber og standardværdier for: Materiale og materialegruppe (til anvendelse for dæksler og åbne tværsnit, bassiner mv.) Firma og Firmatyper Områdekategori og områdekategoriniveau Projektårsag ReservoirKotetype og ReservoirVolumentype AnlægsBestykningtyper Katalogerne er brugerstyrede lister, men for at sikre en vis entydighed kan katalogerne udfyldes med en række DANVA standardværdier. Generelt gælder det, at DANVA standarder for såvel Dandas som den fælles kernemodel ligger som dokumenter på DDVreolen. Katalogerne er i modellerne udfyldt med standardværdier fra DANVA. Disse standardværdier kan suppleres med egne værdier for den enkelte forsyning, men det anbefales så vidt muligt alene at benytte de standardværdier, der forefindes i kataloget, da det sikrer forståelsen af begrebernes værdier samt entydigheden i udvekslingen af data mellem forskellige systemer. Ønskes der andre værdier end de angivne, anbefales det at rette henvendelse til DANVA, som efterfølgende kan supplere de generelle standardværdier til gavn for hele forsyningsbranchen. Bemærk endvidere, at posterne i katalogerne identificeres med den primære nøgle GUID, men i udvekslingsøjemed vil de også inkludere den obligatoriske og unikke nøgle navn (eller betegnelse). Det er derfor GUID, der officielt benyttes som reference. Beskrivelse af det ovenstående samt Dandas 3.0 og den fælles Kernemodel ligger på DDVreolen, se afsnit 1.1. 9.1 Relationer, Attributter og Kodelister Attributter og kodelister knyttet til Dandas 3.0 findes på DDVreolen ved at udpege modelnavnet på hylden med logiske datamodeller. Side 58 af 75

Under reolen vises herefter en oversigt hvorfra man kan vælges beskrivelser knyttet til modellen (Visio diagrammer, denne vejledning mv.) og vælge det begreb i datamodellen, som ønskes undersøgt nærmere. Figur 5 Attributter og relationer på DDVreolen For et valgt begreb vises supplerende dokumentation samt en oversigt over relationer, attributter og koder, der er knyttet til begrebet. Oversigt over alle begreber og attributter i Dandas 3.0 er vist på følgende skematiske UMLdiagram, som kan ses i fuld størrelse på DDV reolen. Side 59 af 75

Udskiller Sandfang 1 3 har Udledningstilladelse QHRelation M Udledningreference H Q Separator kan beskrive4 3 har Afspærring kan beskrive4 1 Overløbskant Recipient Udløb Udsparring DANDAS 3.0 inkl. Fælles Kernemodel 2.0 Dato: 29. november 2016 3 udleder til M = modulkandidat Niveau 1: Geometriske begreber Niveau 2: Fysiske elementer i virkeligheden Niveau 3: Administrative puljer Niveau 4: Supplerende begreber og valglister Niveau 5a: Referencer og relationer Niveau 5b: Virtuelle referencer og relationer. Se detaildiagram. Magasin Ventil Brønd AdministrativOvergang Har udløb i4 DANDAS begreber niveau 2 DANDAS supplerende begreber og valglister ReservoirKoteType Tank Retningsregulering Forsyningspunkt 3 har 1 3 har ReservoirGeometri 1 3 har ReservoirVolumenType Reservoir Tilslutningspunkt Pumpested FysiskOvergang Regulering Forbindelse Tilslutning LabelLedning Referencesystem har AnlægBestykningType M er lavet af4 1 pumper lavet til4 af4 har4 1..* 3 bliver til sidder på4 Bestykning 3 har har4 har4 Note delt fra4 3 er inden i 3 har LedningPunktSanering Linie regulerer flow fra4 beskriver4 Samling 1 beskriver4 LinieBestykning knytter sig til4 3 afstand målt 3 fra sidder i hoved knytter sig til4 1 har målerretning til4 1 1 3 bliver til Måler XOR Knude indeholder4 3 samlet til Gruppering KnudeLinieBestykning knytter sig til4 1 3 indeholder knytter sig til4 1 3 starter i KnudeBestykning 1 Knudesanering 3 slutter i knytter sig til4 1 3 har 1 Servicekote 1 1 Grupperingreference Dæksel 3 indeholder 1 indeholder4 Rottespærre 1..* 3 udbredelse Sandfangbund har4 AnlægBestykning M har Brøndopland LabelKnude 1 1 Aflaster til4 Har udløb i4 knyttes til knyttes til4 har4 Funktion har4 Aktiveringreference M knyttes til4 ejes af4 1 lavet af4 Aktivering M har4 1 Materiale 1 Aktiveringtype M tilhører4 ejes af4 1 MaterialeGruppe har4 har4 har4 Flade 1 1..* 1 Ejer har4 Ejerandel 1..* 1 Firma 1..* Firmatype har XY4 ejes af4 har4 3 har 1 type 1 har4 Oprindelsereference Linkreference har4 3 har 3 har 1 3 er lavet af 3 har 3 indeholder Linktype Link 3 har Firmareference 3 har Oprindelse 3 ejes af Opmålingspunkt 3 har 1 har 1 Ledning 3 har 3 har bruges som4 1 1 1 1 1..* erstatter4 3 har 3 består af under 3 består af under har4 1 består af4 Førringsvej Konstruktion Projekt M Strækning Område M Se underdiagram Konstruktionsreference 3 har Anlægstype M Områdekategori 3 bliver til Rør har4 1 M knyttes til4 3 ejes af har4 1 har4 Områdehierarki M Områdekategoriniveau M Projektårsag M Processtype Strækningtype har4 1 1 har4 1 M 3 består af under 1 3 knyttes til DeltaLedningKote LedningplanParameter M ProfilBeskrivelse er tilknyttet 1 ProfilPunkt Bassin Udskillerbygværk Reguleringsbygværk Brøndbygværk Pumpestation Tryktårn Overløbsbygværk Samlekonstruktion Renseanlæg Nedsivningsanlæg Etagebrønd Udløbsbygværk Opland M 3 har 3 indeholder Figur 6 UMLdiagram for informationsmodellen Dandas 3.0 9.2 Modelspecifikke begreber Som supplement til den fælles Kernemodel findes i Dandas 3.0 følgende ekstra begreber (med kursiv er angivet Kernemodellens overbegreber, så Dandas 3.0 begreberne bliver sat ind i den rette kontekst): Bestykning o KnudeBestykning Servicekote Knudesanering Dæksel Sandsfangbund Rottespærre AnlægBestykning AnlægBestykningType Bestykning o LinieBestykning LedningPunktSanering Funktion Side 60 af 75

o Reservoir Udskiller Sandfang Funktion o Regulering Separator Overløbskant QHRelation Afspærring QHRelation Funktion o Forbindelse Brønd Udsparing Udløb Udledningstilladelse (Modulkandidat) Recipient Konstruktion o Udskillerbygværk o Reguleringsbygværk o Tryktårn o Overløbsbygværk o Samlekonstruktion o Renseanlæg o Nedsivningsanlæg o Etagebrønd Knude o Brøndopland o LabelKnude Ledning o LabelLedning o DeltaLedningKote o LedningPlanParameter (Modulkandidat) Rør o Profilbeskrivelse o ProfilPunkt Herudover er der medtaget en række supplerende begreber og værdilister, da de er en del af Dandas 3.0 datamodellen. Det drejer sig om følgende begreber: o Projektårsag Side 61 af 75

o o o Områdekategori Områdekategoriniveau Materialer Anlægsbestykningstyper Med kursivt er der i listen angivet begreber, der stammer fra den fælles kernemodel. Efterfølgende vil de enkelte dele af informationsmodellen blive præsenteret. Side 62 af 75

10 Bestykninger Bestykninger er elementer, som ikke påvirker hydraulikken, men som alligevel er knyttet til netværket i et punkt eller en linie. 10.1 KnudeBestykning 10.1.1 Servicekote Begrebsforklaring: Bestykning tilsluttet en knude, der beskriver projekteret tilslutningskote, der kan afvande hele matriklen. Typisk registreret sammen med et Forsyningspunkt. 10.1.2 KnudeSanering Begrebsforklaring: Bestykning der benyttes til at angive, hvilke punktreparationer og saneringsmuligheder der kan benyttes til knuder. KnudeSanering sker eksempelvis ved renovering af etagebrønde, brøndrenoveringer udført som håndrenovering eller muret efter DS 43033 med insitu fiberbeton. 10.1.3 Dæksel Begrebsforklaring: Bestykning der angiver oplysninger om dæksler for de enkelte funktioner typisk brønde. Der kan oprettes flere dæksler pr. funktion/konstruktion. Dæksler monteres typisk i en af 2 typer karme: fast eller flydende. Ved fast karm forstås en karm der hviler/står direkte på den underliggende brønd eller ved plast opføringsrør på den omsluttende betonkegle. Ved flydende karm forstås en karm der udelukkende ligger/flyder i det omkringliggende materiale som regel asfalt. Attributten dækselnummer er en entydig fortløbende nummerering for dæksler knyttet til samme knude, startende med Dækselnr=1. Det anbefales at nummeringen foretages i forhold til løbsretning for den ledning, der løber fra knuden, startende fra venstre. Bemærk, at Dækselnummer er et obligatorisk felt som skal udfyldes. Dækselnummer sammen med knudens GUID udgør således en unik nøgle. Side 63 af 75

10.1.4 Rottespærre Begrebsforklaring: Bestykning der placeres i en brønd på afløbssystemet, således at det sikres at rotter ikke kan trænge ind afløbssystemet. Rottespærre vil typisk være udformet som 2 klaps rottespærrer, rottespærrer med højdeforskel eller som en rottedræbende fælde. 10.1.5 Sandfangsbund Begrebsforklaring: Bestykning til markering af, at en standard brønd er udstyret med et sandfang uden hydraulisk betydning et volumen på typisk 35 l eller 70l under afløbskoten. Må ikke forveksles med et reservoir af typen Sandfang, der har en magasinmæssig betydning for netværket. 10.1.6 AnlægBestykning Begrebsforklaring: AnlægBestykning bruges ved håndtering af simple bestykninger til knuder som katalogværdier. Da man ønsker geografien, registreres disse bestykninger i Dandas. Der kan knyttes flere bestykninger af samme type til samme knude. 10.1.7 AnlægBestykningType Begrebsforklaring: Brugerkatalog over typer af AnlægBestykning. Dandas 3.0 standard: udluftning, skumbræt, rist, alarm 10.2 LinieBestykning 10.2.1 LiniePunktSanering LedningPunktSanering relatere til punktsaneringer af ledningen. Sanering af hele ledningsstrækninger håndteres som en rørirør relation gennem relationen er inden i på linie. Ledning PunktSanering kan eksempelvis være af typen sprøjtestøbning, omstøbning, injecering af samlinger, hatprofil eller kortstrømpe. Side 64 af 75

11 Funktion 11.1 Reservoir Reservoir kan i Dandas 3.0 udover at være et Magasin eller en Tank også være af typen Udskiller eller Sandfang. Når der placeres et reservoir i ledningsnettet, skal der tages aktiv stilling til om reservoiret er af typen udskiller, sandfang, magasin eller tank. Alle kote og volumenregistreringer i forhold til reservoir er knyttet til ReservoirGeometri, hvor der i valglister præciseres hvilke data, der ligger i en specifik beskrivelse i begrebet. I forhold til kernemodellen er begrebet ReservoirGeometri udvidet med attributten Tværsnitareal. Feltet angiver gennemstrømningens tværsnitsareal (Betegnes Ac i modelleringsværktøjer), og anvendes sammen med sammenhængende værdier af Overfaldeareal (Betegnes As i modelleringsværktøjer) til at beskrive hydraulikken overfor f.eks. MIKE URBAN ved en given kote. Der er oprettet standarder for beskrivelse af kote, overfladeareal og tværsnitsareal jf. nedenstående figurer som standardværdier til Dandas. Figur 8 Tværsnitsarel for udvalgte kotepunkter Figur 7 Overfladeareal ved udvalgte kotepunkter 11.1.1 Udskiller Begrebsforklaring: En udskiller er en anordning med et fast volumen, der fjerner stoffer fra vandet, f.eks. olie, benzin eller fedt. Sandfang 11.1.2 Sandfang Begrebsforklaring: Et sandfang er en anordning med et varierende volumen og vandspejl, der sikrer bundfældning af sedimenterbare partikler. Side 65 af 75

11.2 Regulering 11.2.1 Separator En regulering, der fjerner stoffer fra vandet, f.eks. olie, benzin eller fedt. En separator sender det udskilte stof videre i spildevandssystemet til forskel fra Udskilleren, der lagrer det udskilte stof ved sedimentation. Der er således lavet en relation fra Separatoren til den Linie.Ledning, som der er udløb til. 11.2.2 Overløbskant En Overløbskant er en beskrivelse af den enkelte overløbskant. Kan eksempelvis være et nødoverløb. Det er muligt at samle flere overløb i et overløbsbygværk. Til Overløbskant er det muligt, at tilknytte en QHRelation, som beskriver flow gennem konstruktionen ved et givent vandtryk/kote. Der kan tilknyttes QH relationer til én overløbskant. En Overløbskant har således en anderledes hydraulisk beskrivelse end en Udsparingen, der er vanddækket på begge sider af væggen, og i modsætning til overløbskanten ikke har frit overløb. 11.2.3 Afspærring En Afspærring er en type af reguleringer, der regulerer den fortsatte vandføring efter en Q/H kurve eller en fast vandføring. Til Afspærring er det muligt, at tilknytte en QHRelation, som beskriver flow gennem konstruktionen ved et givent vandtryk/kote. Der kan tilknyttes QH relationer til én afspærring. For Overløbskant kan der desuden angives til hvilken knude(funktion) overløbet aflaster, samt hvilket Udløb, overløbskanten har udløb i. I relation til ventil gøres der opmærksom på, at det alene placering og åbningsgraden der har betydning. Side 66 af 75

Forbindelse Dandas 3.0 udvider den fælles Kernemodel 2.0 med forbindelser af typen Brønd, Udsparing og Udløb. 11.3.1 Brønd Begrebsforklaring: En Brønd er den forbindelsestype, som oftest benyttes i ledningsregistreringen. Typisk er der tale om en Standard brønd med bund og opføring. Der kan placeres et Dæksel på brønden som en Knudebestykning, og der kan tilsvarende sættes en Sandfangsbund. 11.3.2 Udsparing Begrebsforklaring: Huller i væggen mellem flere kamre i en konstruktion. Udsparingen er vanddækket på begge sider af væggen, og har i modsætning til en overløbskant ikke fri højde og derfor en anderledes hydraulik. 11.3.3 Udløb Begrebsforklaring: Et Udløb er typisk en knude, hvori spildevandet forlader afløbssystemet og ledes til recipienten. Ind/udløb til konstruktioner mv. er kategoriseret under Forbindelser af typen Punkt. Et Udløb kan være knyttet til maximalt en Recipient, men samme recipient kan have flere udløb tilsluttet. Dette giver mulighed for hurtigt at finde og sammentælle udløb til en given recipient. Til et Udløb kan også være knyttet til en eller flere Udledningstilladelser gennem krydsreferencen Udledningreference. En udledningstilladelse kan også omfatte flere udløb. Udledningstilladelser er en modulkandidat. Side 67 af 75

11.4 Tilslutninger 11.4.1 Tilslutningspunkt I Dandas 3.0 er Tilslutningspunktet udvidet med information om, hvor langt det er placeret fra en given knude på hovedledningen. Dette vil typisk være tilfældet for stik oprettet fra en TVinspektion. Her er tilslutningen ikke målt op med koordinater, men fastlagt ud fra en stationering langs den/de ledninger, TVinspektionen dækker. Relationen Afstand målt fra knude angiver fra hvilken retning af ledningen der er målt fra og vil variere løbende ved indlæsning af nye TVinspektioner. Er der anført en Afstand målt fra knude og Afstandfraknude, er det dette offset der er bestemmende for Tilslutningspunktets placering, og koordinater til placeringen bør beregnes ud fra disse informationer. Tilslutningspunktet er kun tænkt anvendt til håndtering af stiktilslutninger, hvor der ikke skal regnes hydraulik for stikledningen Side 68 af 75

12 Konstruktioner Konstruktion kan være af typen Udskillerbygværk, Reguleringsbygværk, Brøndbygværk, Tryktårn, Overløbsbygværk, Samlekonstruktion, Renseanlæg, Nedsivningsanlæg og Etagebrønd er alene knyttet til Dandas 3.0 modellen. 12.1 Udskillerbygværk Begrebsforklaring: Et Udskillerbygværk er benyttes i forbindelse med fjernelse af stoffer fra vandet, f.eks. olie, benzin eller fedt. Der angives en udskiller type. 12.2 Reguleringsbygværk Begrebsforklaring: Et Reguleringsbygværk samler funktioner, der styrer strømningen i en ledning f.eks. med højvandsklap, kontraventil, vandbremser m.m. 12.3 Brøndbygværk Begrebsforklaring: Et Brøndbygværk er en samlende konstruktion, hvor den primære funktion er en brønd og dermed ikke en af de øvrige konstruktionstyper. 12.4 Tryktårn Begrebsforklaring: Et Tryktårn er et bygværk, hvor der opnås en trykforøgelse ved at pumpe vand op i et kammer over terræn, herfra kan vandet løbe videre via gravitation. 12.5 Overløbsbygværk Begrebsforklaring: Et Overløbsbygværk er en konstruktion der, afhængig af størrelse, indeholder et eller flere indløbspunkter, et overløbsmagasin, én eller flere overløbskanter, et aflastningsmagasin og et eller flere udløb. Overløbsfunktionen bruges til at aflaste systemet, når kapaciteten i ledningerne overstiges Side 69 af 75

12.6 Samlekonstruktion Begrebsforklaring: En Samlekonstruktion er en konstruktion, der typisk samler flere andre konstruktioner til en samlet driftsenhed med en overordnet funktion f.eks. en samlet LAR konstruktion, som f.eks. en Wadi, bestående af en kombination af dræn, kanal og nedsivning. 12.7 Renseanlæg Begrebsforklaring: Et Renseanlæg er et anlæg, hvor spildevandet behandles inden det ledes til recipienten. Renseanlæg kan være med mekanisk, biologisk og/eller eventuelt kemisk rensning. 12.8 Nedsivningsanlæg Begrebsforklaring: Et Nedsivningsanlæg er en samlet konstruktion til nedsivning af vand i jorden eller andet medie henblik på forsinkelse eller rensning og bortskaffelse. Nedsivningsanlægget består afhængig af medietype og størrelse af et magasin til bundfældning, en regulering (evt. pumpested) eller et reguleringsbygværk, et nedsivningsmagasin og evt. et udløb. 12.9 Etagebrønd Begrebsforklaring: En Etagebrønd er en regnvandsbrønd etableret over i en dybere liggende spildevandsbrønd. De to brønde registreres som forbindelser og samles i konstruktionen Etagebrønd. 12.10 Bassin I forhold til kernemodellen er begrebet Bassin dog udvidet med tre attributter i Dandas 3.0: Arealvedligehold, Bassinkode og Vådvolumen, samt en relation til det materiale (overflade) bassinet er lavet af. Side 70 af 75

13 Knude 13.1 Brøndopland Begrebsforklaring: Et Hydraulisk Brøndopland angiver det område, som afvander til en specifik brønd. Bemærk, at der her er tale om et Brøndopland som ikke har relation til Kernemodellens Område eller Flade begreb, da der er krav om, at Brøndoplandet referer til netop én Knude. Relation: Der kan således til en Knude kan tilknyttes Brøndopland (f.eks. vejareal, boligområde og grønt område med forskellige befæstigelsesgrader) mens der altid skal være én Knude tilknyttet et Brøndopland. 13.2 LabelKnude Begrebsforklaring: LabelKnude indeholder oplysninger om koordinater, vinkel og skalering for en knudetekst til en funktion/knude. Side 71 af 75

14 Ledning I forhold til kernemodellen har Dandas 3.0 suppleret Ledningsbegrebet med en række afløbsspecifikke attributter, såsom DykkerKode, Fald og Opfyldt. Grøfter, kanaler og åbne vandløb beskrives også som en ledning, men defineres af rør med åbne tværsnit. Til ledning er der i kernemodellen knyttet en LedningKategori og LedningFunktion. Attributterne anvendes som vist i nedenstående eksempel tabellen er ikke fyldestgørende, men blot eksempler, og vil blive uddybet i den kommende registreringsvejledning. Begrebet Ledningstype er ikke noget, der kan registreres i Dandas 3.0, men en sammenstilling af egenskaber, der registreres i en række enkeltattributter: Ledning i Dandas K_LedningKategori K_LedningFunktion K_NyTilslutning K_Transport Uoplyst Uoplyst Uoplyst Uoplyst Uoplyst Fiktiv ledning Fiktiv ledning Hovedledning Hovedledning Almindelig ledning Gravitation Hovedledning, Trykledning Hovedledning Almindelig ledning Tryk Hovedledning, Overløbsledning Hovedledning Overløbsledning Ingen mulighed for tilslutning Hovedledning, Rørbassin Hovedledning Bassinledning Ingen mulighed for tilslutning Hovedledning, Drosselledning Hovedledning Drosselledning Ingen mulighed for tilslutning Infiltrationsledning, nedsivning af vand Hovedledning Infiltrationsledning Ingen mulighed for tilslutning Hovedledning, Supplerende ledninger Hovedledning Supplerende ledninger Ingen mulighed for tilslutning Vacuumledning Intern ledning Almindelig ledning Vacuum Internt ledningssystem Intern ledning Almindelig ledning Internt ledningssystem, Trykledning Intern ledning Almindelig ledning Internt ledningssystem, Overløbsledning Intern ledning Overløbsledning Internt ledningssystem, Udløbsledning (frit udløb) Intern ledning Udløbsledning Internt ledningssystem, Rørbassin Intern ledning Bassinledning Internt ledningssystem, Supplerende ledninger Intern ledning Supplerende ledninger Stikledning Stikledning Almindelig ledning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Stikledning, Trykledning Stikledning Almindelig ledning Tryk Drænledning, opsamling af vand Hovedledning Drænledning Overfladisk afstrømning og klimasikring Strømningsvej Almindelig Ledning Gravitation Afskærende ledning Transportledning Almindelig ledning Afskærende ledning, Trykledning Transportledning Almindelig ledning Afskærende ledning, Rørbassin Transportledning Bassinledning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Tryk Tryk Side 72 af 75

Afskærende ledning, Overløbsledning Transportledning Overløbsledning Afskærende ledning, Rørbassin Transportledning Bassinledning Afskærende ledning, Drosselledning Transportledning Drosselledning Afskærende ledning, Supplerende ledninger Transportledning Supplerende ledninger Hydraulisk forbindelse i bygværk Modelledning Uoplyst Ingen mulighed for tilslutning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Ingen mulighed for tilslutning Ingen mulighed for tilslutning 14.1 DeltaLedningKote Begrebsforklaring: DeltaLedningKote benyttes som begreb til håndtering af ledingskoter som afviger fra brøndbunden. 14.2 LedningPlanParameter Begrebsforklaring: LedningPlanParameter benyttes som begreb til at samle parametre til anvendelse i saneringsplanlægning. 14.3 LabelLedning Begrebsforklaring: LabelLedning indeholder oplysninger om placering af en ledningstekst til ledningen. Side 73 af 75

15 Rør I forhold til kernemodellen har Dandas 3.0 suppleret med en række afløbsspecifikke attributter, såsom BreddeUdvendig, HøjdeIndvendig, HøjdeUdvendig og Medfod. Rør beskriver ligeledes tværsnitskoden for ledningen. Mens rør i Danvand 2.0 altid er cirkulære, er der mange standard former for tværsnit i Dandas. Herunder er vist eksempler på nogle af de mest almindelige tværsnitsformer. 15.1 Profilbeskrivelse Begrebsforklaring: En Profilbeskrivelse er en generel beskrivelse af ikke cirkulære tværsnitsprofiler, med reference til sammenhørende værdier af HøjdeBredde eller Perpendikulær(X) og tilhørende højde (Z). Rør 1 ProfilBeskrivelse er tilknyttet 1 ProfilPunkt 15.1.1 ProfilPunkt Begrebsforklaring: Et profilpunkt er et antal sæt af sammenhørende værdier af HøjdeBredde eller Perpendikulær(X) og tilhørende højde (Z) til beskrivelse af et tværprofil. Se de nedenstående eksempler på profilpunkter. Side 74 af 75

16 Supplerende begreber og værdilister 16.1 Område 16.1.1 Områdekategori Områdekategori er en overordnet gruppering af områder i Dandas 3.0 er f.eks. Spildevandsplan, LAR område og Klimasikringsområder oprettet som standard i valglisten. Områdekategori: Spildevandsplan opland er oprettet med som en selvstændigt begreb: Opland med relation til det udløb, der modtager vand fra oplandet. Opland er en modulkandidat. 16.1.2 Områdekategoriniveau Områdekategoriniveau er en underordnet inddeling af områdekategorier i navngivne hierarkiske niveauer. Spildevandsplanens områder er et eksempel herpå. 16.2 Projekter 16.2.1 Projektårsag Dandas 3.0 supplerer Kernemodellens standardværdier med projektårsager som f.eks. LAR, Klimasikring, Dataforbedring. 16.3 Materiale Dandas 3.0 supplerer Kernemodellens standardværdier for materiale med en række afløbsspecifikke materialer f.eks. rørmaterialer som murværk, monier samt en række materialer anvendt til dæksler. Materialelisten anvendes desuden for materiale og overflader for Bassiner, Nedsivningsanlæg og Samlekonstruktioner. 16.3.1 Materialegruppe Til Dandas 3.0 er der som supplement til den fælles Kernemodel defineret en antal standard materialegrupper med anvendelse som overflade i bassiner mv og som dækselmateriale. 16.4 Strækning 16.4.1 Strækningtype Dandas 3.0 supplerer den fælles Kernemodel med strækningsbegrebet Pumpestrækning, der beskriver en sammenhængende sekvens af linier.ledninger, tryk og gravitation, som indgår i strækning fra pumpested til oppumpningsbrønd. Side 75 af 75