Rooms and Room Tag Parameters

[mdhutchinson]

Actually, I am working on developing a Room Tag with a good portion of it's functionality driven by Dynamo. (I am very green with Revit... but the Dynamo side is coming along fairly well.)

I have many questions... but lets start with just a couple that are decidedly on the Revit side.

Somehow, admittedly through trial and error, I've been successful in creating a couple Room Parameters:  Ceiling Height, and Type.

For the Ceiling Type, I wanted a ListBox to show up in the Properties palette that would provide the user a list to choose from.  I've not been successful in finding a way to pre-populate the list with acceptable 'standard' values, however I can select the Room and Type an acceptable abbreviation. (ACT, GYP, PLC and EXP). Once these are there, that can be selected for new rooms. However if the Rooms are deleted from the model and from a Room Schedule, the list of values are gone.

Let's start with two questions involving Parameters:

1. Is there some solution I am missing that would allow me to pre-populate a list of acceptable values?
   I suspect the only way to pre-populate the list with Ceiling Types is by somehow using Family Types under my Room Tag Family, one Family Type for each or our 4 (or more) ceiling types.
2. I mentioned above that I used Trial and Error to get a list box for the Ceiling Type Parameter. In an effort to get this, I had created a Family Parameter on my Room Tag and set it's formula to ="Number to Select Type: 1=ACT, 2=GYP, 3=PLC, 4=EXP" ...(which I found by multiple Google Searches), but I'm not at all certain this is what did it, because I can blow away this parameter and the listbox is still there.  The Ceiling Type just showed up at one point. Could someone explain how I might have gotten a listbox to show up?

NOTE: The Ceiling Height value gets filled in when I run my Dynamo graph that finds the Ceiling above the Room.

See images attached.

[ToanDN]

1. Place a few Rooms with all the ceiling type value that you need in a different Phase.  Now the list dropdown will be populated with those types.

[SteveKStafford]

I believe the first image is the result of a New Type being created in the family. The second drop down is the result of different values being applied to the parameter value for the rooms in the project. Revit stores all the values that have been entered so far and provides it in that list format. Values are added as users enter and removed as they change values which eliminates the presence of a specific value. If no Ceiling Type value of ACT has been typed in for a Room, it isn't offered. As soon as someone adds ACT it will be available for other rooms. If someone changes the last room with ACT assigned to GWB instead, for example, ACT no longer appears in the list.

Just in case it isn't already understood, the data you're discussing is not in the tag, it is stored with the room element. Tags display information that is stored in the room it is attached to. When you run a Dynamo graph to fill in a tag with a value it is stored in the room's parameter. Technically a tag could graphically indicate something else but if so it isn't connected to the room's parameters, those that are stored in the room the tag is attached to.

In the context of rooms there isn't a built in way to provide a fixed drop down list of types to select. Unless you create some custom program/interface to assign ceiling types to rooms. Also consider that providing a fixed list of ceiling types this way doesn't correlate to the ceiling(s) that has been defined in the model either. I can type or choose ACT but a user can place a GWB ceiling in the room and it will still report ACT.

Fundamentally Revit doesn't tell us what ceiling height or type is present for rooms automatically (not yet anyway) because more than one ceiling can exist and they can be at different heights and/or types. Ceilings can also span more than one room.

A graph that queries rooms and their boundary elements could provide the ceiling type or another ceiling parameter you choose to define. This way a room can know what ceilings are actually within its boundary and then be used to show that information with a tag, or a schedule.

To get there, a shared parameter assigned to the Room category must exist so there is a place to store the data. A tag family must also use this same shared parameter so Revit understands the definition for the Ceiling Type is the same one.

I think of the shared parameter file as a dictionary and the parameters we store there as common definitions. The notion of sharing relates to projects and families sharing a common definition because each are separate by a boundary, their file types. When a family is added to a project this shared definition allows Revit to connect the dots, understand their common definition, though residing in separate files.

Then the graph would need to run through all the rooms and their boundaries and store the result in this shared parameter associated with rooms. If there is more than one ceiling the graph would have to reconcile how to store each unique value in the parameter. That situation normally causes Revit to display blank values, when more than one value is present. It sounds like it would be necessary to combine strings and then store that result.

Good luck!

[SteveKStafford]

I saw @ToanDN's reply after my reply. I didn't suggest what he did because users can still enter anything they like into the parameter, even if the correct intended values are present already. That didn't seem to meet the criteria I assumed you to be considering. If my assumption isn't correct then what he suggests gets you there.

[ToanDN]

Another way to pre-populate a list box without creating mock-up Rooms is via a Key Schedule.

[SteveKStafford]

My first reply started down that route...his focus on tags talked me out of it. It would be nice if they'd remove the barrier between Schedule Keys, Shared Parameters and Tags.

[ToanDN]

If he contents on using only the built-in parameters, not shared parameters, then they are tag-able.

[SteveKStafford]

That's close...a shame it's still disconnected info...but close 🙂

[mdhutchinson]

---

@ToanDN wrote:

If he contents on using only the built-in parameters, not shared parameters, then they are tag-able.

---

So, using this method, the user has to select 1, 2, 3, 4, etc. to set the values accordingly? 

If so, then there's no good way for the user to know which Ceiling Type he is selecting, until the selection is made, or if he opens the key schedule itself.

Is this correct?

Also, what are you referring to as "built-in parameters"?

[Anonymous]

No, @ToanDN just did a quick example of how it would work. New data rows in Key Schedules automatically are numerical, but you can rename them to whatever you like. Just name it the same, and the user won't even notice the background process. And built-in parameters mean the ones that Revit comes with Out-of-the-box, not user-created custom parameters.

[ToanDN · Accepted solution]

---

@mdhutchinson wrote:

---

@ToanDN wrote:

If he contents on using only the built-in parameters, not shared parameters, then they are tag-able.

---

So, using this method, the user has to select 1, 2, 3, 4, etc. to set the values accordingly? 

If so, then there's no good way for the user to know which Ceiling Type he is selecting, until the selection is made, or if he opens the key schedule itself.

Is this correct?

Also, what are you referring to as "built-in parameters"?

---

Edit: I didn't see @Anonymous response before this.  We are on the same page.

Not necessarily.  You don't have to use 1, 2, 3, 4.  You can use any value to clarify your intent.

[mdhutchinson]

Thanks Guys,  This worked and provides what I need (at least in part)

This is where I am presently.

I'd like to get the related parameters together in the properties palette, but there doesn't seem to be a way to do this.