Hi there from Germany,
We’ve checked, why in some cases we get a classification for Revit elements, in some not. Same with levels an so. in the family instance f.ex. is a category property, while it isn’t in RevitStair for example. but there is a RevitElement implemented.
Doesn’t it make more sense to use this RevitElement as base for all revit classes and move all base properties here?
Additionally some Revit classes are in the same cs file as the speckle core class. for ex. pipe. It has a speckle allover implementation + an revit part.
My question, shall we reorg such things an make a pull request? namespaces and so on should stay the same, so no impact in related implementations.
Additionally
it makes sense to transfer the builtin category directly, not in display names. Therefore we should add a new property ( maybe category_enum or so) to avoid breaking the existing implementation.
What do you think?
We have created class definitions for all elements types supported by Speckle such as Wall and RevitWall. Instead, RevitElement is just placeholder type for all the other elements for which we haven’t yet created ad-hoc conversions (and are only supported Revit>Speckle).
We initially had set up the Revit classes just as you describe, inheriting from a base RevitElement with all the common properties, but it was later changed by @dimitrie he can clarify a bit more why; same goes for having Wall and RevitWall in the same file
In regards to the built in category, I’m not sure what you mean, can you provide a quick example?
Hi Matheo,
regarding the category,
, currently there is only a translation pushed to Speckle. For example Wall instead of ost_walls. Which makes it language depending and difficult to consume on the receiving side.
I would prefer to add a new prop for a classification or so. Than we can push here the enum value or ifc entity or omni class… Depending on the sender.
It wouldn’t break existing implementation.
Many greetings from Germany,
Tim
Those were meant as a more human-readable version of the built in categories, but I understand where you’re coming from, so maybe we just replace it with the built in ones?
Hi Matteo, yes, this should stay untranslated, so it works in all languages. We can go with the original one?
But, over the years there has been a lot Bic added. So it is version specific… Shouldn’t we simply add a text property and not an enum, so it is up to the receiving software to make the best out of it? While sending, we can simply pass through the original from rvt element.
Cheers, Tim
