Op weg naar een omgevingsgegevensmodel

Beeld: Николай Начев / Pixabay

Enige tijd geleden vroeg Danny Greefhorst aandacht voor het toenemend belang van gegevensmodellering voor goede data. Eigenlijk is dat belang er al vanaf het begin van de verwerking van data en is het nooit weggeweest. Zie ook een recent artikel van Rick van der Lans daarover: gegevensmodellering is van wezenlijk belang voor het adequaat omgaan met gegevens, onafhankelijk van de opslagtechnologie. Het gaat hier niet om een technisch kunstje, maar om het begrijpen van de gegevens. Dat belang geldt mijns inziens ook voor de overheid bij de implementatie van de Omgevingswet.

In dit artikel introduceer ik het begrip ‘omgevingsmodel’. Een omgevingsmodel is een elektronische representatie van de fysieke werkelijkheid in een bepaald gebied, bijvoorbeeld het gemeentelijk grondgebied. Een ‘omgevings*gegevens*model’ specificeert de gegevensstructuur van omgevingsmodellen. Na een beschrijving van de contouren daarvan volgt een viertal overwegingen, en wel ten aanzien van (1) de Omgevingswet, (2) het innovatieproject Common Ground van de VNG, (3) het gemeentelijk gegevensmodel en (4) een landelijk omgevingsgegevensmodel. Het is duidelijk dat de uitwerking nog veel werk vergt. De vraag is: wie pakt het op, wie pakt het aan?

Teneinde in een gemeente de fysieke leefomgeving integraal te kunnen ontwikkelen, te beheren, te handhaven, te evalueren, et cetera, is het wenselijk – analoog aan de werkwijze in de industrie – alle relevante gegevens geïntegreerd op te slaan, ofwel op te slaan in een omgevingsmodel. Een omgevingsmodel is een afbeelding van alle objecten en processen binnen het gemeentelijk grondgebied. Op dit moment komt de term ‘digital twin’ steeds meer in zwang voor zo’n (near) realtime representatie van de reële omgeving. Zo’n model kan gebruikt worden om te beschrijven, te monitoren, te analyseren, te evalueren, te simuleren, te voorspellen, te plannen en meer. Zie ook figuur 1¹.

Het omgevingsmodel wordt gevuld vanuit een groot aantal bronnen en kan voor een groot aantal informatiefuncties gebruikt worden (zie figuur 2).

Vanuit het omgevingsmodel kunnen ook gegevens worden geleverd aan de bronnen (hub & spoke model). Een omgevingsmodel bevat een aantal kerngegevens van waaruit allerlei detailgegevens benaderd kunnen worden. Op gebiedsniveau is er bijvoorbeeld een GEBOUW zichtbaar in een geografisch informatiesysteem (GIS). Van daaruit kan ingezoomd worden op een bouwwerkinformatiemodel (BIM) van het gebouw. Binnen het BIM kan weer ingezoomd worden op onderdelen, zoals installatiemodellen of productmodellen. Voor iedere doorsnede zijn beperkingen ten behoeve van veiligheid of privacy in te stellen. Een omgevingsmodel maakt ‘virtueel ontwikkelen en beheren’ mogelijk. Aan het omgevingsmodel kunnen allerlei documenten en andere informatieobjecten gekoppeld worden. Zo krijg je een ‘omgevingsdossier’.

Omgevingsgegevensmodel

Om te komen tot een betrouwbaar omgevingsmodel is een adequaat omgevingsgegevensmodel nodig, een gegevensmodel, waarvan een omgevingsmodel een instantie is. In het Omgevingsgegevensmodel wordt de samenhang beschreven van alle objecttypen met aanpalende gegevens². Zie de indicatieve aanzet in figuur 3.

Het Omgevingsgegevensmodel geeft structuur aan het Omgevingsmodel (model van één instantie). Figuur 4 beeldt dat uit.

De uitwerking vergt nog veel werk. Daarbij dienen uiteraard allerlei vigerende standaarden als uitgangspunt. Denk aan de Europese richtlijn INSPIRE en aan standaarden voor de indeling en registratie van bouwwerken. Bij de detaillering dienen de verschillende Omgevingswetbesluiten betreffende bouw, activiteiten en leefomgevingskwaliteit (Bbl, Bal en Bkl) betrokken te worden.

Een viertal overwegingen

Overweging 1: Omgevingswet

