Hi @ToanDN, @Anonymous, @GlynnisVP,
thanks a lot for your answers.
I totally understand it from the Owners point of view and for them it totally makes sense.
The thing is that I am on the other side trying to establish a standard, teaching it and developing work-flows and tools to ensure the quality. This is a crucial thing to have on the radar while doing so.
My strategy so far was to encode pretty much everything* the properties instance based on the elements with Shared parameters loaded as project parameters. The SP have an "SP" suffix that shall tell the users this values can go everywhere.
I chose this way because i think the Type catalogs will explode if i setup too many properties in the type which makes it harder for new users and developing of all the content takes way longer. - not to mention to check if the values of type properties fit the name of the type
e.g.
ConcrFloor_C2024_20cm_Ext_FireRating90_Uniclass_LoadBearing:True_ConstrurtionMethod:InSitu.......
Every parameter in include into the Type needs to be part of the name and acts as a multiplier for all the possible types. So this can easily go up to hundrets even thousands. This is impossible for new users to efficiently deal with.
My strategy to fit this demand:
- Keep the "I" on instance parameters as far as possible
- establish, document and teach the company standard
- create tools for automatically quality check
- Write a program that converts the project to the demanded one.
I guess it is not so hard to create a tool that creates all the demanded family types and sets the correct one for each instance based on its instance properties.
This way we keep the users efficient and do not need to change the rules of the game on every project.
What do you think?
* except for material since this has an influence on the graphical display on the sheets, and late i guess for big LOD steps also
Jeff Wurth
BIM Manager | Dipl Ing. Bauingenieur
LinkedIn