Stored Parameter data on Areas, is this a bug?

Building a pretty big script for doing area calculations, Looking into property data saved on Areas, there’s 2 duplicate sets of parameters for built-in parameters. I assume one is a system parameter, and the other being exposed more to the user. What’s strange is I get a list of Elements in return when I Element.GetParameterValueByName.
If this information was accessible, it would really make my life easier.

Some parameter values are elements. Things like Category and Area/Space Types have to have a definition for what that value represents - that’s an element. The most common example of this is Family and Family Type. Both are parameters of an element instance represented by an element object.

As for the duplicates, it’s not really anything to worry about. The parameter could be inherited from multiple classes or somehow otherwise show up in mulltiple areas for certain categories.

1 Like

Is it possible to quarry the data from them? Digging multiple levels into lists might be a bit too much for what I need to do. I want to ignore gross area plans during my calculations, and having trouble getting class information off the areas I can use for sorting. I want to quarry the project to read everything created internally so I can dump anything gross to process. It’s odd they’re two different elements under the same class.

You should be able to get the Element.Name from the Area Type element and use that to filter your areas. MEPover also has a GetParameterAsString node that will return the “user-facing” value of a parameter as a string.

I try to avoid custom nodes whenever I can. Package management on our network is a pretty big challenge, so keeping things as OOTB as I can for now. Everyone here is pretty new to Dynamo, so I don’t want to make it a ‘pain’ just getting started. (We have 25 offices, 1600 users total.)

You can use ootb nodes to get the name of the element like I mentioned. The custom node only saves you a tiny bit of space in this case.