In Architecture, one of the most important parts of the whole process is to decide what to build. In the US, we call it “Programming”. In Europe, we call it “Briefing”. And I’m sure in some other region around the world it’s called something else!
Essentially this is a process by which we ask questions about the spaces we’re designing for. Questions such as, “what size”, “what finishes”, “what height”, “what equipment”…once we have this information, then and only then can we design something. We can later assess and gauge whether we did a good job by ensuring that at least we met these agreed upon requirements.
Arguably, the most important “what” question is about size: the “Program Area” or “Target Area” of a room. Why isn’t this a built-in parameter in Revit rooms? This is becoming increasingly frustrating as we start looking at API tools to enhance our workflow. For example in the SDK, there is a handy “Room Schedule” tool (thanks for pointing this out Guy!) and the example Excel file has a column for “Room Area”. This example is “flawed” if you ask me, because that column should be called “Target Area”. It’s not “Room Area” until the room is placed in an enclosure This API tool can create Revit Rooms from an Excel workbook and can also update the workbook from the Revit Room data.
Assuming the column was called “Target Area”, the only way to really populate that parameter in a project is to add it beforehand to your project/template file as a Project or a Shared parameter and customize your code to write to it. But WHY NOT have it already built-in? The act of programming is central to Architecture, and the information collected during this process should be easy to record in our B I M. It should not require additional custom parameters. Because of this, we cannot exploit the full potential of this SDK tool as it needs further customization to have it copy the “Target Area” column to our version of “Program Area” in a project.
Another example where we have to deal with this same issue is when using Trelligence Affinity with Revit. Even in this case we have to customize our installs to map to the correct Program Area parameter. These are totally unnecessary pains that both 3rd party software developers and us working in this field have to endure. We’d all rather direct our energy to more important parts of our respective projects instead!
Posts
4 comments:
Is your firm implementing Trelligence Affinity? We are investigating that as well. There seems to be some real possibilities there.
Hi Erik, we own a couple of seats. Yet it's difficult to implement. It's not the technology that's difficult, it's the people :) The programming group is small, so it's statistically hard to find people with a "go get it" attitude to learn and use it. In the Texas region with the kind of projects we do, the benefits would be small (although I'd love to seamlessly move data between programming phase and the design phase in Revit).
For the NorthEastern offices, its use would be a plus because they get into a LOT of detail, and they produce "ed-specs" (some call them "datasheets" I guess), so capturing that information in a database would be a great asset. It can have a lot of advantages, such as early schematic pricing, etc. The problem is...should I spend my time pushing this, or can I have a better impact somewhere else right now? I've tried to push key people to use it, but it has not moved much yet, so it needs more TLC.
I will go with you. I believe that normally Revit should offer the possibility to control areas better with no need of additional software. AutoCAD Architecture (ACA/ADT) does that very well (since the earliest versions): "spaces" offer the possibility not only to have a target surface but also to constrain that surface. In that way you can change the length of room and the width adapts to keep the surface of the room. In Revit you can make an area/room plan only with area/room separation lines. So in a way you can produce a program diagram. But you cannot control the area/room by changing its surface and the separation lines are not parametric in order for you to be able to change their length and keep their area/room surface.
The surface constrain is a very essential and basic functionality of an "area object". In the office I work, one of the first things we do in our workflow is to "layout the program" in ACA/ADT. By constraining the surfaces we can easily make different hypothesis on the overall building width and have a better control over the global to rentable surface. I also have to add that for sustainable architecture it is important to be able to control the factor "room area"/"exterior elevation surface" of the room.
This is one of the reasons I believe Revit has still some workflow disadvantages.
aghis
Aghis, thanks for your insight. I wasn't even going that far. My premise is that as a minimum, a param. for Target Area should be standard OOTB. This would probably be the best universal name too, and I used API tools as examples of why it's sorely required.
Your points are extremely valid. We have a guy that has worked with ArchiCad and he likes the "zones" feature because you can stack and design spaces before you even put any walls/separation lines. Yeah, we can do something similar with masses, but you cannot flex one side and have the other adjust automatically to maintain the area. Affinity can do that too, and actually works in ArchiCad's line of thought.
I do like the fact that rooms get automatically bound with walls, but they somehow need a switch to turn that feature on/off at will. So in SD, you place a room and it would have the area you specify in Target Area, you adjust the shape and any change results in an automatic adjustment so Target Area is maintained. Then as you flush out walls (or perhaps have an automated feature to automatically place walls at room boundaries), you "unlock" the room and let it flow up against the surrounding walls. It would then start reporting "Actual Area" and keep "Target Area" intact.
Post a Comment