iti
(5
34°
In tegenstelling tot veel GIS-bestanden zijn CAD-datasets
vaak volledig in 3D opgesteld.
Voor elk van deze verschillen geldt dat de grote leveranciers
van CAD-software aanvullende modules verkopen waarmee
een aantal van deze nadelen wordt verholpen. De geboden
oplossingen zijn echter leveranciersafhankelijk en bemoei
lijken derhalve de uitwisseling.
Van CAD naar IFC naar CityCML
Om het gebrek aan een standaardsemantiek in CAD-data te
verhelpen is onder andere de Industry Foundation Classes
(IFC) ontworpen. Dit is een open datamodel dat wordt ge
bruikt in het domein van Building Information Modelling
(BIM). Het bestandsformaat is objectgeoriënteerd en ontwik
keld door de International Alliance for Interoperability (LAI).
IFC ondersteunt alleen bouwwerken, er ontbreken voorzie
ningen op het gebied van infrastructuur, grondwerkmodel
len en wegontwerp. IFC is bedoeld voor informatiebeheer
van de hele levenscyclus van een bouwconstructie, ofwel
van het ontwerp tot de sloop. In Denemarken is het gebruik
van IFC voor publieke werken inmiddels verplicht gesteld.
Daar waar IFC zich ten doel stelt de interoperabiliteit tussen
architecten en ingenieurs te verbeteren, mist het de aanslui
ting met de reeds bestaande standaarden voor GIS-gebruik.
In zekere zin kan worden gesteld dat de interoperabiliteit
met beleidsmakers, planvormers, lcaartvervaardigers en het
beheer en onderhoud daarmee niet tot stand komt. Dit zijn
immers traditioneel groepen die voornamelijk met op GIS-
gebaseerde oplossingen werken. Binnen de cyclus van een in
frastructureel project biedt IFC dus alleen een oplossing voor
de ontwerp- en realisatiefase. De acceptatie van IFC verloopt
Fig. 2. City GML
Themes
vooralsnog langzaam, voor velen is het
formaat te zwaar en complex, terwijl
de te behalen winst nog onduidelijk is.
Een andere relevante standaard in
deze context is CityGML. Dit is een
standaard waarin zowel de geometrie
als de semantiek voor geo-informatie
van stedelijk gebied kan worden vast
gelegd. Voor specifieke vakgebieden
levert CityGML een aanvullingsmoge-
lijlcheid om de data te verrijken met
onderscheidende kenmerken zonder
de semantische uitwisselbaarheid te
schaden. Het is de bedoeling om een
onderscheid te gaan maken tussen
AboveSurfaceObjects en BelowSurface-
Objects. Dan kunnen geologische data
en gegevens van ondergrondse instal
laties gemakkelijker worden gecombi
neerd met 3D-vector-data van de boven
grond. De verwachting is dat CityGML,
dankzij de combinatie van semantiek
en geometrie, objectgeoriënteerde da
tabestanden van verschillende bron
nen (2D en 3D) kan integreren.
CityGML is geïmplementeerd als een
XML-applicatie van de Geographic Mar
kup Language 3 (GML3). GML3 is de
uitbreidbare, internationale, open stan
daard voor de uitwisseling van ruim
telijke gegevens, uitgegeven door het
externalObjectReference»'
cityObjectMember*
O
extemalReference
«Feature»
JVaterObject
«Feature»
LandUse
«Feature»
_Site
«Feature»
CityFurniture
«Feature»
CityModel
«Feature»
_AbstractBuilding
«Feature»
GenericCity Object
«Feature»
CityObjectGroup
«Feature»
_Vegetatior>Object
«Feature»
gml::_FeatureCollection
«Feature»
_TransportationObject
+name[0..*]: gmkCodeType
+informationSystem[0..1): xs:anyURI
ExternalReference
+lod[1 integerBetween0and4
«Feature»
ReliefFeature
+name[1]: xs:string
+uri[1]: xs:anyUR!
«Union»
ExternalObjectReference
+name[1]: xs:string
+codeSpace[0..1]: xs:anyURI
«DataType»
gml::CodeType
+creationDate[0..1]: xs:date
+terminationDate[0..1]: xs:date
«Feature»
CityObject
GEO-INFO 2008-9
