nyuuzyou/wikis huggingface dataset:
Thema Totaal 3D

__NOTOC__
Categorie:Projecten
Deze pagina is het vertrekpunt voor de architectuurbeschrijving voor het inwinnen, beheren en beschikbaar stellen van 3D gegevens. De basis hiervoor is gelegd binnen het programma Totaal3D (T3D), dat is uitgevoerd door de VNG in samenwerking met de gemeenten Den Haag, Rotterdam en Amsterdam.
De T3D architectuur staat niet op zichzelf. Er wordt binnen de architectuur rekening gehouden met de principes van Common Ground/GEMMA Gegevenslandschap en wordt er gekeken naar de doorontwikkeling van de geo-basisregistraties in de richting van een samenhangende objectenregistratie (SOR) en andere ontwikkelingen in het werkveld. Daarnaast sluit de T3D architectuur aan op de GEMMA referentiearchitectuur.
=Doelstelling=
Met de T3D architectuur wordt richting gegeven aan initiatieven die gemeenten willen uitvoeren op het gebied van 3D objectbeheer. De T3D architectuur beschrijft welke kaders er zijn en beschrijft daarnaast inrichtingsonafhankelijk wat er nodig is om 3D objectbeheer toe te passen. Er worden ook handreikingen gegeven aan gemeenten die willen beginnen met het registreren en beheren van 3D gegevens. Doel is hierbij niet om een strikte methodiek voor te schrijven omdat de verwachting is dat het beheren van 3D gegevens nog enige tijd een leerproces zal blijven. Vanuit de pilots die binnen het programma T3D zijn uitgevoerd, is er daarnaast beschreven welke inrichtingskeuzes er zijn gemaakt in relatie tot de architectuur.
=T3D Pilots=
Voor het opdoen van ervaringen rondom 3D objectbeheer zijn er binnen het programma T3D drie pilots uitgevoerd door de gemeenten Den Haag, Rotterdam en Amsterdam. Deze pilots kenden een onderlinge samenhang, maar elke gemeente had een eigen focus:
Deze sporen zijn in het project bij elkaar gebracht voor een gezamenlijke workflow.
Thema Totaal 3D/T3D Common Ground

Category:Totaal 3D
== T3D en Common Ground ==
Het is vanzelfsprekend dat de T3D architectuur zich conformeert aan de principes van Common Ground / GEMMA Gegevenslandschap. Om de samenhang te beschrijven is er een generiek model opgesteld waarin wordt aangegeven hoe de binnen T3D onderkende componenten zich verhouden tot de verschillende lagen van Common Ground.
Thema Totaal 3D/T3D Pilots/Den Haag

Category:Totaal 3D
=Introductie=
De gemeente Den Haag had inwinning als focusgebied. In het hele proces van inwinning tot aan gebruik is dat de eerste stap. Eindproduct van deze fase is een CityGML bestand wat gebruik kan worden voor verwerking in een 3D object registratie. Hoewel de gemeente Den Haag zelf ook de wens had om een 3D object registratie op te zetten, is dat binnen het project niet gelukt. De focus heeft daarmee gelegen op:
* Inwinning van gegevens
* Validatie en transformatie van ingewonnen bestanden
* Orkestratie van het proces
Deze onderdelen van het proces worden hier besproken. Daarnaast wordt de Solution architectuur, zoals die in Den Haag is uitgewerkt beschreven.
De pilot is pragmatisch van opzet geweest, en ook voeding voor de referentiearchitectuur, maar zeker niet conform die referentiearchitectuur.
Thema Totaal 3D/T3D Pilots/Den Haag/Overzicht
Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur
Thema Totaal 3D/T3D Pilots/Den Haag/Inwinning
Thema Totaal 3D/T3D Pilots/Den Haag/orkestratie
Thema Totaal 3D/T3D Pilots/Den Haag/Samenstellen
Thema Totaal 3D/T3D Pilots/Den Haag/datamodel
Thema Totaal 3D/T3D Pilots/Den Haag/Gebruik
Thema Totaal 3D/T3D Pilots/Den Haag/Hoe verder
Meer uitgebreide documentatie over het programma kan gevonden worden op Alkemio: https://alkem.io/t3d/dashboard (let op, u moet een account aanmaken)
Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur

Categorie:Totaal 3D
=Architectuur=
 
Het proces diagram zoals voor Den Haag gemaakt is te vinden op Thema_Totaal_3D/T3D_Pilots/Den_Haag/Architectuur/Procesdiagram
De proefopstelling in een Common Ground lagen model is te vinden in Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur/Proefopstelling
Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur/Procesdiagram

Categorie:Totaal 3D
==Procesdiagram==
Dit diagram is een uitwerking van Thema Totaal 3D/T3D proces
Het wijkt hiervan af omdat het in Den Haag gaat om het bijhouden van de eigen 3D kernregistratie. Eventuele levering aan de SOR zal ergens in de beheer stap moeten vallen, maar is nog niet uitgewerkt.
==Overzicht business proces eigenaars==
==Overzicht proces stappen==
Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur/Proefopstelling

Categorie:Totaal 3D
==Proefopstelling==
Dit diagram is een uitwerking van Thema Totaal 3D/T3D Common Ground
Het wijkt hiervan af omdat in Den Haag een praktische invulling is gemaakt. Dat betekent dat bijvoorbeeld een component als Azure ADF de rol van veel componenten in het T3D Common Ground model vervult.
Ook zie je dat de beheer registratie ook op het onderste common ground niveau doorloopt. Dit is omdat veel leveranciers van beheer registraties de data vaak binnen de tooling trekken voor een zo efficient mogelijke verwerking. De data is dan vaak wel via een API voor andere applicaties beschikbaar (voor lees, wijzig en analyse toegang). Dit principe geldt voor alle lagen. De applicatie gebruikt intern shortcuts, maar op elke laag is een API beschikbaar om specifiek die laag te ontsluiten. Er kan dus voor gekozen worden om delen niet te gebruiken, De applicaties zijn daarmee wel common ground compliant. 
Ook aansluiting op Nederlandse initiatieven als NLX en Haven is mogelijk vanuit deze tooling, echter, omdat tooling vaak door internationale leveranciers wordt gemaakt, en er in veel landen, en ook in andere branches soms vergelijkbare, maar toch anders ingevulde initiatieven zijn, is vaak nog wel maatwerk noodzakelijk om goed op deze initiatieven aan te kunnen sluiten. Het zal niet out of the box beschikbaar zijn. Per Use Case kan dan ook de meerwaarde van deze aansluiting bekeken worden.
ADF is een orkestratie en ETL tool van Microsoft die binnen Azure te gebruiken is. Voor T3D in Den Haag wordt de tool vooral gebruik voor orkestratie, aangezien de ETL capabilities van ADF niet goed met deze specifieke data kunnen omgaan (Daarom staan is er nog aparte validatie en samenstellings functionaliteit). Azure ADF vervangt een groot aantal componenten uit het metamodel. Dat maakt het aan de ene kant kwetsbaar en gevoelig voor wijzigingen. Aan de andere kant is het ook overzichtelijker om met 1 component te werken die een aantal taken voor je af vangt. Het zorgt voor een overzichtelijker landschap. Meer over de ervaringen met ADF zijn te vinden in het deel over orkestratie. Ook ADF strekt zich over meerdere lagen van het common ground model uit. Dat lijkt niet compliant, maar op elk niveau zijn API's beschikbaar waardoor de lagen wel los te koppelen zijn indien wenselijk, conform ook de voorziene beheertooling.
Een overzicht hiervan staat in Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur/DHIRTCommonGround
==Overzicht Applicatie componenten==
==Overzicht Applicatie interfaces==
==Overzicht Data objecten==
==Overzicht Groeperingen==
Een weergave van het model waarbij de onderdelen in common ground lagen zijn gesplitst, ziet er als volgt uit:
Thema Totaal 3D/T3D Pilots/Den Haag/Hoe verder

