Thema Totaal 3D/T3D Pilots/Rotterdam

Category:Totaal 3D
=Introductie=
De pilot Totaal 3D binnen Rotterdam had de focus op registratie. Welke standaarden zijn nodig om het volledig 3D vastleggen en beheren van objectgegevens (uiteindelijk als onderdeel van de Samenhangende Objectenregistratie) zowel organisatorisch als technisch mogelijk te maken.
Thema Totaal 3D/T3D Pilots/Rotterdam/Architectuur
== Datafundament ==
Binnen het programma T3D heeft Rotterdam gewerkt aan het ontsluiten van alle "object-gerelateerde" basis- en kernregistraties in één voorziening, het Datafundament, waarbij ook de samenhang tussen de registraties is vastgelegd (vooruitlopend op een toekomstige SOR).
Wat is gerealiseerd?
* Ontsluiting van de BAG en BGT via de Landelijke Voorziening;
* Ontsluiting van de WOZ is ontsloten via een databaselink. Het gaat dan niet om de gehele WOZ, maar om een beperkte dataset (specifiek voor Rotterdam);
* Ontsluiting van de Territoriale Indeling Rotterdam (TIR);
* Ontsluiting van de landelijke energielabels.
BAG, BGT en WOZ worden dagelijks ververst. 
Wat staat er nog op de planning?
* Ontsluiting van de BOR/BRO en BRK
* Het ontwikkeling van triggers die, in 3D, de inconsistenties tonen tussen de basisregistraties. Dit draagt bij aan het verbeteren van de kwaliteit van de basisregistraties. 
Wat heeft het opgeleverd?
Het ontsluiten van de verschillende basisregistraties in het Datafundament levert een belangrijke bijdrage voor nieuwe use cases, bijvoorbeeld voor digitale stad initiatieven. Het presenteren van de samenhangende data in een 3D-viewer stimuleert het ontwikkelen van nieuwe toepassingen. 
== Informatiemodel en Database ==
Wat is gerealiseerd?
Het informatiemodel voor T3D is gericht op het vastleggen van de kaders waarmee de 3D-registratie ingericht kan worden. Oorspronkelijk was het doel van het programma om vanuit 3D-inwinning en -registratie de huidige basisregistraties te voeden met de afgeleide producten, met andere woorden een eerste aanzet naar 3D SOR. Halverwege het programma is de doelstelling bijgesteld naar het in samenhang brengen van de huidige 2D-registraties (BAG, WOZ, BGT en GWSW) en de 3D-registratie. Het hieruit volgende informatiemodel wordt gebruikt om de 3D-objecten te modelleren en informatie uit de registraties mee te geven voor gebruik in de keten en usecases. Door het gebruik van dezelfde modelleringsprincipes en informatiemodel zijn de usecases en ketenoplossingen schaalbaar en algemeen inzetbaar bij het inrichting van een digital twin. 
Om tot een informatiemodel te komen is allereerst een verkenning naar de afstemming en onderlinge samenhang tussen SOR, BAG, BGT, WOZ, GWSW en CityGML gemaakt. Het conceptuele model van de SOR zoals dat nu beschreven is, is voorbereid op 3D-vastlegging van objecten. Dit is uitgewerkt tot modelleringsprincipes op basis van CityGML 2.0 en CityGML 3.0 (concept).
 
