BIM verzamelen, verbinden en visualiseren voor ... · Er is een script ontwikkeld om de informatie...
47
Geo- en Vastgoedinformatie en Advies BIM verzamelen, verbinden en visualiseren voor vergunningverlening Eindrapport Versie 1.0 Auteur(s) Danny Greefhorst Frans Knibbe Anouk Huisman
Transcript of BIM verzamelen, verbinden en visualiseren voor ... · Er is een script ontwikkeld om de informatie...
Geo- en Vastgoedinformatie en Advies
BIM verzamelen, verbinden en visualiseren voor vergunningverlening
Eindrapport
Versie
1.0
Auteur(s)
Danny Greefhorst
Frans Knibbe
Anouk Huisman
Versiehistorie
Versie Datum Auteur Opmerking
0.1 20 augustus 2018 Danny Greefhorst Initiële versie
0.2 24 september 2018 Danny Greefhorst Tekstuele verrijking
0.3 26 september 2018 Danny Greefhorst Aanvullingen door Anouk Huisman
0.4 1 oktober 2018 Danny Greefhorst Resultaten technisch onderzoek toegevoegd
0.5 4 oktober 2018 Danny Greefhorst Reviewcommentaar verwerkt
0.6 13 oktober 2018 Frans Knibbe Aanvullingen technisch onderzoek
1.0 19 oktober 2018 Danny Greefhorst Reviewcommentaar werkgroep en H. Corstens verwerkt
Geo- en Vastgoedinformatie en Advies
BIM verzamelen, verbinden en visualiseren voor
vergunningverlening
Eindrapport
Status
Definitief
2
Inhoudsopgave
1 .......... Inleiding ............................................................................................................................................... 4
1.1 ....... Aanleiding ............................................................................................................................................. 4
1.2 ....... Opdrachtbeschrijving ............................................................................................................................ 4
1.3 ....... Documentstructuur ................................................................................................................................ 5
2 .......... Context en aanpak .............................................................................................................................. 6
2.1 ....... Beoordelen en verwerken van informatie over bouwwerken ................................................................. 6
2.2 ....... Aanpak .................................................................................................................................................. 8
2.3 ....... Eerder onderzoek .................................................................................................................................. 8
3 .......... Bestaande en voorgestelde werkwijzen .......................................................................................... 10
3.1 ....... Gemeente Den Haag .......................................................................................................................... 10
3.2 ....... Gemeente Rotterdam .......................................................................................................................... 11
3.3 ....... Studioschaeffer ................................................................................................................................... 12
3.4 ....... Dura Vermeer ...................................................................................................................................... 13
3.5 ....... TNO..................................................................................................................................................... 14
4 .......... Analyse .............................................................................................................................................. 16
4.1 ....... Beoordeling ......................................................................................................................................... 16
4.1.1 .... BBL ..................................................................................................................................................... 16
4.1.2 .... RO-toets .............................................................................................................................................. 19
4.2 ....... Verwerking .......................................................................................................................................... 20
4.2.1 .... BAG..................................................................................................................................................... 21
4.2.2 .... WOZ .................................................................................................................................................... 22
4.2.3 .... BGT ..................................................................................................................................................... 23
4.2.4 .... Vloeroppervlakte ................................................................................................................................. 24
4.2.5 .... Gebruiksfuncties, gebruiksdoelen en bestemmingshoofdgroepen. ..................................................... 25
4.2.6 .... Ruimtes ............................................................................................................................................... 26
5 .......... Technisch onderzoek........................................................................................................................ 28
5.1 ....... Onderzoek ........................................................................................................................................... 28
5.2 ....... Linked Data ......................................................................................................................................... 28
5.3 ....... Georeferentie ...................................................................................................................................... 31
5.4 ....... Het toevoegen van extra gegevens aan een IFC-bestand .................................................................. 33
5.5 ....... Extractie van gegevens uit een IFC-bestand ....................................................................................... 36
5.6 ....... Viewer ................................................................................................................................................. 37
6 .......... Conclusies en aanbevelingen .......................................................................................................... 39
6.1 ....... Antwoorden op kernvragen ................................................................................................................. 39
6.2 ....... Uitdagingen en oplossingsrichtingen ................................................................................................... 40
3
6.3 ....... Aanbevelingen algemeen – brede doelgroep ...................................................................................... 41
6.4 ....... Aanbevelingen gemeenten .................................................................................................................. 42
6.5 ....... Aanbevelingen bouwsector ................................................................................................................. 43
Bijlage 1: Bronnen .......................................................................................................................................... 45
Bijlage 2: Deelnemerlijst ................................................................................................................................ 46
4
1 Inleiding
1.1 Aanleiding
Het Kadaster ondersteunt de bouwsector in digitalisering, onder meer in de context van de Omgevingswet.
Het streven is om de stappen in het bouwproces en de integratie met andere processen zoveel mogelijk
digitaal te laten verlopen. Een centraal onderdeel daarin is een naadloze aansluiting van geo-informatie en
informatie over bouwwerken. Een dergelijke ketenoptimalisatie kan zowel de bouwsector als de overheid veel
geld besparen.
Op dit moment vinden er allerlei handmatige stappen plaats in het proces om te komen tot een digitaal
bestand van een bouwwerk (ook wel: BIM, van Building Information Model) en de verlening van een
vergunning voor de bouw of aanpassing daarvan. Er wordt informatie in allerlei vormen door allerlei partijen
aangeleverd door de initiatiefnemer en/of de adviesbureaus die deze inzet, zoals architectenbureaus en
ingenieursbureaus. Er bestaat een standaard voor het uitwisselen van informatie over gebouwen: de Industry
Foundation Classes (IFC). Met die standaard is het mogelijk een BIM op te slaan als een tekstbestand
waarvan het formaat open is. Gemeenten accepteren echter in veel gevallen een dergelijk bestand niet, of
gebruiken het niet als bron voor de vergunningaanvraag. Het rijke, vaak driedimensionale BIM wordt
platgeslagen tot een verzameling van bouwtekeningen. Deze tekeningen worden vervolgens door
verschillende lokketten binnen de gemeente handmatig beoordeeld door mensen, onder meer op het voldoen
aan het bouwbesluit alsook aan gemeentespecifieke regelgeving. Naast de tekeningen moeten ze daarbij een
grote verzameling van anderssoortige documenten (bijlagen) beoordelen, waarbij het niet evident is welke
informatie in welk document te vinden is. Daarnaast is het precieze gebruik van IFC niet verregaand
gestandaardiseerd, waardoor het lastig op een standaard manier te interpreteren is.
Er zijn dus kansen om het proces van vergunningverlening te optimaliseren. In het bijzonder kan BIM worden
ingezet om de beoordeling en verwerking van bouwwerk informatie verregaand te automatiseren. Hierdoor
kan het proces vele male efficiënter worden uitgevoerd en kunnen allerlei faalkosten worden voorkomen.
1.2 Opdrachtbeschrijving
Dit rapport bevat het resultaat van een pilot m.b.t. BIM in de context van vergunningverlening. De opdracht
was om te onderzoeken of een specifieke schakel in de geschetste keten kan worden geoptimaliseerd: het
verzamelen van informatie uit een IFC-bestand, het verbinden van deze informatie aan andere informatie en
het visueel inzichtelijk maken van deze samenhang. Hiervoor hebben onder meer werksessies met
vertegenwoordigers van gemeenten (Den Haag, Rotterdam, Almere), de bouwsector (Dura Vermeer,
Studioschaeffer, RoyalHaskoning, TNO, Interconcept, BIM loket) en de geo-sector (Geonovum, TU Delft en
het Kadaster) plaatsgevonden. Het resultaat bestaat voor een belangrijk deel uit een demonstrator die dit
inzichtelijk maakt.
De doelgroep van dit document zijn medewerkers van gemeenten, architectenbureaus, ingenieursbureaus of
andere partijen in de keten die betrokken zijn bij het opstellen van IFC-bestanden of het beoordelen of
verwerken ervan.
5
Kernvragen voor de pilot waren:
• Is informatie die nodig is om een aanvraag te beoordelen (met name voldoen aan Besluit Bouwwerken
Leefomgeving/Bouwbesluit) aanwezig in een IFC-bestand?
• Is het mogelijk om op geautomatiseerde wijze de relevante delen van de geometrie van een bouwwerk te
extraheren uit een IFC-bestand? Wat zijn de randvoorwaarden?
• Is informatie die nodig is om de informatie over een bouwwerk te verwerken in relevante administraties
(zoals BAG) aanwezig in een IFC-bestand?
1.3 Documentstructuur
• Hoofdstuk 2 geeft meer context bij de pilot en beschrijft de gevolgde aanpak
• Hoofdstuk 3 geeft een overzicht van bestaande en voorgestelde werkwijzen van deelnemende partijen
• Hoofdstuk 4 geeft inzicht in de informatie-analyse die heeft plaatsgevonden
• Hoofdstuk 5 beschrijft het resultaat van de ontwikkeling van de technische demonstrator
• Hoofdstuk 6 beschrijft de conclusies en aanbevelingen van het onderzoek
Bijlage 1 geeft een overzicht van de gebruikte bronnen. Bijlage 2 geeft een overzicht van de deelnemers aan
de pilot.
6
2 Context en aanpak
Dit hoofdstuk geeft meer context bij de pilot en beschrijft de gevolgde aanpak. Het geeft ook een beeld van
gerelateerd onderzoek.
2.1 Beoordelen en verwerken van informatie over bouwwerken
Het Besluit Bouwwerken Leefomgeving (BBL) is een AMvB in de context van de Omgevingswet en zal het
Bouwbesluit vervangen. Het BBL beschrijft belangrijke regelgeving waaraan bouwwerken dienen te voldoen.
Toetsing aan dit BBL is dan ook een belangrijk onderdeel van het beoordeling van de vergunningaanvraag
voor een bouwwerk. Op dit moment ligt de verantwoordelijkheid voor toetsing aan het Bouwbesluit nog bij de
gemeente. De Wet kwaliteitsborging voor het bouwen (Wkb) zal ertoe leiden dat deze rol verschuift naar
onafhankelijke kwaliteitsborgers (als deze wordt goedgekeurd door de eerste kamer). Toetsing aan het BBL
zal ook op dat moment nog belangrijk blijven, op meerdere momenten van het initiatief. Zowel initiatiefnemer,
aannemer, gemeente als kwaliteitsborger zullen zo snel mogelijk zicht willen op de mate waarin een
voorgesteld bouwwerk voldoet aan de regelgeving. De kans is wel groot dat er na de implementatie van WBK
op het moment van vergunningaanvraag nog minder gedetailleerde bouwinformatie aanwezig hoeft te zijn en
volledige toetsing op BBL verschuift naar later in het proces.
Naast een toetsing op Bouwbesluit/BBL vinden er bij de beoordeling van een vergunningaanvraag ook
anderssoortige toetsen plaats door de gemeente. Een belangrijke toets is de zogenaamde RO-toets die
beoordeelt of een voorgesteld bouwwerk past vanuit het perspectief van Ruimtelijke Ordening. Het
belangrijkste onderdeel daarvan is het bepalen of het bouwwerk past bij de van toepassing zijnde
bestemmingsplannen. Op dit moment zijn ruimtelijke plannen beschikbaar in de landelijke voorziening voor
ruimtelijke plannen. Na de implementatie van de Omgevingswet zullen deze worden omgevormd tot
omgevingsplannen en beschikbaar worden gesteld via het Digitaal Stelsel Omgevingswet. Naast BBL en RO
toetsen gemeenten ook op ondermeer welstand, milieu en Algemene Plaatselijke Verordeningen.
Figuur 1 Gewenste situatie
initiatiefnemer
architectenbureau/
ingenieursbureau
gemeente
BAG
BGT
WOZ
BBL
BIM/IFC
bestand
Aanvraag
RO-toets
BBL-toets
Verwerking in
BAG, BGT en WOZ
Omgevingsplan
onafhankelijke
kwaliteitsborger
7
Nadat beoordeling van bouwinformatie heeft plaatsgevonden zal de informatie ook moeten worden verwerkt in
de verschillende gemeentelijke administraties. Dit betreft met name de Basisadministratie Adressen en
Gebouwen (BAG), de Basisadministratie Grootschalige Topografie (BGT) en de Basisadministratie
Waardering Onroerende Zaken (WOZ). Daarnaast is de informatie ook relevant voor onder meer de
brandweer. Een deel van deze informatie is geo-informatie en betreft specifieke contouren van het
voorgestelde bouwwerk. Voor de BAG is dat het bovenaanzicht en voor BGT is dat de voetafdruk op
maaiveldniveau zijn. Dit soort informatie wordt op dit moment vooral op basis van 2-dimensionale tekeningen
en metingen van de gemeente zelf ingewonnen. De kans is om hiervoor gebruik te maken van de informatie in
een IFC-bestand, waarin deze informatie al in meer detail aanwezig is.
Figuur 2 BBL gerelateerd aan BAG en BGT
Kadaster heeft een eerste analyse uitgevoerd op een conceptversie van het BBL (ontwerpbesluit). Figuur 2
geeft een overzicht van de belangrijkste concepten in het BBL en hoe deze zijn gerelateerd aan de informatie
in de BAG en de BGT. Hierin wordt zichtbaar dat BAG op andere aspecten van bouwwerken ingaat dan BBL
en dat BGT informatie geeft over de omgeving van het bouwwerk. Merk op dat strikt genomen de soorten
openbare ruimte in BAG alleen bekend zijn door een attribuut van een openbare ruimte. Kunstwerken,
spoorbanen, water, wegen en terreinen zijn geen volwaardige objecttypen in de BAG. Omgevingsinformatie
Bouwwerk
Bouwwerkperceel
Terrein
Ruimte
Gebruiksfunctie
BBL BAG
Pand
Verblijfsobject
Standplaats
Ligplaats
Adresseerbaar object
Nummeraanduiding
Openbare ruimte
Woonplaats
Aansluitend terrein
BGT
Water
Weg
Administratief
gebied
Kunstwerk
Spoorbaan
Landschappelijk gebied
Begroeid
terreindeel
Onbegroeid
terreindeel
Wegdeel
Ondersteunend
wegdeel
Ondersteunend
waterdeel
Waterdeel
Tunneldeel
Overbruggingsdeel
Kunstwerkdeel
Scheiding
Overig bouwwerk
Openbare Ruimte Label
Ongeclassificeerd
object
Plaatsbepalingspunt
Functioneel gebied
Bouwlaag
Bouwproduct
Constructie
onderdeel
BouwconstructieBouwwerk
installatie
Voorziening
Bouwactiviteit
Stof
Brand
compartiment
Vluchtroute
Vluchtroute
aanduiding
8
wordt ook gebruikt bij de toetsing van voorgestelde bouwwerken om te bepalen of voorgestelde bouwwerken
passen in hun omgeving. Dit soort informatie is ook al in een vroeg stadium bij de ontwikkeling van nieuwe
bouwwerken relevant zodat de initiatiefnemer of een architectenbureau of ingenieursbureau al rekening
kunnen houden met deze omgeving.
2.2 Aanpak
De pilot bestond uit twee delen: een analyse (onderzoek) en de ontwikkeling van een technische
demonstrator. In de analyse is vooral gekeken naar de informatiebehoefte vanuit het perspectief van
beoordeling en verwerking van bouwinformatie bij een vergunningaanvraag. Voor toetsing is daarbij met name
gekeken vanuit BBL en RO-toets. Voor verwerking is met name gekeken vanuit het perspectief van BAG, BGT
en WOZ. De analyse bestond voor een deel uit desk research en voor een ander deel uit een viertal
werksessies waarin betrokken partijen (bouwsector en gemeenten) kennis en informatie hebben uitgewisseld
over hun werkwijze (zie bijlage 2 voor deelnemerslijst). Als onderdeel van de desk research is een
conceptueel model van BBL opgesteld en zijn vergelijkingen gemaakt tussen IFC, BBL, BAG, BGT en WOZ.
Voor de ontwikkeling van de technische demonstrator is onderzocht welke tools beschikbaar zijn om
informatie uit IFC-bestanden te georefereren en te extraheren. Een IFC-bestand is gegeorefereerd en verrijkt
met voor BBL relevante gegevens. Er is een script ontwikkeld om de informatie te extraheren en in een
database vast te leggen. Hieruit is onder meer een bovenaanzicht van het gebouw gehaald zoals dat gebruikt
kan worden voor het gebruik in de BAG. Het resultaat is beschikbaar in een viewer waarin het bouwwerk zelf
zichtbaar is, alsook de relatie met contouren uit de landelijke voorzieningen BAG, BRK en ruimtelijke plannen.
Deze viewer is beschikbaar op de URL: http://data.labs.pdok.nl/apps/bimdemo.
De presentaties zoals verzorgd op de werksessies zijn beschikbaar op de website De Pilotstarter van de VNG:
https://depilotstarter.vng.nl/projecten/omgevingsdomein/vereenvoudigen-en-versnellen-vergunningverlening-
bouwaanvragen-bim
2.3 Eerder onderzoek
De pilot bestond uit een onderzoek en een proof of concept en had dus niet tot doel om productierijpe
toepassingen te ontwikkelen. Daarnaast was de intentie om maximaal voort te bouwen op kennis en
initiatieven van anderen. Zo zijn er bijvoorbeeld al eerder onderzoeken geweest naar de relatie tussen Geo,
BIM en vergunningverlening:
• TU Delft en TU/e [10, 11, 12, 13, 14, 17] hebben onder meer onderzocht in hoeverre de geometrie in een
IFC-bestand te converteren is naar CityGML en hoe om te gaan met het georefereren van IFC-
bestanden1.
• TNO [4, 5] heeft onder meer onderzocht in hoeverre IFC-bestanden geautomatiseerd kunnen worden
getoetst aan bestemmingsplannen en of LOD-niveaus in BIM afgestemd zijn op het gebruik door
gemeenten.
• Hogeschool InHolland [6] heeft onderzocht of het mogelijk is IFC-bestanden geautomatiseerd te toetsen
aan het bouwbesluit.
1 zie: https://3d.bk.tudelft.nl/projects/geobim/
9
• De Lund University in Zweden heeft onderzoek gedaan naar geautomatiseerde toetsing van IFC-
bestanden aan Zweedse bouwregelgeving t.b.v. vergunningverlening [16].
Belangrijke inzichten uit deze onderzoeken zijn:
• IFC-bestanden zijn op dit moment onvoldoende gestandaardiseerd om geautomatiseerde verwerking
(zoals beoordeling) goed te ondersteunen.
• De semantiek, geometrie en nauwkeurigheid van IFC-bestanden is fundamenteel anders dan GIS
datasets, waardoor ze niet volledig en zonder betekenisverlies naar elkaar te vertalen zijn.
• IFC-bestanden zijn veelal niet voorzien van een georeferentie (positionering in de ruimte) waardoor voor
dergelijke bestanden integratie met GIS niet mogelijk is (zonder verdere verrijking).
• Er is nog geen brede overeenstemming welke informatie in IFC-bestanden noodzakelijk is om
verschillende vormen van toetsing en verwerking door gemeenten te ondersteunen.
• Het volledig geautomatiseerd toetsen van IFC-bestanden aan regelgeving is niet mogelijk doordat een
deel van de regelgeving niet in gestructureerde vorm beschikbaar is en niet specifiek genoeg is
geformuleerd (bevat subjectiviteiten) of een kwalitatieve beoordeling vraagt.
• Een deel van de toetsing zal bestaan uit een visuele beoordeling en deze kan beter op een schematische
representatie plaatsvinden dan op een fotorealistische representatie.
• Het is mogelijk om geautomatiseerd te toetsen of een bouwwerk past binnen een aantal regels zoals
beschreven in een bestemmingsplan, zoals de maximale bouwhoogte.
• De komst van de Wet Kwaliteitsborging Bouw zorgt ervoor dat gemeenten op dit moment niet geneigd
zijn te investeren in geautomatiseerde toetsing aan Bouwbesluit/BBL.
10
3 Bestaande en voorgestelde werkwijzen
Dit hoofdstuk geeft een overzicht van bestaande en voorgestelde werkwijzen van een aantal deelnemende
partijen zoals gedeeld op de werksessies. Het geeft daarmee zeker geen volledig beeld van de werkwijzen
van deze partijen; het reflecteert alleen de uitgewisselde informatie.
3.1 Gemeente Den Haag
De gemeente Den Haag is al een aantal jaar intensief betrokken bij BIM-Geo integratie en de relatie met
vergunningverlening. De gemeente vindt dat het huidige proces van beoordeling veel sterker gedigitaliseerd
zou kunnen worden. De gemeente heeft een oriëntatiekaart ontwikkeld2 waarmee intiatiefnemers,
architectenbureaus en ingenieursbureaus inzicht kunnen krijgen in de relevante aspecten van de omgeving
van een voorgesteld bouwwerk (zie Figuur 3). Hierin wordt informatie over panden en bijgebouwen (BGT),
kadastrale ondergrond (BRK) en bestemmingsplannen (ruimtelijkeplannen.nl) in samenhang gepresenteerd.
Idealiter is deze informatie direct in de BIM omgeving beschikbaar, zodat er bij het ontwerk van het bouwwerk
mee rekening kan worden gehouden. Het voorgestelde bouwwerk kan dan direct op de juiste locatie in de
omgeving worden geplaatst.
Figuur 3 Oriëntatiekaart van de gemeente Den Haag
Voor de RO-toetsing worden er door de gemeente drie kernvragen gesteld:
• Waar bevindt het gebouw zich precies t.o.v. perceelsgrenzen, belendede bebouwing, publiek/privaat,
wegen, industrie?
• Wat gebeurt er in het gebouw?
• Welk effect heeft gebouw op omgeving en vice versa?
2 https://denhaag.maps.arcgis.com/apps/webappviewer/index.html?id=76f9f5828c5440b29239494646f87e0f
11
De gemeente ziet graag verdere ondersteuning van de RO-toets in een digitale omgeving. In een dergelijke
omgeving kan een voorgesteld bouwwerk (o.b.v. een IFC-bestand) worden geplaatst en getoond op de
aanwezige ondergronden. Hiermee wordt al een eerste visuele beoordeling van begrenzingen ondersteund.
Daarnaast wordt er idealiter ook geautomatiseerd getoetst op een aantal aspecten, zoals of een bouwwerk
binnen de maximale bouwhoogte blijft.
De gemeente heeft in 2017/2018 een specifiek initiatief op basis van BIM beoordeeld. Het doel was om inzicht
te krijgen in de mate waarin de informatie in het aangeleverd BIM gebruikt kon worden voor de constructieve
beoordeling. Initieel was slechts deel deel van de relevante informatie beschikbaar in het IFC-bestand. Na een
aantal iteraties bleek dat vrijwel alle relevante constructieve informatie vindbaar was. Alleen informatie over de
fysieke eigenschappen, veranderingen bij wijzigingen en de goedkeuring van de hoofdconstructeur waren nog
niet te vinden. Een groot deel van de benodigde informatie in het IFC-bestand is in 2D-tekeningen
gepresenteerd door gebruik te maken van een BIM viewer. Dat is geen bezwaar voor de beoordeling. De
gemeente wil in de toekomst IFC waar mogelijk gaan inzetten in haar processen als gebruiken als input voo
haar 3D stadsmodel.
3.2 Gemeente Rotterdam
De gemeente Rotterdam werkt al enige tijd aan een volledig 3D model van de stad3. Onderdeel van dit model
zijn onder meer de gebouwen, bomen, het terrein, de verlichting, kabels en leidingen. De ambitie van de
gemeente is om BIM nader te gaan verbinden aan dit 3D model. Op dit moment is er nog geen integratie met
BIM (anders dan een link naar evt. aanwezige BIM bestanden). Ultiem is het mogelijk om informatie uit BIM te
integreren in het 3D model van de stad. Anderzijds wil de gemeente de informatie in het 3D model gebruiken
om geautomatiseerde toetsing te ondersteunen, alsook om omgevingsinformatie uit het 3D model beschikbaar
te stellen in de vorm van een IFC-bestand. De gemeente wil ook sensorinformatie integreren met het 3D
model. Het is op dit moment al wel mogelijk om de informatie in verschillende formaten te exporteren uit het
3D model. De kern van het 3D model is een CityGML model dat is opgeslagen in een CityDB database.
3 zie ook: https://rotterdam.clearly-3d.nl/#/
12
Figuur 4 3D model van gemeente Rotterdam
3.3 Studioschaeffer
Studioschaeffer is een architectenbureau dat veel relatief kleine projecten doet, veelal voor bestaande bouw
en met een korte doorlooptijd. Vorig jaar hebben ze 451 vergunningsaanvragen ingediend. 90% van deze
aanvragen had betrekking op verbouw/dakopbouw. Vergunningaanvragen worden veelal binnen vijf weken
vanaf opdrachtverstrekking ingediend. Studioschaeffer verzorgt het gehele bouwproces, maar een groot deel
van het werk gaat tot en met vergunningverlening.
Studioschaeffer is in 2007 begonnen met BIM. In eerste instantie vooral voor nieuwbouw, maar al snel ook
voor bestaande bouw. Het eerste gebouw was een bedrijfsloods met 28 units in Nieuw Vennep. De
belangrijkste redenen voor het gebruik van BIM:
• Presentatietechniek. Een deel van de klanten zijn particulieren en kunnen minder goed tekeningen lezen.
3D helpt hierbij.
• Snelheid en dan met name in het aanpassen van tekeningen (als je de plattegrond iets aanpast is het
overal aangepast).
• Voorkomen van fouten. Doorsneden en plattegronden kloppen altijd met elkaar.
Op dit moment werkt Studioschaeffer volledig in BIM. Ook werken ze veel met fases, met voor iedere fase een
eigen BIM. Dit maakt een BIM wel complexer. Op dit moment wordt BIM vooral gebruikt om te modelleren
(tekenen) en nog niet zoveel voor het vastleggen van informatie. De intentie is om dat wel meer te gaan doen,
bijvoorbeeld om snel kostenramingen te kunnen maken. Tegelijkertijd geldt dat ze ook te maken hebben met
kleine bouwbedrijven die op een heel andere manier werken. Door het karakter van de opdrachten van
Studioschaeffer is het ook lastig om veel tijd te besteden aan het verrijken van IFC-bestanden met allerlei
13
extra informatie. Zo is het eigenlijk wel wenselijk om informatie over materialen toe te voegen in het kader van
circulair bouwen, maar het is commercieel gezien niet te rechtvaardigen om deze informatie structureel toe te
voegen. Het vraagt ook meer afspraken over hoe dergelijke informatie op een standaard manier vastgelegd
zou moeten worden in IFC. BIM is op dit moment ook relatief arbeidsintensief. Op dit moment is de output
voor de vergunningaanvraag: 2D vanuit 3D model, met aanvullingen.
Studioschaeffer verzamelt veel informatie uit allerlei bronnen ter voorbereiding van de vergunningaanvraag.
Deze informatie is nu erg versnipperd over bijvoorbeeld het Kadaster, RCE, omgevingsloket, gemeente,
bodemloket en AHN. Een deel van de informatie moet zelfs ook nog uit fysieke archieven gehaald worden. Er
is een een lijst is van wel 64 potentiële informatiebronnen. Het zou heel veel helpen als dit soort
omgevingsinformatie op één site toegankelijk zou zijn. Zelf meten zal overigens bijna altijd ook nog nodig zijn.
Veel van de omgeving tekent Studioschaeffer ook zelf om het overleg met de gemeente makkelijker te maken.
Studioschaeffer zou het een belangrijke verbetering vinden als de vergunningprocedure versneld zou kunnen
worden. Nu duurt een vergunningstraject 8-12 weken.
3.4 Dura Vermeer
Dura Vermeer heeft strategisch ingezet op BIM. Zij verzorgen daarbij de coördinatie en integratie van
informatie die door allerlei onderaannemers worden aangeleverd en zijn verantwoordelijk voor de logistiek en
het eindproduct. Elke onderaannemer levert typisch een eigen IFC-bestand op dat Dura Vermeer integreert in
één IFC-bestand. Bij een gemiddeld woningbouwproiect zijn wel zo’n 75 partners betrokken en bij
utiliteitsbouw kan dat oplopen tot wel 150 partijen. Dura Vemeer kijkt bij de aan te leveren informatie door
onderaannemers vooral naar de raakvlakken. Aannemers hebben bijvoorbeeld zelf verstand van beton en
daar wil Dura Vermeer zich ook niet mee bemoeien. Clash controle is voor betrokken partijen een belangrijke
BIM samenwerkingsfunctionaliteit en geeft inzicht in waar constructies met elkaar conflicteren (overlappen).
Figuur 5 Clash controle - kernfunctionaliteit bij het ondersteunen van samenwerking
14
Dura Vermeer maakt gebruik van Autodesk voor BIM. Deze biedt goede ondersteuning voor IFC (import en
export). Er gaat daarbij geen informatie verloren. Werktekeningen worden steeds minder gebruikt, op de
bouwplaats heeft iedereen tablets om naar het BIM te kijken. Dura Vermeer zet in op visueel scripting, waarbij
IFC-bestanden niet meer handmatig worden gemaakt maar worden gegenereerd. De basis hiervoor is een
spreadsheet waarin alle relevante informatie over het bouwwerk wordt gedefinieerd (objecten, afmetingen,
etc.). Dit is een bredere ontwikkeling in de bouwsector en wordt ook wel parametrisch ontwerpen genoemd.
Daarmee wordt het ontwerp van bouwwerken dus ook verder gestandaardiseerd en geautomatiseerd.
Dura Vermeer is betrokken bij de verdere standaardisering van IFC. Zo hebben ze meegewerkt aan de BIM
basis Informatieleveringspecificatie (ILS), die richtlijnen voor IFC beschrijft zodat ze meer gestandaardiseerd
zijn. Het is de vertaling van de (onleesbare) rijksvastgoednormen naar BIM. De standaard is ontwikkeld door
een aantal grote bouwpartijen, is geadopteerd door het BIM loket en wordt omarmd door meer dan 300
bedrijven. Er is ook internationaal aandacht voor. Er zouden ook aanvullende ILS’en kunnen zijn voor meer
specifieke doelgroepen. Zo zou het wenselijk zijn een ILS specifiek voor de gemeentelijke informatiebehoefte
op te stellen, onder meer ter ondersteuning van vergunningverlening. Dura Vermeer werkt op dit moment ook
mee met een verdere verdieping van de basis ILS in een gegevensbehoefteschema. In dit schema wordt voor
alle soorten objecten per ontwikkelfase aangegeven welke informatie daarin idealiter aanwezig is. Dit soort
informatie kan als user-defined property set worden toegevoegd aan IFC en wordt dan ook ondersteund door
BIM tools.
Dura Vermeer maakt op dit moment gebruik van beschikbare open data. Uitdaging daarbij is het vinden van
de juiste informatiebronnen. Er zijn er teveel en ze spreken elkaar soms tegen. Om zelf alle relevante
informatie te verzamelen is relatief arbeidsintensief. Dura Vermeer heeft zelf landmeters om metingen uit te
voeren gedurende het bouwproces. Gemiddeld wordt er wel 15 keer gemeten. Op dit moment worden BIM
bestanden ook nog niet gegeorefereerd o.b.v. RD; dat kunnen veel onderaannemers ook niet.
3.5 TNO
TNO heeft een aparte groep die zich richt op de bouwsector en BIM. Ze doen al jarenlang onderzoek op het
gebied van BIM. Een spin-off van dat onderzoek is onder meer de open-source BIMserver; een tool waarmee
informatie in een IFC-bestand kan worden gepubliceerd. Verder hebben ze ook al eens onderzoek gedaan
naar de relatie tussen BIM en bestemmingsplannen [4], waarin ook een proof of concept is ontwikkeld
waarmee IFC-bestanden automatisch worden getoetst op een aantal aspecten van een bestemmingsplan.
Een belangrijke ontwikkeling vanuit TNO is de BIMbots technologie (http://bimbots.org/). Het uitgangspunt van
deze technologie is dat veel beoordelingen van informatie in een IFC-bestand ook geautomatiseerd kunnen
plaatsvinden. Beoordelingen kunnen door geautomatiseerde bots worden uitgevoerd. Iedere bot kan daarbij
een eigen aspect toetsen. Zo zouden bijvoorbeeld specifieke aspecten uit het bouwbesluit/BBL door
specifieke bots kunnen worden getoetst.
TNO heeft eerder ook geconstateerd dat de LOD (Levels of Development) niveaus in BIM niet goed bruikbaar
zijn omdat ze onvoldoende zijn gestandaardiseerd en afgestemd op het gebruik. Zij hebben daarom BIM
informatieniveaus gedefinieerd met daarin meer gestandaardiseerde en doelgerichte informatie [5].
15
Onderstaande tabel geeft een overzicht van deze informatieniveaus en de relatie met de gangbare LOD
interpretaties. Interessant is dat hierin ook twee informatieniveaus zijn gedefinieerd die specifiek gericht zijn
op de gemeentelijke informatiebehoefte: niveau 2 is gericht op toetsing aan bestemmingsplan en
welstandcriteria en niveau 3 is gericht op de omgevingsvergunning.
Tabel 1 BIM informatieniveaus zoals voorgesteld door TNO
TNO is ook actief in de toepassing van Linked Data voor de valideren en ontsluiting van informatie over
bouwwerken. De Linked Data standaarden zijn onder meer de basis onder de COINS standaard voor de
uitwisseling van BIM informatie (als tegenhanger van IFC). Daarnaast is er ook een Linked Data versie van
IFC (IfcOWL), waarmee informatie in een IFC-bestand als Linked Data beschikbaar kan worden gesteld. TNO
heeft een modeling guide waarin zij vastleggen op welke wijze zij Linked Data standaarden inzetten voor
bouwinformatie. Daarin wordt onderscheid gemaakt tussen validatie en ontsluiting van informatie. Er wordt
met name ingezet op een combinatie van RDF, RFDS, OWL en SHACL. SHACL is een standaard die uitgaat
van een bekende set gegevens (closed world assumption) en die daardoor beter geschikt is voor het valideren
van Linked Data dan OWL. In meer algemene zin lijkt SHACL een waardevolle standaard, ook bij de
uitwisseling van Linked Data. Leidend principe in de modeling guide is om het zo simpel mogelijk te houden.
16
4 Analyse
Dit hoofdstuk geeft een overzicht van de uitgevoerde functionele analyse. Het is onderverdeeld in een deel
m.b.t. beoordeling en een deel m.b.t. verwerking in relevante administraties.
4.1 Beoordeling
Deze paragraaf gaat in op de beoordeling van bouwinformatie in de context van vergunningverlening. Het
beschrijft met name toetsing aan BBL en RO-toetsing. Andere vormen van beoordeling zijn niet onderzocht.
Wel is besproken dat beoordelding van welstand iets is dat zich (vooralsnog) niet goed leent voor
geautomatiseerde beoordeling.
De eerder genoemde informatieniveaus van TNO zoals beschreven in paragraaf 3.5 zijn een inspiratiebron
om te bepalen welke informatie er idealiter aanwezig is in een IFC-bestand om beoordeling vanuit BBL en RO
perspectief te ondersteunen. In een werksessie werd wel door deelnemers aangegeven dat de details van de
informatieniveaus onvoldoende representatief zijn voor de gemeentelijke informatiebehoefte en dus niet meer
dan een startpunt zijn.
Een belangrijk aandachtspunt is de effecten van geautomatiseerde toetsing richting burgers. De Raad van
State heeft recent een advies geschreven waarin zij zijn zorgen uit over de effecten van digitalisering voor de
rechtstatelijke verhoudingen [15]. Zij maakt zich zorgen over de risico’s, ongemakken en nadelen van
digitalisering voor de burger. Risico’s zijn onder meer dat de burger niet meer kan nagaan welke regels zijn
toegepast en dat het niet meer is vast te stellen of de regels ook werkelijk doen waarvoor ze bedoeld zijn. Ook
dreigt de burger slachtoffer te worden van een robotachtige gelijkheid, waarbij geen oog meer bestaat voor de
eigenheid van zijn situatie. De raad adviseert daarom om bij besluiten expliciet de gehanteerde beslisregels te
vermelden. Overigens geldt een verplichting voor het expliciet documenteren van beslisregels voor
geautomatiseerde beoordeling ook reeds vanuit de Algemene Verordening Gegevensbescherming. Daarnaast
adviseert de Raad om maatwerk en "menselijke" heroverweging in de bezwaarfase van geautomatiseerd tot
stand gekomen besluiten te bevorderen.
4.1.1 BBL
Er heeft door het Kadaster een eerste analyse plaatsgevonden van het ontwerpbesluit bouwwerken
leefomgeving (BBL). Het resultaat is vastgelegd als begrippenlijst en conceptueel model dat deze begrippen in
samenhang toont. Dit conceptueel model is besproken in een werksessie, waarbij voor elk informatie-item een
indicatie is gegeven van de mate waarin deze typisch in een IFC-bestand aanwezig is of zou moeten zijn. Het
resulterende model is weergegeven in Figuur 6. In dit figuur is zichtbaar dat slechts een beperkte hoeveelheid
van de voor BBL gewenste informatie typisch aanwezig is in een IFC-bestand. Onderstaande tabel geeft een
samenvatting van de informatie die meestal wel aanwezig is en meestal niet (en negeert tussenliggende
gradaties).
Er was in de werksessie consensus dat het niet wenselijk is om alle informatie over een bouwwerk in een IFC-
bestand op te slaan. Sommige informatie bestaat al elders en kan beter naar verwezen worden, bijvoorbeeld
omdat IFC niet geschikt is om volledige documenten in op te nemen. Denk bijvoorbeeld aan
prestatieverklaringen of informatie over de uiterste grenstoestand. Andere informatie ontstaat pas op een later
17
moment of wordt in andere registraties beheerd. Dit gaat onder meer over informatie over de eigenaar, de
gebruiker, het energieverbruik en of het bouwwerk tijdelijk of seizoensgebonden is.
Typisch wel aanwezig in IFC-bestand Typisch niet aanwezig maar wel gewenst
• bouwlagen
• ruimtes
• afmetingen
• bouwconstructies/constructieonderdelen
• terrein
• gebruiksfuncties
• brandcompartimenten
• brandwerendheidsinformatie
o brandwerendheid
o weerstand tegen rookdoorgang
• administratieve informatie m.b.t. ruimtes
o hoogste bezetting
o verduisterd
o maximaal aantal personen
o adres
• administratieve informatie m.b.t. bouwwerk
o adres
o geografische locatie
o ligging
o kadastrale informatie
o energie-eigenschappen
Tabel 2 Aanwezigheid van gewenste informatie in IFC-bestand
In het algemeen is het belangrijk om het beheer van gegevens bij de bron te laten. Sommige informatie is
inherent aan het ontwerp van een bouwwerk en kan dus het beste in een IFC-bestand worden beheerd.
Informatie over de leefomgeving valt hier bijvoorbeeld niet onder. Dergelijke geo-informatie wordt typisch
beheerd in de context van GIS. Een combinatie en integratie van BIM- en GIS-pakketten is daarom wenselijk.
De belangrijkste pakketleveranciers spelen hier reeds op in [7].
Een andere overweging om te bepalen of het waardevol is om bepaalde informatie wel of niet op te nemen in
een IFC-bestand is of geprofiteerd wordt van de structuur van IFC. In het bijzonder is een IFC-bestand een
hiërarchische structuur van gegevens, waarbij voor individuele elementen gegevens worden vastgelegd.
Gegevens die niet op het bouwwerk als geheel van toepassing zijn, maar alleen voor specifieke elementen,
profiteren daarmee van de IFC structuur (t.o.v. een anderssoortige administratieve vastlegging). In de tabel is
zichtbaar dat dit bijvoorbeeld voor ruimtes geldt.
Overigens is een deel van de vanuit Bouwbesluit/BBL benodigde informatie ook al geborgd in de RVB BIM
Norm [3] voor IFC-bestanden. Deze stelt onder meer dat informatie over gebruiksfuncties, vluchtroutes,
brandcompartimenten, brandveiligheidsvoorzieningen en maximaal aantal personen in een ruimte moet zijn
opgenomen. Het stelt ook dat bestanden moeten zijn voorzien van een georeferentie en dat bij
terreininformatie een relatie wordt gelegd met de kadastrale aanduidingen.
18
Figuur 6 Aanwezige en gewenste BBL informatie in IFC
Bouw
wer
k(b
esta
and
en n
ieuw
)
eige
naar
gebr
uike
rad
res
geog
rafis
che
loca
tielig
ging
brut
o-vl
oero
pper
vlak
teen
ergi
ever
brui
k vor
ig ja
aren
ergi
elab
elen
ergi
e-pr
esta
tie-c
oeffi
cient
(EPC
)bi
jna e
nerg
iene
utra
al (j
/n)
mon
umen
t (j/n
)be
vat m
onum
enta
le d
elen
(j/n
)bi
jbeh
oren
d (j/
n)tij
delij
k (j/n
)se
izoen
sgeb
onde
n (j/
n)
Kada
stra
al o
bjec
t
kada
stra
le aa
ndui
ding
apar
tem
ents
rech
ten
Terr
ein
terr
eini
nrich
ting
opst
elpl
aats
en
Ruim
te
plaa
tsin
gle
ngte
-bre
edte
-hoo
gte
brut
o-vl
oero
pper
vlak
tene
tto-
vloe
ropp
ervl
akte
vloe
ropp
ervl
akte
gebr
uiks
oppe
rvla
kte
dagl
ichto
pper
vlak
teho
ogst
e bez
ettin
gto
egan
kelij
khei
dsse
ctor
(j/n)
verd
uist
erd
(j/n)
max
imaa
l #pe
rson
enco
ncen
trat
ie va
n as
best
veze
lsco
ncen
trat
ie v.
form
alde
hyde
adre
s
Bouw
laag
max
imaa
l #pe
rson
enpl
atte
gron
dtek
enin
g
Bouw
cons
truc
tie
plaa
tsin
gle
ngte
-bre
edte
-hoo
gte
open
inge
nvl
oero
pper
vlak
tein
wen
dig(
j/n)
bran
dwer
endh
eid
kara
kter
istie
ke ge
luid
wer
ing
klim
lijn
norm
endr
aagc
onst
ruct
ie (j
/n)
uite
rste
gren
stoe
stan
d
Bouw
wer
kin
stal
latie
plaa
tsin
gsy
stee
mre
ndem
ent
norm
en
Bran
dcom
part
imen
t
beva
t cel
eenh
eid
(j/n)
wbd
bosu
bbra
ndco
mpa
rtim
ent(
j/n)
besc
herm
d (j/
n)
Vluc
htro
ute
geom
etrie
leng
te
Cons
truc
tieon
derd
eel
plaa
tsin
gon
derd
eel v
an b
ouw
schi
lle
ngte
-bre
edte
-hoo
gte
vrije
bre
edte
vrije
hoo
gte
aank
ledi
ngw
arm
tedo
orga
ngsc
oëffi
ciënt
wee
rsta
nd te
gen r
ookd
oorg
ang
perm
anen
te vu
urbe
last
ing?
bew
eegb
aar (
j/n)
Aans
luite
nd t
erre
in
mee
tniv
eau
Bouw
prod
uct
mat
eria
alCE
-mar
kerin
gpr
esta
tieve
rkla
ring
bran
dbaa
r(j/n
)
Voor
zieni
ng
plaa
tsin
gca
pacit
eit
norm
en
Vluc
htro
ute
aand
uidi
ng
geog
rafis
che
loca
tielo
opaf
stan
den
orie
ntat
ieve
rlich
ting
Activ
iteit
soor
t act
ivite
itm
ilieu
effe
ctbo
uw-o
f slo
opm
etho
diek
Stof
hoev
eelh
eid
aard
oors
pron
gaf
voer
best
emm
ing
wijz
e va
n to
epas
sing
wijz
e va
n ve
rwijd
erin
g
Gebr
uiks
func
tie
lege
nda
typi
sch
aanw
ezig
som
s aan
wez
ig
afle
idba
ar
last
ig a
fleid
baar
gew
enst
link g
ewen
st
niet
gew
enst
19
Eerder onderzoek heeft al aangetoond dat het mogelijk is om een groot deel van de toetsing aan
BBL/bouwbesluit te automatiseren. In het onderzoek dat vanuit hogeschool InHolland is uitgevoerd [6] zijn
verschillende regels geïmplementeerd in Solibri Model Checker. Het tool controleerde onder meer of er een
verplichte opslagruimte aanwezig is, of rookmelders aanwezig zijn, of afmetingen van specifieke ruimten
voldoen aan de eisen, of vluchtroutes voldoen aan de maximale lengte en of railings hoog genoeg zijn.
Specifieke aandachtspunt dat uit dit onderzoek volgt is dat voorzichtig moet worden omgegaan met het
resultaat van de geautomatiseerde toets omdat deze niet per definitie een betrouwbaar antwoord geeft. Dit
antwoord is onder meer sterk afhankelijk van de mate waarin de informatie op de juiste wijze is aangebracht in
het IFC-bestand. Daarnaast zitten er subjectieve elementen in de toetsing, onder meer in het bepalen en
toepassen van de drie complianceniveaus in het bouwbesluit (nieuwbouw, verbouw, bestaande bouw) en aan
de wijze van vloeroppervlaktebepaling. Zo is de NEN 2580 norm voor het berekenen van vloeroppervlakten
niet gericht op digitale verwerking. De verwaarlozingsregels (zoals kolommen kleiner dan 0,5m2 e.d.) zijn
ontstaan uit de behoefte om snel analoog te kunnen opmeten. Het onderzoek geeft ook aan dat door de
aangekondigde Wet Kwaliteitsborging Bouw gemeenten niet geneigd zijn te investeren in automatisering van
de beoordeling van IFC-bestanden t.a.v. bouwbesluit. Dit betekent dat andere partijen tools voor dit soort
beoordelingen zullen moeten ontwikkelen.
4.1.2 RO-toets
De RO-toets gaat over de inpassing van de vergunningaanvraag in de omgeving. De kernvragen die
onderdeel zijn van de RO-toets (zie paragraaf 3.1) zijn in een werksessie verdiept tot de volgende meer
specifieke vragen die ook geautomatiseerd getoetst zouden kunnen worden:
1. Waar bevindt het gebouw zich precies t.o.v. perceelsgrenzen, belendede bebouwing, publiek/privaat,
wegen, industrie?
a. Blijft het bouwwerk binnen de grenzen van de enkelbestemming?
b. Blijft het bouwwerk (voetafdruk) binnen het voorgeschreven percentage bebouwing?
c. Overlapt het bouwwerk met een dubbelbestemming? (trigger voor menselijke beoordeling)
d. Blijft de hoogte van het bouwwerk binnen de maximale bouwhoogte?
e. Blijft het bouwwerk binnen de perceelsgrenzen?
2. Wat gebeurt er in het gebouw?
a. Zijn de gebruiksfuncties van het bouwwerk in lijn met het bestemmingsplan? (ruimteniveau nog
niet nodig, wel geaggregeerd per functie voor bouwwerk in termen van gebruiksoppervlakte en
vloeroppervlakte)
3. Welk effect heeft gebouw op omgeving en vice versa?
a. Mag het bouwwerk gegeven de geluidzone of veiligheidszone (provinciaal) en/of zijn
aanvullende maatregelen noodzakelijk?
b. Heeft de omliggende bebouwing niet te veel schaduw van het bouwwerk? (gegeven de
gebruiksfuncties in de omgeving)
Figuur 7 geeft een overzicht van de informatie die relevant is vanuit het perspectief van RO-toetsing. Een IFC-
bestand zou in ieder geval de volgende informatie moeten bevatten om deze toets goed te ondersteunen:
• Locatie
20
• Voetafdruk
• Hoogte
• Geometrie in LOD 2 (voor schaduw)
• Gebruiksfuncties (IMRO en BBL) van bouwwerk
• Gebruiksfuncties van de omgeving (bijv. winkel eronder)
Deze informatie in het IFC-bestand dient met name geconfronteerd te worden met informatie uit
bestemmingsplannen (in de toekomst omgevingsplannen), maar ook met informatie uit BRK en BGT. Een
visuele toets wordt daarbij bij voorkeur ondersteund door een meetfunctie die gebruikers in staat stelt om
afstanden te meten tussen objecten. Een dergelijke functie zou de meetpunten ook moeten kunnen vastzetten
(snappen) op contouren van de objecten. Hierbij moet wel de nauwkeurigheid van de verschillende bronnen in
acht worden genomen.
Zoals eerder aangegeven is er al eerder een onderzoek geweest naar mogelijke automatisering van RO-
toetsing [4]. Hierin is een proof of concept ontwikkeld waarmee IFC-bestanden automatisch worden getoetst
op een aantal aspecten van een bestemmingsplan.
Figuur 7 Informatie relevant voor RO-toetsing
4.2 Verwerking
Deze paragraaf gaat in op de relatie tussen de informatie in een IFC bestand en de informatie die nodig is
voor de verwerking in de verschilende administraties bij de gemeente. Het laat zien wat de relatie is met de
geobasisregistraties BAG, WOZ en BGT. Het gaat meer specifiek ook in op gegevens m.b.t.
vloeroppervlakten, gebruiksfuncties en ruimtes. Deze kennen in BBL en de registraties (BAG, WOZ,
BestemmingsplanRuimtelijkeplannen.nl
PDOK
- Enkelbestemming
- Dubbelbestemming
- Bouwvlak
- Bouwaanduiding
- Figuur
- Functieaanduiding
- Gebiedsaanduiding
- Maatvoering
- Lettertekenaanduiding
BRK grenzenPDOK
Percelen
Perceelnummers
BGTPDOK
Ondergrond
Panden
Bijgebouwen
RO toetsBIM- Locatie
- Voetafdruk
- Hoogte
- Geometrie in LOD 2 (voor schaduw)
- Gebruiksfuncties (IMRO en BBL) van bouwwerk
- Gebruiksfuncties van de omgeving (bijv. winkel eronder)
Inpassing van het plan /
de vergunning-aanvraag
in de omgeving
Om
gevin
gP
lan /
Verg
unnin
g-
aanvra
ag
ToolsMeetfunctie (met
snapping)
21
ruimtelijke plannen) afwijkende definities en vragen dus een vertaling. Hieruit wordt zichtbaar hoe belangrijk
het is om scherp te kijken naar de beschikbare definities bij het creëren van gegevens. Merk op dat er op dit
moment gewerkt wordt aan een objectenregistratie met basisgegevens over objecten in de fysieke
werkelijkheid. BAG, BGT en WOZ zullen daarbij waarschijnlijk in één registratie worden samengebracht.
Algemeen aandachtspunt bij verwerking is nauwkeurigheid van GIS informatie. IFC-bestanden hebben typisch
een veel hogere nauwkeurigheid (millimeter) dan de gevraagde nauwkeurigheid van GIS bestanden zoals ook
de landelijke geobasisregistraties (25-30 cm). Er blijkt soms heel precies gemeten te worden met lijnen uit
deze registraties, zonder rekening te houden met hun nauwkeurigheid.
4.2.1 BAG
Gemeenten zijn bronhouder voor de BAG. Het gebruik van een IFC-bestand bij de vergunningaanvraag als
bron voor de informatie kan het administratieve proces m.b.t. BAG voor een gemeente eenvoudiger maken. Er
bestaan voor de levenscyclus van een BAG object vier fasen met een logische volgorde van statussen die in
de BAG worden opgenomen: planvorming, bouw, gebruik en sloop. Daarbij kan het voorkomen dat het IFC-
bestand bij de vergunningaanvraag (as designed) niet volledig overeenkomt met het opgeleverde object (as
built), maar dat kan in het huidige proces ook gebeuren. In Figuur 8 is zichtbaar wat het gegevensmodel van
de BAG is en welke informatie automatisch uit een IFC-bestand kan worden overgenomen.
Het is mogelijk om uit een IFC-bestand automatisch de geometrie van een pand of verblijfsobject af te leiden.
Deze geometrie betreft “de minimaal tweedimensionale geometrische representatie van het bovenzicht van de
omtrekken van een pand”. Daarnaast is het mogelijk om oppervlakteberekeningen uit te voeren. Hierover
meer in paragraaf 4.2.4.
Op dit moment is in een IFC-bestand meestal geen informatie opgenomen over het gebruiksdoel. Maar zoals
in paragraaf 4.1.1 en Tabel 3 genoemd is, is dit gewenste informatie voor beoordeling van een
vergunningaanvraag aan het BBL. Deze informatie kan dan hergebruikt worden voor opname in de BAG. In
paragraaf 4.2.5 wordt het gebruiksdoel ook gerelateerd aan het BBL en ruimtelijke plannen.
Bij sommige bronhouders bestaat de behoefte om meer informatie aan de BAG toe te voegen, de
zogenaamde BAG-plus. Twee van de kenmerken die bijvoorbeeld de gemeente Amsterdam zal gaan
opnemen zijn: aantal bouwlagen en toegang woning. Deze kenmerken kunnen ook automatisch afgeleid
worden uit een IFC-bestand.
22
Figuur 8 BAG gegevensmodel en relatie met informatie in IFC-bestand
4.2.2 WOZ
Naast registratie in de BAG kan een bouwwerk bij een vergunningverlening ook doorwerken in een WOZ-
object binnen de WOZ registratie. Een WOZ-object kan bestaan uit één of meer (delen van) een verblijfsobject
23
en één of meer panden uit de BAG. Het attribuut oppervlakte van een WOZ-object kan net als bij de BAG
afgeleid worden uit een IFC-bestand (zie ook paragraaf 4.2.4).
Figuur 9 WOZ gegevensmodel
4.2.3 BGT
De BGT bevat objecten die de bestaande situatie in de werkelijkheid representeren. Uitsluitend panden die in
de BAG voorkomen met bepaalde status maken met hun grondvlakgeometrie deel uit van de BGT. Het is
inmiddels ook mogelijk om geplande objecten op te voeren in de BGT (plantopografie). Informatie in een IFC-
bestand heeft betrekking op panden in de BGT. Van alle attributen van een BGT-pand is alleen de geometrie
uit een IFC-bestand af te leiden, de overige attributen zijn BGT-specifiek. De grondvlakgeometrie van de BGT
is waar de voetafdruk van het pand de ondergrond raakt, dit is dus anders dan het bovenaanzicht van de
omtrek van een pand in de BAG. Deze ‘footprint’ is automatisch uit een IFC-bestand af te leiden.
Figuur 10 BGT gegevensmodel
24
4.2.4 Vloeroppervlakte
Er spelen in het BBL een aantal verschillende vormen van vloeroppervlakte een rol. Figuur 11 geeft een
overzicht van deze vormen, waarbij het groen gearceerde deel meetelt voor de oppervlakte. De gehanteerde
termen zijn gedefinieerd op basis van NEN 2580. De bruto-vloeroppervlakte is de vloeroppervlakte van de
ruimte, dan wel van meerdere ruimten van een vastgoedobject gemeten op vloerniveau langs de buitenomtrek
van de (buitenste) opgaande scheidingsconstructie, die de desbetreffende ruimte(n) omhullen. Bij de netto-
vloeroppervlakte wordt gemeten op vloerniveau tussen de begrensde opgaande scheidingsconstructie. Ook
worden bepaalde delen niet meegenomen, zoals een schalmgat of een vide, indien de oppervlakte daarvan
groter is dan 4 m². Voor de gebruiksopppervlakte wordt alleen meegerekend de oppervlakte waarboven de
netto-hoogte 1,5 m of hoger is. Vides en schalmgaten van meer dan 4 m2 blijven buiten beschouwing,
evenals inspringingen en uitspringingen langs de omtrekken van minder dan 0,5 m2.
De BAG en de WOZ interpreteren genoemde vloeroppervlakten net iets specifieker. Voor de BAG geldt voor
gebruiksoppervlakte bijvoorbeeld:
1. De BAG meetinstructie verdeelt de inpandige gebruiksoppervlakte onder in gebruiksoppervlakte wonen en
gebruiksoppervlakte overige inpandige ruimte. NEN 2580 kent deze onderverdeling niet.
2. Omdat het vaak lastig te bepalen is of een wand of muur al dan niet dragend is, gaat de BAG meetinstructie
uit van de oppervlakte inclusief dragende binnenwanden. NEN 2580 gaat uit van de oppervlakte exclusief
dragende wanden.
In het kader van de BAG is een oppervlakte verdiepingsdocument voor gemeenten opgesteld [8]. Dit
document geeft duidelijkheid over de gebruiksoppervlakte van verblijfsobjecten en de relatie met onder meer
bouwtekeningen. Vanuit het perspectief van BAG geredeneerd geldt overigens een toegestane afwijking van
1,15 * √ oppervlak, zodat een net iets andere definitie wel binnen de BAG marges kan vallen.
Voor de wijze waarop de oppervlakte of de inhoud van een WOZ-object moeten zijn bepaald, bestaat geen
dwingend meetvoorschrift. Wel vermeldt de Waarderingsinstructie dat de vastlegging van de grootte bij
voorkeur bruto plaatsvindt en bij voorkeur gebaseerd is op de meetvoorschriften van NEN 2580. De WOZ
bruto-vloeroppervlakte betreft de buitenwerks gemeten oppervlakte, inclusief kelders, maar exclusief loggia’s
en bijbouwen, die niet onder dezelfde dakconstructie zijn gelegen. De WOZ netto-vloeroppervlakte
betreft de binnenwerks gemeten oppervlakte exclusief verkeersruimte. Voorwaarde is wel dat elke gemeente
binnen de gemeente alle WOZ-objecten op dezelfde wijze meet. Anders wordt de onderlinge vergelijkbaarheid
onmogelijk. Per gemeente kan de meetmethode dus verschillen.
Er geldt voor de WOZ geen verplichting om de oppervlakte te gebruiken bij de taxatie. Voor gemeenten die op
basis van de oppervlakte taxeren, geldt wel vanaf 2011 het uitgangspunt dat de oppervlakte, zoals deze in de
BAG geregistreerd staat, het uitgangspunt is voor de taxatie. Los van alle taxatietechnische argumentatie die
voor- en tegenstanders van de gebruiksoppervlakte kunnen aanvoeren, is aan een burger immers niet uit te
leggen dat de ene afdeling van de gemeente zegt dat zijn woning X m2 groot en de andere afdeling beweert
dat het Y m2 is. Niet alle WOZ-deelobjecten zijn exact gelijk aan de BAG verblijfsobjecten. Als een BAG
verblijfsobject moet worden gesplitst in bijvoorbeeld twee WOZ-(deel)objecten, dan moet de gezamenlijke
oppervlakte van de desbetreffende WOZ-deelobjecten natuurlijk wel weer gelijk zijn aan de oppervlakte van
25
het verblijfsobject. Op welke wijze BAG-objecten en WOZ objecten met elkaar samenhangen is uitgewerkt in
een brochure [9].
Zolder Verdieping
Bru
to v
loe
rop
pe
rvla
kte
Nett
o v
loe
rop
pe
rvla
kte
Ge
bru
ikso
pp
erv
lakte
Figuur 11 Onderscheid tussen bruto vloeroppervlakte, netto vloeroppervlakte en gebruiksoppervlakte [8].
4.2.5 Gebruiksfuncties, gebruiksdoelen en bestemmingshoofdgroepen.
De term gebruiksfunctie wordt in BBL gebruikt voor gedeelten van een of meer bouwwerken die dezelfde
gebruiksbestemming hebben en die samen een gebruikseenheid vormen. Gebruiksfuncties hebben als doel
om onderscheid in gebruik bij gebouwen te creëren. Dit is belangrijk omdat elke gebruiksfunctie andere
26
voorschriften heeft in bijvoorbeeld daglichttoetreding en daglichtoppervlakte (ramen), aantal vereiste toiletten,
verkeerslawaai (geluidswering), ventilatiecapaciteit, brandwerendheid, minimale bezettingsgraadklasse e.d.
Dit ligt sterk aan tegen de term gebruiksdoel in BAG die is gedefinieerd als een categorisering waarmee het
gebruiksdoel van een verblijfsobject kan worden verbijzonderd. Een categorisering van de gebruiksdoelen van
het betreffende verblijfsobject zoals in de vergunning is opgenomen of bij constatering is vastgesteld. Er
kunnen dus aan aan één object verschillende gebruiksdoelen worden toegekend. Praktisch gezien verwijst
BAG naar het Bouwbesluit en zijn gebruiksfuncties en gebruiksdoelen dus aan elkaar gelijk.
Gebruiksfuncties hebben ook een sterke relatie met de term bestemmingshoofdgroep zoals worden gebruikt
in ruimtelijke plannen. Bestemmingshoofdgroepen zijn een indeling van specifieke planologische
bestemmingen. Deze stellen kaders aan de functies die zijn toegestaan op een specifieke locatie. De
volgende tabel laat de relatie tussen gebruiksfuncties en bestemmingshoofdgroepen zien.
Gebruiksfuncties (BBL)/gebruiksdoelen (BAG) Bestemmingshoofdgroepen (ruimtelijke plannen)
• Bijeenkomstfunctie
• Celfunctie
• Gezondheidszorgfunctie
• Industriefunctie
• Kantoorfunctie
• Logiesfunctie
• Onderwijsfunctie
• Overige gebruiksfunctie
• Sportfunctie
• Verblijfsobject
• Winkelfunctie
• Woonfunctie
• agrarisch
• agrarisch met waarden
• bedrijf
• bedrijventerrein
• bos
• centrum
• cultuur en ontspanning
• detailhandel
• dienstverlening
• gemengd
• groen
• horeca
• kantoor
• maatschappelijk
• natuur
• overig
• recreatie
• sport
• tuin
• verkeer
• water
• wonen
• woongebied
Figuur 12 Gebruiksfuncties en bestemmingshoofdgroepen
4.2.6 Ruimtes
Het is mogelijk om in een IFC-bestand ruimtes aan te geven met het objecttype IFCspace. Vanuit BBL
perspectief is dit een belangrijk objecttype met eigenschappen zoals het maximaal aantal personen, de
27
hoogste bezetting, verschillende vormen van oppervlakte en de gebruiksfunctie. Op dit moment wordt dit soort
informatie nog niet allemaal structureel toegevoegd aan een IFC-bestand.
28
5 Technisch onderzoek
Dit hoofdstuk beschrijft de resultaten van het technisch onderzoek en de ontwikkeling van een technische
demonstrator. Het start met een korte beschrijving van het onderzoek en het onderzoeksobject. Vervolgens
worden de verschillende aspecten van het onderzoek verder uitgewerkt.
5.1 Onderzoek
Het onderzoek had tot doel om inzicht te krijgen in de mate waarin het verrijken en extraheren van informatie
uit een IFC-bestand mogelijk is. Daarnaast was het doel om te bepalen of de verkregen informatie kan worden
verbonden met andere informatie en kan worden gevisualiseerd. In het bijzonder is het verbinden van
informatie uit een IFC-bestand met informatie uit landelijke geo-registraties BRK, BAG, BGT en
ruimtelijkeplannen.nl relevant.
In het onderzoek is een eerder door een stagiair ontwikkeld IFC-bestand van het kantoor van Geodan te
Amsterdam als voorbeeld gebruikt. Dit gebouw is in Autodesk Revit (de meestgebruikte BIM-software voor
gebouwen) voorzien van een georeferentie en verrijkt met aanvullende informatie die relevant is voor RO- en
BBL-toetsing en verwerking in gemeentelijke administraties. Het resultaat is m.b.v. FME geconverteerd naar
een PostGIS-database. Op basis van de inhoud van deze database is een viewer ontwikkeld, waarmee het
gebouw in zijn omgeving wordt getoond. In deze viewer is het gebouw in 2D gekoppeld aan de
enkelbestemming en maatvoering uit het geldende bestemmingsplan alsook aan het kadastrale perceel zoals
gedefinieerd in de BRK.
Er is in het onderzoek ook onderzocht in hoeverre Linked Datatechnieken ingezet kunnen worden voor het
definiëren, extraheren en ontsluiten van de informatie in het IFC-bestand. Hiertoe is de bruikbaarheid van een
aantal hulpmiddelen onderzocht en is een aanzet gemaakt tot een vocabulaire voor BBL-begrippen. Door
beperkingen in tijd was het niet mogelijk geheel op Linked Data gebaseerde toetsing van bouwplannen te
testen. Op basis van de bevindingen is wel het beeld ontstaan dat het gebruik van Linked Data voor IFC-
bestanden een haalbare oplossingsrichting is. De volgende paragraaf gaat dieper in op Linked Data en de
toepassing in de context van IFC.
5.2 Linked Data
Er is in dit onderzoek gekeken naar de inzet van Linked Data. Linked Data is een verzameling ideeën en
bijbehorende standaarden behorende bij het semantisch web. Het semantisch web is een verrijking van het
standaard world wide web met betekenisvolle informatie. Het doel ervan is om informatie eenvoudig te kunnen
delen. Linked Data verwijst vooral naar het idee dat ruwe data op het web te koppelen zijn, op dezelfde
manier als webdocumenten via hyperlinks te koppelen zijn. Door data te ontsluiten via HTTP en vindbaar te
maken via een unieke sleutel (URI) hoeven gegevensbronnen niet gekopieerd te worden, maar zijn ze direct
via het web te gebruiken. Daarnaast zijn de gegevens verbonden met hun definitie, want voor data en
semantiek wordt hetzelfde model gebruikt: het Resource Description Framework (RDF).
Naast het gegevensuitwisselingsprotocol (HTTP) en het basisinformatiemodel (RDF) zijn belangrijke
standaarden voor Linked Data SKOS, RDFS, OWL en SHACL. SKOS is een standaard waarmee begrippen
kunnen worden gedefinieerd en waarmee relaties tussen deze begrippen kunnen worden beschreven. Een
29
dergelijke begrippenlijst of thesaurus zorgt voor gemeenschappelijke definities. Daarmee maakt het ook de
integratie van systemen eenvoudiger. Voor een meer exacte informatiemodellering kunnen de RDFS (RDF
Schema) en OWL (Ontology Web Language) standaarden gebruikt worden. Deze standaarden maken het
mogelijk om domeinen te modelleren op een manier waarop ze zowel door mensen als systemen
interpreteerbaar zijn. Er is ook een standaard zoektaal beschikbaar waarmee vragen kunnen worden gesteld
aan gegevens die op deze manier zijn gemodelleerd. Deze zoektaal heet SPARQL en is vergelijkbaar met
SQL, de zoektaal voor relationele databases. SHACL is een relatief nieuwe specificatie die het mogelijk maakt
de structuur van datasets te beschrijven in de vorm van constraints. Dat maakt het mogelijk om gegevens
geautomatiseerd te controleren op afwijkingen, maar kan bijvoorbeeld ook gebruikt worden om documentatie
te genereren. Het controleren of afwijkingen maakt SHACL een interessant hulpmiddel voor het toetsen IFC-
bestanden.
Linked Data wordt al breder ingezet in de context van bouwwerken. Zo is de Conceptenbibliotheek Nederland
(CB-NL) een voorbeeld van een thesaurus voor begrippen in de bouwsector. Linked Data is ook de basis voor
de COINS-standaard, die meer gangbaar is voor infrastructuur. COINS biedt een semantische container voor
informatie en bestanden die zijn gerelateerd aan een bouwwerk. Een IFC-bestand kan onderdeel zijn van een
COINS container. Er is ook een ontologie beschikbaar voor IFC: IfcOWL4. IfcOWL maakt het mogelijk een
IFC-bestand om te zetten naar Linked Data. De ontologie is het resultaat van een directe één-op-één vertaling
van de IFC-standaard naar OWL. Daardoor is behoorlijk wat kennis van IFC nodig om naar IfcOWL
geconverteerde data te interpreteren. Iemand met algemene kennis van Linked Data maar zonder kennis van
IFC zal daardoor moeite hebben met het interpreteren van deze gegevens.
Tijdens het onderzoek bleek het lastig te zijn software te gebruiken om IFC-SPF om te zetten in Linked Data.
Er is uiteindelijk gebruik gemaakt van het open source tool IFCtoRDF-Desktop5. Er is in het onderzoek een
deel van een ontologie voor BBL opgesteld. Deze beschikbaar op: https://data.labs.pdok.nl/data/bbl/bbl.html
(in HTML formaat) en https://data.labs.pdok.nl/data/bbl/bbl.ttl (als Linked Data in Turtle formaat). Tabel 3 laat
delen zien uit deze ontologie. Het definieert de concepten bouwwerk, gebouw en ruimte en de eigenschappen
bezetting en maximale bezetting. Deze eigenschappen kunnen bijvoorbeeld gebruikt worden om regels uit
BBL te toetsen die betrekking hebben op de bezetting van ruimtes.
:Bouwwerk a skos:Concept, rdfs:Class;
skos:prefLabel "bouwwerk"@nl;
rdfs:label "bouwwerk"@nl;
skos:definition "Constructie van enige omvang van hout, steen, metaal of
ander materiaal, die op de plaats van bestemming hetzij direct of indirect met
de grond verbonden is, hetzij direct of indirect steun vindt in of op de grond,
bedoeld om ter plaatse te functioneren, met inbegrip van de daarvan deel
uitmakende installaties."@nl;
skos:related :Bouwlaag;
.
4 Zie: http://openbimstandards.org/standards/ifcowl/ 5 Zie: https://github.com/jyrkioraskari/IFCtoRDF-Desktop
30
:Gebouw a skos:Concept, rdfs:Class;
skos:prefLabel "gebouw"@nl;
rdfs:label "bouwwerk"@nl;
skos:definition "Bouwwerk dat een voor mensen toegankelijke overdekte geheel
of gedeeltelijk met wanden omsloten ruimte vormt."@nl;
rdfs:subClassOf :Bouwwerk;
skos:relatedMatch ifc:IfcBuilding;
.
:Ruimte a skos:Concept, rdfs:Class;
skos:prefLabel "ruimte"@nl;
rdfs:label "ruimte"@nl;
skos:editorialNote "Dit begrip wordt wel gebruikt, maar niet gedefinieerd in
het bouwbesluit/BBL. De definitie is gekopieerd van wikipedia. Wellicht is het
begrip officieel gedefinieerd in NEN 2748?"@nl;
skos:definition "Een plaats in een gebouw die geheel of gedeeltelijk door
bouwkundige scheidingsconstructies wordt begrensd."@nl;
skos:relatedMatch ifc:IfcSpace;
.
:bezetting a owl:DatatypeProperty;
skos:editorialNote "Dit begrip wordt wel gebruikt, maar niet gedefinieerd in
het bouwbesluit/BBL."@nl;
skos:prefLabel "bezetting"@nl;
rdfs:label "bezetting"@nl;
rdfs:comment "Het aantal personen dat normaal gesproken van een ruimte
gebruik maakt."@nl;
rdfs:domain :Ruimte;
rdfs:range xsd:Integer;
.
:maximaleBezetting a owl:DatatypeProperty;
skos:editorialNote "Dit begrip wordt wel gebruikt, maar niet gedefinieerd in
het bouwbesluit/BBL."@nl;
rdfs:label "maximale bezetting"@nl, "hoogste bezetting"@nl;
rdfs:comment "Het maximaal aantal personen dat zich redelijkerwijs in een
ruimte kan bevinden."@nl;
rdfs:domain :Ruimte;
rdfs:range xsd:Integer;
.
Tabel 3 Delen uit BBL-ontologie
31
Het Kadaster heeft ervoor gekozen strategisch in te zetten op Linked Data. In dat kader is een dataplatform
ontwikkeld gebaseerd op de standaarden en conventies van Linked Data en zijn onder meer BAG, BRT, DKK
(onderdeel van BRK) en ruimtelijkeplannen.nl ontsloten als Linked Data. Deze data zijn via API’s en als
SPARQL-endpoint beschikbaar als open data. De data kunnen ook worden gebruikt in de context van IFC-
bestanden. Ter illustratie is er een zoekvraag (query) opgesteld die de maximale bouwhoogte van het
bestemmingsplan ophaalt (zie Tabel 4). Deze kan worden gebruikt om RO-toetsing te ondersteunen. Meer
informatie over het dataplatform van het Kadaster is te vinden op: https://www.kadaster.nl/dataplatform.
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix dct: <http://purl.org/dc/terms/>
prefix ro: <http://data.informatiehuisruimte.nl/def/ro#>
prefix pdok_pdok: <http://data.pdok.nl/def/pdok#>
prefix ogc: <http://www.opengis.net/ont/geosparql#>
prefix ogcf: <http://www.opengis.net/def/function/geosparql/>
prefix ro_beg: <http://data.informatiehuisruimte.nl/ro/id/begrip/>
select (min(?waarde) as ?maximale_bouwhoogte)
where {
?plan a ro:Bestemmingsplan.
?plan ro:planstatus ?planstatus.
?planstatus ro:status ?status.
?planstatus ro:status ro_beg:Vastgesteld_Documentstatus.
?plan rdfs:label ?planlabel.
?maxhoogte a ro:MaximumBouwhoogte_m_Omvang.
?maxhoogte ro:omvangwaarde ?waarde.
?maatvoering ro:omvang ?maxhoogte.
?maatvoering ?isPartOf ?plan.
?maatvoering dct:spatial ?maatvoeringsgebied.
?maatvoeringsgebied ro:geometrie ?maatvoeringsgebiedgeometrie.
?maatvoeringsgebiedgeometrie ogc:asWKT ?mvgwkt.
FILTER (ogcf:sfContains(?mvgwkt, "POINT(6.75099 52.31332)"^^ogc:wktLiteral))
}
Tabel 4 Zoekvraag (query) voor raadplegen maximale bouwhoogte in bestemmingsplan
5.3 Georeferentie
Georefereren is het koppelen van de geometrie in een BIM aan het aardoppervlak. Georeferentie maakt het
mogelijk de vormpunten van een bouwwerk in een BIM uit te drukken in een coördinatensysteem dat wordt
gebruikt om locaties op aarde mee aan te duiden. Het is noodzakelijk om een RO-toets te kunnen uitvoeren
op een IFC-bestand. Het is ook nodig om het te kunnen verwerken in geografische (basis)registraties zoals
BAG, BGT of WOZ.
In de praktijk blijken veel IFC-bestanden niet of onvoldoende geogerefereerd. De meestgebruikte versie van
de IFC-specificatie (IFC2x3) ondersteunt geogereferentie ook niet optimaal. Een belangrijk onderdeel van
32
georeferentie zijn de lengtegraad, breedtegraad en hoogte die aan IFC-klasse IfcSite kunnen worden
toegekend, als oorsprong van het coördinatensysteem. Volgens IFC2x3 mag de locatie van dat punt bij
benadering worden opgegeven en moeten de lengtegraad en breedtegraad op referentiesysteem WGS84
worden gebaseerd. WGS84 is echter voor locaties in Europa ongeschikt omdat WGS84-locaties vanwege
plaattectoniek met zo’n 2,5 cm per jaar verschuiven ten opzichte van het Europese vasteland. Voor
geodetische locaties (locaties die met een lengte- en breedtegraad worden aangeduid) in Europa zou
referentiesysteem ETRS89 geschikter zijn. Nog handiger zou het zijn om de coördinaten van het nationale
coördinatensysteem, het Rijksdriehoekstelsel, te gebruiken, omdat dat de meter als lengte-eenheid gebruikt,
net als in IFC-bestanden. Over het referentiesysteem voor hoogte zegt IFC2x3 niets. Voor gebouwen in
Nederland is het gebruiken een hoogte ten opzichte van NAP het handigst. Versie 4 van de IFC-specificatie
heeft uitgebreidere mogelijkheden voor georeferentie, onder andere de mogelijkheid een willekeurig
referentiesysteem voor coördinaten te gebruiken.
Op basis van de bevindingen in dit onderzoek wordt aangeraden de locatie van IfcSite zo nauwkeurig mogelijk
op te geven in ETRS89. Mochten coördinaten van een punt op of nabij de bouwlocatie bekend zijn in het
Rijksdriehoekstelsel, dan kunnen die coördinaten nauwkeurig worden omgezet in ETRS896. Verder wordt
aangeraden de hoogte te baseren op NAP. Dit betekent dat de locatie van IfcSite overeenkomstig de
specificatie wordt opgegeven via een lengtegraad en breedtegraad. Toch is er extra informatie nodig om deze
IFC-gegevens correct te kunnen interpreteren:
1. Duidelijk moet zijn dat niet WGS84 maar ETRS89 wordt gebruikt;
2. Duidelijk moet zijn dat de locatie exact, dus geen benadering, is (dat kan bijvoorbeeld worden
gerealiseerd door de ruimtelijke nauwkeurigheid in meters op te geven);
3. Duidelijk moet zijn dat de hoogte ten opzichte van NAP is.
IFC is uitbreidbaar waardoor het mogelijk is deze gegevens aan een IFC-bestand toe te voegen, en af te
spreken hoe die gegevens te herkennen zijn. Een goede beschrijving van het georefereren van een IFC-
bestand is beschreven door Abdoulaye Diakité van de TU Delft7. Het BIM waarop de demonstrator is
gebaseerd is in Revit gegeorefereerd. Mits een nauwkeurige locatie van een gebouw of bouwterrein bekend is
kan georeferentie in Revit als volgt worden samengevat:
1. Zorg dat het Survey Point en het Project Base Point samenvallen met de oorsprong van het interne
coördinatensysteem, bekend als Startup Location of Internal Origin. Normaal gesproken is dat de
uitgangssituatie bij het starten van een nieuw revitproject.
2. Vul de lengtegraad, breedtegraad en hoogte in bij het Survey Point.
3. Vul de oriëntatie ten opzichte van het noorden bij het Project Base Point.
Als dit is gebeurt zullen de coördinaten in het IFC-bestand al correct georiënteerd zijn. Nadat de lengtegraad
en breedtegraad zijn omgerekend naar meters volgens het Rijksdriehoekstelsel kan de lokale oorsprong
worden getransleerd naar het Rijksdriehoekstelsel, door X (de omgerekende lengtegraad), Y (de
omgerekende breedtegraad) en Z (de hoogte in NAP) bij de coördinaten van de geometrie op te tellen. Het
6 Zie: https://www.kadaster.nl/transformatie-van-coordinaten 7 Zie: https://3d.bk.tudelft.nl/pdfs/18_georeferencing.pdf
33
bouwplan is dan direct te combineren met geografische data. Als er een exacte locatie op het bouwterrein
bekend is, en de oriëntatie van het bouwplan is bepaald, is het dus redelijk makkelijk de ruimtelijke gegevens
in een IFC-bestand te georefereren. Dat geldt in ieder geval voor Revit; andere BIM-software is niet getest.
Als een IFC-bestand is voorzien van een georeferentie is het eigenlijk niet meer nodig om expliciete
referenties naar BAG, BRK of andere geodata op te nemen. De gerelateerde gegevens kunnen worden
gevonden op basis van de locatie van het bouwwerk. Gerelateerde panden uit de BAG, of van toepassing
zijnde gebiedsgebonden bepalingen in een bestemmingsplan kunnen worden gevonden op basis van een
punt dat binnen de gebouwomtrek ligt. De gebouwomtrek zelf kan worden gebruikt om bijvoorbeeld
overlappende kadastrale percelen te vinden in de BRK. Het is daarbij niet nodig lokale kopie van BAG, BRK of
ruimtelijke plannen te hebben, want geografische bevragingen zijn ook mogelijk via het dataplatform van het
Kadaster.
Figuur 13 Georeferentie in Revit
Georeferentie maakt het dus niet alleen mogelijk de tweedimensionale of driedimensionale geometrie van een
bouwplan in de geografische context weer te geven, het geeft ook een sleutel tot gerelateerde gegevens die
van belang kunnen zijn voor automatische toetsing. Zo kunnen op basis van locatie bijvoorbeeld de maximale
bouwhoogte of de toegestane gebruiksfunctie van bouwwerken worden uitgelezen uit het vigerende
bestemmingsplan.
5.4 Het toevoegen van extra gegevens aan een IFC-bestand
In de vorige paragraaf werd gemeld dat er aan een IFC-bestand wat extra gegevens moeten worden
toegevoegd om correcte georeferentie mogelijk te maken. Ook voor andersoortige automatische verwerking
van IFC-gegevens kan het nuttig zijn de gegevens die standaard in IFC-data te vinden zijn te verrijken.
34
Hiervoor zijn afspraken nodig over objecttypen, hun eigenschappen en mogelijke waarden. De definities van
de extra parameters kunnen worden gedeeld en worden gestandaardiseerd. IFC kent hiervoor het concept
van property sets (IfcPropertySet). Deze kunnen aan een specifiek objecttype of aan meerdere objecttypen
worden gekoppeld. Property sets kunnen worden gedeeld door gebruik te maken van PSD-bestanden
(Property Set Definitions).
Een basis voor het kunnen definiëren van standaardeigenschappen is een informatiemodel (ontologie). Om
toetsing aan BBL te kunnen ondersteunen is een BBL-ontologie dan ook wenselijk (zie ook paragraaf 5.2). Het
is te overwegen om voor de eigenschappen ook gebruik te maken van de mogelijkheden van Linked Data. Dat
betekent dat in plaats van standaard tekststrings gebruik wordt gemaakt van URI’s. Het Kadaster heeft
ontologieën opgesteld op basis van de informatiemodellen van o.a. BAG, BRK en IMRO (het informatiemodel
voor ruimtelijke plannen).
Voorbeelden van informatie die kunnen worden toegevoerd aan een IFC-bestand zijn:
voor het gebouw (IfcBuilding):
• Categorie (nieuwbouw, bestaande bouw, verbouwing, …)
• Functie (logies, kantoor, bewoning, …)
voor ruimten (IfcSpace):
• Type ruimte (verblijfsruimte, verkeersruimte, badruimte, …)
• Bezetting
• Maximale bezetting
Een uiteindelijke keuze kan worden gebaseerd op welke gegevens in de praktijk vooral van belang zijn voor
toetsing, en welke gegevens goed bruikbaar zijn voor automatisering.
Het voorbeeld BIM is verrijkt met extra informatie in Revit (zie ook Figuur 14). Hiervoor zijn shared parameters
gedefinieerd8. Shared parameters hebben een naam en een datatype en kunnen worden ingedeeld in
groepen. Ze worden vastgelegd in een tekstbestand dat deelbaar is tussen gebruikers. De shared parameters
kunnen worden gekoppeld aan Revit-categorieën, bijvoorbeeld Project information of Room. Die koppeling
kan worden bewaard in een deelbaar sjabloon (Revit project template). Na deze stap komen de parameters
beschikbaar als eigenschappen van geselecteerde Revit-objecten. Om de extra parameters naar IFC te
exporteren moet een koppeling tussen de parameters en IFC PropertySets worden gedefinieerd. Dat gebeurt
via het tekstbestand DefaultUserDefinedParameterSets.txt. Ook dat bestand kan worden gedeeld tussen
gebruikers.
Het principe is alleen met Revit in de praktijk getest, maar het blijkt dus mogelijk te zijn definities van
begrippen online te delen en die dan op een standaardmanier toe te passen in een BIM en op een
8 Zie: https://knowledge.autodesk.com/support/revit-products/learn-explore/caas/simplecontent/content/shared-vs-project-parameter-use-revit.html
35
standaardmanier te exporteren naar IFC. Alle daarvoor benodigde bestanden kunnen voor vrij gebruik ter
beschikking worden gesteld door een coördinerende instantie.
In het onderzoek zijn eigenschappen toegekend aan het bouwwerk en aan ruimtes binnen het bouwwerk. In
Revit is een ruimte een room of een space. Er zijn standaardeigenschappen beschikbaar voor een ruimte in
Revit9. De eigenschap “occupancy” is hierin reeds gedefinieerd, maar komt niet overeen met de door ons
gewenste betekenis: het aantal personen dat de ruimte bezet. Hiervoor moet een nieuwe eigenschap worden
gemaakt. Het is in Revit mogelijk eigenschappen te hebben waarvan de waarde (het datatype) een URI is. Dit
kunnen we gebruiken als we bijvoorbeeld verwijzingen naar een eigen BBL-ontologie willen aanbrengen. Zo
zouden we als eigenschap van een ruimte een type eigenschap ‘type’ kunnen toevoegen die bijvoorbeeld de
volgende waarde heeft: “https://data.labs.pdok.nl/data/bbl/bbl#Verblijfsruimte”. Een room in Revit heeft
standaard geen eigenschap die lijkt op deze eigenschap (type ruimte). In het voorbeeld BIM zijn de
eigenschappen “OccupancyNumber” en “Occupancy Peak Number” toegevoegd op basis van de BBL-
ontologie.
Figuur 14 Shared parameters
9 Zie: https://knowledge.autodesk.com/support/revit-products/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Revit-Model/files/GUID-21326970-0037-41C6-A996-980C24EE019F-htm.html
36
5.5 Extractie van gegevens uit een IFC-bestand
Er zijn verschillende gratis beschikbare hulpmiddelen om de gegevens in een IFC-bestand visueel te
inspecteren. Voorbeelden zijn de Solibri Model Viewer en BIMVision. Voor geautomatiseerde toetsing zijn
echter de ruwe data benodigd, op een manier die begrijpelijk is voor het toetsingssysteem. Binnen het
bouwdomein zijn er al voorzieningen om bouwplannen te controleren. Via bijvoorbeeld Solibri Model Checker
kunnen regels waaraan een bouwwerk moet voldoen worden gespecificeerd en worden toegepast op een
IFC-bestand. In het kader van dit project is nagegaan welke mogelijkheden er zijn om van een IFC-bestand
meer algemeen verwerkbare gegevens te maken.
Er zijn verschillende hulpmiddelen beschikbaar waarmee IFC-bestanden kunnen worden omgezet naar
andere formaten, zoals naar RDF. In het onderzoek is onder meer gekeken naar:
• On-line IFC-SPF converter10: RDF;
• IFCtoRDF-Desktop11: RDF (IfcOWL);
• IfcOpenShell12: programmatisch (C++ of Python) lezen en schrijven van IFC-bestanden;
• IfcConvert13: (extractie van (alleen) geometrie naar diverse grafische formaten (o.a. obj, collada, SVG
(alleen 2D-plattegrond);
• FME: allerlei GIS-formaten, bijvoorbeeld PostGIS of CityGML.
Een aantal andere hulpmiddelen bleken niet goed werkend te krijgen. De on-line IFC-SPF converter publiceert
het geconverteerde bestand op een publieke website en is daarmee in veel gevallen niet geschikt. Om
praktische redenen is er gekozen om gebruik te maken van FME voor het extraheren van de geometrie en
andere informatie uit het voorbeeldbestand. FME is in tegenstelling tot de overige tools niet gratis. Het biedt
wel goede functionaliteiten om IFC-bestanden om te zetten in andere gewenste formaten. Met name
transformatie van geometrie, een lastig onderdeel van IFC-data, blijkt door FME goed uitvoerbaar te zijn. Meer
achtergrond over de verschillen tussen geometrie in IFC en in GIS is te vinden in diverse publicaties van de
TU Delft (zie bijvoorbeeld [14]).
De geëxtraheerde gegevens zijn voor het onderzoek opgeslagen in een PostGIS-database zodat daar
eenvoudig zoekvragen aan konden worden gesteld. Zo is bijvoorbeeld de omtrek van het voorbeeldbouwwerk
bepaald door de vloerplaten (IfcSlab) plat te slaan en te combineren. Het resultaat is weergegeven in Figuur
15. Het is mogelijk om meer soorten IFC-elementen mee te nemen om een rijker bovenaanzicht te verkrijgen.
Op soortgelijke wijze kan ook een voetafdruk op maaiveldniveau worden bepaald. Hiervoor dient te worden
bepaald welke IFC elementen zich op maaiveldniveau bevinden. De geometrie van die elementen kan dan
worden gebruikt om de gewenste contour te bepalen.
10 Zie: http://openbimstandards.org/standards/ifcowl/where-can-i-convert-my-ifc-files-to-rdf-graphs 11 Zie: https://github.com/jyrkioraskari/IFCtoRDF-Desktop 12 Zie: http://ifcopenshell.org/ 13 Zie: http://ifcopenshell.org/ifcconvert.html):
37
Figuur 15 Bovenaanzicht uit IFC-bestand
Een uit een IFC-bestand afgeleide geometrie kan worden gebruikt om bestaande registraties bij te werken. De
tweedimensionale omtrek van een gebouw zou bijvoorbeeld aan de BAG kunnen worden toegevoegd. Een
versimpelde driedimensionale omhullende geometrie zou kunnen worden gebruikt in een 3D stadsmodel bij te
werken. De gegevens kunnen ook voor toetsing van een bouwplan worden gebruikt. Zo zou de maximale z-
coördinaat van de bouwwerkgeometrie kunnen worden vergeleken met de maximale bouwhoogte uit een
bestemmingsplan. Zo’n controle is volledig te automatiseren. Diverse regels uit het BBL zijn zo ook te
automatiseren. De demonstrator laat het voorbeeld zien van een controle op voldoende toiletruimten.
Wanneer van ruimtes bekend is of ze een toiletruimte zijn, en wat de bezetting is, is voor een gebouw uit te
rekenen hoeveel mensen een toiletvoorziening moeten delen (volgens het BBL mogen dat er maximaal 30
zijn).
5.6 Viewer
Er is een viewer ontwikkeld om de resultaten van de voorgaande stappen te visualiseren (zie
http://data.labs.pdok.nl/apps/bimdemo). De viewer is een webpagina die is samengesteld uit gegevens die het
resultaat zijn van bevragingen van de PostGIS database. Voor de geometrie is daarbij gebruik gemaakt van
de ondersteuning van het X3D-formaat. De resulterende viewer bestaat daarmee uit een zelfstandig HTML-
bestand. In de viewer kan zowel 2D als 3D gekeken worden naar het voorbeeldbouwwerk uit het IFC-bestand.
Zichtbaar in eerste instantie zijn de vloerplaten en ruimten van het bouwwerk. Aan de rechterkant worden
eigenschappen van het bouwwerk weergegeven. Deze zijn onder meer resultaat van de verrijking zoals
aangebracht in Revit. Zo is onder meer zichtbaar dat er een georeferentie aanwezig is in het IfcSite object, dat
er referenties naar BAG en BRK zijn opgenomen bij de IfcBuilding en dat er BBL-specifieke eigenschappen
zijn toegevoegd.
38
Figuur 16 Viewer
Voor een RO-toets is een confrontatie van de contouren van het bouwwerk met de contouren uit ruimtelijke
plannen en de kadastrale registratie relevant. In de ontwikkelde viewer zijn deze contouren voor de locatie van
het voorbeeldbouwwerk zichtbaar gemaakt. Deze zijn op handmatige wijze verkregen uit de relevante
administraties. Figuur 17 geeft het resultaat weer. De contour van het bouwwerk is weergegeven in het rood.
In geel is het kadastrale perceel weergeven. Verder zijn de enkelbestemming (blauw) en maatvoering (oranje)
uit het geldige bestemmingsplan gevisualiseerd. Op deze manier is snel zichtbaar hoe het pand zich verhoudt
tot de genoemde contouren.
Figuur 17 Contour van het bouwwerk geconfronteerd met bestemmingsplan en perceel
39
6 Conclusies en aanbevelingen
Dit hoofdstuk beschrijft de belangrijkste conclusies en aanbevelingen die voortvloeien uit eerdere
hoofdstukken. Het start met conclusies m.b.t. de kernvragen voor deze pilot. Vervolgens worden de
belangrijkste uitdagingen en oplossingsrichtingen beschreven. Deze oplossingsrichtinigen worden verder
uitgewerkt in aanbevelingen. Deze aanbevelingen zijn geclusterd naar de doelgroepen die het primair
aangaat: een brede doelgroep, gemeenten (en ander bevoegd gezag) en partijen in de bouwsector. Voor de
aanbevelingen in de eerste categorie is het niet direct evident wie deze dient op te pakken. In het algemeen is
samenwerking tussen overheid en partijen in de bouwsector belangrijk omdat belangen door de gehele keten
heen werken. Ook in deze pilot was het een grote meerwaarde om met alle partijen aan één tafel te zitten en
meer te leren van elkaars belangen en prioriteiten.
6.1 Antwoorden op kernvragen
In deze paragraaf geven we een aantal belangrijke conclusies over het uitgevoerd onderzoek op basis van de
kernvragen zoals deze voor de pilot waren gedefinieerd.
Is informatie die nodig is om een aanvraag te beoordelen (met name voldoen aan Besluit Bouwwerken
Leefomgeving/Bouwbesluit) aanwezig in een IFC-bestand?
Het antwoord op deze vraag is: Nee. Veel van de informatie die nodig is voor BBL is niet standaard aanwezig
in IFC-bestanden. Er zijn ook geen afspraken over welke informatie dit precies betreft en ook niet over de
wijze waarop ze op een standaard manier in een IFC dienen te worden opgenomen. Er wordt op dit moment
wel gewerkt aan een gegevensbehoeftelijst vanuit de bouwsector waarin een deel van de informatiebehoefte
wordt meegenomen. Een andersoortige complicatie is dat er op dit moment geen standaard afspraken zijn
gemaakt over hoe om te gaan met het uitdrukken van hoogte van gebieden in bestemmingsplannen.
Dergelijke informatie is wel nodig om een RO-toets op maximale bouwhoogte goed te kunnen uitvoeren.
Initiatiefnemers hebben hierbij aangegeven dat het versnellen van het vergunningverleningsproces een
belangrijke drijfveer zou zijn om meer informatie in een IFC-bestand op te nemen.
Is het mogelijk om op geautomatiseerde wijze de relevante delen van de geometrie van een bouwwerk
te extraheren uit een IBIM/FC bestand? Wat zijn de randvoorwaarden?
Het antwoord op deze vraag is: Ja. Dit komt omdat voor BAG en BGT slechts een subset van de geometrie
van een bouwwerk relevant is (bovenaanzicht, voetafdruk). Op basis van standaard geo-functies kunnen deze
contouren relatief eenvoudig worden geëxtraheerd uit de geometrie uit een IFC-bestand. Randvoorwaarde
daarbij is wel dat een IFC-bestand geo-gerefereerd is. In meer algemene zin is een volledige vertaling van de
geometrie in IFC-bestand naar GIS zonder informatieverlies niet mogelijk [14]. Hiervoor zijn de verschillen
tussen beide soorten geometrie te verschillend.
Is informatie die nodig is om de informatie over een bouwwerk te verwerken in relevante
administraties (zoals BAG) aanwezig in een IFC-bestand?
40
Het antwoord op deze vraag is: Ja. Informatie die relevant is op het moment van vergunningaanvraag is
(grotendeels) aanwezig of kan worden afgeleid uit de informatie in het IFC-bestand. Het betreft met name
(delen van) de geometrie van het bouwwerk en informatie over vloeroppervlaktes. Een voorwaarde is dat het
IFC-bestand gegeorefereerd is, of eenduidig te georefereren is.
6.2 Uitdagingen en oplossingsrichtingen
De volgende tabel geeft een overzicht van de belangrijkste uitdagingen en oplossingsrichtingen bij het streven
naar een geautomatiseerde beoordeling en verwerking van IFC-bestanden.
Uitdaging Oplossingsrichtingen
Beperkte standaardisatie van
IFC
• Alleen gebruik maken van een subset van gegevens die typisch wel
aanwezig is
• Gebruiken van BIM basis ILS en gegevensbehoeftelijst (in
ontwikkeling) bij IFC modellen
• Verdere standaardisatie van IFC in de bouwsector
Fundamentele verschillen
tussen IFC en GIS datasets
• Focus leggen op relevante informatie voor het gebruik, bijv. subset van
geometrie
• Georefereren van IFC bestanden
• Afspraken maken over het definiëren van hoogte van
werkingsgebieden in omgevingsplannen
Nog geen gemeenschappelijk
inzicht in gemeentelijke
informatiebehoefte
• Verrijken van IFC-bestanden met informatie zoals beschreven in
conceptueel model BBL
• Ontwikkelen van een gemeentelijke informatie levering specificatie
(ILS)
Geen volledig eenduidige
interpretatie van begrippen en
regels in BBL (en andere
regelgeving)
• Alleen een subset van de regels omzetten in geautomatiseerde regels
• Bij ontwikkeling van nieuwe regelgeving nadrukkelijk rekening houden
met automatisering
• Ontwikkelen van een thesaurus en ontologie voor BBL (o.b.v.
conceptueel model)
Relatief grote investering
nodig om BBL toets te
automatiseren
• Focus op regels met veel toegevoegde waarde en relatief beperkte
inspanning – m.n. gerelateerd aan zaken die afgeleid kunnen worden
uit bouwwerkgeometrie zoals afmetingen, volumes en oppervlakten
• Collectieve voorzieningen ontwikkelen
Onduidelijkheid over de impact
van de Wet kwaliteitsborging
voor het bouwen
• Gemeenten voor toetsing focus laten leggen op aspecten die duidelijk
tot hun eigen verantwoordelijkheid behoren, zoals RO
Beperkt bewustzijn bij
gemeenten over kansen van
BIM
• Ontwikkelen kennis en beleid over BIM en relatie met
vergunningverlening
• Beschikbaar stellen tools aan medewerkers van de gemeente
Bouwwerk “as-planned” wijkt
af van bouwwerk “as-built”
• Delen informatie over bouwwerk “as-built” alsook aanpassingen die op
een later moment ontstaan
• Ontwikkelen van een landelijk bouwwerkdossier
41
Geautomatiseerde beoordeling
kan tot verkeerd antwoord
leiden
• Gebruikte regels bijvoegen bij besluiten
• Maatwerk en "menselijke" heroverweging in de bezwaarfase
bevorderen
Tabel 5 Uitdagingen en oplossingsrichtingen voor geautomatiseerde beoordeling en verwerking
6.3 Aanbevelingen algemeen – brede doelgroep
• Ontwikkel een gemeentelijke ILS: Op dit moment zijn IFC-bestanden niet specifiek afgestemd op de
gemeentelijke informatiebehoefte, zoals die voor vergunningverlening. Er zijn landelijke afspraken en
standaarden nodig om te zorgen dat gemeenten op een standaard manier informatie uit een IFC-bestand
kan halen. Een gemeentelijke Informatie Leverings Specificatie beschrijft welke informatie een gemeente
nodig heeft m.b.t. een bouwwerk. Het is een verdieping van de bestaande BIM basis ILS en kan
voortborduren op de in dit rapport gepresenteerde informatie, de nog in ontwikkeling zijnde
gegevensbehoeftelijst, maar bijvoorbeeld ook de RVB BIM Norm [3]. Deze laatste stelt bijvoorbeeld ook al
dat informatie aanwezig moet zijn over de geo-locatie, kadastrale aanduidingen en specifieke
BBL/Bouwbesluit gerelateerde informatie zoals gebruiksfuncties, vluchtroutes, brandcompartimenten,
brandveiligheidsvoorzieningen en maximaal aantal personen in een ruimte.
• Ontwikkel een thesaurus en ontologie voor BBL: Begrippen zijn in het BBL slechts beperkt
gedefinieerd; van veel termen is ook geen definitie aanwezig. Er is in deze pilot een eerste aanzet
gegeven tot een ontologie voor BBL; een semantische specificatie die de concepten in BBL eenduidig
interpreteerbaar makt. Het is de basis voor verdere geautomatiseerde verwerking en noodzakelijk bij
gebuik van standaarden op het gebied van het semantische web (Linked Data). Een dergelijke ontologie
is gebaseerd op semantische web standaarden zoals SKOS, RDFS, OWL en SHACL. De basis voor een
ontologie is een thesaurus die de begrippen zelf en hun belangrijkste relaties definieert. Het definiëren
van een BBL thesaurus is daarmee een eerste logische stap. De aanzet die in dit document is gegeven
dient daarvoor verder te worden uitgewerkt voor alle informatie in het BBL. Onderdeel hiervan is het
leggen van een eenduidige relatie naar IFC. Voor IFC zelf is er inmiddels al een ontologie gedefinieerd
(IfcOWL).
• Borg gebruik BIM/IFC in regelgeving: op dit moment heeft het gebruik van een IFC-bestand in de
context van een vergunningaanvraag geen formele juridische status en wordt het ook niet gestimuleerd.
Het zou helpen als dat wel het geval zou zijn. Dat zou voor veel organisaties een drijfveer zijn om er mee
aan de slag te gaan.
• Maak regelgeving eenduidig interpreteerbaar: een geautomatiseerde toetsing van regelgeving is
alleen haalbaar als de concepten en regels eenduidig interpreteerbaar zijn. Op dit moment zitten er in
BBL aspecten die dit niet volledig mogelijk maken; zij vragen menselijke interpretatie (zie onder meer [6]).
Mogelijk kan een toekomstige versie van BBL verder worden aangescherpt. Bij toekomstige regelgeving
kan hier in eider geval rekening worden gehouden. Idealiter gaat regelgeving vergezeld van een
conceptueel informatiemodel (begripsdefinities) en een set geautomatiseerd uit te voeren regels. De
Raad van State adviseert ook om ontwikkeling van wetgeving en ICT hand in hand te laten gaan [15]. Zij
stelt multi-disciplinaire samenwerking van juridische, beleidsmatige, financiële en ICT-discplines voor.
• Ontwikkel generieke toetsvoorzieningen: Om geautomatiseerde BBL- en RO-toetsing mogelijk te
maken zal geïnvesteerd moeten worden in informatievoorziening. Bij voorkeur worden hiervoor generieke
voorzieningen ontwikkeld, omdat deze breed toepasbaar zijn. RO-toetsing is eenvoudiger te realiseren
42
dan (volledige) BBL-toetsing en ligt daarmee meer voor de hand. Ook met BBL-toetsing kunnen stappen
worden gezet. Een logische eerste stap daarin lijkt te zitten in toetsing op geometrische aspecten zoals
afmetingen, volumes en oppervlaktes (en totalen daarvan). Deze informatie is in alle IFC-bestanden in
ieder geval aanwezig of kan daar eenvoudig uit worden afgeleid (berekend). Het bespaart al direct veel
handmatige beoordeling.
• Deel actuele informatie over bouwwerken: Een bouwwerk zoals daadwerkelijk gerealiseerd zal altijd in
enige mate afwijken van het bouwwerk zoals gepland. Er zijn allerlei partijen (zoals gemeenten) die
geïnteresseerd in de volledige levenscyclus van een bouwwerk en informatie over meest actuele toestand
van het bouwwerk willen hebben. Dat is minimaal informatie over het daadwerkelijk gerealiseerde
bouwwerk (as-built). Het delen/beschikbaar stellen van dergelijke informatie in de keten is daarom
wenselijk. Ultiem is dergelijke informatie vindbaar via een landelijk bouwwerkdossier.
• Ontwikkel een generiek model voor geometrie: Er zijn op dit moment inherente verschillen tussen
geometrie in IFC en GIS. In ander informatiedomeinen, zoals transport en 3D-visualisatie, worden weer
andere manieren gebruikt om geometrie vast te leggen. Het is wenselijk een generiek onderliggend
model te definiëren, waardoor een gemeenschappelijke geometrische basis ontstaat en vertalingen
zonder betekenisverlies kunnen plaatsvinden. Dit is iets dat eigenlijk wereldwijd opgepakt zou moeten
worden, bijvoorbeeld vanuit het W3C.
6.4 Aanbevelingen gemeenten
• Stimuleer aanlevering van IFC-bestanden: Er is landelijk geen afspraak over de wijze waarop
eventueel aangeleverde IFC-bestanden moeten worden behandeld. Het is daarmee aan gemeentes zelf
om hier verder beleid op te formuleren. Gegeven de kansen voor procesoptimalisatie denken we dat een
dergelijk beleid aanlevering van dergelijke bestanden zou moeten stimuleren. Het verkorten van de
doorlooptijd van vergunningaanvragen lijkt een brede behoefte. Daarnaast is communicatie over dit beleid
naar initiatiefnemers belangrijk om te zorgen dat ze informatie ook daadwerkelijk in IFC zullen
aanleveren.
• Ontwikkel kennis m.b.t. IFC: Om beleid m.b.t. IFC goed te kunnen definiëren en uitvoeren is het
randvoorwaardelijk dat voldoende kennis van IFC aanwezig is, zowel op beleidsniveau als op het gebied
van inrichting van informatievoorziening. Op dit moment is dergelijke kennis nog heel beperkt aanwezig,
met name bij kleinere gemeenten.
• Stel IFC tools beschikbaar: Om IFC-bestanden te kunnen verwerken zijn tools nodig. Minimaal betreft
dit tools voor het kunnen bekijken van IFC-bestanden (BIM viewers). Er zijn gratis tools beschikbaar,
maar deze dienen wel aan medewerkers ter beschikking worden gesteld en ondersteuning daarbij is
wenselijk. Denk onder meer aan beschikbaarheid van werkinstructies en ondersteuning (functioneel
beheer).
• Bescherm de burger bij geautomatiseerde beoordeling: De Raad van State heeft recent advies
gegeven om de rechten van burgers te beschermen bij geautomatiseerde beoordeling. Onderdeel hiervan
is onder meer om bij besluiten expliciet de gehanteerde beslisregels te vermelden. Overigens geldt een
verplichting voor het expliciet documenteren van beslisregels voor geautomatiseerde beoordeling ook
reeds vanuit de Algemene Verordening Gegevensbescherming. Daarnaast adviseert de Raad om
maatwerk en "menselijke" heroverweging in de bezwaarfase van geautomatiseerd tot stand gekomen
besluiten te bevorderen.
43
• Standaardiseer hoogte in omgevingsplannen: Er zijn nu geen standaard afspraken over het uitdrukken
van de hoogte van gebieden in bestemmingsplannen. Het zou goed zijn als hier standaard afspraken
over gemaakt worden in de context van de Omgevingswet. Anders is het niet mogelijk om een hoogte-
toetsing van (de geometrie van) een bouwwerk in een IFC-bestand uit te drukken. Een mogelijke afspraak
daarvoor is het gebruik van NAP.
6.5 Aanbevelingen bouwsector
• Gebruik BIM basis ILS: Er zijn in IFC veel vrijheidsgraden en mogelijkheden om bepaalde informatie
vast te leggen. Standaardisatie is randvoorwaardelijk om automatisering te laten werken. De BIM basis
ILS [2] beschrijft een aantal basisafspraken over hoe informatie in IFC vastgelegd zou moeten worden.
Het gebruik hiervan zou een standaard onderdeel moeten zijn van het opstellen van een IFC-bestand.
• Gebruik open geografische datasets: Er is allerlei informatie over de leefomgeving relevant bij het
ontwerpen van bouwwerken. Veel van dit soort informatie is beschikbaar als open data. Zo zijn onder
meer de geografische basisregistraties BRT, BGT en BAG beschikbaar als open data en in verschillende
vormen en formaten af te nemen. Een belangrijke vindplaats voor geo-informatie is de website van
Publieke Dienstverlening op de Kaart (PDOK) en het bijbehorende Nationaal Georegister (NGR).
• Houd rekening met BBL in IFC: Totdat er een landelijke gemeentelijke ILS is gedefinieerd kunnen
individuele partijen in de bouwsector bij het opstellen van IFC-bestanden al wel zelf proberen maximaal
rekening te houden met de vanuit BBL gewenste informatie. In dit document is een aanzet gegeven tot
een conceptueel model dat een indruk geeft van het soort informatie die het betreft.
• Georefereer IFC-bestanden: Op dit moment bevatten IFC-bestanden veelal geen georeferentie. Zonder
een dergelijke verwijzing naar de geo-locatie is het niet mogelijk om geometrische informatie in een IFC-
bestand betekenisvol te integreren in een GIS omgeving. De stappen die nodig zijn voor georeferentie
zijn relatief uitgebreid, dus het beschikbaar stellen van een goede werkinstructie aan de mensen die dat
moeten doen is een belangrijke succesfactor. Overigens kan een georeferentie voor de bouwsector zelf
ook op specifieke momenten onhandig zijn, omdat bepaalde partijen niet met een dergelijk IFC-bestand
om kunnen gaan. Er zullen dus waarschijnlijk meerdere IFC-bestanden nodig zijn; een geo-gerefereerd
(overkoepelend) IFC-bestand voor BIM-GIS integratie en (onderliggende) ongerefereerde IFC-bestanden
voor gebruik door bouwpartijen zelf.
• Houdt rekening met (verschillen in) nauwkeurigheid: Geometrische informatie in zowel BIM als GIS
heeft inherent een bepaalde nauwkeurigheid. Voor de landelijke geo-basisregistraties (BAG, BGT, BRT)
zijn deze ook onderdeel van de standaarden en bijbehorende documentatie. Voor kadastrale informatie
geldt dat de publiek beschikbare geometrische informatie ook een andere nauwkeurigheid kent dan de
veldwerken die eraan ten grondslag liggen [18]. BIM werkt inherent met een hogere nauwkeurigheid,
waardoor er snel een mismatch of misverstand kan ontstaan over de relatie met de geomatrische
informatie uit GIS datasets. Bewustzijn van de nauwkeurigheid van de gebruikte GIS informatie bij alle
gebruikersgroepen is daarom essentieel.
• Definieer bronnen voor informatie: Het is niet logisch om alle informatie die gerelateerd is aan een
bouwwerk ook op te nemen in het IFC-bestand. Informatie moet worden onderhouden in de bron, zodat
er altijd een actueel beeld bestaat van de beschikbare informatie. Een verwijzing naar relevante
informatie vanuit een IFC is veelal logischer. Voor meer stabiele gegevens kan het acceptabel zijn om
een kopie op te nemen, maar dat zou een weloverwogen keuze moeten zijn. Voor het verwijzen naar
44
andere bronnen is het gebruik van Linked Data verwijzingen (URI’s) logisch, zeker als de bron ook als
Linked Data beschikbaar is. Dit soort informatie is typisch onderdeel van een informatie-architectuur. Het
opstellen van een dergelijke informatie-architectuur is dus gewenst.
45
Bijlage 1: Bronnen
Referentie Document
1 “ISO 16739:2013 - Industry Foundation Classes (IFC) for data sharing in the construction
and facility management industries”, ISO, april 2013.
2 “BIM basis Informatie Leverings Specificatie”, versie 1.0, BIM loket, 2016.
3 “RVB BIM Norm”, versie 1.1, Rijksvastgoedbedrijf, 1 februari 2013.
4 Tim Dijkmans en Léon van Berlo: “3D bestemmingsplannen & BIM: Showcase van
beschikbare 3D technologie ten behoeve van digitaal toetsen”, TNO-rapport TNO 2013
R10944, 19 juni 2013.
5 L.A.H.M. van Berlo, F. Bomhof en G. Korpershoek: “Creating the Dutch National BIM
Levels of Development (extended)” in Proceedings of the 2014 International Conference on
Computing in Civil and Building Engineering, 129-136, 2014.
6 Miquel Marzabal Galano: “WeBouwbesluit - 10 sections of the Dutch Building Decree
2012”, InHolland, 19 mei 2014.
7 “Esri and Autodesk— What’s Next?”, ESRI en Autodesk vision paper, februari 2018.
8 “Oppervlakte Verdiepingsdocument voor gemeenten - Mogelijkheden om in de
implementatiefase BAG de oppervlakte van verblijfsobjecten te bepalen”, versie 2.0,
Ministerie van VROM, december 2007.
9 “Informatie BAG-WOZ - Oppervlakte en inhoud”, Ministerie van VROM en de
Waarderingskamer, juli 2009.
10 Abdoulaye Diakité, Thomas Krijnen, Hugo Ledoux, Ken Arroyo Ohori, Friso Penninga en
Jantien Stoter: “BIM-GIS data integratie: makkelijker gezegd dan gedaan?”, GIS magazine,
jaargang 16, april/mei 2018.
11 Abdoulaye Diakité en Jantien Stoter: “Eindrapport scoping studie voor integratie
geotop en bim: Als input voor de ontwikkeling van basis registratie ondergrond”, Technical
report, Delft University of Technology, juni 2017.
12 Abdoulaye Diakité: “About the Georeferencing of BIM models”, Delft University of
Technology, 2018.
13 Sjors Donkers, Hugo Ledoux, Junqiao Zhao and Jantien Stoter: “Automatic conversion of
IFC datasets to geometrically and semantically correct CityGML LOD3 buildings”,
Transactions in GIS 20(4), pp. 547–569, 2016.
14 Ken Arroyo Ohori, Abdoulaye Diakité, Thomas Krijnen, Hugo Ledoux and Jantien Stoter:
“Processing BIM and GIS Models in Practice: Experiences and Recommendations from a
GeoBIM Project in The Netherlands”, International Journal of Geo-Information, 2 augustus
2018.
15 “Advies W04.18.0230/I”, in Staatscourant 2018, nr. 50999, Raad van State, 31 augustus
2018.
16 Per-Ola Olsson, Josefine Axelsson, Martin Hooper and Lars Harrie: “Automation of Building
Permission by Integration of BIM and Geospatial Data”, International Journal of Geo-
Information, 31 July 2018.
17 Jennifer Oldfield, Ronald Bergs, Peter van Oosterom, Thomas F. Krijnen and Miquel
Marzabal Galano: “3D Cadastral Lifecycle: An Information Delivery Manual ISO 29481 for
3D Data Extraction from the Building Permit Application Process”, 7th International FIG
Workshop on the Land Administration Domain Model, Zagreb, Croatia, 11-13 April 2018,
18 Pieter Soffers, Eric Hagemans: “Semantically Enriching and Reconstructing the Cadastral
Map of the Netherlands – An LADM Approach”, 7th International FIG Workshop on the
Land Administration Domain Model, 11-13 April 2018, Zagreb, Croatia
46
Bijlage 2: Deelnemerlijst
De volgende deelnemers zijn aanwezig geweest op één of meer werksessies in de context van de pilot:
• Edward de Wit, Gemeente Den Haag
• Sander de Zee, Dura Vermeer
• Dik Spekkink, BIM loket
• Jantien Stoter, TU Delft/Geonovum/Kadaster
• Michel Bohms, TNO
• Jeroen Lange, Studioschaeffer B.V.
• Timo Erinkveld, Gemeente Rotterdam
• Henny Stolwijk, Gemeente Rotterdam
• Eric Houtman, Interconcept
• Gerry de Koning, Gemeente Almere
• Gerjan Kwakernaak, Dura Vermeer
• Sanne Douma, Royal HaskoningDHV
• Simon Bos, Royal HaskoningDHV
• Emil Otte, Gemeente Almere
