InformatieModel Water (IMWA) 2013

Transcriptie

1 InformatieModel Water (IMWA) 2013 Auteur Datum IHW 21-augustus-2013 Versie 5.0

2 Documentbeheer Wijzigingshistorie Datum Versie Auteur Wijziging H-J. Lekkerkerk Dit document is gebaseerd op IMWA 2005, IMWA 2006 béta en IMWA2006. Versienummering opnieuw begonnen bij IMWA2007 en vanaf daar volgens procedurehandboek H-J. Lekkerkerk Opstellen document. Verwerken: - RfC KRW formats in UM Aquo en IMWA W. Joosse Wijzigingen Aquo update juni 2009 verwerkt W. Joosse Wijzigingen Aquo update juni 2010 verwerkt, RfC W UM Aquo Waterwet W. Joosse Wijzigingen Aquo update juni 2013 verwerkt, dit veroorzaakte alleen wijzigingen in de versie van domeintabellen. Verder zijn er aanpassingen geweest van de Types van domeintabellen i.v.m. het automatisch uploaden van nieuw versies van de xsd bestanden van de domeintabellen vanuit Aquo DS. Review Datum Versie Reviewer Functie Controle en vrijgave Datum Versie Controleur Functie Literatuurbronnen NEN 3610:2005 Basismodel Geo-informatie, Nederlands Normalisatie-instituut, december 2005 IMWA:2006 Informatiemodel Water, IDsW, december 2006 W : Foutherstel IMWA en UM Aquo KRW Uitwisselingsformats: - KRW format Menselijke belasting, versie 1.0a - april KRW format Kunstwerken, versie 1.0 april 2004 W : domeintabel typemeting pagina 2 van 83 Documentbeheer

3 W : foutherstel voor het pattern van attribuut identificatie; controle op 2 cijferige waterbeheerdercode. W : RfC UM Aquo Waterwet Grote wijzigingen voor domeintabellen uit de Aquo Update juni 2013 Documentbeheer pagina 3

4 Inhoudsopgave 1. Inleiding Leeswijzer Achtergrond Toepassingsgebied Gerelateerde documenten Wijzigingen Wijzigingen van versie 2010 naar Wijzigingen van versie 2009 naar Nieuwe klassen en attributen Wijzigingen van versie 2008 naar Gewijzigde klassen en attributen Wijzigingen van versie 2007 naar Gewijzigde relaties Wijzigingen van versie 2006 naar Gewijzigde klassen en attributen Nieuwe klassen in IMWA Verwijderde klassen Toegevoegde relaties Gewijzigde relaties Wijzigingen van versie 0.5 / 2006 béta naar Gewijzigde klassen Nieuwe klassen Verwijderde klassen Gewijzigde relaties Termen, afkortingen en schema s Termen en definities Afkortingen UML klassediagram Constraints Klasse beschrijvingen Attribuut beschrijvingen Identificerende kenmerken Geometrie en Topologie Temporele attributen Beschrijvende kenmerken Metadata Null-waarden Samengestelde attributen Domeinlijsten GML en XML extensible Mark-up Language (XML) XML-schema GML...25 pagina 4 van 83 Inhoudsopgave

5 4. InformatieModel Water Een toepassing van NEN Structuur van het informatiemodel IMWA geo-objectklassen Relatie met bestaande normen en standaarden Beschrijving IMWA: UML klassendiagram en catalogus IMWA klassendiagram Relatie met Basismodel Geo-informatie GeoObject (uit NEN3610: Basismodel Geo-informatie) IMWA klassen BeschermdGebied GrondwaterOnttrekking Inrichtingselement Kunstwerk Ligplaats Meting NatteEcologischeZone Oever OppervlakteWaterLozing OppervlakteWaterOnttrekking Put Water Waterdeel WaterbeheerGebied Waterbodem Waterkering Waterschap WaterstaatkundigeZonering Weg Wegdeel ObjectMetadata Datatypes / samengestelde attributen Adres Adresgegevens Adrescoordinaat Artikel DataTypePlanstatusEnDatum Locatie LocatieNaam LocatieOmschrijving OmvangWaardeInrichtingselement OmvangWaardeKunstwerk OmvangWaardeWater OmvangWaardeWaterbeheergebied OmvangWaardeWeg Domeinwaarden Domeinen Domeinen uit NEN Inhoudsopgave pagina 5

6 6.2.1 MateriaalKunstwerk MateriaalWaterkering Status TypeInfrastructuur TypeWeg Verharding Domeinlijsten IMWA FunctieKunstwerk TypeInfrastructuur Inrichtingtype Kunstwerktype Meting NoseCodetype OmvangWaardeInrichtingselement OmvangWaardeKunstwerk OmvangWaardeWater OmvangWaardeWaterbeheerGebied OmvangWaardeWeg Waterkeringtype Waterbeheerder Waterbeheergebied WaterTypeKwantitatief WatertypeKwalitatief WegAardtype Waterstaatkundigezonering WetVerordeningtype Domeinen uit IMRO: TypePlanStatus...75 Bijlage A Van LMA tot IMWA 77 Bijlage B Overzicht Basismodel Geo-informatie (NEN 3610) 80 Met opmaak Met opmaak Met opmaak Met opmaak Met opmaak Met opmaak pagina 6 van 83 Inhoudsopgave

7 1. Inleiding 1.1 Leeswijzer Dit rapport beschrijft het InformatieModel voor de sector WAter (IMWA). De verschillende objecten die in dit model gedefinieerd zijn worden gepresenteerd, de relaties tussen deze objecten en de attributen met bijbehorende domeinwaarden zijn opgenomen. Dit document is vooral van belang voor applicatiebouwers en als referentie voor andere IMWA gerelateerde documenten. In dit hoofdstuk wordt ingegaan op de achtergrond en toepassing van IMWA. Hoofdstuk 2 bevat een toelichting op de gebruikte termen, afkorten en gebruikte schema s. Hoofdstuk 3 beschrijft in conceptuele termen het IMWA als een model van de werkelijkheid zoals die van belang is voor het ontsluiten van geo-informatie in de sector water. Tevens is in dit hoofdstuk de context van deze standaard beschreven. Deze standaard staat niet op zich zelf maar maakt gebruik van en refereert aan andere normen en standaarden. Overzichten van de aan deze standaard gerelateerde normen en standaarden zijn weergegeven in de bijlagen. In hoofdstuk 4 is het concept uitgewerkt. Op een formele manier worden door middel van een UML diagram de objectklassen weergegeven, de kenmerken van de verschillende objectklassen en hun onderlinge relaties. In een objectcatalogus wordt in tabelvorm van alle objectklassen de definitie gegeven en de attributen toegelicht. Tot slot wordt in hoofdstuk 5 ter illustratie een overzicht gegeven van de huidige gebruikte domeinwaarden zoals die binnen het model gebruikt worden. 1.2 Achtergrond De laatste jaren neemt het gebruik van Geografische Informatie Systemen (GIS) hand over hand toe. De in GIS opgeslagen informatie bevat per definitie een ruimtelijke component. Bij de uitwisseling van geografische gegevens is het van belang dat deze ruimtelijke component intact blijft, maar dat de overige gegevens ook aan deze geografische informatie gekoppeld blijven. Om te zorgen voor een eenduidige uitwisseling van geografische informatie ten aanzien van water objecten is in 2001 versie 1.0 van het InformatieModel Water ontwikkeld. Het IMWA is ontwikkeld vanuit het Logisch (gegevens-) Model Aquo (LMA). In het LMA is geografische / geometrische informatie slechts in beperkte mate omschreven. IMWA is dan ook ontwikkeld om deze leemte binnen de Aquo standaard op te vullen. Bij de ontwikkeling is aangesloten bij de norm NEN3610: Basismodel Geo-informatie. Hierbij is het IMWA opgenomen als sectormodel onder de NEN3610 naast onder andere het IMRO (InformatieModel Ruimtelijke Ordening) en de TOP10NL (topografische informatie). IMWA is feitelijk de praktische invulling van de NEN3610 voor de sector water. Inleiding pagina 7 van 83

8 In 2005 is door het Nederlands Normalisatie Instituut een nieuwe versie van de NEN3610 ontwikkeld. Daarnaast heeft de techniek niet stilgestaan. Om deze reden is in 2005 begonnen met het moderniseren van IMWA door het aanpassen aan de laatste stand van zaken. Daarnaast zijn er ontwikkelingen zoals het traject Digitale Uitwisseling Ruimtelijke Processen (DURP) ingebracht in het IMWA. Deze acties hebben geleid tot IMWA versie 2006 / Toepassingsgebied Het informatiemodel is voor het uitwisselen van geo-informatie tussen organisaties binnen de sector Water en voor uitwisseling naar andere werkvelden. Het uitwisselen van informatie is hierin het proces dat door IMWA ondersteund wordt. Het type informatie dat uitgewisseld wordt is geo-informatie, informatie die op een of andere manier gekoppeld is aan een locatie bepaald ten opzichte van het aardoppervlak. En als laatste punt betreft het geo-informatie die binnen de sector Water gegenereerd wordt. Voor een efficiënte uitwisseling van geo-informatie is het van belang dat de verschillende partijen een gemeenschappelijke notie hebben van de werkelijkheid. Deze gemeenschappelijke notie is vastgelegd in een begrippenkader dat die de werkelijkheid beschrijft. IMWA vormt dit begrippenkader voor het beschrijven van geo-informatie binnen de sector water. IMWA is voor het uitwisselen van informatie. Dit betekent dat het gaat om informatie die voor verschillende partijen van belang is, vandaar de uitwisseling. Dit betekent dat het IMWA geen model is voor een specifieke, geïsoleerde toepassing. Een specifieke toepassing vereist een specifiek model, een nationale standaard heeft dan immers geen meerwaarde. 1.4 Gerelateerde documenten Rondom om IMWA zijn er een drietal documenten die van belang zijn bij het gebruik en de implementatie van IMWA. Dit zijn: 1. Modelbeschrijving (dit document). De modelbeschrijving is tevens interactief te benaderen via de IDsW website ( via de pagina van de uitwisselmodellen. 2. Praktijkrichtlijn IMWA. Hierin worden de diverse klassen en het gebruik daarvan verder beschreven. Ook zijn hierin voorbeelden opgenomen. 3. Technische richtlijn UitwisselModellen. Hierin is opgenomen de manier van beschrijven van IMWA in UML als schematisatietaal, de omzetting van het UML model uit dit document naar een XML schema bestand (XSD) en de manier waarop het XSD toegepast kan worden bij het genereren van een GML document. Gerelateerd aan het IMWA model is het UM Aquo, waarvan de volgende delen beschikbaar zijn: UM Aquo metingen, sinds december 2006 UM Aquo Kaderrichtlijn Water, sinds juni 2007 Het UM Aquo is een verdere doordetaillering van het IMWA. pagina 8 van 83 Inleiding

9 2. Wijzigingen 2.1 Wijzigingen van versie 2010 naar 2013 Grote wijzigingen uit de Aquo update van juni 2013 veroorzaakten wijzigingen in de versie van domeintabellen. Verder zijn er aanpassingen geweest van de Types van domeintabellen i.v.m. het automatisch uploaden van nieuw versies van xsd bestanden van de domeintabellen vanuit Aquo DS. Tabel met was - wordt overzicht van de 13 gewijzigde Types van domeintabellen domeintabel was van het Type FunctieKunstwerk TypeInrichting TypeKunstwerk TypeNoseCode TypeWaterbeheerGebied TypeWaterKwalitatief TypeWaterKwantitatief WetVerordening TypeWaterkering TypeWaterstaatkundigeZonering TypeWegAard TypeBeschermdGebied domeintabel is nu van het Type TypeFunctieKunstwerk TypeInrichtingtype TypeKunstwerktype TypeNoseCodetype TypeWaterbeheergebiedtype TypeWatertypeKwalitatief TypeWaterTypeKwantitatief TypeWetVerordeningtype TypeWaterkeringtype TypeWaterstaatkundigezonering TypeWegAardtype TypeBeschermdGebiedtype 2.2 Wijzigingen van versie 2009 naar 2010 De toevoegingen aan IMWA die ten gevolge van RfC W UM Aquo Waterwet nodig waren zijn in de documentatie verwerkt. Er zijn alleen nieuwe klassen waaronder een datatype ingevoegd Nieuwe klassen en attributen Klasse Attributen Motivatie Oever - geometrievlak2d T.b.v. UM Aquo Waterwet Put - geen T.b.v. UM Aquo Waterwet Waterbodem - geometrievlak2d T.b.v. UM Aquo Waterwet Inrichtingselement - geometriepunt - geometrievlak2d OmvangWaardeInrichtingselement - waardetype - waarde T.b.v. UM Aquo Waterwet T.b.v. UM Aquo Waterwet Wijzigingen pagina 9 van 83

10 2.3 Wijzigingen van versie 2008 naar 2009 In de Aquo update van juni 2009 zijn twee wijzigingsvoorstellen van invloed geweest op IMWA namelijk: W : foutherstel voor identificatie, de waterbeheerdercode moet uit 2 posities bestaan. In het xsd is het deel van het pattern dat bepaalt of de waterbeheerdercode lang genoeg is daarom van d{1,2} naar d{2} gewijzigd; W : de inhoud van de domeintabel Aquo-domein_metingtype.xsd wordt niet meer door een koppeling via een include statement geladen, maar is intern in het xdsbestand bestand opgenomen Gewijzigde klassen en attributen Klasse Wijziging Motivatie Meting Attribuut Identificatie: in het technisch model wordt het pattern hiervoor aangepast. Check op verplichte 2 posities voor de waterbeheerdercode Attribuut typemeting de cardinaliteit wordt [0] in het logisch model en blijft [0..1] in het technisch model. Dit attribuut is alleen nog technisch in IMWA opgenomen om koppeling van IMWA LMA mogelijk te maken, maar is logisch gezien niet nodig. 2.4 Wijzigingen van versie 2007 naar 2008 Om meer duidelijkheid te scheppen in de relaties in zowel het logisch model als het bijbehorende XSD schema is ervoor gekozen om alle relaties in UM Aquo niet meer te voorzien van de naam van de klasse waarnaar de relatie verwijst. In het bijbehorende XSD schema is er juist voor gekozen om deze naam bij ALLE relaties op te nemen. Achterliggende motivatie is dat uit het diagram zonder meer duidelijk wordt naar welke klasse een relatie verwijst. In het XSD is dit juist niet het geval en is het meegeven van de relatie van cruciaal belang voor het eenvoudig lezen / maken van een GML document. In het Logisch Model (UML klassendiagram) worden daarom de volgende wijzigingen doorgevoerd: Gewijzigde relaties Klasse 1 Klasse 2 Wijziging GeoObject ObjectMetadata heeftobjectmetadata wordt gewijzigd in heeft heeft wordt gewijzigd in vantoepassingop pagina 10 van 83 Wijzigingen

11 2.5 Wijzigingen van versie 2006 naar Gewijzigde klassen en attributen Klasse Wijziging Motivatie Meting Waterbeheergebied Attribuut waterbeheerder toegevoegd Geometrie attributen toegevoegd Geometrie2D van verplicht terug naar conditioneel Waterbeheerder toegevoegd Compatibiliteit met KRW elementen Stonden in UM Aquo metingen, maar zijn generiek voor alle metingen In IMWA2006 was ervoor gekozen om deze verplicht te maken; echter middels een locatienaam kan de locatie ook aangeduid worden en is een geometrie niet verplicht (maar wel gewenst) Compatibliteit met KRW en praktijkgebruik Nieuwe klassen in IMWA Klasse Attributen Motivatie ObjectMetaData - opmerking - URI - datumopname Lost het probleem van het toevoegen van metadata voor specifieke klassen op. Feitelijk is datumopname gelijk aan het NEN3610 attribuut versiebegintijd. In de praktijk blijkt het moeten aangeven van een tijdstip echter in veel gevallen lastig. Vandaar dat dit attribuut opnieuw gemodelleerd is met de tijd als optioneel element. BeschermdGebied - typebeschermdgebied Gebieden die wel beschermd zijn maar waarvoor geen lokale regelgeving bestaat. OppervlakteWater Onttrekking OppervlakteWater Lozing - codenose - waterbeheerder - capaciteit - waterbeheerder - geometriepunt Noodzakelijk voor kaderrichtlijn Water, maar generiek genoeg voor opname in IMWA Analoog aan oppervlaktewateronttrekking Verwijderde klassen Er worden geen klassen verwijderd. Wijzigingen pagina 11 van 83

12 2.5.4 Toegevoegde relaties Er wordt bij geo-object een relatie toegevoegd waarmee het mogelijk is om een geo-object uit meerdere, andere, geo-objecten op te bouwen. Hierdoor kunnen bijvoorbeeld complexen zoals RWZI of sluiscomplexen uit hun onderdelen worden opgebouwd. Een andere toepassing is het groeperen van verschillende meetpunten in een enkele meetlocatie zoals dat binnen de KRW van belang is Gewijzigde relaties Er worden geen relaties gewijzigd. 2.6 Wijzigingen van versie 0.5 / 2006 béta naar Gewijzigde klassen Klasse Wijziging Motivatie Kunstwerk Water Waterbeheergebied Aanpassing domeintabel typekunstwerk Aanpassing domeintabel omvangwaarde / toevoegen nieuwe beschrijvende kenmerken Vervallen attribuut omvangwaardewater Vervallen attribuut wetverordening Vervallen attribuut typewaterkwantitatief Vervallen attribuut typewaterkwalitatief Optionaliteit tussen water en waterdeel van 0 naar 1 (tenminste 1 verplicht waterdeel per water) Geometrie2D van optioneel naar verplicht Vervallen attribuut waterkwaliteit Vervallen attribuut ingreepeneffect Toevoegen inundatiegebied aan typewaterbeheergebied Toevoegen kans op inundatie (2x) aan OmvangWaardeType De huidige tabellen sluiten niet aan bij de gegevens van de kunstwerken uit het LMA Door deze oplossing dient elk water uit tenminste 1 waterdeel te bestaan en kunnen attributen nog maar op een plaats (laagste niveau) worden vastgelegd. Elke klasse dient tenminste een geometrie te hebben. De vervallen attributen zijn overervingen van een eerste inpassing van KRW formats. Deze gaan nu naar een apart model en horen daarom niet meer hier thuis. Daarnaast worden inundatiegebieden toegevoegd vanuit het DURP traject. Weg Vervallen attribuut omvangwaardeweg Deze is al opgenomen bij wegdeel en alleen daar relevant Nieuwe klassen Klasse Attributen Motivatie NatteEcologischeZone Gelijk aan Keurzone, behalve het typezonering Ter onderscheid van keur zoneringen als aparte klasse opnemen. pagina 12 van 83 Wijzigingen

13 2.6.3 Verwijderde klassen Er zijn geen klassen verwijderd uit IMWA bij deze wijziging Gewijzigde relaties Er zijn geen relaties gewijzigd in IMWA bij deze wijziging. Wijzigingen pagina 13 van 83

14 3. Termen, afkortingen en schema s In dit hoofdstuk worden de begrippen toegelicht die gebruikt worden voor de beschrijving van de structuur van het model. De definities van elementen van het model worden gegeven in hoofdstuk Termen en definities Term / definitie (engels) applicatieschema (application schema) attribuut (feature attribute) Toelichting Informatiemodel dat wordt beschreven en toegepast. OPMERKING IMWA is met UML beschreven in een applicatieschema. Kenmerk van een object attribuutwaarde (value) Waarde die een attribuut aanneemt geo-informatie (geo-information, geographic information) domein (domain) geo-object (feature type of feature class) georeferentie (georeference) informatiemodel (conceptual model / conceptual schema) interoperabiliteit (interoperability) metadata (metadata) Gegevens met een directe of indirecte referentie naar een plaats op het aardoppervlak. OPMERKING Geo-informatie is synoniem aan geografische informatie. Kennisgebied of activiteit gekarakteriseerd door een verzameling van concepten en begrippen Abstractie van een fenomeen in de werkelijkheid dat direct of indirect geassocieerd is met een locatie relatief ten opzichte van het aardoppervlak Locatie van een ruimtelijk object vastgelegd in een ruimtelijk referentiesysteem Formele definitie van objecten, attributen, relaties en regels in een bepaald domein Mogelijkheid van verschillende autonome, heterogene eenheden, systemen of partijen om met elkaar te communiceren en interacteren. Gegevens over gegevens. model (model) Abstractie van de werkelijkheid. presentatie (portrayal) Visualisatie van geografische informatie voor mensen. representatie (representation) ruimtelijk referentie-systeem (spatial reference system) Inhoudelijk vastleggen van de werkelijkheid. OPMERKING: Het informatiemodel is een representatie van de werkelijkheid. Model (systeem) voor identificatie van een positie (locatie) gerelateerd aan het aardoppervlak. OPMERKING Identificatie van een positie kan door coördinaten (directe locatie) en door geografische identificatoren (indirecte locatie). pagina 14 van 83 Termen, afkortingen en schema s

15 werkelijkheid (universe of discourse) beeld van de echte of hypothetische wereld die alles van belang omvat Afkortingen DURP ISO OCL OGC OMG GFM GIS GML IMWA KRW RfC UML URI URL XML W3C Digitale Uitwisseling in Ruimtelijke Processen International Organization for Standardization Object Constraint Language Open Geospatial Consortium Object Management Group General Feature Model Geografisch Informatie Systeem Geography Markup Language InformatieModel WAter Europese Kaderrichtlijn Water Request for Change wijzigingsvoorstel Unified Modelling Language Uniform Resource Identifier (uit XML) Uniform Resource Locator Extensible Markup Language World Wide Web Consortium 3.2 UML klassediagram Voor het beschrijven van het model wordt gebruik gemaakt van de grafische modelleertaal UML (Unified Modelling Language). UML vindt zijn oorsprong in de objectoriëntatie en is door de Object Management Groep (OMG) ontwikkeld als een standaard voor het beschrijven van objectgeoriënteerde modellen. Het UML klassediagram is één van de mogelijkheden die UML biedt. Dit onderdeel wordt in dit document gebruikt voor het beschrijven van het IMWA. Hieronder volgt een beknopte samenvatting van de belangrijkste begrippen en notaties die gebruikt worden in een UML klassediagram. Termen, afkortingen en schema s pagina 15 van 83

16 Begrip (Engels) Klasse (Class) = verzameling objecten met overeenkomstige eigenschappen ( kenmerken, associaties en gedrag ). UML-notatie Naam van de klasse +attributen +operaties() Abstracte klasse (abstract class) = klasse zonder objecten. Concrete klasse = klasse met objecten. Instantie (instance) = een object uit een klasse Associatie (association) = relatie tussen twee klassen Rechthoek met drie compartimenten: - Naam van de klasse - Attributen (» kenmerken) - Operaties (» gedrag) Een relatie tussen twee of meer klassen. Om weer te geven hoeveel objecten met elkaar gekoppeld zijn gebruiken we de multipliciteit. Klasse A 1 0..* Klasse B Multipliciteit (multiplicity) = het aantal betrokken objecten in een associatie Specialisatie (specialization) = het verfijnen van een klasse (de zgn. superklasse) in onder- of subklassen Eén object (instantie) van klasse A heeft een relatie met nul of meer objecten (instanties) van klasse B Opname van een expliciet aantal (1, 2 enz) Of een reeks: 0..* = nul of meer 1.. * = één of meer 2..5 = twee tot vijf Superklasse Subklasse 1 Subklasse 2 Subklasse 3 Overerving (inheritance) = iedere subklasse erft alle eigenschappen (kenmerken, associaties en gedrag) van zijn superklasse pagina 16 van 83 Termen, afkortingen en schema s

17 Begrip (Engels) Aggregatie (aggregation) = een associatie tussen een samengestelde klasse en een component klasse (maakt deel uit van). Objecten van de deelklasse kunnen worden toegevoegd of verwijderd zonder dat de geheelklasse ophoudt te bestaan. UML-notatie geheelklasse 1 -Bevat 0..* deelklasse Compositie (composition) = een associatie die aangeeft dat een of meer klassen (componenten) onderdeel zijn van een andere klasse (compositieklasse), met als restrictie dat een component niet zelfstandig verder leeft als de compositieklasse verdwijnt Component 1 Compositieklasse Component 2 Component 3 Enumeratie (enumeration) = Een klasse die een lijst van waardes weergeeft. Deze kan gebruikt worden op plaatsen waar voor een bepaalde waarde uit een beperkt aantal vooraf bekende mogelijkheiden gekozen moet worden. Een enumeratie is een klasse met als stereotype <<Enumeration>>. CodeList= Wanneer vooraf niet bekend is welke waardes een bepaald attribuut kan krijgen, maar als er wel een lijst waarschijnlijke waardes is, wordt in plaats van een Enumeratie een CodeList gebruikt. Een CodeList is een klasse met als stereotype <<CodeList>>. <<enumeration>> typespoorbaan trein tram metro 3.3 Constraints Bij de modelleertaal UML is een extra taal Object Constraint Language (OCL) gedefinieerd, waarin eisen en beperkingen (constraints) in het model, die niet rechtstreeks uit het model kunnen worden afgeleid, kunnen worden uitgedrukt. Vaak worden dit soort eisen in tekst aan het model toegevoegd maar het formeel uitdrukken van deze beperkingen heeft voordelen; OCL is een formeel gedefinieerde taal, waardoor (digitale) spraakverwarring bij uitwisseling van de gegevens kan worden voorkomen. Typische beperkingen, die met OCL kunnen worden vastgelegd, zijn; De oppervlakte van een gebouw is minimaal 25 m 2. (context Gebouw; geometry()- >area() > 25 m 2 ) Termen, afkortingen en schema s pagina 17 van 83

18 De geometrie van een wooneenheid ligt altijd geheel binnen de geometrie van het pand waar deze deel van uitmaakt (context verblijfobject; geometry()- >inside(maaktdeeluitvan()->geometry()) De begintijd van een object moet altijd voor de eindtijd van een object liggen. (context GeoObject; objectbegintijd < objecteindtijd) In onderstaande figuur staat een voorbeeld hoe beperkingen in het model verwerkt kunnen worden. Hierin is bijvoorbeeld vermeld dat de eindtijd altijd voor de begintijd zal moeten liggen. figuur: toepassen van constraints bij een geo object Momenteel biedt XML-schema nog geen ondersteuning voor OCL beperkingen en bij een vertaling van UML naar XML-schema worden de beperkingen dan ook niet meegenomen. Binnen het UML-model hebben de beperkingen echter zeker een functie. Op dit moment zijn er voor IMWA (nog) geen beperkingen gedefinieerd. 3.4 Klasse beschrijvingen De volgende formaten worden gebruikt voor de beschrijving van de klassen van IMWA. Een figuur waarmee een bepaalde IMWA klasse in het UML-schema gevisualiseerd wordt ziet er als volgt uit:. Naam van de Klasse +attribuutnaam : <attribuutdomein> [multipliciteit] In de figuur staan de volgende onderdelen: De naam van de klasse; Bij een abstracte klasse wordt de naam van de klasse cursief weergegeven. attribuutnaam : de attributen die gedefinieerd zijn voor deze klasse; <attribuutdomein>: een referentie naar de verzameling van toegestane attribuutwaarden, het domein. Om duidelijk onderscheid te maken tussen een attribuutnaam en een attribuutdomein is het attribuutdomein indien nodig voorzien van het prefix Type. pagina 18 van 83 Termen, afkortingen en schema s

19 [multipliciteit]: de cardinaliteit van het attribuut weergegeven in het aantal keren (multipliciteit) dat een attribuut kan of moet voorkomen. Een cardinaliteit van [0] houdt in dat het attribuut niet gebruikt wordt in dit specifieke model, ook als het wel in de bovenliggende klasse (generalisatie) is gedefinieerd (C). Een cardinaliteit van [0..1] houdt in dat het attribuut optioneel is (O). Een cardinaliteit van [1] houdt in dat het attribuut verplicht is (V) Een cardinaliteit van [0..n] of [1..n] is ook mogelijk, er worden dan meerdere instanties van een attribuut bij eenzelfde klasse toegestaan. Bij elke klasse is een tabel opgenomen waarin de definitie en andere klasse informatie wordt gegeven. De tabel heeft de volgende indeling: Klasse Definitie Herkomst definitie Generalisatie Specialisatie Attributen Associaties Gebruik/voorbeelden Klassenaam Definitie van de klasse. De herkomst, bron, van de definitie. Van welke klassen is deze klasse een generalisatie. Van welke klasse is deze klasse een specialisatie. De attributen die gedefinieerd zijn voor deze klasse: Attribuutnaam* Toelichting V/C/O De naam van het attribuut Een toelichting op het doel en gebruik van het attribuut. Met welke klassen heeft deze klasse associaties. Toelichting bij het gebruik van deze klasse. Is het attribuut Verplicht, Conditioneel of Optioneel? * De asterisk geeft aan dat het attribuut overgeërfd is van een hogere klasse en een specifieke uitwerking heeft voor deze klasse. 3.5 Attribuut beschrijvingen Eigenschappen van objecten worden beschreven in attributen. De attributen van een object kunnen in de volgende groepen worden onderscheiden: identificerende, geometrische en topologische, temporele, beschrijvende, en metadata. Voor iedere groep zijn datatypen beschikbaar. Voor de waarden van de attributen zijn verschillende datatypen te onderscheiden. In de volgende paragrafen worden deze datatypen per groep behandeld. De volgende indeling geeft de gebruikte datatypen weer. Groep / Datatype Identificerende kenmerken Standaard Geometrie en topologie GM_Point GM_Curve GM_Suface GM_Solid Omschrijving String, Integer, etc. Punt object Lijn object Vlak object (2D) Volume object (3D) Termen, afkortingen en schema s pagina 19 van 83

20 Groep / Datatype GM_Object TP_Node TP_Face TP_Edge TP_Solid Temporele attributen Date Time DateTime Beschrijvende attributen Standaard ScopedName Enumeration CodeList nieuw Datatype Union Omschrijving Willekeurige geometrisch object Topologische node Topologisch vlak Topologische grens Topologisch volume Datum object Tijdstip Datum plus Tijd String, Integer, etc. Opsommend limitatief (domeinlijst) Opsommend uitbreidbaar (domeinlijst) Een samengesteld attribuut. Een klasse aangegeven als <<DataType>>, waarin een combinatie van meerdere attributen aangegeven wordt. Deze attributen hebben weer hun eigen specifieke datatype. Een klasse aangegeven als <<Union>> is een datatype met een of-relatie tussen de aangegeven attributen Identificerende kenmerken Identificerende kenmerken zijn kenmerken die een object uniek identificeren. Vanuit het Basismodel Geo-informatie wordt bij het geo-object het attribuut identificatie hiervoor gebruik Geometrie en Topologie Ieder geo-object moet direct of indirect een geometrie hebben. Dit kan door vanuit dit object te verwijzen naar een geometrie die ergens anders is opgeslagen, of een geometrisch of topologisch attribuut opnemen. In ISO is een uitgebreide selectie van datatypen aanwezig die moet worden gebruikt als ruimtelijk type. Vanzelfsprekend zijn de geometrische attributen zeer belangrijk in het Basismodel Geoinformatie. Het hierboven genoemde lijstje is dan ook slechts een minimale selectie uit de uitgebreide type hiërarchie in ISO Coördinaat referentiesysteem Het is in GML verplicht iedere geometrie te voorzien van een verwijzing naar het coördinaat referentiesysteem waarin de coördinaten van de geometrie beschreven zijn. Coördinaat referentiesystemen moeten voldoen aan ISO en bestaan uit een horizontaal en verticaal coördinaat referentiesysteem. Een coördinaat referentiesysteem is op zijn beurt weer opgebouwd uit een datum (horizontaal / verticaal) en een coördinaatsysteem. pagina 20 van 83 Termen, afkortingen en schema s

21 Binnen Europa geldt dat coördinaten herleidbaar moeten zijn tot het European Terrestrial Reference System 1989 (ETRS89). De dagelijkse praktijk is dat coördinaten veelal worden gemeten en opgeslagen in andere coördinaat referentiesystemen. Binnen de Nederlandse kustlijnen wordt veelal gebruik gemaakt van het RDNAP coördinaat referentiesysteem. Hiervoor geldt dat de gebruikte horizontale datum Bessel 1841 is en het coördinaatsysteem de stereografische projectie. Als verticaal datum wordt het NAP vlak gebruikt. Hoewel toepassing van andere coördinaat referentiesystemen dan ETRS89 niet wordt uitgesloten is het belangrijk steeds aan te geven welke coördinaat conversie en coördinaat transformatie noodzakelijk zijn om van de in de GML gehanteerde coördinaten te komen tot coördinaten in het ETRS89. Bij het ontwikkelen van het IMWA is geen expliciete keuze gemaakt voor 2D of 3D objecten. Dit impliceert dat het gebruikte coördinaat referentiesysteem voor het IMWA tenminste is opgebouwd uit een horizontaal coördinaat referentiesysteem, eventueel aangevuld met een verticaal coördinaat referentiesysteem. Wel wordt, zo mogelijk aangegeven hoe de relatie is (ligt boven / onder) ten opzichte van andere GeoObjecten in dezelfde dataset. ISO geeft een uitgebreide beschrijving welke parameters in bovenstaande gevallen uitgewisseld moeten worden Temporele attributen Behalve de temporele attributen in GeoObject (objectbegintijd, objecteindtijd, versiebegintijd en versieeindtijd) die een door het Basismodel Geo-informatie vastgelegde semantiek hebben, kunnen ook andere attributen een temporele waarde krijgen. De in ISO beschikbare basis datatypen zijn opgenomen in het overzicht, maar ISO bevat een veel uitgebreider scala aan temporele datatypen. OPMERKING: Bij een temporeel attribuut behoort te worden gedocumenteerd wat het tijdstip eigenlijk inhoudt. Er kan bij een verandering in het landschap een behoorlijke tijd zitten tussen het tijdstip van de verandering en de tijd dat de verandering wordt waargenomen en wordt verwerkt. Temporeel referentiesysteem Bij gebruik van temporele attributen is het verplicht deze te voorzien van een verwijzing naar het temporele referentiesysteem waarin de tijdstippen beschreven zijn. Temporele referentiesystemen moeten voldoen aan ISO Internationaal is afgesproken (ISO 8601) dat tijd referentiesystemen voor de uitwisseling van informatie moet gebeuren op basis van de Gregoriaanse kalender in 24-uurs formaat. Als referentietijd is voor het IMWA de zogenaamde Universal Time Coordinated (UTC) gekozen. In de praktijk is deze nagenoeg gelijk aan de Greenwich Mean Time (GMT). Hoewel toepassing van een lokale referentietijd niet wordt uitgesloten, dient deze volgens ISO gerelateerd te worden aan de UTC tijd Beschrijvende kenmerken Beschrijvende kenmerken beschrijven eigenschappen van objecten zoals: naam, type, status, materiaal enz. Bij de attributen die de beschrijvende kenmerken vastleggen zijn een aantal groepen van datatypen te onderscheiden. Deze zijn in het overzicht weergegeven. Termen, afkortingen en schema s pagina 21 van 83

22 Standaard datatypen Deze datatypen zijn aangegeven in het geval het attribuut een open domein heeft. ScopedName Een attribuut met het type ScopedName is vergelijkbaar met een CharacterString attribuut. Alleen is er ook de mogelijkheid om bij de tekst optioneel een scope op te nemen waarbinnen die naam is gedefinieerd. Deze scope bevat dan een verwijzing naar de instantie die de naam heeft afgegeven. Voorbeeld: De officiële straatnaam krijgt als scope een verwijzing naar de gemeente die de straatnaam heeft afgegeven. Eventuele onofficiële namen krijgen dan geen scope. Enumeration en CodeList In IMWA is een aantal voor-gedefinieerde datatypen als enumeratielijst opgenomen. Dit zijn lijsten van toegestane waarden die een attribuut binnen IMWA kan aannemen. Een enumeratielijst is limitatief en binnen het model niet uitbreidbaar. Niet voor elke attribuut kan een lijst met mogelijke waarden gedefinieerd worden. Dit komt voor omdat het (nu) niet mogelijk of zinvol is om een lijst te maken die binnen de sector Water geldt. Om toch aan te geven dat er mogelijk een lijst kan komen is in die gevallen het datatype wel opgenomen als CodeList maar leeg gelaten. Dit betekent dat er een open domein is Metadata Het uitwisselen van Metadata is in deze versie van het IMWA nog niet uitgewerkt. Voorlopig wordt hiervoor verwezen naar ISO en de NL Kernset Metadata Null-waarden Bij het uitwisselen van gegevens is het vaak onduidelijk wat wordt bedoeld als bij een attribuut niets oftewel null is ingevuld. Een oplossing hiervoor is het gebruik van het UML NullType. Dit type heeft in UML de volgende definities. inapplicable missing template unknown withheld anyuri Er is geen waarde. De correcte waarde is niet beschikbaar bij de verzender van deze gegevens. Het kan ook zijn dat er geen correcte waarde is. De waarde zal later beschikbaar zijn. De correcte waarde is niet bekend bij, en niet berekenbaar door, de verzender van deze gegevens. Een correcte waarde bestaat waarschijnlijk wel. De waarde is niet vrijgegeven. Deze URI moet dan verwijzen naar iets dat de reden van het null zijn van dit attribuut weergeeft. pagina 22 van 83 Termen, afkortingen en schema s

23 Deze Null waarden kunnen bij alle attributen ingevuld worden behalve bij het attribuut identificatie. In het volgende UML diagram wordt de toepassing van null-waarden toegelicht. In het voorbeeld is een datatype RechtstypeOrNull gecreëerd dat de aangegeven waarden voor Rechtstype of de null-waarden kan aannemen. Toepassing NullType in UML diagrammen Samengestelde attributen Attributen staan soms in relatie tot elkaar. Het is mogelijk dat een attribuut een eigenschap van ander attribuut beschrijft of dat een combinatie van attributen samen een eigenschap beschrijven. Indien dit het geval is, wordt er in het basismodel een aparte klasse gecreëerd van het stereotype <<DataType>>. Een voorbeeld van bij elkaar horende attributen is het datatype Adres. Het toepassen van een attribuut dat een eigenschap van een ander attribuut beschrijft, wordt in het hieronder genoemde voorbeeld toegelicht. Bijvoorbeeld voor een weg kunnen bij een weg verschillende maatvoeringen horen waarbij bij iedere maatvoering een waarde hoort. In dat geval heeft het attribuut omvangwaarde zelf weer een attribuut waarde. In het plaatje hieronder is uitgewerkt door het wegattribuut omvangwaarde van het datatype OmvangWaardeWeg te maken. Dit nieuwe datatype is een combinatie van een waarde en een waardetype, waarbij het waardetype het soort maatvoering bepaald. toepassing samengesteld attribuut 3.6 Domeinlijsten Bij de beschrijving van de domeinwaarden in IMWA zijn het bijbehorende datatype, enumeratie, CodeList of DataType aangegeven op de volgende wijze: Termen, afkortingen en schema s pagina 23 van 83

24 verbinding kruising knooppunt vlakte <<enumeration>> <<CodeList>> VoorbeeldKlasse Hiërarchie in domeinwaarden In principe zit er geen hiërarchie van hoofdgroepen en subgroepen binnen een lijst met domeinwaarden. In sommige lijsten is echter wel een hiërarchie ingebracht. Dit wordt gedaan door hoofd en subgroepen met een punt komma (;) te scheiden. Bijvoorbeeld: <imwa:typekunstwerk>waterstaatkundigwerk;lozingswerk</imwa:typekunstw erk> In de domeinlijst typekunstwerk is er een waarde waterstaatkundigwerk; lozingswerk. Dit geeft aan dat een lozingswerk onder de hoofdgroep waterstaatkundigwerk valt. CodeList Bij de opgenomen enumeratielijsten is aangegeven of ze van het type CodeList zijn. Als dit het geval is kunnen de lijsten uitgebreid worden met attribuutwaarden die nog niet in het model gedefinieerd zijn. Bij de uitwisseling worden deze waarden voorafgegaan door het woord other. Een waarde die een verdere detaillering betreft van een hoofdtype uit de lijst bevat naast het woord other gevolgd door een :. Daarachter staat het hoofdtype uit de vastgestelde lijst (indien aanwezig/bekend), een ; en het gedetailleerde type. Hierdoor wordt een maximale compatibiliteit met bestaande systemen verkregen. Zie de voorbeelden. Toevoegen van een waarde aan de enumeratielijst voor een status van een plan waarvoor nog geen (hoofd)type is opgenomen: <imwa:status>other:doofpot</imwa:status> Verder detailleren van de enumeratielijst voor (hoofd)typen die al bestaan. Een bestaande waarde uit de enumeratielijst, in dit geval een realisatie gebaseerd op het principe van kan zonder meer worden gebruikt. <imwa:status>other:realisatie;lange termijn;5 jaar</imwa:status> Stel we hebben een status gebruikt waarbij de hoofdgroep wel bekend is welke nog niet in de lijst is opgenomen, bijvoorbeeld een status dat dit plan, om bepaalde redenen, nooit meer gerealiseerd zal worden, dan kunnen we deze als volgt toepassen bij de uitwisseling: <imwa:status>other:realisatie;nooit</imwa:status> pagina 24 van 83 Termen, afkortingen en schema s

25 3.7 GML en XML GML is een syntax om geo-objecten te beschrijven zodanig dat gebruik via het internet mogelijk is. Daartoe bouwt GML voort op de extensible Mark-up Language (XML) afkomstig uit de kringen van W3C, het consortium dat alle Internet-standaarden vaststelt. Eén van die standaarden is XML-schema bedoeld om de structuur van XML-documenten te beschrijven. Kennis van XML respectievelijk XML-schema is noodzakelijk om GML te kunnen begrijpen. Begrippen zoals 'gebouw' of 'planologisch gebied' worden niet in GML gedefinieerd, maar in een 'applicatieschema'. Het Basismodel Geo-Informatie is zo'n applicatieschema extensible Mark-up Language (XML) Om geo-informatie tussen GIS-systemen uit te wisselen is gecodeerde informatie noodzakelijk. XML is een op tekst gebaseerde codering (tekst gebaseerde codering staat tegenover binaire codering), en dus ook te lezen en te begrijpen door mensen (hoewel hiervoor niet ontworpen). In XML worden speciale woorden, de zogenaamde 'tags', onderscheiden door 'vishaakjes' (< en >). Een zo'n tag is <gebouw>. Tussen een openings'tag' <gebouw> en eind'tag' </gebouw> staat de 'inhoud' van de informatie. Tags plus inhoud vormen een 'element'. 'Elements' op hun beurt vormen een XML-document. 'Elements' komen voor binnen 'elements', binnen 'elements' enz., een zogenoemde geneste hiërarchie; <gebouw> <classificatie> </classificatie> <adres> </adres> </gebouw> XML-schema Om de structuur van XML-documenten te beschrijven is een aparte op XML-gebaseerde schemataal ontworpen; XML-schema. Zo wordt de structuur van het hiervoor genoemde gebouw-element vastgelegd in het volgende XML-document; <element name="gebouw"> <complextype> <sequence> <element name="classificatie" type="string'/> <element name="adres" type="string'/> </sequence> </complextype> </element> GML GML is het geografische dialect van de XML-taalfamilie. Termen, afkortingen en schema s pagina 25 van 83

26 <gml;boundedby> <gml;box> <gml;coordinates> , , </gml;coordinates> </gml;box> </gml;boundedby> <gml;featuremember> <gebouw gml;id:123> <classificatie> </classificatie> <adres> </adres> </gebouw> <featuremember> pagina 26 van 83 Termen, afkortingen en schema s

27 4. InformatieModel Water 4.1 Een toepassing van NEN 3610 Het InformatieModel Water (IMWA) is een toepassing van het Basismodel Geo-informatie, NEN 3610, voor de sector Water. Het is hiermee één van de toepassingen van deze norm. NEN 3610 vervult als algemeen geldende norm een paraplufunctie voor bestaande of nog te ontwikkelen informatiemodellen voor specifieke beleidsvelden. Hierdoor ontstaat de mogelijkheid om beleidsveld-eigen registraties van geo-informatie via de algemene overlappende classificatie van NEN 3610 met andere beleidsvelden uit te wisselen Structuur van het informatiemodel. De structuur van het IMWA is ontleend aan het Basismodel Geo-informatie. In bijlage C is hiervan een beschrijving opgenomen. Centraal staat dat het een object georiënteerd model betreft voor uitwisseling van geo-informatie. Objectoriëntatie betekent dat de informatie gemodelleerd is rond objecten. Alleen de informatie die rechtstreeks het object betreft is bij het object opgenomen. De objecten vormen de eenheid van informatie. Ook de relaties die objecten hebben met andere objecten is gemodelleerd. Dit maakt dat informatie over een object per object opvraagbaar is en ook de context van het object bekend en bevraagbaar is. Objecten met gelijke eigenschappen worden gegroepeerd in objectklassen IMWA geo-objectklassen. Het IMWA is een verdere uitwerking van de geo-objectklassen uit het Basismodel Geo- Informatie die relevant zijn voor het uitwisselen van geografische informatie tenminste zover die informatie door de sector water beheerd en uitgewisseld wordt. In onderstaande figuur wordt de Werkelijkheid nu gevormd door de sector water. De abstractie daarvan wordt gemodelleerd in het IMWA. Door middel van dit gemeenschappelijke model kunnen er vertaalregels opgesteld worden voor een centrale ontsluiting van decentraal opgeslagen informatie. Werkelijkheid data collectie abstractie geo-database geïmplementeerd in IMWA Het Basismodel Geo-informatie beschrijft een abstractie van de werkelijkheid die wordt vastgelegd in een geo-database. IMWA op zijn beurt is weer een abstractie van het basismodel Geo-Informatie InformatieModel Water pagina 27 van 83

28 Op modelniveau is het model IMWA een specialisatie van het model NEN Zie onderstaande figuur. pkg Aquo uitwisselmodellen NEN3610 IMWA Aquo domeinen «use» UM Aquo - metingen UM Aquo - krw «use» «use» figuur: relaties tussen Aquo uitwisselmodellen In het Basismodel zijn alle klassen abstract. In de figuren is dit weergegeven door een cursief lettertype voor het informatiemodel NEN Dit betekent dat van de klassen uit het Basismodel geen instanties gemaakt kunnen worden, dat wil zeggen dat geen individuele geo-objecten uit een klasse beschreven kunnen worden. Dit kan pas in de sectormodellen. In dit geval IMWA. Bijvoorbeeld een geo-object Meting kan pas beschreven worden als instantie van de objectklasse Meetobject uit IMWA en niet als instantie van de klasse Meting uit het Basismodel. Objecten die in IMWA voorkomen behoren tot de algemene klasse GeoObject van het Basismodel. Deze klasse is de superklasse waar alle IMWA klassen. Tussen de klassen van het Basismodel en het IMWA gelden de normale overervingsregels. Attributen en relaties die in het Basismodel gedefinieerd zijn gelden daarom ook voor het IMWA. Alleen als er voor attributen andere condities of waarden gelden worden ze in het IMWA nog een keer opgenomen. Bijvoorbeeld als in het Basismodel een attribuut optioneel is maar in het IMWA verplicht. Of als een attribuut in het IMWA een ander domein heeft dan in IMWA. Mogelijk is ook dat een attribuut in het Basismodel optioneel is maar in het IMWA niet gedefinieerd is. In al die gevallen wordt het attribuut met de gewijzigde opties nog een keer opgenomen. Het in het IMWA gedefinieerde attribuut overschrijft in die gevallen het Basismodel attribuut. 4.2 Relatie met bestaande normen en standaarden IMWA verwijst naar en maakt gebruik van regels die uitgewerkt zijn in een aantal normen en standaarden. Normen die zijn vastgelegd op nationaal niveau bij het NEN, en standaarden en afspraken die binnen de watersector worden toegepast. pagina 28 van 83 InformatieModel Water

29 Standaarden in relatie tot het model NEN 3610: 2005 Aquo-lex Aquo domeinen UM Aquo ISO 8601 ISO ISO ISO Basismodel Geo-informatie. Termen, definities, relaties en algemene regels voor de uitwisseling van informatie over aan het aardoppervlak gerelateerde ruimtelijke objecten. Waterwoordenboek zoals in beheer bij IDsW en basis voor de definitie van gegevensobjecten. Domeintabellen zoals gebruikt in andere onderdelen van de Aquo standaard en in beheer bij IDsW. Uitwisselmodel Aquo. Verdere detaillering van het IMWA voor de uitwisseling van specifieke gegevens zoals bijvoorbeeld meetgegevens. Deze beschrijft het gebruik van tijd referentie systemen bij data uitwisseling. Deze beschrijft de modelleertaal UML als conceptuele schematisatie taal. Hierin wordt een uitgebreide typehierarchie gegeven voor het aanduiden van geometrie of topologie van objecten. Beschrijving van de temporele aspecten van geo objecten. Standaarden voor uitwisselingsformaat ISO ISO ISO ISO In deze norm wordt onder andere het gebruik van landcode s beschreven. Deze zijn relevant bij het toekennen van identificatie s. Deze beschrijft het gebruik van coordinaat referentiesystemen bij de uitwisseling van geografische informatie. Voor de NEN3610 is gekozen tot het herleidbaar maken van alle coordinaten tot ETRS89 Hierin worden de elementen voor de uitwisseling van metadata beschreven. Een afgeleide hiervan is de NL kernset Metadata. In deze norm wordt de Geography Markup Language (GML) besproken. In NEN 3610 wordt voor het uitwisselingsformaat van bestanden (het technische formaat voor uitwisseling) gerefereerd aan GML. Voor IMWA geldt hiervoor dezelfde referentie. GML is hiermee het aan IMWA gekoppelde uitwisselingsformaat van conform het IMWA gemodelleerde bestanden. Voor IMWA komt een XML/GML schema beschikbaar voor import en export van en naar GML bestanden. Standaarden voor toepassing IMWA: Voor de toepassing van IMWA wordt verwezen naar praktijkrichtlijnen. In deze richtlijnen wordt toegelicht hoe verschillende uitwisselingsbestanden conform IMWA gecodeerd moeten worden. InformatieModel Water pagina 29 van 83

30 Standaarden voor presentatie: De uitwisseling van de presentatie, kleuren, symbolen et cetera, die bij de visualisatie van digitale gegevens een rol spelen is geen onderdeel van IMWA. Indien gewenst zal hiervoor een aparte praktijkrichtlijn moeten worden ontwikkeld. pagina 30 van 83 InformatieModel Water

31 5. Beschrijving IMWA: UML klassendiagram en catalogus In het voorafgaande hoofdstuk is het concept van InformatieModel WAter (IMWA) beschreven. In dit hoofdstuk is het concept uitgewerkt. De klassen worden aan elkaar gerelateerd, de attributen worden gedefinieerd en de domeinen worden aan attributen toegekend. In het diagram zijn ook de datatypen aangegeven in het geval dat ze bestaan uit een combinatie van attributen. De attribuutdomeinen die in de diagrammen genoemd worden zijn opgenomen in het volgende hoofdstuk. In hoofdstuk 2 wordt een algemene toelichting gegeven op het klasse-diagram en de klassebeschrijvingen. 5.1 IMWA klassendiagram Het volgende klassendiagram beschrijft het InformatieModel Water (IMWA) inclusief de relatie met het Basismodel Geo-informatie (NEN3610). In het diagram is bijvoorbeeld afgebeeld hoe de klasse Meting van het model IMWA is gedefinieerd als subklasse van de abstracte klassen Meting en GeoObject van NEN3610. Via deze sub- en superklasse relatie erft het IMWA alle voor de superklassen in het Basismodel aanwezige eigenschappen, attributen en condities van het Basismodel. Het hoogste niveau waarvan geërfd wordt is de superklasse GeoObject. Zo is bijvoorbeeld het attribuut identificatie bij de klasse GeoObject al gedefinieerd. Door de overerving is het een attribuut dat ook voor de subklassen geldt. Dit betekent dat attributen die bij een superklasse gedefinieerd zijn, bij een subklasse niet meer worden herhaald. Het wordt echter niet meer opgenomen in de afbeelding van de subklasse. Bij het lezen van de diagrammen dient hier rekening mee te worden gehouden. Beschrijving IMWA: UML klassendiagram en catalogus pagina 31 van 83