De Eerste Kamer der Staten-Generaal heeft 18 januari het Adviescollege ICT-toetsing gevraagd om te beoordelen of 1 juli 2022 als datum voor de inwerkingtreding van de Omgevingswet haalbaar is, gelet op de stand van zaken bij het Digitaal Stelsel Omgevingswet (DSO). Het is zeer verstandig van de Eerste Kamer om niet alleen te vertrouwen op de rooskleurige voortgangsbrieven van de minister.
Het is voor mij volstrekt helder dat het Adviescollege half februari met een zeer negatief advies zal komen wat betreft de stand van zaken bij het DSO momenteel. Het grote gevaar is dat dan besloten wordt tot een half jaar uitstel. Er zijn zulke fundamentele problemen met het DSO dat een half jaar uitstel slechts zal leiden tot doormodderen.
1. Problemen met de uitwisseling tussen gemeente en stedenbouwkundig bureau
De standaarden kennen te veel vrijheden en hierdoor ontstaan dialecten. Dit leidt tot problemen met de uitwisseling tussen gemeente en stedenbouwkundig bureau. Een stedenbouwkundig bureau dat in opdracht van een provincie een omgevingsdocument maakt in software X, kan deze niet vlekkeloos inlezen in software Y van de provincie.
Doordat de standaarden te veel vrijheden kennen, zijn leveranciers gedwongen keuzes te maken. Dit heeft geleid tot verschillende dialecten die allemaal voldoen aan de standaarden maar onderling niet of moeilijk uit te wisselen zijn. Om een voorbeeld te geven: de standaarden kennen 'juridische regel' als eenheid. Je mag één of meer 'juridische regels' opnemen in bijvoorbeeld een lid. Meer 'juridische regels' per lid is in strijd met de principes van objectgericht schrijven en leidt tot onnodig veel extra handelingen voor de gebruiker. Logisch dat sommige leveranciers ervoor gekozen hebben om slechts één 'juridische regel' per lid toe te staan. Andere leveranciers kozen ervoor om dit wel vrij te laten. Zonder nadere afspraken is een import op dit punt niet mogelijk. Zo zijn er nog talloze andere voorbeelden.
Ook is er nog geen integrale validator beschikbaar zodat kan worden gecontroleerd of wat het bureau heeft aangeleverd, valide is volgens de standaarden.
Problemen in de viewers van het DSO
De Provincie Utrecht ontdekte dat haar omgevingsverordening in de software van Tercera wel het juiste werkingsgebied bij een bepaalde activiteit weergaf, maar in de DSO-viewer niet. Uit onderzoek van het DSO bleek dat dit komt doordat er, als gevolg van de vrijheden in de standaarden, dialecten zijn ontstaan per leverancier. Al deze dialecten voldoen aan de standaarden, maar de DSO-viewer spreekt deze dialecten niet en dit leidt tot fouten. Wij en ook anderen hebben jaren geleden al gewaarschuwd hiervoor, maar hier werd niks mee gedaan. Nu worden de gevolgen zichtbaar helaas.
2. Het hele DSO is onnodig complex gemaakt
Hierdoor zijn er vele wegen die naar Rome leiden en dus veel foutgevoeliger. Een voorbeeld is de manier waarop bijvoorbeeld provincies wijzigingen in hun omgevingsverordening kunnen doorgeven aan het DSO.
Provincies hebben één omgevingsverordening en na publicatie van de initiële versie, gaan zij alleen deze omgevingsverordening wijzigen via een van de mutatiescenario’s. Omdat deze mutatiescenario’s nog niet door alle leveranciers worden ondersteund en ze nog steeds niet foutloos werken in het DSO, mag de provincie als Tijdelijke Alternatieve Maatregel het scenario 'intrekken en vervangen' gebruiken Dit houdt in dat als je bijvoorbeeld alleen artikel 7 wijzigt, je toch de hele nieuwe versie van het plan opstuurt, met daarin het nieuwe artikel 7.
Probleem is dat KOOP dit scenario wel ondersteunt, maar het Kadaster niet. Het Kadaster vereist dat voordat je een nieuwe versie plaatst, je eerst een aantal zaken in de oude versie moet beëindigen. Dit doe je via een DirecteMutatie-opdracht. Je geeft dus voordat je de nieuwe versie plaatst, eerst aan het Kadaster door welke tekstonderdelen (en activiteiten etc.) van de oude versie je wilt beëindigen.
Maar dat is niet genoeg: je moet ook voor zo’n tekstonderdeel alle eigenschappen meegeven. Een voorbeeld van zo’n eigenschap van een tekstonderdeel is de verwijzing naar de locatie. Aan iedere tekst is immers een werkingsgebied gekoppeld, zodat de burger weet op welk gebied bijvoorbeeld een juridische regel van toepassing is.
Het Kadaster checkt dan eerst of de eigenschappen van zo’n tekstonderdeel in hun systeem gelijk is aan wat de gemeente (via de plansoftware) doorgeeft via zo’n DirecteMutatie-opdracht.
Nu blijkt dat het Kadaster bij het inlezen van een versie van de omgevingsverordening deze verwijzingen naar locatie in een bepaalde volgorde opslaat in hun database die verschilt van de volgorde van aanleveren door de provincie (via de plansoftware). Maar als je vervolgens via een DirecteMutatie-opdracht een tekstonderdeel wilt beëindigen, keurt het Kadaster dit af omdat de volgorde waarin de verwijzingen naar locaties worden aangeleverd door de provincie afwijkt van hoe ze zijn opgeslagen door het Kadaster. De provincie kan nu niet meer publiceren en dus niet oefenen.
3. Het DSO is nog lang niet goed genoeg getoetst aan de praktijk
Hierdoor ontstaan er nog steeds nieuwe issues die blokkerend zijn bij het publiceren. De belangrijkste issues zijn:
Problemen met afbeeldingen en pdf’s
Steeds vaker loopt het DSO vast op omgevingsverordeningen en omgevingsvisies omdat deze veel afbeeldingen en pdf-bestanden bevatten. Het lukt dan niet om deze besluiten te publiceren. Dit komt omdat bij het ontwerpen van de standaarden onvoldoende rekening is gehouden met het feit dat decentrale overheden in hun plannen werken met relatief veel afbeeldingen en pdf-bestanden.
Daarnaast schrijft de STOP-standaard voor dat afbeeldingen een resolutie moeten hebben van minimaal 300 dpi. Dit is een veel hogere resolutie dan noodzakelijk, waardoor de bestanden onnodig groot worden.
Om een besluit te publiceren naar de Landelijke Voorziening Bekendmaken en Beschikbaarstellen (LVBB) wordt gebruik gemaakt van het zogenaamde 'kleine berichtenverkeer'. Deze methode kent een maximum aan de totale bestandsgrootte en daarnaast geldt hoe groter, hoe meer kans dat er wat misgaat. Dit in tegenstelling tot de methode 'grote berichtenverkeer'.
Foutieve en onvolledige validaties
Bij het aanbieden vanuit de plansoftware van besluiten wordt eerst e.e.a. gevalideerd. DSO-LV is 'over-complex' geworden waardoor er heel veel validaties nodig zijn. Er zijn intussen al meer dan 800 validatieregels! Ondanks dit indrukwekkende aantal zijn de validaties nog steeds onvolledig en soms onjuist of overbodig.
Onvolledige validaties in combinatie met het ontbreken van een testomgeving heeft voor de provincie Noord-Brabant geleid tot het niet meer kunnen publiceren, omdat het Ambtsgebied tijdens het testen dubbel geregistreerd is in het DSO waardoor nu alles blokkeert.
Het DSO kan nog geen ontwerp-besluiten aan
Ontwerp-besluiten worden niet goed verwerkt in het DSO waardoor ze niet zichtbaar zijn in Regels op de kaart.
Het DSO heeft moeite met grote/complexe geometrie
Het DSO had zoveel tijd nodig voor het valideren van werkingsgebieden die bestaan uit veel vlakken (zoals bijvoorbeeld natuurnetwerken uit omgevingsverordeningen of watergangen uit waterschapsverordeningen), dat er time-outs ontstonden en er niet kon worden gepubliceerd.
Dit probleem hebben we eind 2020 aangekaart. Omdat er niks met onze signalen werd gedaan, hebben we dit in de openbaarheid gebracht. Pas nadat Gemeente.nu hierover berichtte, werd er een taskforce Geo opgericht. Er zijn intussen wel vorderingen gemaakt, maar het probleem is nog steeds niet helemaal opgelost.
4. Lage beschikbaarheid / veel storingen
De DSO-organisatie geeft aan dat dit probleem veel minder groot is dan vroeger. Dat is niet onze ervaring. Na de kerstvakantie was het op 6 van de 9 dagen als gevolg van storingen en updates grotendeels onmogelijk om te publiceren naar de LVBB/DSO.
12-14 januari
Update doorgevoerd door het DSO. Publiceren was daardoor vrijwel onmogelijk. Het is sowieso raar dat updates worden doorgevoerd op werkdagen overdag.
17-18 januari
Storing met het aanroepen van een onderdeel van de validatie. Hierdoor kon niet worden gepubliceerd.
20 januari
Door het maken van een back-up door het DSO kon weer grotendeels niet worden gepubliceerd.
Als deze problemen nu al spelen terwijl er nog weinig wordt geoefend, geeft te denken.
Het Ministerie ziet 1 juli 2022 als startpunt. De problemen kunnen ook daarna worden opgelost. ''We zetten geen punt, maar een komma.'' Ook wordt gesteld dat ''dit soort problemen erbij horen''.
Ik ben het hier 100% mee oneens: dit soort grote fundamentele problemen horen er niet bij! En invoeren van een niet goed doordacht en getest systeem is onverantwoord.
Het enige verstandige besluit zal zijn: het vereenvoudigen van het DSO en dan bepalen hoeveel uitstel hiervoor nodig is.
