Areaalgegevens uitwisselen op basis van IMBOR

Op 30 januari 2020 werkte een groep vertegenwoordigers van overheden, softwareleveranciers, adviesbureaus en Bouwend Nederland samen aan het thema “Gegevens uitwisselen”. Naar aanleiding van de startbijeenkomst over IMBOR, OTL en ILS. In dit blog deel ik de resultaten van en de aanbevelingen uit deze werksessie. Wil je meedenken of ben je benieuwd hoe we hiermee verder gaan? Je leest het onderaan de blog. Veel leesplezier.

Uitgangspunten voor de opdracht

De deelnemers werkten aan het vraagstuk vanuit een concrete opdracht. Die luidde: ga uit van een bouw- of onderhoudsproject, met één opdrachtgever en één opdrachtnemer.

De opdrachtgever (asset manager) heeft zijn informatiebehoefte vastgelegd in een Objecttypebibliotheek (OTL) op basis van 80% selectie uit IMBOR en 20% eigen aanvullingen op IMBOR. Hierin staan “administratieve gegevens” die hij wil weten bij zijn objecten.

In de Informatieleveringsspecificatie (ILS) vraagt de opdrachtgever het volgende:

• De geometrie van objecten met het gewenste bestandsformaat;
• De administratieve gegevens over de objecten conform IMBOR / OTL met het gewenste bestandsformaat;
• De overige informatie over objecten (documenten, of andere datasets) met gewenste bestandsformaten;
• Voorwaarden rondom samenwerking en uitwisseling en validatie van gegevens;
• Frequentie van leveringen.

User stories

In twee groepen werkten de deelnemers aan user stories; het belang of de gewenste uitkomst beschreven vanuit de gebruiker. Een groep dacht na over het uitwisselen van areaalgegevens vanuit het belang van de opdrachtnemer, de andere groep vanuit de asset manager (met een voorbeeldproject over bomen).

• Als Asset manager:

wil ik actuele, betrouwbare en complete gegevens over de bomen in mijn areaal ontvangen, met frequente leveringen vanuit het project
zodat ik kan aantonen dat mijn bomen veilig zijn en aan mijn wensen voldoen.

• Als Opdrachtnemer van een bouw- of onderhoudsproject:

wil ik een gestandaardiseerde, functionele specificatie met de gegevens over het areaal op dezelfde manier aangeleverd als ik het moet terugleveren
zodat ik weet welke data, en hoe ik de data terug moet leveren aan mijn opdrachtgever, en ik dit op efficiënte wijze en zonder discussie kan uitvoeren

Het proces

Beide groepen hebben het proces van uitwisselen van gegevens uitgewerkt, hieronder ben ik zo vrij geweest de twee samen te voegen en de nadruk te leggen op de uitwisseling van gegevens over het areaal. De laatste drie stappen worden steeds herhaald tijdens het project, zodat de areaalgegevens constant actueel zijn, en beide partijen beschikken over dezelfde informatie.

Common Ground

Het bovenstaande proces is natuurlijk beschreven met als doel: applicaties zodanig inrichten dat de informatie over het areaal op vlotte manier beschikbaar is. Hierbij valt een parallel te trekken met de Common Ground-beweging bij de overheid:

“[…] de ICT-systemen dreigen vast te lopen als gevolg van de snel wassende stroom aan digitale gegevens. De ontsluiting van deze gegevens loopt via een complex systeem van koppelingen. Het maakt het huidige ICT-systeem weinig flexibel, kwetsbaar en duur. En het staat daarmee een optimale dienstverlening aan burgers en ondernemers in de weg. Dit besef zette een beweging in gang voor de stapsgewijze ontwikkeling van een nieuwe, toekomstbestendige gemeentelijke ICT-infrastructuur. De door de Taskforce Samen Organiseren enthousiast omarmde beweging kreeg de toepasselijke naam Common Ground." (bron)

Aan de hand van deze infographic hebben we het proces nagelopen op basis van de principes die bij Common Ground zijn geformuleerd. De belangrijkste principes op een rij:

