Een steeds terugkerende onderwerp, als je met mensen spreekt over de BGT, is: “waar leggen we de bronhoudergrens ?”
In eerste instantie wordt gedacht aan de kadastrale grens. Die komt per slot van rekening ook uit een authentieke registratie en voor twee gemeenten onderling zou dat willicht een prima bronhoudergrens zijn. Ik ben betrokken bij een project bij de provincie en die “doorsnijdt” de gemeenten met haar provinciale wegen en daarvoor komt de kadastrale grens minder in aanmerking.
Gebruikers van de provinciale kaart zijn oa. de eigen diensten weg- en groenbeheer. Naast de topografie, die in een strook langs de weg wordt ingemeten, zijn het vooral de weg- en groenobjecten die van belang zijn voor deze beheerkaarten.
Soms wordt er meer groen beheert dat eigendom is van de provincie – denk aan een bermsloot die in z’n geheel gemaaid wordt, terwijl de kadastrale grens door het hart van de sloot loopt.
Momenteel worden veel kruisingen vervangen door rotondes, daarvoor is meer ruimte nodig en zullen stukken grond van gemeenten of particulieren moeten worden aangekocht. Het vaststellen en inmeten van de nieuwe kadastrale situatie gebeurt vaak later en daardoor is de kadastrale grens niet ( meer ) actueel.
Binnen ons project hebben we nu gekozen voor een pragmatische aanpak: we gebruiken de buitenste topografische lijnen in de stroken kaarten om de vlakken te vormen. In sommige gevallen moeten we hulp-lijnen toevoegen om de vlakken te sluiten. Als de bronhoudergrens bepaald is, zal blijken welke vlakken moeten worden opgeknipt.
De huidige beheergrens en kadastrale grens laten we momenteel volledig buiten beschouwing. Ook gebouwen die buiten het beheergebied vallen en gedeeltelijk op de kaart staan ter referentie, worden niet meegenomen evenals aanzetten van rasters, sloten en zijwegen die gedeeltelijk op de kaart staan, maar buiten het beheergebied vallen.
Met deze aanpak kunnen de kaarten object gericht worden gemaakt en kan de geometrie van de weg- en groenvlakken gekoppeld worden aan de beheer-data.
Ondertussen wordt overleg gevoerd met Stichting GBKN, gemeenten, waterschappen, Rijkswaterstaat en het Ministerie van VROM over de bronhoudergrens.
Frist suggestion is the cadastral border. This is also an authentic registration and a good solution for two municiplalities. I’m involved with a project at one of the provinces and they “slice” through municipalities with their provincial roads, that makes the cadastral border less useful.
Users of the provincial map are among others the departments of road- and greenmanagement. Besides surveying the topography, that is situated in a corridor along the road, the road- and greenobjects are important for these maintenance maps.
Sometimes there is more green managed than is owned by the province – imagine a ditch that is mown completely, while the cadastral borderline is in the center of the ditch.
Currently many road crossings are tranferred into roundabouts, and therefore the province needs to buy pieces of land from municipalities or private owners. The new cadastral situation will take some time to become established and therefore the cadastral border isn’t up-to-date.
In our project we’ve taken a pragmatic approach: we use the outside topographic lines in the corridor maps to build the polygons. In some cases we have to add supporting-lines to close the polygons. If the BGT border polygon has been defined than we will know which polygons needs to be splitted.
The current maintenance and cadastral borders are left out of the proces for now. Also buildings, fences, roadlines that a partly on the map, but outside the provincial maintenance area are left out of polygon creation.
With this approach we can create the object oriented map and use the geometry of road- and greenobjects to connect to maintenance-data.
In the meantime still discussing with the GBKN Foundation, municipalities, waterboards, National Road Administration and the Ministry of Housing, Spatial Planning and the Environment about the BGT border polygon.
In de huidige systeem configuratie worden AutoCAD tekeningen ge-exporteerd naar diverse SDF-files en Access-tabellen. De teksten en punt-objecten worden eerst ge-explodeerd om vervolgens als lijnstukjes te worden ge-exporteerd. Er waren dus nooit echte punt-symbolen gedefinieerd tbv. MapGuide.