Op basis van deze modelleringsprincipes zijn voorbeeldmodellen gemaakt voor objecten uit de BAG (panden), BGT (weg-, terrein en waterdeel) en GWSW (rioolputten en -leidingen). Voor het vastleggen van de samenhang van tussen de registraties zijn de identificatiecodes vastgelegd in het 3D-model, zodat de kenmerken en administratieve data uit de registraties verbonden kunnen worden aan het 3D-model en zo in samenhang getoond kunnen worden. 
Wat heeft het opgeleverd?
* Vooralsnog is het niet haalbaar gebleken om op basis van een 3D-registratie de huidige 2D-registraties te voeden;
* Door de 3D-geometrie (CityGML) te linken aan de bijbehorende 2D-registraties hoeft niet alle informatie in het 3D-model opgeslagen te worden. Administratieve wijzigingen in de bronnen worden zo automatisch overgenomen;
* CityGML 2.0 is niet toereikend voor het koppelen van de WOZ in alle gevallen. CityGML 3.0 biedt uitgebreidere ondersteuning voor het maken onderscheid in de inpandige verdeling;
* CityGML 3.0 is nog niet getest. Het informatiemodel is wel beschikbaar, maar de implementatie ervan in een database en uitwisselformaat zijn nog niet afgerond. 
Overall is de conclusie dat het mogelijk is op basis van CityGML een digitale tweeling op te bouwen, waarbij de samenhang met de bestaande registraties is geborgd.
== Texturering ==
Het deelproject Texturing beoogde het creëren van een overzicht van verschillende textureringsmethoden en de afweging tussen deze methoden, met een focus op het textureren van panden. Door gebruik van texturering is de herkenbaarheid van het 3D-model te verbeteren. Een realistische weergave van de werkelijkheid verbetert de gebruikerservaring en opent de deur naar nieuwe toepassingsmogelijkheden. 
Wat heeft het opgeleverd?
Het kleuren van gebouwen aan de hand van classificaties in de data of gekoppelde themadata is een laagdrempelige methode waar verder geen aanvullende software of bronmateriaal voor nodig is. Om de herkenbaarheid van het model verder te vergroten, kan er gekozen worden voor grafische textureren. Dit is vooral bruikbaar als er voldoende details in de data zitten (denk aan ramen, deuren of andere pandelementen). Als dit niet aanwezig is, geeft het textureren met fotomateriaal een realistischer beeld van de werkelijkheid.
== 3D Objectenbeheer ==
=== Rotterdamse proefopstelling ===
De centrale component van de Rotterdamse proefopstelling was Virtual Citysystems (VCS) van Future Insight. Nieuw ontwikkelde componenten werden hierop aangesloten, waarmee alle data in dezelfde database terecht kwam. Koppeling en ontsluiting met derde partijen verliep via deze centrale component. 
Een voorbeeld hierin is het hydrodynamisch rekenmodel 3Di van Nelen & Schuurmans in een 3D Dynamic Digital Twin. Het project Dynamic Digital Twin voor Riolering had als doel om een dynamisch 3D-model voor stedelijk waterbeheer te ontwikkelen. Om dit 3D-model vervolgens laagdrempelig beschikbaar te maken is er zoveel als mogelijk gebruik gemaakt van open standaarden. Met de GWSW naar CityGML converter is het mogelijk om rioleringsdata in 3D te presenteren. Tijdens dit project is er een hydrodynamisch 3Di-rekenmodel in een 3D Dynamic Digital Twin geïntegreerd.
M/3D viewer
Deze vormt het meest zichtbare deel van de infrastructuur. De 3D-viewers worden vanaf een aparte server ontsloten, zodat deze geen performance hinder ondervinden van bijvoorbeeld zware berekeningen op de publiceeromgeving. Wij scheiden data en toepassing. Doordat er gebruik wordt gemaakt van de 3D-services tussen viewer en datastorage hoeft de data niet steeds gekopieerd te worden, maar kan deze hergebruikt worden. In de viewers komt de data uit de datastorage, maar ook uit externe bronnen samen voor het beantwoorden van de informatievragen van de eindgebruikers.
PU/Publisher
Via de VC Publisher kunnen op basis van de lagen uit de VC Database 3D-services samengesteld en gepubliceerd worden in de vorm van open 3D Tiles. Deze kunnen in steeds meer toepassingen gebruikt worden. Ook kunnen hier 3D-viewers geconfigureerd worden. Door zelf 3D-services en standaardfuncties te kiezen kan zo snel een specifieke viewer voor een specifieke gebruiker samengesteld worden. Doordat er altijd met open standaarden wordt gewerkt, is het echter ook mogelijk om deze data in andere toepassingen, buiten onze beschreven infrastructuur, te ontsluiten.
DB/Database
De 3D CityGML-data wordt opgeslagen in de VC Database. Dit is een uitgebreidere versie van de open source 3D CityDB. Dit geeft extra mogelijkheden voor bijvoorbeeld het updaten, opslaan van historie en bevragen van de database middels een WFS query. Dat maakt het mogelijk om de 3D-data niet alleen te hosten, maar ook daadwerkelijk te gaan beheren, vergelijkbaar met het beheer van de bestaande basisregistraties. Daarmee is de weg vrij voor een integraal en actueel 3D stadsmodel.
WH/Warehouse
Dit component zorgt ervoor dat er exports gemaakt kunnen worden van de data naar heel veel verschillende formaten.
=== 3D Beheertool ===
Mutaties in de BAG en de BGT worden in 2D bijgehouden. Om het stadmodel bij te werken is 3D-registratie nodig. In dit pilotproject heeft de gemeente Rotterdam beproeft wat er nodig is om 3D-topografie te kunnen beheren en muteren. Deze beproeving is uitgevoerd in samenwerking met Sweco, de leverancier van de beheersoftware dg DIALOG BGT. 
Wat hebben we gedaan?
Om 3D-topografie te kunnen beheren en terug te leveren aan de sprintviewer zijn een aantal stappen nodig. Gestart is met het downloaden van de BGT uit LV-BGT om dit vervolgens te importeren in dg DIALOG BGT. Vervolgens is de bestaande FME workspace, die nodig is voor conversie van CityGML naar dg DIALOG BGT, verder geoptimaliseerd aan de hand van de ontvangen data van de pilotgebieden. Voor 3D beheer en mutatie zijn extra attributen nodig, de conversie is daarom uitgebreid met de relevante ‘SOR-attributen’ voor de panden. Als laatste waren technische aanpassingen nodig voor de export vanuit de dg DIALOG BGT naar cityGML.
 
