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!