Gevangen in standaarden

Het is logisch dat waterbeheerders (zelfs binnen dezelfde organisatie) naar oppervlaktewater kijken vanuit een eigen perspectief. Dat perspectief is door de jaren heen verwerkt in informatiemodellen en -systemen. Hergebruik en nut voor voor anderen van de verzamelde informatie staat daarbij niet hoog op de prioriteitenlijst. Dit heeft geleid tot een aantal complexe gegevensstandaarden die niet op elkaar aansluiten wat uiteindelijk leidt tot onbruikbare data.

Is een standaard eenmaal stabiel en heilig verklaard dan liggen de specificaties vast en wordt het lastig om koerswijzigingen in standaarden voor elkaar te krijgen. Vanaf dat moment staan innovaties op gespannen voet met standaarden.

In de praktijk worden diverse standaarden vooral technisch met ingewikkelde transformaties en datamapping aan elkaar geknoopt om iedereen maar tevreden te houden. Mooi voorbeeld is de estafette tussen de informatiemodellen waar de waterbeheerder mee te maken heeft:  DAMO >> IMWA >> INSPIRE. Bij iedere gegevensoverdracht gaat een beetje informatie verloren. De standaarden zijn vanaf een bepaald punt domweg incompatible, al beschrijven zij dezelfde werkelijkheid. In het generieke datamodel voor waterbeheerders (DAMO) is deze worsteling van de standaarden goed te zien. Zoek het object oppervlaktewaterlichaam maar eens op. Het blijkt dat voor dit object behoefte is aan maar liefst drie 'unieke' identificatievelden (oppervlaktewaterlichaamID, code,  lokaalID), waar je mag verwachten dat één toch echt wel volstaat. Het object is ontstaan uit objecten van hiërarchisch hogere informatiemodellen  zoals BGT en NEN3610, waarbij in DAMO nog de opmerking wordt geplaatst dat de definitie van deze bovenliggende objecten eigenlijk niet juist is (!). De verschillen lijken triviaal, maar leiden uiteindelijk tot complexe informatiesystemen, veel voorbereidingen bij gegevensuitwisseling  en leveringen van onbruikbare data.

Nog fraaier is dat er kennelijk meer dan 250 watertypen nodig zijn om oppervlaktewater te beschrijven vanuit diverse invalshoeken, en minstens net zo kwalijk, verspreid over verschillende objecten van verschillende informatiemodellen. Op hoeveel manieren kun je zeggen dat een beek een beek is, en op hoeveel plekken moet dat dan vastgelegd worden ?

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

Voorbeeld KRW

Het informatiemodel KaderRichtlijn Water (KRW) kent o.a. de watertypen ‘Grote diepe kanalen met scheepvaart’ en ‘Grote diepe kanalen zonder scheepvaart’.

Normaliter zijn deze typeringen de uitkomst van een analyse en worden gecodeerd in een KRW model opgeslagen. In dit voorbeeld als code ‘M07a’ en ‘M07b’. Helemaal goed, maar interpreteer dit niet als een watertype. Het is een kwaliteitslabel, dat is iets anders.

Iemand kan ook achter een beeldscherm gaan zitten en zelf kunnen gaan bepalen of een water een groot, diep kanaal met scheepvaart is. Dezelfde overwegingen zijn eerder door anderen ook al gemaakt vanuit een ander perspectief (om te beginnen door de landmeter). Wie zorgt er dan voor de consistentie van toegekende watertypen over alle systemen heen?

Dat er werk dubbel gebeurt met misschien zelfs tegengestelde resultaten komt omdat de definities van watertypen onhandig zijn opgesteld of verkeerd worden toegepast.

Het grootste bezwaar is dat fysieke kenmerken (groot en diep) in een watertype wordt samengevoegd met een ander kenmerk zoals de aanwezigheid van scheepvaart. Dat laatste kenmerk kan beter automatisch afgeleid worden van het officiële vaarregister van het ministerie van IenW, hoewel het geen sinecure is om deze koppeling te leggen. Het informatiemodel DAMO heeft nota bene ook een speciaal object vaarweg.

Andere voorbeelden van informatie die beter automatisch afgeleid en/of separaat vastgelegd kan worden zijn de eigenschappen ondergrond (Zand/Klei, Kalk, Veen), chloridegehalte, stroming, etc. Nu worden ze te vaak meegenomen in de benaming van een watertype.