Het Digitaal Stelsel Omgevingswet (DSO) bevat functionaliteit voor de registratie, publicatie en verwerking van omgevingsbesluiten, toepasbare regels en vragenbomen, vergunningen en meldingen, informatieproducten, begrippen en definities (stelselcatalogus), en digitale samenwerking.

In de oorspronkelijke opzet van het DSO werd de stroom van gegevens van bronhouders via informatiehuizen gezien als de hoofdstroom. Een informatiehuis zou een bundeling zijn van een aantal samenhangende taken in een bestuursorgaan. Tijdens de verdere ontwikkeling is de idee van informatiehuizen losgelaten en is de hoofdstroom door de minister in feite getransformeerd tot een grote verzameling stroompjes, per informatieproduct een stroompje. Dit naar aanleiding van een advies van het Bureau ICT-toetsing (BIT), omdat de implementatie te complex zou zijn³. De hoofdmoot van het DSO bestaat daardoor vooral uit plan-, regel- en procesgegevens en nauwelijks uit de fysiek-ruimtelijke gegevens waar het vanuit de thema’s gezien uiteindelijk om gaat. Uiteraard zijn die fysiek-ruimtelijke gegevens wel noodzakelijk en ze zullen ook gegenereerd worden en gevalideerd, verrijkt en verwerkt tot informatieproducten. De situatie zonder informatiehuizen betekent dat een omgevingsgegevensmodel als basis voor integratie en uitwisseling van de gegevens die nodig zijn voor de informatieproducten, harder nodig is dan ooit.

Het gegevensmodel van de Omgevingswet (CIMOW)⁴, gaat nu niet verder dan het modelleren van de regels; de ruimtelijke werkelijkheid wordt gereduceerd tot een (geometrisch gespecificeerde) locatie en locatieaanduidingen bij juridische regels, activiteiten en gebiedsaanwijzingen (functies en beperkingengebieden). De geometrische specificatie kan overigens wel afgeleid zijn van (‘geïnspireerd zijn op’) een reële of virtuele ruimte, bijvoorbeeld een perceel. Het zou wenselijk zijn de relatie tussen regels, omgevingswaarden, et cetera en fysiekruimtelijke objecten om te keren: een regel, een waarde, et cetera is een eigenschap van een object en niet omgekeerd. Hoe het ook zij, het gegevensmodel van de Omgevingswet zou gecompleteerd moeten worden met een gegevensmodel, dat de omgeving zelf betreft, een omgevingsgegevensmodel.

Overweging 2: Common Ground

De modernisering van de gemeentelijke informatievoorziening krijgt vorm in een groot project van de VNG, de realisering van een gemeentelijk ‘Gegevenslandschap’, de Common Ground. Deze is gericht op ontkoppeling van gegevens, bedrijfslogica en gebruikersinterface. Belangrijk is de opbouw van de data in een gemeenschappelijke basis, los van de applicaties. De kern van het model is dat gegevens binnen een gemeente kunnen worden ontsloten en beheerd via (standaard) software services/API’s op basis van een standaard informatiemodel. Figuur 5 geeft de Common Ground schematisch weer.

Een omgevingsgegevensmodel zou (uiteraard) als standaard-informatiemodel een plaats dienen te krijgen in de Common Ground.

Overweging 3: Gemeentelijk gegevensmodel

Er bestaat eigenlijk geen integraal gemeentelijk gegevensmodel, er bestaan alleen enkele gegevensmodellen, specifiek voor de gemeentelijke bedrijfsvoering: RSGB (Basis- en kerngegevens), RGBZ (Zaken) en ImZTC (Zaaktypen). Deze zijn te vinden in de gemeentelijke modelarchitectuur GEMMA. Daarnaast zijn er niet puur op gemeenten gerichte sectormodellen (zoals IMGeo voor grootschalige topografie). Intussen is er een verandering ten goede gekomen: er is een gemeentelijk gegevensmodel, een GGM! De gemeente Delft – beter gezegd: Arjen Brienen, in opdracht van de gemeente Delft – heeft dat ontwikkeld. Het open source GGM verbindt bestaande gegevensstandaarden en bouwt daarop voort. Het bestaat uit een basis, waarop specifieke beleidsdomeinen voortbouwen. De basis bestaat uit een kern (RSGB en RGBZ) en de algemene beleidsdomeinen Financiën, ICT en Dienstverlening. Specifieke domeinen (Burgerzaken, Veiligheid, Verkeer & vervoer, enzovoorts) hebben in principe geen relaties met elkaar, ze vallen alleen terug op de gemeenschappelijke gegevensdefinities in de basis. Ik vind de ontwikkeling van het GGM fantastisch en het verdient aanbeveling verdere ontwikkelingen, zoals die van een omgevingsgegevensmodel daarop aan te sluiten. Uiteraard dient het GGM tot een landelijke standaard verder ontwikkeld te worden.

