search

Autodesk / revit-ifc

IFC for Revit and Navisworks (2019+)
481 stars 194 forks source link

Dealing with duplicate IfcExportAs parameters #391

Open Moult opened 2 years ago

Moult commented 2 years ago

I'm dealing with files where, perhaps due to lots of copy pasting of a shared parameters files, there are many duplicate project parameters all with the same name "IfcExportAs". It is not obvious to the user which of these parameters actually are used during the export process.

It also runs the risk of users deleting the wrong IfcExportAs parameter and losing a huge amount of work doing IFC class mapping.

AngelVelezSosa commented 2 years ago

Our IFC roadmap includes getting rid of the magic IfcExportAs parameter and replacing it with a built-in parameter to avoid this sort of issue. I do have a question about how upgrade should work. Currently, the intention is that the new built-in parameter would get the value of the old IfcExportAs parameter on upgrade, but that we wouldn't delete the shared parameter, since it could be used for who knows what. The IFC code would ignore it, though, and only use the new parameter. Thoughts? New files of course would have no issue - there'd be no need for a shared parameter.

Moult commented 2 years ago

Fantastic! Getting rid of it in favour of a built in one is a great solution.

Agree with the intention to inherit the old IfcExportAs parameter on upgrade, but don't delete the parameter, and please delete the references to it in the code. Right now there are so many fallbacks that can change the outcome that users have the follow a complex decision tree or do test exports to see what happens.

Due to the complexity of getting the right IFC export class, we've actually now started a new approach of advising consultants to ignore IfcExportAs and use our own parameter.

AngelVelezSosa commented 2 years ago

OK, good, that was also my thought. Other thoughts are also welcome.

tsolsen commented 2 years ago

Wondering how this will play out, implementation wise? Would sound like a good idea, to stay as close as possible, to the BS naming af the parameters, to make the logic more obvious to the end user.

Now when looking at new parameters, I'd expect them to be lookup style parameters, ala Assembly Code (or even better, ARCHICAD style classification, so a new parameter type). This would certainly ease the implementation, and improve quality quite a bit. No fun in having to hunt down the correct values on the BS website or a spreadsheet.

I'm in the minority. But having implementet and filled ExportAs[Type] and ExportType[Type] as locked parameters through a formula, in all library families, I'd appreciate some assistance in effectively not only transfering into the new paramerers, but also removing the old ones. A .dyn /.py /C# solution would be sufficient, to allow for admin of parameters in families (remove, add, fill). :)

@AngelValezSoza I have previously made a similar comment in the beta fora. Post "Ifc parameters".

AngelVelezSosa commented 2 years ago

I am scared to remove the old parameters automatically, since they may show up in schedules, or even be used by other add-ins. However, providing some sort of macro that you could use seems reasonable enough.