Categorie:Totaal 3D
==Hoe nu verder?==
In Den Haag zijn genoeg plannen om verder te gaan met 3D gegevens. Parallel aan het T3D project heeft er in Den Haag het project 3D stadsmodel gelopen, en loopt er ook een project voor de digitale spiegelstad. Het doel is om dit meer als 1 geheel te gaan behandelen.
Het is zeker nog niet dudelijk wat er de komende tijd gaat worden opgepakt, maar er wordt o.a. aan de volgende zaken gedacht:
* Use case huisnummerbesluit verder in productie proberen te brengen. Dit zal met kleine stapjes gaan om steeds meer ervaring te krijgen en ook meer handvaten te krijgen om dit aan te pakken.
* Workflow automation verder uitwerken. Uiteindelijk moet veel input verwerkt worden naar 1 set aan overzichtelijke beschikbare data (in welke vorm dan ook). Dit moet als een soort regiekamer gaan dienen.
* Verder nadenken over een beheerregistratie. Voldoet het huidige stadsmodel, of wil Den Haag dit toch iteratief gaan bijhouden. En indien dat gewenst is, hoe gaat dat gebeuren, en wat is de busincess case daarvoor.
* Goed kijken wat de markt gaat doen op het gebied van beheer van 3D registraties. In T3D is door Rotterdam naar DgDialog gekeken, en ook in Den Haag wordt daarnaar gekeken, maar er zijn ook andere opties.
* Het aantal use cases waarvoor het stadsmodel nu wordt gebruikt is beperkt. Daar zal ook uitbreiding in moeten komen om goed te kunnen evalueren of dit voldoet of niet.
* Wisselwerking met digital twin beter bekijken
* T3D heeft beperkte resultaten opgeleverd, mede omdat een gezamenlijk beeld moeilijk te bepalen is, wat veel overleg tijd heeft gekost. Vanaf 2023jaar proberen meer focus aan te brengen.
* ADF wordt verhuisd naar een interne Azure omgeving van de gemeente.
Thema Totaal 3D/T3D Pilots/Den Haag/Inwinning

Categorie:Totaal 3D
=Inwinning=
Voor inwinning heeft Den Haag in eerste instantie vooral gekeken naar welke bestandsformaten gebruikt kunnen worden in het proces. Daarnaast is ook gekeken naar het proces voor inwinning. Is er data die al wordt ingewonnen voor bepaalde bedrijfsprocessen die ook voor 3D beheer kan worden gebruikt, of moet daar een apart proces voor worden ingericht.
De beschrijving van de bestandsformaten met de ervaringen staan hier: Thema Totaal 3D/T3D Pilots/Den Haag/Inwinning/Bestandsformaten
==Inwinningsproces==
Waar in het project te weinig naar gekeken is, is naar het proces voor inwinning. In Den Haag wordt onderkend dat gegevens vanuit verschillende bronnen en in verschillende formaten binnenkomen. Orkestratietooling dient als een soort trechter om al deze informatie samen te brengen. Mogelijkheden voor inwinning zijn:
* Gebruik maken van inwinning vanuit bestaande processen, zoals vergunningsverlening, WOZ, etc.
* Expliciet data inwinnen voor ondersteuning van business processen. Dit wordt nu gedaan met de luchtfoto's voor het 3D stadsmodel en is in test bekeken voor de huisnummerbesluiten.
* Opleggen van verplichtingen voor het aanleveren van gegevens in bepaalde processen (bijvoorbeeld grote projecten, volgens een vastgestelde ILS)
* Expliciet inwinnen voor de 3D object registratie.
In Den Haag moet dit proces nog verder worden uitgewerkt. Het inwin proces is daarbij afhankelijk van de 3D use cases die binnen de gemeente ondersteund gaan worden. Deze use cases bepalen uiteindelijk de eisen waaraan ingewonnen data moet voldoen. Die eisen worden dan in de datalaag van common ground vastgelegd.
Thema Totaal 3D/T3D Pilots/Den Haag/Overzicht