Ik wil ervoor pleiten de omgevingsaspecten uit de verschillende domeinen (zoals Beheer Openbare Ruimte, Omgevingswet, Afval, Erfgoed/Archeologie, Erfgoed/Monumenten, Vergunningverlening en Toezicht en Handhaving/Bouwen) te integreren in één aparte laag in de basis, uitmondend in een gemeentelijk omgevingsgegevensmodel. Dit kan tevens meehelpen de ‘lappendeken aan standaarden’, waarover in de toelichting op het GGM gesproken wordt, te uniformeren.

Overweging 4: Omgevingsgegevensmodel NL

Het gemeentelijk omgevingsgegevensmodel dient ingebed te zijn in een overheidsbreed omgevingsgegevensmodel. Je kunt denken aan een opzet met een centraal model met uitbreidingen (zie figuur 6). Andere organisaties of sectoren zouden kunnen aansluiten. Uiteraard zou men dan kunnen proberen gemeenschappelijke elementen van overheids- en andere organisaties in het centrale model op te nemen. Dit is in principe alleen wenselijk als er voor die elementen (internationale) standaarden bestaan. Maar in de praktijk zal de overheid zulke standaarden al in het centrale model opgenomen hebben (bijvoorbeeld de standaarden van de OGC).

Het Omgevingsgegevensmodel NL dient aan te sluiten op de lopende ontwikkeling van een samenhangende objectenregistratie onder de naam DiS-Geo. Het Omgevingsgegevensmodel zou ingebed moeten zijn in een referentiearchitectuur voor het domein fysieke leefomgeving, zijnde een dochter van NORA, bijvoorbeeld: LORA: leefomgevingsrefentiearchitectuur.

Conclusie

De implementatie van de Omgevingswet vergt een omgevingsmodel, een elektronische representatie van de fysieke leefomgeving in het betrokken grondgebied. Om integratie en uitwisseling van gegevens mogelijk te maken dient zo’n model gestructureerd te worden. De betreffende gegevensstructuur noem ik het omgevingsgegevensmodel. Dat model hangt samen met verschillende actuele ontwikkelingen, met name betreffende de Omgevingswet, de Common Ground, het gemeentelijk gegevensmodel en de landelijke informatiearchitectuur.

Daarover concludeer ik:

• Het vigerende conceptueel model Omgevingswet, het CIMOW, is beperkt tot modellering van de regels, activiteiten en gebiedsaanwijzingen. Het zou gecompleteerd moeten worden met een gegevensmodel van de echte omgeving, met een omgevingsgegevensmodel dus.
• Het omgevingsgegevensmodel hoort als standaard-informatiemodel in het gemeentelijk gegevenslandschap Common Ground opgenomen te zijn.
• Het omgevingsgegevensmodel hoort als integrale laag thuis in het gemeentelijk gegevensmodel (GGM), zoals dat onlangs door de gemeente Delft ontwikkeld is.
• Het omgevingsgegevensmodel dient een integraal onderdeel te zijn van een omgevingsgegevensmodel NL, voor wat betreft het overheidsdeel als onderdeel van de referentiearchitectuur NORA.

De uitwerking van een omgevingsgegevensmodel vergt nog veel werk. De vraag is: wie pakt het op, wie pakt het aan?

Hein Corstens is zelfstandig informatiearchitect en adviseert onder meer gemeenten over de implementatie van de Omgevingswet en het DSO. Hein Corstens, die dit verhaal schreef op persoonlijke titel, bedankt Rob van Dort en Dirk Moree voor hun commentaar op een conceptversie van dit artikel.

¹ Deze figuur betreft de gemeente Zoetermeer, waarvoor ik in 2019 meegewerkt heb aan een implementatieplan voor gegevensmanagement in relatie tot de Omgevingswet

² De gegevensmodellen die in dit artikel aan de orde komen, zijn conceptuele gegevensmodellen. Die worden ook wel informatiemodellen genoemd.

³ Tweede Kamer, Kamerstuk 33118 nr. 98, 10-10-2017

⁴ ‘Conceptueel informatiemodel Omgevingswet (CIMOW)’, versie 1.0, Geonovum, 17-04-2020