1. Component gebaseerd: de “areaalgegevens” worden gescheiden van applicaties, met als groot voordeel dat een asset manager en een opdrachtnemer elk meerdere applicaties kunnen hebben die dezelfde areaalgegevens gebruiken. Een “silo systeem” waarin beide moeten inloggen om de areaalgegevens te kunnen lezen is niet nodig. We laten voor nu in het midden of ze beiden dezelfde bron van gegevens gebruiken, of dat ze elk een database met de areaalgegevens hebben.
2. Open: beide partijen moeten goed weten hoe ze samenwerken en welke afspraken er zijn rondom gegevensuitwisseling. De manier waarop gegevens worden uitgewisseld en de rol van beide partijen is in het beschreven proces zeer transparant.
3. Vertrouwd: privacy en security. Bij Common Ground gaat dit om belangrijke principes omdat het ook over persoonsgegevens van burgers gaat. In IMBOR worden op dit moment geen persoonsgegevens verwerkt. Zodra verificatie en validatiegegevens worden toegevoegd, wordt dit natuurlijk wel een thema: voeg je toe WIE de areaalgegevens heeft geleverd, opgesteld, gevalideerd? En mag je dit dan weer delen met de volgende partij?
4. Eenmalig beheren en bij de bron vastleggen van areaalgegevens: dit is meteen een dilemma: moet de opdrachtnemer de gegevens dan publiceren, en de asset manager deze alleen bekijken? Dan wordt de informatie over het areaal straks over heel veel locaties verspreid bij alle opdrachtnemers. De asset manager moet in elk geval beschikken over alle informatie over zijn areaal, er ook gegevens leveren aan de Basisregistratie Grootschalige Topografie (BGT. Hierbij komen er ook dilemma’s boven: nu worden de gegevens over het areaal dubbel opgeslagen, bij de asset manager en nationaal. Wordt dat straks nationaal? Moet de asset manager dan straks de gegevens splitsen en op twee plekken neerzetten?
5. Regie op gegevens: dit thema speelt vooral bij gegevens over personen. Wie is de rechtmatige partij bij areaalgegevens? Het meest logisch is de asset manager. Wel nog even dubbel nadenken: is de sloot bij een provinciale weg nu van de provincie, of hoort die bij het waterschap? Of gaan beiden een deel van de data leveren over die sloot? En wie mag nu welke eigenschap van die sloot aanpassen?
6. Maak van Standaarden maar Open Standaarden: de areaalgegevens moeten wel met een open formaat worden uitgewisseld, omdat je anders verplicht wordt om specifieke software aan te schaffen. Dit leidde meteen tot het gesprek: in welk formaat moeten areaalgegevens worden uitgewisseld?

Conclusie: Hoe gaan we nu uitwisselen?

Er zijn veel open uitwisselformaten denkbaar, waarmee deze vraag beantwoord kan worden:

• Een open-GIS formaat zoals GML met IMBOR-informatie in XML
• Een open CAD-uitwisselformaat zoals IFC met IMBOR-informatie in XML
• Een COINS pakketje of de (ICDD) opvolger daarvan (voor echte nerds daar denkt BIM loket over na): Voor ICDD en NTA 8035 is een Github gestart: https://github.com/bimloket/COINS-3.0-ICDD

Voorwaarden voor het uitwisselformaat

In plaats van een keuze te maken, hebben we voorwaarden opgeschreven waaraan het uitwisselformaat moet voldoen:

• Zo veel mogelijk gebruiken van bestaande, internationale standaarden; niet zelf (in Nederland) iets nieuws bedenken.
• Korte doorlooptijd van implementatie, we moeten de gegevensuitwisseling wel binnen 5 jaar met uitbreidingen aan bestaande technologie kunnen implementeren.
• Beheerders moeten het eens worden over de standaard, bijvoorbeeld IMBOR en GWSW.
• De standaard moet geschikt zijn om zoveel mogelijk vormen van data de delen.
• Bij de data moeten we metadata of bestandsdefinities kunnen meegeven, ten behoeve van verificatie.
• Het uitwisselen van gegevens mag niet leiden tot informatieverlies.
• Daarnaast het volgende verzoek vanuit de softwareleveranciers: er moet een onafhankelijke validatiemogelijkheid komen van gegevens. Zodat we straks geen “datapakketjes” krijgen, die door de ene leverancier niet, en de andere wel worden goedgekeurd “conform IMBOR”. Misschien wel op landelijk niveau, omdat je naast IMBOR straks ook GWSW hebt, en ICDD, en BGT, en…….

Aanbeveling: Roadmap en VISIE

De deelnemers hebben dringend behoefte aan een roadmap en visie, waarin CROW aangeeft wat het programma is rondom IMBOR, welke targets er zijn, enzovoorts.

Het is maar goed dat we binnenkort (maart/april 2020), onder vlag van het BIM loket, verder praten met gebruikers, om het eens te worden over de gebruikerswensen rondom “Areaaldata uitwisselen”.

Wil je daarbij meedenken, of heb je aanvullingen naar aanleiding van deze blog?

Neem contact met me op: elisabeth.kloren@crow.nl
Of meld je aan voor de eindbijeenkomst van het traject op 26 maart 2020.

Groetjes, Elisabeth Klören