Categorie:Totaal 3D
=Overzicht=
Het proces van inwinning en verwerking wat in Den Haag is uitgewerkt, bestaat uit een aantal stappen. Aangevuld met de stappen die Rotterdam en Amsterdam gaan zetten komt in Den Haag op termijn het volgende proces in beeld:
====Inwinnen====
Dit onderdeel bestaat uit 3 deelstappen
# Inwinnen van ruwe data. Dit kan op veel manieren gebeuren, en ook in het kader van verschillende business processen worden uitgevoerd.
# Opwerken van data tot het voldoet aan de leveringsspecificaties. Voor BIM bestanden kan deze stap wellicht worden overgeslagen, maar Lidar bestanden kunnen wel opgeschoond worden (verwijderen tijdelijke objecten bijvoorbeeld)
# Aanleveren aan workflow. Als de data klaar is kan gestart worden met de verwerking. Aanleveren kan een actieve stap zijn. Het kan ook zijn dat data door de workflow wordt opgehaald van een vaste locatie. In Den Haag zijn beide opties onderzocht, en beide kunnen werken.
Voor een uitgebreide beschrijving van de ervaringen met inwinning, zie Thema Totaal 3D/T3D Pilots/Den Haag/Inwinning
====Samenstellen====
Het samenstellen van data bestaat uit 4 stappen.
# Ontvangen brondata. De aangeleverde data wordt ontvangen en geregistreerd, zodat een passende workflow kan worden opgestart. 
# Valideren. Het ontvangen bestand wordt gevalideerd. Validatie is afhankelijk van het types aangeleverde bestand. Het gaat zowel om een technische (schema) validatie, als een validatie tegen bijvoorbeeld een specifieke ILS
# Samenstellen. Na validatie wordt het aangeleverde bestand verwerkt tot 3D bestanden. Binnen T3D is daarbij gekozen voor CityGML als tussenformaat. 
# Inspecteren. Tenslotte wordt er een inspectie gedaan op het CityGML bestand om te zien of dit correct is (ligt het op de juiste plek, juiste hoogte, zitten er geen rare gaten in, etc. 
Voor meer informatie over de workflow om door deze stappen heen te lopen, zie Thema Totaal 3D/T3D Pilots/Den Haag/orkestratie
Voor meer informatie over validatie, samenstellen en inspectie, zie Thema Totaal 3D/T3D Pilots/Den Haag/Samenstellen
====Beheren====
Voor het beheren van 3D gegevens, in Den Haag binnen het project nog niet geimplementeerd, worden drie stappen voorzien.
# Registreren. In deze stap wordt het CityGML bestand verwerkt binnen de gekozen 3D beheer tooling, en ontstaat een 3D object registratie i.p.v. een verzameling bestanden
# Beheren. In deze stap wordt de data onderhouden, up-to-date gehouden, en beschikbaar gehouden
# Ontsluiten. In deze stap wordt de 3D object registratie ontsloten voor andere business processen
Binnen Den Haag zijn wel ideeen hoe hier verder mee te gaan, maar binnen T3D is dit niet uitgewerkt.
====Gebruiken====
Voor het gebruik zijn meerdere kandidaat processen aanwezig binnen de gemeente Den Haag. Binnen het project is hier beperkt ervaring mee opgedaan. Om die reden is dit onderdeel beperkt uitgewerkt.
Een aantal processen waar maar gekeken is, zijn hier te vinden: Thema Totaal 3D/T3D Pilots/Den Haag/Gebruik
Thema Totaal 3D/T3D Pilots/Den Haag/orkestratie/pakketkeuze

Categorie:Totaal 3D
==Keuze voor ADF==
Binnen de gemeente Den Haag is uitgebreid onderzoek gedaan naar mogelijke orkestratietooling. Er is gekeken naar de keuze tussen On Premise en in de Cloud of Hybride, maar ook naar de keuze tussen low-code, high-code of hybride. 
Ook de kosten van de tools was een factor, waarbij gekeken is naar betaal modellen van de tools, maar ook van de opslag (want ook met open source tools moet ergens de data worden opgeslagen).
Met dat in het achterhoofd zijn functionele en non-functionele wensen opgesteld, waarna met een beoordelingsmatrix is gekeken welke tool het beste paste.
Daarnaast zijn er nog een aantal uitsluitingscriteria opgesteld (bijvoorbeeld: AWS Glue werkt binnen een AWS Cloud, die binnen Den Haag niet aanwezig is)
Uiteindelijk is nog een wat dieper onderzoek gedaan naar FME en ADF.
Hoewel de verschillen tussen de tools vaak klein waren is de keuze uiteindelijk gevallen op Azure data factory, onder meer omdat er meer specialisten voor ADF zijn, omdat het minder domein specifiek is.
Thema Totaal 3D/T3D Pilots/Rotterdam/Architectuur

