Naar een loepzuivere digitale kaart (VK 2/2013)

zondag 17 maart 2013
timer 16 min

Een samenvatting van dit artikel is in VK 2/2013 gepubliceerd onder de titel 'Naar een loepzuivere digitale kaart'

Hoe meer input met geo-informatie, hoe meer bijvoorbeeld in 3D kan worden gevisualiseerd [Fotobron: Rheinmetall Defence Electronics]

 


Auteurs:

Guus Tamminga, Grontmij
Linda van den Brink, Geonovum
Jantien Stoter, TU Delft, Kadaster en Geonovum
Hans van Lint, TU Delft

Met de wet Basisregistratie Grootschalige Topografie (BGT) wordt de komende jaren een traject ingezet waar vrijwel alle overheidsorganisatie mee te maken krijgen. Met de wet wordt een belangrijke stap gezet in de afstemming van de verzameling én het beheer van geo-informatie. En daarmee leidt de BGT tot een gedetailleerde digitale kaart van Nederland met informatie over uiteenlopende zaken als gebouwen, wegen,  groenvoorzieningen en waterwegen. In dit artikel richten we ons op de mogelijkheden en uitdagingen die de BGT biedt voor vraagstukken op het gebied van verkeer en vervoer.

Goede informatie is essentieel bij het analyseren van verkeerkundige vraagstukken op terreinen als verkeerveiligheid, bereikbaarheid en leefbaarheid. Zo vormt gedetailleerde informatie over verkeersongelukken bijvoorbeeld de basis voor het traceren van verkeersonveilige locaties en het analyseren van de oorzaken van die onveiligheid. Bij het opstellen van verkeersprognoses worden verkeersmodellen gebruikt, waarvoor eveneens veel data nodig zijn. Ook uitspraken over de drukte op het wegennet (file-informatie) en trends daarin (nemen de files af?) worden gebaseerd op metingen van het verkeer.

Geo-informatiestructuur

Het verzamelen en beheren van deze gegevens is geen sinecure. Het gaat om een grote hoeveelheid informatie die verzameld wordt vanuit verschillende bronnen. Typerend voor deze informatie is dat het plaatsgebonden is. Dit wordt geduid met de term geografische informatie: alle informatie die een ruimtelijk component heeft, dat wil zeggen een verwijzing naar een plek op de aarde, kan worden beschouwd als geo-informatie. Met een Geografisch Informatie Systeem (GIS) wordt deze informatie beheerd en kunnen allerlei ruimtelijke analyses worden gedaan. In Nederland wordt gewerkt aan een geo-informatiestructuur (GII), met de bedoeling de aanwezige geo-informatie zo laagdrempelig mogelijk te ontsluiten. Dit vormt een basisvoorwaarde voor een goede uitwisseling van data.

Het belang van afstemming

Een van doelen bij de standaardisering van databeheer is het bevorderen van hergebruik van data, om dubbel werk te voorkomen. Hoewel de wens om data op een uniforme en gestandaardiseerde wijze te beheren al veel langer bestaat, is er in de huidige praktijk nog lang niet altijd sprake van. Dat geldt ook voor de verkeerswereld. Bijvoorbeeld bij de bouw en toepassing van verkeersmodellen, waar datavergaring een substantieel deel van het werk omvat, blijkt het proces van dataverzameling en databeheer nog lang niet optimaal [1].

Topografie van netwerken komt niet overeen

