Thema Totaal 3D/T3D Pilots/Amsterdam
Inleiding[bewerken]
In de 3D keten zoals vastgesteld voor T3D, is Amsterdam de eigenaar van de use case hergebruik 3D registratie. Hierin is specifiek gekozen om het proces van vergunningaanvraag te gebruiken. Een eerste use case daarin is het in een 3D versie van bestaande verblijfsobject een aanvraag in te dienen voor uitbouw, dakkapel. Waarin de interactie met het 3D model kan worden voorzien in zowel interactieve modus met laagdrempelige “bouwblokken” of een gedetailleerde interactie op basis van meer gedetailleerde 3D modellen van bijvoorbeeld een architect of bouwbedrijf (IFC). Het interacteren met een 3D model kan op verschillende methoden worden ingericht waarbij er twee hoofdpatronen mogelijk zijn:
- Interactie op een (de)centraal beheerd 3D model zoals nu met een BGT / BAG registratie via bijv. pdok. Gebruikers (burgers / ondernemers) en diensten eigenaar (gemeente) kijken op hetzelfde centrale model. Beheerder model is centraal aangewezen voor Nederland en zorgt voor geschikte ontsluiting voor hergebruik.
- Hybride situatie waar extra lokale gegevens worden geïntegreerd met centraal model. Gemeente gebruikt integratie diensten waar landelijke registratie kan worden geïntegreerd met lokale processen en data die verrijking toestaat met lokale regels / informatie. Hierin is het integreren van de informatie en de ontsluiting aan de gemeente zelf.
DSO en SOR
In een scenario met het DSO en/of SOR kunnen integratiediensten ook worden verleend door het DSO of de SOR, maar ook dan zullen mogelijk lokale informatie en processen moeten worden geïntegreerd. Uiteindelijk zal voor veel gemeenten de integratie een onderdeel worden van de architectuur. Maar dit is grotendeels afhankelijk van de manier waarop een gemeente haar diensten wil ontwikkelen en aanbieden (marktwerking versus eigen ontwikkelsnelheid).
Standaarden voor de ontsluiting en interactie bij gebruik zijn gebaseerd op open standaarden voor 3D tiling en CityGML zoals in beheer bij OGS.
Ervaringen Amsterdam
Bij de eerste ontwikkelingen van de interactie met een 3D model heeft de gemeente Amsterdam gekozen voor het hergebruiken van een lopend project “3D Amsterdam” waarin een 3D model van Amsterdam is ontwikkeld op basis van bestaande technologie (Unity).
Reden voor deze keuze was het gebrek aan een werkende service voor rendering van een voldoende volwassen 3D model (3D BAG) of vergelijkbaar.
In eerste instantie is er gewerkt aan een vergunningchecker die op basis van een grof model kan bepalen of er specifieke eisen worden gesteld aan een uitbouw of dakkapel. Deze twee producten zijn populair en bestrijken daarmee een brede groep van gebruikers. In een latere iteratie zal het renderen ook tegen een centraal gehost model moeten worden getoetst, en zal er daarnaast een integratie scenario moeten worden getoetst. In beide gevallen zal er worden aangestuurd op een standaardisatie van de services tussen bron en beheer en gebruik.
Gebruikers van de 3D versie waren enthousiast over het gebruik van 3D omdat daarmee sneller een situatie kon worden gecommuniceerd met betrokkenen zoals de naastgelegen bewoners of derden. In de praktijk blijkt dat voor veel kleinere verbouwingen geen 3D bronmateriaal aanwezig is. Vaak omdat dit door kleinere aannemers wordt uitgevoerd die, door de gemeenten gedreven, veel in een papieren proces de aanvraag indienen.
Voor grotere bouwprojecten lopen er vaak andere processen waar 3D materiaal wel voorhanden is maar een dermate hoog detail-niveau bevat waarvan een deel relevant is voor de vergunning aanvraag. Het verwerken daarvan vereist een koppelvlak dat hoge eisen stelt aan zowel de gebruikers zijde als de ontvangende zijde en waarin een "eenvoudige 3D weergave in een web-interface" nog niet eenvoudig is te realiseren.
Solution architectuur proefopstelling[bewerken]
In onderstaande figuur is de proefopstelling van de pilot Amsterdam weergegeven: