Architecturale Informatie Modellering - ICT conceptie van een geïntegreerde architecturale ontwerpomgeving

M i c r o s o f t Windows XP Codefragment 6.1: Een gbXML bestand dat door de Demeter plug-in gegenereerd werd uit SketchUp.

6.2.2. UG-EPW Een andere applicatie die tracht in te gaan op energiecalculatie voor de component evaluation of design solutions, is UG-EPW. De basis voor de UG-EPW applicatie is de Vlaamse EnergiePrestatieRegelgeving (EPR), die van toepassing is sinds 1 januari 2006. Beschrij-

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

133

vende informatie over wat deze EnergiePrestatieRegelgeving precies inhoudt, kan gevonden worden op http://www.energiesparen.be/energieprestatie/. Deze informatie wordt hieronder kort verwerkt ter situering van de UG-EPW applicatie. Via de EPR regelgeving wordt vastgelegd dat elk gebouw met een bouwvergunning van na 1 januari 2006, moet voldoen aan specifieke energieprestatienormen. Deze regelgeving is hiervoor onderverdeeld in enkele gebouwspecifieke regelgevingen, zoals EPW voor woningbouw en EPU voor utiliteitsbouw. De na te volgen normen voor private woningbouw (EPW ) zijn drievoudig: het gebouw moet voldoen aan algemene ventilatie-eisen, elk element aan de buitengrens van het gebouw moet presteren volgens de EPR isolatienormen (0.4 w/m2K voor muren en 0.6 W/m2K voor vloeren en daken) en ten derde moet het gebouw voldoen aan algemene isolatie- en energieconsumptienormen (K-45 en E-100).

6

Figuur 6.6.: In de EPB software (links) wordt in vijf stappen (rechts) gebouwinformatie ingevoerd, zodat via de software de resultaten berekend kunnen worden. Drie van deze vijf stappen bestaan daarbij uit zogenaamde ‘Invoer’ stappen.

Deze EPW -regelgeving wordt vergezeld van bestaande EPB calculatiesoftware. In deze software moeten ontwerpers handmatig verschillende karakteristieken van hun ontworpen gebouw invoeren aan de hand van lijsten met gebouwkarakteristieken (figuur 6.6). Als dit juist ingevoerd is, dan wordt de energieprestatie van het gebouw automatisch berekend en wordt zo bepaald of het gebouw al dan niet voldoet aan de wettelijke energieregelgeving. UG-EPW vertrekt specifiek vanuit de EPW -regelgeving voor woningbouw (Verstraeten et al., 2008). De applicatie tracht de drie handmatige invoerstappen en de calculatiestap uit de EPB software (figuur 6.6) te automatiseren in UG-EPW, door de informatie die in BIM

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

134

applicaties ingevoerd wordt, rechtstreeks te importeren en hierop een EPB berekening uit te voeren (Verstraeten et al., 2008). Op dit moment is de eigenlijke UG-EPW applicatie ontwikkeld in zijn eerste fase en wordt ze ge¨evalueerd en verbeterd (Verstraeten et al., 2008). De applicatie zou in staat moeten zijn om de nodige gebouwdata voor de EPB berekening te extraheren uit een IFC of een gbXML dataformaat (Verstraeten et al., 2008), op voorwaarde dat deze bestanden de nodige informatie wel degelijk bevatten. Na een korte grafische en tekstuele controle van de weergegeven data in UG-EPW wordt de berekening automatisch uitgevoerd en zijn de resultaten onmiddellijk zichtbaar onder de vorm van verschillende isolatie- en ventilatiewaarden die vergeleken worden met de eisen van de EPW -regelgeving (Verstraeten et al., 2008).

6

Figuur 6.7.: UG-EPW grafische voorstelling en datavoorstelling.

Behalve binnen BIM kan UG-EPW ook een belangrijke toepassing hebben binnen expliciete schetsomgevingen of virtuele voorontwerpomgevingen (Verstraeten et al., 2008). Door de integratie van UG-EPW in een schetsmatige voorontwerpomgeving zou UG-EPW het mogelijk maken om het allereerste ontwerp objectief te vergelijken met de verplichte energieprestatieregelgeving in Vlaanderen, zodat ontwerpbeslissingen hiernaar kunnen genomen worden van in de vroegste fase van het ontwerpproces (Verstraeten et al., 2008). Daarom werd, bij wijze van test, een uitbreiding op de Google SketchUp schetsomgeving ontwikkeld en ge¨evalueerd (Verstraeten et al., 2008). Door het gebruiken van de Demeter plug-in binnen SketchUp (§ 6.2.1), wordt een minimale hoeveelheid aan informatie, namelijk details van elke ruimte en van elk tussenliggend scheidingselement (§ 6.2.1), toegevoegd aan de louter geometrische data die SketchUp kent (§ 6.2.1). Deze informatie zou via het gbXML dataformaat (§ 6.2.1) ingevoerd kunnen worden binnen UG-EPW (Verstraeten et al., 2008). Hiervoor wordt gebruik gemaakt van een eigen ontwikkelde XML converter, die het gbXML bestand omzet naar het intern gebruikt dataformaat van UG-EPW. Binnen UG-EPW kun-

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

135

nen vervolgens benaderende energieprestatiewaarden worden berekend van dit voorlopige voorontwerp. Indien nodig kan vervolgens teruggekeerd worden naar Google SketchUp om het voorontwerp aan te passen aan de gevonden waarden uit de UG-EPW applicatie (Verstraeten et al., 2008).

6.3. Lights & Acoustics Calculation 6.3.1. Ecotect Ecotect is een applicatie die specifiek ontwikkeld werd om de architect een hulpmiddel aan te bieden dat berekeningen uitvoert tijdens de voorontwerpfase, op basis waarvan ontwerpbeslissingen genomen kunnen worden (Marsh en Roberts, 2001). De basis voor het programma werd reeds gelegd in het doctoraatsproefschrift van Andrew Marsh (Marsh, 1997) en in enkele publicaties uit dezelfde periode (Marsh, 1996b,a). Oorspronkelijk werd Ecotect bedoeld als een ‘Integrated Performance Modelling Tool (Marsh, 1996a). Dat wil zeggen dat zou getracht worden om de applicatie zodanig uit te werken dat tijdens het modelleren van een vroeg voorontwerp onmiddellijk berekeningen hierop zouden uitgevoerd worden (Marsh, 1996b,a). Deze feedback gebeurt voor heel uiteenlopende factoren, zoals akoestische en thermische performantie, zonlichttoetreding, beschaduwing, belichtingsniveaus, enzovoort (Marsh, 1996a). Via deze feedback zou de ontwerper in staat moeten zijn om tijdens het ontwerpproces verschillende ontwerpalternatieven af te wegen en tegelijk hun impact op de gebouwperformantie te beschouwen (Marsh, 1996a) (evaluation of design solutions). Andrew Marsh was in 1994 ´e´en van de mede-oprichters van Square One 4 , door wie de Ecotect applicatie uitgewerkt en ge¨ımplementeerd zouden worden, naast andere applicaties zoals The Weather Tool en The Solar Tool (http://www.squ1.com/). Vandaag laat Ecotect toe om in de applicatie zelf een driedimensionaal voorontwerp als in figuur 6.8 te modelleren, maar het zou volgens de gegeven informatie op de Square One webpagina even goed mogelijkheden moeten hebben naar het importeren van bestaande driedimensionale modellen uit bijvoorbeeld Google SketchUp en Graphisoft ArchiCAD. Eens het model ingeladen of uitgetekend is in Ecotect, kunnen data gespecifieerd worden die gebruikt zouden kunnen worden als basis om benaderende voorontwerpanalyses uit te voeren (evaluation of design solutions, zoals bijvoorbeeld thermische en akoestische performantieberekeningen, daglichtsimulaties en lichtstudies (Marsh, 1996a; Marsh en Roberts, 2001). Naar de resultaten van deze voorontwerpanalyse (figuur 6.9) zou het oorspronkelijk uitgete4

Square One - http://www.squ1.com/

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

136

Figuur 6.8.: Een driedimensionaal model zoals het in Ecotect gehanteerd wordt, na modellering binnen Ecotect of na importeren vanuit een externe driedimensionale modelleeromgeving.

Figuur 6.9.: Grafische visualisatie in Ecotect van informatie, die automatisch ingeladen wordt op basis van reeds ingegeven data door de gebruiker (bv. gebouwlocatie) (Marsh en Roberts, 2001).

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

137

kende of ingeladen voorontwerp verder gedetailleerd en fijngesteld kunnen worden, waarna het, bij een voldoende hoge graad van gedetailleerdheid, zou ge¨exporteerd kunnen worden voor een meer gedetailleerde ontwerpanalyse (Marsh en Roberts, 2001). Deze exporteermogelijkheid werd in Marsh en Roberts (2001) bijvoorbeeld voorgesteld naar de dataformaten RADIANCE, VRML en DOE-2. Op basis van de positieve studentencommentaren in Marsh en Roberts (2001) werd de Ecotect applicatie verder uitgewerkt. In Marsh (2003) werd als volgende stap geopteerd om de uitgebreide rekentechnieken van Ecotect, op het vlak van schaduwberekening bijvoorbeeld, te gebruiken om de applicatie zelf ontwerpvoorstellen te laten doen, bijvoorbeeld voor het genereren van de vorm van zonweringen (Marsh, 2003). In Marsh (2005) wordt dit verder ontwikkeld tot een nieuwe benadering voor de applicatie, namelijk een expliciet rekenkundige benadering (‘Computational Approach’ ). Er wordt gesteld door Marsh (2005) dat de ‘traditionele ‘design-validate-redesign’ benadering aan bestaansrecht inboette, ten voordele van een benadering, waarbij regelgevingen en parameters aan de basis liggen van een zogenaamd automatisch gegenereerd ontwerp. Deze regelgevingen en parameters kunnen daarbij volgens Marsh (2005) uiteenlopende vormen aannemen, zoals bijvoorbeeld de geldende wetgeving op de locatie van het gebouw, of de gebouwen die zich in de omtrek van de locatie bevinden.

Figuur 6.10.: Voorbeeld van hoe berekend kan worden wat het effect is van de omgeving op een gebouw voor daglichttoetreding, waarop door Ecotect een bepaald ontwerpalternatief kan voorgesteld worden, eventueel op basis van genormeerde minimumeisen (Marsh, 2005).

Ter illustratie wordt in figuur 6.10 getoond hoe de omgeving van een gebouw de daglichttoetreding van een gebouw kan be¨ınvloeden, waardoor de ene ontwerpoplossing zou kunnen verkozen worden boven de andere (Marsh, 2005). Een tweede voorbeeld, dat specifiek ingaat op een regelgevende randvoorwaarde op het

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

138

ontwerp, wordt weergegeven in figuur 6.11 en beschreven in Marsh (2005). Links in deze figuur wordt een ontwerp afgebeeld dat uitgetekend is binnen Ecotect en voorgesteld is (‘proposed’ ) om dit te controleren met geldende normen voor energiezuinigheid (Marsh, 2005). Nadat een energetische simulatie en een controle van de resultaten met de regelgeving is uitgevoerd, wordt door Ecotect een nieuw ontwerpvoorstel gedaan (‘notional’ ), waarin delen van het ontwerp aangepast zijn om te voldoen aan deze geldende normen (Marsh, 2005).

Figuur 6.11.: Automatische herwerking door Ecotect van een ontwerpalternatief dat voldoet aan de geldende normering voor het gebouw in kwestie op het vlak van energiezuinigheid.

6 6.4. Design Program Simulation 6.4.1. Trelligence Affinity Trelligence Affinity is een simulatieprogramma dat ontwikkeld werd door Trelligence Inc.5 en in 2006 op de markt is gebracht in de Verenigde Staten. Dit programma werd ontwikkeld op basis van intern R & D, zodat voor onderstaande beschrijvende informatie moest teruggevallen worden op de informatie die op de eigen website van Trelligence Inc. gegeven werd. “Trelligence Affinity software is an extension of BIM that adds the Program Model into the architectural business process of planning, designing and constructing a building. Affinity focuses on architectural programming and schematic design giving the entire AECO (Architecture, Engineering, Construction and Owner/Developer) team a platform for communicating the requirements for a building project.” - http: // www. trelligence. com/ Uit de beschrijvingen op de website van Affinity, zoals deze hierboven, werd afgeleid dat Affinity werd ontwikkeld als een applicatie die werkt volgens een BIM -gebaseerde benadering, maar dat zich hierbij specifiek richt op de voorontwerpfase v´ o´ or de uitwerking in BIM applicaties. Zoals lijkt geschematiseerd te worden in figuur 6.12, wordt door Trelligence 5

Trelligence, Architectural Programming and Schematic Design, http://www.trelligence.com/

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

139

Affinity getracht om een ‘Program Model’ uit te werken die de specifieke eisen (‘design requirements’ ) naar het in te vullen programma van het gebouw (‘Program’ ) beheert, op een gelijkaardige manier als de manier waarop het Building Information Model of het ‘Building Model’ de informatie over de eigenlijke uit te voeren gebouwcomponenten bevat.

6 Figuur 6.12.: Schematische situering van het ‘Program Model’ van Affinity en de geboden functionaliteiten van Affinity (weergegeven in het geel), ten opzichte van een ‘Building (Information) Model’ (http://www.trelligence.com/).

Bovenop de informatie uit dit centrale ‘Program Model’ werden de verschillende functionaliteiten van Affinity uitgewerkt en ge¨ımplementeerd (figuur 6.12). 1. datainvoer (‘Data Gathering’ ) 2. management van ‘ontwerpeisen’(‘Requirements Mgmt’ ) 3. ruimtelijke planning (‘Space Planning’ ) 4. ontwerpanalyse ‘Design Analysis’ Op de website van Affinity wordt daarnaast kort de functionaliteit en de werkmethode voorgesteld voor het gebruik van de applicatie. Dit kon binnen deze scriptie echter niet gecontroleerd of geverifieerd worden, net zoals de overige informatie in deze beschrijving van Affinity. Nadat het volledige ‘Program Model’ conceptueel is uitgewerkt in Trelligence Affinity, wordt voorgesteld om het geheel te exporteren naar de gewenste BIM applicaties of naar gedetailleerdere kostencalculatie- of planningapplicaties. Affinity zou zo volledig compatibel

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

140

ge¨ımplementeerd zijn met de twee BIM applicaties Autodesk Revit en Graphisoft ArchiCAD. Hierbij wordt zelfs gesteld dat een terugkoppeling voorzien is naar vanuit deze BIM applicaties naar Affinity, zodat het mogelijk zou zijn om nog in een late fase te controleren of het ontwerp nog aan de gestelde ‘design requirements’ voldoet.

6.4.2. AMCE Algemene doelstelling Het onderzoeksproject naar een ‘Aid to the Multiple criteria Conception of the building Envelope (AMCE)’ is uitgevoerd aan het Laboratoires d’Etudes M´ethodologiques Architecturales (LEMA) van de Universiteit Luik in de periode 1998 tot 2001 (Hauguslaine, 2000). Het project werd gestart naar aanleiding van de parametrische mogelijkheden van de EsQUIsE ontwerpomgeving (§ 9.2.9), die ongeveer in dezelfde periode ontwikkeld werd aan het Laboratoire d’Electromagn´etisme et Acoustique (LEMA) (Leclercq, 1999; Juchmes et al., 2004). Als doel werd in Hauguslaine (2000) gesteld dat, in de vorm van een gepast softwarepakket, een medium moest kunnen geboden worden om bepaalde ontwerpcriteria of -eisen gestructureerd in te kunnen voeren voor gebruik binnen de EsQUIsE ontwerpomgeving. Deze ontwerpomgeving zou dergelijke ontwerpcriteria en -eisen uit dit softwarepakket volgens Hauguslaine (2000) namelijk kunnen gebruiken om reeds een benaderend voorontwerp uit te werken, of om minstens het ontwerp dat door de gebruiker samengesteld wordt, te toetsen aan deze ontwerpcriteria (evaluation of design solutions). Om dit doel te bereiken werd in Hauguslaine (2000) een Multiple Criteria Decision Aid (MCDA) procedure voorgesteld die zou ge¨ımplementeerd worden in het AMCE softwarepakket. In deze procedure zouden waarden gegeven worden aan uiteenlopende gebouwcriteria die van belang kunnen zijn in de voorontwerpfase, waarna deze waarden samengevoegd zouden worden in een gestructureerd overzicht dat gebruikt kan worden binnen de EsQUIsE ontwerpomgeving (Hauguslaine, 2000). Deze MCDA procedure werd een eerste maal ge¨ımplementeerd in het AMCE softwarepakket zoals het in Hauguslaine (2000) beschreven wordt. Deze eerste implementering werd nog niet ge¨ıntegreerd met de EsQUIsE ontwerpomgeving en beperkte zich met andere woorden tot de zuiver tekstuele AMCE interface en het uitvoeren van een evaluatie op basis van de gegevens uit die interface (Hauguslaine, 2000). Onderstaande beschrijving van het vroegst ge¨ımplementeerde AMCE softwarepakket werd volledig op Hauguslaine (2000) gebaseerd.

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

141

Eerste implementering Via de AMCE software kunnen in eerste instantie verschillende evaluatiecriteria tekstueel ingevoerd worden voor gebruik in een evaluation of design solutions. Deze criteria kunnen gaan van energetische aspecten tot eerder constructieve of financi¨ele aspecten. Niet elk project hoeft echter volgens al deze criteria even veel afgewogen te worden. In een eerste versie (Hauguslaine, 2000) werd daarom de term ‘Actor’s Preferences’ ingevoerd, een mogelijkheid waarlangs de verschillende partijen (‘Actors’ ) in het ontwerpproces (architect, bouwheer, aannemer, . . . ) zouden kunnen aanduiden welke criteria hij in rekening wil brengen om het virtuele voorontwerp te evalueren (figuur 6.13).

6

Figuur 6.13.: In AMCE kunnen deze twaalf criteria aangeduid worden door de verschillende actoren in het bouwproject (Hauguslaine, 2000). Bij een daaropvolgende simulatie zullen enkel deze criteria in rekening gebracht worden om ontwerpalternatieven onderling te vergelijken.

Wanneer de verschillende partijen deze criteria gekozen hebben, kan in de AMCE software vervolgens door elk van hen een ‘scenario’ gedefinieerd worden, waarin aangeduid wordt in hoeverre elk criterium in rekening gebracht zou moeten worden. In figuur 6.14 wordt dit ge¨ıllustreerd voor de partij ‘Owner’ in het ontwerpproces. Wanneer de verschillende actoren aan de hand van verschillende scenario’s gespecifieerd hebben welke ontwerpcriteria volgens hen tot op een bepaald niveau in rekening gebracht zouden moeten worden in de evaluatie van een voorgesteld ontwerp, wordt een eerste ontwerpvoorstel gegenereerd. Aangezien het AMCE softwarepakket in deze eerste implementering nog

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

142

Figuur 6.14.: De definite van een ‘scenario’ in AMCE.

6 niet gekoppeld was aan de grafische schetsomgeving van EsQUIsE, werd dit voorstel volledig manueel gedaan door parameters in te voeren in een tekstuele interface (figuur 6.15). Deze tekstuele interface kan volgens Hauguslaine (2000) beschouwd worden als een soort ‘vragenlijst’, waarin de ontwerper gevraagd wordt om verschillende eigenschappen van het ontworpen gebouw in te geven. Aangezien AMCE oorspronkelijk vooral werd bedoeld als een applicatie waarin de energetische aspecten van het gebouw ge¨evalueerd werden (Hauguslaine, 2000), bestaat deze vragenlijst (figuur 6.15) voor een groot stuk uit thermische en geometrische eigenschappen (‘Fenestration’, ‘Thermal charact.’, ‘Geometry Details’, . . . ). In deze interface wordt bij het opstarten reeds een standaardwaarde ingegeven door de software, die bestaat uit een aangenomen gemiddelde waarde van de eigenschap in kwestie voor een ontwerp. De gebruiker kan elk van deze standaardwaarden aanpassen, waarna deze aangepaste waarde in het vet wordt weergegeven (figuur 6.15). De ingegeven waarden worden door het AMCE softwarepakket herkend als ontwerpparameters, waarmee in een volgende stap een (energetische) simulatie kan uitgevoerd worden die automatisch getoetst wordt aan de vooropgestelde evaluatiecriteria uit de scenario’s (figuur 6.14). In figuur 6.16 wordt een voorbeeld gegeven van het resultaat van een dergelijke simulatie. In dit resultaat staan links de in rekening genomen evaluatiecriteria, bovenaan de benaming van de verschillende scenario’s en centraal en rechts de mate waarin elk scenario voldoet aan de criteria, respectevelijk in een tekstuele en grafische weergave.

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

143

Figuur 6.15.: Het parametrisch doorgeven van een ontwerpvoorstel in AMCE, via een tekstuele interface.

Figuur 6.16.: De resultaten van een uitgevoerde berekening en evaluatie in AMCE.

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

144

In de grafische weergave wordt elk evaluatiecriterium per scenario op een lineare schaal geplaatst, met de kleur van de verbindingslijn gelijk aan de kleur van het scenario. Op die manier worden de relatieve posities van de verschillende scenario’s aangeduid ten opzichte van elkaar. Bovendien wordt in de grafische weergave (figuur 6.16) aangeduid wanneer aan bepaalde criteria ni´et voldaan zou zijn (rode of groene vierkantjes). Uit figuur 6.16 valt bijvoorbeeld af te leiden dat het tweede scenario van de Owner het best voldoet aan zijn evaluatiecriteria, waarbij het echter minst presteert op het criterium ‘¤Construction’ en het niet voldoet aan het criterium ‘¤Heating+DHW’. Tweede implementering Voorafgaand aan de tweede implementering werd onderzocht wat de mogelijkheden konden zijn van de combinatie van parametrische simulatiesoftware voor calculatie en evaluatie, zoals AMCE, met een virtuele ontwerpomgeving, zoals EsQUIsE. Dit onderzoek en zijn resultaten worden gepresenteerd in Leclercq (2001) en kan worden samengevat aan de hand van figuur 6.17.

Figuur 6.17.: Schematische beschouwing van het ontwerpproces en de wijze waarop de ICT applicaties AMCE en EsQUIsE, naast bestaande CAAD-tools, hierin gesitueerd kunnen worden volgens Leclercq (2001).

In deze figuur 6.17 wordt een schematische beschouwing gegeven van het ontwerpproces en de manier waarop de verschillende ontwikkelde ICT applicaties hierin een rol kunnen spelen. Dit proces valt volgens Leclercq (2001) uiteen in de zes volgende stappen. 1. ‘Constraints & Objectives’ : samenstelling van de op te leggen randvoorwaarden en te halen doelstellingen voor het ontwerp 2. ‘Feasibility’ : uitvoeren van een haalbaarheidsstudie, waarin de randvoorwaarden en doelstellingen vergeleken worden met heel algemene gebouwkenmerken (compactheid, percentuele hoeveelheid beglazing, . . . )

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

145

3. ‘Sketch’ : uittekenen van verschillende ontwerpmatige schetsen, waarbij getracht wordt steeds beter aan opgelegde randvoorwaarden en doelstellingen te voldoen (cfr. groeiende curve ‘Basic Performance’ - ‘Performances’ in figuur 6.17) 4. ‘Production’ : productie van de uitvoeringsplannen, uitvoering van laatste berekeningen, . . . 5. ‘Construction’ : uitvoering van het ontwerp 6. ‘Use’ : ingebruikname van het gebouw

Waar de EsQUIsE ontwerpomgeving door Leclercq (2001) vooral in de derde stap ‘Sketch’ gesitueerd werd, zou de toepassing van AMCE voor het ontwerp volgens Leclercq (2001) in feite over de hele curve ‘Basic Performance’ - ‘Performances’ uit figuur 6.17 kunnen gesitueerd worden (met evenwel een belangrijke nadruk op de tweede stap, ‘Feasibility’ ). Om tot deze groeiende curve te komen, zou volgend proces doorlopen kunnen worden (Leclercq, 2001). In de eerste plaats wordt een voorontwerpschets uit EsQUIsE ingevoerd in de AMCE applicatie. Uit de hierin uitgevoerde berekeningen en evaluaties zou het ontwerp telkens opnieuw verder fijngesteld kunnen worden in EsQUIsE om uiteindelijk tot op voldoende hoogte te voldoen aan de vooropgestelde randvoorwaarden en doelstellingen van het ontwerp (Leclercq, 2001). Op dat moment kan vervolgens overgestapt worden naar gespecialiseerde ‘CAAD tools’ (figuur 6.17, Leclercq (2001)) om de uiteindelijke uitvoeringsplannen uit te werken (‘Production’ ). Bij de tweede implementering werd daarom vooral ingegaan op de tweede en de derde fase van het schema in figuur 6.17. Er werd getracht om de 62 ge¨ımplementeerde, parametrische gebouweigenschappen (Leclercq, 2001), die hierboven enkel tekstueel konden ingegeven worden (figuur 6.15), te baseren op de gegevens uit een eerste versie van de virtuele EsQUIsE schetsomgeving, zoals deze beschreven staat in Leclercq (2001). Met deze schetsomgeving was het toen reeds mogelijk om een virtueel gebouwmodel uit te tekenen zoals weergegeven in figuur 6.18 (Leclercq, 2001). Kort samengevat, werd het volgens Leclercq (2001) door de koppeling van EsQUIsE en AMCE mogelijk gemaakt om vanuit EsQUIsE de juiste gegevens uit de schetsomgeving te halen en de tekstueel ingevoerde gegevens in AMCE zich hieraan te laten aanpassen, zoals weergegeven is in figuur 6.19. In AMCE zouden deze gegevens vervolgens ge¨evalueerd kunnen worden volgens de ingegeven evaluatiecriteria, waarna het ontwerp terug zou aangepast kunnen worden in EsQUIsE, enzovoort (Leclercq, 2001).

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

146

Figuur 6.18.: Voorbeeld van een driedimensionaal gebouwmodel dat in de EsQUIsE schetsomgeving (Leclercq, 2001) geconstrueerd werd door de extrusie van tweedimensionale ontwerpschetsen.

6

Figuur 6.19.: Automatische aanpassing van de 62 tekstuele gebouwparameters in AMCE volgens gegevens uit de EsQUIsE ontwerpomgeving.

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

147

6.5. Building Permit Simulation 6.5.1. Digital Dormer Algemene Doelstelling In 2004 werd in Nederland (Rotterdam - Eindhoven) een project gestart voor de uitwerking van een applicatie voor de automatische evaluatie van bouwvergunningen, op basis van een eigen uitgewerkt informatiemodel (‘The Digital House’ ) dat door de bouwheer aangemaakt wordt (van Leeuwen et al., 2004). Het project werd ‘De Digitale Dakkapel’ of ‘The Digital Dormer’ genoemd en werd uitgewerkt door de Stichting JANUS, een samenwerkingsverband tussen ‘De Twee Snoeken’ en de faculteit Bouwkunde (BWK) van de Technische Universiteit Eindhoven. De aanleiding van het project werd gevormd door het grote aantal bouwvergunningsaanvragen dat ingediend werd in Nederland (van Leeuwen et al., 2004; Jessurun et al., 2004). Zo werden volgens van Leeuwen et al. (2004) en Jessurun et al. (2004) in 2004 jaarlijks gemiddeld 3500 bouwvergunningsaanvragen ingediend, waarvan 20 procent (300 aanvragen) handelde over dakkapellen of ‘dormers’ als uitbreidingen aan bestaande gebouwen. Met als doel een vermindering van de hoeveelheid administratief werk, zowel aan de zijde van de aanvrager als aan de zijde van de instanties die de vergunningen verlenen, werd door van Leeuwen et al. (2004) en Jessurun et al. (2004) als doel van het ‘Digital Dormer’ project een gebruiksvriendelijke webapplicatie vooropgesteld voor het uitwerken en aanvragen van vergunningen voor deze dakkapellen. Om voldoende doelgerichtheid mogelijk te maken, werd in Jessurun et al. (2004) gesteld dat de webapplicatie de aanvrager voldoende zou moeten kunnen assisteren als hem volgende elementen aangeboden worden. 1. gedetailleerde en juiste informatie voorzien over de omgeving en de site in kwestie 2. feedback geven op basis van correcte informatie rond de regelgevingen die van toepassing zijn 3. hulp aanbieden voor het controleren van het ontwerp ten opzichte van deze regelgevingen 4. plannenmateriaal genereren voor het indienen van de uiteindelijke aanvraag 5. een link aanbieden naar een portaal waar plaatselijke bouwbedrijven en aannemers een offerte zouden kunnen plaatsen voor (een deel van) het project

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

148

De webapplicatie werd na uitwerking online beschikbaar gemaakt6 . Na aanmelding en registratie in deze webapplicatie, kan hier informatie gevonden worden over de applicatie of kan een aanvraag ge¨evalueerd worden. Het is ni´et mogelijk om de uiteindelijke aanvraag ook effectief in te dienen voor goedkeuring door de Nederlandse overheid (van Leeuwen et al., 2004; Jessurun et al., 2004). Deze applicatie is dus enkel opgebouwd als een middel voor evaluatie om de nadien volgende, ‘traditionele’ aanvraagprocedure eventueel vlotter te kunnen laten verlopen (van Leeuwen et al., 2004; Jessurun et al., 2004). Uitgeteste evaluatieprocedure Bij wijze van test voor de mate waarin de applicatie tracht in te spelen op het ontwerpaspect evaluation of design solutions, werd binnen deze scriptie een aanvraagprocedure uitgevoerd in de Digital Dormer applicatie. Op basis daarvan werd de volgende algemene beschrijving opgesteld van de werking van het ‘Digital Dormer’ systeem. De procedure van de Digital Dormer evaluatie verloopt in twaalf chronologische stappen, waarbij na elke stap een deel van de informatie ingegeven wordt door de gebruiker. De twaalf stappen zouden op basis van de uitgevoerde test als volgt onderverdeeld kunnen worden. • indienen van eigen adresgegevens – Stap 1: Adresgegevens • indienen van informatie over het gebouw zelf – Stap 2: Dakvorm – Stap 3: Ori¨entatie – Stap 4: Woning • indienen informatie over de gewenste dakkapel – Stap 5: Dakzijde – Stap 6: Type dakkapel – Stap 7: Afmetingen dakkapel (figuur 6.20) – Stap 8: Kozijn – Stap 9: Materiaal en Kleur (figuur 6.21) • verwerking en output van de resultaten door het systeem – Stap 10: Bouwkundig advies – Stap 11: Tekeningen 6

Digital Dormer / Digitale Dakkapel - http://www.digitaledakkapel.com/

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

149

– Stap 12: Aanvraag Het resultaat van de evaluatieprocedure bestaat uit een bouwkundig advies, de resulterende tekeningen uit ‘stap 11: Tekeningen’ en een mogelijkheid om online offertes aan te vragen bij lokale bouwfirma’s. In figuur 6.20 en 6.21 wordt een illustratie gegeven van twee stappen in de aanvraag waarin respectievelijk informatie moet gegeven worden over de vorm van de dakkapel (stap 7: Afmetingen dakkapel) en over de gevraagde materialiteit van de dakkapel (Stap 9: Materiaal en Kleur).

6

Figuur 6.20.: De gebruikersinterface van Digital Dormer : invoer van de afmetingen van de dakkapel (Stap 7).

Conceptie & uitwerking van de software Om een controle uit te kunnen voeren van de consistentie van de ingevoerde informatie en van de mate waarin de aanvraag zou voldoen aan regelgevingen en normeringen, wordt door van Leeuwen et al. (2004) voorgesteld om achter de webinterface van de Digital Dormer applicatie een parametrisch informatiemodel van het gebouw op te bouwen. Dit parameterisch model zou hierbij gebaseerd worden op vooraf uitgewerkte, parametrische ‘sterotypes’ uit Autodesk 3ds Max en op de informatie die tekstueel door de gebruiker ingegeven wordt in de webapplicatie (Jessurun et al., 2004). Deze twee elementen (stereotypes - ingevoerde informatie) zouden volgens van Leeuwen et al. (2004) zodanig op elkaar moeten afgestemd worden, dat een voldoende solide werkwijze en

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

150

Figuur 6.21.: De gebruikersinterface van Digital Dormer : invoer van de te gebruiken materialen (Stap 9).

opbouw van het model kan gegarandeerd worden. Hiervoor werd in Jessurun et al. (2004) een gepaste systeemarchitectuur en werkwijze uitgewerkt, waarvan een schematische voorstelling gegeven wordt in figuur 6.22. De software architectuur achter de Digital Dormer applicatie koppelt de twee aangehaalde elementen, stereotypes en ingevoerde informatie, als volgt. Aan de ene zijde van de applicatie wordt de gebruiker geplaatst, die de informatie manueel kan invoeren via het HTTP protocol, en aan de andere zijde wordt een Perl Scripting Engine geplaatst, die de eigenlijke parametrische handelingen kan uitvoeren (figuur 6.22).

Figuur 6.22.: De systeemarchitectuur achter de Digital Dormer applicatie.

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

151

Deze zogenaamde parametrische handelingen van de Perl Scripting Engine gebeuren, zoals te zien is in figuur 6.22, op twee niveaus (Jessurun et al., 2004). Enerzijds wordt de informatie die ingevoerd is in de webapplicatie, aan de overeenkomstige parameters van de 3ds Max stereotypes gekoppeld, en anderzijds wordt via deze Perl Scripting Engine ook een actieve ‘code checking’ gedaan (Jessurun et al., 2004). Parametrisch informatiemodel Het schema dat gevolgd wordt voor de opbouw van het parametrisch informatiemodel, werd volgens Jessurun et al. (2004) uitgewerkt in zes onderdelen aan de zijde van de gebruiker en drie onderdelen aan de zijde van de applicatie of server (figuur 6.23). Binnen deze scriptie worden deze onderdelen, op basis van de uitgeteste en beschreven evaluatieprocedure en op basis van de beschreven software architectuur, licht verschillend gestructureerd (figuur 6.23), zodat de eigenlijke opbouw van dit parametrisch informatiemodel voldoende duidelijk kan beschreven worden. 1. Selectie van stereotypes De twee onderdelen die de basis lijken te leggen voor de opbouw van het eigenlijke parametrische model, zijn de onderdelen ‘Select Stereotype House’ en ‘Select Dormer Type’ (aangeduid in het geel in figuur 6.23). Zoals bleek uit de test werd in de twee corresponderende stappen van de webapplicatie (‘stap 2: Dakvorm’ en ‘stap 6: Type dakkapel’) aan de gebruiker gevraagd om een stereotype uit te kiezen voor de vorm van respectievelijk het huis en de dakkapel. In Jessurun et al. (2004) is bepaald dat, op het moment dat dit Stereotype gekozen wordt, een vooraf aangemaakt, parametrisch deelmodel van het gekozen type (figuur 6.24) zou moeten ingeladen worden via de Perl Scripting Engine (figuur 6.22). Zo wordt voor een huis met een traditioneel zadeldak bijvoorbeeld een model met volgende vier parameters ingeladen: breedte en diepte van het huis, hoogte van de nok en hoogte van de dakgoot (figuur 6.25). 2. Invoer van geometrische parameters Via de onderdelen ‘Dimension House’ en ‘Place and Dimension dormer’ (aangeduid in het rood in figuur 6.23), worden vervolgens de geometrische parameters van het huistype en het dakkapeltype door de gebruiker gespecifieerd om het parametrisch model correct op te kunnen bouwen (Jessurun et al., 2004). Deze twee onderdelen lijken overeen te komen met ‘stap 3: Ori¨entatie’ en ‘stap 7: Afmetingen dakkapel’ van de uitgevoerde test. 3. Invoer van niet-geometrische parameters

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

152

6 Figuur 6.23.: Het chronologisch stappenschema voor de opbouw van een informatiemodel in de Digital Dormer applicatie. Binnen deze scriptie werden deze geherstructureerd in vijf onderdelen: selectie van stereotypes (geel) - invoer van geometrische parameters (rood) - invoer van niet-geometrische parameters (groen) - code checking (blauw) output van resultaten (grijs)

Figuur 6.24.: Na het kiezen van een bepaald type dak (a) en dakkapel (b) wordt het informatiemodel uitgebreid met een vooraf aangemaakte geometrie en zijn bijhorende parameters.

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

153

Figuur 6.25.: Voorbeeld van een Digital Dormer informatiemodel met vier zichtbare parameters: breedte en diepte van het huis, hoogte van de nok en hoogte van de dakgoot.

Naast de geometrische parameters van het dak en zijn dakkapel moeten ook nietgeometrische parameters invoerd worden in het informatiemodel om een evaluatie uit te kunnen voeren in de Digital Dormer applicatie. Dit gebeurt via de onderdelen ‘Input post code + house number’ en ‘Non-geometric parameters’ (aangeduid in het groen in figuur 6.23). Deze onderdelen lijkt overeen te komen met ‘stap 1: Adresgegevens’, ‘stap 4: Woning’, ‘stap 5: Dakzijde’, ‘stap 8: Kozijn’ en ‘stap 9: Materiaal en Kleur’ in de uitgeteste evaluatieprocedure. De niet-geometrische parameters worden toegevoegd aan het model omdat hiermee bijvoorbeeld enkele specifieke stedenbouwkundige eisen voor het gebouw (bv. uniformiteit in straatbeeld) gecontroleerd kunnen worden (van Leeuwen et al., 2004; Jessurun et al., 2004). Zo kan bijvoorbeeld in ‘stap 1: Adresgegevens’ ingegeven worden waar het gebouw zich precies bevindt, waarmee kan nagekeken worden welke stedenbouwkundige regelgevingen op het gebouw van toepassing zijn. In ‘stap 8: Kozijn’ en ‘stap 9: Materiaal en Kleur’ kan door middel van niet-geometrische parameters gespecifieerd worden welk materialen gebruikt worden voor de verschillende onderdelen van de dakkapel (figuur 6.21). Volgens van Leeuwen et al. (2004); Jessurun et al. (2004) zou deze informatie vervolgens gebruikt kunnen worden voor het genereren van de plannen voor een vergunningsaanvraag en voor het doorgeven van informatie aan lokale aannemers voor het opstellen van een prijsofferte. 4. code checking

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

154

In het onderdeel ‘Code checking’ (aangeduid in het blauw in figuur 6.23), worden de controles uitgevoerd (‘code checking’ ) door de Perl Scripting Engine om het model te evalueren naar uiteenlopende aspecten (van Leeuwen et al., 2004; Jessurun et al., 2004). Dit onderdeel lijkt geen evenwaardige stappen te hebben in de uitgeteste evaluatieprocedure, omdat dit logischerwijs een onderdeel dat volledig door de applicatie / server gedaan moet worden en dus geen invoer of uitvoer van informatie verwacht van of naar de gebruiker. Volgens van Leeuwen et al. (2004); Jessurun et al. (2004) worden opeenvolgend de drie volgende controles uitgevoerd. a) Basic Test In een eerste Basic Test wordt gecontroleerd of het model effectief geometrisch opgebouwd kan worden (van Leeuwen et al., 2004; Jessurun et al., 2004). Indien de hoogte van de dakgoot bijvoorbeeld hoger ligt dan de hoogte van de nok, moet dit eerst aangepast worden voordat verdergegaan kan worden. b) VROM Test In deze test wordt nagegaan of algemene stedenbouwkundige regels, opgelegd door VROM7 , gevolgd worden in de aanvraag van de dakkapel (van Leeuwen et al., 2004; Jessurun et al., 2004). Als hieraan voldaan wordt, zal de bouwvergunning bij het indienen van een aanvraag automatisch verleend worden (van Leeuwen et al., 2004; Jessurun et al., 2004). Als aan deze controle niet voldaan wordt, dan zal een uitgebreidere procedure bij de lokale gemeente uitsluitsel moeten geven. In dat laatste geval, kan het resultaat van de ‘Esthetische Test’ een doorslaggevende rol spelen (van Leeuwen et al., 2004; Jessurun et al., 2004). c) Esthetische Test In deze test wordt het informatiemodel ge¨evalueerd op meer esthetische kwaliteiten (bv. uniformiteit van straatbeeld). Het resultaat van deze test geeft een indicatie of de aanvraag geneigd is om afgekeurd of goedgekeurd te worden door de gemeente, indien reeds een uitgebreidere procedure moet uitgevoerd worden (zie VROM test). Op basis van deze indicatie kan de bouwheer beslissen om de aanvraag al dan niet in te dienen, aan te passen of te laten vallen. 5. Output van resultaten In het onderdeel ‘Output results’ (aangeduid in het grijs in figuur 6.23) worden tot slot de resultaten van de uitgevoerde controles en de van het gemodelleerde informatiemodel doorgegeven aan de gebruiker (van Leeuwen et al., 2004; Jessurun et al., 2004). 7

VROM is het Nederlands Ministerie (Volkshuisvesting, Ruimtelijke Ordening en Milieubeheer). Zij zijn de Nederlandse instantie die nationale, stedenbouwkundige regels oplegt bij het bouwen en verbouwen van gebouwen - http://www.vrom.nl/

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

155

Dit onderdeel lijkt daarmee overeen te komen met ‘stap 10: Bouwkundig advies’, ‘stap 11: Tekeningen’ en ‘stap 12: Aanvraag’ van de uitgeteste evaluatieprocedure. In ‘stap 10: Bouwkundig advies’ wordt een bouwkundig advies gegeven aan de gebruiker, dat bestaat uit de resultaten van de uitgevoerde VROM Test en de eventueel uitgevoerde Esthetische Test (Jessurun et al., 2004). In ‘stap 11: Tekeningen’ wordt plannenmateriaal gegenereerd van de parametrisch gemodelleerde dakkapel (Jessurun et al., 2004). Hiervoor worden volgens (Jessurun et al., 2004) voornamelijk de geometrische parameters gebruikt, samen met standaarddetails (uit een databank) van de aansluitingen van de verschillende elementen in de dakkapel. Dit resulteert bijvoorbeeld in de snede die weergegeven wordt in figuur 6.26.

6

Figuur 6.26.: Resulterende snedes worden onder andere uitgetekend op basis van standaarddetails in een centrale databank (van Leeuwen et al., 2004; Jessurun et al., 2004).

Tot slot wordt in ‘stap 12: Aanvraag’ getracht om een verbinding te voorzien met lokale bouwfirma’s die eventueel bereid zouden zijn om de aangevraagde dakkapel uit te voeren (Jessurun et al., 2004). Volgens Jessurun et al. (2004) wordt hiervoor de meer niet-geometrische parameters gebruikt, zoals het ingevoerde adres om op te zoeken welke bouwfirma’s zich in de buurt bevinden, en de ingevoerde materiaalparameters, om dit door te kunnen geven aan de gevonden bouwfirma’s.

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

156

6.5.2. CORENET ePlanCheck System Achtergrond van het project Het CORENET ePlanCheck System 8 is uitgewerkt als een onderdeel van het online platform ‘CORENET’ (figuur 6.27), dat een gelijkaardige doelstelling beoogt als de Digital Dormer applicatie, namelijk de uitvoering van een ‘Building Permit Simulation’ als controlemechanisme om een ontwerp te evalueren op zijn beantwoording aan nationaal opgelegde regelgevingen en voorschriften (Hammad et al., 2005).

6 Figuur 6.27.: Schematische werking van het eSubmission System.

De uitwerking van het ePlanCheck System gebeurde in Singapore onder het CORENET Construction and Real Estate Network. Dit CORENET wordt centraal aangestuurd door de Building and Construction Authority (BCA), ´e´en van de bestuursraden onder het Ministry of National Development (MND) van Singapore, en is opgestart aan het eind van de jaren 90 op basis van voorgaande OOCAD initiatieven (Liebich et al., 2002). De concrete uitwerking van het online CORENET platform werd vanaf de start uiteengetrokken in twee, functioneel te onderscheiden onderdelen, zoals beschreven is in Lam et al. (2003). Enerzijds werd een ePlanCheck System uitgewerkt dat gebruikt kon worden om informatiemodellen te controleren op de mate waarin het voldoet aan opgelegde, nationale regelgevingen en normeringen (Liebich et al., 2002) en anderzijds werd een platform ontwikkeld waarlangs de elektronische aanvraagprocedure moest verlopen, namelijk het eSubmission System (Lam et al., 2003). Deze twee onderdelen werden beiden ge¨ımplementeerd en gecombineerd door novaCITYNETS Pte Ltd.9 (Lam et al., 2003).

8 9

CORENET Construction and Real Estate Network - http://www.corenet.gov.sg/ novaCITYNETS Pte Ltd. - http://www.novacitynets.com/

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

157

Conceptuele werking en implementering eSubmission System De implementering van het eSubmission System werd gestart in 2000, onder de naam OneStop Submission Center (OSSC) (Lam et al., 2003). Het uiteindelijk ge¨ımplementeerde eSubmission System volgens Liebich et al. (2002) cre¨eerde een gebruikersinterface voor het online CORENET platform dat weergegeven is in figuur 6.27. Deze gebruikersinterface bood volgende, dubbele functionaliteit aan volgens Liebich et al. (2002). 1. on-line bouwaanvragen automatisch laten controleren in het ePlanCheck System, waarna de aanvraag eventueel nog kan aangepast worden 2. bouwaanvragen indienen om ze te laten verwerken tot een eventuele goedkeuring Conceptuele werking ePlanCheck System Van in de conceptueel beschreven werking van het ePlanCheck System wordt getracht om een applicatie te ontwikkelen die het expliciet mogelijk maakt om een Building Information Model via het IFC bestandsformaat in te laden en te controleren op de mate waarin het voldoet aan opgelegde, nationale regelgevingen en normeringen (Liebich et al., 2002). Door dit vertrekpunt van het ePlanCheck System, via BIM en IFC, wordt volgens Liebich et al. (2002) uitdrukkelijk getracht om een zo ruim mogelijke functionaliteit aan te bieden voor een zo ruim mogelijk publiek uit de AEC industrie. Om de aangeboden functionaliteit van het ePlanCheckSystem nog te vergroten, wordt bijkomend aan het CORENET project een IFC Codes and Standards extension project (CAS) opgestart (Liebich et al., 2002). Dit CAS extension project tracht volgens Liebich et al. (2002) de nodige, bijkomende definities te voorzien aan de reeds uitgebreide IFC Industry Foundation Classes, om zo de correcte informatie te kunnen voorzien voor het CORENET ePlanCheck System. Er werd voorzien dat deze bijkomende definities in volgende versies van dit IFC bestandsformaat zouden opgenomen worden (Liebich et al., 2002). Implementering ePlanCheck System De implementering van het ePlanCheck System werd in 2000 gestart met de uitwerking van twee apart werkende Integrated Plan Checking Systems, namelijk het IBP systeem of Integrated Building Plans ePlanCheck System en het IBS systeem of Integrated Building Services ePlanCheck System (Liebich et al., 2002). Deze twee systemen controleren elk hetzelfde ingevoerde IFC bestand op verschillende criteria, gericht op enerzijds de planmatige inhoud en anderszijds de ‘diensten’ die in het gebouw voorzien worden (Liebich et al., 2002). De systemen zijn in een later stadium samengevoegd als twee modules onder eenzelfde, enkelvoudig ePlanCheck System (figuur 6.28).

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

158

Figuur 6.28.: Het ge¨ımplementeerde ePlanCheck System bestond oorspronkelijk uit twee aparte modules, de IBP module en de IBS module (Liebich et al., 2002).

In de eerste twee modules van het ePlanCheck System werden slechts een aantal bouwkundige eigenschappen in het informatiemodel gecontroleerd. Dit behandelde eerder de meer voor de hand liggende aspecten die aan een driedimensionaal BIM model gecontroleerd kunnen worden, zoals ‘Barrier Free Access’ en ‘Fire Code’ (Liebich et al., 2002). Ook werd bijvoorbeeld gecontroleerd in hoeverre deur- en gangbreedtes voldeden aan de gestelde normeringen in Singapore (Liebich et al., 2002). De implementatie van een extra, derde module, die het informatiemodel zou kunnen controleren op zijn eigenlijke performantie (Wong, 2004), werd pas gestart in 2004 (figuur 6.29). Dit gebeurde in eerste instantie onder de vorm van een koppeling tussen het bestaande ePlanCheck System en een bijkomende eThermal Engine (Lam et al., 2003; Wong, 2004), waarin het informatiemodel omgevormd werd tot een EnergyPlus model voor de uitvoering van een thermische en een energetische simulatie (Lam et al., 2003; Wong, 2004) (figuur 6.29).

6.6. Besluit In deze studie is gebleken dat opmerkelijk veel ICT applicaties vermeld kunnen worden die trachten in te gaan op het aspect evaluation of design solutions. Het in dit hoofdstuk gegeven overzicht, volgens de onderverdeling Energy Calculation - Lights & Acoustics Calculation - Design Program Simulation - Building Permit Simulation, kan dan ook verre van volledig beschouwd worden. Uit het benaderende overzicht zouden wel enkele meer algemene conclusies getrokken kunnen worden.

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

159

Figuur 6.29.: Het ePlanCheck System omhelsde van bij het begin het controleren van regelgevingen rond de onderwerpen die weergegeven worden onder de Building Plan Module en de Building Services Module. Controles op de gebouwperformantie werden in een derde module toegevoegd vanaf 2004.

• Zo zou kunnen vastgesteld worden dat over het algemeen een groot deel van de ICT applicaties eerder ontwikkeld zijn met het oog op de meer expliciet kwantitatieve en meetbare categorie van evaluation of design solutions. In dit opzicht kunnen bijvoorbeeld de ICT applicaties vermeld worden die onder de noemers Energy Calculation en Lights & Acoustics Calculation vallen. Deze applicaties importeren expliciet meetbare gegevens (driedimensionale gebouwinformatie) in hun applicatie om deze te verwerken en een objectief resultaat te geven voor een bepaalde, ge¨evalueerde parameter (in dit geval energieprestatie of licht- en akoestische prestatie). Deze ICT applicaties zijn doorgaans nog bijkomend in staat om deze objectieve resultaten te toesten aan andere objectieve resultaten, zoals bijvoorbeeld wettelijke eisen en normen. Wanneer echter geoordeeld moet worden of een bepaald energieniveau of een bepaalde akoestische prestatie weldegelijk op maat is van wat de bouwheer bijvoorbeeld impliciet verwacht, zonder dat daarbij zelfs een kwalitatieve factor vermeld wordt, dan blijken de onderzochte ICT applicaties hier weinig op in te gaan. Hieruit zou besloten kunnen worden dat ICT applicaties op deze evaluatiecategorie (impliciet, tacit en kwalitatief) van weinig of geen nut blijken te zijn. De eigenlijke evaluatie lijkt met andere woorden eerder te worden overgelaten aan de ontwerper zelf, die daardoor verondersteld lijkt te worden zelf te kunnen oordelen of een bepaalde energiewaarde of akoestische prestatiewaarde op een bepaald moment voldoende is voor het ontwerp of eerder voor herziening vatbaar is. • De applicaties die onder de noemers Design Program Simulation en Building Permit Simulation geplaatst werden, lijken hier tot op een bepaalde hoogte een uitzondering op te vormen. Waar het merendeel van de aangehaalde applicaties (bv. ePlanCheck System en Trelligence Affinity) zich namelijk nog eerder lijken te beperken tot de kwan-

6

HOOFDSTUK 6. III - ‘EVALUATION OF DESIGN SOLUTIONS’

160

titatieve, niet-geometrische informatie die aanwezig is in uitgewerkte BIM modellen (bv. verwachte kosten, benamingen van ruimtes, expliciete ontwerpeisen, . . . ), lijkt de applicatie AMCE al meer in te gaan op de evaluatie van de eigenlijke impliciete, tacit en kwalitatieve informatie in het ontwerp. De werkwijze in deze evaluatie lijkt neer te komen op het zoeken naar een manier waarop de informatie van het impliciet, tacit en kwalitatief niveau ge¨expliciteerd kan worden tot beter meetbare en afweegbare termen. Dit gebeurt expliciet door de verschillende partijen in het ontwerp vastgelegd worden welk energieniveau hij of zij bijvoorbeeld zou willen behalen en hoe ver hierin mag afgeweken worden volgens de verschillende factoren in dit energieniveau (§ 6.4.2).

Als algemene conclusie kan over ICT applicaties met een focus op het aspect evaluation of design solutions vooral vastgesteld worden dat deze applicaties zich in de eerste plaats lijken te richten op de meer kwantitatieve en meetbare gegevens van een ontwerp. De applicaties die zich ook op het meer kwalitatief, impliciet en tacit gebied richten, trachten daarbij voornamelijk om deze vormen van informatie te laten expliciteren door de personen zelf voor wie een evaluatie op dit vlak van belang is. Hieruit zou kunnen besloten worden dat het vandaag niet mogelijk is om een ontwerp expliciet te evalueren op een kwalitatief, tacit en impliciet niveau, z´ onder de aanwezigheid van de personen. Er bestaat bijvoorbeeld niet een evaluatie naar ‘gemiddelde woonkwaliteit’ of een toetsing aan ‘impliciete minimale comforteisen’.

6

7 IV - ‘Decision-making’

W

ANNEER beslissingen genomen worden, wordt gesteld in Moum (2006b) dat dit in feite gebeurt op basis van heel uiteenlopende factoren, zoals materiaalkundige en bouwtechnische eisen, eerder stedenbouwkundige voorschriften, de wijze van communicatie, ethische aspecten, criteria naar verantwoordelijkheid, enzovoort. Volgens Moum (2006b) worden deze factoren daarbij samengesteld en be¨ınvloed door de drie andere aspecten van het ontwerpproces (generation of design solutions - communication - evaluation of design solutions).

7.1. Inleiding Centraal in bovenstaande omschrijving van het aspect decision-making staat de grote hoeveelheid invloedsfactoren die inwerken op een ‘beslissing’. Het nemen van die beslissing in een ontwerpproces kan hierdoor in sommige gevallen een bijna onbegonnen zaak lijken, aangezien met zoveel invloedsfactoren rekening moet gehouden worden, dat het bijna onmogelijk wordt om al deze factoren op de juiste manier in rekening te brengen. Wanneer enkele van deze invloedsfactoren bijgevolg niet in rekening worden gebracht bij het nemen van een bepaalde ontwerpbeslissing, dan heeft dit ongetwijfeld een grote weerslag op het verdere verloop en het uiteindelijke resultaat van het ontwerpproces in zijn geheel, wat ook reeds aangehaald werd in § 3.2.2. Aangezien het zelfs voor ICT applicaties uiterst moeilijk is om alle invloedsfactoren in een

161

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

162

ontwerpbeslissing op een correcte manier in rekening te brengen, wordt dit in deze scriptie niet verder onderzocht. Een factor die meegespeeld heeft in deze beslissing is de stelling van Moum (2006b) dat vele van deze invloedsfactoren in feite afkomstig zijn uit de drie overige ontwerpaspecten, die reeds behandeld werden in de hoofdstukken 4, 5 en 6). Er wordt daarentegen wel een studie uitgevoerd naar de wijze waarop ICT applicaties op dit moment een voldoende ruim kader zouden kunnen bieden, om ontwerpbeslissingen te kunnen nemen die gebaseerd zijn op een zo ruim mogelijke blik of een zo ruim mogelijk begrip van het ontwerpprobleem. Binnen deze scriptie wordt aangenomen dat hiervoor best teruggevallen wordt op de uitgebreide softwareplatformen en tekenpakketten die de voorghaande drie ontwerpaspecten zo doorzichtig mogelijk trachten toegankelijk te maken. Concreet wordt daarom ingegaan op de ontwikkeling van teken- en modelleerapplicaties, waaronder enkele markante stappen in de evolutie van het geometrische CAD naar het semantisch betekenisvolle BIM of Building Information Modelling beschreven worden.

7.2. CAD - Computer Aided Design Traditionele CAD systemen, zoals ze voornamelijk ontwikkeld werden in de jaren ’90 (Penttil¨ a en Weck, 2006), worden doorgaans benoemd als Computer Aided Design systemen, maar in het licht van huidige ontwikkelingen richting Building Information Modelling zouden ze eerder benoemd kunnen worden als Computer Aided Drafting systemen (Moum, 2006b; Pelosi, 2007). Deze systemen blijken tot op vandaag namelijk nog veel gebruikt te worden als digitale tekentafels, waarbinnen tweedimensionale en driedimensionale objecten nog worden uitgetekend zoals op een gewoon papier (Fu et al., 2006). Deze ‘traditionele’ CAD applicaties waren oorspronkelijk ook in de eerste plaats voor dit doel ontwikkeld (Boeykens, 2007). Ze werden bedoeld om de ineffici¨entie van een werkmethode aan de hand van pen en papier te elimineren door deze tekenmethode om te zetten naar een digitaal medium (Boeykens, 2007). Daarin blijken ze bijzonder goed geslaagd te zijn, want aan het einde van de jaren ’90 zijn reeds gedetailleerde visualisaties van driedimensionale gebouwmodellen in CAD terug te vinden en blijkt ook een het communicatieproces in de bouwindustrie reeds sterk verbeterd te zijn (Penttil¨ a, 2006). Hoewel dit ongetwijfeld een grote vooruitgang was in de AEC industrie voor de graad van effici¨entie in de productie van tekeningen en plannen, wordt bij dit gebruik echter inderdaad weinig of geen object-ge¨ ori¨enteerde informatie aan het ontwerp toegevoegd (Fu et al., 2006; Penttil¨ a, 2006; Boeykens, 2007), waardoor deze systemen eerder beperkt zouden kunnen lijken ten opzichte van wat vandaag getracht wordt in Building Information Modelling applicaties.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

163

In huidige ICT ontwikkelingen wordt uitdrukkelijk ingegaan op de vaststelling dat deze traditionele CAD applicaties te veel als Computer-Aided Drafting zouden gebruikt moeten worden, zonder extra mogelijkheden naar verdere informatieverwerking. Er worden daarom applicaties ontwikkeld waarin w´el uitgebreide object-ge¨ ori¨enteerde informatie toegevoegd kan worden aan het gebouwmodel (Eastman, 1999; Penttil¨ a, 2006). Deze applicaties contrasteren hierdoor sterk met de traditionele CAD applicaties en worden daarom in veel gevallen ondergebracht onder een andere noemer, namelijk BIM of Building Information Modelling (Eastman, 1999; Penttil¨ a, 2006). Het is echter wel zo dat BIM in principe ook benoemd zou kunnen worden als een vorm van Computer Aided Design, als hiermee bedoeld wordt dat de BIM applicaties ontwikkeld werden om de ontwerper te helpen in zijn ontwerpproces (Boeykens, 2007). Het wordt ook hier echter n´ a´ ast CAD geplaatst om duidelijk onderscheid te maken met bovenstaande Computer Aided Drafting betekenis van CAD. Een recent overzicht van de evolutie van CAD -systemen tot op vandaag, wordt gegeven a (2006); Boeykens (2007). Hierin komt ook de evolutie naar voor van objectin Penttil¨ ge¨ ori¨enteerde informatie naar meer semantische informatie. Hiermee wordt bedoeld dat niet enkel uitgebreidere informatie toegevoegd wordt aan de uitgetekende objecten, maar dat deze informatie eveneens ´e´enduidig en gestandaardiseerd uitgedrukt wordt zodat deze in een taalkundige semantiek begrepen kan worden door zowel menselijke gebruikers als door externe ICT applicaties die naar deze standaard semantiek ontwikkeld zijn (Boeykens, 2007).

7.3. PM - Product Modellering Sinds het ontstaan van informatietechnologie is onderzocht hoe deze technologie aangewend kon worden bij het ontwerpen van toestellen, gebouwen, objecten, enzovoort. In eerste instantie gebeurde dit onder de vorm van zuiver geometrische modellen die uitgetekend werden in gepaste CAD/CAM tekenapplicaties (§ 7.2). Door de ongeschiktheid van deze geometrische informatie voor meer geavanceerde evaluaties en simulaties, werd in het begin van de jaren ’80 reeds gezocht naar manieren om object-geori¨enteerde informatie aan het geometrisch model te koppelen (Shah en Rogers, 1988; Boeykens, 2007). Dit resulteerde in een nieuwe vorm van modellering, namelijk Product Modellering (PM) aan de hand van features (Shah en Rogers, 1988; Mantyla, 1989; Wong, 1994). Deze ontwikkeling vond in eerste instantie plaats binnen het industrieel ontwerp van toestellen en machines (Wong, 1994), onder de vorm van vooral beschrijvende, eerder technische informatie (figuur 7.1) die als features geassocieerd konden worden met specifieke industri¨ele toepassingen en technieken (van Leeuwen et al., 1995).

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

164

Figuur 7.1.: Toekenning van features aan eigenschappen van een mechanisch onderdeel (Mantyla, 1989; Wong, 1994; van Leeuwen et al., 1995).

Het begrip productdata kreeg in zijn verdere uitwerking concreet vorm als “... data die de functie en fysische karakteristieken van elk onderdeel van een product beschrijft vanaf zijn conceptie tot zijn configuratie en zijn uiteindelijke bestaanseinde” - (van Leeuwen et al., 1996). In Shah en Rogers (1988) werd ´e´en van de eerste classificaties gemaakt voor features, specifiek gericht op de industri¨ele toepassing waarin deze features in eerste instantie gebruikt zouden worden (figuur 7.1). • Form features: beschrijving van de nominale geometrie • Precision features: aanvaardbare afwijkingen van de nominale geometrie • Technological features: performantie en maakbaarheidseisen • Material fatures: materiaalcompositie, -behandeling en conditie • Assembly features: wijze van samenstelling, individueel en in het groter geheel

In bovenstaande betekenis van ‘productdata’ volstaan features volgens van Leeuwen et al. (1995) echter niet voldoende voor architecturaal gebruik. Binnen productmodellering staat namelijk een eerder statisch, voorgedefinieerd schema van de samenstellende producten en

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

165

zijn hoofdzakelijk geometrische features centraal, wat conceptueel strookt met het dynamisch en ongedefinieerd karakter van een architecturaal ontwerpmodel (van Leeuwen et al., 1995). Volgens van Leeuwen et al. (1995) zouden daarentegen onder andere verschillende andere soorten features moeten kunnen gedefinieerd worden buiten de hierboven gegeven features van Shah en Rogers (1988) en zou bovendien continu de mogelijkheid moeten bestaan tot herinterpretatie en herstructurering van deze features, zodat het ontwerp effectief gestimuleerd kan worden en de (her)indexering van abstracte en impliciete informatie mogelijk gemaakt kan worden. Om het Product Modellering systeem aan de hand van features hiernaar aan te passen voor gebruik binnen een architecturale ontwerpomgeving, werd een onderzoek gestart naar Feature Based Modelling in architectuur (van Leeuwen et al., 1995, 1996; van Leeuwen en Wagter, 1997), binnen het onderzoeksprogramma Virtual Reality - Design Information Systems (VRDIS). Dit onderzoeksprogramma werd nadien opgevolgd door de huidige onderzoeksgroep Digital Design Support Systems (DDSS) van de faculteit Bouwkunde aan de Technische Universiteit Eindhoven (de Vries et al., 2000).

7.4. FBM - Feature Based Modelling 7.4.1. Informatiemodellering aan de hand van ‘features’ A feature is a collection of high-level information, possibly emerging during design, defining ” a set of characteristics or concepts with a semantic meaning to a particular view in the lifecycle of a building.” (van Leeuwen en Wagter, 1998). Mechanical Engineering De basiswerking en conceptie van features binnen Feature Based Modelling (FBM) volgens van Leeuwen en Wagter (1997) werd overgenomen uit het domein werktuigbouwkunde of Mechanical Engineering, waarin via een algemeen werkingsschema bruikbare features en feature types gedefinieerd en gecombineerd konden worden tot een feature model (figuur 7.2). In eerste instantie worden in dit schema verschillende feature types gedefinieerd om deze vervolgens geclassificeerd op te slaan in een Feature Type Library (van Leeuwen en Wagter, 1997). Voor elk nieuw ontwerp worden de eigenlijke ontwerp-features gedefinieerd door instantiatie van de attributen van een bepaalde feature type om ze vervolgens bewerkbaar in te voeren in het Feature-Based Model (van Leeuwen en Wagter, 1997).

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

166

Figuur 7.2.: De definitie, classificatie en bewerking van feature types en features gebeurt volgens bovenstaand conceptueel werkingsschema. (van Leeuwen en Wagter, 1997).

Architecturale features Aanvankelijk werd niet rechtstreeks met de features zelf gewerkt / gemodelleerd, maar werd een werkmethode via ‘Feature Type Recognition’ (FTR) toegepast (van Leeuwen et al., 1996). In deze werkmethode zou een expliciet geometrisch model uitgetekend worden zonder enige features hieraan toe te voegen, waarna dit model vergeleken zou worden met vooraf gedefinieerde feature types uit een bestaande ‘Feature Type Library’ (figuur 7.2). Het informatiesysteem werd vervolgens in staat geacht om, met of zonder menselijke hulp, features letterlijk te kunnen herkennen in het geometrisch model, via de resultaten van deze vergelijking. Via die werkwijze zou tenslotte object-ge¨ ori¨enteerde of eventueel semantische betekenis kunnen gegeven worden aan de onderdelen van het reeds uitgetekende, geometrisch model (van Leeuwen et al., 1996). De classificatie van de features in de werktuigbouwkunde, zoals ze door Shah en Rogers (1988) uitgewerkt werd en aanvankelijk door van Leeuwen et al. (1996) overgenomen werd, was echter ge¨ınspireerd op concrete, technische informatie uit de werktuigbouwkunde, wat in een architecturale ontwerpomgeving doorgaans beperkt aanwezig is (van Leeuwen et al., 1996). In van Leeuwen et al. (1996); van Leeuwen en Wagter (1997, 1998) werd daarom uitdrukkelijk naar een andere invulling voor deze features gezocht, specifiek voor toepassing binnen het architectuurontwerp. Als resultaat werd een FBM techniek ontwikkeld die gebaseerd was op een uitgebreidere classificatie van features (tabel 7.1), zodat FBM eveneens toepasbaar gemaakt kon worden voor eerder abstracte, ontwerpmatige informatie (van Leeuwen et al., 1996; van Leeuwen en

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

167

Wagter, 1997).

Tabel 7.1.: Classificatie van feature types volgens van Leeuwen en Wagter (1997).

Uit deze FBM classificatie werd in van Leeuwen en Wagter (1998) duidelijk dat de werkmethode via Feature Type Recognition niet voldoet, aangezien de hier gedefinieerde, eerder abstracte features onvoldoende herkend zouden kunnen worden uit louter geometrische input, zoals wel gedaan kon worden voor bijvoorbeeld het element in figuur 7.1. De toegevoegde hoeveelheid informatie via FTR blijft met andere woorden gelimiteerd tot de door het informatiesysteem herkenbare informatie uit het informatiemodel (van Leeuwen et al., 1996). Daarom werd in van Leeuwen en Wagter (1998) een tweede techniek uitgewerkt, namelijk Design-by-Features, waarbij de features en feature types rechtstreeks gebruikt worden bij de modellering (van Leeuwen en Wagter, 1998). Design-by-Features In van Leeuwen en Wagter (1998) wordt de uiteindelijke methodiek voor de Design-byFeatures modelleeromgeving voorgesteld op basis van eerder onderzoek en een test-case uit Achten (1997); van Leeuwen en Achten (1998, 1999). De inhoud van de abstracte, ontwerpmatige features wordt in deze methodiek ingevuld aan de hand van de expertise van Achten (1997) rond ‘generic design representations’.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

168

De methodiek voor de gebruiker werd in van Leeuwen (1999a) concreter uitgewerkt vanuit het principeschema in figuur 7.2 tot het meer gedetailleerde werkingsschema in figuur 7.3. De verschillende fases die de ontwerper doorloopt voor het defini¨eren van de features zijn volgens dit schema en volgens van Leeuwen (1999a) in grote lijnen viervoudig.

Figuur 7.3.: Het voorgestelde werkingsschema bij het gebruik van features in FBM. Dit is g´e´en eenmalig, chronologisch proces, maar een eerder iteratief proces, waarbij telkens een bepaald deel van de informatie aangepast wordt naargelang de situatie in het ontwerp (van Leeuwen, 1999a).

• Feature Type Definition Domeinkennis wordt omgezet in nieuwe feature types. • Classification into Feature Type Libraries De gedefinieerde feature types worden opgeslagen in een bibliotheek ter bevordering van de overzichtelijkheid en algemene eenduidigheid in de centrale structuur. • Features Instantiation De feature types worden ge¨ınstantieerd met een projectspecifieke invulling. • Features Modification Elke vorm van informatie die door features bepaald is, kan nadien op een consistente manier aangepast worden naar nieuw ontstane ontwerpeisen. De feature types, die de basis vormen van bovenstaand werkingsschema (figuur 7.3), worden in van Leeuwen en Wagter (1998) en van Leeuwen (1999b) onderverdeeld volgens acht

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

169

basisklassen (figuur 7.4). Deze klassen worden beschreven door middel van de objectgeori¨enteerde EXPRESS data definition language van de International Organisation for Standardisation (ISO), waarbij elke klasse een bepaald soort informatie bevat op een gestructureerd, object-ge¨ ori¨enteerd niveau (van Leeuwen en Wagter, 1998; van Leeuwen, 1999b).

7

Figuur 7.4.: Onderverdeling van de feature types door van Leeuwen en Wagter (1998) in acht basisklassen. Deze klassen werden beschreven door middel van de EXPRESS data definition language.

In deze acht basisklassen (figuur 7.4) zijn eveneens twee klassen opgenomen door van Leeuwen en Wagter (1998) en van Leeuwen (1999b) die de relaties tussen de verschillende features zouden kunnen expliciteren. Dit zijn de klassen ‘Complex FeatureType’ en ‘Feature SubType’ (van Leeuwen en Wagter, 1998; van Leeuwen, 1999b). De relaties tussen features worden door van Leeuwen en Wagter (1998) en van Leeuwen (1999b) onderverdeeld in de vier volgende types.

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

170

• Specialisation Relation: De ene feature type is een sub-type van de andere. De karakteristieken worden van deze laatste overge¨erfd en nieuwe karakteristieken worden toegevoegd ter specialisatie. • Decomposition Relation: Een feature type is onderverdeeld in verschillende componenten. Elke component is hierbij een feature type op zich en bevat een aantal karakteristieken die gecombineerd het karakter van het hoofdtype uitmaken. • Association Relation: Een vorm van associatie bestaat tussen verschillende feature types, maar hier komt geen overerving of onderverdeling in karakteristieken aan te pas. • Specification Relation: Voor de ene feature type wordt informatie gespecifieerd door middel van een tweede feature type. Dit kan bijvoorbeeld de kostprijs zijn die voor een raam gespecifieerd wordt.

De exacte en concrete werking van deze conceptuele FBM structuur voor het architectuurontwerp wordt uitvoerig behandeld aan de hand van test-cases in van Leeuwen (1999b) en van Leeuwen (1999a).

7.4.2. Generic Representations in FBM Voor de definitie van feature types werd in het onderzoek naar Feature-Based Modelling voor het architectuurontwerp teruggevallen op het onderzoek van Achten (1997) en Achten (2000) rond ‘generic design representations’ of kortweg ‘generic representations’. Dit onderzoek werd eveneens uitgevoerd binnen het VR-DIS onderzoeksprogramma van de faculteit Bouwkunde aan de Technische Universiteit Eindhoven (de Vries et al., 2000). Generic Design Representations Het onderzoek naar ‘generic design representations’ vertrekt vanuit de aanname dat architectuurschetsen samengesteld zijn uit verschillende elementen met elk hun eigen symbolische voorstellingswijze(n), resulterend uit onder andere impliciete tekenconventies (Achten, 1997). Deze elementen bevatten volgens Achten (1997) elk op zich specifieke impliciete informatie over het ontwerp. Als men deze informatie echter in een computergestuurde omgeving wil inzetten ter ondersteuning van de ontwerper, dan zou deze impliciete kennis volgens Achten (1997) ge¨expliciteerd moeten kunnen worden naar een concreet informatiemodel. In een eerste stap is in Achten (1997, 2000) onderzocht hoe de impliciete informatie in architectuurschetsen uitgedrukt wordt. Dit zou als volgt samengevat kunnen worden.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

171

De concrete onderverdeling van impliciete informatie achter generic design representations vertrekt bij de definitie van een ‘graphic representation’ of een grafische voorstelling. Voor de definitie van een ‘graphic representation’ wordt in Achten (1997) teruggegrepen naar de definitie die gegeven wordt door Akin (1986) (p. 49-50). Ruim samengevat kunnen ‘graphic representations’ volgens Achten (1997) begrepen worden als de eigenlijke grafische voorstellingswijzen waarmee een architect concepten, schema’s, voorontwerpen, enzovoort voorstelt. Dit kunnen schetsen zijn, maar ook diagrammen of bijvoorbeeld uitgewerkte tekeningen (Achten, 1997). Door deze grafische voorstellingen telkens opnieuw te wijzigen, op basis van bijkomende ‘kennis’ (Achten, 1997), kan het ontwerp steeds dichter komen bij het uiteindelijk te bekomen voorontwerp. Dit wordt ge¨ıllustreerd in figuur 7.5.

7 Figuur 7.5.: Het ontwerpproces zoals het volgens Achten (1997) verloopt aan de hand van grafische voorstellingen.

Deze grafische voorstellingen worden in Achten (1997) onderverdeeld volgens de elementen waaruit ze opgebouwd zijn, zogenaamde ‘graphic units’ of grafische entiteiten. Dit zijn volgens Achten (1997) grafische elementen met een bepaalde, specifieke betekenis, zoals ‘grid’, ‘as’, ‘vorm’, enzovoort (figuur 7.6). Op het moment dat twee grafische voorstellingen opgebouwd zijn uit dezelfde graphic units of grafische entiteiten, dan worden deze door Achten (1997) onder dezelfde noemer geplaatst, namelijk eenzelfde ‘generic representation’. Dit wil niet zeggen dat de verschillende grafische voorstellingen onder een zelfde generic representation telkens volledig gelijk zijn aan elkaar, ze worden enkel opgebouwd uit dezelfde grafische entiteiten (Achten, 1997). In Achten (1997) werden reeds 24 grafische entiteiten vastgelegd, zoals ‘simple contour’, ‘contour’, ‘measurement device’ en ‘specified form’. Op basis daarvan werden eveneens in Achten (1997) 50 generic representations ge¨ıdentificeerd, zoals bijvoorbeeld ‘contour in

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

172

Figuur 7.6.: Een grafische voorstelling, bestaande uit verschillende ‘grafische eenheden’ (‘grid, ‘contour’, . . . ), van het ontwerp van Louis Kahn voor het Community Centre of Salk Institute.

grid’. Beslissingsboom / Decision Tree Vervolgens kon in Achten (1997) gesteld worden uit het gevoerd onderzoek dat bepaalde grafische entiteiten pas konden voorkomen op het moment dat een voorgaande entiteit voorgekomen was. Zo was het pas mogelijk om een element te idenitificeren als een ‘elaborated structural contour’ op het moment dat het al benoemd was als een ‘contour’ met een ‘specified form’, of kon er pas gesproken worden over een ‘tartan grid’ op het moment dat de grafische entiteit al benoemd was tot een ‘grid’ (Achten, 1997). In Achten en van Leeuwen (2000) werd daarom een ‘decision tree’ of beslissingsboom voorgesteld, op basis waarvan generic representations herkend konden worden in grafische voorstellingen. In deze beslissingsboom bevindt zich volgens Achten en van Leeuwen (2000) op elke knoop ofwel een gestelde vraag (A, B, C, . . . ), ofwel een ge¨ıdentificeerde generic representation (1,2,3,4, . . . ). Door deze beslissingsboom van boven naar beneden te doorlopen, zouden de verschillende grafische eenheden in de grafische voorstelling herkend worden, waardoor kan afgeleid worden welke generic representations in de schets kunnen teruggevonden worden. Deze beslissingsboom werd oorspronkelijk voorgesteld voor gebruik binnen een Case-Based Design Aid System (CBDAS) (§ 4.2.2), waarin het gebruikt zou worden als informatiebron in een CBD omgeving.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

173

Figuur 7.7.: De ‘decision tree’ voor de herkenning van generic representations (Achten en van Leeuwen, 2000).

Toepassing binnen FBM In een tweede stap (1999 - 2000) werd in Achten en van Leeuwen (2000) onderzocht op welke manier deze expertise rond generic representations van Achten (1997) geconcretiseerd kon worden in een Feature-Based Modelling Framework voor architectuur. Een ‘decision tree’ of beslissingsboom (figuur 7.7), die leidt tot de identificatie van generic representations in grafische voorstellingen, wordt hiervoor vooropgesteld door Achten en van Leeuwen (2000). Aan deze beslissingsboom werd een conceptuele methodiek gekoppeld voor de toekenning van grafische eenheden aan overeenkomstige features in het Feature-Based Modelling Framework. Deze methodiek wordt onderverdeeld in drie verschillende deelmethodes om de generic design representations te kunnen beschrijven door middel van features. Uiteindelijk zou dit kunnen verwerkt worden in de algemene FBM werkmethode, die reeds schematisch voorgesteld werd in figuur 7.3. In van Leeuwen en de Vries (2000a) en van Leeuwen en de Vries (2000b) wordt de toekenningsmethode van een grafische eenheden uit een generic design representation aan een overeenkomstige feature voorgesteld via drie verschillende methodes, gebaseerd op de methodes voor de definitie van ‘object classes’ in object-geori¨enteerde probleembenaderingen (van Leeuwen en de Vries, 2000a). 1. Feature Type Definition “from scratch” Een vierdelige procedure op basis van gerichte vraagstellingen, werd uitgewerkt in

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

174

van Leeuwen en de Vries (2000a). Deze procedure tracht de ontwerper te leiden door verschillende te nemen beslissingen tot de definitie van een nieuw feature type. Via deze procedure worden de geschikte klassen van de feature types geselecteerd met de bijhorende definitie van hun verschillende attributen (figuur 7.8).

7

Figuur 7.8.: De eerste stap in de vierdelige procedure om een nieuwe feature type te defini¨eren (van Leeuwen en de Vries, 2000a).

2. Feature Type Definition “from prototype” Dit gebeurt op dezelfde manier als de Feature Type Definition “from scratch”, met dat verschil dat hier reeds een deel van de te defini¨eren feature beschikbaar is uit een eerder gemaakt prototype (van Leeuwen en de Vries, 2000a). Dit prototype dient dus als basis om van hieruit nieuwe, compexere feature types te defini¨eren (van Leeuwen en de Vries, 2000a). 3. Feature Type Recognition (FTR)

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

175

Deze methode is de productmodelleertechnieken gevolgd vanuit het domein van de werktuigbouwkunde, waar rond de jaren ’80 features werden aangemaakt door analyse van het geometrisch model (Wong, 1994). Als in dit FTR proces bepaalde patronen in de geometrie overeenkomen met een vooraf gedefinieerde feature type uit de feature type Library, dan wordt deze opgeslagen in het nieuwe FBM model, zoals beschreven werd in Wong (1994). Dit zou op een gelijkaardige manier kunnen toegepast worden voor architecturale features, waarbij in van Leeuwen en Wagter (1998) wel opgemerkt wordt dat deze methode vooral de features zal kunnen herkennen die gebaseerd zijn op geometrische voorstellingen van objecten.

7.5. BIM - Building Information Modelling Binnen deze scriptie zijn, tot slot van dit hoofdstuk over hoe het aspect decision-making ondersteund wordt door ICT applicaties, de huidige mogelijkheden van de BIM modelleertechniek kort uitgetest binnen Autodesk Revit Architecture 2008. Er werd gekozen voor Autodesk Revit omdat, uitgaande van de marktpositie van Autodesk, aangenomen kan worden dat hun uitgebrachte BIM applicaties op zijn minst representatief zijn voor de functionaliteit die algemeen via Building Information Modelling wordt aangeboden. In onderstaande beschrijving van de functionaliteit van Building Information Modelling applicaties, worden enkel conclusies en resultaten gegeven op basis van deze zelf uitgevoerde test. De BIM test werd uitgevoerd aan de hand van twee historische gebouwen in Gent. Enerzijds werd de Gentse Onze-Lieve-Vrouw en Sint-Pieterskerk gekozen voor het kort uittesten van heel uiteenlopende BIM functionaliteiten (§ 7.5.1), zoals het gebruiken van geometrische parameters voor de modellering van bepaalde objecten in het driedimensionaal model en het toekennen van informatie aan het informatiemodel zelf. Daarnaast werd het Casino van Gent uitgekozen om een volledig Building Information Model uit te werken (§ 7.5.2). Dit Casino is gebouwd in 1835 en heeft dienst gedaan voor talrijke feesten, tentoonstellingen, florali¨en en andere laat 19e en vroeg 20e eeuwse festiviteiten, tot het afgebroken werd in 1945. Aan de hand van uiteenlopend historisch materiaal (figuur 7.9) werd het gebouw opnieuw uitgetekend zoals het vermoedelijk geconcipieerd was in 1835.

7.5.1. Illustratie van de modelleertechniek Structuur van het Building Information Model Waar in traditionele CAD applicaties slechts gewerkt wordt met eenvoudige objecten die in de eerste plaats verschillen in hun geometrie, wordt in BIM gewerkt met objecten die in de eerste plaats verschillen in hun onderliggende informatie of features. Zo zal bijvoorbeeld elke

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

176

Figuur 7.9.: Historische documenten voor de Onze-Lieve-Vrouw en Sint-Pieterskerk (a) (Stadsarchief Gent - Atlas Goetghebuer) en voor het Casino (b) (Stadsarchief Gent - Atlast Goetghebuer).

‘box’ in AutoCAD in se dezelfde zijn, namelijk een regelmatige, driedimensionale matrix van acht punten met daartussen de vlakken die het volume afbakenen, maar zullen in Autodesk Revit heel verschillende object types bestaan onder het object ‘window’ bijvoorbeeld. Deze object types stammen wel af van eenzelfde basiselement of template, maar ze kunnen elk heel uiteenlopende features hebben (bv. opening: vierkant in staal - rond in aluminium spiraalvormig in hout - . . . ). Een aantal standaard object types wordt meegeleverd bij het Autodesk Revit. Deze worden gebundeld in een ‘Metric Library’, zoals weergegeven in figuur 7.10. Bovenaan de figuur is het merendeel van de object types weergegeven die gebruikt worden in Autodesk Revit. Onderaan zijn vervolgens de verschillende varianten te zien die voorzien worden onder ´e´en van de object types. Deze hebben de extensie .rfa, wat staat voor “Revit Family File”. Als ´e´en van de family files geopend wordt, bijvoorbeeld ‘M Double-Panel2.rfa’, is een model te zien dat opgeslagen is in de geopende family file (figuur 7.11). Als vervolgens het grondplan van deze family file geopend wordt (figuur 7.12), wordt onmiddellijk zichtbaar hoe de deur parametrisch in elkaar zit. Zo is te zien dat de deur standaard open draait naar de buitenzijde van de muur (‘Exterior’ ) en dat onder andere de breedte van de deur (‘Width’ ) en de dikte van het deurblad (‘Thickness’ ) geparametriseerd zijn met een standaardwaarde van respectievelijk 1830mm en 51mm. Dit zijn twee voorbeelden van geometrische parameters die aan het model verbonden zijn. Daarnaast zijn ook enkele ‘constraints’ of randvoorwaarden zichtbaar. Deze worden gekenmerkt door het slotje dat weergegeven wordt, zoals uiterst rechts in figuur 7.12 weergegeven

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

177

Figuur 7.10.: Structuur van de Metric Library uit Revit Architecture 2008.

7

Figuur 7.11.: De family file ‘M Double-Panel 2.rfa’.

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

178

Figuur 7.12.: Grondplan van de family file ‘M Double-Panel2.rfa’, met weergave van de gedefinieerde constraints en parameters.

wordt voor een geselecteerde afmeting. Deze constraint bepaalt dat de afmeting tussen de twee randen van de deur ´ altijd gelijk moet zijn aan 12,70mm (figuur 7.12). Ook de dubbele indicatie ‘EQ’ (equals) bovenaan wijst erop dat de twee bladen van de deur van een gelijke grootte mo´eten zijn, ook en vooral wanneer gerelateerde parameters, zoals bijvoorbeeld de deurbreedte, aangepast worden. Door de toekenning van deze parameters en constraints kunnen verschillende, zogenaamde ‘family types’ gecre¨eerd worden. In het dialoogvenster dat weergegeven wordt in figuur 7.13, zijn de verschillende features te zien voor de deur ‘M Double-Panel2’. Indien gewenst, kunnen vervolgens nieuwe family types aangemaakt worden met verschillende waarden voor deze parameters. Bovenaan de figuur zijn de vijf reeds gecre¨eerde family types te zien, met als naam de twee waarden die respectievelijk voor de breedte en de hoogte van de deur vastgelegd is. De op deze manier gedefinieerde family types zijn voor de gebruiker beschikbaar bij het uittekenen van elke revit project file (.rvt). Bij het openen van een nieuwe project file, kan de gewenste .rfa file opgezocht en geselecteerd worden om ingeladen te worden voor gebruik in het project. De toegekende type parameters, zoals zichtbaar in figuur 7.13, zijn dan beschikbaar binnen deze project file, om rechtstreeks nieuwe family types aan te kunnen maken. Ook binnen de project file zelf kunnen parameters en constraints toegekend worden aan

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

179

Figuur 7.13.: Dialoogvenster ‘Family Types’, met weergave van de toegekende parameters.

objecten, maar deze hebben enkel vat op de elementen die binnen de project file gedefinieerd zijn en dus niet op samenstellende onderdelen van ´e´en van de object types. Parametrische modellering Voordat gestart werd met het uittekenen van een parametrisch Building Information Model van het Casino van Gent, werd eerst gestart met het uittesten van de hierboven voorgestelde, parametrische modelleertechniek op een concreet testmodel. Als testmodel werd de Onze-Lieve-Vrouw en Sint-Pieterskerk op het Sint-Pietersplein van Gent gekozen, waarvan accurate plannen rechtstreeks voor handen waren van architect R.A.C. Van den Driessche (figuur 7.14). Van deze kerk werd slechts een klein onderdeel genomen om illustratief parametrisch te modelleren, meer bepaald het samenspel van kolommen en architraven dat terug te vinden is in de onderste geleding van de voorgevel van de kerk (figuur 7.15 en 7.16).

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

180

Figuur 7.14.: Langse snede over de Onze-Lieve-Vrouw en Sint-Pieterskerk, opgemeten en opgetekend door architect R.A.C. Van den Driessche.

7

Figuur 7.15.: Voorgevel van de Onze-Lieve-Vrouw en Sint-Pieterskerk, opgemeten en opgetekend door architect R.A.C. Van den Driessche.

De uiteindelijke revit project file (.rvt) bestaat uit een wall element met daaraan gekoppeld vijf verschillende zelf gedefinieerde column types. Elke column type bestaat hierbij uit verschillende kleinere ‘deelkolommen’, die op zich eveneens opgebouwd waren op basis van nog andere profile families (.rfa) (tabel 7.2). Deze hi¨erarchische structuur zorgt ervoor dat

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

181

Figuur 7.16.: Illustratief revit project model, met in het rood aangeduid ´e´en van de gemodelleerde column types.

enkel de basistypes aangepast moet worden om een onderdeel van een kolom te veranderen in ´ alle kolommen die het basistype in kwestie gebruiken. Als bijvoorbeeld vastgesteld wordt dat het middelste deel van alle kolommen 10 cm versmald moet worden, dan moet dit in principe maar op ´e´en plaats aangepast worden. Onderaan de hi¨erarchische ladder in tabel 7.2 is elke family type opgebouwd uit eenvoudige CAD -gebaseerde elementen, zoals lines, splines en solids. Zo is in Figuur 7.17 een eenvoudige, parametrische lijntekening te zien van het profiel ‘voorgevel lev0 prof3.rfa’, dat gebruikt werd in de verschillende kolommen (tabel 7.2). Deze family type is uitgetekend door middel van de template voor profile families. Dit wil zeggen dat, wanneer de lijntekening in onderstaande figuur opgeslagen wordt als een .rfa bestand, dit als een profile family type kan ingeladen worden in eender welke nieuwe project file of family file. Het profiel werd uiteindelijk gebruikt in de aanmaak van de column family types zoals ook terug te vinden is in tabel 7.2. Het uiteindelijke, hi¨erarchische schema van family types wordt in tabel 7.2 getoond.

7.5.2. Uitgewerkt model Bovenstaande parametrische technieken werden gebruikt om een parametrisch model op te bouwen van het Casino in Gent in Revit Architecture 2008. Dit gebeurde op basis van originele documenten uit 1835 en 1845 van het gebouw, zoals bijvoorbeeld de snede in figuur 7.18.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

182

Figuur 7.17.: Parametrisch profiel, dat gebruikt wordt in de opbouw van de column families in de voorgevel van de Onze-Lieve-Vrouw en Sint-Pieterskerk.

7

Figuur 7.18.: Origineel plan van het Casino uit 1845, van de hand van architect P. J. Goetghebuer (Stadsarchief Gent - Atlas Goetghebuer).

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

183

7

Tabel 7.2.: Overzicht van de hi¨erarchische ordening van de family types in de revit project file.

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

184

Werkmethode via ‘worksets’ Voordat het modelleren gestart werd, werden in Autodesk Revit verschillende ‘worksets’ gecre¨eerd, waarin telkens een onderdeel van het gebouw in zou ondergebracht worden. Op die manier kon het overzicht op de opbouw van het model gemakkelijker behouden worden. Om deze worksets te cre¨eren, werd via ‘File > Worksets. . . ’ het dialoogvenster geopend dat links in figuur 7.19 te zien is. In dit dialoogvenster kunnen worksets aangemaakt, verwijderd en hernoemd worden. Daarnaast kunnen de bestaande worksets geopend of gesloten worden en aanpasbaar of nietaanpasbaar gemaakt worden en kan aan elke workset een eigenaar toegekend worden. Indien een nieuwe project gestart wordt, is enkel de workset ‘Shared Levels and Grids’ aanwezig. Dit wil zeggen dat in dit project zeven extra worksets toegekend zijn (figuur 7.19), waarin telkens een verschillend onderdeel te vinden is van het volledige project. Zo bevat de workset ‘Centrale Hal’ enkel de centrale inkomhal van het gebouw (rechts in figuur 7.19), wat de behandeling van het model een stuk vereenvoudigt.

7

Figuur 7.19.: Onderverdeling van BIM model in worksets.

Voordat het dialoogvenster uit figuur 7.19 afgesloten wordt en gestart wordt met het samenstellen van het eigenlijke BIM model, wordt door de gebruiker een workset ingesteld als ‘actieve workset’. Zo is bovenaan links in het dialoogvenster (figuur 7.19) te zien dat de workset ‘Centrale Hal’ geactiveerd is. Wanneer vervolgens het dialoogvenster afgesloten wordt en gestart wordt met het modelleren van objecten, dan zullen deze objecten automatisch terechtkomen in deze workset. Dit wordt met andere woorden ´e´en van de features van het object, zoals te zien is in figuur 7.20.

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

185

Figuur 7.20.: Weergave van de feature ‘workset’ voor de inkomdeur in het BIM model van het Casino.

Parametrische geometrie Aan de hand van ´e´en van de buitendeuren in het Casino wordt hier kort de hoeveelheid en de inhoud van de parameters ge¨ıllustreerd die aan de verschillende object types in het model gekoppeld zijn (figuur 7.21). Deze buitendeur bestaat uit naar buiten opendraaiende deurbladen, bovenaan afgewerkt met een halfrond kader. Zowel de twee deurbladen als het halfronde kader bovenaan zijn onderverdeeld door rechthoekige openingen met een glazen invulling of onderaan een houten paneel. In totaal bestaat de deur uit acht onderdelen: twee keer drie onderdelen voor elk deurblad (kader - glas - houten paneel) en ´e´en keer twee onderdelen voor het vaste kader bovenaan (kader - glas) (figuur 7.21). Het cre¨eren van de parametrische geometrie van de deur in figuur 7.21 werd gestart zoals het uitgelegd werd in § 7.5.1 voor de voorgevel van de Onze-Lieve-Vrouw en Sint-Pieterskerk. De Revit template file met de naam ‘Metric Door.rtf ’ werd geopend, waarna de deur opgebouwd werd door telkens opnieuw geometrische elementen toe te voegen en hieraan de juiste parameters toe te kennen. Een voorbeeld van een geometrisch toegevoegd element, is het houten frame van ´e´en van de twee deuren. Zoals te zien is in figuur 7.21, bestaat dit houten frame uit een enkele extrusie van een tweedimensionale lijntekening (in het paars), waarbij het einde en het beginpunt van de extrusie gespecifieerd worden in een dialoogvenster met ‘element properties’. Eenmaal deze geometrische modellering van het deurkader be¨eindigd

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

186

is, is een resultaat te zien zoals uiterst rechts in figuur 7.21.

Figuur 7.21.: De geometrische opbouw van ´e´en van de twee deurbladen. Uiterst links staat het dialoogvenster met de ‘Element Properties’ ; centraal staat in het paars de tweedimensionale lijntekening weergegeven die de vorm van de extrusie bepaalt; uiterst rechts wordt het resultaat weergegeven.

Doordat geen expliciete parameters toegekend zijn aan de vorm van de deur zelf, zorgt Autodesk Revit ervoor dat deze vorm nog enigszins aangepast kan worden. Hiervoor voorziet het zogenaamde ‘shape handles’ die rechts in figuur 7.21 weergegeven worden als driehoekige, blauwe pijlen. Door deze pijlen of shape handles te verschuiven, kan de geometrie nog vervormd worden. Hetzelfde werd uitgevoerd voor de andere onderdelen van de deur, waarbij het resulterende onderdeel telkens gevormd werd door een ‘Solid Extrusion’ van een tweedimensionale lijntekening (figuur 7.21). Naast een extrusie kan een object in Revit eveneens aangemaakt worden door middel van de commando’s ‘Solid/Void Extrusion’ - ‘Solid/Void Blend’ - ‘Solid/Void Revolve’ - ‘Solid/Void Sweep’ (figuur 7.22).

Figuur 7.22.: Beschikbare commando’s voor het aanmaken van geometrie in Revit : ‘Solid/Void Extrusion’ - ‘Solid/Void Blend’ - ‘Solid/Void Revolve’ - ‘Solid/Void Sweep’.

Aan de verschillende objecten van de deur zijn vervolgens parameters toegevoegd (§ 7.5.1),

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

187

zodanig dat verschillende types deuren konden aangemaakt worden, vertrekkende van dezelfde basisgeometrie. Aan de deur zijn in totaal de volgende negen geometrische parameters toegekend (figuur 7.23). • Lijsthoogte onderaan • Width Half • UnderInset • Thickness • Inset • Height • Muntin • Stile Width • Width

7

Figuur 7.23.: Overzicht van de aan de deur toegekende parameters.

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

188

Er moeten echter eveneens ‘constraints’ of randvoorwaarden aan de geometrie van de deur toegevoegd worden. De meest toegepaste constraint in dit voorbeeld is de constraint waarbij vastgelegd wordt dat een bepaalde shape handle, bijvoorbeeld de shape handle aan de zijkant van het deurframe (links in figuur 7.24), een bepaalde referentielijn moet volgen (centraal in figuur 7.24). Als deze referentielijnen vervolgens parametrisch vari¨eren, dan zal de shape handle van de deur deze referentielijn volgen en op die manier de geometrie van het deurblad aanpassen (rechts in figuur 7.24).

7 Figuur 7.24.: De toekenning van een constraint tussen een shape handle enerzijds en een reference plane anderzijds. Door de aanpassing van de parameter ‘Width’, die enkel toegekend werd aan het reference plane, zal ook de deur zijn geometrie aanpassen om aan deze constraint te voldoen.

Op eenzelfde manier kunnen ook minder voor de hand liggende constraints toegepast worden, zoals bijvoorbeeld het koppelen van de shape handles van het glas aan de shape handles van het deurkader. Wanneer vervolgens de vorm van ´e´en van de rechthoekige openingen in het deurframe aangepast zou worden, dan zal het glas automatisch deze beweging volgen. Dit kan eveneens toegepast worden voor de koppeling van de deur aan een bepaalde plek van de muur waar de deur moet komen, bijvoorbeeld aan de buitenzijde, aan de binnenzijde of in het midden. Een laatste constraint waar in bovenstaand model van de deur gebruik van werd gemaakt, is de constraint die kan gelegd worden tussen verschillende parameters onderling. Dit wordt doorgaans niet zo expliciet omschreven als een constraint, maar in feite werkt het wel op een

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

189

gelijkaardige manier. Een voorbeeld hiervan is terug te vinden in figuur 7.23. Hierin staat bijvoorbeeld gedefinieerd dat de parameter ‘Width Half’ altijd gelijk moet zijn aan de helft van de parameter ‘Width’ (‘Width / 2’) en dat de parameter ‘Height’ altijd gelijk moet zijn aan de som van de parameters ‘Inset’ en ‘UnderInset’. Wanneer de verschillende parameters en constraints correct toegepast zijn, kunnen automatisch uiteenlopende variaties gegenereerd worden, vertrekkende van de basisgeometrie van de deur, zoals te zien is (figuur 7.25).

Figuur 7.25.: Voorbeelden van parametrische variaties van de deur van het Casino. Uiterst links wordt de originele deur (a) weergegeven, met rechts daarvan variaties door een veranderende parameter ‘Stile Width’ (b), ‘ Lijsthoogte onderaan’ (c), ‘Height’ - ‘Inset’ - ‘UnderInset’ (d) of ‘Width’ (e).

Na deze modellering werd nagekeken op de originele plannen wat de juiste waarden zouden kunnen geweest zijn van de parameters. Deze werden vervolgens ingegeven voor de verschillende objecten van het model, waarna deze opgeslagen werden in verschillende types voor eenzelfde object. Nadat deze family file vervolgens ingeladen was in de project file, kon de deur geplaatst worden in de juiste muur en kon het juiste type geselecteerd worden van de deur (figuur 7.26) Niet elk object in het gebouwmodel is echter te cre¨eren op de manier die hierboven beschreven werd voor de deur. Voor bepaalde elementen, zoals vloeren en muren, zijn zelfs geen Revit Template Files (.rtf ) voorzien. Als voor deze elementen enigszins moet afgeweken worden van de standaardelementen die Revit voorziet, dan moeten deze elementen op een andere manier gemodelleerd worden. In het model voor het Casino moest regelmatig op deze werkwijze teruggevallen worden. Zo is het bijvoorbeeld onmogelijk om muren uit te tekenen met een in plan variabele dikte,

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

190

Figuur 7.26.: Parametrisch verschillende deurtypes zijn beschikbaar in de project file, zodat op elk moment kan gekozen worden om een licht verschillende deur te gebruiken op een bepaalde plek.

wat noodzakelijk was voor de modellering van de centrale hal van het Casino. Ook kunnen geen vloer- of plafondelementen aangemaakt worden die niet vlak zijn, wat bijvoorbeeld nodig was voor het uittekenen van de vloer van het amfitheater, het centrale koepelgewelf en verschillende kruis- en tongewelven in het gebouw. Er is echter wel een mogelijkheid voorzien binnen Revit om deze elementen aan te maken alsof het gewoon driedimensionale CAD objecten zijn, om er vervolgens een annotatie aan toe te kennen, zoals ‘Floor’, ‘Roof’ of ‘Wall’. Dit wordt hieronder ge¨ıllustreerd voor een kruisgewelf in ´e´en van de zijgebouwen van het Casino (figuur 7.27). De modellering van het kruisgewelf is opgestart via het commando ‘Modelling > create...’. Via deze weg kan aangegeven worden aan Revit welk type object zal gemodelleerd worden. Voor de modellering van het kruisgewelf werd gekozen om dit te laten benoemen als een ‘Floor’ element. Vervolgens werden in de eerste plaats de verschillende Solid elementen, waaruit het kruisgewelf opgebouwd is, elk apart gemodelleerd (links in figuur 7.28). Dit gebeurde via de ‘Solid’ commando’s die reeds aan bod kwamen in figuur 7.22. In een volgende stap werden aan deze Solid objecten twee Void objecten toegevoegd (rechts in figuur 7.28). Door deze verschillende elementen samen te voegen tot ´e´en element, werd het uiteindelijke kruisgewelf uit figuur 7.27 gevormd. Informatie in het informatiemodel Behalve geometrische informatie kan ook niet-geometrische informatie aan het model toegevoegd worden. E´en van de meest voor de hand liggende soorten informatie die aan het

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

191

Figuur 7.27.: Een parametrisch gemodelleerd kruisgewelf in Revit.

Figuur 7.28.: Een combinatie van Solids (a) en Voids (b) vormt uiteindelijk het kruisgewelf uit figuur 7.27.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

192

model gekoppeld is, is het materiaal van de verschillende elementen uit het informatiemodel. Wanneer als voorbeeld opnieuw de deur genomen wordt, waarvan reeds de geometrische parameters voorgesteld werden in figuur 7.23, dan kunnen hieraan eveneens parameters aan toegekend worden voor materialen. Deze zijn terug te vinden in figuur 7.29. Er werden twee materiaalparameters toegekend aan de deur, namelijk een materiaal voor de deurpanelen zelf (‘Door Material) en een materiaal voor het deurkader (‘Frame Material’ ). Deze twee parameters kunnen beschouwd worden als een soort ‘informatieblok’ dat gekoppeld is aan de deur. Deze ‘informatieblok’ kan verder uitgewerkt worden, zodat in feite aan deze informatie opnieuw andere informatie gekoppeld is.

7 Figuur 7.29.: Toekenning van materiaalinformatie aan objecten uit het BIM model.

Concreet werd bijvoorbeeld aan de parameter ‘Door Material’ het materiaal ‘Door Panel’ toegekend (figuur 7.29). Dit materiaal bevat op zich opnieuw verschillende parameters of informatie. Deze informatie is te vinden onder de tabbladen die in het rood aangeduid zijn in figuur 7.29. Hierin is te zien dat de informatie achter het materiaal onderverdeeld wordt in ‘Appearance’, ‘Physical’ en ‘Identity’ informatie (figuur 7.30). Deze informatie lijkt vooral van nut te kunnen zijn bij het aanspreken van externe applicaties. Via de ‘Appearance’ informatie kan zo bijvoorbeeld rechtstreeks doorgegeven worden aan visualisatiesystemen welke bitmap gebruikt moet worden wanneer het materiaal gevisualiseerd wordt. Door middel van de ‘Physical’ informatie kan doorgegeven worden aan een applicatie voor energiecalculatie welke waarden moet gebruiken om rekening te kunnen houden met de warmtetransmissie door de deur. Met de ‘Identity’ informatie zou dan weer informatie

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

193

kunnen doorgegeven worden aan applicaties voor planning en kostencalculatie (bv. welke leverancier levert het hout en hoeveel kost dit precies).

Figuur 7.30.: Informatie die in Revit toegekend wordt aan materialen, met onderscheid in ‘Appearance’ (a), ‘Physical’ (b) en ‘Identity’ (c) informatie.

In dit BIM model is eveneens getracht een onderverdeling in te brengen volgens de verschillende ruimtes van het Casino. Hiervoor zijn verschillende ‘rooms’ gecre¨eerd, waar opnieuw extra informatie aan gekoppeld zou kunnen worden over de ruimte in kwestie (figuur 7.31).

Figuur 7.31.: Aanmaak van ‘rooms’ in het BIM model van het Casino.

Deze rooms kunnen niet afzonderlijk in de ruimte uitgetekend worden, maar worden bepaald door de elementen die deze rooms begrenzen. Zo kan voor elk scheidend element (muur, vloer, dak, . . . ) door middel van een ‘Room Bounding’ parameter (figuur 7.32) gespecifieerd worden of dat element al dan niet ruimtebegrenzend is.

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

194

Figuur 7.32.: De ‘Room Bounding’ eigenschap van een muur uit het Casino bepaalt door welke elementen de ruimte begrensd is.

Resultaat Nadat de modellering vervolledigd was van de verschillende gebouwcomponenten en de verschillende soorten informatie die daaraan gekoppeld waren, zag het model eruit zoals het weergegeven is in figuur 7.33. Omgeving Tot slot werd aan het model uit figuur 7.33 ook een omgeving toegevoegd (figuur 7.34). Deze omgeving is opgebouwd uit een grondoppervlak dat bepaalde hoogtelijnen volgt. Op dit oppervlak is een pad en een vijver uitgetekend, waarrond enkele bomen en struiken geplaatst zijn, om de tuin van het Casino te vervolledigen zoals ze er ooit vermoedelijk heeft uitgezien. Het uiteindelijk resultaat is te zien in figuur 7.34.

7.6. Besluit Uit dit beschrijvend overzicht van de evolutie van CAD Computer Aided Drafing / Design applicaties naar steeds uitgebreidere BIM Building Information Modelling applicaties, lijkt algemeen besloten te kunnen worden dat vooral het aangeboden ICT kader onder Building

7

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

195

Figuur 7.33.: Building Information Model van het volledige gebouw van het Casino.

7

Figuur 7.34.: Afgewerkt BIM model van het Casino, inclusief omgeving.

HOOFDSTUK 7. IV - ‘DECISION-MAKING’

196

Information Modelling applicaties een accuraat en gedetailleerd beeld kan geven over de verschillende invloedsfactoren binnen een ontwerp, zonder hier een al te eenzijdig beeld op te willen geven. • Er moet evenwel opgemerkt worden dat in § 2.1.1 reeds vastgesteld werd dat deze BIM applicaties eerder hun toepassing lijken te kennen in de uitwerkingsfase van het ontwerp en minder in de voorontwerpfase (§ 2.1.1). In Moum (2006b,a); Penttil¨ a (2007) wordt bijvoorbeeld gesteld dat het voor architecten een te grote tijdsinvestering vraagt om van bij het begin van het ontwerp onmiddellijk te beginnen werken in BIM applicaties, omdat deze applicaties “zeer gedetailleerde componentengebaseerde gebouwmodelleera, 2007), waar doorgaans pas tijd voor technieken” vereisen van de architect (Penttil¨ uitgetrokken wordt in latere ontwerpfases (§ 2.1.1). Dit lijkt relatief goed overeen te stemmen met het beeld van BIM applicaties zoals dit naar voor komt in bovenstaande omschrijving. Hierin is het mogelijk om een gebouwontwerp tot in de allerlaatste puntjes fijn te stellen, inclusief uitvoeringsdetails en gedetailleerde karakteristieken van de gebruikte materiaalsoorten bijvoorbeeld (§ 7.5.2). Om tot dit gebouwontwerp te komen, moet echter elk element reeds vrij gedetailleerd uitgewerkt worden, met concrete waarden voor deurafmetingen, hoogtes van ruimtes, vormen van ramen, enzovoort, wat in principe niet van het allergrootste belang is in de voorontwerpfase. • In dat opzicht lijkt de benadering die via Feature-Based Modelling (FBM) (§ 7.4) en de generische en grafische representaties van Achten (1997) (§ 7.4.2) gerealiseerd werd, minstens een waardig alternatief van BIM te zijn, met betrekking op toepassingsmogelijkheden in de ontwerpfase. Hierin wordt namelijk in de eerste plaats getracht een informatiemodel te beschrijven aan de hand van meer abstracte elementen, zoals een ‘grid’, een ‘aslijn’, een ‘contour’, enzovoort, wat als een meer geschikt ICT kader zou kunnen beschouwd worden voor decision-making in de voorontwerpfase dan BIM.

Algemeen kan besloten dat de ICT applicaties voor de ondersteuning van het aspect decisionmaking zich in de eerste plaats lijken te baseren op een te zeer componentengebaseerde tekenmethode, waardoor ontwerpers of architecten hier minder op terugvallen voor decision making in het voorontwerp. Deze modelleermethode biedt echter wel ´e´en van de meest geschikte kaders waarin de vele factoren die het decision-making be¨ınvloeden, objectief gestructureerd zouden kunnen worden en waarin dus wel aan decision-making gedaan zou kunnen worden.

7

Deel III.

Huidige Benadering

197

8 Digitale datastructuur

H

ET in deze scriptie reeds uitgevoerde onderzoek naar mogelijke ICT toepassingen die kunnen aangewend worden binnen een ICT ondersteunde ontwerpomgeving, heeft weinig bestaansrecht indien er geen correcte ondersteuning gegeven wordt door middel van de gepaste bestandsformaten. Uitgaande van de evolutie van object-ge¨ ori¨enteerde talen naar meer semantische talen, talen op basis van ontologische definities en talen die specifiek gericht zijn op interoperabiliteit tussen systemen, is geopteerd om in deze scriptie een korte studie van digitale dataformaten uit te voeren, maar om dit te beperken tot deze taalsoorten. De informatie die in dit hoofdstuk verwerkt is, is grotendeels afkomstig van de documentatie die gegeven wordt door de instanties die het betreffende dataformaat ontwikkeld hebben. Onderstaande informatie zou met andere woorden teruggevonden moeten kunnen worden op de webpagina’s die voor de besproken instanties gegeven wordt.

8.1. Ontologie¨ en Het woord ontologie kent zijn oorsprong in de Griekse filosofie en ontleent zijn betekenis bijgevolg ook uit het Grieks. Het betekent zoveel als “de leer (logos) van het zijn (ontos)”. In de computerwetenschappen wordt een ontologisch beschrijvingssysteem veelal eerder praktijkgericht begrepen als een systeem om elementen ´e´enduidig en semantisch correct te beschrijven volgens hun intrinsieke betekenis. Dit zou betekenen dat in een ontologisch systeem elk element maximaal ´e´en keer zou moeten beschreven worden om er nadien ontelbare keren naar te kunnen verwijzen. Wanneer een informatiesysteem deze set aan

198

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

199

ontologische beschrijvingen gebruikt als dataformaat om informatie mee door te geven, dan zou de informatie uit dit informatiesysteem in principe automatisch gebruikt moeten kunnen worden door applicaties en informatiesystemen die van deze zelfde ontologische beschrijvingen gebruik maken, zonder rekening te moeten houden met eventuele applicatie-specifieke elementen in dit dataformaat.

8.2. Semantic Web Wat tot op vandaag het World Wide Web (WWW) kenmerkt, is dat het niet gelezen kan worden door informatiesystemen, maar enkel door menselijke gebruikers. Het bestaat namelijk typisch uit webpagina’s die in HTML (HyperText Markup Language) of in een HTMLgebaseerde taal beschreven zijn. De structuur van de webpagina’s wordt, bij het gebruik van HTML als informatiedrager, bijeengehouden door handmatig gedefinieerde links of ‘hyperlinks’ en een beschrijving van de visuele opmaak of ‘markup’ van de webpagina. Aan een informatiesysteem wordt met andere woorden enkel informatie weergegeven over wat moet weergegeven worden en niet over welke informatie de webpagina eigenlijk bevat. Object-ge¨ ori¨enteerde talen, zoals XML, verbeterden dit enigszins, in die zin dat met deze talen wel aan de computer doorgegeven kon worden welke informatie er in welke structuur op de webpagina stond. Dit kon echter op zodanig veel manieren beschreven worden dat het onmogelijk bleek om applicaties te maken die deze beschreven informatie in XML voor ´elke pagina van het web kon analyseren via dezelfde hulpmiddelen. Deze object-ge¨ ori¨enteerde talen werden vooral om deze reden als onvoldoende beschouwd om bovenstaande tekortkomingen rond het huidige WWW op een gestructureerde en effectieve manier op te lossen. Dit werd erkend door verschillende instanties als de reden waardoor geautomatiseerde analyse van informatie op het WWW onmogelijk lijkt. Daarom werd een zogenaamd ‘Semantic Web’ conceptueel voorgesteld, waarin nieuw ontwikkelde, ontologisch beschrijvende talen dit probleem trachten aan te pakken door informatie zo ´e´enduidig mogelijk te proberen vastleggen (§ 8.1). Onder impuls van het World Wide Web Consortium (W3C)1 , werd dit conceptueel Semantic Web (SW) onderzocht als mogelijke opvolger van het huidig bestaande WWW of World Wide Web. De talen die hier achtereenvolgens voor ontwikkeld zijn, worden opgesomd en kort beschreven in § 8.2.1 tot en met § 8.2.4. De bespreking van deze talen gebeurt grotendeels aan de hand van teruggevonden bronnen op de webpagina’s van het W3C.

1

W3C World Wide Web Consortium - http://www.w3c.org

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

200

8.2.1. XML XML (Extensible Markup Language) is net zoals HTML een Markup Language, waaruit geconcludeerd zou kunnen worden dat hun algemene doelstellingen gelijkaardig zijn, namelijk het defini¨eren van hoe informatie weergegeven moet worden, al dan niet in een WWW of SW omgeving. De manier waarop dit gebeurt in XML, verschilt echter wel van hoe dit bij HTML gebeurt-. XML is namelijk een object-ge¨ ori¨enteerde taal, in tegenstelling tot HTML, waarin de weergave van informatie volledig uitgedrukt wordt door het specifi¨eren van lijnen, achtergronden, lettertypes en figuren. XML stelt de gebruiker hierdoor in de eerste plaats in staat om de inhoud en de structuur van heel uiteenlopende systemen te beschrijven, zonder zich te moeten beperken tot de beschrijving van het eigenlijke uitzicht van het resultaat. Zo werd het mogelijk gemaakt om de ‘objecten’ in de object-ge¨ ori¨enteerde taal volledig zelf te defini¨eren en onderling te relateren. Dit wordt ge¨ıllustreerd in codefragment 8.1. < f i e t s> page mijn f i e t s r o o d mijn f i e t s r o o d < f i e t s> < d e t a i l s> h r e f = ‘ ‘ page ’ ’

mijn f i e t s r o o d < f i e t s h r e f = ‘ ‘ page ’ ’ name= ‘ ‘ mijn f i e t s ’ ’ c o l o r = ‘ ‘ r o o d ’ ’ /> Codefragment 8.1: Illustrerend voorbeeld van de structuur van een XML schema.

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

201

Hetzelfde object kan dus op heel verschillende manieren beschreven worden, afhankelijk van de structuur die de programmeur van de applicatie in kwestie wil gebruiken. Daardoor is een informatiesysteem echter nog niet in staat om de semantische betekenis van elementen in het XML document automatisch te begrijpen. Als een applicatie bijvoorbeeld moet zoeken naar de kleur van “mijn fiets”, dan moet de ontwikkelaar van het programma minstens weten hoe dit in het bijhorende XML document is opgeslagen en moet hij liefst ook weten in welke structuur dit opgeslagen is, aangezien dit in heel uiteenlopende vormen kan beschreven worden (codefragment 8.1). Waar in de jaren ‘70 werd gesteld dat object-ge¨ ori¨enteerde talen een mogelijke oplossing waren voor het probleem van computergestuurd begrip van informatie, groeide vanaf de jaren ‘90 het besef dat deze object-ge¨ ori¨enteerde talen alleen misschien niet genoeg waren. De object-ge¨ ori¨enteerde talen, waarvan XML op basis van zijn ruime toepassing wellicht een heel representatief voorbeeld is, legden namelijk geen eenduidige betekenis of structuur vast voor de beschreven elementen van informatiesystemen. Bijgevolg moest elke computergestuurde applicatie ondanks de object-ge¨ori¨enteerde implementering nog steeds uitgewerkt worden naar de eigenlijke structuur en beschrijving waarin de te verwerken informatie gevat werd. Nadat bovenstaand probleem duidelijker gesitueerd werd, werd een mogelijke oplossing uitgedacht op basis van ontologische beschrijvingen van domeinen (§ 8.1). In deze ontologische beschrijving worden zowel de samenstellende elementen als hun onderlinge relaties ´e´enduidig beschreven, zodat elke semantische applicatie op eender welke computer in staat zou moeten zijn om deze ontologische beschrijving te begrijpen en te verwerken (§ 8.1). Voor het Semantic Web werd dit verder uitgewerkt in de ontwikkeling van de talen RDF, DAML+OIL en OWL.

8.2.2. RDF Met het Resource Description Framework (RDF) werd een variant op XML uitgewerkt door het World Wide Web Consortium (W3C). Oorspronkelijk werd dit bedoeld als een metadatamodel waarin de structuur van documenten verwerkt kon worden. Het aanvankelijk idee achter RDF als metadatamodel was om bronnen of elementen te beschrijven door middel van drieledige uitdrukkingen, genaamd ‘triplets’. Deze triplets werden samengesteld uit een ‘subject’, een ‘predicaat’ en een ‘object’ (figuur 8.1), telkens met een semantisch ´e´enduidige betekenis. Door deze werking kon het model uiteindelijk echter een stuk algemener gebruikt worden als een methode om informatie achter informatiesystemen eenduidig te beschrijven. Elk van de drie elementen uit de triplets bezitten doorgaans een URI of Uniform Resource Identifier , die bijna fungeert als een ID (identifier - identiteit) voor het element. Aan de hand van deze URI kan vervolgens extra, externe informatie aan deze elementen gekoppeld

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

202

Figuur 8.1.: Visuele voorstelling van de triplets in RDF (a) met een illustrerend voorbeeld voor het object ‘mijn fiets’ (b).

worden. De URI wordt meestal gebruikt voor de koppeling van een webadres aan een bepaald element uit de RDF structuur, juist doord´ at RDF zo intensief gebruikt wordt in samenwerking met het Semantic Web. Via deze URI kan in principe echter eender welke vorm van informatie gekoppeld worden aan het subject, object of predicaat. Bovenstaand mechanisme van RDF (figuur 8.1) staat al enige tijd centraal in de ontwikkeling van het Semantic Web door het W3C. Door de informatie eenduidig te defini¨eren in triplets, kunnen informatiebestanden omgezet worden in een uitgebreide samenstelling van verschillende drieledige schema’s. Hierdoor krijgt informatie die beschreven wordt in RDF een duidelijke betekenis en een ´e´enduidige structuur, zodat deze informatie in een latere fase ´e´enduidig kan teruggevonden worden in deze structuur. Het zoeken naar informatie in de RDF triplets is vandaag onder andere mogelijk gemaakt via de SPARQL taal of de SPARQL Protocol And RDF Query Language, een variant op de algemenere SQL taal of Structured Query Language. Het codefragment 8.2 is een voorbeeld van een SPARQL Query waarin gezocht wordt naar de titel van een bepaald document op basis van de RDF datastructuur. PREFIX d c : SELECT ? t i t l e WHERE { d c : t i t l e ? t i t l e } Codefragment 8.2: Voorbeeld van een zoekopdracht of ‘query’ in een RDF databestand, via de SPARQL Query Language.

Een problematische eigenschap van RDF voor het gebruik in een intelligente, semantisch

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

203

eenduidige informatieomgeving zoals het Semantisch Web, kan als volgt worden omschreven. De volgorde van voorkomen van de verschillende schematische triplets in een informatiebestand is in feite van minstens even groot belang als de structuur en inhoud van de afzonderlijke RDF triplets, hoewel hier in RDF niet rechtstreeks op ingegaan wordt. In een RDF bestand zijn de verschillende triplets per bronbestand namelijk zonder enige vorm van volgorde in ´e´en RDF bestand opgeslagen en wordt de volgorde waarin de triplets in een bepaalde informatiebron voorkomen, eerder verwaarloosd.

8.2.3. DAML+OIL De DAML+OIL taal is een combinatie van twee voorgangers, de talen DAML en OIL. DAML staat daarbij voor DARPA Agent Markup Language, waarbij DARPA opnieuw staat voor Defense Advanced Research Projects Agency, een onderzoeks- en ontwikkelingsorganisatie van het Departement van Defensie in de Verenigde Staten. De DAML taal vertrok van de eerder ontwikkelde XML en RDF datastructuren om op basis daarvan een nieuwe, beter gestructureerde, maar toch eenduidige Markup Language uit te werken. De OIL Language (Ontology Inference Layer of Ontology Interchange Language) werd onafhankelijk hieraan uitgewerkt in het IST project OntoKnowledge aan de Vrije Universiteit Amsterdam en de University of Manchester. In dit project werd in de eerste plaats gewerkt aan een taal die ontologische structuren konden beschrijven. Door het samenvoegen van DAML met OIL, ontstond een nieuwe taal die geschikt geacht werd voor gebruik in het Semantic Web, omwille van de combinatie van een verbeterde XMLen RDF -gebaseerde taal met een gestructureerde taal voor het beschrijven van ontologie¨en. In 2006 werd het onderzoek rond DAML+OIL afgerond en werd het resultaat ter beschikking gesteld van de W3C onderzoeksgroep rond webontologie¨en (de Web Ontology Working Group (WebOnt2 )). Nagenoeg alle DAML+OIL functionaliteit werd door deze onderzoeksgroep ge¨ıncorporeerd in de nieuw ontwikkelde OWL of Web Ontology Language van het W3C.

8.2.4. OWL De OWL Language of Web Ontology Language werd vanuit DAML+OIL ontwikkeld door de Web Ontology Working Group (WebOnt) van het W3C, specifiek voor toepassing binnen het Semantic Web. Het tracht meer mogelijkheden te bieden naar interpreteerbaarheid door informatiesystemen dan de talen XML, RDF en RDF-Schema (RDF-S). Om dit te realiseren, wordt getracht om een expliciet ontologische structuur op te stellen, zoals dit 2

WebOnt Web Ontology Working Group - http://www.w3.org/2001/sw/WebOnt/

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

204

reeds gestart was bij de ontwikkeling van DAML+OIL, en deze intensief te gebruiken voor de beschrijving van informatie. Het resultaat hiervan zou moeten zijn dat informatie kan samengesteld worden uit, ten eerste, termen waarvan de betekenis semantisch of ´e´enduidig vastligt in digitale woordenboeken en, ten tweede, relaties die de onderlinge verhoudingen vastleggen tussen deze termen. Dit werd gebaseerd op de algemeen gebruikte interpretatie van ontologie¨en in de Semantic Web context (§ 8.1). De algemene wijze waarop de informatie in een OWL datastructuur gevat kan worden en de daaruit volgende mogelijkheden worden in de OWL Web Ontology Language Guide van het W3C ge¨ıllustreerd aan de hand van volgend voorbeeld. Dit voorbeeld gaat over het vinden van een antwoord via OWL op de gegeven vraag “Vertel mij welke wijnen ik zou moeten kopen zodat ze passen bij elke gang uit de volgende menu. En Sauternes drink ik niet graag.”. Kort samengevat wordt elke ‘omgeving’ die voorkomt in de bovenstaande vraag, nl. ‘wijn’ en ‘eten’, samen met gerelateerde ‘omgevingen’, zoals ‘wijnregio’, ‘druifsoorten’, ‘wijnproducenten’, ‘kleur’, in een ontologische structuur gegoten. Dit gebeurt volledig in de OWL structuur, die zelf ook refereert naar elementen uit voorgaande talen, zoals RDF, RDFS en XSD (XML Schema Definition). De verschillende ontologische structuren vormen volgens de OWL Web Ontology Language Guide van het W3C samen een soort prototype van het Semantic Web. Codefragment 8.3 illustreert de ontologisch werking van de OWL structuur voor de wijn ‘LindemansBin65Chardonnay’ en de druifsoort ‘CabernetSauvignonGrape’. 1. Een nieuwe klasse wordt aangemaakt met de naam ‘Grape’. 2. Een nieuwe klasse ‘WineGrape’ wordt aangemaakt als een subklasse van ‘Grape’. Alle elementen in ‘WineGrape’ zijn dus ook elementen van ‘Grape’. 3. Er wordt een nieuw element aangemaakt van de klasse ‘WineGrape’, met de naam ‘CabernetSauvignonGrape’. 4. Een nieuwe klasse ‘Wine’ wordt aangemaakt als een subklasse van ‘PotableLiquid’, dat gedefinieerd werd in een externe OWL ontologie ‘food’. Deze klasse krijgt twee labels, ‘wine’ (Engels) en ‘vin’ (Frans). 5. Een objecteigenschap ‘MadeFromGrape’ wordt aangemaakt als verbinding tussen de elementen in het domein ‘Wine’ en de elementen in het bereikgebied ‘WineGrape’. 6. Een nieuw element ‘LindemansBin65Chardonnay’ wordt aangemaakt met een toegekende objecteigenschap. Door de toekenning van deze eigenschap weet het element dat

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

205

het zelf een element is uit het domein ‘Wine’ en dat het een relatie ‘madeFromGrape’ aangaat met het element ‘ChardonnayGrape’ uit het domein ‘WineGrape’. < !−− s t a p 1 −−> ... < !−− s t a p 2 −−> < !−− s t a p 3 −−> <WineGrape r d f : I D = ‘ ‘ CabernetSauvignonGrape ’ ’ /> < !−− s t a p 4 −−> < r d f s : l a b e l xml:lang= ‘ ‘ en ’ ’>wine < r d f s : l a b e l xml:lang= ‘ ‘ f r ’ ’>v i n ... < !−− s t a p 5 −−> < !−− s t a p 6 −−> <madeFromGrape r d f : r e s o u r c e =‘‘#ChardonnayGrape ’ ’ /> Codefragment 8.3: Aanmaak van de elementen ‘Wine’ en ‘WineGrape’ en de definitie van de onderlinge relaties in het OWL dataformaat.

Dit ‘verkleind prototype’ van het Semantic Web kan vervolgens doorzocht worden op zeer specifieke informatie. Hiervoor wordt een uitgebreide set aan functies toegevoegd binnen OWL zelf, die het in principe enkel mogelijk trachten te maken om gericht om te gaan met de aangemaakte, semantische elementen. De objecteigenschappen die in codefragment 8.3 bijvoorbeeld aangemaakt zijn, kunnen bijvoorbeeld gemakkelijk ge¨ınverteerd worden tot een nieuwe objecteigenschap door middel van de functie owl:inverseOf (codefragment 8.4).

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

206

Op basis van de eigenschap ‘hasMaker’ kan een exact omgekeerde eigenschap ‘producesWine’ aangemaakt worden, net zoals met de objecteigenschap ‘madeFromGrape’ uit codefragment 8.3 een omgekeerde eigenschap ‘usedInWine’ aangemaakt zou kunnen worden. Codefragment 8.4: Extra functionaliteit werd binnen OWL toegevoegd aan de aangemaakte OWL elementen, zoals bijvoorbeeld de owl:inverseOf functie.

Een voorbeeld die de semantische zoekmogelijkheden van deze OWL datastructuur (codefragment 8.3) en de extra OWL functionaliteit (codefragment 8.4) illustreert, wordt weergegeven in codefragment 8.5. Hierin worden drie klasses aangemaakt, namelijk ‘WhiteWine’, ‘Burgundy’ en ‘WhiteBurgundy’, met elk als inhoud de resultaten van gerichte zoekopdrachten. Om bijvoorbeeld de klasse ‘WhiteWine’ af te bakenen, zou een functie owl:intersectionOf uitgevoerd kunnen worden op de collectie ‘Wine’. Een eigenschap die doorgegeven wordt aan owl:intersectionOf, is dat enkel wijnen mogen geselecteerd worden waar onder de objecteigenschap ‘hasColor’ de waarde (‘owl:hasValue’) ‘White’ gegeven is. Daardoor worden enkel de witte wijnen uit de collectie geselecteerd om deze op te slaan in de klasse ‘WhiteWine’. Dit gebeurt analoog voor de klasse ‘Burgundy’. < o w l : R e s t r i c t i o n> < o w l : R e s t r i c t i o n>

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

207

Codefragment 8.5: Uitgebreide OWL functionaliteit laat toe om in het Semantic Web heel specifieke zoekacties uit te voeren en de gewenste informatie op te zoeken.

Om een klasse aan te maken die vervolgens alle witte, Bourgondische wijnen bevat, zou de functie owl:intersectionOf enkel nog toegepast moeten worden op de twee eerder aangemaakte klasses ‘Burgundy’ en ‘WhiteWine’ (codefragment 8.5). Via deze owl:intersectionOf worden nu enkel de elementen geselecteerd die in deze twee klasses tegelijk voorkomen, waarbij geen enkele extra restrictie opgelegd wordt. Een extra restrictie zou echter wel mogelijk zijn, afhankelijk van de doorgegeven zoekopdracht. Zo zou door extra restricties bijvoorbeeld de ‘beste witte bourgondische wijn uit het jaar 2002 van een set van wijnproducenten’ kunnen geselecteerd worden, op voorwaarde dat deze informatie in de ontologische OWL structuur opgenomen is. Bovenstaand voorbeeld illustreert enkele functionaliteiten die volgens de OWL Web Ontology Language Guide van het W3C op dit moment aanwezig zijn in de OWL Language en die rechtstreeks gebaseerd zijn op een ontologische benadering van een informatiestructuur (§ 8.1). Vanzelfsprekend is OWL uitgebreider dan wat hierboven getoond werd. Voor extra informatie wordt hiervoor doorverwezen naar de OWL Web Ontology Language Guide van het W3C.

8.3. AEC industrie 8.3.1. International Organization for Standardization (ISO) In de voorbije decennia groeide in de AEC industrie en bij CAD systeemontwikkelaars een besef dat een goede data-uitwisseling nodig was tussen verschillende CAD systemen vereist is om onder andere een verbeterde effici¨entie in de AEC industrie te kunnen bekomen. Dit resulteerde in de idee om CAD modellen, net als in de benadering van het Semantic Web, achtereenvolgens op te slaan in een object-ge¨ ori¨enteerde en in een ontologische taal. Dit zou het mogelijk maken dat AEC-gerelateerde informatie zowel voor de mens als voor informatiesystemen leesbaar en begrijpbaar zou worden.

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

208

STEP Vanaf 1984 begon de International Organization for Standardization (ISO) met de uitwerking van de STEP standaard (Standard for the Exchange of Product Model Data). De standaard werd in de eerste plaats ontwikkeld voor toepassing binnen Product Lifecycle Management en Product Model Data Exchange en baseerde zich oorspronkelijk op de eerdere initiatieven IGES (VS), SET (Frankrijk) en VDAFS (Duitsland). De oorspronkelijke doelstelling werd omschreven als “het ontwikkelen van een mechanisme dat het mogelijk maakt om data van een product te beschrijven en bij te houden doorheen de levenscyclus van dat object”. Deze standaard werd dus niet enkel voor gebruik binnen de AEC industrie ontwikkeld, maar wel voor meer algemeen gebruik doorheen de verschillende takken van de industrie die met dergelijke producten te maken kregen. Bijgevolg werd het zo breed mogelijk uitgewerkt om tegemoet te kunnen komen aan de noden van de verschillende partijen in deze industrie. De STEP standaard voor productmodeldata-uitwisseling is rond 1994 voor het eerst uitgegeven onder de ISO 10303 standaard met als titel ‘Industrial automation systems and integration - Product data representation and exchange3 ’. Het werd onder andere gebruikt voor de uitwisseling van data tussen CAD, CAM, CAE (Computer-Aided Engineering) , Product Data Management/EDM en andere CAx systemen. Binnen deze scriptie wordt minder aandacht besteed aan de ontwikkeling en toepassing van de STEP standaard zelf, maar worden eerder de daaruit volgende datastandaarden IFC en IFD beschreven, die ontwikkeld werden op basis van deze meer algemeen toepasbare STEP standaard. Deze twee beschrijvingssystemen werden met hetzelfde doel als de STEP standaard ontwikkeld, namelijk geoptimaliseerde en gestandaardiseerde data-uitwisseling tussen verschillende systemen (interoperabiliteit), maar dan voor specifieke toepassing binnen de AEC industrie. EXPRESS De EXPRESS Data Definition Language is een taal die ontwikkeld is om de datamodellen in STEP te kunnen beschrijven. Dit kan zowel tekstueel als grafisch gebeuren. Afhankelijk van de toepassing waarin het datamodel gebruikt wordt, kan ´e´en van deze twee voorstellingen gebruikt worden. Zo zou de tekstuele voorstelling bijvoorbeeld eerder gebruikt kunnen worden voor de controle van de formele correctheid van het datamodel, terwijl de grafische 3

ISO 10303-1:1994 Industrial automation systems and integration Product data representation and exchange - Overview and Fundamental Principles, International Standard, ISO TC184/SC4, 1994, http://www.steptools.com/.

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

209

voorstelling (EXPRESS-G) eerder geschikt kan zijn voor menselijke interpretatie (figuur 8.2). De EXPRESS Data Definition Language beschrijft verschillende entiteiten in een samenstellend schema. Een entiteit kan daarbij gedefinieerd worden als een subtype onder andere entiteiten of onder ´e´en of meerdere supertypes, of als een supertype dat verscheidene subtypes bevat (figuur 8.2). Elke entiteit krijgt vervolgens verscheidene attributen toegekend, die er voor zorgen dat de entiteiten bepaalde eigenschappen of ‘properties’ krijgen en dat de entiteiten onderling gerelateerd kunnen worden volgens een bepaalde relationele betekenis. De algemene structuur en de werking van de EXPRESS Data Definition Language wordt kort ge¨ıllustreerd met een voorbeeld in figuur 8.2. Het voorbeeld bevat vier entiteiten, namelijk het supertype ‘Person’, de twee subtypes ‘Male’ en ‘Female’ en de stringentiteit ‘Name’ die de naam van de persoon bevat (figuur 8.2). In het tekstueel schema staat beschreven hoe het datamodel deze vier entiteiten onderling relateert, met centraal een abstracte ‘Person’ die slechts kan bestaan uit ´e´en van de twee subtypes ‘Male’ of ‘Female’. In omgekeerde zin kan aan een ‘Person’ ´e´en verplicht attribuut toegekend worden, namelijk het ‘Name’ attribuut, en twee optionele attributen ‘father’ of ‘mother’, waarbij ‘father’ verplicht ‘Male’ is en ‘mother’ verplicht ‘Female’.

8

Figuur 8.2.: Het datamodel dat door de EXPRESS Data Definition Language beschreven wordt, is beschikbaar in een tekstuele voorstelling (a) en een grafische voorstelling (b).

Bovenstaande basisprincipes kenmerken de object-ge¨ ori¨enteerde EXPRESS Data Definition Language, en hoewel bovenstaand voorbeeld eerder eenvoudig blijft, kan een STEP datamodel via deze principes zeer complex gemaakt worden en toch goed gestructureerd blijven (Yang et al., 2004). Complexere datastructuren kunnen bijvoorbeeld teruggevonden worden in gegenereerde IFC databestanden van een gebouwmodel (§ 8.3.2).

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

210

Aangezien de STEP standaard en de EXPRESS Data Definition Language zich vooral richtten op de eigenlijke object-ge¨ ori¨enteerde beschrijving van datamodellen, werd bewust niet verder ingegaan op de eigenlijke inhoud van deze informatiestructuren. Er werd namelijk in de eerste plaats getracht om een flexiblel kader op te stellen, dat het mogelijk zou maken, net zoals XML dat leek te doen binnen de SW benadering, om elk mogelijk informatiemodel hierin op te kunnen slaan. De eigenlijke overstap die in het Semantic Web gebeurde vanuit de object-ge¨ ori¨enteerde talen (XML) naar ontologische talen (OWL), werd dus niet door STEP en EXPRESS gedaan, maar wel eerder door de IFC en IFD initiatieven van het International Alliance for Interoperability (IAI).

8.3.2. IAI International Alliance for Interoperability Door de recente toename aan systemen voor informatiemodellering in de AEC-industrie (hoofdstuk 7), is steeds meer aandacht besteed aan de bevordering van de interoperabiliteit tussen verschillende systemen en ontwerpers. Deze hebben als specifiek doel om alle gebruikers in een AEC project een zelfde standaardtaal te bezorgen waarop hun systemen en modellen kunnen gebouwd worden, zodat geen informatie of tijd verloren gaat in de onderlinge uitwisseling van informatie. Vooral de overgang tussen verschillende softwareplatformen, bijvoorbeeld van Autodesk Revit naar Nemetschek ArchiCAD, kan hierdoor sterk vereenvoudigd worden. Het IAI (International Alliance for Interoperability 4 ) neemt deze opdracht voor zijn rekening voor de AEC industrie, met als resultaat de uitwerking van twee Interoperability Specification Languages (IFC en IFD ), op basis van de STEP standaard en de EXPRESS Data Definition Language uit § 8.3.1. IFD International Framework for Dictionaries IFD staat voor International Framework for Dictionaries. Het is ontwikkeld als een bibliotheek van ontologie¨en die gebruikt kan worden bij de aanmaak van semantisch gestandaardiseerde applicaties. De IFD standaard zelf werd vanaf 1999 ontwikkeld tot het formeel uitgegeven werd in april 2007 (ISO 12006-3). De resulterende applicaties concentreren zich in de AEC industrie en trachten voor deze industrie zo goed mogelijk een semantisch lexicon samen te stellen dat gebruikt kan worden voor extra interoperabiliteit. Zo werd in Noorwegen de BARBi library 5 ontwikkeld, in Nederland het LexiCon 6 en in Frankrijk de applicatie EDIBATEC 7 . 4

IAI International Alliance for Interoperability - http://www.iai-international.org/ BARBi library, Noorwegen - http://www.barbi.no/index.jsp 6 LexiCon, Nederland - http://www.stabu-lexicon.nl/ 7 EDIBATEC, Frankrijk - http://www.edibatec.org 5

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

211

In IFD wordt, in tegenstelling tot wat in traditionele woordenboeken gebeurt, niet getracht om een woord aan een betekenis of om woorden aan woorden te koppelen, maar wordt getracht om het eigenlijke beschreven element als een afzonderlijk ‘concept’ in de IFD omgeving te brengen om vanuit dit concept ontologische relaties te defini¨eren met overeenkomende woorden. Dit net van relaties en concepten zou heel precies de ontologische betekenis en structuur van hele domeinen moeten kunnen vastleggen. Wanneer dit ontologisch net rond een concept verder uitgebreid wordt en een set van vertalingen meegegeven wordt aan dat centraal concept, kan dan afhankelijk van de context een bepaalde vertaling weergegeven worden aan de gebruiker. Het meest evidente verschil ligt in de taal (Frans, Engels, Nederlands, . . . ) die gebruikt moet worden in een bepaalde context, maar ook de inhoud zelf van de context speelt een rol. Waar een concept namelijk kan voorkomen in uiteenlopende omgevingen, bestaat per omgeving doorgaans ´e´en geschikte woordelijke omschrijving voor het concept. In sommige contexten is het bijvoorbeeld van belang om het woord ‘balk’ te gebruiken in plaats van ‘ligger’ of het woord ‘millimeter’ in plaats van ‘mm’ (figuur 8.3). Door het gebruiken van relationele definities en centrale concepten is het eveneens mogelijk om verschillende concepten aan een zelfde woord te koppelen. Zo kan het woord ‘meter’ gekoppeld worden aan een eenheid van afstand, maar ook aan een vrouwelijk persoon.

8

Figuur 8.3.: Centraal in IFD staat het concept zelf, met daaraan verschillende relaties gekoppeld naar woorden die weergegeven kunnen worden afhankelijk van de context of naar andere, gerelateerde concepten (figuur 8.4).

Om het gebruik van IFD in goede banen te kunnen leiden, is een techniek voorgesteld om de verschillende concepten en de gerelateerde woorden of objecten een gegarandeerd unieke ID mee te geven. Dit gebeurt onder de vorm van een GUID (Global Unique Identifier) of UUID (Universal Unique Identifier). Deze GUID wordt zowel gebruikt binnen IFC als binnen IFD en is te herkennen als een string van 22 tekens, zoals “7QDBkvCA1+B9K/U0vrQx1A”. Binnen de AEC industrie wordt IFD vooral gebruikt als een ontologisch beschrijvend naam-

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

212

systeem in combinatie met IFC. IFD is namelijk niet alleen in staat om ‘betekenissen’ aan concepten te koppelen, maar het is eveneens in staat om concepten en betekenissen aan elkaar te koppelen tot een ontologisch beschrijvend netwerk, bijvoorbeeld voor een bepaald gebouw of gebouwcomponent (figuur 8.4).

Figuur 8.4.: Schema van een ontologisch systeem dat gebruikt kan worden om verschillende soorten deuren te beschrijven, met weergave van relaties zoals ‘consists of ’ en ‘is part of ’ om de verhoudingen tussen verschillende concepten te defini¨eren.

Er bestaat dus een gesofisticeerde, maar zeer effici¨ente manier om informatie over beschreven gebouwen, webpagina’s of andere elementen overzichtelijk te structureren en nadien op een nog eenvoudiger wijze terug te vinden en verder te verwerken in eender welke applicatie die er op voorzien is om informatie in dit eenduidig ontologisch formaat te ontvangen (figuur 8.5). IFC Industry Foundation Classes De Industry Foundation Classes (IFC) is een datastandaard die parallel aan IFD uitgewerkt wordt door het IAI, voor de verbetering van interoperabiliteit binnen de bouwindustrie. Het is gebaseerd op de ISO standaarden STEP en EXPRESS (§ 8.3.1). Op basis van ontologie¨en wordt met IFC een nieuwe datastructuur voor gebouwinformatie uitgewerkt die het mogelijk zou moeten maken om de verschillende bestaande systemen op een gelijke lijn te brengen en de overgang van informatie vanuit het ene systeem naar het andere systeem probleemloos te doen verlopen. IFC werkt hiervoor nauw samen met IFD. In IFD kunnen namelijk volledige, ontologische structuren beschreven worden aan de hand van ‘classes’, ‘attributes’, ‘relations’ en ‘events’ (§ 8.3.2). Dit wil zeggen dat het concept ‘deur’ bijvoorbeeld via IFD reeds weet dat het

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

213

Figuur 8.5.: De in IFD beschreven eigenschappen van een raam kunnen gebruikt worden in applicaties die weten onder welke ontologische beschrijving de benodigde informatie (zoals de warmtedoorgangsco¨effici¨ent en afmetingen in een applicatie voor energiecalculatie) te vinden is.

in een concept ‘muur’ geplaatst moet worden, dat het als attributen bepaalde afmetingen, een materiaal, een producent enzovoort heeft en dat er verschillende soorten ‘deuren’ zijn, afhankelijk van de functie. Wat IFD echter uitdrukkelijk overlaat aan IFC, is de eigenlijke instanti¨ering van de individuele elementen. Binnen IFC moet met andere woorden gespecifieerd worden binnen w´elke muur de deur nu precies zit, wat de functie is, en wat de verschillende eigenschappen of attributen als waarde hebben. Een eenvoudig voorbeeld van hoe een deel van de instanti¨ering via IFC precies in zijn werk gaat, wordt weergegeven in een voorbeeld waarin ‘IFCPROPERTYSETS’ toegekend worden aan IFC objecten (figuur 8.6). Er wordt een deur of ‘IFCDOOR’ getoond die geplaatst is in een ‘IFCWALLSTANDARDCASE’, de IFC instanti¨ering van een muur. Per element wordt in IFC een nieuwe, oplopend genummerde lijn begonnen in het centraal IFC bestand. Aan de hand van deze nummers is te illustreren hoe de verschillende elementen aan elkaar gerelateerd zijn. In figuur 8.6 wordt via #61 en #202 respectievelijk een muur en een deur gedefinieerd. Voor de deur worden vervolgens via #210 tot #219 verschillende eigenschappen beschreven. Deze eigenschappen worden in groepen onderverdeeld via #226 tot #228, waarna elke aangemaakte set via #238 tot #240 toegekend wordt aan de deur. Via #231 wordt tenslotte expliciet gespecifieerd dat de deur (#202 ) deel uitmaakt van de ruimtelijke structuur van de muur (#61 ).

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

214

8

Figuur 8.6.: Voorbeeld van de structuur van een IFC bestand op basis van een tekening met een deur in een muur.

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

215

Op dit moment is de IFC technologie tot op een bepaald niveau ge¨ımplementeerd in de bestaande applicaties van o.a. Autodesk, Bentley en Nemetschek. Hierin wordt het vooral gebruikt in de aanmaak van een BIM uitvoeringsmodel, wat hetzelfde is als een ontologisch informatiemodel dat beschrijft hoe het gebouw is opgebouwd uit de verschillende samenstellende componenten.

8.4. Animation & Visualisation Industry Interoperabiliteit wordt internationaal erkend als ´e´en van de belangrijkste voorwaarden voor een goede workflow en dataflow binnen een bepaald project, waarbij in het bijzonder projecten bedoeld worden die expliciet gebruik maken van meerdere actoren en van heel uiteenlopende, chronologische stappen om tot een resultaat te komen. Ook binnen de animatieen visualisatieindustrie speelt interoperabiliteit daarom een steeds belangrijkere rol. Een evoluerend project dat rond dit onderwerp extra beschreven wordt, is de uitwerking van het FBX dataformaat als een centraal formaat voor de uitwisseling van algemene, driedimensionale data binnen Autodesk. Hoewel er vermoedelijk nog andere voorbeelden te noemen zijn met als doel de uitwerking van interoperabiliteitssystemen voor visualisatie- en animatiedoeleinden, verdient dit FBX formaat wellicht bijzondere aandacht op basis van het marktaandeel van Autodesk binnen deze animatie- & visualisatie-industrie. Om de workflow en dataflow vanuit de modelleeromgeving naar een uiteindelijke visualisatie zo effici¨ent mogelijk te laten verlopen, wordt binnen Autodesk sinds kort uitdrukkelijk gewerkt aan een AutoDesk bestandsformaat (FBX ). Met dit initiatief wordt getracht om het voor het eerst mogelijk te maken om driedimensionale data diagonaal de productsuite van Autodesk te laten doorkruisen, gaande van Autodesk Revit, over 3ds Max en MotionBuilder, eventueel zelfs tot in het externe Virtools Dev platform (§ 5.3.3). Op dit moment wordt het FBX dataformaat verder uitgewerkt tot het ‘Autodesk’ formaat, waardoor zijn functionaliteit in ´e´en adem ook uitgebreid lijkt te worden naar de AEC industrie en het CAD en BIM domein binnen Autodesk. Het waarmaken van dit laatste is recent gestart door het toegankelijk maken van de FBX functionaliteit in onder andere Revit Architecture 2009 en Autodesk 3ds Max 2009.

8.4.1. Revit Architecture 2009 en 3ds Max 2009 In de nieuwste versies van Autodesk Revit en Autodesk 3ds Max, namelijk versie Architecture 2009 en 3ds Max 2009, wordt de FBX technologie voor het eerst toepasbaar gemaakt voor ontwerpdoeleinden. In Autodesk Revit is namelijk een exportfunctie ingebouwd naar

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

216

het FBX formaat, terwijl een importfunctie in 3ds Max aanwezig gebleven is. Waar tot 2008 dus de gehele informatiestroom vanuit Revit naar 3ds Max noodgedwongen via een alternatief .dwg formaat moest gebeuren, kan nu dus een veel ruimer FBX databestand gebruikt worden. Wat de eigenlijke werking van het FBX dataformaat (§ 8.4.2) betreft, werd, omwille van de relevantie van FBX voor interoperabiliteit in de visualisatie- en animatieindustrie, via een testmodel onderzocht in hoeverre het FBX dataformaat op dit moment ge¨ımplementeerd is in Autodesk Revit Architecture 2009 en Autodesk 3ds Max 2009.

8.4.2. Evaluatie via testmodel Als testmodel werd het Building Information Model gebruikt van het Casino te Gent (figuur 8.7), dat binnen deze scriptie reeds opgebouwd was in § 7.5.2. Dit model werd vanuit Revit Architecture 2009 ge¨exporteerd naar het FBX dataformaat. Hierdoor wordt als output het eigenlijke FBX bestand gegenereerd, met een gelijknamige FBM map waarin de omgeving en de gebruikte materialen zitten, zoals weergegeven in figuur 8.8. In het FBX bestand staan de eigenlijke driedimensionale data opgeslagen van het model, samen met de animatiegerichte elementen, zoals in dit geval de eigenschappen van camera’s en de materiaalaanduiding per object. In de bijhorende FBM map zitten vervolgens de verschillende elementen die nodig zijn binnen een visualisatieomgeving als 3ds Max, zoals .jpeg afbeeldingen voor de achtergrondomgeving en de gebruikte materialen. Dit wordt in figuur 8.8 getoond voor enkele gebruikte materialen in het FBX model van het Casino. Als bijvoorbeeld in Revit bepaald werd dat een muur opgebouwd is uit een bepaald soort baksteen, bijvoorbeeld ‘Brick Non Uniform Running’, dan zal diezelfde muur in 3ds Max na het importeren van het eigenlijke FBX bestand, weten dat het uit dit materiaal bestaat, waarna 3ds Max de bijhorende afbeelding voor dit materiaal inlaadt uit de gegenereerde FBM map. Er werd in een volgende stap uitgetest welke resultaten geboekt kunnen worden met deze export- en importfunctionaliteit. Het FBX model werd daarom ge¨ımporteerd in Autodesk 3ds Max, waarvan het resultaat te zien is in figuur 8.9. Hierbij valt op te merken dat slechts ´e´en camera ge¨ımporteerd werd vanuit Revit. Voor de rest lijken alle objecten inderdaad mee te komen in een goed hanteerbare vorm, namelijk zoals deze gehanteerd wordt in Autodesk 3ds Max. Elk object is namelijk getransformeerd in een zogenaamde ‘Editable Mesh’ (figuur 8.10). Dit wil zeggen dat elk object apart selecteerbaar is, en dat dit, ongeacht de vorm, omgezet is in een hanteerbaar, getrianguleerd

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

217

Figuur 8.7.: Het informatiemodel van het Gentse Casino in Revit Architecture 2009.

8

Figuur 8.8.: FBX boomstructuur die bij exporteren gegenereerd wordt door Revit.

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

218

Figuur 8.9.: Het geopende FBX bestand in Autodesk 3ds Max 2009.

oppervlak. Om dit te illustreren werd een afbeelding genomen van het model met daarin ´e´en van de driehoeken in het koepeldak geselecteerd (figuur 8.10). Behalve deze geometrische en materiaalkundige input is er bijzonder weinig terug te vinden van de uitgebreide hoeveelheid informatie die aan het model werd toegevoegd in Revit (§ 7.5.2). Zo kan enkel nog de naam van elk object vermeld worden. De objecten behouden namelijk de naam van het equivalente objecttype in Revit, bijvoorbeeld ‘Basic Roof: Generic - 125mm’. Hoewel de gemodelleerde informatie van elk object, zoals bijvoorbeeld de verschillende objectparameters en -informatie, dus tot een absoluut minimum herleid zijn, komt de belangrijkste informatie voor visualisatie wel mee in een geschikt formaat. Als namelijk een allereerste rendering genomen wordt vanuit het meegenomen camerastandpunt, kan namelijk al een rendering ontwikkeld worden, zoals deze te zien is in figuur 8.11. Dit is relatief goed, gezien het feit dat hiervoor enkel de informatie uit Revit en FBX gebruikt werd en geen materialen binnen 3ds Max zelf gemodelleerd werden.

8.5. Besluit Uit dit beschouwend overzicht kan in eerste instantie geconcludeerd worden dat op dit moment een uitgebreide functionaliteit aangeboden wordt door uiteenlopende instanties. Hierin kan bijvoorbeeld het OWL Web Ontology Language initiatief onder vermeld worden van het W3C, de STEP standaard en de EXPRESS Data Definition Language van ISO, de Industry Foundation Classes van het IAI, en zelfs het eerder applicatiespecifieke FBX bestandsfor-

8

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

219

Figuur 8.10.: Bij importeren van het FBX bestand in Autodesk 3ds Max 2009 blijken de objecten omgezet te zijn naar ‘Editable Meshes’.

8

Figuur 8.11.: Eerste rendering van een onbewerkt FBX model in Autodesk 3ds Max 2009.

HOOFDSTUK 8. DIGITALE DATASTRUCTUUR

220

maat van Autodesk. Deze uitgebreide functionaliteit wordt doorgaans aangeboden door de datastructuren uit te werken met een zo groot mogelijke interoperabiliteit. Hiermee wordt bedoeld dat getracht werd om informatie uit de verschillende toepassingsdomeinen (SW, AEC, . . . ) te beschrijven op een manier die begrijpbaar zou zijn voor heel uiteenlopende soorten informatiesystemen en mensen. Deze interoperabiliteit werd in de verschillende toepassingsdomeinen bereikt na een gelijklopende evolutie, vertrekkende van applicatiespecifieke dataformaten over meer object-ge¨ ori¨enteerde dataformaten tot de huidige eerder ontologische dataformaten. Waar dus aanvankelijk gewerkt werd met dataformaten die enkel binnen een bepaalde applicatie gebruikt konden worden, werd reeds vroeg overgeschakeld op de ontwikkeling van object-ge¨ ori¨enteerde talen, zoals bijvoorbeeld XML. Met deze object-ge¨ ori¨enteerde talen werd getracht om een zo groot mogelijke flexibiliteit en extensibiliteit aan te bieden. Dit zorgde er echter voor dat informatie niet ´e´enduidig, maar op heel uiteenlopende manieren beschreven werd. Afhankelijk van de programmeur en van de applicatie waarbinnen het object-ge¨ ori¨enteerd dataformaat gebruikt zou worden, kan namelijk een zelfde object door middel van heel andere benamingen en een heel andere datastructuur beschreven worden (§ 8.2.1). Door deze uitgebreide flexibiliteit en extensibiliteit kon de informatie in systemen echter niet ´e´enduidig beschreven worden, wat de interoperabiliteit tussen deze systemen merkbaar verkleinde. Daarom is sinds enkele jaren steeds meer getracht om dataformaten te ontwikkelen die informatie op een ´e´enduidige manier beschrijven. Hiervoor is doorgaans teruggevallen op een werking aan de hand van ontologische beschrijvingen (§ 8.1), of beschrijvingen waarin gebruikt gemaakt wordt van ´e´enduidig gedefinieerde ‘concepten’ die verbonden zijn met eveneens ´e´enduidig gedefinieerde relaties. Deze ontologische beschrijvingen kunnen met andere woorden begrepen worden als een netwerk van semantisch gekende concepten, zoals terug te vinden is in de beschreven structuur van de EXPRESS Data Definition Language (§ 8.3.1) en de IFC Industry Foundation Classes (§ 8.3.2). Deze ontologische beschrijvingen zouden in principe herkend moeten kunnen worden door elke ICT applicatie die deze ontologische beschrijving ondersteunt. Toegepast op de benadering van Building Information Modelling (§ 7.5), zorgt dit ervoor dat in een centraal kader een bepaalde informatiestructuur kan opgebouwd worden, waarna dit in een ontologisch dataformaat (IFC ) kan doorgestuurd worden en automatisch verwerkt worden in applicaties die deze zelfde datastructuur (IFC ) eveneens ondersteunen.

8

9 Virtuele ontwerpomgevingen

I

N dit hoofdstuk wordt een beschrijvend overzicht gegeven van bestaande virtuele ontwerpomgevingen die specifiek gericht worden op toepassing binnen de voorontwerpfase. Binnen deze scriptie werd daarbij niet getracht om een volledig overzicht te maken, maar wel werd getracht om een opsomming uit te werken van applicaties die representatief geacht worden voor de ontwikkelingen in de functionaliteit van deze ontwerpomgevingen vanaf 1995 tot nu, zodat een goed beeld kan gevormd worden van hoe dit ontwikkeld is tot wat het nu is. Daarbij werd bovendien eerder geconcentreerd op systemen die binnen Belgi¨e en Nederland ontwikkeld werden, waarmee aangenomen wordt dat deze voldoende representatief zijn voor de globale ontwikkeling van deze virtuele ontwerpomgevingen.

9.1. Inleiding Met ‘virtuele ontwerpomgevingen’ worden binnen deze scriptie de applicaties bedoeld die ontwikkeld en gebruikt worden in de fase van het vroege architecturaal schetsontwerp. In dit hoofdstuk is in de eerste plaats getracht een beschrijving te geven van de doelstellingen en werkmethodes van deze virtuele ontwerpomgevingen (§ 9.2). Deze beschrijving wordt vergeleken met de resultaten uit de voorgaande delen van de literatuurstudie, met name de mate waarin de ontwikkelde applicaties lijken in te spelen op de verschillende ontwerpaspecten die overlopen werden in § 4, § 5, § 6 en § 7 en de mate waarin ze hiervoor gebruik trachten te maken van bestaande dataformaten (§ 8).

221

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

222

9.2. Overzicht 9.2.1. VIDE E´en van de eerste virtuele ontwerpomgevingen die genoemd kan worden, is VIDE of Virtual Interactive Design Environment1 . Dit is een omgeving die ontwikkeld werd in 1995-1996 aan het Departement Bouwkunde (BWK) van de Technische Universiteit Eindhoven (Oxman en Coomans, 1996). De doelstelling van VIDE bestond er volgens Oxman en Coomans (1996) in om de realiseerbaarheid te onderzoeken van een interface waarin de ontwerper met eenvoudige handelingen en acties virtuele objecten intu¨ıtief zou kunnen behandelen en be¨ınvloeden. Deze interface zou daarbij zowel het ontwerpen zelf als het visueel evalueren ervan mogelijk moeten maken (Oxman en Coomans, 1996). Dit werd in Oxman en Coomans (1996) voorzien door aan de gebruiker een min of meer fotorealistisch beeld van het ontwerp aan te bieden ter evaluatie, naast de eigenlijke tweedimensionale ontwerpomgeving in de vorm van een planmatige representatie (figuur 9.1).

9 Figuur 9.1.: De tweeledige interface van de VIDE Virtual Interactive Design Environment.

Als voornaamste resultaat van het project werd in Oxman en Coomans (1996) de conclusie gesteld dat Virtual Reality technologie technisch nog niet genoeg op punt stond om een voldoende effici¨ent ontwerpproces mogelijk te maken. Zo bleek ook de onderlinge relatie tussen de planmatige ontwerpomgeving en de driedimensionale evaluatieomgeving eerder problematisch te zijn. Wel werd de intu¨ıtieve interface aan de hand van eenvoudige objecten in Virtual Reality als veelbelovend en geschikt bestempeld (Oxman en Coomans, 1996). 1

VIDE Virtual Interactive Design Environment - http://www.ds.arch.tue.nl/Research/projects/vide/

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

223

9.2.2. DDDoolz DDDoolz of 3D Tools is een applicatie die tussen 1999 en 2002 uitgewerkt werd aan het Departement Bouwkunde (BWK) van de Technische Universiteit Eindhoven. De applicatie werd opgevat als een intu¨ıtieve applicatie waarin schetsen snel en eenvoudig driedimensionaal kunnen uitgetekend worden (de Vries, 2000). Hiermee wil DDDoolz een mogelijkheid bieden aan de architect om zijn ide¨een rechtstreeks uit te tekenen en te visualiseren op de computer, op een minstens even intu¨ıtieve manier als met potlood en papier (de Vries et al., 2000).

Figuur 9.2.: Voorbeelden van uitgetekende projecten in DDDoolz (Achten et al., 2000).

DDDoolz vertrekt hiervoor van ‘voxels’, de driedimensionale tegenhanger van de pixel. Enkel door middel van kubussen met ribbes van 100 cm zou een driedimensionale schets kunnen uitgetekend worden (de Vries et al., 2001; de Vries en Achten, 2002), zodat een blokkenmodel ontstaat als een driedimensionale, ‘schetsmatige’ representatie van het eigenlijke ontwerp (figuur 9.2). Door de heel eenvoudige en intu¨ıtieve interface en de gebruiksvriendelijkheid van DDDoolz kende de applicatie volgens de Vries et al. (2001); de Vries en Achten (2002) noemenswaardig succes in zijn onderzoeksopzet. Om dit ‘succes door eenvoud’ te behouden, is de DDDoolz applicatie na 2002 bewust niet verder uitgebreid met bijkomende functies en mogelijkheden (de Vries en Achten, 2002).

9.2.3. DDDiver Gelijklopend met het DDDoolz project werd het onderzoeksproject DDDiver (3D Interactive Visualisation of Entity Relationships) uitgevoerd (Coomans, 1999). Dit project werd

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

224

uitgevoerd in het kader van het onderzoek rond Feature-Based Modelling (FBM) aan het Departement Bouwkunde (BWK) van de Technische Universiteit Eindhoven (§ 7.4) en was volgens Coomans (1999) bedoeld om een interactieve visualisatie mogelijk te maken van de verschillende features en feature types uit een Feature-Based Model in een expliciet virtuele ontwerpomgeving (Figuur 9.3).

Figuur 9.3.: Met de Virtual Reality hardware systemen die toen beschikbaar waren, zoals een traceermechanisme en een 3D muis (rechts) wordt door DDDiver getracht om Virtual Reality schemas van een Featur-Based Model te visualiseren (links), zodat het bewerkt zou kunnen worden door de gebruiker (Coomans, 1999).

9.2.4. BAS-CAAD Het onderzoeksproject BAS-CAAD of Building and user Activity Systems Modelling for Computer Aided Architectural Design werd uitgevoerd aan de School of Architecture van The Lund University in Zweden. De algemene doelstelling voor dit project werd in (Fridqvist et al., 1995) omschreven als de verbetering of aanpassing van gekende CAAD technieken om typische acties en handelingen uit de voorontwerpfase uit te kunnen voeren. Volgens (Fridqvist et al., 1995) zou de BAS-CAAD applicatie hiervoor expliciet moeten vertrekken vanuit de definitie van ‘ruimtes’ en de relaties tussen deze ruimtes, in tegenstelling tot voorgaande VDE en CAAD applicaties waarin vertrokken wordt van de materi¨ele elementen waaruit het gebouw opgebouwd is (Ekholm en Fridqvist, 1997a). Om dit te kunnen realiseren, worden technieken uit de informatiemodellering, meer bepaald Product Modelling (§ 7.3), toegepast binnen een CAD omgeving (Ekholm en Fridqvist, 1999; Fridqvist, 2000). De relevantie van dit project voor deze scriptie lijkt vooral te liggen in de uitwerking van een geschikt informatiemodel dat specifiek gericht wordt op de vroege ontwerpfase. In Ekholm en Fridqvist (1999) wordt zo onderscheid gemaakt tussen ‘statische informatiemodellering’, dat eerder geschikt is voor industri¨ele probleemoplossingen, en ‘dynamische informatiemodellering’, dat geschikt is voor het ontwerpen van innovatieve (architecturale) probleemoplossingen. Dit ‘dynamisch modelleren’ wordt verder uitgewerkt in Ekholm en Fridqvist

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

225

(1999) en Fridqvist (2000) binnen het BAS-CAAD project. Hierna zou de expertise omtrent dynamische informatiemodellering in het architecturaal voorontwerp verdere toepassing vinden in het project rond Feature-Based Modelling aan de Technische Universiteit Eindhoven (§ 7.4) (van Leeuwen en Fridqvist, 2002d).

9.2.5. The Electronic Cocktail Napkin In Do en Gross (1995) wordt de doelstelling van The Electronic Cocktail Napkin voorgesteld. Er wordt gesteld dat de ontwerper zijn ontwerp start en uitwerkt vanuit visuele referenties, wat verder uitgewerkt wordt tot een zogenaamd ‘Drawing Analogies System’. Volgens Do en Gross (1995) zouden onder andere afbeeldingen, eerdere schetsen en notities binnengehaald moeten kunnen worden in een virtuele tekenomgeving, om deze opnieuw te kunnen interpreteren en van hieruit het ontwerp een bepaalde richting te geven. Tijdens het ontwerp zelf worden vervolgens telkens opnieuw ontwerpide¨een gegenereerd op basis van deze ingeladen bronnen en de reeds door de ontwerper uitgetekende schetsen en schema’s. Deze verzameling aan ingeladen materiaal wordt in Do en Gross (1995) benoemd tot een geheel van ‘visuele referenties’ binnen een ‘Drawing Analogies’ programma. Vanuit deze aanname werd in Do en Gross (1996a) de The Electronic Cocktail Napkin ontwerpomgeving geconstrueerd, die het mogelijk moest maken om visuele referenties rechtstreeks in te laden in zijn eigen ontwerpomgeving. Deze referenties konden in deze omgeving volledig vrij ge¨ınterpreteerd en verder uitgewerkt worden tot nieuwe visuele referenties (schetsontwerpen) en uiteindelijk tot een gepast voorontwerp. Op deze manier zou de effectiviteit van de voorontwerpfase sterk verhoogd kunnen worden, terwijl de nodige flexibiliteit en interpreteerbaarheid bewaard blijft en zelfs gestimuleerd wordt (Do en Gross, 1996a).

9

Figuur 9.4.: De elektronische tekentafel van the electronic cocktail napkin. Aan de hand van de hierin uitgetekende schetsen en diagrammen, worden gelijkaardige tekeningen opgezocht in de CBR metadatabase ARCHIE (§ 4.2.1) (Do en Gross, 1996b).

In de eigenlijke implementeringsfase werd een zogenaamde ‘pen-based drawing board’ ontwikkeld (Do en Gross, 1996a), waarvan de interface te zien is in figuur 9.4. Binnen deze

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

226

schetsomgeving wordt bovendien een rechtstreekse verbinding gemaakt met grafische collecties zoals ARCHIE, de ‘Great Buildings’ collectie en de ‘Flora’ database (Do en Gross, 1995, 1996b). De mogelijkheden van een zoekopdracht naar ‘visuele referenties’ in deze databases worden in figuur 9.5 voorgesteld.

Figuur 9.5.: Er wordt gezocht naar analoge ‘visuele referenties’ in de databases van ARCHIE, de ‘Great Buildings’ collectie en de ‘Flora’ database. Bovenaan wordt de in de zoekopdracht ingevoerde schets getoond en onderaan het resultaat van de zoekactie in de databases.

In Do en Gross (1997); Do et al. (2000) werd onderzocht hoe architecturale schetsen en schema’s, zoals ze met de hand uitgetekend werden op een digitaal drawing board (figuur 9.4), konden omgezet worden in een digitaal formaat dat kan gebruikt worden als basis voor het zoeken naar visuele referenties. Wat volgens Do en Gross (1997); Do et al. (2000) echter vooral van belang is in deze omzetting, is de vraag wat er in feite impliciet uitgedrukt wordt in de tekening, welke bedoelingen en ontwerpbeslissingen impliciet vervat zitten achter de lijntekening. Hiervoor wordt in Do en Gross (1997); Do et al. (2000) een onderscheid gemaakt tussen een architecturaal diagramma, een schematische schets en een driedimensionale architectuurschets, waarbij gesteld wordt dat de bedoelingen van de ontwerpers het meest expliciet vervat zit in de diagramma’s. In Do en Gross (1996a) en Do en Gross (1996b) wordt hierop verdergegaan en wordt onderzocht wat de eigenschappen zijn van de diagramma’s, hoe deze kunnen herkend worden volgens hun samenstellende elementen en hoe deze verder kunnen geanalyseerd worden op analogie¨en in externe databases. De resultaten van dit onderzoek worden toegepast in de uitwerking van The Electronic Cocktail Napkin (Do et al., 2000).

9.2.6. MUSEV MuseV (Measuring User Satisfaction through Virtual Environments) werd ontwikkeld in drie opeenvolgende versies aan het Departement Bouwkunde (BWK) van de Technische Universiteit Eindhoven. Het werd specifiek ontworpen voor onervaren gebruikers, dus voor de bouwheer in plaats van voor de architect (Orzechowski et al., 2003), met als doel het

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

227

meten van de tevredenheid van de gebruikers over een voorgesteld ontwerp. Daarom wordt in dit project specifiek aandacht besteed aan de gebruikersinterface en aan de interactie tussen gebruiker en computer. Dit wordt concreet gerealiseerd door een ontwerp aan de bouwheer voor te stellen, waarop deze zelfstandig veranderingen mag aanbrengen aan het voorstel via MuseV (Orzechowski en de Vries, 2000; Orzechowski et al., 2001, 2003; Orzechowski, 2004). Achter het systeem zelf zit vervolgens een statistische module die aan de hand van de handelingen van de gebruiker meet in hoeverre de bouwheer tevreden is met bepaalde delen van het ontwerpvoorstel. Hiervoor wordt gebruikt gemaakt van een Bayesian Network of Belief Network (Orzechowski en de Vries, 2000; Orzechowski et al., 2001, 2003; Orzechowski, 2004).

Figuur 9.6.: De interface van MuseV3 maakt gebruik van een combinatie van een planzicht en een perspectivisch driedimensionaal zicht, met bovenaan de gebruikte toolbox.

9 9.2.7. E3dAD Het E3dAD (Easy 3D Architectural Design) project is gestart vanuit een uitgebreide analyse in Segers et al. (2000) van de bestaande architecturale ICT applicaties voor het schetsontwerp en hun verschillende benaderingen van het ontwerpprobleem. Aan de hand van dat onderzoek werd vervolgens getracht om een nieuwe ontwerpomgeving aan te maken die de tekortkomingen van CAD systemen in het schetsontwerp opvangt. In Segers et al. (2001) wordt nader onderzocht hoe het ontwerpproces in de vroege ontwerpfase algemeen in zijn werk gaat. Uit de resultaten van dit onderzoek (Segers et al., 2001) wordt een Idea Space System (ISS) voorgesteld die bestaat uit nodes (ide¨een) en links

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

228

(relaties tussen ide¨een). Dit wordt vergeleken in Segers et al. (2001) met de traditionele ontwerpomgeving op basis van potlood en papier, waarin deze twee elementen eveneens gebruikt worden, maar dan in de vorm van schema’s en notities enerzijds, en relationele symbolen anderzijds. Aan de hand van deze explicitering van de concepten in grafisch voorgestelde nodes en links, zou de architect in staat moeten zijn om rechtstreeks op een conceptueel niveau te denken en het ontwerp vervolgens hiernaar bij te sturen. Door de Vries et al. (2004) wordt gesteld dat voor de explicitering van concepten zowel in de potlood en papier omgeving als in de digitale omgeving het meest effici¨ent gebruik gemaakt wordt van woorden of begrippen. Segers (2004) gaat hier verder op in door de expliciete toepassing van woorden en associaties in een E3dAD virtuele ontwerpomgeving (figuur 9.7). Om dit voor te stellen, worden schema’s gebruikt op basis van woorden, uitgewerkt in een UML2 taal (de Vries et al., 2004).

Figuur 9.7.: De uitgewerkte analogie tussen conceptuele schema’s, opgetekend via pen en papier, en een conceptueel computerschema met woorden en associaties, samengesteld op een virtueel papier.

Na de conceptueel-theoretische uitwerking door Segers (2004), wordt in Aliakseyeu (2003) onderzocht hoe de eigenlijke ontwerpomgeving er concreet uit moet zien om te beantwoorden aan de noden van de architect. Daartoe wordt het Idea Space System (ISS) concreet vormgegeven via de combinatie van een ‘re¨eel papier’ en een ‘virtueel papier’ (figuur 9.8). Op het virtueel papier wordt de eigenlijke informatie voorgesteld die E3dAD kan bieden als hulp bij het architectuurontwerp. Deze informatie is bijvoorbeeld een visualisatie van de op papier uitgetekende concepten, maar dit kan ook een ingeladen afbeelding of tekst zijn van een voorgaand project. 2

UML Unified Modelling Language - http://www.omg.org/cgi-bin/doc?ad/97-08-11

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

229

Hierrond werd in Heylighen en Segers (2002) een test-case uitgevoerd die de DYNAMO metadatabase (§ 4.4.5) tracht te koppelen aan het Idea Space System van E3dAD. Door het intoetsen van ‘Shift+F7’ (Heylighen en Segers, 2002) zou een opzoekactie geactiveerd worden binnen de ISS ontwerpomgeving die zoekt naar relevante cases in de DYNAMO database voor de op dat moment ingevoerde of opgetekende schema’s. Hoewel de eerste resultaten veelbelovend leken (Heylighen en Segers, 2002), is er geen officieel vervolg gekomen op deze test-case.

Figuur 9.8.: Het Idea Space System (ISS), met op de tafel het echt papier dat ‘gelezen’ wordt door camera’s boven de tafel en op het scherm het virtuele papier waar relevante informatie, zoals onder andere de ge¨expliciteerde conceptschema’s en de gevonden, analoge projecten uit DYNAMO, op gevisualiseerd zouden kunnen worden.

9 9.2.8. Structural Sketcher De virtuele ontwerpomgeving van Structural Sketcher werd ontwikkeld in de periode 2004 tot 2005 aan het Departement Mathematics and Computer Science (MCS) van de Technische Universiteit Eindhoven. Als vertrekpunt wordt gesteld dat reeds tientallen ontwerpomgevingen voor de ontwerper ontwikkeld zijn in de laatste jaren, maar dat nog steeds de potlood en papier methode overheerst in de architecturale voorontwerpfase (Pranovich et al., 2005). Om een oplossing te bieden voor dit tekort aan digitale hulpmiddelen in het architecturaal schetsontwerp, wordt een nieuwe applicatie voorgesteld die expliciet vertrekt van de eigenschappen van een architecturale ontwerpomgeving (Pranovich, 2004). Hierbij wordt teruggekeerd naar het concept van generic representations van Achten (1997) (§ 7.4.2). De

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

230

‘grafische entiteiten’ waaruit deze generic representations volgens Achten (1997) opgebouwd zijn, worden getoond in figuur 9.9.

Figuur 9.9.: Overzicht van de verschillende grafische entiteiten die volgens Achten (1997) kunnen voorkomen in grafische voorstellingen (§ 7.4.2).

‘Pen-plus’ versus ‘paper-plus’ De invoer van ontwerpmatige informatie, onder de vorm van de generic representations en grafische eenheden (Achten, 1997), in de architecturale schetsomgeving kan volgens op verschillende manieren gebeuren, waarbij in Achten (2004) onderscheid wordt gemaakt tussen een ‘pen-plus’ en een ‘paper-plus’ benadering. De grafische eenheden worden hierbij respectievelijk door de ‘pen’ geproduceerd, of door het ‘papier’ herkend (Achten, 2004). Als voorbeeld van een virtuele ontwerpomgeving met een ‘pen-plus’ benadering wordt in Achten (2004) de Structural Sketcher van Pranovich (2004) genoemd. Deze gebruikt de

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

231

grafische eenheden van Achten (1997) expliciet als basiselementen om een ontwerp uit te tekenen. De ontwerper zou hierdoor dus in staat moeten zijn om rechtstreeks de grafische eenheden als as, grid, contour en andere eenheden toe te passen in een vormelijke structuur en combinatie die hij zelf bepaalt (Pranovich et al., 2005). Ook latere transformaties aan deze samenstelling van grafische entiteiten kunnen in Structural Sketcher uitgevoerd worden door middel van de KITE geometry manipulator (figuur 9.9).

Figuur 9.10.: Er wordt gewerkt met een nieuwe gebruikersinterface op basis van de KITE of Kool Integrated Transformation Editor (Pranovich et al., 2002), die de tekenmethode zo intu¨ıtief mogelijk tracht te maken.

De ‘pen-plus’ benadering van Structural Sketcher lijkt bij een evaluatie door Pranovich et al. (2005) volgende voor- en nadelen te vertonen. • voordelen – goed gestructureerde tekeningopbouw tijdens de hele ontwerpfase – consistentie door eenduidigheid van de tekenapplicaties – directe toegankelijkheid van de tekening voor computergestuurde analyse • nadelen – nodig aanleerproces voor de architect ongewenst – de functionaliteit van het systeem hangt af van de correctheid en uitgebreidheid van de herkenbare grafische eenheiden, waardoor de creatieve ontwerpmogelijkheden van de architect sterk beperkt kunnen worden Wat de ‘paper-plus’ benadering betreft, lijken de verwachtingen in Achten (2004) een stuk hoger te liggen. In deze benadering wordt verondersteld dat het ‘papier’ in staat is om automatisch te herkennen wat de architect aan het tekenen is en dat bij het tekenen zelf

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

232

dus niet telkens expliciet moet gespecifieerd worden wat getekend wordt (Achten, 2004). Deze benadering steunt op de techniek van automatische schetsherkenning door Multi-Agent Systemen, wat hierna kort behandeld wordt ter illustratie van de techniek. Een architecturale ontwerpomgeving die deze ‘paper-plus’ benadering toepast, is EsQUIsE (§ 9.2.9). Multi-Agent Systems voor ‘automatische schetsherkinning’ Via automatische schetsherkenning wordt als doel gesteld dat het ‘papier’ ahw. in staat is om automatisch te herkennen wat de architect aan het tekenen is. Dit is voor het eerst als een benodigdheid naar voren gekomen tijdens onderzoek aan de Technische Universiteit Eindhoven, in het kader van het werk van Achten en van Leeuwen (§ 7 op pagina 161 en § 5 op pagina 87). De techniek wordt in eerste instantie binnen dit onderzoek voorgesteld, waarna een kort overzicht gegeven wordt van andere toepassingen waarin automatische schetsherkenning wordt toegepast. In het TU/e onderzoeksproject wordt de schetsherkenning ontwikkeld met als concreet doel het herkennen van ‘grafische eenheden’ (§ 7.4.2 op pagina 170) in de uitgetekende schets, waardoor de functionaliteit van het systeem opnieuw sterk afhangt van de correctheid en uitgebreidheid van die ‘grafische eenheiden’. Hiervoor worden twee technieken gebruikt, namelijk Multi-Agent Systems en Case-Based Reasoning. De meer gebruikelijke toepassing waarvoor multi-agent systems worden gebruikt, is de analyse van ruimtes door tientallen tot honderden virtuele gebruikers als ‘agents’ door die ruimtes te laten lopen. Elke agent wordt namelijk altijd in een ruimte geplaatst en voorgeprogrammeerd om zelf beslissingen te nemen naargelang de situatie en de ruimte waarin hij zich bevindt. Hierdoor kan een gebouw ge¨evalueerd worden op zijn ontsnappingsmogelijkheden bij brand, of kan een stad actief ‘gesimuleerd’ worden om bijvoorbeeld grootschalige evenementen te kunnen organiseren. Een Multi-Agent Systems is dus een typische Artificial Intelligence techniek, die reeds uitgebreid toegepast werd in de gaming- en filmindustrie. Zo zijn ook de gevechtssc`enes van de film “Lord of the Rings” automatisch gesimuleerd op basis van meer dan 50000 agents die ofwel aanvallen, zich overgeven of vluchten, naargelang hun situatie. Concreet wil dit zeggen dat elke agent zijn omgeving analyseert op specifiek voorgeprogrammeerde gebeurtenissen of op inkomende berichten, bijvoorbeeld ‘het uittekenen van een vierkant’. Op basis van deze input wordt al dan niet een voorgeprogrammeerde interne bewerking uitgevoerd, bijvoorbeeld de herkenning van een deel van de grafische eenheid ‘contour’. Tot slot wordt een output gegenereerd onder de vorm van een uitgezonden bericht of een manipulatie in zijn omgeving, bijvoorbeeld de invoer van informatie in een informatiemodel (figuur 9.11). Multi-Agent Systems kunnen in feite in elke computergebaseerde omgeving gebruikt worden,

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

233

Figuur 9.11.: De werking van een agent in een multi-agent system, met duidelijke onderverdeling in input, intern proces en output.

zoals in Achten en Jessurun (2002) wordt aangetoond. Zo kunnen de virtuele agents ook voorgeprogrammeerd worden om handelingen uit te voeren op het moment dat bepaalde elementen in een ontwerpschets herkend worden. Deze hypothese werd in eerste instantie getest in een Mah Jong spelomgeving (Achten en Jessurun, 2003). Na dit experiment werd het een stuk duidelijker wat de mogelijkheden waren van MAS met het oog op automatische schetsherkenning. Uit het Mah Jong experiment werden reeds volgende problemen onderkend (Achten en Jessurun, 2002). 1. aanmaak van algoritmes voor de beschrijving van grafische eenheden 2. leermechanismen voor het aanleren van tekenstijlen van verschillende gebruikers 3. plaats maken voor de gebruiker in het systeem

Op basis van de herkende grafische eenheden door de agents, kan informatie worden doorgegeven worden aan andere systemen. Zo kan Case-Based Reasoning (§ 4.2.1 op pagina 39) aangesproken worden voor het aanduiden van de meest relevante generische presentatie die gevormd kan worden met de doorgegeven grafische eenheden. Dit gebeurt aan de hand van de beslissingsboom die gedefinieerd werd in Achten (1997) (figuur 9.12). Door de agents de beslissingsboom te laten doorlopen, worden de verschillende gebruikte grafische eenheden in de schets ge¨ıdentificeerd. Op basis van deze lijst wordt door middel van CBR gezocht naar de meest relevante generische representaties voor het ontwerp (Achten, 2004). Als dit proces op punt staat, kan deze informatie opgeslagen worden in een

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

234

Figuur 9.12.: De beslissingsboom die gebruikt wordt om te bepalen welk element in de ontwerpschets uitgetekend werd. Deze boom verdeelt de grafische eenheden in volgende groepen: text (A7); samenstellende vormen op gebouwniveau (ABCEI); samenstellende vormen op elementniveau (ABCEJ); enkele vormen op gebouwniveau (ABCF); elementen voor gebiedsstructurering (ABDG & ABDGK); elementen voor gebouwstructurering (overige onder ABDH).

architecturaal informatiemodel om dit vervolgens te verwerken, bijvoorbeeld in het zoeken naar relevante projecten in het Architectural Memory. In het hierboven voorgestelde Multi-Agent System wordt het gedrag van elke agent bepaald door zijn voorgeprogrammeerde eigenschappen P, G, F, C, S. Deze eigenschappen verschillen van agent tot agent, naargelang zijn specifieke functie (Achten, 2005, 2006). Deze eigenschappen stellen het volgende voor: • purpose P: herkennen van ´e´en bepaalde grafische eenheid. • goal G: bepalen of een bepaalde grafische eenheid aanwezig is in de tekening. • features F: diverse primitieve elementen (lijn, cirkel, . . . ) waaruit de grafische eenheden opgebouwd zijn, worden gebruikt om grafische eenheden te kunnen opsporen. • criteria C: voorwaarden op basis waarvan bepaald kan worden in welke mate een bepaalde grafische eenheid aanwezig is. Er moeten bijvoorbeeld x verschillende lijnen getekend worden vooraleer sprake kan zijn van een grid-eenheid.

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

235

• segmentation measures S: bepaalt of het traceren van een grafische eenheid al dan niet verder moet gezet worden.

Een tweede manier waarop MAS te werk zou kunnen gaan in het herkennen van grafische eenheden, is via on-line herkenning. Hierbij wordt de schets reeds geanalyseerd tijdens het schetsen zelf, zodat de tekenorde en de tekenwijze van bepaalde elementen in de grafische eenheden mee in rekening kan genomen worden. Dit werkt op een licht verschillende manier (Achten, 2005, 2006), maar heeft op het eerste gezicht meer voordelen doordat een uitgebreidere datastroom doorgegeven wordt aan de agents.

9.2.9. EsQUIsE EsQUIsE is een ontwerpapplicatie die aan het Laboratoire d’Etudes M´ethodologiques Architecturales (LEMA) van de Universiteit van Luik ontwikkeld werd tussen 1996 en vandaag. De problematiek die ook overheerst in bovenstaande onderzoeksprojecten werd reeds uitgebreid onderzocht in het doctoraatsproefschrift van P. Leclercq (Leclercq, 1994) en wordt in Leclercq (2001) uitvoerig voorgesteld na de realisatie van het eerste prototype van EsQUIsE. De verschillende voorwaarden voor de goede werking van een architecturale schets-hulpapplicatie worden hierin als volgt gestructureerd (Leclercq, 2001). 1. intrinsieke eigenschappen van een hulpapplicatie bij het ontwerp • het ontwerp wordt op een eerder abstract niveau uitgewerkt, met weinig ‘tastbare’ concepten • verschillende niveau’s van abstractie 2. actieve interactie tussen hulpapplicatie en ontwerper • de schets is een middel, geen resultaat 3. hulpapplicatie met een hoog-semantisch niveau • een gelijkaardige grafische expressie voor verschillende ontwerpers en applicaties • expliciteren van impliciet gekende architecturale informatie

Het voorgestelde architecturaal informatiemodel achter EsQUIsE wordt naar aanleiding van deze voorwaarden in Leclercq (2001) als volgt uitgewerkt. Er worden teneerste drie niveau’s van abstractie aangemaakt, waaronder een niveau voor ‘Boundaries (B)’, een niveau voor ‘Functional Spaces (FS)’ en een niveau voor ‘Detailed Boundaries (DB)’ (figuur 9.13). Op het Functional Spaces niveau wordt getracht om de essentie van het plan schematisch weer te geven in een schematisch diagram met relationele en topologische aanduidingen

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

236

van de verschillende abstracte ruimtes. Op het ‘Boundaries’ niveau worden de verschillende ruimtes zelf gedefinieerd. Dit gebeurt niet via een aanduiding van materialiteit, maar via een aanduiding van ‘boundaries’ of begrenzingen. De ruimtes binnen deze begrenzingen krijgen betekenis door het schema op het Functional Spaces niveau. Op het ‘Detailed Boundaries’ niveau ten slotte kunnen de verschillende begrenzingselementen gedetailleerder uitgewerkt worden met bijvoorbeeld ramen, deuren en muurdiktes.

Figuur 9.13.: Drie niveaus van abstractie structureren de informatie die in een schets vervat zit. Een niveau FS bevat Functional Spaces, niveau DB bevat Detailed Boundaries en niveau B bevat Boundaries.

Het tweede element in het architecturaal model (Leclercq, 2001), is de mogelijkheid om ‘impliciete informatie’ in te laden bij de herkenning van specifieke elementen. Ook deze informatie wordt in Leclercq (2001) onderverdeeld in drie lagen, met respectievelijk een laag voor eigen referenties of eigen uitgevoerde ontwerpen, een laag voor “standaard regels voor goede praktijk” (wettelijk, klimatologisch, . . . ) en een laag voor “universele referenties” (e.g. materiaaleigenschappen) (Leclercq, 2001) (figuur 9.14).

Figuur 9.14.: De impliciete informatie die in het architecturaal model gebruikt wordt.

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

237

De impliciete en expliciete informatie die in het model opgeslagen zit, kan onder de vorm van parameters en constraints ingevoerd worden in de aan EsQUIsE gekoppelde AMCE applicatie (§ 6.4.2). Hierin kan een benaderende simulatie uitgevoerd worden voor in de eerste plaats een energetische evaluatie van het model (Hauguslaine, 2000) (figuur 9.15)).

Figuur 9.15.: De werking van EsQUIsE met links de uitgetekende schets die digitaal verwerkt wordt en rechts de bijhorende energetische analyse die uitgevoerd wordt door AMCE (§ 6.4.2).

Na afloop van het AMCE project in 2001 is verder onderzocht hoe het automatisch importeren van parametrische informatie uit een grafische EsQUIsE architectuurschets beter fijngesteld kan worden (Juchmes et al., 2004). Met dat doel werd het onderzoeksproject EsQUIsE-SMA opgestart in 2001, waarbij SMA staat voor Syst`eme Multi-Agents of MultiAgent System (Juchmes et al., 2004). Hierin worden de samenstellende delen van schetsen volledig computergestuurd herkend door verschillende virtuele ‘agents’, waarna deze agents de informatie uit die delen verder verwerken (§ 9.2.8). Dit Multi-Agent System werd ge¨ıntegreerd uitgewerkt in een EsQUIsE ontwerpomgeving met een zogenaamde ‘absent interface’ (Juchmes et al., 2004). Met dit MAS systeem wordt getracht om zoveel mogelijk van de bijkomende moeite die aan een ontwerper wordt gevraagd in traditionele virtuele ontwerpomgevingen, zoals het aanklikken van buttons en het selecteren van punten met behulp van een muis, uit te sluiten en te vervangen door een digitale schetspad en een digitale pen (Juchmes et al., 2004). De omgeving van de architect wordt hierdoor nagenoeg niet veranderd, met dat verschil dat de architect in EsQUIsE automatisch voorzien wordt van onder andere een real-time simulatie in AMCE waarop hij zijn ontwerpbeslissingen kan baseren (Hauguslaine, 2000; Juchmes et al., 2004).

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

238

9.2.10. IDEA+ De IDEA+ ontwerpomgeving (‘Integrated Design Environment for Architects’ ) werd uitgewerkt via het gelijknamige IDEA+ project aan het departement Architectuur, stedenbouw en ruimtelijke ordening (ASRO) van de Katholieke Universiteit Leuven. Het eigenlijke project is pas van start gegaan in 2000, maar de conceptie is terug te voeren naar het werk van Neuckermans (1992) en Hendricx (2000). In Neuckermans (1992) werd het oorspronkelijke theoretisch kader gelegd voor de IDEA+ ontwerpomgeving (figuur 9.16). Dit conceptueel model vertrekt van de aanname dat een ontwerpproces kan onderverdeeld worden in enerzijds drie ‘Design Phases’ of ontwerpfases en in anderzijds drie ‘Scale Levels’ of schaalniveaus (Neuckermans, 1992; Boeykens en Neuckermans, 2003). De verschillende ontwerpfases werden gedefinieerd in Neuckermans (1992) tot een ‘sketch design phase’ (SD), een ‘preliminary design phase’ (PD) en een ‘construction design phase’ (WD). Bijkomend werd voor elk van deze ontwerpfases een onderverdeling gemaakt volgens de schaalniveaus ‘masterplan niveau’ (niveau 1), ‘blok niveau’ (niveau 2) en ‘space niveau’ (niveau 3) (figuur 9.16).

9 Figuur 9.16.: Het conceptueel model dat aan de basis lag van IDEA+ (Neuckermans, 1992; Boeykens en Neuckermans, 2003).

In een daaropvolgend onderzoek (Hendricx, 2000) werd een benadering uitgewerkt waarmee dit conceptueel model van Neuckermans (1992) zou kunnen uitgewerkt worden tot een realiseerbare ontwerpomgeving. Deze theoretische benadering werd voorgesteld in het Core Object Model van Hendricx (2000). Dit Core Object Model zou beschouwd kunnen worden als een eigen gedefinieerd gebouwmodel waarin de verschillende elementen van het ontwerp

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

239

als aparte objecten beschreven en onderling aan elkaar relateerd kunnen worden via een uitdrukkelijk object-ge¨ ori¨enteerde benadering (Hendricx, 2000; Boeykens en Neuckermans, 2003).

Figuur 9.17.: De theoretische benadering voor de uitwerking van IDEA+ aan de hand van een Core Object Model (COM) (Hendricx, 2000).

Van bij de start van het project werd bovendien, aan de hand van dit theoretisch kader, getracht om een ontwerpomgeving aan te maken die de verschillende benodigdheden in het ontwerpproces tracht te integreren binnen deze ontwerpomgeving Hendricx en Neuckermans (2001). Uit Hendricx en Neuckermans (2001) blijkt dat dit gebaseerd is op de wijze waarop een ontwerpproces doorlopen wordt in drie uitgevoerde testcases. In Hendricx en Neuckermans (2001) wordt dit proces onderverdeeld in zeven chronologisch stappen, gaande van de stappen ‘modelling the building site’ en ‘modelling the overall layout of new building blocks’ tot de stappen ‘modelling the user spaces, the user activities [. . . ] on a more detailed level’ en ‘modelling the additional openings and the appropriate links in the building envelope’. Uitgaande van deze gesimuleerde werkwijze (Hendricx en Neuckermans, 2001) wordt getracht om deze opeenvolgende stappen, waarbij het ontwerpmodel steeds gedetailleerder uitgewerkt wordt, uit te werken en mogelijk te maken in een conceptuele IDEA+ ontwerpomgeving. Bij deze uitwerking werd volgens Heylighen en Neuckermans (2001c) uitdrukkelijk afgezien van de internationale initiatieven STEP en IFC, om integendeel een eigen Core Object Model te gebruiken als basis voor de beschrijving van het gebouwmodel. Deze keuze werd gemaakt vanuit de vaststelling dat “STEP mislukt zou zijn en IFC nog ver verwijderd zou zijn van een volledige standaard” (Heylighen en Neuckermans, 2001c). Bij de uitwerking werd gebruik gemaakt van MERODE (‘Model-driven existence-dependency relationship object-oriented development’) (Heylighen en Neuckermans, 2001c) om de beschrijving van het gebouwmodel onder te verdelen in drie lagen of categorie¨en.

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

240

1. generic principle layer Deze laag bevat algemene informatie over een bepaald project, zonder daarbij de verschillende objecten in dit project te beschrijven 2. architectural aspects layer Deze laag bevat de algemene categoriserende beschrijving van de verschillende gebruikte objecten in het model (bv. ‘physical object’, ‘space’, ‘user activity’, . . . ) 3. specialisation or library layer Deze laag bevat de specifieke objecten die onder de verschillende categorie¨en kunnen vallen die beschreven zijn in de architectural aspects layer

Door de combinatie van de beschrijving aan de hand van MERODE en de aangenomen wijze waarop een ontwerpproces evolueert (Heylighen en Neuckermans, 2001c), werd het mogelijk geacht om elementen steeds gedetailleerder te beschrijven, door het doorlopen van verschillende stappen. Bij elke stap zou de ontwerper beslissingen kunnen nemen, waardoor het ontwerp steeds beter afgestemd kon worden op de gevraagde ontwerpeisen (Heylighen en Neuckermans, 2001c). Zo zou in een eerste fase enkel een vlak kunnen gedefinieerd worden, om dit vervolgens in verschillende stappen steeds fijner uit te werken tot het uiteindelijk in de laatste stap een specifiek soort spouwmuur is (figuur 9.18).

9

Figuur 9.18.: De lineaire verfijning van een ‘vlak’ tot een volwaardige ‘spouwmuur’ in IDEA+ volgens de conceptuele uitwerking in Heylighen en Neuckermans (2001c).

Er werd bovendien gesteld dat voor elke verfijnende stap in het ontwerpproces, ICT hulpmiddelen zouden kunnen voorzien worden die het de ontwerper mogelijk maken om zijn

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

241

keuzes te baseren op een concrete analyse of simulatie (Geebelen, 2000; Hendricx en Neuckermans, 2001). Dit werd echter enkel concreter uitgewerkt aan de hand van een IDEA-l hulpmiddel, dat het zou mogelijk maken om een ontwerp in een bepaalde fase te evalueren op natuurlijke lichtinval (Geebelen, 2000). Dit lijkt echter niet verder uitgewerkt te zijn, en andere voorbeeld van dergelijke hulpmiddelen voor het aspect evaluation of design solutions kunnen niet genoemd worden. De conceptuele benadering van IDEA+ werd in een eerste fase ge¨evalueerd in van Leeuwen et al. (2001). Hierin wordt gesteld dat de werkwijze via een centraal objectmodel het toelaat om een gestructureerd en correct gedocumenteerd gebouwmodel op te bouwen. Bovendien biedt dit volgens van Leeuwen et al. (2001) bijkomende flexibiliteit naar de eindgebruiker, die op een flexible wijze de verschillende beschikbare objecten onderling kan combineren en verder uitwerken zonder hierbij verplicht te zijn om bepaalde details reeds uit te werken. Ook de eigenlijke ontwikkelaar beschikt volgens van Leeuwen et al. (2001) over een flexibel kader om objecten toe te voegen en aan te passen, zolang de onderliggende principes van de Core Object Model structuur gehandhaafd blijven. In het volgende onderzoek, tussen 2001 en 2008, werd getracht om de theoretische benadering verder uit te werken (Boeykens et al., 2002; Boeykens en Neuckermans, 2003, 2005; Boeykens et al., 2005) en uiteindelijk ook in een eerste fase te implementeren (Boeykens en Neuckermans, 2006, 2007; Boeykens, 2007). In dit onderzoek werd uitgebreide aandacht besteed aan de wijze waarop de overgangen tussen schaalniveaus en tussen ontwerpfases ge¨ımplementeerd zouden kunnen worden (figuur 9.19).

9

Figuur 9.19.: Onderzochte overgangen tussen schaalniveaus (onderaan) en ontwerpfases (bovenaan) in IDEA+.

In Boeykens en Neuckermans (2007); Boeykens (2007) werd tenslotte onderzocht hoe de informatie uit de aangemaakte IDEA+ ontwerpomgeving gebruikt zou kunnen worden in

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

242

externe applicaties die kunnen helpen tijdens het maken van ontwerpbeslissingen in het ontwerpproces. Hierbij wordt getracht om de informatie, die opgeslagen wordt in een intern XML-gebaseerd IDEA+ dataformaat (figuur 9.20), automatisch om te zetten naar een formaat dat leesbaar is in andere applicaties.

Figuur 9.20.: Uitreksel uit een XML-gebaseerd IDEA+ databestand.

9.3. Besluit Wanneer de beschrijvingen van bovenstaande virtuele ontwerpomgevingen kort vergeleken worden met de resultaten uit de literatuurstudie in § 4, § 5, § 6, § 7 (ICT componenten) en § 8 (Dataformaten), dan kunnen enkele vaststellingen gedaan worden met betrekking op de aspecten ‘interoperabiliteit’ en ‘extra functionaliteit’. • Interoperabiliteit Uit de beschrijvingen van de verschillende virtuele ontwerpomgevingen kan een duidelijke, gemeenschappelijke eigenschap vastgesteld worden, namelijk ‘flexibiliteit’. Dit wordt nagenoeg overal voorzien door een toolset te voorzien die op een zo uitgebreid mogelijk manier kan aangewend worden. Waar dit echter ´e´en van de belangrijkste basisdoelstellingen is in deze ontwerpomgevingen, wordt dit dikwijls op een verschillende manier uitgewerkt. In DDDoolz wordt bijvoorbeeld gebruik gemaakt van de uitgebreide configuratiemogelijkheden van eenvoudige kubussen (§ 9.2.2), terwijl EsQUIsE eerder tracht terug te vallen op de flexibiliteit van de pen en papier tekenmethode, en terwijl in IDEA+ ten slotte een complex systeem wordt uitgewerkt van scale level & design phase overgangen. Waar de nadruk op flexibiliteit bijna overheersend naar voor lijkt te komen, lijkt de uitwerking van interoperabiliteit tussen verschillende ontwerpomgevingen eerder

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

243

verwaarloosd te worden. Zo wordt bijvoorbeeld in nagenoeg geen van de beschreven ontwerpomgeving expliciet gestreefd om een koppeling te maken vanuit de virtuele schetsomgeving naar een bestaande CAD applicatie, wat toch een voordeel zou kunnen zijn in het brengen van effici¨entie in het ontwerpproces. Ook onderlinge koppelingen tussen de virtuele schetsomgevingen lijken niet aan de orde te zijn. De nadruk op flexibiliteit en de verwaarlozing van de interoperabiliteit lijkt eveneens terug te vinden te zijn in het gebruikte bestandsformaat. Wanneer bijvoorbeeld naar het gebruikte bestandsformaat van IDEA+ gekeken wordt, dan blijkt er teruggevallen te worden op een XML-gebaseerd dataformaat (§ 9.2.10), wat in § 8.5 reeds bestempeld werd als een uiterst flexibele taal, met bijgevolg ook weinig mogelijkheden naar interoperabiliteit (§ 8.5). Een ontwerpomgeving dat als ´e´en van de enigen tracht om interoperabiliteit aan te bieden in een tegelijk flexibele ontwerpomgeving, is IDEA+ (§ 9.2.10). In de recentste onderzoeken wordt namelijk getracht om het gebruikte XML-gebaseerd IDEA+ dataformaat om te zetten naar een formaat dat ingelezen kan worden door externe applicaties voor evaluatie. Door het vasthouden van XML als basis, lijkt dit echter niet het niveau van interoperabiliteit te bereiken die gerealiseerd wordt in de BIM benadering voor de uitwerkingsfase van het ontwerp. • Extra functionaliteit Aangezien weinig mogelijkheden aangeboden worden naar interoperabiliteit, zou verwacht kunnen worden dat een zo groot mogelijk functionaliteit aangeboden wordt binnen de virtuele ontwerpomgeving zelf. Hierdoor zou de ontwerper in feite een volledig ‘ge¨ıntegreerde’ ontwerpomgeving ter beschikking krijgen, wat even goed zou kunnen werken voor het ontwerpproces als een uitgebreide verzameling aan applicaties waar telkens geconcentreerd zou worden op een bepaald aspect van het ontwerp. Bij een beoordeling van de gegeven beschrijvingen (§ 9.2) lijkt dit inderdaad ook de doelstelling te zijn van het merendeel van de ontwerpomgevingen. In dit opzicht wordt bijvoorbeeld getracht om EsQUIsE te koppelen aan een AMCE applicatie voor evaluatie (§ 6.4.2) en wordt in IDEA+ getracht om een koppeling te voorzien naar het digitaal archief DYNAMO (§ 4.4.5) ´en naar de applicatie IDEA-l, waarmee lichtinval in het ontwerp zou kunnen ge¨evalueerd worden. Wanneer de aangeboden extra functionaliteiten van deze ontwerpomgevingen echter vergeleken worden met de verschillende aspecten van het ontwerp volgens Moum (2006b), dan lijkt geen van de hier beschreven ontwerpomgevingen effectief in te gaan op ´elk van deze aspecten. De ontwerpomgevingen van EsQUIsE en IDEA+ lijken uit bovenstaande beschrijvingen nog de meeste extra functionaliteiten aan te bieden. Wanneer dit nader ge¨evalueerd wordt voor EsQUIsE, dan blijkt vooral de nadruk ge-

9

HOOFDSTUK 9. VIRTUELE ONTWERPOMGEVINGEN

244

legd te worden op ICT functionaliteit die ingaat op het aspect evaluation of design solutions (§ 6), terwijl relatief weinig ICT functionaliteit aangeboden wordt voor het aspect generation of design solutions, zoals dit beschreven werd in § 4. In IDEA+ lijkt dit net omgekeerd te zijn, hier wordt nagestreefd om een koppeling te maken met het digitaal archief DYNAMO om zo het aspect generation of design solutions een extra ICT ondersteuning te bieden, terwijl de ICT ondersteuning van het aspect evaluation of design solutions (§ 6) eerder verwaarloosd lijkt te worden.

9

Deel IV.

AIM Conceptie

245

10 AIM Benadering

O

P basis van de uitgevoerde literatuurstudie in DEEL II (ICT Componenten), DEEL III (Bestaande Informatiestructuren) en DEEL IV (Bestaande ontwerpomgevingen) wordt in dit hoofdstuk getracht om op conceptueel-theoretisch niveau een geschikte benadering voor te stellen die een antwoord zou kunnen bieden aan de gegeven vraagstelling in § 2.3. Via deze voorgestelde benadering wordt getracht om de ontwerper een ICT platform aan te kunnen bieden dat rechtstreeks afgestemd is op de vroegste ontwerpfase, waarvan de verschillende essenti¨ele aspecten gesitueerd werden in § 3.3, zodat dit ICT platform zou kunnen evolueren tot een effectieve ‘vaste partner’ in het ontwerp (Reffat, 2007)..

10.1. Situering Op basis van een kort beschouwend onderzoek in § 2.1 en § 2.2 werd in § 2.3 een vraagstelling vooropgesteld, waarop in deze scriptie verder ingegaan werd. Deze vraagstelling werd omschreven als de vraag waarom het merendeel van de ontwerpers in de ontwerpfase nog steeds lijkt te werken met een op papier gebaseerde werkmethode of met een ICT applicatie die eerder als ‘digitale tekentafel’ of visualisatiemiddel gebruikt wordt, en minder geneigd lijkt te zijn om over te schakelen op een ontwerpproces waarin ICT eerder gebruikt wordt als een ‘vaste partner’ in het ontwerpproces (§ 2.3). Deze werkmethode lijkt namelijk sterk in contrast te staan met de huidige werkmethodes in het eigenlijke uitvoeringsontwerp (Penttil¨ a en Weck, 2006; Penttil¨ a, 2007).

246

HOOFDSTUK 10. AIM BENADERING

247

Uit de resultaten van de uitgevoerde literatuurstudie kon vastgesteld worden (§ 8.3.2) dat de werkmethodes in het uitvoeringsontwerp op dit moment structureel herwerkt zijn, op initiatief van de International Alliance for Interoperability, waarbij als doelstelling een ruim modelleerplatform (BIM ) voorgesteld is, in combinatie met een maximum aan interoperabiliteit (IFC ) tussen de verschillende partijen in het uitvoeringsontwerp (§ 8.3.2). Hierdoor is getracht om de verschillende applicaties voor de uitwerking en detaillering van een ontwerp een gemeenschappelijke basis te geven, zodat de consistentie van het gebouwmodel en de effici¨entie in het ontwerpproces geoptimaliseerd zouden kunnen worden (§ 8.3.2). Waar deze BIM werkmethode een zeker succes kent in het uitvoeringsontwerp (Penttil¨ a a, 2007), wordt in verschillende onderzoeken vastgesteld dat ze door en Weck, 2006; Penttil¨ ontwerpers eerder ongeschikt bevonden is om effectief ingezet te worden in het eigenlijke voorontwerp (§ 2.1). Als ´e´en van de voornaamste redenen wordt in Moum (2006b); Penttil¨ a en Weck (2006) en Penttil¨ a (2007) gesteld dat Building Information Modelling te veel “zeer gedetailleerde componentengebaseerde gebouwmodelleertechnieken” zou bevatten, waarin een ontwerper niet geneigd is te investeren tijdens de ontwerpfase. Uitgaande van de resultaten van de literatuurstudie zou dit bevestigd kunnen worden (§ 7.5). Het lijkt inderdaad voldoende tijd te vergen om de verschillende componenten van het gebouwmodel te modelleren in al zijn samenstellende onderdelen. Eens deze componenten echter gemodelleerd zijn en de ontwerper gewend is geraakt aan het werken met deze componenten, zou wel kunnen aangenomen worden dat hiermee ook relatief snel een voorontwerp kan uitgetekend worden (Moum, 2006b). Het BIM platform biedt via de mogelijkheden van parameters en constraints namelijk voldoende functionaliteit naar het aanpassen en eventueel volledig vervangen van de verschillende, uitgetekende componenten van het model (§ 7.5.2). In Moum (2006b) werd dan ook gesteld dat de ontwerper zichzelf zou moeten trachten aan te passen en meer zou moeten leren denken in object-ge¨ ori¨enteerde of BIM -gerelateerde termen (§ 2.1.2). In ditzelfde deel van de literatuurstudie (§ 7) werd echter ook een andere vaststelling gedaan die eventueel meer aan de basis zou kunnen liggen van het onderzochte verschil tussen ICT gebruik in de ontwerpfase en ICT gebruik in de uitwerkingsfase. In § 7.6 wordt namelijk geconcludeerd, op basis van de literatuurstudie naar de uitgewerkte combinatie van FeatureBased Modelling en Generic Design Representations (§ 7.4.2), dat een techniek met dezelfde basis als de BIM modelleertechniek gebruikt zou kunnen worden voor de modellering van meer ontwerpgerelateerde componenten, zoals een ‘grid’, een ‘aslijn’, enzovoort. Er zou dus kunnen geconcludeerd worden dat, door een kleine nuance te maken in het eigenlijke onderwerp van deze Building Information Modelling technieken (§ 7.6), ook gewerkt zou kunnen worden met heel andere, minder gedetailleerde en meer ontwerpgerelateerde componenten. Indien dit als een alternatief modelleerplatform uitgewerkt zou worden, dan zou het even-

10

HOOFDSTUK 10. AIM BENADERING

248

tueel mogelijk zijn om de ontwerper een platform aan te bieden dat meer gericht is naar de informatie die gebruikt wordt in de eigenlijke ontwerpfase. Deze ‘ontwerpinformatie’ wordt over het algemeen een stuk abstracter, implicieter en minder gedetailleerd geacht dan in de uitwerkingsfase van het ontwerp (Moum, 2006b), waardoor de “zeer gedetailleerde componentengebaseerde gebouwmodelleertechnieken” vermoedelijk tot op een bepaald niveau weggewerkt kunnen worden.

10.2. Problematiek Doordat geen vergelijkbare modelleermethode als BIM vermeld kan worden voor de ontwerpfase, lijken op een algemeen niveau twee centrale problemen te ontstaan binnen de werkwijze in de voorontwerpfase (§ 9.3). Deze hebben betrekking op de aard van de informatie die in dit model gemodelleerd dient te worden en op de interoperabiliteit tussen het model en de bestaande ICT applicaties voor het ontwerpproces.

10.2.1. Ontwerpinformatie Via bestaande modelleertechnieken lijkt het, op basis van de conclusies in § 7.6, moeilijk om informatie over het ontwerp zelf in te brengen in een driedimensionaal informatiemodel. Bij de uitwerking van een mogelijke benadering naar een alternatief modelleerplatform, gericht op de ontwerpfase, is het bijgevolg van bijzonder belang dat de informatie die w´el van nut kan zijn in deze ontwerpfase, correct benoemd en ingevuld kan worden, zodat dit alternatief modelleerplatform effectief zijn nut kan bewijzen voor het architecturaal ontwerpproces. Binnen deze scriptie wordt niet dieper ingegaan op de eigenlijke invulling van deze informatie, maar wordt wel een benadering gegeven van wat wellicht de aard van deze informatie zal zijn. Dit gebeurt op basis van de invulling die, doorheen de verschillende onderdelen van het uitgevoerde literatuuronderzoek, gegeven lijkt te worden aan het woord ‘ontwerpinformatie’. • generation of design solutions Binnen het aspect generation of design solutions, worden ontwerpen of ‘cases’ in digitale archieven meestal onderverdeeld volgens bepaalde ‘keywords’ of categorie¨en (§ 4.4). Deze categorie¨en vormen doorgaans de eigenlijke metadata achter de digitale data uit het archief in kwestie, waaruit kan geconcludeerd worden dat aan de hand van deze categorie¨en een onderscheid kan gemaakt worden tussen verschillende ontwerpen. De eigenlijke inhoud van deze categorie¨en kan dus wellicht ook begrepen worden als een vorm van ontwerpinformatie. Wanneer de eigenlijke aard van deze informatie beschouwd wordt, dan lijken dit veeleer

10

HOOFDSTUK 10. AIM BENADERING

249

algemene, categoriserende termen te zijn om een ruime onderverdeling te cre¨eren tussen verschillende cases in het digitaal archief. Zo worden bijvoorbeeld in het digitaal archief van ARCHInform (§ 4.4.1), naast de eerder benoemende informatie (locatie periode - architect), keywords of categorie¨en gebruikt zoals ‘betonbouw’, ‘kathedraal’, ‘sociale woningbouw’, ‘romaanse stijl’, enzovoort. • communication Binnen het aspect communication lijkt zowel in de beschrijving (§ 3.2.2) als in de uitgevoerde literatuurstudie (§ 5.5) niet rechtstreeks teruggekomen te worden op de aard z´elf van de ontwerpinformatie, zodat via dit ontwerpaspect hier ook geen specifieke invulling aan wordt gegeven. • evaluation of design solutions Binnen het aspect evaluation of design solutions zou volgens § 3.2.2 uitgebreid gebruik moeten gemaakt worden van de informatie die in een ontwerp aanwezig is. In Moum (2006b,a) wordt deze informatie expliciet onderverdeeld naar een ‘kwantitatief en meetbaar niveau’ en een ‘kwalititatief, tacit en impliciet’ niveau. De informatie op het kwalitatief en meetbaar niveau kan volgens § 6.6 in de eerste plaats beschouwd worden als informatie over eerder ‘kennisgerichte’ eigenschappen van een ontwerp. In § 6.6 wordt geconcludeerd dat deze vorm van informatie reeds uitgebreid gebruikt wordt in de huidige ICT applicaties voor evaluation of design solutions. Dit kan daarbij bijvoorbeeld gaan om parameters die gebruikt worden om voorlopige energieberekeningen of akoestische simulaties en lichtsimulaties uit te voeren (§ 6.6). De informatie op het kwantitatief, tacit en impliciet niveau wordt volgens de conclusies in § 6.6 beduidend minder toegepast in bestaande applicaties voor de evaluation of design solutions. Dit lijkt te worden veroorzaakt doordat deze informatie moeilijk omgezet kan worden naar een vorm waarin een informatiesysteem deze verschillende soorten informatie kwantitatief kan interpreteren en ten opzichte van elkaar kan afwegen. Zo blijkt uit de conclusie in § 6.6 dat, indien een ontwerp volgens dit niveau ge¨evalueerd wordt, nagenoeg altijd de persoon in kwestie gevraagd wordt om de evaluatiecriteria van dit niveau uitdrukkelijk te expliciteren. • decision-making Binnen het aspect decision-making wordt een uitgebreide verzameling aan invloedsfactoren en ontwerpeigenschappen vermeld, op basis waarvan een beslissing kan genomen worden in het ontwerpproces (§ 3.2.2). Deze invloedsfactoren en ontwerpeigenschappen zouden kunnen beschouwd worden als ontwerpinformatie. In § 3.2.2 wordt echter eveneens gesteld dat deze invloedsfactoren en ontwerpeigenschappen reeds grotendeels

10

HOOFDSTUK 10. AIM BENADERING

250

bepaald werden door de overige drie aspecten van het ontwerpproces (generation of design solutions - communication - evaluation of design solutions) (Moum, 2006b). Er zou bijgevolg aangenomen kunnen worden dat onder het aspect decision-making geen extra, nieuwe invulling gegeven wordt aan ‘ontwerpinformatie’.

Uit dit korte overzicht zou een onderscheid gemaakt kunnen worden tussen de volgende soorten ontwerpinformatie. Om een wetenschappelijk meer correcte invulling en onderverdeling op te kunnen stellen voor ‘ontwerpinformatie’, zou echter in de eerste plaats een uitgebreider onderzoek moeten uitgevoerd worden naar dit onderwerp. • expliciet – categoriserende ontwerpinformatie – kwantitatieve ontwerpinformatie – meetbare ontwerpinformatie • impliciet – impliciete ontwerpinformatie – tacit ontwerpinformatie – kwalitatieve ontwerpinformatie

10.2.2. Interoperabiliteit In de studie naar Virtual Design Environments in hoofdstuk 9 wordt nagenoeg nergens vastgesteld dat een ontwerpmodel in het IFC dataformaat opgebouwd of doorgegeven wordt (§ 9.3). Dit lijkt er op te wijzen dat geen centraal model kan opgebouwd worden waarin de heel uiteenlopende soorten informatie uit de ontwerpfase (§ 10.2.1) gestructureerd of driedimensionaal gemodelleerd kunnen worden ´en in een dataformaat doorgegeven worden dat een even grote interoperabiliteit tussen personen en informatiesystemen biedt als IFC dat doet (§ 9.3). Zo wordt bijvoorbeeld voor de ontwerpomgeving IDEA+ (§ 9.2.10) wel een ontwerpmodel opgebouwd met uitgebreide informatie over heel uiteenlopende aspecten van het ontwerp, zoals verschillende schaalniveaus en een overgang in ontwerpfases, maar dit model wordt vervolgens opgebouwd en bijgehouden in een eigen ontwikkeld XML-gebaseerd dataformaat (§ 9.2.10). Zoals beschreven werd in § 8.5 biedt dit dataformaat een veel lagere interoperabiliteit naar externe applicaties dan een dataformaat op basis van IFC.

10

HOOFDSTUK 10. AIM BENADERING

251

Aangezien in de eigenlijke ontwerpfase op dit moment dus geen vergelijkbaar modelleerplatform als BIM vermeld kan worden, kent een initiatief naar interoperabiliteit, zoals IFC, nog maar betrekkelijk weinig toepassing in de eigenlijke voorontwerpfase. Dit lijkt ook geconcludeerd te kunnen worden uit de resultaten van de literatuurstudie die in DEEL II (ICT Componenten) werd uitgevoerd. Zoals blijkt uit de resultaten van deze literatuurstudie (§ 4.5 - § 5.5 - § 6.6 - § 7.6), worden ICT applicaties vandaag namelijk in veel gevallen ontwikkeld om expliciet te kunnen voldoen aan de verschillende aspecten van het ontwerpproces, maar richten ze zich daarbij eerder op de eigenlijke aspecten van dit ontwerpproces z´elf en niet op een centraal modelleerplatform met een bijhorend dataformaat als IFC, waarin deze aspecten aan bod zoudenkunnen komen. Doordat dus geen centraal kader aanwezig blijkt te zijn zoals dit in de uitwerkingsfase het geval is, lijkt deze verzameling aan ICT applicaties een sterk heterogeen karakter te krijgen. Dit zou kunnen resulteren in een ontwerpmethodiek waarbij de ontwerper slechts in enkele gevallen beroep doet op specifieke, zelf gekozen ICT applicaties, zoals dit in § 2.2.1 omschreven werd als een ICT gebruik van het ‘Type B’ (ICT als een effectief en handig medium / extra hulpmiddel). Het gebrek aan een betere interoperabiliteit tussen een modelleerplatform en de verschillende ICT componenten die naar de verschillende aspecten van het ontwerpproces ontwikkeld worden, zou met andere woorden de oorzaak kunnen zijn waarom ontwerpers niet, zoals in de uitwerkingsfase van het ontwerp meer het geval lijkt te zijn, overstappen naar een ICT gebruik van het ‘Type C’ (ICT als een vaste ‘partner’ in het ontwerp).

10.3. Doelstelling Via bovenstaande, korte situering van de oorspronkelijke vraagstelling uit deze scriptie ten opzichte van de uitgevoerde literatuurstudie (§ 10.1), werd getracht om de mogelijke aanleiding van deze vraagstelling correct te situeren binnen deze literatuurstudie. Een korte beoordeling van deze vraagstelling werd vervolgens in § 10.2 uitgevoerd volgens deze situering en toegelicht aan de hand van de resultaten uit de literatuurstudie. Deze beoordeling kon worden onderverdeeld in volgende twee aspecten. • de aard van de informatie die beschikbaar zou moeten zijn in een ontwerpomgeving • het interoperabiliteitskarakter dat deze ontwerpomgeving zou moeten kenmerken

Uitgaande van de resultaten van het uitgevoerde literatuuronderzoek zou bij een benadering van de problematiek vooral op deze twee aspecten moeten ingegaan worden, indien deze

10

HOOFDSTUK 10. AIM BENADERING

252

benadering voldoende mogelijkheden zou willen aanbieden voor de integratie van ICT functionaliteit in het ontwerpproces. Daarom wordt de uitwerking van deze benadering binnen deze scriptie in de eerste plaats op deze twee aspecten geconcentreerd. Deze uitwerking wordt in § 10.4 stapsgewijs opgebouwd op basis van deze algemene doelstelling en op basis van de resultaten uit het uitgevoerde literatuuronderzoek.

10.4. Algemene benadering In de opbouw van een algemene benadering die een antwoord zou kunnen bieden aan de in § 2.3 gegeven vraagstelling, wordt vertrokken van de in § 10.3 bekomen doelstelling om een centraal kader op te stellen voor deze benadering. Via dit centraal kader wordt getracht om de basis te leggen voor een verbeterde werkmethode in de voorontwerpfase. In een tweede stap worden in dit kader de verschillende ICT componenten gesitueerd. Dit wordt daarbij gebaseerd op de resultaten van het uitgevoerde literatuuronderzoek rond de aspecten van een ontwerpproces (§ 4, § 5, § 6 en § 7), zodat deze ICT componenten op een zo correct mogelijke wijze op dit centrale kader ge¨ent kunnen worden.

10.4.1. Centraal kader In de eerste plaats wordt voorgesteld om in de benadering een nieuw gedefinieerd kader te voorzien waarin een voldoende grote interoperabiliteit voorzien wordt tussen de invulling van dit centrale kader en de gerelateerde ICT applicaties. Aangezien uit § 7.6 en § 8.5 kon geconcludeerd worden dat de interoperabiliteit die geboden wordt door het IFC bestandsformaat voldoende bestaande functionaliteiten en toekomstperspectieven bood binnen de uitwerkingsfase van het ontwerp (BIM ), wordt er binnen deze scriptie ook aangenomen dat dit evenveel toekomstperspectieven kan bieden binnen de voorontwerpfase van het ontwerp. Deze interoperabiliteit dient daarbij, in de tweede plaats, uitgewerkt worden op basis van een ander soort informatie, namelijk de verschillende soorten ontwerpinformatie, zoals deze reeds benaderend beschreven werden in § 10.2.1. Door het expliciete gebruik van deze ‘ontwerpinformatie’ binnen een benadering van ICT gebruik in de voorontwerpfase, wordt getracht een kleine, maar belangrijke nuance te geven aan de basiswerking van Building Information Modelling, namelijk door het soort informatie aan te passen naar een meer architecturaal getinte invulling en minder naar een gebouwtechnisch getinte invulling. Door deze nuance wordt het mogelijk geacht om uiteindelijk een grotere meerwaarde te kunnen bieden aan de ontwerper dan op dit moment het geval lijkt te zijn in de voorontwerpfase (§ 2.2.1). De nuance wordt eveneens doorgevoerd in de naamgeving van de voorgestelde benadering.

10

HOOFDSTUK 10. AIM BENADERING

253

Hierin wordt de benaming Building Information Modelling (BIM), dat expliciet gericht is op de uitwerkingsfase, herbruikt en omgevormd tot ‘Architectural Information Modelling’ (AIM) of ‘Architecturale Informatie Modellering’. Via de nuancering in deze benaming wordt indirect verwezen naar de twee centrale aspecten van deze benadering (figuur 10.1), namelijk de interoperabiliteit, die gebaseerd wordt op de werkmethodes binnen BIM (‘Information Modelling’ ), en het behandelde soort informatie (‘Architectural’ ), wat uitdrukkelijk verschilt met het soort informatie binnen BIM (‘Building’ ).

Figuur 10.1.: Schema met de twee centrale aspecten in de Architectural Information Modelling benadering.

10.4.2. ICT Componenten Om het centraal kader zo geschikt mogelijk uit te kunnen werken voor de voorontwerpfase, zou in de AIM benadering reeds rekening gehouden moeten worden met een zo hoog mogelijk niveau van interoperabiliteit tussen het kader en de verschillende ICT componenten uit DEEL II (ICT Componenten). Op die manier zou worden getracht om deze benadering van bij de conceptie als een correct ge¨ıntegreerd geheel uit te werken, wat volgens § 9.3 in bestaande virtuele ontwerpomgevingen veeleer problematisch bleek te zijn (figuur 10.2). De onderverdeling in ICT componenten, zoals deze gehanteerd werd in de hoofdstukken 4, 5, 6 en 7, werd in § 3.2.2 gebaseerd op de wijze waarop het ontwerpproces door Moum (2006b) werd onderverdeeld volgens verschillende essenti¨ele ‘design aspects’. Hiervoor werd door Moum (2006b) teruggevallen op het reeds uitgebreid uitgevoerde onderzoek rond het specifieke karakter van het architecturaal ontwerpproces. Er wordt in Moum (2006b) onder andere verwezen naar Sch¨ on (1991); Lawson (1997); Kalay (2004); Kiviniemi en Haymaker (2005). De onderverdeling volgens ‘design aspects’ ziet er als volgt uit (§ 3.2.2). • generation of design solutions

10

HOOFDSTUK 10. AIM BENADERING

254

Figuur 10.2.: In vraag gestelde situering van de ontwerpaspecten ten opzichte van het voorgestelde Architectural Information Modelling kader.

• communication • evaluation of design solutions • decision-making

Door Moum (2005b,a, 2006a,b) werden deze vier ontwerpaspecten echter ook concreet geplaatst binnen een schematisch voorgesteld ontwerpproces (§ 3.2.3), dat te zien is in figuur 10.3. Aan de hand van dit schema werd door Moum (2005a) getracht om de onderlinge relaties tussen de vier verschillende aspecten concreter te defini¨eren, zodat het gebruikt kon worden om de impact van ICT applicaties op elk van deze aspecten te beoordelen (§ 3.2.3). In § 3.3 werd echter reeds gesteld dat binnen deze scriptie in eerste instantie niet verdergegaan wordt op dit schematisch ontwerpproces van Moum (2005a). Waar de onderverdeling volgens vier verschillende ontwerpaspecten namelijk duidelijk gebaseerd wordt op uitvoerig voorgaand onderzoek, lijkt de onderlinge situering van deze ontwerpaspecten in een geschematiseerd ontwerpproces op een heel wat minder stevige basis gefundeerd te zijn (§ 3.3). Binnen deze scriptie wordt daarom aangenomen dat een overname van dit schema, een te eenduidige en te rechtlijnige invloed zou kunnen hebben op een benadering van de wijze,

10

HOOFDSTUK 10. AIM BENADERING

255

Figuur 10.3.: Onderlinge situering van de verschillende ‘design aspects’ volgens Moum (2005b,a, 2006a,b).

waarop de vier aangehaalde ICT componenten gekoppeld dienen te worden aan een centraal Architectural Information Modelling kader (§ 10.4.1). Er wordt daarom rechtstreeks vertrokken van de resultaten uit de literatuurstudie om de karakteristieken van de vier verschillende ICT componenten te beoordelen en te benoemen, en aan de hand daarvan deze ICT componenten op een zo breed mogelijke basis te enten op het kader uit § 10.4.1. Deze beoordeling en benaming wordt hier uitgevoerd voor de vier gesitueerde ICT componenten volgens de verschillende design aspects. Generation of design solutions Bestaande ICT applicaties die ingaan op het ontwerpaspect generation of design solutions, lijken zich in de eerste plaats te concentreren op de aanname dat, wanneer een ontwerp gestart of aangepast wordt, dit doorgaans vertrekt vanuit algemene, architecturale kennis of ervaringen die beleefd zijn door de ontwerper zelf of door andere ontwerpers voordien (Heylighen en Neuckermans, 2000a). Op basis van de beschrijving die hieraan gegeven werd in § 3.3.1 wordt deze ICT component in de verdere uitwerking van de ICT benadering hernoemd tot een ‘Architectural Memory’ (AM). Met deze benaming wordt getracht om de wijze waarop deze ICT component tracht in te spelen op het ontwerpaspect ‘generation of design solutions’ correcter te benoemen. De ICT component Architectural Memory lijkt vooral te bestaan uit digitale archieven die de architect of de ontwerper een zo groot mogelijke informatiebron trachten te geven (§ 4.5) binnen de ontwerpfase. Via deze informatiebron wordt getracht om het referentiekader dat door de architect gebruikt wordt om nieuwe ontwerpoplossingen te genereren, in de eerste plaats te doen vergroten en in de tweede plaats doelgerichter te doen werken. • verruiming van het referentiekader

10

HOOFDSTUK 10. AIM BENADERING

256

De verruiming van het referentiekader kan zowel beschouwd worden op het niveau van de data als op het niveau van de metadata. Wat de verruiming op het vlak van data betreft, wordt door bestaande digitale archieven getracht om een zo ruim mogelijk aanbod aan verschillende documenten aan te bieden. Het digitaal archief van IRB kan dit illustreren door het grote aantal documenten dat in dit archief aangeboden wordt (§ 4.4.3) en het digitaal archief van DYNAMO kan dit illustreren door de verscheidenheid aan dataformaten dat opgenomen kan worden (§ 4.4.5). Wat de verruiming op het vlak van metadata betreft, kan het initiatief van MACE genoemd worden, dat expliciet tracht om de verschillende digitale archieven te verenigen onder ´e´en centraal portaal. Om dit mogelijk te maken wordt een OAI-PMH Federator gebruikt die de verschillende bestaande digitale archieven kan doorzoeken. Via dit portaal wordt met andere woorden getracht om alle metadata van de in MACE opgenomen digitale archieven toegankelijk te maken op een zelfde basis (§ 4.4.7). • doelgerichtheid in het referentiekader In bestaande digitale archieven wordt eveneens getracht om de opgenomen informatie zo doelgericht mogelijk te kunnen doorzoeken zodat di´e informatie kan doorgegeven worden aan de architect die waarschijnlijk het best beantwoordt aan zijn vraag. Hiervoor wordt reeds geruime tijd onderzocht op welke manier Case-Based Reasoning technieken kunnen toegepast worden in deze digitale archieven (§ 4.2.1). Communication In § 3.2.2 werd reeds beschreven hoe het aspect communication kan gesitueerd worden op twee verschillende niveaus, namelijk binnen het denkproces van de architect zelf en binnen de interactie tussen de architect en externe personen, zoals de bouwheer, een aannemer of eventueel zelfs een onafhankelijke buitenstaander. Centraal in deze twee vormen van communicatie werd echter vooral het belang van de interpreteerbaarheid van de voorstellingswijze benadrukt. Een onderscheid in interpretatie zou het namelijk mogelijk kunnen maken dat heel nieuwe invalshoeken op een ontwerpprobleem ontstaan, wat enkel bevorderlijk kan zijn voor het genereren van nieuwe ontwerpalternatieven (§ 3.2.2). Op basis van deze beschrijving wordt voorgesteld om de ICT component die tracht in te spelen op het ontwerpaspect ‘communication’ te benoemen als de component VR-SIM of ‘Virtual Reality - Visual Simulation’. Uit het uitgevoerde onderzoek (§ 5.5) naar de wijze waarop ICT applicaties trachten in te spelen op het ontwerpaspect communication, kon namelijk vastgesteld worden dat Virtual Reality een waardig systeem kan zijn waarmee

10

HOOFDSTUK 10. AIM BENADERING

257

een zo ruim mogelijke funtionaliteit kan aangeboden worden aan de ontwerper voor de visualisatie van de informatie in het ontwerpmodel. De verschillende manieren waarop deze informatie kan gevisualiseerd worden, zowel op softwarematig als op hardwarematig vlak, en de verschillende manier waarop met deze visualisatie kan ge¨ınterageerd worden in de verschillende Virtual Reality systemen (§ 5.5), worden beschouwd als een goede basis om heel uiteenlopende interpretaties van eenzelfde informatiemodel mogelijk te maken. Binnen deze scriptie wordt deze component expliciet als complementair beschouwd aan het medium pen en papier, omdat aangenomen wordt dat de mogelijkheden naar interpretatie van een snelle, gerichte schets van het architectuurontwerp op dit moment wellicht niet kunnen overtroffen worden door de visualisatiemogelijkheden van een informatiesysteem (§ 5.5). Waar een algemeen perspectief via de interpretatie van een ontwerpschets op papier snel lijkt aangepast en herwerkt te kunnen worden, zou een ICT component VR-SIM op basis van de resultaten in § 5.5 eventueel meer mogelijkheden kunnen bieden naar de interpretatie van de eigenlijke informatie achter de ontwerpschets. Zo zouden bijvoorbeeld de resultaten van een driedimensionale warmteverliesberekening in het Virtual Reality systeem op een snelle en relatief correcte manier gevisualiseerd kunnen worden aan de hand van een soort ‘thermografische camera’ op het opgebouwde informatiemodel, waar dit via pen en papier te moeilijk zou kunnen zijn om dit snel te visualiseren. Daarom wordt voorgesteld om deze VR-SIM component in de AIM benadering in de eerste plaats te richten op de eigenlijke ontwerpinformatie die eerder in de andere componenten van het centraal kader aanwezig lijkt te zijn (§ 10.2.1), zodat een zo goed mogelijke samenwerking kan gecre¨eerd worden tussen deze VR-SIM component en het vertrouwde medium potlood en papier van de architect. Evaluation of design solutions Een derde, essentieel aspect binnen het ontwerpproces is volgens Moum (2006b,a) het aspect evaluation of design solutions. Dit wordt door Moum (2006b,a) onderverdeeld in twee niveaus, namelijk een ‘kwantitatief en meetbaar’ niveau en een ‘kwalitatief, tacit en intu¨ıtief’ niveau (§ 3.3.3). Uit de conclusies van de literatuurstudie naar applicaties die inspelen op het ontwerpaspect evaluation of design solutions (§ 6.6), kwam naar voor dat de bestaande ICT applicaties zich in de eerste plaats lijken te richten op expliciet meetbare en kwantitatieve informatie, aangezien de kwalitatieve, tacit en impliciete informatie van een voorontwerp moeilijk te benoemen bleek (Lawson, 1997). Deze applicaties trachten de verschillende expliciet definieerbare parameters van een ontwerp terug te vinden in het voorontwerp om aan de hand

10

HOOFDSTUK 10. AIM BENADERING

258

hiervan simulaties en berekeningen uit te voeren. De resultaten van deze simulaties en berekeningen worden volgens § 6.6 daarna weinig verder ge¨ınterpreteerd, maar eerder onverwerkt doorgegeven aan de ontwerper of architect zodat deze ze zelf kan verwerken. Op basis van deze beschrijving wordt voorgesteld om deze ICT component te hernoemen als de component ‘Virtual Simulation & Calculation’ of kortweg V-CALC. Aangezien binnen de AIM benadering w´el getracht wordt om ook de meer impliciete, kwalitatieve en tacit ontwerpinformatie te benoemen (§ 3.3.3) en tot op een bepaalde hoogte onderling afweegbaar te maken, dient ook rekening gehouden te worden met dit aspect van V-CALC. Aangezien de aard van deze informatie op dit moment in feite nog verder onderzocht dient te worden (§ 10.2.1), wordt de voorgestelde V-CALC component nog voorlopig beperkt tot de meer expliciet aanwezige informatie (categoriserend, kwantitatief en meetbaar). Decision-making Het aspect decision-making is volgens Moum (2006b) van onmiskenbaar belang in het ontwerpproces (§ 3.2.2). Onder dit aspect wordt door Moum (2006b) de wijze bedoeld waarop beslissingen worden gemaakt in het ontwerpproces (§ 3.2.2). Hiervoor wordt volgens Moum (2006b) teruggevallen op heel uiteenlopende factoren, die in feite gesitueerd kunnen worden (§ 3.2.2) in de drie overige aspecten van het ontwerpproces (generation of design solutions communication - evaluation of design solutions). Dit wordt opnieuw, net zoals in Moum (2006b), ruim begrepen binnen deze scriptie. Er wordt gesteld dat decision-making gebaseerd kan zijn op invloedsfactoren zoals materiaalkundige en bouwtechnische eisen, eerder stedenbouwkundige voorschriften, de wijze van communicatie, ethische aspecten, enzovoort. In § 7.6 werd reeds gesteld dat in deze scriptie niet ingegaan wordt op de verschillende manieren waarop ICT applicaties zouden trachten in te spelen op het in rekening brengen van de verschillende invloedsfactoren op dit aspect decision-making. Deze invloedsfactoren en ontwerpeigenschappen werden namelijk reeds door Moum (2006b) verondersteld om eerder afkomstig of behandeld te zijn in de overige drie aspecten van de voorontwerpfase (§ 7.6). In deze scriptie wordt daarentegen wel ingegaan op de wijze waarop ICT applicaties op dit moment een voldoende ruime omkadering trachten te bieden voor het nemen van beslissingen in het voorontwerp. Deze ‘voldoende ruime omkadering’ dient daarbij een zo volledig mogelijk perspectief te kunnen bieden op de uiteenlopende invloedsfactoren en ontwerpeigenschappen in de voorontwerpfase. In principe werd via de algemene benadering van het centraal AIM kader reeds getracht om dit mogelijk te maken voor specifieke ‘ontwerpmatige’ (§ 10.2.1) invloedsfactoren en

10

HOOFDSTUK 10. AIM BENADERING

259

ontwerpeigenschappen. Om het kader waarin beslissingen genomen kunnen worden, echter nog uitgebreider te maken, wordt voorgesteld om ook de werkomgeving van BIM tot op een bepaald niveau toegankelijk te maken binnen de voorontwerpfase. Er wordt voor de werkomgeving van BIM gekozen, omdat deze, door zijn gerichtheid op de eerder componentengebaseerde ontwerpfasen binnen het ontwerp (§ 7.6), als een effectieve verruiming wordt beschouwd van het reeds voorgestelde AIM kader. In § 7.6 werd namelijk reeds vastgesteld dat deze BIM omgeving in sommige gevallen wel degelijk een meerwaarde zou kunnen bieden voor de voorontwerpfase. Omwille van deze specifieke gerichtheid op de BIM werkmethode, wordt deze ICT component benoemd met de term ‘Building Information Modelling’ zelf, of kortweg BIM.

10.4.3. Resultaat Het voorgesteld resultaat van bovenstaande, stapsgewijs opgebouwde benadering is een centraal AIM kader waarin van bij de conceptie de mogelijkheid voorzien wordt tot koppeling van de vier ICT componenten aan dit kader (figuur 10.4), waarmee getracht wordt een meerwaarde te bieden binnen de verschillende aspecten van de voorontwerpfase. Dit kader zou in de eerste plaats gebaseerd worden op een IFC datastructuur waar de verschillende soorten ontwerpinformatie (§ 10.2.1) in kunnen opgebouwd en bewaard worden. In de tweede plaats wordt hierop een intensieve verbinding voorzien met de ICT componenten Architectural Memory (AM), Virtual Reality - Visual Simulation (VR-SIM), Virtual Simulation & Calculation (V-CALC) en Building Information Modelling (BIM), die de informatie in deze IFC datastructuur kunnen gebruiken om het geheel tot een effectieve ICT ‘partner’ te kunnen laten evolueren. Om deze benadering uit te kunnen werken tot een functionerend AIM kader, zouden deze verschillende ICT componenten (figuur 10.4) echter concreter gesitueerd moeten worden ten opzichte van het centrale Architectural Information Model. Aan de hand van deze situering zou vervolgens kunnen gespecifieerd worden hoe de informatiestroom vanuit het centrale AIM model naar de verschillende ICT componenten zou kunnen verlopen, zodat ook kan afgeleid worden waartoe deze gekoppelde ICT componenten in staat zouden kunnen zijn en wat de eigenlijke meerwaarde van deze componenten binnen de AIM benadering bijgevolg kan worden (§ 10.5). Een mogelijke onderlinge plaatsing van de ICT componenten werd reeds gesuggereerd in Moum (2006b), op basis van een schematisch doorlopen ontwerpproces (§ 3.2.3 - § 10.4.2). Hierin werd het ontwerpaspect communication (‘VR-SIM’) centraal geplaatst in een proces van visualisatie en interpretatie tussen enerzijds de architect en anderzijds de cli¨ent.

10

HOOFDSTUK 10. AIM BENADERING

260

Figuur 10.4.: Schema van de situatie voorafgaand aan de situering van de ICT componenten in de Architectural Information Modelling benadering.

Het ontwerpaspect generation of design solutions (‘AM’) werd vervolgens ingevuld door de architect, terwijl de ontwerpaspecten evaluation of design solutions (‘V-CALC’) en decisionmaking (‘BIM’) ingevuld werden door de cli¨ent (figuur 10.3 op pagina 255). In DEEL I (ICT Componenten) van de literatuurstudie (§ 4, § 5, § 6 en § 7) is echter niet verdergegaan op deze reeds vernauwende situering van de verschillende ontwerpaspecten binnen een ontwerpproces, maar werd integendeel getracht om te beoordelen hoe bestaande ICT applicaties lijken uitgewerkt te worden naar deze gegeven ‘design aspects’ op zich. Wanneer vervolgens de beschrijvingen beschouwd worden van de verschillende ICT componenten (§ 10.4.2), zoals deze naar voor komen op basis van deze literatuurstudie, dan zouden deze als volgt ten opzichte van elkaar gesitueerd kunnen worden. Uit de resultaten van de literatuurstudie (§ 4 tot en met § 7) en de opsomming onder § 10.4.2 lijken de verschillende ICT componenten, zoals ze op dit moment benaderd worden door uiteenlopende ICT applicaties, in grote lijnen naar voor te komen als evenwaardige componenten, die telkens op een nagenoeg even belangrijk aspect van het ontwerp ingaan. Daarbij worden doorgaans geen aannames gedaan door wie deze verschillende ICT componenten effectief zouden gebruikt moeten worden. Ze worden enkel aangeboden voor gebruik. De expliciete onderverdeling van de ICT component Architectural Memory (‘generation of

10

HOOFDSTUK 10. AIM BENADERING

261

design solutions’ ) onder het domein van de architect, en de expliciete onderverdeling van de ICT componenten Virtual Simulation & Calculation (‘evaluation of design solutions’ ) en Building Information Modelling (‘decision-making’ ) onder het domein van de cli¨ent, zou in dit opzicht eerder voorbarig en beperkend ge¨ınterpreteerd kunnen worden voor toepassing van een uitgebreid en veelzijdig proces als het architecturaal ontwerpproces. Deze aanname van het schema in Moum (2006b) wordt daarom niet gevolgd en er wordt voorgesteld om deze drie componenten enkel ‘toegankelijk’ te maken op een gelijksoortige basis in het centraal AIM kader, zonder daarbij te specifi¨eren voor wie dit toegankelijk gemaakt wordt (figuur 10.5).

Figuur 10.5.: Conceptuele plaatsing van de ICT componenten AM, V-CALC en BIM ten opzichte van het AIM kader. Vanuit het conceptueel AIM kader zouden deze componenten op een evenwaardige basis enkel toegankelijk gemaakt worden en dus ook niet volledig ge¨ıncorporeerd worden.

In de situering van de verschillende ontwerpaspecten door Moum (2006b) is eveneens een eerder speciale rol weggelegd voor het ontwerpaspect communication. Dit aspect is door Moum (2006b) benoemd als een centrale spil tussen de verschillende partijen in het ontwerpproces, waarlangs heel uiteenlopende perspectieven en invalshoeken gegenereerd kunnen worden op eenzelfde onderwerp, enkel en alleen door een verschil in de interpretatie van eenzelfde boodschap.

10

HOOFDSTUK 10. AIM BENADERING

262

Wanneer de overeenkomstige ICT component binnen deze scriptie, VR-SIM, beschouwd wordt (§ 10.4.2), dan lijken de ICT applicaties onder deze component een zeer gelijkaardig doel voor ogen te hebben. Door een medium aan te bieden die enorm veel verschillende mogelijkheden aanbiedt in de voorstelling en in de mogelijke interactie met deze informatie, lijkt volgens § 5.5 getracht te worden zo veel mogelijk verschillende interpretaties van een zelfde ontwerp te genereren. Er wordt dus getracht om een centraal medium ter beschikking te stellen naast het medium pen en papier, waarin heel uiteenlopende visies op eenzelfde verzameling aan informatie zouden kunnen gegenereerd worden. Aan de ICT component Virtual Reality - Visual Simulation of VR-SIM wordt in deze scriptie bijgevolg net als in Moum (2006b) een heel centrale rol gegeven. Dit komt tot uiting in het conceptueel schema dat de verschillende ICT componenten en het centrale AIM kader ten opzichte van elkaar tracht te positioneren (figuur 10.6). De VR-SIM component wordt in dit schema als een overkoepelen ‘medium’ boven het AIM kader ´en de drie overige ICT Componenten geplaatst. Hierdoor wordt getracht om een enkelvoudige interface aan te bieden aan de gebruiker die infomatie uit elk deel van de AIM benadering toegankelijk maakt voor interpretatie.

10

Figuur 10.6.: Conceptueel schema van de Architectural Information Modelling benadering.

HOOFDSTUK 10. AIM BENADERING

263

10.5. AIM informatiestroom Nadat het conceptueel schema toegelicht werd van een voorgestelde Architectural Information Modelling benadering voor de integratie van ICT gebruik in het ontwerpproces, wordt hier getracht om een eerste invulling te geven aan de wijze waarop de informatiestroom in dit conceptueel schema zou kunnen verlopen. Binnen deze scriptie wordt enkel ingegaan op de digitale datastructuren (§ 8.5)) die binnen deze informatiestroom zouden kunnen aangewend worden en de reden waarom hiervoor gekozen zou worden. Een beoordeling van de eigenlijke inhoud zelf van deze AIM informatiestroom valt buiten het bereik van deze scriptie. Hiervoor kan in feite enkel verwezen worden naar een eerder voorbarige onderverdeling en invulling van deze ‘ontwerpinformatie’ in § 10.2.1.

10.5.1. AIM kader Voor de informatiestroom binnen het ICT kader zelf, wordt voor de IFC datastructuur gekozen (figuur 10.7). De reden daarvoor werd reeds toegelicht in § 10.2.2. Dit is in feite terug te brengen op het nastreven van een zo hoog mogelijke interoperabiliteit naar de ICT systemen die gebruik zullen maken van de informatiestructuur van dit AIM kader.

10

Figuur 10.7.: Centrale informatiestroom in het Architectural Information Modelling kader.

HOOFDSTUK 10. AIM BENADERING

264

10.5.2. AIM kader - ICT componenten Bovenop deze centrale AIM informatiestroom dient in de voorgestelde benadering een tweede laag van informatiestromen te komen (figuur 10.8) naar de verschillende ICT componenten die hierop ge¨ent zijn in § 10.4.2. Hier wordt in de eerste plaats gedoeld op de componenten Architectural Memory, Virtual Simulation & Calculation en Building Information Modelling. Omwille van het specifieke karakter van de component Virtual Reality - Visual Simulation (VR-SIM), wordt dit namelijk apart beschouwd in § 10.5.3. In de uitwerking van deze ‘zijstromen’ naar deze drie ICT componenten, wordt vooral rekening gehouden met de mogelijkheden naar interoperabiliteit met het onderliggende AIM kader en met de benaderde aard van de doorgegeven informatie. Dit wordt niet voorgesteld als een beslissende invulling, maar als een benaderende invulling die een voorlopig idee kan geven van enkele voordelen die de AIM benadering zou kunnen verzorgen. Op het moment dat het aspect ‘ontwerpinformatie’ uit § 10.2.1 met een meer wetenschappelijke basis ingevuld is, zouden deze drie zijstromen geherevalueerd moeten worden.

10 Figuur 10.8.: ‘Zijstromen’ naar en van de gekoppelde ICT componenten AM, V-CALC en BIM.

HOOFDSTUK 10. AIM BENADERING

265

Architectural Memory - (AM) Bestaande Architectural Memory applicaties vatten de Architectural Memory informatie doorgaans in digitale archieven (§ 4.5 - § 10.4.2), waarbij een uitgebreide verzameling aan beschrijvende metadata en aan data kan ingevoerd worden voor de verschillende Digital Items in dit digitaal archief. Volgens § 10.4.2 wordt binnen deze digitale archieven nagenoeg voortdurend een tweeledig doel nagestreefd. Enerzijds wordt volgens § 10.4.2 getracht om het digitaal archief continu te laten uitbreiden met nieuwe cases en met nieuwe data over bestaande cases en anderzijds wordt getracht om in deze archieven zo gericht mogelijke zoekacties mogelijk te maken, op maat van de vraagstelling van de architect. In § 4.5 werden hier reeds volgende pijnpunten gesitueerd. • terugvinden van informatie via CBR Er wordt met betrekking tot bestaande digitale archieven in de architectuur eveneens gesteld dat het moeilijkheden geeft om de juiste cases voor de architect terug te vinden. Hoewel hier reeds door middel van Case-Based Reasoning een aanzet werd gegeven om dit op te lossen, zouden nog andere elementen kunnen aangedragen worden, waarom het terugvinden van juiste informatie niet vlot genoeg zou kunnen verlopen. • uitbreidbaarheid Er wordt door bestaande digitale archieven een vorm van free-ridership vastgesteld. Dit wil zeggen dat architecten wel neigen gebruik te maken van het Architectural Memory, maar dat ze minder geneigd zijn om het Architectural Memory zelf ook te voeden met nieuwe cases en met nieuwe kennis over bestaande cases.

In de AIM benadering wordt voorgesteld om, met betrekking op het eerste pijnpunt (terugvinden van informatie), de informatie die in het digitale archief opgeslagen is, uit te breiden met meer specifieke ‘ontwerpinformatie’. Er is namelijk in § 4.5 gebleken dat bestaande digitale archieven zich vooral lijken te concentreren op ruim benaderende ‘categoriserende’ informatie, die in feite van beduidend minder nut is in de voorontwerpfase, dan gedetailleerde informatie van een impliciet, tacit en kwalitatief karakter. Aangezien getracht wordt in de voorgestelde AIM benadering om vooral deze ‘ontwerpinformatie’ te expliciteren in het Architectural Information Model, zou deze informatie dus net zo goed gebruikt kunnen worden om de koppeling met een Architectural Memory te verbeteren. Daarom wordt voor de conceptie van deze informatiestroom voorgesteld om de data en metadata van deze digitale archieven meer af te stemmen op de eigenlijke ontwerpinformatie die in het opgebouwd driedimensionaal informatiemodel ge¨expliciteerd zou opgeslagen zijn.

10

HOOFDSTUK 10. AIM BENADERING

266

Hoe deze ontwerpinformatie specifiek ingevuld wordt, dient nog verder onderzocht te worden(§ 10.2.1), maar er wordt in deze scriptie aangenomen dat de bestaande metadatatechnieken (via een URI Resolver en een OAI-PMH Federator ) en eventueel ook de bestaande technieken rond Case-Based Reasoning zouden moeten volstaan om deze digitale archieven rechtstreeks te kunnen koppelen aan de IFC datastructuur van het Architectural Information Model. Daarom wordt in het voorlopig voorgestelde AIM stromingsschema (§ 10.8) voorgesteld om enkel een IFC dataformaat van het Architectural Information Model beschikbaar te maken van dit Architectural Memory. Door dit op deze manier te doen, zou in feite ook een oplossing kunnen uitgewerkt worden aan het probleem van free-ridership, dat hierboven gegeven werd. Bij het gebruiken van het AIM kader, zal een ontwerper namelijk steeds zijn eigen ontwerpinformatie beschikbaar stellen, juist om op zoek te gaan naar relevante, voorgaande cases. Hiervoor wordt een IFC dataformaat aangereikt waarmee het Architectural Memory in feite in staat zou moeten zijn om de relevante cases voor deze ontwerpinformatie terug te vinden, maar zou het deze informatie net zo goed onmiddellijk kunnen opslaan in de bestaande case-base van het Architectural Memory. Op die manier zou de case-base doorlopend gevoed worden met nieuwe informatie over de wijze waarop ontwerpen uitgewerkt zijn, waardoor het probleem van free-ridership wellicht opgelost zou kunnen worden. Indien dit uitgewerkt zou worden, dan dient evenwel goed rekening gehouden te worden met onderwerpen als ‘privacy’ en ‘intellectuele eigendom’. Virtual Simulation & Calculation - (V-CALC) Vanuit het AIM ontwerpmodel dienen de juiste data ge¨exporteerd en ge¨ımporteerd te worden in functie van de analyse die uitgevoerd moet worden. Zo verschilt de benodigde informatie voor een kostenanalyse in Trelligence Affinity (§ 6.4.1) bijvoorbeeld van de benodigde informatie voor een energiesimulatie in UG-EPW (§ 6.2.2) of voor een lichtanalyse in Ecotect (§ 6.3.1). Op basis van de evoluties naar interoperabiliteit die merkbaar zijn in de ontwikkeling van de bestaande ICT applicaties voor simulatie en calculatie (§ 8.5), wordt in deze scriptie aangenomen dat de IFC datastructuur waarop de AIM benadering gebaseerd wordt, een voldoende solide basis kan bieden voor de uitwisseling van informatie tussen het Architectural Information Model en de ICT applicaties die onder de V-CALC component vallen. Het merendeel van de ICT applicaties onder deze component blijken namelijk op dit moment herwerkt te worden om de IFC datastandaard in te kunnen lezen en een simulatie of berekening op basis van deze informatie uit te voeren. Op het moment dat echter ook meer ge¨expliciteerde ontwerpinformatie (§ 10.2.1) ter be-

10

HOOFDSTUK 10. AIM BENADERING

267

schikking zou zijn in het AIM ontwerpmodel, zou deze werkwijze via IFC geherevalueerd moeten worden. Aangezien de eigenlijke inhoud van deze ontwerpinformatie nog niet concreet vastgelegd is, kan er namelijk niet zomaar van uitgegaan worden dat een ICT applicatie onder V-CALC deze informatie zonder problemen kan inladen via het IFC dataformaat. Na herevaluatie van deze informatiestroom zou, door de koppeling van V-CALC aan het AIM kader, mogelijk gemaakt kunnen worden om analyses en evaluaties uit te voeren naar zowel expliciete als impliciete ontwerpcriteria en design requirements (Kiviniemi, 2005). Zo zou net zo goed een analyse naar de energieprestaties van het voorlopig samengestelde AIM model kunnen ge¨evalueerd worden, als een simulatie van de mate waarin een ontwerp voldoet aan minimale comforteisen voor dat specifiek ontwerp. Het voornaamste voordeel dat de AIM benadering lijkt te bieden voor de ICT component V-CALC, is dat alle benodigde data centraal opgebouwd wordt in het AIM databestand, waardoor simulatie en calculatie volledig geautomatiseerd hieraan zou kunnen gekoppeld worden. Net zoals bij BIM kan dit ervoor zorgen dat informatie niet meer handmatig gedefinieerd dient te worden in de diverse softwarepakketten onder de component V-CALC, maar dat dit real-time ge¨extraheerd en automatisch verwerkt kan gebeuren. Het AIM ontwerpmodel zou dus in feite continu ‘geherevalueerd’ kunnen worden en via een grafische interface VR-SIM voorgesteld kunnen worden aan de ontwerper, zodat deze ten allen tijde de geboden resultaten kan interpreteren en het ontwerp hiernaar zou kunnen bijsturen. Building Information Modelling - (BIM) Er werd reeds voorgesteld om voor het ontwerpaspect decision-making de Building Information Modelling component te koppelen aan het reeds voorziene AIM kader. Op basis van de stapsgewijs ingevoerde informatie in het AIM ontwerpmodel (§ 10.2.1), zouden in de ontwerpfase reeds benaderende aannames gedaan worden omtrent de opbouw van een componentengebaseerd BIM uitvoeringsmodel. Naarmate het voorontwerp meer concreter vorm krijgt, zal dan ook de benaderende BIM steeds concreter en juister worden, totdat aan het eind van het voorontwerp de concentratie zou kunnen verlegd worden naar de uitwerking van het BIM informatiemodel zelf. Wat de eigenlijke informatiestroom tussen dit AIM kader en de BIM component betreft, wordt voorgesteld om binnen deze benadering een AIM modus en een BIM modus te voorzien. Het verschil in deze twee modi zou zitten in het type van informatie dat aangepast wordt (impliciete ‘ontwerpinformatie’ of eerder expliciete, ‘componentengebaseerde’ informatie). Dit zou ervoor zorgen dat in de AIM -modus eerder aanpassingen (of dus beslissingen) gemaakt kunnen worden die te maken hebben met de uitwerking van het conceptueel voorontwerp, terwijl anderzijds in de BIM -modus eerder aanpassingen of beslissingen gemaakt kunnen worden met betrekking op aspecten naar materialiteit en uitvoerbaarheid van het

10

HOOFDSTUK 10. AIM BENADERING

268

ontwerp. Het zou hierbij niet de bedoeling zijn dat een volledig correct BIM uitvoeringsmodel wordt uitgewerkt binnen het AIM framework. Wel zou reeds een summier BIM model aangemaakt dat een eerste aanzet kan vormen voor een verdere uitwerking in meer gespecialiseerde BIM pakketten. Zowel het AIM ontwerpmodel als het BIM uitvoeringsmodel worden van in de ontwerpfase aangemaakt in de IFC datastructuur en kunnen elk afzonderlijk aangepast worden in de twee modi van het AIM framework, de AIM modus en de BIM modus. Op het moment dat het voorontwerp goedgekeurd wordt door de bouwheer, zou het AIM framework verlaten moeten worden als basisplatform en moet overgestapt worden naar meer BIM gerichte applicaties, zoals Autodesk Revit, Nemetschek Allplan en ArchiCAD of Bentley Microstation. Voor aanpassingen van conceptuele aard kan dan nog steeds het bijhorende AIM ontwerpmodel geopend worden, waarna het BIM uitvoeringsmodel opnieuw geupdate wordt hiernaar. Het verlies van informatie in dit update-proces kan beperkt worden door het gebruik van de GUID of Globally Unique Identifier. Door AIM en BIM op dezelfde IFC informatiestructuur te baseren, maar beiden wel te laten werken met hun eigen specifieke informatie (ontwerpinformatie tegenover componentengebaseerde informatie), zouden voorontwerp en uitwerking op een effici¨ente manier onderling kunnen gerelateerd worden binnen een computergestuurde ontwerpomgeving en dus simultaan ontwikkeld kunnen worden tot een volwaardig ontwerp. Aangezien aan elk element binnen IFC een GUID (Global Unique Identifier) toegekend wordt, zou bovendien in een ver gevorderd stadium binnen het BIM uitvoeringsmodel teruggekeerd kunnen worden naar het AIM ontwerpmodel om ontwerpmatige aanpassingen door te voeren, zonder dat reeds uitgewerkte BIM uitvoeringsinformatie verloren gaat.

10.5.3. AIM kader - VR-SIM interface In de voorgestelde AIM benadering wordt gesteld dat een uitgebreide VR-SIM functionaliteit voor visualisatie dient voorzien te worden. De VR-SIM component wordt hierin beschouwd als een complementair medium voor pen en papier, zodat met deze twee media een geoptimaliseerde communicatie van algemene concepten, ontwerpidee¨een, driedimensionale werkingsschema’s, invloedsfactoren voor beslissingen, . . . ´en de eigenlijke informatie zelf achter deze elementen mogelijk zou kunnen gemaakt worden. Indien de VR-SIM component op de juiste manier geschakeld wordt op het centrale AIM kader en op de ICT componenten AM, V-CALC en BIM, en indien tussen deze elementen bovendien een gepaste informatiestroom kan bewerkstelligd worden, dan zou dit wellicht kunnen uitgewerkt worden met een maximum aan interpretatiemogelijkheden voor het ontwerpproces. Binnen deze scriptie werd voor het eerste van deze twee elementen, een correcte koppeling

10

HOOFDSTUK 10. AIM BENADERING

269

van VR-SIM in het globale AIM kader, reeds gesteld dat de VR-SIM component zou moeten uitgewerkt worden als een overkoepelende component bovenop het AIM kader ´en zijn drie overige componenten, zodat informatie uit al deze domeinen kan gevisualiseerd worden. Bij de uitwerking van een gepaste informatiestroom in dit schema, kan echter gesteld worden dat veel zal afhangen van de manier waarop de informatie in het AIM informatiemodel gestructureerd is. Gezien de grote verscheidenheid aan informatie (AM - V-CALC - BIM ) lijkt heel wat af te hangen van de manieren waarop de VR-SIM component in staat is om gestructureerd om te gaan met een IFC dataset en tegelijk een intensieve verbinding mogelijk maakt met het Architectural Memory (AM), met Virtual Simulation & Calculation (V-CALC) en met Building Information Modelling (BIM). Bovendien dient ook de gebruikersinterface zelf zo eenvoudig en intu¨ıtief mogelijk gehouden te worden, waarbij gestreefd wordt naar een minimalisatie van de hoeveelheid input met tegelijk een maximale, overeenkomstige output. Om aan deze verschillende eisen te voldoen, wordt binnen deze scriptie enkel voorgesteld om de IFC datastructuur van het Architectural Information Model en van het benaderende Building Information Model uit de BIM modus beschikbaar te maken voor de VR-SIM component. Deze IFC datastructuren bevatten namelijk nagenoeg alle informatie die over het ontwerp kan gevonden worden. Voor de verdere realisatie van deze component zou echter verder onderzoek uit moeten wijzen welke technieken aangewezen zijn om de heel uiteenlopende soorten informatie uit deze IFC datastructuur om te zetten naar een formaat dat door het Virtual Reality systeem gebruikt wordt.

10.5.4. ICT component - ICT component Tot slot wordt in deze AIM benadering een aanzet voorgesteld voor een eventuele informatiestroom tussen de verschillende ICT componenten zelf. Dit wordt als een aparte, secundaire ICT stroom beschouwd, die evenwel nog steeds binnen het voorgestelde Architectural Information Modelling kader gebeurt (figuur 10.9). Omwille van de nog weinig concrete invulling van de inhoud van de eigenlijke informatiestroom (§ 10.2.1), blijft de invulling van deze secundaire stroom bij een vroege benadering. Enkele voorbeelden worden hieronder ter illustratie gegeven van wat via deze secundaire informatiestroom beoogd zou kunnen worden. Dit is niet volledig, maar het kan wellicht een benaderend beeld geven van de aard van deze secundaire informatiestroom. • Doorgeven van meer technische informatie uit het Architectural Memory naar de Building Information Modelling component, zodat deze laatste, op basis daarvan en op basis van de informatie die gegeven wordt in AIM modus, bijvoorbeeld aannames kan maken over de wellicht te gebruiken componenten in BIM modus

10

HOOFDSTUK 10. AIM BENADERING

270

Figuur 10.9.: Secundaire informatiestromen tussen de ICT componenenten zelf.

• Doorgeven van componentengebaseerde informatie uit de BIM component aan de VCALC component om hier eventueel meer precieze calculaties en simulaties in uit te kunnen voeren • Doorgeven van resultaten uit de V-CALC component, bijvoorbeeld het resultaat van een uitgevoerde evaluatie naar de mate waarin het ontwerp voldoet aan impliciete en expliciete design requirements, aan de AM component, om hier bijvoorbeeld op zoek te kunnen gaan naar cases met een gelijkenis in de per case opgeslagen V-CALC resultaten. • ...

Deze drie soorten AIM informatiestromen zouden uiteindelijk resulteren in het conceptueel stromingsschema dat voorgesteld wordt in figuur 10.10.

10

HOOFDSTUK 10. AIM BENADERING

271

10 Figuur 10.10.: Volledig voorgesteld AIM stromingsschema.

11 AIM testcase

E

EN uit te voeren AIM testcase wordt voorgesteld binnen deze scriptie, met als doel het beoordelen van de inhoud die gegeven zou kunnen worden aan de term ‘ontwerpinformatie’ of ‘Architectural Information’ binnen de AIM benadering. Deze testcase is niet bedoeld om een volledig werkende ontwerpomgeving samen te stellen, maar probeert vooral om de verschillende problemen te situeren die in de aanmaak van een AIM ontwerpomgeving onvermijdelijk aan bod zullen komen, meer bepaald in verband met het type informatie dat gemodelleerd kan worden in deze benadering en dus van cruciaal belang is voor een goede functionaliteit van deze benadering binnen de voorontwerpfase.

11.1. Probleemstelling In de voorstelling van de AIM benadering (§ 10.4) werd reeds een aanzet gegeven waarin getracht werd om ter illustratie een concrete AIM informatiestroom uit te werken. In deze informatiestroom werd getracht om een zo hoog mogelijke graad aan interoperabiliteit te verkrijgen tussen de verschillende ICT componenten en het AIM kader, zodat een zo uitgebreid mogelijke verzameling aan gebruiksmiddelen ter beschikking van de ontwerper gesteld kon worden. Er werd hierbij aangenomen dat via het IFC bestandsformaat een zodanige interoperabiliteit zou bereikt kunnen worden, dat de uitwerking van deze informatiestroom hier niet door beperkt wordt. Het tweede aspect van de Architectural Information Modelling benadering, ‘ontwerpinfor-

272

HOOFDSTUK 11. AIM TESTCASE

273

matie’ of ‘Architectural Information’, bleek in de uiteenzetting van de voorgestelde informatiestroom (§ 10.5) een belangrijker hindernis te vormen voor de mogelijke uitwerking van een concreter AIM kader. Vooral in de laatste laag van de informatiestroom (§ 10.5.4), waar ontwerpinformatie doorgegeven wordt op een secundair niveau tussen de verschillende ICT componenten onderling, bleek moeilijk concreet ingevuld te kunnen worden zonder een duidelijke beschrijving van wat deze ‘ontwerpinformatie’ effectief inhoudt. Dit kan worden ge¨ıllustreerd aan de hand van de functionaliteit die in deze secundaire informatiestroom voorgesteld werd van de Architectural Memory component naar de Building Information Modelling component. “Doorgeven van meer technische informatie uit het Architectural Memory naar de Building Information Modelling component, zodat deze laatste, op basis daarvan en op basis van de informatie die gegeven wordt in AIM modus, bijvoorbeeld aannames kan maken over de wellicht te gebruiken componenten in BIM modus” In dit voorbeeld kan nog niet duidelijk vastgelegd worden welke informatie nodig is om dit uit te voeren. Er wordt bijvoorbeeld wel aangehaald dat ‘technische informatie’ doorgegeven wordt, op basis van de ‘ontwerpinformatie’ die via het AIM ontwerpmodel doorgegeven wordt. Het is echter niet concreet duidelijk welke informatie hier effectief voor nodig is, welke informatie hier een rol in kan spelen en dan effectief bepaald wordt welke technische informatie doorgegeven moet worden naar de BIM component. Hierin wordt zelfs nog niet ingegaan op de verschillende mogelijke manieren waarop deze BIM component dit vervolgens kan interpreteren om een benaderende aanname te doen in de opbouw van een voorlopig Building Information Model. Binnen deze thesis wordt mogelijk verder onderzoek dan ook voornamelijk op dit aspect van de AIM benadering gericht. Het is niet de bedoeling om dit binnen deze thesis concreter uit te werken of om hier reeds een bepaalde aanname in te doen (behalve de aanname omtrent het impliciet / expliciet karakter van deze informatie in § 10.2.1). Wel wordt getracht om een aanzet te geven voor hoe dit zou kunnen uitgewerkt worden. Concreet wordt een illustrerende, uit te voeren testcase voorgesteld, die meer duidelijkheid kan brengen in de aard van het probleem en de wijze waarop dit opgelost kan worden. Deze illustrerende testcase beperkt de probleemstelling bewust tot de ‘ontwerpinformatie’ die van belang kan zijn in de informatiestroom tussen het Architectural Memory en het AIM kader. De informatiestroom tussen de andere componenten van de AIM benadering maakt wellicht gebruik van hetzelfde soort informatie en zou dus tijdelijk buiten beschouwing gelaten kunnen worden. In een latere fase dienen de resultaten van de Architectural Memory testcase wel hiernaar bijgewerkt te worden.

11

HOOFDSTUK 11. AIM TESTCASE

274

11.2. Benadering van het probleem Bij de benadering van de Architectural Memory testcase zou worden aangenomen dat het AIM kader reeds aanwezig is en beschikbaar is in de vorm van een virtuele ontwerpomgeving. Op die manier kan concreet onderzoek uitgevoerd worden naar de eigenlijke aard van de informatie uit het Architectural Memory die in deze ontwerpomgeving gebruikt kan worden door de ontwerper. Het doel van het Architectural Memory werd reeds opeenvolgend uitgewerkt via § 3.2.2 en § 4 tot hoe het uiteindelijk voorgesteld is binnen het AIM kader in § 10.5.2. Kort samengevat wordt van het Architectural Memory de volgende functionaliteit verwacht. In het Architectural Memory wordt verder ingegaan op de vaststelling dat, wanneer een ontwerp gestart of aangepast wordt, dit doorgaans vertrekt vanuit algemene, architecturale kennis of ervaringen die beleefd zijn door de ontwerper zelf of door andere ontwerpers voordien (Heylighen en Neuckermans, 2000a). In de context van bestaande computertechnologie kan dit ge¨ınterpreteerd worden als de kennisverzamelingen op het vlak van architectuur die in dit geval digitaal toegankelijk zijn. Binnen bestaande benaderingen wordt dit vooral ingevuld met digitale archieven die de architect of de ontwerper een zo groot mogelijke informatiebron trachten te geven (§ 4.5) binnen de ontwerpfase. Via deze informatiebron wordt getracht om het referentiekader dat door de architect gebruikt wordt om nieuwe ontwerpoplossingen te genereren, in de eerste plaats te doen vergroten en in de tweede plaats doelgerichter te doen werken (§ 10.4.2). Indien dit toegepast wordt op een concreet voorbeeld, dan zou bijvoorbeeld aangenomen kunnen worden dat, op het moment dat de ontwerper een bepaald ontwerp aan het uitwerken is, bijvoorbeeld een schoolgebouw, relevante ‘architecturale kennis’ opgezocht wordt in dit Architectural Memory, zodat de ontwerper deze informatie kan gebruiken om zijn eigen ontwerp verder uit te werken. Een bepaald soort kennis die hij zou kunnen gebruiken, wordt gegeven door het boek “Architect’s Data” van architecten Ernst en Peter Neufert (Neufert en Neufert, 2002). Dit boek is bedoeld als handleiding of vademecum voor de architect en bevat geometrische en functionele ontwerpregels om tot een bepaald ontwerp te komen (Neufert en Neufert, 2002). In schaalgrootte zou dit boek binnen het Architectural Memory beschouwd kunnen worden als ´e´en van de vele Digital Items in het digitaal Architectural Memory archief (§ 4.4). Het illustreert echter wel goed ´e´en van de wijzen waarop het Architectural Memory zou kunnen werken. Tijdens het uitwerken van de verschillende elementen van het schoolgebouw, zou het Architectural Memory namelijk automatisch op zoek kunnen gaan naar gerelateerde functionele

11

HOOFDSTUK 11. AIM TESTCASE

275

en geometrische ontwerpregels in dit boek, om vervolgens deze informatie aan de ontwerper door te geven, zodat hij dit kan interpreteren en eventueel kan verwerken in zijn ontwerp. Wanneer in het Architectural Information Model bijvoorbeeld blijkt dat de architect een gang of een nooduitgang conceptueel aan het verwerken is in het ontwerp, dan zou het Architectural Memory kunnen zoeken naar ontwerpregels die een minimum aangeven voor de breedte van de gang, of naar ontwerpregels die de minimale loopafstand van een klaslokaal naar een nooduitgang beschrijven. Binnen deze scriptie werd getracht om dit illustrerend uit te werken met als onderwerp ‘het schoolgebouw’.

11.3. Experimentele testcase In 2006 werd een publicatie uitgegeven door de Vakgroep Architectuur en Stedenbouw (VA&S) van de Universiteit Gent, namelijk “De school als ontwerpopgave - schoolarchitectuur in 1995 - 2005” (Van Den Driessche en Verschaffel, 2006). Hierin worden vijftien schoolprojecten uit de periode 1995 - 2005 geanalyseerd en op basis van bepaalde criteria naast elkaar gelegd en vergeleken (Van Den Driessche en Verschaffel, 2006). Elk schoolproject in het boek wordt hiervoor onder andere gedocumenteerd aan de hand van een fiche met enkele objectieve en concrete data. In deze fiche wordt informatie over het schoolproject opgenomen zoals de uiteindelijke kostprijs, het aantal klassen, de verschillende deeloppervlaktes van het schoolproject, enzovoort. Binnen het kader van deze thesis werd ´e´en van deze schoolprojecten uitgekozen, namelijk het schoolproject van architectenbureau Macken & Macken in Grimbergen (Van Den Driessche en Verschaffel, 2006), om deze om te zetten in een voorlopige benadering van een Architectural Information Model. Aangezien er geen applicatie voor handen is die het enigszins mogelijk maakt om de informatie die beoogd wordt in de AIM benadering, te modelleren tot een driedimensionaal informatiemodel, werd dit eveneens binnen deze voorbereidende testcase uitgewerkt. Dit werd ontwikkelde aan de hand van het .NET applicatieframework en door middel van de C# programmeertaal. Het resultaat hiervan is geen grafische modelleeromgeving, maar een tekstuele interface waarin bepaalde informatie kan ingegeven worden door de gebruiker over hoe het ontwerp zou uitgewerkt moeten worden. Er wordt binnen deze scriptie verwezen naar de werkmethode die ook in de ontwikkeling van de applicatie AMCE gebruikt werd (§ 6.4.2). Hierin werd namelijk eveneens in een eerste stap een tekstuele interface ontwikkeld waarin een deel van de functionaliteit eerder illustratief ge¨ımplementeerd werd, waarna in een latere stap overgeschakeld werd op een driedimensionale schetsomgeving (EsQUIsE ) om de informatie in deze AMCE applicatie te voorzien. Er werd dus getracht om binnen deze scriptie een experimentele, tekstuele interface te ontwikkelen, die de methodiek kan illustreren, maar die

11

HOOFDSTUK 11. AIM TESTCASE

276

voor zijn volle functionaliteit wel zou beschouwd moeten worden met een driedimensionale ontwerpomgeving.

11.3.1. Experimentele, tekstuele interface In de tekstuele interface van dit experimenteel AIM kader worden drie tabbladen gegeven (figuur 11.1). In elk van deze tabbladen kan telkens een bepaald deel van de informatie, waaraan het uiteindelijk uit te werken AIM model aan zou moeten voldoen (ontwerpinformatie), gespecifieerd worden. Dit wordt onderverdeeld onder de benamingen ‘Architectural Memory - opdrachtmetadata’, ‘Architectural Memory - resultaatmetadata’ en ‘Architectural Conscience’. In deze experimentele testcase werd de in te geven informatie per tabblad beperkt tot de volgende structuur, waarbij teruggevallen werd op de structuur van de fiches in Van Den Driessche en Verschaffel (2006). • Architectural Memory - opdrachtmetadata 1. opdrachtgever 2. architect 3. project 4. programma 5. omgeving • Architectural Memory - resultaatmetadata 1. stabiliteit 2. technieken 3. projectregie 4. project 5. programma 6. ontwerp 7. informatiemodel • Architectural Conscience 1. VIN ontwerpregels 2. stedenbouwkundige regels

Binnen deze tekstuele interface wordt de volgende informatie ingevoerd. In het eerste tabblad komt informatie over de eigenlijke opdracht aan de basis van het ontwerp. Dit wordt

11

HOOFDSTUK 11. AIM TESTCASE

277

Figuur 11.1.: Drie tabbladen werden voorzien om telkens informatie tekstueel te kunnen specifi¨eren over het beoogde ontwerp (experimenteel AIM model).

onderverdeeld in vijf aspecten: opdrachtgever - architect - project - programma - omgeving. Onder de categorie¨en ‘opdrachtgever’ en ‘architect’ worden de gegevens en contactdetails van de opdrachtgever en van de architect voor het uit te tekenen ontwerp ingevoerd. Onder de categorie ‘project’ wordt algemene informatie ingevoerd over het uit te voeren project. Zo wordt een naam en een doorgegeven, een digitaal adres inclusief referenties naar een locatie op Google Earth en GIS data, maar ook meer ontwerpgerichte data zoals een vooropgesteld budget, een gevraagde totale oppervlakte en het gebruiksdoel van het gebouw (figuur 11.2). Onder de categorie ‘programma’ wordt informatie ingevoerd over het in de opdracht gevraagde programma. Hieronder kan gekozen worden welke ruimtes nodig zijn, met daarbij telkens nog enkele aanwijzingen betreffende de gevraagde vorm en plaats van die ruimtes (figuur 11.3). Daarnaast zou ook kunnen worden aangeduid in welk typologisch patroon de gevraagde ruimtes moeten geplaatst worden. Dit laatste werd evenwel nog niet verder uitgewerkt in deze testcase. Per ruimte kan de hieronder volgende informatie doorgegeven worden. 1. functionele eenheid • klas kleuter • klas lager • klas middelbaar • klas hoger • polyvalente zaal • sportzaal • administratie • toiletten 2. aantal

11

HOOFDSTUK 11. AIM TESTCASE

278

Figuur 11.2.: Overzicht van de ‘projectinformatie’ die in de ontwikkelde applicatie ingevoerd kan worden.

11

HOOFDSTUK 11. AIM TESTCASE

279

Figuur 11.3.: Overzicht van de ‘programma-informatie’ die in de ontwikkelde applicatie ingevoerd kan worden. De weergegeven informatie hoort bij het schoolproject van architectenbureau Macken & Macken in Grimbergen (Van Den Driessche en Verschaffel, 2006).

11

HOOFDSTUK 11. AIM TESTCASE

280

3. level • niveau -1 • niveau 0 • niveau +1 • niveau +2 4. vorm • polygoon extrusie • blend1 • sweep • revolve 5. aantal zijden

Tot slot werd in het eerste tabblad ook de mogelijkheid voorzien om informatie door te geven over de categorie ‘omgeving’. In dit deel zou informatie kunnen ingegeven worden over de stedelijke of landschappelijke context van het gebouw en over de gevraagde aanpassingen in het terrein. Dit werd evenwel nog niet verder uitgewerkt in deze testcase. Via deze vijf categorie¨en werd getracht om een bepaalde set aan ‘ontwerpinformatie’, namelijk de informatie die gegeven is bij de start van het ontwerp (design requirements), door te geven aan een tekstuele interface. Er wordt binnen deze scriptie verondersteld dat deze informatie in een uitgewerkt AIM kader grafisch kan gemodelleerd worden en dus in feite slechts een heel klein onderdeel is van het pakket aan ‘ontwerpinformatie’. Een tweede en een derde pakket aan ‘ontwerpinformatie’ werd eveneens voorzien op de overige twee tabbladen, ‘Architectural Memory - resultaatmetadata’ en ‘Architectural Conscience’. In deze twee tabbladen zou in deze experimentele testcase eveneens ‘ontwerpinformatie’ doorgegeven kunnen worden, die vervolgens gebruikt wordt om een eerste Architectural Information Model aan te maken. Onder het tabblad ‘Architectural Memory - resultaatmetadata’ zou informatie ingevoerd kunnen worden over hoe het uiteindelijke voorontwerp afgeleverd werd. Dit werd echter niet verder uitgewerkt en wordt dus verder buiten beschouwing gelaten. Het tabblad ‘Architectural Conscience’ zou tot slot informatie bevatten over ‘ontwerpregels’ die gevolgd werden in de uitwerking van het eerste AIM model.

1

De functionaliteiten ‘blend’, ‘sweep’ en ‘revolve’ werden voorzien, maar nog niet verder uitgewerkt.

11

HOOFDSTUK 11. AIM TESTCASE

281

11.3.2. Virtual Interactive Neufert (VIN) Invoer van informatie Zoals te zien is in figuur 11.4, bevat het tabblad ‘Architectural Conscience’ twee soorten informatie, die benoemd worden met ‘VIN ontwerpregels’ en ‘stedenbouwkundige regels’. Binnen deze experimentele testcase zou het de bedoeling zijn dat onder elk van deze twee noemers gespecifieerd kan worden door een ontwerper welke ‘ontwerpregels’ hij zou willen volgen in de uitwerking van het ontwerp. Dit werd in deze scriptie enkel uitgewerkt voor de noemer ‘VIN ontwerpregels’. Tot op dit punt van de experimentele testcase werd enkel getracht om een tekstuele interface samen te stellen die zou kunnen ge¨ınterpreteerd worden als een voorlopige vervanger voor een onbeschikbare, grafische modelleeromgeving. Door het invoeren van informatie in deze interface zou een virtueel informatiemodel opgebouwd worden met meer ‘ontwerpmatige’ informatie, en minder expliciet bouwtechnische informatie (BIM ). Deze experimentele testcase werd echter wel bedoeld om de informatiestroom naar het Architectural Memory meer te concretiseren. Dit werd onder dit derde tabblad ‘Architectural Conscience’ uitgewerkt als een ‘Virtuele Interactieve Neufert’ (figuur 11.4). In het derde tabblad kunnen onder ‘VIN ontwerpregels’ twee soorten informatie doorgegeven worden. In de eerste plaats wordt een bepaald architecturaal ‘ontwerppatroon’ gekozen. In deze testcase kan bijvoorbeeld gekozen worden voor het ontwerppatroon ‘appartementsgebouw’, ‘kerk, ‘rijwoning’ of ‘school’. In de tweede plaats kan onder dit ontwerppatroon een ‘graad’ gekozen worden. In deze testcase wordt een keuze aangeboden tussen ‘graad 1 - minimum’, ‘graad 2 - normaal’ of ‘graad 3 - comfort’ (figuur 11.4). Deze graden komen overeen met bepaalde comfortniveaus die ook in Neufert en Neufert (2002) zouden kunnen voorkomen. Zo zou een mogelijk element ‘gang’ in graad 3 breder kunnen zijn dan in graad 1 of 2, telkens overeenkomstig met Neufert en Neufert (2002). Wanneer bijvoorbeeld gekozen wordt om aan het experimenteel uitgewerkte AIM model de informatie ‘school’ en ‘graad 2 - normaal’ te koppelen, wordt in principe in feite enkel tekstuele ontwerpinformatie gekoppeld aan het informatiemodel, vergelijkbaar met wat gebeurt onder de eerste twee tabbladen van de applicatie. Deze informatie zou, volgens de AIM benadering, echter gebruikt kunnen worden om relevante informatie op te zoeken en toegankelijk te maken in het conceptueel AIM kader. Er zou aan de hand van deze informatie met andere woorden een informatiestroom kunnen opgestart worden tussen het voorlopig opgebouwde Architectural Information Model (hierboven) en het Architectural Memory. Hoe dit in zijn werk kan gaan en wat hiermee bereikt zou kunnen worden, wordt hieronder ge¨ıllustreerd onder de uitwerking van de Virtuele Interactieve Neufert.

11

HOOFDSTUK 11. AIM TESTCASE

282

Figuur 11.4.: De VIN ontwerpregels worden in twee stappen gekozen op het derde tabblad: ‘ontwerppatroon’ en ‘graad’.

11

HOOFDSTUK 11. AIM TESTCASE

283

Uitwerking VIN Aangezien het binnen deze scriptie niet mogelijk was om een uitgebreid digitaal archief te ontwikkelen om dienst te doen als illustratief Architectural Memory, werd geopteerd om via een zo flexibel mogelijk medium een alternatief Architectural Memory aan te maken. Binnen deze experimentele testcase werd dit alternatief Architectural Memory benaderd met ´e´en XML databestand. Dit staat in sterk contrast met de uitgebreide digitale archieven die aangewend kunnen worden, maar bij een evaluatie van de eigenlijke informatiestroom zelf werd dit binnen deze scriptie wel representatief geacht. In een uitgebreidere testcase zou geopteerd kunnen worden voor uitgebreide databasesystemen of andere, meer geschikte dataformaten. Dit viel echter buiten het bereik van deze scriptie.

Figuur 11.5.: Het XML bestand van de Virtuele Interactieve Neufert. Voor het ontwerppatroon ‘school’ met ‘graad 1 - minimum’ is voor elke ruimte beschreven welke oppervlakte en hoogte deze zou moeten hebben en is voor elke niveau aangeduid op welke hoogte dit niveau zich bevindt.

Het XML databestand werd afzonderlijk aangemaakt en lokaal opgeslagen. Vervolgens werd het via het .NET framework aan de applicatie gekoppeld, zodat het hierin gebruikt kan worden. Een gedeelte van het XML bestand dat voor het ontwerppatroon ‘school’ uitgewerkt is, wordt weergegeven in figuur 11.5. Hierin zijn overeenkomstige elementen terug te vinden met de informatie die expliciet ingegeven moeten worden in de tekstuele interface voor de

11

HOOFDSTUK 11. AIM TESTCASE

284

opbouw van een experimenteel Architectural Information Model. In de testcase gaat deze opbouw als volgt in zijn werk. In figuur 11.6 is te zien welke data op deze manier samengebracht kan worden. Dit werd voor deze testcase vooral illustrerend bedoeld en bijgevolg eerder eenvoudig gehouden. Zo wordt hier door de architect het benodigde ‘programma’ beschreven, waarna de applicatie bij het aanmaken van het AIM ontwerpmodel op zoek gaat naar de namen van de gevraagde ruimtes in het te gebruiken XML bestand van de Virtuele Neufert. Als overeenkomsten gevonden wordt, zoals de naam van de ruimte of de naam van het niveau, dan worden de te gebruiken afmetingen ingeladen en gebruikt om het driedimensionaal model op te stellen. Op dit moment wordt enkel een oppervlakte, een hoogte en een niveauhoogte ingeladen (figuur 11.6). Met deze informatie wordt vervolgens automatisch een IFC bestand aangemaakt die het overeenkomstig driedimensionaal model beschrijft. Dit gebeurt grotendeels met de IFC objecten die gerelateerd zijn aan het element ‘IFCSPACE’. Dit breekt uitdrukkelijk met de werkwijze die traditioneel gerbuikt wordt in het uittekenen van componentengebaseerde elementen in een BIM uitvoeringsmodel, waar gaan abstracte ruimtes kunnen worden gedefinieerd zonder dat eerst de omringende elementen expliciet moeten bepaald worden (§ 7.5).

Figuur 11.6.: De combinatie van de expliciete AM informatie en de impliciete AC kennis, onder andere uit de VIN, maakt het mogelijk om een correct benaderend, eerste AIM ontwerpmodel op te stellen.

Het virtueel AIM ontwerpmodel dat door het opgemaakte IFC bestand beschreven wordt, is enkel ter illustratie toegankelijk gemaakt via een eigen ontwikkelde IFC viewer. Deze IFC viewer maakt gebruik van de Open Source IFC Engine DLL van TNO (Nederlandse organisatie voor toegepast-natuurwetenschappelijk onderzoek) 2 en is zichtbaar in figuur 11.7. Conclusie Het resultaat van bovenstaande koppeling is dus, dat de ontwerper of de opdrachtgever als input enkel de verschillende nodige ruimtes moet specifi¨eren met bijhorend hun aantal, vorm 2

TNO (Nederlandse organisatie voor toegepast-natuurwetenschappelijk onderzoek) - IFC Engine DLL: http://www.ifcbrowser.com/

11

HOOFDSTUK 11. AIM TESTCASE

285

Figuur 11.7.: De uitgewerkte AIM modelviewer waarin elk aangemaakt AIM ontwerpmodel kan bekeken en doorgelicht worden. Links wordt het volledige model getoond met de verschillende ‘IFCSPACES’ ; door dubbelklikken kan elke ruimte geselecteerd worden, waarna zijn ‘IFCPROPERTIES’ rechts getoond worden ter informatie.

11

HOOFDSTUK 11. AIM TESTCASE

286

en verdiepingsniveau. Er wordt van hem bijvoorbeeld nog niet verwacht dat hij specifieke geometrische informatie ingeeft, wat regelmatig kan voorkomen in de vroegste ontwerpfase. In combinatie met een Architectural Memory echter zou wel de nodige informatie teruggevonden kunnen worden. In dit geval wordt maar ´e´en type informatie teruggevonden, aangezien er ook maar ´e´en Digital Item is, namelijk het XML bestand. In principe zou echter meer ontwerpinformatie kunnen gespecifieerd worden in de tekstuele interface, zoals bijvoorbeeld een stedenbouwkundige regelgeving. Indien deze stedenbouwkundige regelgeving vervolgens teruggevonden kan worden in het Architectural Memory, kan de verschillende relevante informatie voor het AIM model opgehaald worden uit dit Architectural Memory en gepresenteerd worden aan de ontwerper. Indien deze laatste vervolgens kiest om bijvoorbeeld enkel gebruik te maken van de VIN ontwerpregels, dan worden enkel deze regels uit het Architectural Memory ingeladen en toegepast op het op dat moment nog conceptuele voorontwerp.

11.4. Verder onderzoek 11.4.1. Situering De voorgaande experimentele testcase trachtte tot op een bepaald niveau aan te duiden hoe een informatiestroom tussen een conceptueel Architectural Memory en een conceptueel Architectural Information Modelling kader zou kunnen verlopen. Dit ging bewust in op de eigenlijke informatie die hierin wordt doorgegeven en minder op de eigenlijke informatiestroom in onderliggende databestanden, zoals vooraf gesteld werd (§ 11.2). Bij het beschouwen van de resultaten die bereikt werden in deze experimentele testcase, kan geconcludeerd worden dat uiteenlopende functionaliteiten zouden kunnen uitgewerkt worden aan de hand van de koppeling Architectural Memory - AIM kader. In de experimentele testcase werd namelijk enkel een voorbeeld uitgewerkt waarbij informatie uit een Virtuele Interactieve Neufert uit een conceptueel Architectural Memory opgeladen werd, zodat aan de hand hiervan enkele IFCSPACES uitgetekend kunnen worden. Via dezelfde werkwijze zou het in principe ook mogelijk moeten zijn om impliciete, tacit en kwalitatieve informatie terug te vinden op basis van de informatie die ingegeven werd in de overige tabbladen. De voornaamste hindernis die echter nog steeds zou kunnen gesitueerd worden, is de eigenlijke invulling van de ‘ontwerpinformatie’. Eerder werd reeds gesteld dat dit ging om impliciete, tacit en kwalitatieve informatie (§ 10.2.1), maar deze onderverdeling komt nog steeds onvoldoende expliciet naar voor in bovenstaande, experimentele testcase. Door de ontwikkeling van een Virtuele Interactieve Neufert werd dus wel mogelijk gemaakt dat impliciete ontwerpregels zouden kunnen ingeladen kunnen worden op basis van bepaalde

11

HOOFDSTUK 11. AIM TESTCASE

287

noemers (‘ontwerppatroon’ en ‘graad’), maar hieruit lijkt geen globaal schema uit afgeleid te kunnen worden over hoe de overige impliciete, tacit en kwalitatieve informatie in de AIM benadering kan onderverdeeld en ge¨expliciteerd worden.

11.4.2. Testcase Er wordt voorgesteld om verder onderzoek uit te voeren naar de wijze waarop ‘ontwerpinformatie’ gedefinieerd kan worden. Hiervoor zou in de eerste plaats de onderverdeling die aangenomen werd in § 10.2.1 geherevalueerd moeten worden. Uit verder literatuuronderzoek zou een meer wetenschappelijk gefundeerde onderverdeling kunnen aangenomen worden, die vervolgens aan de hand van een testcase verder ge¨evalueerd zou kunnen worden. In deze testcase dient vooral getracht te worden om het concept ‘ontwerpinformatie’ zodanig te benaderen dat deze op een gestructureerde manier kan ge¨expliciteerd worden. Met dit doel wordt voorgesteld om de conceptueel voorgestelde Virtuele Interactieve Neufert verder uit te werken, maar om deze beter te funderen op het boek Neufert en Neufert (2002) zelf, zodat een duidelijk gestructureerd overzicht kan gegeven worden van wat verstaan wordt onder ‘ontwerpinformatie’. In een volgende fase kunnen methodes uitgedacht worden om deze ontwerpinformatie verder te expliciteren en deze te situeren in de geboden functionaliteiten van een informatiestroom binnen de conceptuele AIM benadering.

11.5. Besluit In een summier uitgewerkte, experimentele testcase werd kort onderzocht hoe een informatiestroom tussen een conceptueel Architectural Information Model en een conceptueel Architectural Memory zou kunnen verlopen. Het conceptueel Architectural Information Model werd in deze experimentele testcase opgebouwd aan de hand van een manuele invoer in een tekstuele interface (§ 11.3). De informatie die hierin ingevoerd werd, is gekoppeld aan een XML bestand, dat in deze experimentele testcase dienst deed als een alternatief Architectural Memory. De functionaliteit dat door dit conceptueel Architectural Memory geboden werd, is uitgewerkt in een Virtueel Interactieve Neufert (§ 11.3.2). Uit de resultaten van deze experimentele testcase werd geconcludeerd dat de voornaamste hindernis in een vloeiende en functionele informatiestroom in de AIM benadering zich nog steeds situeert in de eigenlijke inhoud van het concept ‘ontwerpinformatie’. Daarom wordt voorgesteld om dit verder uit te werken in een volgende testcase. Deze testcase zou verder werken op de explicitering van de impliciete ontwerpinformatie die in Neufert en Neufert (2002) beschreven wordt in de verschillende functionele en geometrische ontwerpregels. Op deze manier zou getracht worden om een concrete invulling en structuur te geven aan het

11

HOOFDSTUK 11. AIM TESTCASE

288

concept ‘ontwerpinformatie’ zodat dit verder gebruikt kan worden in de eventuele uitwerking van een Architectural Information Modelling kader.

11

12 Besluit

12.1. Situering Sinds enkele jaren lijken de ontwikkelingen in het domein van de informatie- en communicatietechnologie een steeds grotere invloed uit te oefenen op de werkmethodes in het architectuurontwerp. Uitgebreide fotorealistische visualisaties worden in een handomdraai uitgewerkt door gespecialiseerde visualisatiebureaus en uitgebreide rekenkundige simulaties maken het mogelijk om een ontwerp tot op de kleinste details te simuleren en als het ware virtueel op te bouwen nog voordat de eigenlijke aannemer of bouwfirma nog maar in het bouwproces betrokken wordt. ICT lijkt in bovenstaande ontwikkelingen met andere woorden een steeds grotere invloed uit te oefenen op de gebruikte werkmethodes in het architectuurontwerp. Deze scriptie trachtte hier op in te gaan. Uit een analyse van verschillende reeds uitgevoerde onderzoeken naar de impact van ICT op het architectuurontwerp en uit een beschouwing van schijnbare ontwikkelingen in de architectuurpraktijk zelf, kon vastgesteld worden dat ICT vandaag een belangrijke impact heeft op het architectuurontwerp. Met name de invloed van BIM applicaties (Building Information Modelling) lijkt hierin een steeds grotere rol in te spelen. Uit de analyse en bijhorende beschouwing leek echter ook volgende vaststelling gemaakt te kunnen worden. Er lijkt een onderscheid te bestaan tussen de mate waarin ICT gebruikt wordt in de voorontwerpfase van het architectuurontwerp en de mate waarin het gebruikt wordt in de eigenlijke

289

HOOFDSTUK 12. BESLUIT

290

uitwerkingsfase van het architectuurontwerp. ICT in de uitwerkingsfase wordt enerzijds relatief intensief gebruikt en eerder beschouwd als een ‘vaste, onmisbare partner’ in de uitwerking van het project. ICT in de voorontwerpfase anderzijds lijkt nog eerder beperkt te worden tot een soort ‘effici¨ent medium’, dat evenwel zijn nut kan bewijzen in de voorontwerpfase, maar dat echter niet zo onmisbaar is als het in de uitwerkingsfase is. Zo lijken verschillende ontwerpers in gerelateerde onderzoeken nog steeds in de eerste plaats terug te vallen op een ontwerpmethode via pen en papier, om slechts in een tweede fase, de uitwerkingsfase, terug te vallen op ICT applicaties.

12.2. Vraagstelling Op basis daarvan werd een vraagstelling aangevoerd, die verder onderzocht zou worden in het verdere verloop van de scriptie. “Wat zou de voornaamste reden kunnen zijn van dit verschil in de mate waarin ICT applicaties gebruikt worden in het architectuurinformatie? Zou uit het antwoord op deze vraag een benadering uitgewerkt kunnen worden, waardoor dit verschil zou kunnen weggewerkt worden en ontwerpers in de voorontwerpfase beter gebruik kunnen maken van ICT als een effectieve ‘partner’ in het ontwerp?

12.3. Methodiek Het antwoord op deze vraagstelling werd in de eerste plaats gezocht binnen de wijze waarop ICT applicaties aangewend kunnen worden in de voorontwerpfase. Om dit te kunnen bestuderen, werd in een eerste stap onderzocht volgens welke aspecten het architecturaal ontwerpproces zou kunnen onderverdeeld worden, zodat in een volgende stap zou kunnen geanalyseerd worden op welke manier bestaande ICT applicaties op elk van deze aspecten trachten in te spelen en hiervoor functionaliteiten trachten aan te bieden. Uit dit onderzoek kwam volgende onderverdeling in ‘essenti¨ele aspecten in het ontwerpproces’ naar voor. Deze onderverdeling werd gebaseerd op uitgebreide, bestaande onderzoeksresultaten van een analyse van de karakteristieken van een ontwerpproces en de wijze waarop een ontwerper volgens deze karakteristieken lijkt te denken. 1. generation of design solutions, of de wijze waarop een architect effectief redeneert om vervolgens tot een voorlopige ontwerpoplossing te komen 2. communication, of de manier waarop door de architect zelf en door de verschillende partijen uit het ontwerpproces gecommuniceerd wordt om vervolgens door een verschil

12

HOOFDSTUK 12. BESLUIT

291

in interpretaties tot heel nieuwe inzichten en perspectieven te komen op een ontwerpprobleem. 3. evaluation of design solutions, of de wijze waarop gegenereerde ontwerpoplossingen zouden ge¨evalueerd kunnen worden, zowel op een kwantitatief en meetbaar niveau als op een kwalitatief, ‘tacit’ en impliciet niveau 4. decision-making, of de wijze waarop beslissingen genomen worden, terugvallend op de verschillende invloedsfactoren afkomstig uit de voorgaande drie ontwerpaspecten

In de volgende, uitgebreide literatuurstudie werd in een eerste stap onderzocht hoe door verschillende ICT applicaties uit de voorontwerpfase lijkt ingespeeld te worden op elk van deze verschillende ontwerpaspecten. Vervolgens werd een korte literatuurstudie uitgevoerd naar de verschillende bestaande dataformaten en dataconversietechnieken, waarna dit in een laatste deel kort getoetst werd aan bestaande virtuele ontwerpomgevingen.

12.4. Literatuurstudie Uit deze literatuurstudie konden verschillende besluiten en vaststellingen gemaakt worden. Deze bleken echter uiteindelijk terug te brengen op twee elementen die aan de basis lijken te liggen van de vaststelling dat ICT in de voorontwerpfase nog steeds niet effectief ingezet wordt in de voorontwerpfase. Deze elementen werden als volgt geformuleerd. • Ontwerpinformatie Bestaande ICT applicaties vallen in de eerste plaats terug op het gedeelte aan expliciete informatie dat in een ontwerp aanwezig is. Deze expliciete informatie kan onderverdeeld worden in benoemende, categoriserende informatie en concrete, componentengebaseerde informatie. De categoriserende informatie kan daarbij begrepen worden als een onderverdeling volgens verschillende, ruim interpreteerbare categorie¨en waarin de mens het ontwerp tracht onder te brengen, zoals de categorie¨en ‘sociale woningbouw’, ‘betonbouw’, enzovoort. De concrete, componentengebaseerde informatie daarentegen kan eerder begrepen worden als de informatie die aan bod komt bij een uiteenrafeling van een gebouw in zijn verschillende, samenstellende onderdelen of componenten. Dit wordt vergeleken met de soorten informatie die volgens uitgebreid, bestaand onderzoek aanwezig zouden moeten zijn in de verschillende aspecten van het ontwerp. Hieruit kon geconcludeerd worden dat een belangrijk gedeelte aan informatie ontbrak in het geheel aan informatie dat door ICT applicaties gebruikt wordt, namelijk de informatie die veel implicieter in het ontwerp aanwezig is. Deze impliciete informatie

12

HOOFDSTUK 12. BESLUIT

292

werd door het bestaande onderzoek onderverdeeld in impliciete, ‘tacit’ en kwalitatieve informatie. Er blijken geen concrete methodes of applicaties te zijn die in staat zijn deze soort informatie te expliciteren. Bijgevolg kan er door ICT applicaties die zich richten op de verschillende aspecten van het voorontwerpproces, niet rechtstreeks gebruik gemaakt worden van deze impliciete ‘ontwerpinformatie’. Het geheel aan informatie dat gebruikt zou worden in het ontwerp, bleek uiteindelijk als volgt onderverdeeld te kunnen worden. – expliciet ∗ categoriserende ontwerpinformatie ∗ kwantitatieve ontwerpinformatie ∗ meetbare ontwerpinformatie – impliciet ∗ impliciete ontwerpinformatie ∗ tacit ontwerpinformatie ∗ kwalitatieve ontwerpinformatie Als conclusie zou gesteld kunnen worden dat deze noodzakelijke beperking tot eerder expliciete informatie er toe geleid heeft dat ICT applicaties zich te veel moeten richten op slechts een gedeelte van de noodzakelijke informatie in een ontwerpproces. Hierdoor worden deze applicaties wellicht minder geschikt bevonden door ontwerpers dan een traditionele werkmethode via pen en papier en via het menselijk denkvermogen, dat deze impliciete informatie w´el kan vatten. Dit komt daarbij minder tot uiting in de eigenlijke uitwerkingsfase van het architectuurontwerp, omdat in deze fase uitdrukkelijk geconcentreerd wordt op het uitwerken van deze expliciete informatie, waarbij de eerder impliciete, ‘ontwerpmatige’ informatie als definitief vastgelegd kan beschouwd worden. • Interoperabiliteit Het tweede aspect dat uit het literatuuronderzoek naar voor kwam, richtte zich op interoperabiliteit, of de mate waarin ICT applicaties onderling kunnen verderwerken op basis van eenzelfde dataformaat. In de uitwerkingsfase wordt op dit gebied een initiatief uitgewerkt door het IAI (International Alliance for Interoperability) dat gericht is op de interoperabiliteit via de IFC standaard (Industry Foundation Classes). Via dit bestandsformaat is het mogelijk om nagenoeg alle componentengebaseerde informatie met betrekking op een uit te voeren gebouw, te vatten in een structuur die door heel uiteenlopende ICT applicaties begrepen kan worden.

12

HOOFDSTUK 12. BESLUIT

293

Uit het onderzoek naar bestaande ontwerpomgevingen bleek deze zoektocht naar interoperabiliteit beduidend minder aanwezig te zijn. Er werden wel expliciet koppelingen met ICT applicaties die ingingen op enkele van voornoemde ontwerpaspecten, maar deze koppelingen bleken zich daarbij te sterk afgestemd te zijn tot die geselecteerde applicaties. Bij een gebruik van deze ontwerpomgevingen zou dan ook enkel teruggevallen kunnen worden op deze heel beperkte verzameling aan gekoppelde ICT applicaties, wat in sterk contrast staat met het uitgebreide gamma aan ICT applicaties dat beschikbaar kan gemaakt worden voor de ontwerper in de uitwerkingsfase. Hieruit werd geconcludeerd dat, door dit tekort aan interoperabiliteit tussen bestaande, virtuele ontwerpomgevingen en gerelateerde ICT applicaties, het niet mogelijk was voor een ontwerpomgeving om een voldoende uitgebreide keuze aan gekoppelde ICT applicaties te voorzien en om dus tot een effectief ‘ge¨ıntegreerde’ ontwerpomgeving te kunnen evolueren. Er werd gesteld in deze scriptie dat ook dit element wellicht een belangrijke rol speelt in de vaststelling dat huidige ontwerpers eerder terugvallen op een pen en papier werkmethode en minder geneigd zijn om ICT als een effectieve, vaste partner te beschouwen in het ontwerpproces.

12.5. Antwoord Op basis van deze conclusies uit het literatuuronderzoek werd in een laatste stap een antwoord geformuleerd op de voorafgaande vraagstelling uit deze scriptie. Dit antwoord werd geformuleerd onder de vorm van een voorgestelde benadering die gebruikt zou kunnen worden voor de constructie van een kader dat zich rechtstreeks tracht te richten op het eigenlijke ontwerpproces in de voorontwerpfase. Deze benadering is rechtstreeks gebaseerd op de gesitueerde elementen, ‘ontwerpinformatie’ en ‘interoperabiliteit’, waarmee expliciet getracht wordt om een voldoende solide alternatief aan te bieden op de gestelde problematiek.

12.5.1. Algemene benadering Om in te gaan op het aspect ‘interoperabiliteit’ werd in de eerste plaats een algemeen kader voorgesteld, dat zich op de zelfde manier zou moeten gedragen als het kader dat in de uitwerkingsfase gebruikt wordt, namelijk Building Information Modelling. Uit de gevoerde literatuurstudie is namelijk gebleken dat dit BIM kader op een effectieve wijze interoperabiliteit kan aanbieden aan de ontwerper. Aangezien in dit BIM kader de interoperabiliteit uitdrukkelijk mee verzord blijkt te zijn door het gebruik van de Industry Foundation Classes standaard, werd ook in de benadering van ICT voor de voorontwerpfase voorgesteld om terug te vallen op deze Industry Foundation Classes als centraal dataformaat. Bij de vorming van een kader voor de ontwerpfase werd op basis van het tweede aspect,

12

HOOFDSTUK 12. BESLUIT

294

‘ontwerpinformatie’, een kleine, maar belangrijke nuance doorgevoerd in de Building Information Modelling benadering. Via die nuance in het eigenlijke onderwerp van de benadering wordt voorgesteld om de Building Information Modelling benadering uitdrukkelijk te richten op expliciet aanwezige informatie en de voorgestelde benadering voor de voorontwerpfase uitdrukkelijk te richten op impliciet aanwezige informatie in de voorontwerpfase. Deze nuance wordt ook doorgevoerd in de benaming van de voorgestelde benadering. De benaming Building Information Modelling wordt namelijk herbruikt en omgevormd tot ‘Architectural Information Modelling’ (AIM) of ‘Architecturale Informatie Modellering’. Via deze nuancering wordt getracht indirect te verwijzen naar de twee centrale aspecten van deze benadering, namelijk ‘interoperabiliteit’, die gebaseerd wordt op de werkmethodes binnen BIM (‘Information Modelling’ ), en het behandelde soort informatie (‘Architectural’ ), wat uitdrukkelijk verschilt met het soort informatie binnen BIM (‘Building’ ). Overeenkomstig met de BIM benadering staat een AIM ontwerpmodel of ‘Architectural Information Model’ centraal in dit kader, waarin deze eigenlijk ‘ontwerpinformatie’ gevat wordt. Met deze extra data en metadata over het ontwerp zouden applicaties mogelijk gemaakt kunnen worden die op een ge¨ıntegreerde manier effici¨entie brengen in het architecturaal ontwerpproces, niet enkel op het vlak van ontwerpvisualisatie (concretisering van een idee tot een schetsontwerp), maar ook op het vlak van vroege ontwerpanalyse (kostencalculatie, warmteberekening, . . . ) en ontwerpdocumentatie (ontwerpaanpassingen in de uitwerkingsfase, renovatieprojecten, . . . ).

12.5.2. Interactie met gerelateerde ICT componenten Op basis van het uitgevoerde literatuuronderzoek naar de wijze waarop door huidige ICT applicaties getracht wordt in te spelen op de verschillende aspecten van het ontwerpproces, werden volgende vier ICT componenten gedefinieerd en beschreven. • Architectural Memory (AM): generation of design solutions • Virtual Reality - Visual Simulation (VR-SIM): communciaton • Virtual Calculation & Simulation (V-CALC) - evaluation of design solutions • Building Information Modelling (BIM) - decision-making Deze ICT componenten trachten elk op hun manier in te spelen op een bepaald aspect van het ontwerpproces. Hoe dit in zijn werk zou kunnen gaan, wordt per ICT component afzonderlijk omschreven en gesitueerd ten opzichte van het reeds voorgestelde Architectural Information Modelling kader. Dit resulteerde uiteindelijk in het schema dat weergegeven wordt in figuur 12.1.

12

HOOFDSTUK 12. BESLUIT

295

Figuur 12.1.: Voorgesteld, conceptueel AIM werkingsschema.

Architectural Memory (AM) Het AIM ontwerpmodel dient in de eerste plaats in verbinding gebracht te worden met een Architectural Memory (AM). Dit Architectural Memory dient daarbij begrepen te worden als een opgeslagen verzameling aan kennis op het vlak van architectuur. De achterliggende idee voor deze relatie tussen het Architectural Memory en het AIM ontwerpmodel is, dat in een ontwerpomgeving impliciet steeds visuele referenties aanwezig zijn naar specifieke ontwerppatronen en historische voorbeelden. Expliciteren van deze referenties zou ervoor zorgen dat extra kennis in een doorzichtige structuur binnen de ontwerpomgeving beschikbaar gemaakt zou kunnen worden. Virtual Simulation & Calculation (V-CALC) In tweede instantie wordt voorgesteld om vanuit het centrale AIM ontwerpmodel een verbinding te maken naar applicaties voor virtuele simulatie en calculatie (V-CALC ), waarmee in eerste instantie concrete tools beoogd worden voor simulatie en visualisatie van een eerste, uiterst schematisch voorontwerp. In tweede instantie zou ook de impliciete informatie binnen deze V-CALC component gebruikt moeten kunnen worden voor de uitvoering van een analyse of calculatie van een voorontwerp.

12

HOOFDSTUK 12. BESLUIT

296

Building Information Modelling (BIM) Het maken van beslissingen zou kunnen beschouwd worden als ´e´en van de belangrijkste aspecten in het ontwerpproces. Hiermee wordt namelijk doorgaans het verdere verloop van het ontwerpproces en dus ook het uiteindelijk bekomen ontwerpresultaat sterk be¨ınvloed. Dit aspect is daarbij bovendien grotendeels afhankelijk van het resultaat van de drie voorgaande aspecten van het ontwerpproces. De ontwerpbeslissing zal dus sterk be¨ınvloed worden door de manier waarop de architect tot een ontwerpvoorstel is gekomen, de manier waarop dit onderling gecommuniceerd is met de cli¨ent en de manier waarop deze cli¨ent dit ontwerpvoorstel ge¨evalueerd heeft. Via de derde component, Building Information Modelling, wordt getracht om een voldoende uitgebreid kader te voorzien waarin de ontwerper in staat is om de verschillende informatie in deze drie overige componenten te overzien. Dit wordt in principe reeds voorzien in het voorgestelde AIM kader, maar door toevoeging van een meer expliciet componentengebaseerde platform, wordt getracht om een nog ruimer beeld aan te bieden aan de ontwerper voor het maken van correct gefundeerde ontwerpbeslissingen.

12.5.3. Virtual Reality - Visual Simulation (VR-SIM) Een laatste ICT component, VR-SIM, wordt voorgesteld als een medium waarlangs een uitgebreide visualisatie aangeboden wordt aan de ontwerper. Dit medium tracht hiermee in te spelen op het aspect communication door een zo uitgebreid mogelijk te interpreteren, grafisch beeld te geven van de verschillende aspecten en vormen van informatie die in het centrale AIM informatiemodel opgeslagen zijn. Door de grafische communicatie via deze VR-SIM component wordt getracht om, in samenwerking met het medium potlood en papier, een zo uitgebreid mogelijke set aan interpretatiemogelijkheden aan te bieden aan de ontwerper. Deze interpretatiemogelijkheden vinden in deze VR-SIM component niet alleen plaats op basis van de eigenlijke informatie van het AIM informatiemodel. Er wordt integendeel voorgesteld om de VR-SIM component in de AIM benadering uit te werken als een ‘overkoepelende’ component, die eveneens de informatie uit de overige componenten van de AIM benadering zou kunnen communiceren voor interpretatie.

12.5.4. Besluit en verder onderzoek De stapsgewijs opgebouwde Architectural Information Modelling benadering resulteerde uiteindelijk in het schema dat voorgesteld wordt in figuur 10.10.

12

HOOFDSTUK 12. BESLUIT

297

Figuur 12.2.: Resulterend AIM werkingsschema.

Om de mogelijk aan te bieden functionaliteiten van de AIM benadering concreter te kunnen invullen, werd getracht om de informatiestroom die tussen het Architectural Memory en het conceptueel AIM kader plaatsvindt, illustrerend en zeer benaderend uit te werken aan de hand van een testcase rond scholenbouw. Hieruit kon geconcludeerd worden dat er wel degelijk enkele nuttige functionaliteiten zouden kunnen geboden worden voor uiteindelijk gebruik in de voorontwerpfase. Een belangrijkere conclusie echter werd nog steeds gesitueerd in de eigenlijke invulling van het concept ‘ontwerpinformatie’. Er kon in deze experimentele testcase niet duidelijk gedefinieerd worden hoe deze ontwerpinformatie gestructureerd en ingevuld zou kunnen worden met expliciete termen. Daarom wordt voor verder onderzoek een volgende testcase voorgesteld, waarin concreet onderzoek uitgevoerd worden naar de aard en de structuur van het concept ‘ontwerpinformatie’ en de wijze waarop deze informatie ge¨expliciteerd kan worden, zodat deze begrijpbaar en bruikbaar wordt voor informatiesystemen. Er wordt voorgesteld om in deze testcase een ‘Virtueel Interactieve Neufert’ (VIN) uit te werken. Deze zou in staat moeten zijn om impliciete, geometrische en functionele ontwerpregels te expliciteren volgens een correcte onderverdeling. In een later onderzoek zou deze Virtuele Interactieve Neufert ondergebracht kunnen worden in een prototype van een Architectural Memory zodat deze VIN kan gebruikt worden binnen een concreet Architectural Information Modelling kader.

12

Bibliografie

Aamodt, A. en E. Plaza (1994). Case-based reasoning: Foundational issues, methodological variations, and system approaches. AICOM Artificial Intelligence Communications 7 (1), 39–59. Achten, H. H. (1997). Generic Representations - An Approach for Modelling Procedural and Declarative Knowledge of Building Types in Architectural Design. Ph. D. thesis, Technische Universiteit Eindhoven / Faculteit Bouwkunde. Achten, H. H. (2000). Design case retrieval by generic representations. Artificial Intelligence in Design, 373–392. Achten, H. H. (2004, September). Lowering the threshold for computers in early design some advances in architectural design. In Proceedings of the 4th International Conference on Advanced Engineering Design, Glasgow. Achten, H. H. (2005, June). Resolving some ambiguities in real-time design drawing recognition by means of a decision tree for agents. In B. Martens en A. Brown (Eds.), Computer Aided Architectural Design Futures 2005 - Proceedings of the 11th International CAAD Futures Conference Held at the Vienna University of Technology, Vienna, Austria, pp. 311–320. Achten, H. H. (2006). Towards real-time design drawing recognition. Computer Geometry & Graphics 8 (2), 16–28. Achten, H. H., B. de Vries, en J. Jessurun (2000). Dddoolz - a virtual reality sketch tool for early design. In Proceedings of the fifthe Conference on Computer Aided Architectural Design Research in Asia, Singapore, pp. 451–460. Achten, H. H. en J. Jessurun (2002). An agent framework for recognition of graphic units in drawings. In K. Koszewski en S. Wrona (Eds.), Proceedings of the 20th International Conference on Education and Research in Computer Aided Architectural Design in Europe, Warsaw, pp. 246–253. Achten, H. H. en J. Jessurun (2003). Learning from mah jong - towards a multi-agent system that can recognize graphic units. In Digital Design: Research and Practice - Proceedings

298

BIBLIOGRAFIE

299

of the 10th International Conference on Computer Aided Architectural Design Futures., Dordrecht, pp. 115–124. Achten, H. H. en J. P. van Leeuwen (2000). Towards generic representations of designs formalised as features. In Proceedings of the 5th Conference on Design and Decision Support Systems in Architecture and Urban Planning. Akin, . (1986). Psychology of Architectural Design. Pion Limited, London. Aliakseyeu, D. (2003). A computer support tool for the early stages of architectural design. Ph. D. thesis, Technische Universiteit Eindhoven. Beetz, J., J. P. van Leeuwen, en B. de Vries (2006). Towards a topological reasoning service for ifc-based building information models in a semantic web context. In H. Rivard, M. Cheung, H. Melhem, E. Miresco, R. Amor, en F. Ribeiro (Eds.), Building on IT Proceedings of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering., pp. 3426–3435. Bekaert, J. (2006). Standards-based interfaces for harvesting and obtaining assets from digital repositories. Ph. D. thesis, Universiteit Gent - Faculteit Ingenieurswetenschappen - Vakgroep Architectuur en Stedenbouw. Bekaert, J., L. Balakireva, P. Hochstenbach, en H. Van de Sompel (2004, February). Using mpeg-21 dip and niso openurl for the dynamic dissemination of complex digital objects in the los alamos national laboratory digital library. D-Lib Magazine 10 (2). Bekaert, J., P. Hochstenbach, en H. Van de Sompel (2003). Using mpeg-21 didl to represent complex digital objects in the los alamos national laboratory digital library. D-Lib Magazine 9 (11). Bekaert, J. en H. Van de Sompel (2005). Representing digital assets using mpeg-21 digital item declaration. International Journal on Digital Libraries. Bille, W., O. De Troyer, B. Pellens, en F. Kleinermann (2005). Conceptual modeling of articulated bodies in virtual environments. In Proceedings of the 11th International Conference on Virtual Systems and Multimedia, Gent, Belgium, pp. 17–26. Publ. Archaeolingua. Bille, W., B. Pellens, F. Kleinermann, en O. D. Troyer (2004a). Intelligent modelling of virtual worlds using domain ontologies. In C. Delgado-Mata en J. Ib´ an ˜ez (Eds.), IVEVA, Volume 97 of CEUR Workshop Proceedings. CEUR-WS.org. Bille, W., B. Pellens, F. Kleinermann, en O. D. Troyer (2004b). Intelligent modelling of virtual worlds using domain ontologies. In C. Delgado-Mata en J. Ib´ an ˜ez (Eds.), IVEVA, Volume 97 of CEUR Workshop Proceedings. CEUR-WS.org.

BIBLIOGRAFIE

300

Bille, W., O. D. Troyer, F. Kleinermann, B. Pellens, en R. Romero (2004). Using ontologies to build virtual worlds for the web. In P. T. Isa´ıas, N. Karmakar, L. Rodrigues, en P. Barbosa (Eds.), ICWI, pp. 683–690. IADIS. Bo, J. D., P. Spyns, en R. Meersman (2004). Assisting ontology integration with existing thesauri. In CoopIS/DOA/ODBASE (1), pp. 801–818. Boeykens, S. (2007). Design phase and scale level transitions in a digital building model. Ph. D. thesis, Katholieke Universiteit Leuven / Departement Architectuur, Stedenbouw en Ruimtelijke Ordening (ASRO). Boeykens, S. en H. Neuckermans (2003, April). Implementation strategy for an architectural design environment;issues in the development of idea+. In 3rd International Postgraduate Research Conference in the Built and Human Environment. Boeykens, S. en H. Neuckermans (2005, September). Scale level and design phase transitions in a digital building model. In J. Pinto Duarte, G. Ducla-Soares, en A. Zita Sampaio (Eds.), Proceedings eCAADe 2005, Lisbon (Portugal). Boeykens, S. en H. Neuckermans (2006, December). Improving design workflow in architectural design applications. International Journal of Architectural Computing 4 (4), 1–19. Boeykens, S. en H. Neuckermans (2007, September). A generic data structure for an architectural design application. In J. Kieferle en K. Ehlers (Eds.), Proceedings of the 25d eCAADe Conference, pp. 303–310. Boeykens, S., H. Neuckermans, en B. Geebelen (2002, September). Design phase transitions in object-oriented modeling of architecture. In Proceedings of the 20th eCAADe Conference. Boeykens, S., H. Neuckermans, en B. Geebelen (2005, July). Virtual engineering in architectural design. In The 9th World Multi-Conference on Systemics, Cybernetics and Informatics, pp. 36–40. Boland, R. J., K. Lyytinen, en Y. Yoo (2007). Wakes of innovation in project networks: the case of digital 3d representations in architecture, engineering and construction. Organization Science 18 (4), 631–647. Chan, L. M. en M. L. Zeng (2006). Metadata interoperability and standardization: A study of methodology part ii. D-Lib Magazine 12 (6). Chiariglione, L. (1998). Impact of mpeg standards on multimedia industry. In Proceedings of the IEEE, Volume 86, Los Alamitos, pp. 1222–1227. IEEE Computer Society Press.

BIBLIOGRAFIE

301

Colakoglu, B. en S. Dionyan (2005, September). A parametric form generator - congen, digital design: The quest for new paradigms. In 23nd eCAADe Conference Proceedings, Lisbon (Portugal), pp. 623–628. Coninx, K. en E. Cuppens (2005). Cogenive: Code generation for interactive virtual environments. In The Future of User Interface Design Tools, workshop of ACM Conference on Human Factors in Computing Systems (CHI 2005). Coninx, K., E. Cuppens, en C. Raymaekers (2005). A model-based design process for interactive virtual environments. In DSV-IS, pp. 225–236. Coninx, K., J. De Boeck, C. Raymaekers, E. Cuppens, en T. De Weyer (2004a). Multisensory interaction metaphors with haptics and proprioception in virtual environments. In R. Raisamo (Ed.), NordiCHI, pp. 189–197. ACM. Coninx, K., J. De Boeck, C. Raymaekers, E. Cuppens, en T. De Weyer (2004b, June). Taskbased abstraction of haptic and multisensory applications. In Proceedings of Eurohaptics 2004, Munchen, Deutschland, pp. 174–181. Coninx, K., O. De Troyer, C. Raymaekers, en F. Kleinermann (2006). Vr-demo: a toolsupported approach facilitating flexible development of virtual environments using conceptual modelling. In D. Coutellier en X. Fischer (Eds.), Proceedings of Virtual Concept 2006, Cancun, Mexico. Springer-Verlag. Coninx, K., D. Vanacken, J. De Boeck, en C. Raymaekers (2006). Nimmit: A notation for modeling multimodal interaction techniques. In GRAPP, pp. 224–231. Coomans, M. K. D. (1999). A virtual reality user interface for a design information system. In CCAI : journal for integrated study of artificial intelligence, cognitive science and applied epistemology, Rijks Universiteit Gent. Cosmas, J., T. Itegaki, D. Green, E. Grabczewski, F. Weimer, L. Van Gool, A. Zalesny, D. Vanrintel, F. Leberl, M. Grabner, K. Schindler, K. Karner, M. Gervautz, S. Hynst, M. Waelkens, M. Pollefeys, R. Degeest, R. Sablatnig, en M. Kampel (2001). 3d murale: a multimedia system for archaeology. In VAST ’01: Proceedings of the 2001 conference on Virtual reality, archeology, and cultural heritage, New York, NY, USA, pp. 297–306. ACM Press. Cuppens, E., C. Raymaekers, en K. Coninx (2004). Vrixml: A user interface description language for virtual environments. In Proc. of the 1 st ACM AVI’2004 Workshop: Developing User Interfaces with XML: Advances on User Interface Description Languages. Czernuszenko, M., D. Pape, D. Sandin, T. A. DeFanti, G. Dawe, en M. D. Brown (1997, May). The immersaddesk and infinity wall projection-based virtual reality displays. ACM SIGGRAPH Computer Graphics 31 (2), 46–49.

BIBLIOGRAFIE

302

De Bo, J., P. Spyns, en R. Meersman (2004). Towards a methodology for semi-automatic ontology aligning and merging. Technical report, STAR Lab, Brussel. De Boeck, J., C. Raymaekers, en K. Coninx (2005, April). Are existing metaphors in virtual environments suitable for haptic interaction. In Proceedings of Virual Reality International Conference, Laval, France, pp. 261–268. De Troyer, O., W. Bille, R. Romero, en P. Stuer (2003). On generating virtual worlds from domain ontologies. In MMM, pp. 279–294. De Troyer, O., F. Kleinermann, H. Mansouri, B. Pellens, W. Bille, en V. Fomenko (2007). Developing semantic vr-shops for e-commerce. Virtual Real. 11 (2), 89–106. De Troyer, O., F. Kleinermann, B. Pellens, en W. Bille (2007). Conceptual modeling for virtual reality. In Tutorials, Posters, Panels, and Industrial Contributions of the 26th international Conference on Conceptual Modeling (ER 07), Auckland, New Zealand. de Vries, B. (2000, June). Sketching in 3d. In Proceedings of the 18th Conference on Education in Computer Aide Architectural Design in Europe (eCAADe), Weimar, Germany. de Vries, B. en H. H. Achten (2002, September). Dddoolz: designing with modular masses. Design Studies 23 (5), 515–531. de Vries, B., J. Jessurun, en M. Engeli (2000, August). Development of an intuitive 3d sketching tool. In Proceedings of the 5th Conference on Design and Decision Support Systems in Architecture and Urban Planning, Nijkerk. de Vries, B., J. Jessurun, en J. J. van Wijk (2001, September). Interactive 3d modeling in the inception phase of architectural design. In Eurographics Short Presentations, Manchester, United Kingdom, pp. 265–271. de Vries, B., S. M. Mallory, E. de Groot, en P. G. S. Rutten (2000, November). Vr-dis, een interactieve integrale ontwerpomgeving. TVVL Magazine 29 (11). de Vries, B., N. M. Segers, J. Jessurun, en H. H. Achten (2004). Word graphs in architectural design. In J. Gero (Ed.), Proceedings International Conference on Design Computing and Cognition 2004., Dordrecht, pp. 541–556. Deckers, D. (2003, July). The Regionmaker: Rheinruhrcity, The Hidden Metropolis (1 ed.). MVRDV. Hatje Cantz Publishers. Do, E. Y.-L. en M. D. Gross (1995). Shape based reminding as an aid to creative design. In M. Tan en R. Teh (Eds.), Proceedings of CAAD Futures 1995 Conference.

BIBLIOGRAFIE

303

Do, E. Y.-L. en M. D. Gross (1996a). Ambiguous intentions: A paper-like interface for creative design. In Proceedings of 9th Annual Symposium for User Interface Software and Technology (UIST 1996). Do, E. Y.-L. en M. D. Gross (1996b). Reasoning about cases with diagrams. Design Computing proceedings of American Society of Civil Engineers (ASCE), 314–320. Do, E. Y.-L. en M. D. Gross (1997). Thinking with diagrams. In Thiking with Diagrams Interdisciplinary Workshop. Do, E. Y.-L., M. D. Gross, B. Neiman, en C. Zimring (2000, September). Intentions in and relations among design drawings. Design Studies 21 (5), 493–503. Duval, E. (1999). An open infrastructure for learning - the ariadne project: share and reuse without boundaries. In Proceedings of ENABLE99: Enabling Network-Based Learning, Espoo, Finland, June 3, 1999, pp. 144–151. Duval, E. (2002). Ieee standard for learning object metadata 1484.12.1-2002. Eastman, C. (1999). Building Product Models: Computer environments supporting design and construction. Boca-Raton, FL: CRC Press. Eastman, C., P. Teicholz, R. Sacks, en K. Liston (2008, March). BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors. Wiley. Ekholm, A. en S. Fridqvist (1997a, September). Concepts of space in computer based product modelling and design. In B. Martins (Ed.), Proceedings of the 15th ECAADE conference, Vienna, Austria. Ekholm, A. en S. Fridqvist (1997b). Design and modelling in a computer integrated construction process - the bas-caad project. In R. Junge (Ed.), Proceedings of CAAD Futures ’97, Dordrecht, Netherlands, pp. 501–518. Ekholm, A. en S. Fridqvist (1999). The bas-caad information system for design - principles, implementation, and a design scenario. In G. Augenbroe en C. Eastman (Eds.), Computers in Building, Proceedings of the CAADfutures ’99 Conference. Fazio, P., H. S. He, A. Hammad, en M. Horvat (2007). Ifc-based framework for evaluating total performance of building envelopes. Journal of Architectural Engineering 13 (1), 44– 53. Foley, J., A. van Dam, S. Feiner, en J. Hughes (1990). Computer Graphics: Principles and Practice (second ed.). Addison-Wesley Professional.

BIBLIOGRAFIE

304

Fridqvist, S. (2000). Property Oriented Information Systems for Design - Prototypes for the BAS-CAAD project. Ph. D. thesis, Lund University, Lund Institute for Technology. Fridqvist, S., A. Ekholm, en J. af Klercker (1995). Bas-caad - building and user activity systems modelling for computer-aided architectural design. In Multimedia and Architectural disciplines. Proceedings from the 13th ECAADE conference, eCAADe’95. Fridqvist, S. en J. P. van Leeuwen (2002, June). Feature type recognition - implementation of a recognizing feature manager. In Distributing Knowledge in Building, Proceedings of CIB W78 2002, Aarhus, Denmark. Fu, C., G. Aouad, A. Lee, A. Mashall-Ponting, en S. Wu (2006). Ifc model viewer to support nd model application. Automation in Construction 15, 178–185. Fuertes, A., M. Casals, N. Forcada, A. Giretti, M. de Grassi, S. Apelt, en M. Eisenhauer (2007). Mace econtentplus project: Metadata for architectural contents in europe. In IV Simposio Pluridisciplinar sobre Dise˜ no, Evaluaci´ on y Desarrollo de Contenidos Educativos reutilizables. Gallagher, M. P., A. C. O’Connor, J. L. Dettbar, en L. T. Gilday (2004). Cost analysis of inadequate interoperability in the u.s. capital facilities industry (nist gcr 04-867). Technical report, National Institute of Standards and Technology (NIST). Geebelen, B. (2000, September). Idea-l, an early-stage architectural design tool for natural lighting. In Proceedings of IBPC2000, Eindhoven, The Netherlands, pp. 18–21. Gent, U. en Google (2007, May). Google and ghent university library to make hundreds of thousands of dutch and french books available online. Press Release. Gray, C. en W. Hughes (2001). Building Design Management. Butterworth Heinemann, USA. Gross, M. D. (1996). The electronic cocktail napkin - working with diagrams. Design Studies 17 (1), 53–69. Hammad, A., P. Fazio, en H. S. He (2005, June). Computer tool to achieve better performance and integration of building envelopes with structural and mechanical systems. In 33d Annual General Conference of the Canadian Society for Civil Engineering, Toronto, Ontario, Canada. Hauguslaine, J.-M. (2000). Multicriteria and multiactors aspects of an interactive tool aiding to sketch the building envelope during the first stages of the design. In 52th meeting of the Working Group: Multicriteria Aid for Descisions.

BIBLIOGRAFIE

305

Hendricx, A. (2000). A core object model for architectural design. Ph. D. thesis, Faculty of Civil Engineering, KU Leuven University. Hendricx, A. en H. Neuckermans (2000, September). Towards a working design environment: From enterprise to functionality model. In 4th SIGRADI Conference Proceedings, Rio de Janeiro, Brazil, pp. 197–199. Hendricx, A. en H. Neuckermans (2001, August). The use of design cases to test architectural building models. In Proceedings of the 19th eCAADe Conference, Helsinki, Finland. Hernandez, C. R. B. (2006, May). Thinking parametric design: introducing parametric gaudi. Design Studies 27 (3), 309–324. Heylighen, A. (1996). Case-based reasoning in architectural design. Master’s thesis, KU Leuven. Heylighen, A. (2000, May). In case of architectural design - Critique and praise of CaseBased Design in architecture. Ph. D. thesis, KU Leuven. Heylighen, A. (2002). An update on dynamo’s adventures since nov 2000. In Proceedings of the Case Study Work Group Open Meeting. Heylighen, A. (2003). Stories from case study shop floor: case study production and use. In Proceedings of the AIA Case Study Workgroup meeting 3, pp. 17–21. Heylighen, A., M. Casaer, en H. Neuckermans (2005). Sharing-in-action: How designers can exchange insights without knowing. In P. Kommers en P. Isaias (Eds.), Proceedings of the IADIS International Conference Web Based Communities 2005, Algarve (Portugal), pp. 238–245. Heylighen, A., M. Casaer, en H. Neuckermans (2006, January). Unaware: Supporting tacit design knowledge exchange. International Journal of Web Based Communities 2006 2 (1), 31–44. Heylighen, A., F. Heylighen, J. Bollen, en M. Casaer (2005). A distributed model for tacit design knowledge exchange. In Proceedings of the 4th Social Intelligence Design Workshop, Stanford University (CD Rom). Heylighen, A. en H. Neuckermans (1999). (learning from experience)2: Promises, problems and side-effects of cbd in architectural design. In M. B. P. Browen, A. Knight (Ed.), 17th eCAADe Conference Proceedings, eCAADe, Liverpool, pp. 567–575. eCAADe. Heylighen, A. en H. Neuckermans (2000a, July). Design(ing) knowledge in architecture. In EAAE/ARCC Conference.

BIBLIOGRAFIE

306

Heylighen, A. en H. Neuckermans (2000b). Dynamo: A dynamic architectural memory on-line. Educational Technology & Society 3 (2), 86–95. Heylighen, A. en H. Neuckermans (2001a). Baptism of fire of a web-based design assistant. Computer Aided Architectural Design Futures 2001 (De Vries B., Van Leeuwen J. and Achten H., editors), Kluwer Academic, 111–124. Heylighen, A. en H. Neuckermans (2001b). A case base of case-based design tools for architecture. Computer-Aided Design 33 (14), 1111–1122. Heylighen, A. en H. Neuckermans (2001c, April). The object model at the core of the idea+ design environment. In R. Beheshti (Ed.), Proceedings of Europia8 - Advances in Design Sciences and Technology, the 8th EuropIA International Conference on the application of Artificial Intelligence, Robotics and Image Processing to Architecture, Building Engineering and Civil Engineering, Delft, The Netherlands. Heylighen, A., H. Neuckermans, en M. Casaer (2004, Special Issue Digital Media Libraries). Ict revisited - from information & communication to integrating curricula? ITcon 9, 101–120. Heylighen, A., H. Neuckermans, M. Casaer, en G. P. M. Dewulf (2007). Building memories. Building Research & Information 35 (1), 90–100. Heylighen, A., H. Neuckermans, M. Wolpers, M. Casaer, en E. Duval (2007, September). Sharing and enriching metadata in architectural repositories. In eCAADe 25: Predicting the Future, Frankfurt am Main, pp. 401–408. eCAADe: Fachhochschule Frankfurt. Heylighen, A., M. Ryckewaert, en H. Neuckermans (2003). Yet another paper about integration? In W. Dokonal en U. Hirschberg (Eds.), 21th eCAADe Conference Proceedings, Graz, Austria. Heylighen, A. en N. M. Segers (2002). An architectural shift+f7: Supporting concept development through design cases. In Proceedings of the ARCC/EAAE 2002 - International Conference on Architectural Research, Montreal. Heylighen, A. en I. M. Verstijnen (2003, July). Close encounters of the architectural kind. Design Studies 24 (4), 313–326(14). Iqbal, R., S. Shirmohammadi, en A. El Saddik (2007, January). A framework for mpeg-21 dia based adaptation and perceptual encryption of h.264 video. In SPIE/ACM Multimedia Computing and Networking Conference, San Jose, California. Iverson, V., Y.-W. Song, R. Van de Walle, M. Rowe, D. Chang, E. Santos, en T. Schwartz (2001, March). Mpeg-21 digital item declaration wd (v2.0) - iso/iec jtc 1/sc 29 n 3971. ISO committe draft.

BIBLIOGRAFIE

307

Jannach, D., K. Leopold, en H. Hellwagner (2004). An extensible framework for knowledgebased multimedia adaptation. In Proceedings of the 17th international conference on Innovations in applied artificial intelligence. Jessurun, J., J. P. van Leeuwen, en E. de Wit (2004, September). The digital dormer applying for building permits online. In A. Dikbas en R. Scherer (Eds.), Proceedings of the European Conference on Product and Process Modelling, Istanbul, Turkey, pp. 355– 361. Balkema Publishers. Juchmes, R., P. Leclercq, en S. Azar (2004). A multi-agent system for the interpretation of architectural sketches. Computers and Graphics Journal 29 (5). Juchmes, R., P. Leclercq, en S. Azar (2005). A freehand-sketch environment for architectural design supported by a multi-agent system. Computer & Graphics 29 (6), 905–915. Kalay, Y. E. (2004). Architecture’s New Media - Principles, Theories and Methods of Computer-Aided Design. The MIT Press, USA. Khemlani, L. (2004, February). Technology at work at gehry partners: A case study. AECbytes Feature. Kiviniemi, A. (2005). Requirements management interface to building product models. Technical Report 161, CIFE, Stanford University. Kiviniemi, A., A. C. B. Garcia, J. Kunz, en M. Ekstrom (2004, March). Building a project ontology with extreme collaboration and virtual design and construction. AI EDAM Journal (Artificial Intelligence for Engineering Design, Analysis and Manufacturing) 18, 71–83. Kiviniemi, A. en J. Haymaker (2005). Integration of multiple product models. In R. Scherer, K. P., en S.-E. Schapke (Eds.), CIB W78 22nd Conference on Information Technology in Construction, Dresden, Germany, pp. 35. Institute for Construction Automatics, Technische Universit¨ at Dresden. Kiviniemi, A., R. Howard, en O. Samuelson (2002, June). The latest developments in communications and e-commerce - it barometer in three nordic countries. In International Council for Research and Innovation in Building and Construction - CIB w78 conference 2002 - Distributing Knowledge in Building. Aarhus School of Architecture. Kleinermann, F., O. De Troyer, H. Mansouri, R. Romero, B. Pellens, en W. Bille (2005). Designing semantic virtual reality applications. In Proceedings of the 2nd INTUITION International Workshop. Kolodner, J. (1983). Reconstructive memory: A computer model. Cognitive Science 7, 281–328.

BIBLIOGRAFIE

308

Kolodner, J. (1992, March). An introduction to case-based reasoning. Artificial Intelligence Review 6 (1), 3–34. Kolodner, J. (1993). Case-Based Reasoning. Morgan Kaufmann. Kolodner, J. (1996). Case-Based Reasoning: Experiences, Lessons & Future Directions. AAAI Press / MIT Press. Kooima, R., T. Peterka, J. Girado, J. Ge, D. Sandin, en T. A. DeFanti (2007, March). A gpu sub-pixel algorithm for autostereoscopic virtual reality. In Proceedings of the IEEE Virtual Reality Conference 2007(VR’07). Kravcik, M. en M. Specht (2004, August). Flexible navigation support in the winds learning environment for architecture and design. In P. D. Bra en W. Nejdl (Eds.), Proc. of Adaptive Hypermedia and Adaptive Web-Based Systems, pp. 156–165. Springer. Kravcik, M. en M. Specht (2005). Experience with winds virtual university. In Conference Proceedings AACE 2005. Kravcik, M., M. Specht, en R. Oppermann (2004, August). Evaluation of winds authoring environment. In P. D. Bra en W. Nejdl (Eds.), Proc. of Adaptive Hypermedia and Adaptive Web-Based Systems, pp. 166–175. Springer. Lagoze, C., H. Van de Sompel, M. Nelson, en S. Warner (2003). The open archives initiative protocol for metadata harvesting - version 2.0. Lam, K. P., N. H. Wong, L. J. Shen, A. Mahdavi, E. Leong, W. Solihin, K. S. Au, en Z. J. Kang (2003, August). Mapping of industry building product model for thermal simulation and analysis. In Proceedings of the eight International IBPSA Conference, pp. 697–704. Lawson, B. (1997). How Designers Think, The Design Process Demystified (3 ed.). Architectural Press. Lebowitz, M. (1983). Memory-based parsing. Artificial Intelligence 21 (4), 363–404. Leclercq, P. (1994). Environnement de conception architecturale pr´e-int´egr´ee - El´ements d’une plate-forme d’assistance bas´ee sur une repr´esentation s´emantique. Ph. D. thesis, Faculty of Applied Sciences, LEMA, Li`ege University. Leclercq, P. (1999). Interpretative tool for architectural sketches. In Proceedings of first international roundtable conference on visual and spatial reasoning in design: computational and cognitive approaches, Cambridge, USA. MIT. Leclercq, P. (2001). Programming and assisted sketching, graphic and parametric integration in architectural design. In B. de Vries, J. P. van Leeuwen, en H. H. Achten (Eds.), 8th

BIBLIOGRAFIE

309

conference Computer Aided Architectural Design Futures 2001. Kluwer Academic Publishers. Leigh, J., C. Luciano, A. Johnson, R. Kooima, G. Dawe, L. Renambot, en T. A. DeFanti (1999). Immersadesk-4: a high resolution, high visual acuity desktop virtual reality system. Liebich, T., J. Wix, J. Forester, en Z. Qi (2002). Speeding-up building plan approvals, the singapore e-plan checking project offers automatic plan checking based on ifc. In European Conf. on Product and Process Modeling (ECPPM), Portoroz, Slovenia. Lipton, L. en M. Feldman (2002). A new autostereographic display technology: The synthagram. In Proceedings of SPIE Photonics West 2002: Electronic Imaging, San Jose, California. Lottaz, C., R. Stouffs, en I. Smith (2000). Increasing understanding during collaboration through advanced representations. Electronic Journal for Information Technology in Construction 5 (1), 1–24. Maas, W. (1998). Farmax: Excursions on Density (1 ed.). MVRDV. Rotterdam, Nederland: 010 Publishers, Rotterdam. Maas, W. (1999). Metacity Datatown. MVRDV. 010 Publishers, Rotterdam. Maas, W. (2001). Hunch: The Berlage Institute Report. Number 3. the Berlage Institute, Rotterdam. Maas, W. (2005, December). KM3 : Excursions on Capacity. MVRDV. Actar. Maas, W. (2006, September). Spacefighter: The evolutionary city(game:). MVRDV/DSD Project Description. in collaboration with Berlage Institute, MIT and cThrough. Maas, W. (2007a, November). Skycar City: A Pre-Emptive History. MVRDV. Actar. Maas, W. (2007b, November). Space Fighter: The Evolutionary City (Game:). Actar. Maher, M. L., M. B. Balachandran, en D. M. Zhang (1995). Case-Based Reasoning in Design. Lawrence Erlbaum. Mantyla, M. (1989). Feature-based product modeling for process planning. In Organization of Engineering Knowledge for Product Modelling in Computer Integrated Manufacturing, pp. 303–320. Marsh, A. J. (1996a). Integrating performance modelling into the initial stages of design. In ANZAScA Conference Proceedings, Hong Kong, China. Chinese University of Hong Kong.

BIBLIOGRAFIE

310

Marsh, A. J. (1996b). Performance modelling and conceptual design. In International IBPSA Conference, Sydney, Australia. The University of New South Wales. Marsh, A. J. (1997). Performance Analysis and Conceptual Design. Ph. D. thesis, School of Architecture and Fine Arts, University of Western Australia. Marsh, A. J. (2003). Computer-optimised shading design. In Building Simulation 2003, Eighth International IBPSA Conference, Eindhoven, Netherlands. Technische Universiteit Eindhoven. Marsh, A. J. (2005). A computational approach to regulatory compliance. In Building Simulation 2005, Nineth International IBPSA Conference,, Montreal, Canada. Marsh, A. J. en A. Roberts (2001). Ecotect: Environmental prediction in architectural education. In Conference Proceedings, 19th ECAADE - Education for Computer Aided Architectural Design in Europe, Helsinki, Finland. Martin, W. M., A. Heylighen, en H. Cavallin (2003a, April). Building stories - a hermeneutic approach to studying design practice. In Proceedings of the 5th European Academy of Design Conference, Barcelona. Martin, W. M., A. Heylighen, en H. Cavallin (2003b). From repository to resource: Exchanging stories of and for architectural practice. In Proceedings of Social Intelligence Design 2003. Martin, W. M., A. Heylighen, en H. Cavallin (2004, July). The right story at the right time: Towards a tacit knowledge resource for (student) designers. AI & Society 19 (1), 34–47. Martin, W. M., A. Heylighen, en H. Cavallin (2005a). Accidental resource: A fable of design research through storytelling. Studying Designers ’05, JS Gero and N Bonnardel (eds.), 343–349. Martin, W. M., A. Heylighen, en H. Cavallin (2005b). Knowledge sharing in the wild: Building stories’ attempt to unlock the knowledge capital of architectural practice. In Proceedings of the CIB W096 Architectural Management ’Special Meeting’ Designing Value: New Directions in Architectural Management. Martin, W. M., A. Heylighen, en H. Cavallin (2007). Building stories revisited: Unlocking the knowledge capital of architectural practice. Architectural Engineering and Design Management 3, 65–74. McGinity, M., J. Shaw, V. Kuchelmeister, A. Hardjono, en D. Del Favero (2007). Avie: a versatile multi-user stereo 360° interactive vr theatre. In Proceedings of the 2007 Workshop on Emerging Displays Technologies: Images and Beyond: the Future of Displays and interacton (San Diego, California, August 04 - 04, 2007).

BIBLIOGRAFIE

311

Mechant, P. en K. Michiels (2007). Het virtuele kunstencentrum van de toekomst: Zoektocht naar een innovatief webplatform voor virtuele cultuurbeleving (1 ed.). VACF-IBBT. Moran, T. (1981). The command language grammar: A representation for the user interface of interactive computer systems. International Journal of Man-Machine Studies 15, 3–50. Moum, A. (2005a, June). Ict and the architectural design process - introduction of an ict impact matrix. In Pricewinning paper at the CIB Joint Symposium, Helsinki, Finnland. Moum, A. (2005b). A three level approach for exploring ict impact on architectural design and management applied to a hospital development project. Moum, A. (2005c). A three level approach for exploring the ict impact on the building design process applied to a real-life project. Moum, A. (2006a). A framework for exploring the ict impact on the architectural design process. ITcon, Special Issue The Effects of CAD on Building Form and Design Quality 11, 409–425. Moum, A. (2006b). Ict and the architect’s work and contribution in the design process. In Project report ¨ architectural design: theory and practice”, DIXIL-01. MPEG-21 (2001, December). Information technology, multimedia framework, part 1: Vision, technologies and strategy. ISO/IEC TR 21000-1:2001. MPEG-21 (2003a, July). Information technology, multimedia framework, part 10: Mpeg-21 digital item processing. ISO/IEC JTC1/SC29/WG11 N5855. MPEG-21 (2003b, March). Information technology, multimedia framework, part 2: Digital item declaration. ISO/IEC 21000-2:2003. MPEG-21 (2003c, March). Information technology, multimedia framework, part 3: Digital item identification. ISO/IEC 21000-3:2003. MPEG-21 (2003d, July). Information technology, multimedia framework, part 4: Mpeg-21 intellectual property management and protection. ISO/IEC JTC1/SC29/WG11 N5874. MPEG-21 (2003e, July). Information technology, multimedia framework, part 5: Mpeg-21 rights expression language. ISO/IEC JTC1/SC29/WG11 N5838. MPEG-21 (2003f, July). Information technology, multimedia framework, part 7: Digital item adaptation. ISO/IEC JTC1/SC29/WG11 N5845. Najjar, J., S. Ternier, en E. Duval (2003). The actual use of metadata in ariadne: an empirical analysis. In Proceedings of the 3rd Annual ARIADNE Conference, pp. 1–6. ARIADNE Foundation.

BIBLIOGRAFIE

312

Neuckermans, H. (1992). A conceptual model for caad. Automation in Construction 1 (1), 1–6. Neuckermans, H., A. Heylighen, en M. Casaer (2005). Dynamo: an on-line collection of architectural precedents in construction. (Re)searching and redefining the Content and Methods of Construction Teaching in the New Digital Era. (EAAE publisher) Transactions on Architectural Education(29), 329–338. Neuckermans, H., A. Heylighen, en P. Morisse (2002, April). Visual keys to architectural design. In A. Eshaq (Ed.), Proceedings of the 7th CAADRIA Conference, Cyberjaya, Prentice Hall, Selangor (Malaysia), pp. 175–185. Neuckermans, H., M. Wolpers, M. Casaer, en A. Heylighen (2007, April). Data and metadata in architectural repositories. In CAADRIA 2007, Proceedings of the 12th International Conference on Computer-Aided Architectural Design Research in ASIA, Nanjing (China), pp. 489–497. Neufert, E. en P. Neufert (2002, July). Architects’data (3 ed.). Wiley-Blackwell. (NISO), N. I. S. O. (2001, September). The dublin core metadata element set. ANSI/NISO Z39.85-2001. Nuyts, K., J.-P. Kruth, B. Lauwers, H. Neuckermans, M. Pollefeys, Q. Li, J. Schouteden, P. Smars, K. Van Balen, L. Van Gool, en M. Vergauwen (2001, October). From a conservationist’s point of view. In Proceedings of the 5th Conference on optical 3D-Maesurement Techniques, Vienna, Austria, pp. 179–186. Orzechowski, M. A. (2004). Measuring Housing Preferences using Virtual Reality and Bayesian Belief Networks. Ph. D. thesis, Eindhoven University of Technology. Orzechowski, M. A. en B. de Vries (2000). Measuring user satisfaction for design variations through virtual reality. In Proceedings of the 5th Conference on Design and Decision Support Systems in Architecture and Urban Planning, Eindhoven, Netherlands, pp. 278– 288. Orzechowski, M. A., B. de Vries, en H. J. P. Timmermans (2003). Virtual reality cad system for non-designers. In Proceedings of 7th Iberoamerican Congress Of Digital Graphic Sigradi-2003, pp. 221–225. Orzechowski, M. A., H. J. Timmermans, en B. De Vries (2001, September). Musev2 the virtual reality application to collect user preference data. In Proceedings of the 5th Iberoamerican Congress of Digital Graphics, SIGraDi, Chili, pp. 162–164.

BIBLIOGRAFIE

313

Oxman, R. M. en M. K. D. Coomans (1996). Prototyping of designs in virtual reality. In Proceedings of 3-rd Design & Decision Support Systems in Architecture and Urban Planning Conference, pp. 20–34. Pape, D., J. Anstey, M. Bogucki, G. Dawe, T. A. DeFanti, A. Johnson, en D. Sandin (1999, May). The immersadesk3 - experiences with a flat panel display for virtual reality. In 3rd International Immersive Projection Technology Workshop. Stuttgart, Germany. Pape, D., C. Cruz-Neira, en M. Czernuszenko (1997, May). Cave user’s guide. Pellens, B., O. De Troyer, W. Bille, en F. Kleinermann (2005a). Conceptual modeling of object behavior in a virtual environment. In Proceedings of Virtual Concept 2005, Biarritz, France. Springer-Verlag. Pellens, B., O. De Troyer, W. Bille, en F. Kleinermann (2005b). Vr-wise: A conceptual modeling approach for virtual environments. In Proceedings of the Methods and Tools for Virtual Reality (MeTo-VR 2005) workshop. Pellens, B., F. Kleinermann, en O. D. Troyer (2006). Intuitively specifying object dynamics in virtual environments using vr-wise. In M. Slater, Y. Kitamura, A. Tal, A. Amditis, en Y. Chrysanthou (Eds.), VRST, pp. 334–337. ACM. Pellens, B., F. Kleinermann, O. D. Troyer, en W. Bille (2006). Model-based design of virtual environment behavior. In H. Zha, Z. Pan, H. Thwaites, A. C. Addison, en M. Forte (Eds.), VSMM, Volume 4270 of Lecture Notes in Computer Science, pp. 29–39. Springer. Pellens, B., O. D. Troyer, W. Bille, F. Kleinermann, en R. Romero (2005). An ontologydriven approach for modeling behavior in virtual environments. In R. Meersman, Z. Tari, P. Herrero, G. M´endez, L. Cavedon, D. Martin, A. Hinze, G. Buchanan, M. S. P´erez, V. Robles, J. Humble, A. Albani, J. L. G. Dietz, H. Panetto, M. Scannapieco, T. A. Halpin, P. Spyns, J. M. Zaha, E. Zim´ anyi, E. Stefanakis, T. S. Dillon, L. Feng, M. Jarrar, J. Lehmann, A. de Moor, E. Duval, en L. Aroyo (Eds.), OTM Workshops, Volume 3762 of Lecture Notes in Computer Science, pp. 1215–1224. Springer. Pelosi, A. (2007, October). Architectural hyper-model: changing architectural construction documentation. UTSePress UTSePress Institutional Repository. Penttil¨ a, H. (2003). Survey of architectural-ict in the educational curriculums of europe. In eCAADe 21 - Digital Design. Penttil¨ a, H. (2006). Describing the changes in architectural information technology to understanding design complexity and free-form architectural expression. ITcon 11, 395–408. Penttil¨ a, H. (2007, July). Early architectural design and bim. In Proceedings of the 12th International Conference on Computer Aided Architectural Design Futures, pp. 291–302.

BIBLIOGRAFIE

314

Penttil¨ a, H. en T.-U. Weck (2006, September). The effects of information and communication technology (ict) on architectural profession. In ECPPM - e-Business and e-work in Architecture, Engineering and Construction, Valencia, Spain. Perlin, K., S. Paxia, en J. S. Kollin (2000, July). An autostereoscopic display. In SIGGRAPH 2000 Conference Proceedings. New Orleans, Louisiana, pp. 319–326. Peterka, T. (2007). Dynallax: Dynamic Parallax Barrier Autostereographic Display. Ph. D. thesis, University of Illinois at Chicago / EVL Electronic Visualisation Laboratory. Peterka, T., R. Kooima, J. Girado, J. Ge, D. Sandin, en T. A. DeFanti (2007, January). Evolution of the varrier autostereoscopic vr display: 2001-2007. In IS&T / SPIE Electronic Imaging 2007 Conference Proceedings. Peterka, T., R. Kooima, D. Sandin, A. Johnson, J. Leigh, en T. A. DeFanti (2007). Advances in the dynallax solid-state dynamic barrier autostereoscopic visualization display system. In IEEE Transactions on Visualization and Computer Graphics. Peterka, T., D. J. Sandin, J. Ge, J. Girado, R. Kooima, J. Leigh, A. E. Johnson, M. Thi´ebaux, en T. A. DeFanti (2006). Personal varrier: Autostereoscopic virtual reality display for distributed scientific visualization. Future Generation Comp. Syst. 22 (8), 976–983. Plessers, P. en O. D. Troyer (2004a). Annotation for the semantic web during website development. In N. Koch, P. Fraternali, en M. Wirsing (Eds.), ICWE, Volume 3140 of Lecture Notes in Computer Science, pp. 349–353. Springer. Plessers, P. en O. D. Troyer (2004b). Web design for the semantic web. In C. Bussler, S. Decker, D. Schwabe, en O. Pastor (Eds.), WWW Workshop on Application Design, Development and Implementation Issues in the Semantic Web, Volume 105 of CEUR Workshop Proceedings. CEUR-WS.org. Pollefeys, M. (1999). Self-calibration and metric 3D reconstruction from uncalibrated image sequences. Ph. D. thesis, Katholieke Universiteit Leuven - Dept. ESAT - PSI. Pollefeys, M., R. Koch, M. Vergauwen, B. Deknuydt, en L. Van Gool (2000). Threedimensional scene reconstruction from images. In proceedings SPIE Electronic Imaging, Volume 3958, pp. 215–266. Pollefeys, M., R. Koch, M. Vergauwen, en L. Van Gool (1998, November). Automatic generation of 3d models from photographs. In Proceedings 4th international conference on virtual systems and multimedia, VSMM’98, Volume 1, Gifu, Japan, pp. 128–133.

BIBLIOGRAFIE

315

Pollefeys, M., R. Koch, M. Vergauwen, en L. Van Gool (1999). Hand-held acquisition of 3d models with a video camera. In Proc. 3DIM’99 Second International Conference on 3-D Digital Imaging and Modeling, pp. 14–23. IEEE Computer Society Press. Pollefeys, M., L. Van Gool, I. Akkermans, D. De Becker, en K. Demuynck (2001). A guided tour to virtual sagalassos. In Proc. VAST2001 (Virtual Reality, Archaeology, and Cultural Heritage), pp. 213–218. Pollefeys, M., L. Van Gool, M. Proesmans, en A. Zalesny (2000, November). The murale project : image-based 3d modeling for archaeology. In Proceedings of the VAST2000 Euroconference, Arezzo, Italy. Oxford, Archaeopress. Pranovich, S. (2004). Structural Sketcher: A Tool for Supporting Architects in Early Design. Ph. D. thesis, Technische Universiteit Eindhoven / Departement Wiskunde en Informatica (WIN). Pranovich, S., H. H. Achten, B. de Vries, en J. van Wijk (2005, January). Structural sketcher: Representing and applying well-structured graphic representations in early design. International Journal of Architectural Computing 3, 75–92. Pranovich, S., J. J. van Wijk, en K. van Overveld (2002). The kite geometry manipulator. In CHI Extended Abstracts, pp. 764–765. Prause, C. R., S. Ternier, T. de Jong, S. Apelt, M. Scholten, M. Wolpers, M. Eisenhauer, B. Vandeputte, M. Specht, en E. Duval (2007). Unifying learning object repositories in mace. In First International Workshop on Learning Object Discovery & Exchange, LODE 2007, in conjunction with the 2nd European Conference on Technology Enhanced Learning (EC-TEL07), Crete, Greece, 2007. Quintero, M. S. (2003, Januari). The Use of Three-dimensional Techniques of Documentation and Dissemination in Studying Built Heritage. Ph. D. thesis, Katholieke Universiteit Leuven. Quintero, M. S., H. Neuckermans, en K. Van Balen (1998). Three-dimensional representation of the different phases of construction and actual state of conservation of the castle of arenberg using caad and virtual reality applications towards its adequate conservation. In 4th Internationall Conference on Virtual Systems and Multimedia, Gifu, Japan. Quintero, M. S., B. Van Der Wee, K. Van Balen, en H. Neuckermans (2002). Teaching digital three-dimensional documentation methods to architectural heritage conservators. In Virtual Congress - World Heritage in the Digital Age, the 30th Anniversary of the World Heritage Convention.

BIBLIOGRAFIE

316

Ransburg, M., R. Cazoulat, B. Pellan, C. Concolato, S. De Zutter, C. Poppe, A. Hutter, H. Hellwagner, en R. Van de Walle (2006, September). Dynamic and distributed adaptation of scalable multimedia content in a context-aware environment. In Proc. of the European Symposium on Mobile Media Delivery (EuMob 2006), Alghero, Italy. Reffat, R. (2002). Designing with computers in a paperless design computing studio. In A. Eshaq, C. Khong, M. Neo, en S. Ahmad (Eds.), Proceedings of the 7th International Conference on Computer Aided Architectural Design Research in Asia (CAADRIA), Prentice Hall, New York, pp. 347–354. Reffat, R. (2003). Semantic-based virtual design environments for architecture. In eCAADe Digital Design, Graz, Austria, pp. 133–140. Reffat, R. (2005). Collaborative digital architecture design teaching within virtual environments. In CAADRIA Computer Aided Architectural Research in Asia, India, pp. 65–74. Reffat, R. (2006). Computing in architectural design: Reflections and an approach to new generations of caad. Journal of information Technology in Construction 11, 655–668. Reffat, R. (2007). Revitalizing architectural design studio teaching using ict: Reflections on practical implementations. International Journal of Education and Development using Information and Communication Technology (IJEDICT) 3 (1), 39–53. Reinberger, M. L. en W. Daelemans. Unsupervised text mining for ontology extraction: An evaluation of statistical measures. Reinberger, M.-L., P. Spyns, J. Pretorius, en W. Daelemans (2004). Automatic initiation of an ontology. In Proceedings of the Conference on Ontologies, Databases and Applications of Semantics (ODBASE), Lecture Notes in Computer Science, pp. 600–617. Springer Verlag. Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy, en W. Lorensen (1991). Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, New Jersey. Sandin, D., T. Margolis, G. Dawe, J. Leigh, en T. A. DeFanti (2001). The varrier autostereographic display. In Proceedings of SPIE, San Jose, California, Volume 4297. Sandin, D., T. Margolis, J. Ge, J. Girado, T. Peterka, en T. A. DeFanti (2005, June). The varrier autostereoscopic virtual reality display. In ACM Transactions on Graphics, Proceedings of ACM SIGGRAPH 2005, Volume 24, pp. 894–903. Sariyildiz, I., R. Stouffs, . C ¸ ift¸cioglu, en T. B. (2000). Future developments of ict in the building sector. In Construction Informatics Digital Library.

BIBLIOGRAFIE

317

Schank, R. (1982). Dynamic Memory: A Theory of Learning in Computers and People. Cambridge University Press. Sch¨ on, D. A. (1991). The reflective practitioner. How professionals think in action. Ashgate, Aldershot. Segers, N. M. (2004). Computational Representations of Words and Associations in Architectural Design - Development of a System Supporting Creative Design. Ph. D. thesis, Eindhoven University of Technology. Segers, N. M., H. H. Achten, H. J. P. Timmermans, en B. de Vries (2000, August). A comparison of computer-aided tools for architectural design. In H. J. P. Timmermans en B. de Vries (Eds.), Proceedings of the 5th International Conference on Design & Decision Support Systems in Architecture, Nijkerk, pp. 325–340. Segers, N. M., B. de Vries, H. H. Achten, en H. J. P. Timmermans (2001, April). Towards computer-aided support of associative reasoning in the early phase of architectural design. In Proceedings of CAADRIA 2001, Sydney, Australia. Segers, R. (1998). Prototype van een interactieve case-base voor architectuur, ge¨ıllustreerd met woningen op helling. Master’s thesis, Katholieke Universiteit Leuven / Dept. ASRO. Shah, J. J. en M. T. Rogers (1988). Functional requirements and conceptual design of the feature-based modelling system. Computer-Aided Engineering Journal 5 (1), 9–15. Shneiderman, B. (1998). Designing the User Interface: Strategies for Effective HumanComputer Interaction (3rd ed.). Reading, MA: Addison-Wesley. Stefaner, M., E. D. Vecchia, M. Condotta, M. Wolpers, M. Specht, S. Apelt, en E. Duval (2007). Mace - enriching architectural learning objects for experience multiplication. In E. Duval, R. Klamma, en M. Wolpers (Eds.), EC-TEL, Volume 4753 of Lecture Notes in Computer Science, pp. 322–336. Springer. Swann, C. (2002). Action research and the practice of design. Design Issues 18 (2), 49–61. Tanriverdi, V. en R. J. K. Jacob (2001). Vrid: a design model and methodology for developing virtual reality interfaces. In Proceedings of ACM Virtual Reality Software and Technology, pp. 175–182. Ternier, S. en E. Duval (2003). Web services for the ariadne knowledge pool system. In Proceedings of the 3rd Annual ARIADNE Conference, pp. 1–9. Ternier, S., D. Olmedilla, en E. Duval (2005, June/July). Peer-to-peer versus federated search: towards more interoperable learning object repositories. In World Conference on Educational Multimedia, Hypermedia and Telecomunications (ED-MEDIA 2005).

BIBLIOGRAFIE

318

Unlimited, W. (2006). Virtual world of art [implant]: een project van het kunstenaarscollectief workspace unlimited, in co-productie met kunstencentrum vooruit. Persdossier. Retrieved from: http://workspace-unlimited.org/pers/ImplantPERSdossier.pdf. Van de Sompel, H., J. Bekaert, X. Liu, L. Balakireva, en T. Schwander (2005, June). adore: A modular, standards-based digital object repository. The Computer Journal 48 (5), 514– 535. Van de Sompel, H., R. Chute, en P. Hochstenbach (2008). The adore federation architecture. Available in Preprint. Van Den Driessche, M. en B. Verschaffel (2006). De school als ontwerpopgave - schoolarchitectuur in 1995-2005. A&S/books & De Vlaamse Gemeenschap/ Team Vlaams Bouwmeester. Van Gool, L. (1991). Similarity detection in computer vision. Ph. D. thesis, Katholieke Universiteit Leuven - Dept. ESAT - PSI. Van Gool, L., M. Waelkens, P. Mueller, T. Vereenooghe, en M. Vergauwen (2004a, April). Photo-realistic and detailed 3d modeling : the antonine nymphaeum at sagalassos (turkey). In The XXXII CAA - computer applications and quantitative methods to archaeology conference, Prato, Italy. Van Gool, L., M. Waelkens, P. Mueller, T. Vereenooghe, en M. Vergauwen (2004b, July). Total recall : a plea for realism in models of the past. In International Society for Photogrammetry and Remote Sensing (ISPRS), XXth ISPRS congress, Istanbul, Turkey. van Leeuwen, J. P. (1999a). Framework for feature-based architectural information modelling. In Design Systems Report nr. 1999/2. van Leeuwen, J. P. (1999b). Modelling Architectural Design Information by Features. Ph. D. thesis, Eindhoven University of Technology / Faculteit Bouwkunde. van Leeuwen, J. P. en H. H. Achten (1998, July). A feature-based description technique for design processes: A case study. In Proceedings of the 4th Conference on Design and Decision Support Systems in Architecture and Urban Planning, Maastricht. van Leeuwen, J. P. en H. H. Achten (1999). Feature-based high level design tools. In Proceedings of CAAD Futures ’99, pp. 275–290. van Leeuwen, J. P. en B. de Vries (2000a, August). Capturing design knowledge in formal concept definitions. In Proceedings of the 5th Conference on Design and Descision Support Systems in Architecture and Urban Planning.

BIBLIOGRAFIE

319

van Leeuwen, J. P. en B. de Vries (2000b). Modelling with features and the formalisation of early design knowledge. In Proceedings of the Third European Conference on Process and Product Modelling, Lisbon, Portugal. van Leeuwen, J. P. en S. Fridqvist (2002a, July). Design knowledge sharing through internet application. In Proceedings of the Concurrent Engineering Conference 2002. van Leeuwen, J. P. en S. Fridqvist (2002b, July). Knowledge sharing for collaborative design. In Proceedings of 6th International Conference on Design and Decision Support Systems in Architecture and Urban Planning, Ellecom, Netherlands. van Leeuwen, J. P. en S. Fridqvist (2002c, June). On the management of sharing design knowledge. In Distributing Knowledge in Building, Proceedings of CIB W78 2002, Aarhus, Denmark. van Leeuwen, J. P. en S. Fridqvist (2002d). Supporting collaborative design by type recognition and knowledge sharing. ITcon 7, 167–182. van Leeuwen, J. P., A. Hendricx, en S. Fridqvist (2001, June). Towards dynamic information modelling in architectural design. In Proceedings of CIB W78, Mpumalanga, South Africa. van Leeuwen, J. P. en H. Wagter (1997, August). Architectural design-by-features. In R. Junge (Ed.), Proceedings of the 7th International Conference on Computer Aided Architectural Design Futures held in Munich, Germany, pp. 97–115. van Leeuwen, J. P. en H. Wagter (1998). A features framework for architectural information. In Proceedings of the Artificial Intelligence in Design ’98 conference, pp. 461–480. van Leeuwen, J. P., H. Wagter, en R. M. Oxman (1995). A feature based approach to modelling architectural information. In Proceedings of the CIB W78 workshop 1995, Modeling of Buildings through their Life-cycle., pp. 260–269. van Leeuwen, J. P., H. Wagter, en R. M. Oxman (1996, August). Information modelling for design support - a feature-based approach. In Proceedings of 3-rd Design and Decision Support Systems in Architecture and Urban Planning., pp. 304–325. van Leeuwen, J. P., A. Wijnen, N. Benschop, en M. Eeltink (2004). Citizens and public services - a digital dialogue regarding building permits. In H. Rivard, M. Cheung, H. Melhem, E. Miresco, R. Amor, en F. Ribeiro (Eds.), Building on IT - Proceedings of the Joint International Conference on Computing and Decision Making in Civil and Building Engineering., pp. 3364–3373. Vanderdonckt, J., T. Clerckx, K. Coninx, en K. Luyten (2003). Derivation of a dialog model from a task model by activity chain extraction. In DSV-IS, pp. 203–217.

BIBLIOGRAFIE

320

Vergauwen, M. en L. V. Gool (2006). Web-based 3d reconstruction service. Mach. Vision Appl. 17 (6), 411–426. Verstraeten, R., P. Pauwels, J. Van Campenhout, en R. De Meyer (2008, September). Revit architecture 2008 and google sketchup as dataproviders for an energy performance calculation tool. In eCAADe 08, Architecture ’in computro’: practice, methods and techniques. The University College of Antwerpen, College of Design Sciences, The Higher Institute of Architectural Sciences, Henry van de Velde. Waelkens, M. (2002). Ontdekking van het verloren Sagalassos. Davidsfonds, Leuven. Watkin, D. (2005). A History of Western Architecture. Watson-Guptill. Weeghmans, L. en C. Licia (2005). Virtual arts centre of the future. In Conference on Digital arts & culture (DAC): digital experiences - Design, aesthetics, practice. Wong, N. H. (1994). Feature-based application in cad/cam. Technical report, Department of Industrial & Manufacturing systems Engineering, University of Hong Kong. Wong, N. H. (2004). Integration of cad and thermal simulation through industry foundation classes (ifc) product model. Technical report, Department of Building - School of Design and Environment - National University of Singapore (NUS). Yang, D., C. Eastman, en S.-Y. You (2004). Exchangeable subset of product model. In G-CAD Conference. Carnegie-Mellon University.