dinsdag 20 november 2012

Revisies bijhouden

Om inzicht te geven in de wijzigingen die in het ontwerp zijn doorgevoerd sinds de laatst verstrekte versie is het noodzakelijk om dit op je sheets duidelijk aan te geven. In een 2D pakket was dit relatief eenvoudig te bewerkstelligen door vanaf het moment dat je een set hebt verstrekt bij iedere wijziging een wijzigingspijl te plaatsen. Bij het wijzigen van een 3D-model is dit echter minder overzichtelijk: wanneer je immers vanuit een plattegrond een kozijn opschuift is ook iedere gevel en/of doorsnede gewijzigd waarop dit kozijn zichtbaar is. De kans dat je een wijziging vergeet aan te duiden in één of meer views is dan ook zeer reëel.

Veel gebruikte methode
Mede vanwege onbekendheid met de standaard methode en de gewoonte vanuit het voorheen gebruikte 2D-pakket, wordt bij veel bureaus gewerkt met een Generic Annotation of Detail Component in de vorm van een wijzigingspijl die handmatig op een view of sheet kan worden geplaatst. Deze moet echter handmatig worden toegevoegd aan iedere view waarop een wijziging voor komt en is daardoor dus foutgevoelig. Tevens zijn wijzigingen die op deze wijze worden aangeduid wat lastiger in tabelvorm op te nemen in of bij de stempel.


De standaard methode
De officiële Revit-methode behelst de mogelijkheid om wijzigingen aan te duiden met behulp van Revision Clouds en Revision Tags. De revisies kun je naar keuze per sheet of voor het hele model laten nummeren. Op je sheet kun je vervolgens een tabel opnemen waarin de revisies netjes worden getoond met nummer, datum en omschrijving. Ook hier gaat het echter om een 2D-annotatie die handmatig moet worden toegevoegd aan iedere view waarop een wijziging voor komt.

In het model geïntegreerde 'BIM' oplossing
Om het risico dat je een wijziging vergeet aan te duiden te verkleinen zou het beter zijn om een wijziging in het model zelf te registreren. Je krijgt dan de mogelijkheid om in iedere view de wijzigingen te laten oplichten.

Zoals altijd zijn er meerdere methoden te bedenken om dit voor elkaar te krijgen, maar mijns inziens is de onderstaande de beste:

  • Je maakt twee 'instance' *) Shared Project Parameters van het type 'text' aan, die worden toegekend aan alle soorten objecten, zowel 2D als 3D.
    • Revisie
    • Revisie_omschrijving
  • Maak een filter bij ieder object de zojuist aangemaakte parameter 'Revisie' controleert op de aanwezigheid van een bepaalde waarde. Bijvoorbeeld 'Revisie' equals 'A'
  • Voeg dit filter toe in iedere View Template en stel een Graphic Override in, zoals rood voor de Cut Line.
Zodra je nu een wijziging doorvoert aan een object, vul je bij de Properties van het object de letter in van de actuele wijzigingsronde en eventueel een korte omschrijving (bijv. "verschoven" of "toegevoegd"). De wijzigingen die je met gefilterde letter hebt aangeduid zullen nu bij consequent gebruik van de View Templates op alle sheets netjes met rode lijnen worden weergegeven.


Door in de template meerdere filters in te stellen en in de juiste volgorde op te nemen in je View Templates, kun je de Visibility/Graphics voor meerdere wijzigingsrondes voordefiniëren. Doe je dat niet, dan moet je het filter bij iedere wijzigingsronde even aanpassen, zodat de juiste revisie in rood zal worden weergeven.

Verwijderde objecten
Een aandachtspunt is dat verwijderde objecten vanzelfsprekend niet oplichten of getagd kunnen worden. Om een dergelijke wijziging toch zichtbaar te maken kun je, afhankelijke van de aard van de verwijderde objecten, de Host van het verwijderde object aanmerken als gewijzigd, of een speciaal (semi-transparant) wijzigingsobject ervoor in de plaats zetten.

Tabellen en wijzigingspijlen
De weergave in rode lijnen zal voor het verstrekken van tekeningen in PDF-formaat of kleurenprints voldoende duidelijk zijn. Wanneer je de tekeningen op de zwart-wit plotter afdrukt, vallen de rode lijnen natuurlijk een stuk minder op en zul je toch de vertrouwde wijzigingspijlen weer willen plaatsen. Omdat de wijzigingen op je scherm wel netjes rood oplichten, kun je alle wijzigingen snel met de standaard Revision Clouds en Revision tags verduidelijken. Daarmee heb je gelijk de mogelijkheid om de revisions te rapporteren in een tabel die op elke sheet of in je standaard stempel opgenomen kan worden.

Het klinkt misschien dubbel om na de geïntegreerde registratie van wijzigingen ook nog eens een 2D-annotatie toe te voegen, maar ik ben ervan overtuigd dat het niet veel extra tijd zal kosten, doordat je niet langer hoeft te zoeken welke onderdelen van het project nou ook alweer gewijzigd waren, terwijl de betrouwbaarheid van de registratie toeneemt.

*) Eventueel kun je de Shared Project Parameters nogmaals toevoegen als Type-Parameters, zodat je een wijziging van bijvoorbeeld een kozijnmerk maar op één plek hoeft te registreren.

Geen opmerkingen:

Een reactie posten