Group Category - Doors

Current State: 
Proposed
GUID: 
b401407d-3512-4c49-b0b8-94b2ef4b8d0b
Data Type: 
FAMILYTYPE
Visible: 
1
Description: 
A new Group Category called 'Doors' to cover all aspects about doors, stops, grilles etc
User Modifiable: 
1

Comments

That's a good idea, but may we first flush out a list of door specific parameters, possibly with real life project examples to discuss?

As I understand it this is a proposal for a user defined Group in the shared Parameter file. Why does it have Datatype: "FAMILYTYPE" and Group: "Dimensions"? 

Does the site need a different way of proposing Group names?

 I would second the idea to flush out the list first.  It seems likely that a bunch of parameters which might be useful to doors would also apply to other opening types.  For instance RoughOpeningWidth or HardwareSet.  I am sure there are a bunch we could all think of.  It would be nice if there was a way to list which parameters are relevant to which element categories.  I'm new here so perhaps there already is or perhaps that would over complicate things. Thoughts?

ismith, interesting suggestion to add element categories to the parameters. I will look into this as a feature.

I don't see the point of being overzealous on using the same parameter for multiple disciplines and purposes. 

In day to day use we only need a GUID for parameters that hold particular data. The RoughOpeningWidth for a door is not likely to get confused with the RoughOpeningWidth for a duct. lnfact you probably want to make sure they don't get confused with each other, and hence give them then own GUID.

IFC uses this approach. Parameters are grouped under "Property Sets"  (bit like Groups in Revit Shared Parameter files), and GUID for RoughOpening under Doors pSset is different to GUID for RoughOpening under MechanicalDuct pSet. 

I think AntMC brought up a good point in a previous discussion regarding whether or not elements need to be scheduled together or not. However we should also consider the needs of other trades using the data. For example, would it make sense for a general contractor have a single parameter for RoughOpening that they could apply to both windows and doors? Would it help with, say, cost estimating by having a single parameter?

Does anyone have any BIM-savvy GC contacts that they can invite to this conversation?

Sure a single parameter might be useful to contractors but what about everyone else? What if you wanted to compare openings only for ducts against duct sizes? 

Separating parameters means more information means more uses. 

It is always dangerous to decide on parameters based on what you "think" they might be used for. These decisions must be based an evidence. Or alternatively use an existing standard where others have already done (most) of the hard work. 

It is always dangerous to decide on parameters based on what you "think" they might be used for. These decisions must be based an evidence. Or alternatively use an existing standard where others have already done (most) of the hard work. 

Right, which is why I am not making decisions, but rather asking for more input.

Separating parameters means more information means more uses. 

For the sake of simplicity, I would actually think less buckets would simplify how we could pull data from the Revit model. For example, say I had a Dynamo graph that uses the node Element.GetParameterValueByName, I could use the graph with less modification if I used the same shared parameter name. This is only one example of why less parameters would make things easier for a consumer of the model, but I am open to hearing why it is preferred to use multiple shared parameters that essentially store the same data.

Also, for the rest of the community, what are everyone's thoughts on all of this?

But what if you want your Dynamo routine to only find openings for ductwork? How would you do that without a lot of extra nodes! 

When you say "essentially store the same data" you are making a massive assumption. How do you know it is the same data? 

The thing to remember here is that the name of a parameter is not important to manipulating data. The name is only there for humans, so they understand what it is for. Computers only care about the GUID.

So just because a name is the same doesn't necessarily mean the data is the same.  

Fair enough, I suppose whether or not a parameter holds the "same data" is up to the consumer.

Let's consider a simple parameter such as EquipmentId (which currently doesn't exist on OpenRFA). Would you propose we have several parameters such as EquipmentIdMechanical, EquipmentIdElectrical, EquipmentIdPlumbing? Why wouldn't we use a shared EquipmentId parameter across all categories?

Yes, there are cases where parameters should be common. 

But the basis for that shouldn't be because the name is the same. Probably a good place to start is that data used for facilities management should generally be common, construction not so many are common, design mostly not common. 

 

Great point. This could become the basis of how we decide which parameters should be common and which should be more specific. Perhaps we can try to hash this out in another thread?

I would agree that it would not make sense to use parameters just becasue the name is the same, but in my mind it would make no sense to have seperate parameters for EquipmentIdMechanical & EquipmentIdElectrical.  It is the same datatype and intended usage.  I would advocate that we need some way to present the intended use of parameters which does not seem to be captured currently.  Perhaps we can begin to develop a cascading parameter structure, where each group or whatever we call it would have some common parameters and then cascading down more parameters are availiable to products / elements  with increasing specificity.  For instance you may have a group of ceiling parameters that apply to all types of ceilings then drilling down we would find some parameters which are specific to accoustic ceiling tiles some which are specific to hard ceilings.   Cascading provides the flexibility to increase speficity and data storage without needing to worry about managing all the redundancy and potentially creating issues where certain elements are assigned parameters that are not really relevant.  This would allow parameters whose usage has a more global scope such as GlazingArea to be applied to doors, windows, curtain wall panels etc.  In a case like this it would be a huge benefit for calculating total building glazing percentages to have the parameters and data normalized across several categories.  I suggested including some definition of element categories becasue that is the particular method that revit currently assigns and partitions the parameters in the project environment but perhaps there is another method that would work.  

Good idea but a heck of a lot of work. Why not base it on an existing standard? At least start with one and adjust it. I know no standard is perfect but it would avoid repeating a lot of work others have already done.    

Introducing collaborative shared parameters.

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