De gemeente Rotterdam maakt gebruik van VCS-producten. Dat maakt het mogelijk om het bijwerken te automatiseren met “jobs” (scripts of taken) zodat we onze data actueel kunnen houden. Daarnaast hangt het er sterk vanaf of je bijvoorbeeld behoefte hebt aan texturen, of publicatie op detail niveau van subobjecten (bijvoorbeeld de constructieve onderdelen van een tunnelbak).

Geodan is actief zijn tooling aan het doorontwikkelen en ook FME is breed beschikbaar bij gemeenten. Omdat FME een generiek in te zetten ETL tooling is, is deze het meest flexibel in de settings. De keuze voor de tooling is daarmee heel breed en kan dus per situatie verschillen. Alle geteste tools zijn prima in staat om 3Dtiles voor BAG / BGT toepassingen te maken vanuit 3D-brondata

Deze dienen handmatig te worden doorgevoerd. Reden daarvoor is dat gemeente Rotterdam gebruikmaakt van ingevlogen hoogtes. Het eerste object dat een vliegtuig tegenkomt vanuit de lucht, is de ingevlogen hoogte. Dat betekent dat er geen hoogte beschikbaar is van alles wat daaronder zit. Om dat in kaart te brengen, zijn andere technieken nodig.

Hoe dit precies werkt of gaat werken binnen Tailormap is meer een vraag voor de leverancier of ontwikkelaar. Wat wij in ieder geval zien is dat steeds meer GIS-platforms en viewers 3D functionaliteit laten ontwikkelen. Welke functionaliteit dat is hangt af van de leverancier en het platform. In ieder geval zorgen we met 3D Tiles Nederland voor uniforme en gestandaardiseerde toegang tot de data. Omdat 3dtiles als OGC-standaard uitgebreid is beschreven, is het voor ontwikkelaars een relatief kleine moeite om de ondersteuning op 3dtiles in een eigen platform of viewer “in te bouwen”. En vanaf daar is het dan voor gebruikers eenvoudig om naar behoefte 3D datasets (bijvoorbeeld via 3dtilesnederland.nl) op te halen en te combineren in een viewer. Zie ook het voorbeeld van Netherlands3D.

De 'need to have' zit voor een belangrijk deel bij de eindgebruikers. Om gebiedsontwikkelingen te versnellen heeft Bouwend Nederland bijvoorbeeld behoefte aan actuele en betrouwbare 3D geo-informatie, zodat ze tijdig en makkelijk nieuwe ontwikkelingen kunnen toetsen. De bouwwereld zet 3D zelf al breed in voor ontwerp en modellering, maar moet voor toetsing en ruimtelijke inpassing helaas vaak weer terug naar 2D. Dat kost tijd en geld. Daar ligt in ieder geval een 'need to have'. Ook voor klimaatadaptatie, energietransitie en mobiliteit en bereikbaarheid neemt met 3D data de kwaliteit van het voorspellen en inzichtelijk maken van beleid sterk toe.
Voor gemeenten geldt daarnaast in de rol van een belangrijke (mede-) bronhouder van verschillende geo-basisregistraties als BAG, BGT en WOZ dat gebruik van 3D data in inwinning en registratieprocessen helpt om het bijhoudingsproces te vernieuwen, meer samenhang aan te brengen in het gegevensbeheer en uiteindelijk meer kwaliteit tegen dezelfde kosten te kunnen leveren.

Het antwoord hierop is in eerste instantie afhankelijk van de gebruikte tooling voor het maken van 3d tilesets, maar het is tegelijkertijd ook heel flexibel. Een database is mogelijk (bijv. Postgresql of 3dCityDB), maar niet strikt noodzakelijk. Het is ook mogelijk om met een bestandsformaat te beginnen.  Zeker voor kleine projecten is het ook prima om de 3D data als Geopackage of CityJson op te slaan en als databron te gebruiken. Je hoeft ook niet meteen je hele gemeente of grondgebied beschikbaar te stellen. Je kunt het ook beperken tot bijvoorbeeld een nieuw plan of de gebouwen waarvoor een vergunning is verleend (gepland).

Gebruik maken van het platform is voor eigen risico. Dat heeft als voordeel dat er geen overeenkomst nodig is en als nadeel dat je als gebruiker goed moet opletten wat je met de data doet. De actualiteit van de data die nu via 3dtilesnederland.nl is gepubliceerd is een verantwoordelijkheid van de datahouder. Omdat de website primair is bedoeld voor het demonstreren van het principe van data bij de bron (of “uit betrouwbare bron”) hebben we een aantal voorbeeld datasets beschikbaar. Er zijn geen afspraken gemaakt over actualisatie of verversing. Die afspraken zijn uiteraard op landelijk niveau wel nodig en dat is dan ook één van de belangrijke aanbevelingen uit ons project.