Het volgende voorbeeld geeft aan waar winst valt te behalen. Bij de bouw van een microsimulatiemodel is als input veel geo-gerelateerde informatie nodig, onder meer voor een goede en gedetailleerde beschrijving van de infrastructuur. Aan de basis daarvan staat de topografie van het wegennet. Digitale informatie van wegen is te vinden in meerdere bronnen, zoals het Nationaal Wegenbestand (NWB), een digitale topografische kaart van het Kadaster, Open Street Map of een bestaand verkeersmodel waarin al een wegennet is gedigitaliseerd. Het probleem is dat de topografie van deze netwerken vaak niet overeenkomt, waardoor uitwisseling van data tussen deze netwerken niet direct mogelijk is. Het gegeven dat er meerdere keuzemogelijkheden zijn, leidt daarmee al tot potentiele afstemmingsproblemen: als gemeente A een andere databron kiest dan buurgemeente B, en de overkoepelende regio een derde bron gebruikt, bemoeilijkt dit al snel de uitwisseling of samenvoeging van gegevens. Vervolgens moeten er voor het simulatiemodel extra data worden verzameld. In het NWB en vergelijkbare databronnen ontbreken gedetailleerde gegevens over de inrichting van de weg, zoals het aantal rijstroken en de geometrie van de kruispunten (de lengte en de richting van de opstelstroken, maar ook de eventuele voorrangsregels of de locatie van de stopstreep).

Ad hoc-toevoegingen

In de huidige praktijk worden deze, gedetailleerde gegevens meestal ad hoc verzameld en toegevoegd aan het netwerk van het verkeersmodel. Dit veroorzaakt een tweede probleem. De modelsoftware (bijvoorbeeld Vissim, Paramics of Aimsun) converteert de primaire netwerken naar een pakket-specifieke datastructuur waarmee in feite een nieuwe gegevensdrager wordt gecreëerd. Dit maakt het lastig om de gegevens weer terug te sluizen naar een gangbaar dataformaat en beperkt daarmee de uitwisseling en het hergebruik van de toegevoegde informatie in sterke mate. Het is dan ook geen uitzondering dat voor bepaalde gebieden de netwerken van een model meerdere malen opnieuw worden gebouwd. Twee oorzaken worden gesignaleerd:

  • Er bestaan geen generieke afspraken over ruimtelijke gegevens zoals gebruikt in verkeersmodellen en daarmee is er geen uniforme geografische datadrager voor deze informatie;
  • Verkeersmodellen gebruiken hun eigen dataformat, wat data-uitwisseling sterk bemoeilijkt.