Tot slot blijkt dat sommige watertypen ook impliciete eigenschappen bevat. De twee genoemde watertypen hierboven betreft bijvoorbeeld altijd zoet water. Je moet het maar weten.

Voorbeeld DAMO

De watertypen zoals DAMO beschrijft zijn door de tijd ook flink versnipperd. Sloot, kadesloot, kavelsloot, poldersloot, te verlanden sloot, vaarsloot, wegsloot, dijksloot, zure sloten, licht brakke sloten.. de lijst is eindeloos lang.

Ook hier weer wordt te pas en te onpas een basis typering (sloot) verweven met functies (varen), locaties (polder, boezem) of ondergrond (zandgaten, grindgaten, kleigaten). Waarom? Data Management t.a.v. een thema sloot wordt zo alleen maar complexer.

Voorbeeld BGT / IMGeo

Hoe zit het dan met de hiërarchisch hogere standaarden, die zijn toch zeker generiek? De BGT kent inderdaad een kort lijstje met watertypen en bevat de waarden waterloop en watervlakte dat bijna alles al afdekt. Alleen greppel als apart type ontbreekt nog. Maar er staan ook nog wat andere waarden in de lijst zoals zee en 'greppel, droge sloot', die net als de KRW en DAMO verwijzen naar impliciete eigenschappen. Vraagt niemand zich af of dat in deze vorm iets toevoegt?

Het BGT-type water lijstje is belangrijk omdat de waterbeheerder deze verplicht moet gebruiken in haar processen. De BGT is immers een basisregistratie. Maar omdat men het BGT lijstje toch te compact vond is het toegestaan dat de BGT naast de vastgestelde (dus verplichte) inhoud ook aanvullende (dus optionele) inhoud mag bevatten. De BGT bouwt voort op het model IMGeo, dus kan het lijstje van IMGeo, dat langer is,  in hetzelfde record NAAST HET LIJSTJE VAN DE BGT gebruikt worden. Wat een warboel..
Dus in de BGT kan in één record staan dat een waterdeel een waterloop is, maar ook een sloot.

Zelfs de watertypen van het IMGeo model bevatten waarden die versleuteld zijn met hun functie (gracht, haven) en wordt 'meer, plas, ven en vijver' op één hoop gegooid, terwijl dat juist wel onderscheidende typen zijn. IMGeo krijgt voor dit onderdeel dan ook geen schoonheidsprijs.

Hoe kan het beter?

Een fictief informatiesysteem voor waterbeheerders biedt natuurlijk de ruimte om creatief met standaarden om te gaan, ze mogen even opzij gelegd worden.

Als er dan toch geschrapt wordt in watertypen, wat zijn dan de uitgangspunten,  wat blijft er over van de huidige standaard, waar worden gegevens geregistreerd, en hoe wordt de consistentie bewaakt ? Deze blog van vandaag geeft alleen antwoord op de eerste vraag.

Wikipedia is weliswaar geen standaard, maar biedt veel en zeer relevante informatie als je maar de moeite neemt om goed te lezen. Kijk bijvoorbeeld naar de pagina over watergangen of waterlopen. Daar is voor een waterbeheerder prima uit te vissen dat er in de basis maar een beperkt aantal watertypen nodig zijn en dat de overige eigenschappen beter apart geregistreerd kunnen worden. Zo is de volgende indeling bedacht, die idealiter al in de BGT (en IMGeo) toegepast zou moeten worden, maar nu wordt meegenomen in het fictieve informatiesysteem DEMO.

waterloop: rivier, beek, nevengeul, wadi, kanaal, sloot, greppel, spreng, [default] waterloop

watervlakte: gracht, haven, meer, plas, ven, vijver, [default] watervlakte

aanvullende eigenschappen (apart registreren):

• stromingstoestand: stilstaand, langzaam stromend, snelstromend
• saliniteit: zoet, brak, matig zilt, zout
• oorsprong: natuurlijk, kunstmatig, sterk veranderd
• persistentie: permanent, droogvallend, getijde
• categorie: primair, secundair, tertiair

functie(s): vanuit andere objecten worden functies gerelateerd aan waterlopen/-vlakten (tegen database richtlijnen in), bijvoorbeeld bij object vaarweg wordt een verwijzing gemaakt naar een object waterdeel of set van waterdelen voor de functie scheepvaart.