Zoals tijdens het webinar is verteld hebben gemeenten nog steeds de ambitie om toe werken naar één integrale 3D objectenregistratie (SOR). De weg er naar toe kan via het 3D maken van de huidige geo-basisregistraties en in eerste instantie mogelijk een aparte (maar wel gekoppelde) 3D objectenregistraties. Maar dit is voor gemeenten nadrukkelijk niet het eindbeeld. We willen namelijk op lange termijn geen twee “systemen” naast elkaar in de lucht houden (m.a.v. 2D registraties en een 3D registratie naast elkaar bijhouden). Gemeenten willen ook graag 3D ingewonnen data bij de bron direct kunnen gebruiken voor registratie, terwijl deze nu als gevolg van de wettelijk verplicht 2D registratie letterlijk wordt platgeslagen  (denk aan BIM van architecten en lokaal ingewonnen puntenwolken met bijvoorbeeld drones of scanauto’s). Dit alles betekent in de huidige situatie informatieverlies, dubbel werk en is dus kostbaar. In een eindsituatie zou je 3D als basis willen registreren in landelijke basisregistraties en 2D daarvan afleiden. Van gedetailleerde 3D geometrie is bijvoorbeeld vrij eenvoudig geautomatiseerd en flexibel 2D weergave te maken (bovenaanzicht, maaiveld en alles daartussen). Die eindsituatie is eerder al uitgewerkt in de SOR.

Het uitwisselformaat van 3dtiles is afhankelijk van de versie .B3DM of .glb (zie 3dtilesnederland.nl voor meer info). Dat zijn technische  formaten die geschikt zijn voor het via het web  “streamen” van grote hoeveelheden 3d data. 3dtiles wordt fundamenteel anders ingezet dan berichtenverkeer. Het is een webservice die door een datahouder wordt aangeboden (gepubliceerd), zodat datagebruikers via de webservice actuele 3d data kunnen ophalen. Waar berichtenverkeer werkt volgens het principe de datahouder brengt zijn data naar gebruikers (of een LV), haalt de gebruiker bij 3dtiles data op bij de datahouder. Vergelijkbaar met onder andere WMS en WFS.

Voor het uitwisselen van 3d data via berichtenverkeer zul je waarschijnlijk andere formaten gebruiken (bijv. GML of CityJson of OBJ).

Er is nu geen landelijke standaard. Er zijn wel verschillende keuzes gemaakt door aanbieders van 3d data. Als voorbeeld Gebouwen: de 3D Basisvoorziening van het Kadaster ondersteunt maximaal 1.3 (dit wordt 2.2), de 3D Bag ondersteunt maximaal LoD 2.2, en de 3D Gebouwen van Rotterdam zijn nog iets gedetailleerder beschikbaar op maximaal LoD 2.3.  3dtiles als uitwisselformaat is “LoD neutraal” en kan 1 of meerdere loD’s uitwisselen. Om dit landelijk te standaardiseren zijn dus aanvullende afspraken nodig over wat we exact verstaan onder de verschillende niveau’s van LoD en welk niveau we maximaal of minimaal willen uitwisselen. Die afspraken zullen ook verschillen per type objecten  (Gebouwen, Terreinen / BGT, BOR etc). In het programma Totaal Driedimensionaal hebben we bijvoorbeeld een aanzet gegeven voor een indeling van LoD niveaus voor de Openbare Ruimte als aanvulling op en analoog aan die voor Gebouwen.

Rotterdam biedt over het algemeen een hoger LoD aan dan nu beschikbaar is in de 3D BAG of 3D Basisvoorziening. Dat zie je bij Gebouwen bijvoorbeeld terug in onder- en overbouwsituaties. Een mooi voorbeeld is het beroemde “gebouw over gebouw” aan de Nassaukade. Vergelijk daar de 3D Bag maar eens met 3D Rotterdam gebouwen. Een hoger detailniveau levert hier direct meer en betere 3D data op voor bijv. een water op straat analyse of een schaduwanalyse. Een hoger detailniveau wil je soms ook voor beeldbepalende objecten als kerken en torens.

LoD 2.2 is over het algemeen behoorlijk verregaand te automatiseren op basis van 2D geometrie en hoogtebestanden. Een hoger detailniveau van LoD 2.2 vraagt dan meestal weer meer handmatig karteerwerk.

Kortom: een uitspraak over een gewenste standaard voor het maximale of minimale detailniveau is dus lastig en hangt af van meerwaarde bij toepassingen.