Thema Totaal 3D/T3D Pilots/Den Haag/Architectuur/Proefopstelling
Inhoud
Proefopstelling[bewerken]
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
De kernregistratie en de basisregistratie hebben een onderlinge verhouding zoals beschreven in Thema_Totaal_3D/Contexten_basisregistraties
Overzicht Applicatie componenten[bewerken]
| Element | Beschrijving |
|---|---|
| Azure ADF | Feitelijk ADF (Azure Data Framework). Tooling voor Workflow automation en ETL. De tool gaat over meerdere lagen in het comon ground model heen. |
| Azure WFM | Workflow management binnen ADF. Hier als apart element benoemd omdat het de interface naar andere componenten is. |
| Beheer 3D object registratie | Een nog nader te bepalen applicatie waarmee de 3D object registratie beheerd gaat worden. |
| Inspectie | Een geconverteerd bestand kan visueel geinspecteerd worden (ligt het op de goede plek, is de schaal goed, zitten er geen rare gaten in, etc. ). Het gaat dan om het tonen van een GML bestand in context. Hier kunnen verschillende viewers voor worden gebruikt. |
| Inwin database | Centrale opslag voor ingewonnen data. Nu nog een fictief object |
| Transformatie | Het component Transformatie draagt zorg voor de transformatie van een set aan gegevens volgens de ene standaard naar de andere standaard (bijvoorbeeld BIM naar CityGML) |
| Validatie | Het validatie component zorgt ervoor dat een ingewonnen dataset wordt gevalideerd op basis van vastgestelde validatie regels voordat er een transformatie kan plaatsvinden.
Er kunnen straks verschillende soorten bestanden worden aangeleverd (BIM, LIDAR, PDF, etc.), elk met eigen leveringsspecificaties. Deze worden door verschillende soorten leveranciers ingewonnen. Voordat deze verwerkt gaan worden in de 3D object registratie is het goed om deze eerst te valideren. Hiervoor zijn verschillende componenten (vaak vanuit standaard open source libraries) beschikbaar die via een API worden aangeroepen. Een groot deel van deze validaties is gelijk voor alle gemeenten. Gezamenlijke ontwikkeling lijkt dan ook een optie. |
Overzicht Applicatie interfaces[bewerken]
| Element | Beschrijving |
|---|---|
| Azure ADF API | De API van ADF. |
| Inspectie API | API om de inspectie tooling aan te roepen en een weergave van het CityGML bestand te tonen. |
| Inwin database API | API om de inwin database te ontsluiten |
| Transformatie API | API's van de transformatie tools die vanuit ADF worden aangeroepen. |
| Validatie API | API's van de verschillende validatie tools die vanuit ADF worden aangeroepen. |
Overzicht Data objecten[bewerken]
| Element | Beschrijving |
|---|---|
| 3D data | Het generieke formaat waarin alle ingewonnen data wordt omgezet om vervolgens verwerkt te worden in een basisregistratie.
Dit formaat zou moeten mappen op het generieke datamodel. |
| 3D object registratie | De 3D objectregistratie die het eindproduct is van het inwinnen van 3D data. |
| Ingewonnen data | Dit is een verzamel item voor alle ingewonnen data. Dit kan data in verschillende formaten zijn, maar ook uit verschillende bronnen. Data kan door de gemeente zelf worden ingewonnen, worden aangeleverd door burgers, via projecten, etc. Dit moet nog veel verder worden uitgewerkt. Daarom is er nu voor een generieke component gekozen waar alle data binnenkomt. |
| Procesdata | m.b.t. validatie, transformatie, verwerking |
| Verwijzing ingewonnen data | Als data extern wordt aangeleverd, dan wordt het door de applicatie opgeslagen (via ADF). Als data al aanwezig is bij de gemeente en er is met de leverende partij een duidelijke SLA over de data, dan kan het opslaan van een verwijzing voldoende zijn. Twee keer opslaan van de data is onwenselijk omdat synchronisatie dan ook moet worden ingeregeld. Vandaar dat naast ingewonnen data ook een verwijzing kan worden aangeleverd. |
| metadata ingewonnen data | Naast de ingewonnen data worden er ook gegevesn opgeslagen die beschrijvend zijn (inwindatum, inwinner, reden inwinning, etc.). Deze gegevens worden centraal vastgelegd. |
Overzicht Groeperingen[bewerken]
| Element | Beschrijving |
|---|---|
| (1) Bronnen | Common ground data bronnen laag |
| (2) Ontsluiting | Common ground data ontsluitingslaag |
| (3) integratie | Common ground integratie laag |
| (4) Proceslogica | Common ground proceslogica laag |
| (5) Presentatie | Common ground presentatie laag |
| web interface | ADF heeft zelf geen gebruikersvriendelijke interface. Er moet voor eindgebruikers dus een WebINterface gebouwd worden om ADF te bedienen. Deze interface kan (zoals hier) compleet op ADF worden gebouwd. Hij kan ook generiek worden gemaakt voor meerdere orkestratietools. |
Een weergave van het model waarbij de onderdelen in common ground lagen zijn gesplitst, ziet er als volgt uit: