Thema Totaal 3D/T3D Pilots/Den Haag/Inwinning/Bestandsformaten
Inhoud
Bestandsformaten[bewerken]
De onderzochte bestandsformaten worden in hier kort beschreven. Als achtergrond is het goed om te weten dat in Den Haag een Use case binnenkant gebouwen is gebruikt, en dat speciaal daarvoor bepaalde bestandsformaten zijn onderzocht.
BIM modellen[bewerken]
BIM modellen zijn de meest voor de hand liggende input voor een 3D object registratie. Een BIM model is 3D vector data, en als het op de juiste geografische positie is geplaatst, dan is het met ETL tooling te transformeren naar elk gewenst ander formaat. Er zijn wel een aantal aandachtspunten:
- Er moet een goede ILS zijn met welke lagen er in een BIM model moeten zitten. Een BIM model kan ongelofelijk veel detail bevatten (alle moertjes en schroefjes van een brug), en die heb je in een 3D registratie niet allemaal nodig. Tegelijkertijd kunnen er ook relevante delen missen.
- BIM modellen worden vooral veel in de bouw gebruikt, en ze beschrijven dan ook alleen wat er gebouwd wordt. Dus er is wel een BIM model van een gebouw, maar niet van de omgeving daarvan. Of er is juist een BIM model van een stuk snelweg, maar niet van de gebouwen daaromheen.
- BIM modellen worden over het algemeen in de bouw gebruikt als ontwerp document, en een BIM model maken zonder dat er iets gebouwd wordt (dus alleen om gegevens in te winnen) zal niet snel gebeuren, om dat het een behoorlijk arbeidsintensief proces is.
Tijdens T3D is een ETL tool gemaakt om BIM modellen om te zetten naar CityGML. Dat is gelukt, en de CityGML bestanden kunnen dan verder in het proces gebruikt worden.
In het project is ook een pilot gedaan om een ILS op te stellen voor BIM modellen om het proces van huisnummerbesluiten te ondersteunen. Met een goed BIM model kunnen de randvoorwaarden om een huisnummer uit te geven veel sneller worden gecontroleerd. Het is gelukt om deze ILS aan te maken (hieronder een voorbeeld, waarbij de groene delen voor huisnummerbesluiten noodzakelijk zijn). Op dit moment zal het lastig zijn om die ILS ook te verplichten, maar voor de toekomst is het wel haalbaar om op basis van een aantal bedrijfsprocessen van gemeenten een ILS op te stellen die veel van deze processen ondersteunt, en daarover in overleg te gaan met de bouwwereld. Voor de huisnummerbesluiten is het bekijken van het BIM bestand in een viewer genoeg. Verwerking in een 3D object registratie is niet noodzakelijk. De bestanden moeten wel terug te vinden zijn via een logische koppeling.
De bouwwereld gebruikt op dit moment zelf ook al standaarden, waardoor veel van wat er in de gewenste ILS zit, nu ook al geleverd wordt. Echter, voor veel architectenbureau's bijvoorbeeld is dit nog best een uitdaging. Daarom kan een ILS die door gemeente samen wordt opgesteld wellicht eenvoudiger landen, dan dat elke gemeente apart een ILS gaat opstellen.
Lidar bestanden[bewerken]
In het project is ook gekeken naar de bruikbaarheid van Lidar bestanden, en dan vooral van Lidar bestanden voor de binnenkant van gebouwen. Er zijn verschillende manieren beproefd om deze in te winnen.
- Het meest eenvoudige is om met een app op een telefoon rond te lopen in een huis en opnamen te maken. Er zijn apps beschikbaar die dat behoorlijk goed kunnen omzetten in een puntenwolk. Het is gebleken dat dit nuttige informatie is, maar dat de nauwkeurigheid niet heel hoog is. Dat betekent dat deze bestanden bijvoorbeeld prima gebruikt kunnen worden ter controle (is er gebouwd wat in het BIM model is ontworpen?), maar niet als basis voor een 3D object registratie. Zowel nauwkeurigheid (in coordinaten), als objectherkenning moet daarvoor nog verbeteren.
- Om meer nauwkeurige resultaten te halen is ook gekeken om met een meer professionele data gegevens te scannen. Dit levert meer nauwkeurige resultaten op, maar beeldherkenning blijft een issue.
De conclusies zijn op dit moment dat beeldmateriaal nuttig is ter ondersteuning, maar niet geheel geschikt voor het bijhouden van een 3D object registratie. In de pagina over het samenstellen van data wordt ook nog gekeken naar het omzetten van beeldmateriaal naar CityGML. Zie daarvoor Thema Totaal 3D/T3D Pilots/Den Haag/Samenstellen
CityJSON/CityGML[bewerken]
Het verwarrende van CityGML is dat het zowel een informatiemodel is als een uitwisselbestand. In dit hoofdstuk gaat het over het uitwisselbestand. CityJSON is een bestandstype data dezelfde informatie kan bevatten als een CityGML, maar dan in een ander formaat (JSON wordt door veel ontwikkelaars als prettiger ervaren dan GML). Het aantal bronnen wat dit formaat kan aanleveren is vermoedelijk zeer beperkt, maar in Amsterdam is voor het aanvragen van vergunningen wel gewerkt met CityJSON, dus het is mogelijk. Deze bestanden zijn zeer bruikbaar, omdat ze 3D gegeven bevatten volgens een GIS informatiemodel, en dus niet, zoals bij BIM, volgens een meer CAD-achtig informatiemodel. Het omzetten van deze formaten in een database is daarom relatief eenvoudig. De formaten zijn tegelijkertijd nog wel in ontwikkeling. Tijdens het project is versie 3.0 van CityGML ontwikkeld, en dat zal vermoedelijk ook niet de laatste versie zijn, en CityJSON, ontwikkeld door de TU Delft, wordt steeds meer gebruikt, maar is nog geen officiele standaard.
Luchtfoto's[bewerken]
In het T3D programma zijn deze niet als basis gebruikt. In Den Haag wordt wel gewerkt met luchtfoto's voor het 3D stadsmodel. Deze worden ingewonnen (met hoge nauwkeurigheid), en vervolgens in een "tekenfabriek" via een derde partij verwerkt tot een database in het CityGML informatiemodel. Daarnaast bieden GIS leveranciers ook steeds meer tooling op basis van luchtfoto's (vaak true ortho en obliek gecombineerd), waardoor luchtfoto's voor veel bedrijfsprocessen een zeer nuttige rol kunnen spelen.
PDF/2D CAD[bewerken]
Formaten als PDF, CAD bestanden zijn niet beproefd als invoer voor een 3D object registratie beheer proces. Logischerwijs kunnen deze wel informatie geven over (op handen zijnde) wijzigingen, en soms ook wel over 3D gegevens, maar er is niet naar gekeken
Overige 3D gegevens[bewerken]
Er zijn al registraties die 3D gegevens bijhouden. In het programma is hiervoor gekeken naar gegevens die RIONED beheert voor rioleringen. De vraag is of de wijze waarop dit soort gegevens zijn opgeslagen aansluit bij hoe de gemeente gegevens wil opslaan. Als dat zo is, kan via ETL tooling deze informatie worden geimporteerd. Alternatief kunnen deze gegevens ook via services worden ontsloten, maar dat is helemaal afhankelijk van wat de gegevens eigenaar aan mogelijkheden biedt. Voor de RIONED gegevens is met een import gewerkt.