Thema Totaal 3D/T3D Pilots/Den Haag/datamodel
Inhoud
Datamodel[bewerken]
Informatiemodel[bewerken]
Het T3D informatiemodel is opgesteld op basis van een aantal gebruiksprocessen van de verschillende gemeenten, gecombineerd met de SOR als basis. Vanuit Den Haag was de use case binnenkant gebouwen hierbij leidend.
Het T3D informatiemodel is vooral opgesteld vanuit de gemeente Rotterdam, en in Den Haag is er niet getest of het inderdaad voldoende basis biedt, of dat er nog veel extra objecttypes noodzakelijk zijn. Het informatiemodel werd laat opgeleverd in het project, en daarom is bij veel van de tests in de gemeente Den Haag uit gegaan van standaard CityGML. Voor een mogelijk vervolg is het een opgave om dit datamodel goed te bekijken en waar nodig aan te passen. Daarin zullen meerdere use cases moeten worden geevalueerd, zoals dat nu bijvoorbeeld met het huisnummerbesluit is gedaan.
Voor meer details over het T3D informatiemodel, zie Thema Totaal 3D/T3D bedrijfsobjecten
Model voor getransformeerde bestanden[bewerken]
In de transformatie is uitgegaan van CityGML als datamodel. In de eerste jaren was dit CityGML 2.0, maar al snel werd duidelijk dat dit te weinig boodt. CityGML 3.0 (het informatiemodel) biedt meer mogelijkheden, en de afspraak is ook om dit als basis te gebruiken. In Den Haag is wel gekeken naar transformatie van bijvoorbeeld BIM bestanden naar dit model (wat prima gaat). Waar niet naar is gekeken, is of CityGML exact aan sluit op het opgestelde T3D informatie model. Deze controle is in Rotterdam uitgevoerd.
Of ook de uiteindelijke 3D objectregistratie in het CityGML formaat gaat zijn is op dit moment nog niet duidelijk. Daarmee is nog geen ervaring opgedaan.
3D object registratie[bewerken]
In Den Haag is een 3D object registratie aanwezig. Die wordt buiten dit project aangemaakt, en wordt af en toe geheel ververst. De methodiek hiervoor is het invliegen van luchtfoto's (obliek en loodrecht), en deze handmatig laten verwerken tot CityGML data. Het is dus geen registratie die van dag tot dag wordt bijgehouden. Voor de gebruiksprocessen die Den Haag er op dit moment mee uit voert, is die informatie up-to-date genoeg.
Of en hoe er in Den Haag gegroeid gaat worden naar een iteratief bijgehouden 3D object registratie is op dit moment niet duidelijk. Daarvoor moet eerst eventueel te gebruiken software worden geevalueerd, en moet beter bekeken voor welke use cases dit van belang is. In Rotterdam is in meer detail gekeken naar een 3D object registratie. Ook moet nog gekeken worden naar de wijzen van ontsluiting van een 3D objectregistratie voor gebruik in andere applicaties.
Level of detail[bewerken]
Bij het opslaan en inwinnen van gegevens kunnen verschillende detailniveau's worden gebruikt. Voor bepaalde businessprocessen is het genoeg als een 3D object als een soort kubus wordt weergegeven, terwijl het voor andere van belang is, of een bijvoorbeeld een pand een deur heeft en waar die deur zit. Zonder uitgebreid op deze detailevels in te willen gaan, is het van van belang om bij elk proces erover na te denken welk detailniveau nodig is. Bij verschillende behoeftes wordt het ook complexer om keuzes te maken in de in te winnen en beheren data.
Koppeling bestanden aan objecten[bewerken]
Op dit moment worden 3D bestanden ingewonnen voor verschillende doeleinden. Soms hebben die bestanden betrekking op een specifiek pand, soms op meerdere objecten. Het is goed om ook na te denken over een wijze van indexering/zoekwoorden waarmee bestanden gevonden kunnen worden vanuit een 2D object registratie om zo 3D informatie te kunnen inzien. Daarmee kan data eenvoudiger in meer gebruiksprocessen beschikbaar worden gemaakt. Een koppeling via Pand-id's ligt voor de hand, maar zal niet altijd mogelijk zijn. Tot nu toe is hier in Den Haag nog niet over nagedacht.
Voor bijvoorbeeld luchtfoto's of Lidar bestanden kan ook gebruik worden gemaakt van geografische relaties (welke bestanden heb ik op deze locatie?). De op te stellen ontologie kan ook helpen om hier een goede opzet voor te maken.