Current State: 
Data Type: 
Program Outline Heading Level 1
User Modifiable: 


This parameter would be grouped under the Architecture discipline / namespace  and applies to rooms and areas.  Used for tying spatial elements to the developed space program for a given project

We had a long discussion for a previous parameter about using generic "title" parameters:

I see this being a similar case, where perhaps rather than naming these multiple heading parameters as ...Heading1, ...Heading2, and ...Heading3 we should look at what data we are actually storing in these headings. In other words, can this be named something more specific?

I think in general making the parameters more specific in their names is a good goal.  I'll think over how this could be changed.  The issue is that very often projects in the programming stage have different terminology and criteria for how their spaces a broken down.  The generic headings allow the same parameter to be implemented on many different types of projects, which allows the specific space program to drive the categorization terminology.  For instance "Department"  is a built-in parameter but projects are not always split up this way, therefore in many offices I have worked with we create our own parameters instead of using this.  It makes reporting much easier for the clients to use their system.   In a school we might have a space category "Classroom Sets"  on a hospital we might have a similar division "Surgical Suites".   One suggestion be to break it down to  parameters like ProgrammingDepartment, ProgrammingUseGroup, ProgrammingSpaceType,  but the problem is not all projects would be dividing the program by use group etc. all the time. 

Anyhow I am open to suggestions, I don't have an imediate solution, but I would suggest that whatever direction it goes it needs to be sufficiently adaptable to accomodate different projects in such a way that the same handful of parameters are implemented on each project.  We don't want to be in a situation where we use these 3 parameters on one project and another 3 or 4 on another becasue it takes way more time to automate plugins, templates etc.


Sounds like we are on the same page. My experience is more on the MEP side, so I'm not sure if my feedback is of any value, but I can try!

We started prefixing some parameters with the word Building

I wonder if that is enough to meet your requirements for departments etc. while not duplicating built-in parameters. So for your examples, would it work if we created shared parameters for BuildingDepartment, BuildingUseGroup, BuildingRoomSet, etc.?

Introducing collaborative shared parameters.

Join OpenRFA to help build the new master shared parameters for Revit.