BGT: katalysator
De invoering van de Wet Basisregistratie Grootschalige Topografie biedt een prima gelegenheid om de basisgegevens goed op orde te krijgen door het creëren van een uniforme datadrager. Doel is een topografisch objectenbestand te creëren dat voor heel Nederland uniform is als het gaat om inhoud en kwaliteit. De BGT is bedoeld voor gebruik op een schaal van 1:500 tot 1:5000. Eind 2015 moet de BGT gevuld zijn en beschikbaar voor gebruik (bron: http://www.geonovum.nl/dossiers/bgt ).

De invoering van de BGT steunt op twee  pijlers:

  • Het informatiemodel geografie (IMGeo) waarin is vastgelegd hoe de topografische objecten worden vastgelegd;
  • Het Samenwerkingsverband van Bronhouders, dat is bedoeld om bronhouders (gemeenten, provincies, waterschappen, Rijkswaterstaat, ProRail, ministeries van EZ en defensie) te ondersteunen bij de overgang naar de BGT. Een gezamenlijke aanpak is essentieel, zowel bij de afstemming van verschillende bronhouders binnen een regio, maar ook als het gaat om de afstemming tussen de verschillende vakgebieden.

Feitelijke invulling

De feitelijke invulling van de BGT vergt een initiële inspanning waarbij draagvlak en samenwerking essentieel zijn. De data-inwinning gebeurt in regioverband, waarbij de verschillende instanties afspreken wat en hoe er geleverd wordt. De regio’s leveren deze samengevoegde bestanden vervolgens aan de “Landelijke Voorziening” , waardoor er een landelijke dekking wordt bereikt. De resulterende data zal als Open data beschikbaar komen.

Met deze initiële investering krijgen overheden en andere instellingen een kapstok om hun informatie aan op te hangen. Hier staan diverse besparingen tegenover: minder fouten en kosten voor data-inwinning en zeker ook minder afstemmingsproblemen.

Geo-standaarden belegd bij Geonovum

Voor het verwezenlijken van een duurzame geo-informatiestructuur (GII) zijn standaarden onontbeerlijk: Zij zorgen ervoor dat het wiel niet voor een tweede keer wordt uitgevonden en dat er bij uitwisseling overeenstemming is tussen beide partijen over het formaat en de betekenis van de uitgewisselde gegevens. Belangrijk daarbij is dat het open standaarden betreft. Een open standaard is voor iedereen toegankelijk en toekomstvast omdat toegang tot de standaard en beheer van de standaard bij een non-profit organisatie zijn belegd.

Het ontwikkelen en beheer van geo-standaarden is in Nederland ondergebracht bij Geonovum. Deze stichting zorgt ook voor de afstemming met internationale geo-standaarden. Voor Nederland zijn de ISO/TC 211, Open Geospatial Consortium (OGC) en CEN/TC 287 van belang. Deze drie internationale standaardisatie-organisaties maken technische geo-standaarden die Nederland semantisch invult.

Europese geo-informatie-infrastructuur

Geonovum neemt deel aan deze organisaties en dus aan de ontwikkeling van de internationale standaarden; mede op basis van de Europese kaderrichtlijn INSPIRE die sinds 15 mei 2007 van kracht is en leidt tot een Europese geo-informatie-infrastructuur. De invoering van INSPIRE is met een implementatiewet in de Nederlandse wet verankerd. In een notendop verplicht INSPIRE de Europese lidstaten geo-informatie over 34 thema's te voorzien van metadata, te harmoniseren en beschikbaar te stellen via services volgens leveringsvoorwaarden die het gebruik niet onnodig belemmeren. De invoeringsregels die

worden opgesteld voor standaarden zijn metagegevens, data specificaties en netwerkdiensten. De INSPIRE technical guidelines, ISO of OGC standaarden die door INSPIRE zijn voorgeschreven, of Nederlandse profielen die compliant zij, worden met het INSPIRE symbool gekenmerkt.

 

BGT vormt kern van IMGeo
Nationale publieke sectoren die te maken hebben met de GII zijn onder meer de ministeries van Infrastructuur en Milieu en Economie en Landbouw en Innovatie, waarbij de beheerstaken worden uitgevoerd door het Kadaster en de Geologische Dienst Nederland (TNO). Voor allerlei domeinen zijn al semantische standaarden ontwikkeld en in gebruik. Denk bijvoorbeeld aan IMRO (ruimtelijke ordening), IMKL (kabels en leidingen), IMKAD (kadaster), IMWA (water), en IMGeo (grootschalige topografie) (bron: www.geonovum.nl).  

Het informatiemodel Geografie (IMGeo) hangt nauw samen met de nieuwe Basisregistratie Grootschalige Topografie. De BGT vormt de kern (verplichte deel) van IMGeo en bevat onder andere wegen, water, terrein, bruggen, tunnels, panden en andere gebouwde objecten. IMGeo kent daarnaast nog een verdiepingsslag met een rijkdom aan optionele objecten en informatie. Denk hierbij bijvoorbeeld aan lantaarnpalen, afvalbakken, enzovoort.

Bronhouders

De standaarden voor IMGeo/de BGT zijn onlangs vastgesteld en op dit moment wordt de BGT ingericht en gevuld met gegevens door de bronhouders. IMGeo is een uitbreiding van de internationale standaard CityGML, een OGC-standaard voor het in 3D vastleggen van allerlei objecten die je in en om een stad tegenkomt, zoals wegen, gebouwen, water, vegetatie en terrein. Er is een grote semantische overlap met IMGeo, en daarom is de wens gerealiseerd om in IMGeo ook 3D-informatie op te kunnen nemen, door aan te sluiten op CityGML. IMGeo is dan ook als extensie op CityGML gemodelleerd.

De OGC-standaard CityGML [2] is een informatiemodel voor de 3D-representatie van ruimtelijke objecten in een stedelijke omgeving, met momenteel uitbreidingen voor andere toepassingen. CityGML maakt op geometrisch èn op semantisch niveau een onderscheid tussen thematische gebieden (zoals gebouwen, vegetatie, water, terrein en kleinere objecten op straat), maar doet dit ook – per object - op verschillende detailniveaus. Het hoogteniveau op maaiveld wordt weergegeven in Level of Detail 0 (LOD0): gebouwen en wegen worden weergegeven in een 2D-beschrijving (‘vlakken en lijnen’). Een gebouwobject (en andere volumeobjecten zoals kunstwerken) kan vervolgens op verschillende detailniveaus worden opgetrokken in 3D, variërend van een eenvoudig blokmodel (LOD1), met dakvormen (LOD2), met ramen, deuren en andere exterieurkenmerken (LOD3), tot een volledig uitgewerkt interieurmodel (LOD4) al dan niet voorzien van textuurinformatie (‘appearance’), zie figuur 1 hieronder.

 

Figuur 1: Verschillende Levels of Detail (LOD) zoals gedefinieerd in CityGML (CityGML, 2012)


Transport in CityGML heeft representaties in alle vijf levels of detail (zie figuur 2 verderop). In het laagste level of detail (LOD0) worden in de klasse ‘TransportationComplex’ lijnobjecten opgenomen die een netwerk vormen. Dit kan bijvoorbeeld gebruikt worden voor macroscopische toedelingsmodellen en routeberekening voor voertuigen en kan ook worden gebruikt voor het berekenen van bus-, trein- of voetgangersroutes. In LOD1 worden transportobjecten opgenomen als vlakobjecten die te onderscheiden zijn van andere vlakobjecten zoals water en terrein. Hierdoor wordt duidelijk wat het voor verkeer beschikbare oppervlak is. Er kan in dit level of detail een semantisch onderscheid gemaakt worden tussen Road (weg), Track (pad), Railway (spoor) en Square (plein, kruispunt). In LOD2-4 wordt de TransportationComplex nader opgedeeld in zogeheten Traffic Area en Auxiliary Traffic Area-klassen. Deze klassen geven meer specifiek aan wat de verschillende onderdelen van de weg voor functie en fysiek voorkomen hebben. De traffic area is dat deel van de weg dat wordt gebruikt door verkeer, terwijl auxiliary traffic area die delen zijn die wel bij de weg horen, maar doorgaans niet door het verkeer gebruikt worden, zoals bermen of vluchtheuvels. De CityGML standaard gaat op dit moment niet verder in het definiëren van LOD 3 en 4. 

 

Catalogi en codelijsten

Alle transportklassen in CityGML hebben de attributen class, function en usage. Het attribuut ‘class’ beschrijft de hoofdclassificatie van het object, ‘function’ beschrijft de functie/het doel, en  ‘usage’ geeft aan welke transportmiddelen het mogen gebruiken (bijvoorbeeld auto, bus of voetgangers). Daarnaast kan bij traffic area en auxiliary traffic area worden aangegeven wat voor verhardingssoort er aanwezig is. Wat er verder mag worden ingevuld in deze attributen kan worden vastgelegd in catalogi of codelijsten. CityGML geeft voorbeeld-catalogi, maar deze zijn niet normatief en kunnen worden vervangen door termen die bijvoorbeeld op landelijk niveau worden gehanteerd. In IMGeo is dit voor Nederland gedaan.

Hoewel CityGML LOD0 een netwerkmodel is, zijn er verder geen functionele aspecten van transportation-netwerkmodellen gemodelleerd. Zo kan men in CityGML geen snelheidslimieten kwijt. Dit is bewust zo gedaan: voor dit soort gegevens bestaat al de ISO standaard GDF en wordt voorkomen dat CityGML als vervanging van deze standaard optreedt. CityGML kan dus worden gezien als complementair aan deze standaard. Het is mogelijk om vanuit CityGML koppelingen te leggen naar GDF-data voor de benodigde gegevens, of de gegevens alsnog in CityGML op te nemen in generieke attributen.

CityGML kan voor allerlei analyses gebruikt worden. Zo kan een gemodelleerd terrein met gebouwen (en eventueel andere objecten zoals bomen) in CityGML in 3D, berekeningen doen die voorspellen hoe de wind zich rond de gebouwen zal gedragen. Evenals geluidsanalyses die rekening houden met het materiaal van het wegdek, met de hoeveelheid en snelheid van het verkeer, maar ook met de mate van reflectie door aanwezige gebouwen. Ook is zo het effect te simuleren van een geluidsscherm. Voor het doen van zulke geluidsanalyses is een extensie op CityGML bedacht die is beschreven in een annex van de standaard. Deze extensie voegt een groot aantal attributen toe aan de klassen Road (bijvoorbeeld snelheidslimieten), Railway (bijvoorbeeld het materiaal), Building (bijvoorbeeld . mate van reflectie van het materiaal, aantal inwoners) en voegt een klasse Train en NoiseCityFurnitureSegment toe die geluidsschermen modelleert.

Breng en haal-plicht

De invoering van de BGT biedt kansen en uitdagingen om meerwaarde te creëren. De introductie van een gemeenschappelijke standaard voor alle Nederlandse overheden schept de mogelijkheid om tot een landelijk dekkend digitaal wegennetwerk te komen, die als centrale datadrager gebruikt kan worden voor een veelheid aan weg-gerelateerde informatie en objecten. Met het IMGeo-informatiemodel wordt ervoor gezorgd dat door iedereen dezelfde taal wordt gesproken. De volgende stap in het proces is dat er afspraken worden gemaakt om ook de verkeersgerelateerde geo-informatie volgens duidelijke regels op te slaan en te beheren. Dat zou  bijvoorbeeld kunnen door een ‘breng en haal’-plicht te introduceren.

De ‘brengplicht’ impliceert dat nieuw verzamelde informatie wordt opgeslagen en beheerd conform de IMGeo-richtlijnen (of aanvullingen daarop). Gaan we terug naar het eerder in dit artikel aangehaalde voorbeeld van de verkeersmodellen, dan blijkt veel infrastructuur-gerelateerde informatie opgeslagen te worden in niet gestandaardiseerde data formats, waardoor uitwisseling van deze gegevens uitermate moeizaam is. Voor verkeersmodellen is het daarom wenselijk om tot een pakket-onafhankelijke data- architectuur te komen die aansluit op IMGeo en de gewenste data-uitwisseling wel mogelijk maakt. Geconstateerd is al dat een groot deel van de infrastructuurdata en -objecten in de vigerende verkeersmodellen direct kan worden vastgelegd in CityGML [3], en dus in IMGeo. Bovendien is het mogelijk het domein transport van CityGML met extra objecten en attributen uit te breiden en deze uitbreidingen ook weer te harmoniseren via nationale en internationale afspraken. Voor de in Nederland gebruikte verkeersmodelpakketten vergt dit de creatie van een import- en exportmodule naar de pakket-onafhankelijke data-architectuur. Deze eenmalige inspanning zal ruimschoots worden gecompenseerd door de winst die wordt behaald met de uitwisselbaarheid van de data.

De ‘haal’-plicht heeft als doel zoveel mogelijk gebruik te maken van dezelfde basisinformatie. Het voordeel daarvan is dat verschillende toepassingen gebruikmaken van goed op elkaar afgestemde data en dezelfde uitgangspunten. Hiermee worden discussies over de uitgangspunten op dit punt voorkomen. Bijkomend voordeel is dat wanneer er fouten in de data worden geconstateerd, de correcties alleen in de BGT hoeven te worden doorgevoerd.

Implementatie

De afgelopen jaren zijn er al de nodige initiatieven geweest om te komen tot afstemming van basisdata, ook voor verkeersmodellen. Recente voorbeelden zijn de provinciebrede modelaanpak door de provincies Utrecht en Noord-Brabant, waarbij veel aandacht uitgaat naar het afstemmen en beheren van de invoerdata en de afstemming van de modellen van Rijkswaterstaat (NRM/LMS). Met de BGT komt er een platform dat uitermate geschikt is om een flinke stap vooruit te komen. Voorwaarde daarvoor is dat er afspraken worden gemaakt over wijze waarop data worden opgeslagen en volgens welke definities dat gebeurt. Daarbij kan nuttig gebruik worden gemaakt van de optie die CityGML en IMGeo biedt om verschillende detailniveaus te onderscheiden. De mate van detail die een wegbeheerder wenselijk acht, kan daarbij leidend zijn. De keuze kan variëren van een wegennetwerk met alleen lijnen en knopen (LOD0) tot een beschrijving waarbij de geometrie conform de situatie op straat (LOD2) wordt gedigitaliseerd. Wordt er bijvoorbeeld een gebied in een microsimulatiemodel opgenomen, dan kan de geometrie op LOD2 worden gehanteerd. In plaats van lijnen en knopen worden dan vlakken van de rijbanen gedefinieerd, met bijvoorbeeld een omschrijving van de belijning, de locatie van de stopstrepen en de detectoren bij de verkeerslichten.

‘Open traffic’

Een volledig overzicht van de wijze waarop alle data objecten worden opgeslagen is nog niet voorhanden. Het is dan ook zaak om hier op korte termijn een verdere uitwerking aan te geven. Met het project ‘Open Traffic’ wordt momenteel door de TU Delft in samenwerking met Grontmij uitgewerkt hoe de infrastructurele objecten die onderdeel zijn van een verkeersmodel, het beste kunnen worden vastgelegd. Daarmee zijn we er echter nog niet. Er zijn nog veel meer gegevens die gebruikt worden in verkeergerelateerde studies, zoals ongevalgegevens en meetgegevens (intensiteiten, snelheden). Met de start van de BGT is er momentum om ook hier afstemming te zoeken, zodat ook deze informatie in de nabije toekomst op een eenduidige manier kan worden vastgelegd.

Conclusie

Het creëren van een digitale kaart van Nederland, die door alle overheden als basis wordt gebruikt voor het vastleggen en beheren van geografische informatie, biedt goede kansen voor een efficiënter gebruik van verkeersgegevens. Daarmee kan worden voorkomen dat gegevens worden gekoppeld aan meerdere digitale datadragers waarvan de topografie vaak niet exact overeenkomt. Met een uniforme basis hoeven de gegevens maar eenmalig  te worden vastgelegd. Eventuele fouten in de data hoeven dan ook maar eenmalig te worden gecorrigeerd. De mogelijkheid om meerdere ‘levels of detail’ te onderscheiden biedt de gelegenheid om te variëren in de mate van detail waarmee informatie wordt vastgelegd. Daar waar nodig kan gedetailleerde informatie worden opgeslagen, maar waar dat niet nodig is kan het globaler. De Basisregistratie Grootschalige Topografie biedt gelegenheid om ook op het terrein van verkeer en vervoer afspraken te maken over het vastleggen van allerlei data.Dat zal niet vanzelf gebeuren; er zijn convenanten nodig  waarin wordt vastgelegd dat data op een eenduidige manier wordt opgeslagen. Dit vergt in eerste instantie extra kosten, bijvoorbeeld  om een goede data-architectuur te ontwikkelen en ervoor te zorgen dat verschillende typen verkeersmodellen hun geografische data koppelen aan de nieuwe digitale kaart van Nederland. Daar staan wel diverse kostenbesparingen tegenover:

  • minder kosten voor databeheer;
  • minder data inwinnen;
  • meer flexibiliteit bij data-uitwisseling;
  • minder data synchroniseren;
  • minder afstemmingsproblemen.

Literatuur

1. Miska, M., Nantes, A., Torday, H. Jin & E. Chung, ‘Model-free networks as basis for a transport data hub’, Congress Proceedings, TRB 2013

2. CityGML, ‘OGC City Geography Markup Language (CityGML) Encoding Standard’,  Open Geospatial Consortium, 2012

3. Tamminga, G., L. van den Brink, H. Van Lint, J. Stoter, S.P. Hoogendoorn
‘Towards GIS compliant data structures for traffic and transportation models’, Congress Proceedings, TRB 2013

 
Auteur: Joske van Lith

verkeerskunde artikel
mail_outline

Aanmelden voor de nieuwsbrief

Reactie plaatsen

Beperkte HTML

  • Toegelaten HTML-tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Regels en alinea's worden automatisch gesplitst.
  • Web- en e-mailadressen worden automatisch naar links omgezet.
  • Lazy-loading is enabled for both <img> and <iframe> tags. If you want certain elements skip lazy-loading, add no-b-lazy class name.