In een omgevingsplan legt de gemeente haar beleid voor de fysieke leefomgeving in regels vast. Elke regel heeft een werkingsgebied: de plek of plekken binnen het gemeentelijk grondgebied waar die regel geldt. Zo’n werkingsgebied baken je af met de begrenzing er van; preciezer: de geometrie van de buitengrens van dat werkingsgebied. Die geometrie kan veranderen bij wijziging van regels of bij veranderingen in het grondgebied. Dat roept de vraag op hoe je dat beheersbaar houdt oftewel hoe je werkingsgebieden beheert.
Eén van de aspecten waarop het omgevingsplan verschilt van een bestemmingsplan is dat het omgevingsplan gewijzigd kan worden. Vernieuwing van beleid en ontwikkelingen in de fysieke leefomgeving kunnen aanleiding zijn het omgevingsplan daarop aan te passen. Dat kan met zich mee brengen dat werkingsgebieden veranderen en dus de geometrie daarvan moet wijzigen. Dat is nieuw in vergelijking met een bestemmingsplan. De bestemmingsplankaart wordt gemaakt ten behoeve van de vaststelling van dat plan en wijzigt daarna niet meer. De vertrouwde werkwijze voor het samenstellen van de bestemmingsplankaart moet dus op de schop. Het werken met een omgevingsplan vereist niet alleen het initieel creëren van werkingsgebieden maar vooral aandacht voor het beheren van – de geometrie van – die werkingsgebieden.
Stel, er zijn regels in het omgevingsplan opgenomen om woning-(gebieds-)ontwikkeling mogelijk te maken op een paar plekken binnen de gemeente. Die plekken vormen gezamenlijk het werkingsgebied van de regels voor die ontwikkeling. Die geometrie kan gemaakt zijn met bijvoorbeeld CAD-software (of software met CAD-functionaliteit). Voor zover ik weet bevat plansoftware dergelijke functionaliteit niet omdat hiervoor al goede oplossingen zijn. In de plansoftware zijn dan één of meer zgn. ‘Locaties’ (STOP/TPOD-term) opgenomen die aan de desbetreffende regels gekoppeld zijn als zijnde het werkingsgebied daarvan. Enige tijd later besluit de gemeente om op meer plekken dergelijke ontwikkelingen mogelijk te maken. Een bestaande plek wordt bijvoorbeeld vergroot en er komen plekken bij. Aan de regels verandert niets, alleen het werkingsgebied wordt groter. De geometrie daarvan moet dus aangepast worden. En die ligt vast in de plansoftware bij de desbetreffende Locaties. Maar voor aanpassing is CAD-functionaliteit nodig. Hoe exporteer je die geometrie zodanig dat die na aanpassing weer geïmporteerd kan worden bij de desbetreffende Locaties? Door objectgericht te denken en werken en gebruik te maken van de juiste software!
Die objecten, dat zijn de Locaties in de plansoftware. Bijvoorbeeld het ‘Woningbouwontwikkelingsgebied Zeeheldenbuurt’ en ‘Woningbouwontwikkelingsgebied Buitengebied-Oost’ (zgn. noemers van de Locaties). Met die noemers hebben de Locaties een unieke en betekenisvolle aanduiding en kunnen ze als object uitgewisseld worden tussen de benodigde software. Maar dan moet die software wel objecten kunnen verwerken. CAD-software kan dat m.i. niet, hier komt de GIS-software in beeld, met CAD-functionaliteit om geometrische grenzen nauwkeurig te kunnen karteren. GIS-software is wel in staat om objectgericht te beheren. Een overstap van CAD- naar GIS-software lijkt dan ook onvermijdelijk.
Dit is slechts een simpel voorbeeld. In de praktijk zullen er voor de diverse regels allerlei verschillende werkingsgebieden nodig zijn die samengesteld worden uit nog veel meer Locaties. De uitdaging is om die Locaties goed te kunnen beheren.
Het proces en de werkwijze voor het creëren en aanpassen van de geometrie van werkingsgebieden verschilt al met al van dat voor het opstellen van de bestemmingsplankaart. Dit grijpt vooral in op de werkzaamheden van bestemmingsplantekenaars en geo-specialisten. Ik raad hen, en andere betrokkenen bij het omgevingsplan, aan zich te verdiepen in wat het omgaan met het omgevingsplan vraagt en zich de nieuwe werkwijze en tools eigen te maken, voor inwerkingtreding van de Omgevingswet. Bevraag ook je plansoftwareleverancier hierover. En wordt het wijzigen van het omgevingsplan uitbesteed aan een ruimtelijk adviesbureau, stem dit dan met hen af. Zelf ben ik betrokken bij een werkgroep van enkele gemeenten en de VNG waarin we deze problematiek pogen te doorgronden. Ik merk dat meerdere gemeenten hiermee ‘aan het stoeien’ zijn. Prima, vooral doen! En zeker de ervaringen uitwisselen. We kunnen veel van elkaar leren, er moet nog veel ‘ontdekt’ worden. Genoemde werkgroep publiceert haar ervaringen op de website van het Gemeentelijk GeoBeraad. Ik ben benieuwd naar andere ervaringen.
Er zijn 3 reacties op dit artikel
Thomas van Offeren
Hallo Arjan, Ik begrijp dat je liever geen (merk)namen noemt van softwarepakketten. Maar ik benoem gewoon man en paard als je het niet erg vind. Gewoon voor de duidelijkheid :) Bij CAD-software denk ik aan de AutoCAD en Microstation pakketten. Bedoeld om de (geografische) basisregistraties BAG-BGT te beheren. Met CAD kan je goed de bouw- en revisietekeningen die doorgaans in DGN, DXF formaat worden opgeleverd, verwerken en héél exact de grenzen bepalen. Maar inderdaad minder goed 'objectgericht' werken. De computer maakt er, op basis van het point-boundary systematiek, in de database geografische vlak-objecten van na het befaamde 'inchecken'. Die geografische objecten (vlakken) kun je juist weer wel goed inlezen, beheren en verwerken met softwarepakketten als QGIS en ArcGIS (in Geopackage of Shape formaat) om er (multi-vlak) werkingsgebieden van te maken. In de tussentijd (afgelopen jaren) zijn de CAD en GIS software meer en meer naar elkaar toegegroeid. Dus of het nog steeds zo is weet ik niet: maar ik heb indertijd begrepen dat je met de CAD-software echt één grenslijn hebt tussen twee aan elkaar grenzende vlakobjecten. Terwijl als je heel ver inzoomt in Shape-vlakken, dan kan het voorkomen dat er op een gegeven moment een millimeter overlap (of leemte) tussen het linker en rechter vlakobject zit. En als je van Shape-vlak-objecten weer lijnen maakt om in de geografische objecten in de CAD-software bij te werken, krijg je 'dubbele grenslijnen die net niet over elkaar heen liggen'. Terwijl GIS-software indertijd minder goed was in de CAD-functionaliteiten. Het exact overnemen van lijnen en punten uit CAD-bestanden (DXF, DWG) en grenslijnen op de exacte coördinaten 'snappen'. In het geval van een 'woningbouwontwikkelingsgebieden' zal het niet erg zijn en kan je die gebieden prima in GIS beheren en verwerken. Zeker als ontwikkelingsgebieden niet/nooit aan elkaar grenzen. Is er wel een gemeenschappelijke grens tussen twee gebieden die elkaar niet mogen overlappen (op milimeter-niveau) en/of waar geen (millimeter) leemte tussen mag ontstaan, dan ben je tot CAD software veroordeeld. In mijn plansoftware heb ik geen optie om individuele 'Locaties' (bijvoorbeeld: Woningbouwontwikkelingsgebied Zeeheldenbuurt’ en ‘Woningbouwontwikkelingsgebied Buitengebied-Oost’ ) te registreren. Uiteraard kan ik wel een gebied 'Woningbouwontwikkelingsgebied Zeeheldenbuurt' registreren onder de noemer 'Woningbouwontwikkelingsgebied Zeeheldenbuurt'. En een apart gebied met de noemer ‘Woningbouwontwikkelingsgebied Buitengebied-Oost’. Maar dan zal je die twee (of meer) gebieden ook allemaal individueel moeten Annoteren bij de regels rondom Woningbouwontwikkelingsgebieden. Ook heb ik dan iets als 'gebied' geregistreerd, terwijl het eigenlijk een Locatie is. Daarom is het volgens mij de bedoeling dat ik (lokaal) in het GIS-pakket de individuele Locaties 'Woningbouwontwikkelingsgebied Zeeheldenbuurt en -Buitengebied-Oost' beheer. Al dan niet gevoed vanuit de CAD-software voor de exacte grens van de objecten; zonder overlap of leemte tussen de aan elkaar grenzende objecten (woningbouwontwikkelingsgebieden). En dan vanuit het GIS-pakket de individuele Locaties als multivlak samenvoegen tot één kaartlaag in een Shape-file met de noemer: 'Woningbouwontwikkelingsgebieden" en dat bestand registreren in de plansoftware onder de noemer 'Woningbouwontwikkelingsgebieden' om vervolgens te (laten) Annoteren zodat alle regels die betrekking hebben tot alle woningbouwontwikkelings-locaties in één keer geannoteerd zijn aan het woningbouwontwikkelingsgebied. En wanneer er in één van de Locaties weer andere regels gelden ten opzichte van de andere Locaties, dan zal daar, volgens mij, toch nog weer een apart Werkingsgebied voor gemaakt moeten worden. Met bijbehorende extra Annotatie. De crux zit hem dan inderdaad in het actualiseren van het bestand met de (bestaande) noemer 'Woningbouwontwikkelingsgebieden' in GIS (al dan niet gevoed vanuit CAD-software). Een nieuw bestand uploaden met dezelfde naam in de plansoftware kan gewoon, maar ik weet niet wat het met de Annotaties doet. Verwijder je eerst de kaartlaag, dan zijn de Annotaties volgens mij zeker kwijt. Dank voor de tip om daarover mijn softwareleverancier te bevragen. De uitdaging om Locaties goed te beheren is er inderdaad één. Zeker als er meerdere 'beheerders Werkingsgebieden Omgevingswet' zijn. Een gestructureerde werkwijze, duidelijke documentatie over de bron-geometrie van de (individuele) Woningbouwontwikkelingsgebieden en een gegeven over wanneer de gebieden geactualiseerd moeten worden, zal dan een vereiste zijn (metadata op orde houden).
Bert
Volledig mee eens. Je hebt dus Cad software nodig met Gis mogelijkheden. Als je tekent zul je object gericht moeten gaan werken. Met het koppelen van gegevens aan bv. vlakken. Als je dan ook nog de "locatie"-versies gaat opslaan in een database omgeving houd je overzicht over de juiste locaties, en de verschillende versies ervan. Je moet dan wel goede afspraken maken over het wijzigen van vlakken e.d. in de plansoftware. Dit zou dan niet moeten. Je tekent in de Cad-omgeving.
Arjan Kloosterboer
Mooi betoog, Thomas. Helemaal mee eens dat je CAD-functionaliteiten nodig hebt om de grenzen van (locaties zijnde) gebieden exact te kunnen karteren, zodanig dat een grens hetzelfde is voor de gebieden die aan weerszijden van die grens liggen. Wellicht kan het helpen om ook topologische relaties vast te leggen, bijvoorbeeld dat het ene gebied aan het andere grenst en dat er daarbij sprake is van één grens die ze beide delen. Dan zit je al meer op GIS-functionaliteit (met CAD-consequenties). En of nu GIS-software met CAD-functionaliteit nodig is of CAD-software met GIS-functionaliteit, dat is m.i. niet relevant, beide zijn nodig. Het tweede deel van je reactie gaat over het beheer binnen de plansoftware. Daar wordt echt objectgericht beheerd, de objecten zijn de Locaties waarvan er meerdere typen bestaan. De belangrijkste zijn Gebied en Gebiedengroep (allemaal in STOP/TPOD-terminologie). Je schrijft dat je individuele gebieden (in mijn ogen Locaties zijnde Gebieden), zoals 'Woningbouwontwikkelingsgebied Zeeheldenbuurt' en 'Woningbouwontwikkelingsgebied Buitengebied-Oost' al in je CAD/GIS-software samenvoegt (tot een multivlak-geometrie) om het resultaat als Gebied in je plansoftware te kunnen gebruiken. Dat lijkt mij in dit geval niet de juiste werkwijze. Beide woningbouwontwikkelingsgebieden hebben blijkbaar een eigen bestaansrecht. Vanuit objectgericht werken-perspectief zijn het dan twee objecten, vanuit STOP/TPOD-perspectief twee Gebieden die je met je plansoftware als zodanig vastlegt. En die groepeer je in een (Locatie zijnde een) Gebiedengroep (met als noemer 'Woningbouwontwikkelingsgebied'. En die Locatie annoteer je als werkingsgebied. Als er een woningbouwontwikkelingsgebied bij komt is het enige dat je hoeft te doen, dat Gebied aan je registratie in je plansoftware toevoegen (nadat je dat met CAD/GIS gecreeerd hebt) en onderdeel maken van de eerder genoemde Gebiedengroep. Als voor een specifiek woningbouwontwikkelingsGebied specifieke regels gelden, dan annoteer je die regels met als werkingsgebied dat ene Gebied. En bij wijziging van de geometrie van één van de woningbouwontwikkelingsgebieden voer je die aanpassing door in je CAD/GIS-software en update daarmee vervolgens het desbetreffende Gebied in je plansoftware. Aan je annotaties hoe je niets te veranderen. Zowel de specifieke regels voor dat gebied als de algemene regels voor woningbouwontwikkelingsgebieden krijgen daarmee een gewijzigd werkingsgebied. Al met al, denk en werk objectgericht, dan kun je gestructureerd Locaties beheren en 'kont het allemaal goed' (mits je plansoftware de vereiste ondersteuning biedt).
Plaats een reactie
Reageren? Deel hier uw mening. Uw e-mailadres wordt niet gepubliceerd.