Category:Totaal 3D
== Totaal 3D, proefopstelling Rotterdam, totaaloverzicht ==
== Totaal 3D, proefopstelling Rotterdam, Datafundament ==
== Totaal 3D, proefopstelling Rotterdam, Beheer ==
== Totaal 3D, proefopstelling Rotterdam, Use Case Watermanagement ==
Thema Totaal 3D/T3D begrippen

Category:Totaal 3D
==T3D Begrippen==
De T3D begrippen zijn grotendeels gebaseerd op het model van de Samenhangende Objectenregistratie (zie ook: https://docs.geostandaarden.nl/disgeo/emso/#geometrie). Dit model is weliswaar nog in ontwikkeling, maar biedt wel een goede uitgangsbasis. In relatie tot de MIM standaard betreft het een beschrijving op niveau 1. Op basis van deze begrippen kan een conceptueel informatiemodel worden opgesteld. Deze begrippen zijn ten behoeve van het T3D model aangevuld met enkele andere begrippen.
Binnen T3D zijn op dit moment een beperkt aantal begrippen meegenomen.
Begrippen met definities, eigenschappen en hun onderlinge relaties vormen een ontologie. Dit geldt dus ook voor de hier getoonde begrippen. 
Er zijn diverse ontologiëen met overeenkomstige begrippen binnen zowel basisregistraties als binnen standaarden zoals BRT, NEN3610, 
CityGML, INSPIRE, etc. Er is een apart traject opgesteld om een analyse te doen naar de definities voor vergelijkbare begrippen in de verschillende ontologiëen en om op basis hiervan een definitieve keuze te maken. Zie hiervoor: https://data.gwsw.nl/1.6/t3d/index.html
== SOR begrippen==
Uiteindelijk zal op termijn de volledige inhoud van het conceptueel model van de SOR in samenhang moeten worden beschreven met de hier beschreven T3D begrippen. Het gaat daarbij om de volgende begrippen zoals deze momenteel in het conceptueel model van de SOR zijn beschreven:
==Overzicht SOR begrippen==
Thema Totaal 3D/T3D componenten

Category:Totaal 3D
==Totaal 3D componenten==
In onderstaande figuur zijn de referentie componenten weergegeven waarvoor in een concrete toepassing oplossingen moeten worden ingezet. Een oplossing kan een product van een leverancier zijn, een open source toepassing zijn of een zelf te ontwikkelen component zijn. Het kan daarbij onderdeel zijn van een systeem waarin meerdere referentie componenten zijn gerealiseerd of het kunnen losse componenten zijn. Zie ook de toelichting op de relatie tussen T3D en Common Ground:
Thema Totaal 3D/T3D Common Ground - onderverdeling van de referentiecomponenten naar de Common Ground lagen
Het basismodel voor de referentie componenten komt uit de concept architectuurbeschrijving Voorzieningen Samenhangende Objecten Registratie (SOR). Daaraan zijn een aantal referentiecomponenten toegevoegd die in het kader van T3D zijn onderkend.
De componenten kunnen ook worden geordend per processtap. Hierbij komen een aantal componenten bij meerdere stappen terug.
==Overzicht Applicatiecomponenten==
Thema Totaal 3D/T3D proces

Category:Totaal 3D
Het onderstaande processchema geeft in hoofdlijnen het proces weer voor het inwinnen, registeren en gebruiken van een 3D objectenregistratie. 
Het hier beschreven proces is specifiek gericht op het beheren van 3D objecten. Er zijn gerelateerde processen die gebruik maken van beheerde 3D objecten maar ook processen die kunnen leiden tot nieuwe en gewijzigde 3D objecten. Hetzelfde gerelateerde proces kan bovendien zowel gebruiker als inwinner zijn. Het verlenen van een vergunning kan bijvoorbeeld tot nieuwe/aanvullende informatie leiden rondom een 3D object, die vanuit een inwinbestand (zoals een BIM model) wordt toegevoegd aan een 3D objectenregistratie. 
Dit processchema komt in grote lijnen overeen met het processchema dat in het kader van de samenhangende objectenregistratie (SOR) is opgesteld. De in het kader van het beheren van 3D objecten toegevoegde processtappen kunnen daarbij worden gezien als een verdere verrijking van het SOR processchema.
De genoemde T3D rollen kunnen bij verschillende organisaties/afdelingen/functionarissen worden belegd, maar ook bij dezelfde. 
==Overzicht processtappen==
=Rollen=
=processtappen=
Toegankelijkheid

Categorie:Layout Elements
VNG Realisatie bouwt aan de toegankelijkheid van deze website voor iedereen. De VNG streeft ernaar te voldoen aan de overheidsstandaard WCAG versie 2 op niveau AA. Voldoen aan deze standaard maakt onze website gebruiksvriendelijker en beter toegankelijk voor verschillende doelgroepen.
Hebt u vragen of problemen met de toegankelijkheid van de website, neem dan contact met ons op via GEMMAOnline@VNG.nl.
==Uitzonderingen digitale toegankelijkheid==
* Niet alle pdf-bestanden die toegankelijk moeten zijn, voldoen aan de toegankelijkheidseisen. We zijn bezig om die bestanden alsnog toegankelijk te maken. Bijvoorbeeld door publicatie in html.
==Meer informatie==
Voor meer informatie over toegankelijkheid kijkt u op de website van de rijksoverheid.
Toelichting Open source software

Open source software is software waarvan de broncode openbaar beschikbaar is. Dit betekent dat iedereen de code mag bekijken, gebruiken, wijzigen en verspreiden, vaak onder bepaalde voorwaarden die in een open-sourcelicentie zijn vastgelegd.
De Nederlandse overheid heeft een beleid dat het gebruik van open source software en open standaarden stimuleert. Dit beleid is ingegeven door het streven naar meer transparantie, kostenbesparing, innovatie en onafhankelijkheid van leveranciers. Software die de overheid maakt of laat maken moet zoveel mogelijk open source zijn, behalve als er goede redenen zijn om de software niet beschikbaar te maken (‘Open, tenzij’).
De GEMMA richt als referentiearchitectuur op het beschrijven van breed toepasbare architectuur als hulpmiddel voor gemeenten om hun bedrijfsvoering en informatievoorziening te ontwikkelen. Zij schrijft niet voor via welke aanpak realisatie moet plaatsvinden en of een gemeente van open of closed software gebruik moet maken. Een gemeente kan de GEMMA als basis voor haar architectuur gebruiken en vervolgens zelf bepalen welke software het beste aansluit bij haar lokale behoeften en middelen. Dit laat onverlet dat gezamenlijke gemeentelijke kaders en uitgangspunten met betrekking tot realisatie nuttig kunnen zijn. Programma's zoals Samen Organiseren en Common Ground en coöperatieve verenigingen van gemeenten zoals Dimpact spelen daarin een belangrijke rol. 
De GEMMA spreekt, in lijn met overheidsbreed beleid, wel een duidelijke voorkeur uit voor het gebruik van open boven gesloten standaarden. Open standaarden zijn technische specificaties waarmee software met elkaar kan communiceren en samenwerken, onafhankelijk van de gebruikte technologie of leverancier. Het open karakter zorgt ervoor dat iedereen deze standaarden vrij kan gebruiken, implementeren en doorontwikkelen, wat interoperabiliteit en innovatie bevordert. Open standaarden kunnen worden geïmplementeerd in zowel open source als gesloten software. 
Meer informatie over beleid en gebruik van open source binnen de overheid:
* Algemene informatie en verwijzingen (noraonline.nl).
* Beleidsmatige toelichting (digitaleoverheid.nl).
* Community-site voor het delen van kennis en ervaring (opensourcewerken.nl).
* Toolbox om met open source aan de slag te gaan (opensourcewerken.nl).