Ook de training van BGT-beheerders was een onderdeel van deze pilot. Na de training hebben deze BGT-beheerders zelfstandig getest en met alle beschikbare tooling binnen dg DIALOG BGT handmatig enkele complexe Rotterdamse panden in 3D opgebouwd en bestaande panden uit het 3D stadsmodel verbeterd en aangevuld.
Als laatste is in deze pilot beproeft of het mogelijk is om een BIM-model te uploaden in de dg DIALOG BGT. 
Hiernaast is Geodelta gevraagd om datasets , zoals het Actueel Hoogtebestand Nederland 4 (AHN4), de Topografische basiskaart, Airborne Lidar Rotterdam 2021 en 2022, puntenwolken, panorama- nadir- en obliekfoto’s en terrestrische laserscan data in Omnibase klaar te zetten en medewerkers een training te geven in het gebruik van Omnibase.
Wat heeft het opgeleverd?
* Het is mogelijk gebleken om een aangepast object vanuit DG DIALOG BGT naar CityGML te exporteren en aan de sprintviewer toe te voegen;
* Het ontbreken van standaarden zorgt op dit moment voor kwalitatief arme en inefficiënte informatieoverdracht. Dit zal de doorontwikkeling afremmen;
* Karteren in 3D, in Omnibase, bleek prima haalbaar;
* Het 3D beheer stelt stevige eisen aan de onderliggende hardware.
== Toepassingen ==
=== Watermanagement ===
Wat wilden we bereiken?
In de use case is een hydrologisch model gemaakt op basis van beschikbare registraties verrijkt met informatie uit een Mobile Lidar Scanning (MLS) puntenwolk. Vanuit de T3D proefopstelling kan een regenbui-analyse worden gestart, waarna de resultaten getoond worden in de viewer. De regenbui-analyse geeft inzicht in de optredende overlast als gevolg van extreme regenbuien. 
Wat hebben we gedaan?
Om de buitenruimte in het proefgebied gedetailleerd in 3D in kaart te brengen is gebruik gemaakt van MLS techniek. De MLS puntenwolk is vervolgens geclassificeerd en objecten zijn gevectoriseerd. Dit is als basis gebruikt voor het opzetten van de 3D BGT-registratie. 
Voor het in 3D in kaart brengen van de riolering zijn GWSW- conversies naar CityGML en Hydx ontwikkeld. 
De opgebouwde data is gebruikt voor de simulatie van extreme regenbuien. De analyse kan vanuit een laagdrempelige gebruikersomgeving worden gestart door de ontwikkelde widget. 
Wat hebben we gerealiseerd?
* Met het inzetten van de MLS-techniek is mogelijk om snel en eenvoudig de actuele situatie inzichtelijk te maken. De geclassificeerde puntenwolk en afgeleide vectoren zijn bruikbaar voor meerdere toepassingen;
* Het bijhouden van een 3D-registratie Riolen is vanuit het reguliere beheerproces te realiseren door gebruik te maken van de GWSW-standaard; 
* Het bijhouden van een 3D-regisratie BGT is vanuit het reguliere beheerproces te realiseren door gebruik te maken van puntenwolken;
* Door gebruik te maken van Common Ground-uitgangspunten is het mogelijk gebleken meerdere platformen met elkaar te verbinden. Zo is het mogelijk gebleken om op gespecialiseerde platformen puntenwolken te analyseren, hydrologische modelberekeningen uit te voeren en de resultaten te streamen naar een gebruikerstoepassing;
* Het hydrologisch model kan verder verfijnd worden door het inwinnen van aanvullende informatie. Hiermee maken we optredende overlast verder inzichtelijk. 
=== Vergunningcontroleservice ===
Het doel van deze toepassing is het verkorten van het vergunningsproces, rekening houdende met de eisen die de Omgevingswet zal gaan stellen. We hebben een prototype opgeleverd dat voor een beperkt aantal use cases en locatie het proces ondersteunt. 3D-informatie speelt hierbij een essentiële rol. Het gaat om zowel BIM (de aanvraag), de omgeving van het object als aanvullende datastromen.
Wat hebben we gerealiseerd?
* De opgeleverde vergunningscontrole-applicatie biedt de aanvrager de mogelijkheid een IFC-model (Industry Foundation Classes te uploaden, waarna meteen (na plaatsing op de juiste locatie) een aantal checks automatisch worden uitgevoerd. De gebruiker, zoals de medewerker van bouw- en woningtoezicht, ziet dan meteen of en wat er goedgekeurd is. Indien er een of meer aspecten niet goedgekeurd zijn, kan de aanvrager inzicht krijgen in de vereiste verbeteringen of aanpassingen aan het model.
* Voor het 3D-gebouw-model is IFC het uitgangspunt geweest. De informatie in het model is conform de BIM-basis ILS en BIM-ILS-O&E (ontwerp & engineering). De IFC is naar Linked Data vertaald met OWL (Web Ontology Language), de W3C taal van het semantische web. Voor het 3D-stad-model is CityGML het uitgangspunt geweest. De informatie in het stadmodel is conform de basisregistraties uit de NEN3610. Ook deze informatie is vertaald naar OWL. Deze vertaling naar OWL is noodzakelijk om een machinematige beoordeling van het model mogelijk te maken, met informatie die uitwisselbaar, gestructureerd, eenduidig, correct, volledig en herbruikbaar is.
* Beleid en wetgeving zijn voor deze service omgezet in datagedreven beleidsontwikkeling. De query-taal SPARQL is hiervoor het uitgangspunt geweest. De informatie in het regel-model is conform Linked Open Vocabularies opgesteld. 
Wat zijn onze bevindingen?
De gebruikers zijn redelijk tevreden met de opgeleverde service en zien de potentie. Om echte meerwaarde te hebben in het proces moet de service worden uitgebreid. Een belangrijk aspect is de implementatie van de verschillende ILS-voorwaarden. Hiermee wordt de benodigde standaardisering bereikt. 
Uitgebreide online presentatie over de Vergunningcontroleservice
=== Berekening hittestress ===
In deze use case hebben we gekeken welke data nodig is om hittestress te berekenen (o.a. gebouwen, bomen en maaiveldtypering) en hoe we deze data (zoveel mogelijk geautomatiseerd) kunnen laten stromen van de onze data-infrastructuur naar het softwareplatform Tygron en onze proefopstelling, met gebruik van open datastandaarden.
Wat zijn onze bevindingen? 
* De berekeningen in Tygron zijn volledig geautomatiseerd te publiceren in de proefopstelling T3D;
* Een belangrijke randvoorwaarde is dat alle betrokkenen in deze keten dezelfde principes hanteren en ondersteunen. Voor deze specifieke use case was dat voor de gemeente Rotterdam, Tygron en Future Insight het geval.
=== Bewonersparticipatie ===
Deze use case richt zich op het verbeteren van de communicatie door het inzetten van 3D-tekeningen en 3D-ontwerpen van de buitenruimte, waarbij participanten (bewoners, belanghebbenden) zelf in 3D-tekeningen kunnen maken en delen. Visuele 3D-representaties van ontwerpen nemen taalbarrières grotendeels weg.
Wat hebben we gerealiseerd?
Op dit moment bestaat de oplossing uit een samenwerking tussen gemeente Rotterdam en Furban. Furban is een startup en heeft een gelijknamig product waarmee in 3D tekeningen van de buitenruimte kunnen worden gemaakt. De data zoals 3D-tekeningen en -ontwerpen zijn eigendom van de gemeente Rotterdam. Het definitieve ontwerp is teruggeleverd aan de proefopstelling. De tool ondersteunt het exporteren van een 3D-ontwerp, dit ontwerp is in te lezen met een viewer zoals Cesium
Furban bestaat uit een 3D-ontwerpomgeving en een AR-publicatieomgeving (augmented reality). De 3D-ontwerpomgeving is te bereiken via een desktop, laptop of tabblet met internetverbinding. De AAR-publicatieomgeving is te bereiken via een smartphone app.
In de 3D-ontwerpomgeving is een project administratie opgenomen en een userregistratie aanwezig. Binnen een project zijn de 3D-tekeningen te vinden en is een 3D-objectlibrary gekoppeld. Alle data staan in de applicatie Furban.
De 3D ontwerpen kunnen worden geëxporteerd met een “save in” optie. Ook kan een link (iFrame url) rechtstreeks naar een 3D-ontwerp worden gegenereerd. Deze link geeft toegang tot een 3D-ontwerp vanuit een device met internetverbinding zonder dat de app daarvoor nodig is.
Een ontwerp omzetten naar augmented reality is een handmatige procedure die door de leverancier moet worden uitgevoerd. Een 3D-ontwerp in AR bekijken kan vereenvoudigd worden met een QR-code met daarin de link naar het betreffende model. 
De oplossing ondersteunt budgetgebonden ontwerpen door aan objecten een prijs te koppelen en door aan het project een budget toe te kennen.
De oplossing ondersteunt het samen ontwerpen in één omgeving waarbij meerdere gebruikers het ontwerp kunnen aanpassen (co-creatie modus).
De User Interface is zo eenvoudig dat betrokkenen zonder training vooraf een tekening in 3D kunnen maken.
De oplossing ondersteunt “unnamed users”, waarbij gebruikercodes kunnen worden gegenereerd voor het samenwerken met een grotere groep.
Wat zijn onze bevindingen?
Het 3D-ontwerpen met bewoners werkt! Bewoners zijn enthousiast, in 3D is een ontwerp veel duidelijker dan op papier met legenda. Bewoners lichten elkaars ontwerpen toe waardoor veel afwegingen waarom iets is opgenomen in een ontwerp duidelijk worden, ook voor het projectteam van het project. Het bereik van AR is groter dan normaliter met bewonersavonden.