Load classification system via ruby code

[icehuli]

Hi all,

Does any know if it is possible to load classification system into a model via Ruby Code? If yes, how? Thanks!

[Aerilius]

Classifications are not yet exposed via the API.
Developers like to work with a well-designed, consistent and logical API. Once "not so good" features (unlogical, inconsistent, misspelled, errorprone) have been added to the API, they can not be removed anymore because someone might potentially rely on it already. Because of this, a good API needs time to be designed, and the SketchUp developers need time to get experiences with the features that could be useful for plugins.

[tt_su]

As Andreas mentions, classifier manipulation did not make it into the SketchUp Ruby API this round. The classifier system was such a big change that it was in the works close uptil release which didn't leave us with enough time to implement a proper API for it.

[icehuli]

Thanks Aerilius,
Thanks tt_su,

I am waiting for the next release.
Anyway it is nice to see that SketchUp is on the way to BIM.
I have figured out how to add a classification to an entity, just in case that anyone would like to try the [highlight=#ffff00:3oppyo7z]undocumented[/highlight:3oppyo7z] API function " add_classification".

group.add_classification 'IFC 2x3', 'ifc;IfcBeam'

[brewsky]

@tt_su said:

The classifier system was such a big change that it was in the works close uptil release which didn't leave us with enough time to implement a proper API for it.

Ah! Too bad... That's why I couldn't find it in the documentation.
I really would like to have API access to the new classifiers.
Apart from the existing unofficial :add_classification and :remove_classification I would also like to have a :get_classification method.

Cheers!
Jan

[tt_su]

Yea, the method set was incomplete which is why we never documented them. Once there is a complete set we'll document them and make them part of the API. At the moment, if you use them, keep in mind they could change - so keep any eye on breaking changes in next release.

[zilony]

@tt_su said:

Yea, the method set was incomplete which is why we never documented them. Once there is a complete set we'll document them and make them part of the API. At the moment, if you use them, keep in mind they could change - so keep any eye on breaking changes in next release.

So we have a new version. Has anything changed on the classification and the API?

[tt_su]

Yup!

http://www.sketchup.com/intl/en/developer/docs/releases

http://www.sketchup.com/intl/en/developer/docs/ourdoc/classifications
http://www.sketchup.com/intl/en/developer/docs/ourdoc/classificationschema

http://www.sketchup.com/intl/en/developer/docs/ourdoc/componentdefinition#add_classification
http://www.sketchup.com/intl/en/developer/docs/ourdoc/componentdefinition#remove_classification

http://www.sketchup.com/intl/en/developer/docs/ourdoc/componentdefinition#get_classification_value
http://www.sketchup.com/intl/en/developer/docs/ourdoc/componentdefinition#set_classification_value

[blruuska]

Not able to set enumerated "choice" type attributes via the API. For example, the IFC 2x3 CompositionType for IfcBuilding provides the values "complex", "element", or "partial". It can be set manually with the UI, but not the API:

selection = Sketchup.active_model.selection
definition = selection.first.definition
definition.add_classification("IFC 2x3", "IfcBuilding")

path = ["IFC 2x3", "IfcBuilding", "CompositionType", "IfcElementCompositionEnum"]
success = definition.set_classification_value(path, "element")

Error; #<RuntimeError; Unexpected attribute type>
<main>;in `set_classification_value'
<main>;in `<main>'
SketchUp;1;in `eval'

Am I doing something wrong, or is this kind of value setting not yet available in the API?

---

[Dan Rathbun]

I think classification features are Pro edition ONLY of SketchUp version 2015 ?

The API says:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/componentdefinition#set_classification_value
... which says:
@unknownuser said:

• Raises NotImplementedError when trying to set the value of "choice" attributes.
• Raises RuntimeError if the attributes being set are corrupt.
• Raises TypeError when trying to set a value that is not valid for the attribute.

That looks like a "choice" attribute. The API doc is incorrect on the exception class being raised, but it looks like setting these kind of attributes is not yet implemented.

I even tried a ordinal integer without success. The same exception occurs.

[blruuska]

Dan, Thanks for verifying. It is surprising that NotImplementedError wasn't raised, if that is the case here.

[brewsky]

HaHa!!!
I just found out that classifications are stored as nested attribute dictionaries!
That means you can set classifications(if you're a bit careful) using the "normal" way with "set_attribute", I guess even in the free version...
A "IfcBuilding" for example gets an attribute dictionary called "IFC 2x3" which gets a nested attributedictionary "CompositionType" which gets a nested attributedictionary "IfcElementCompositionEnum" in which "value" can be set as "partial"

Cheers!
Jan

[Dan Rathbun]

@brewsky said:

A "IfcBuilding" for example gets an attribute dictionary called "IFC 2x3" which gets a nested attributedictionary "CompositionType" which gets a nested attribute dictionary "IfcElementCompositionEnum" in which "value" can be set as "partial"

Oh that is correct... I forgot that. (Don't interact with classifications much myself yet, via code.)

But... the actaul value in the nested dictionary is a string "partial" ?
Ie, not the integer of the choice ?

How would coders check if a value was one of the proper choices ?
It looks like not much but the name, namespace and the <=> sort comparison operator have been exposed for the ClassificationSchema class.

They have not exposed the filepath to the schema file from which it was loaded, so coders would need to go try to find skc & xsd files that match, in order to do their own XML parsing.

[brewsky]

@dan rathbun said:

But... the actaul value in the nested dictionary is a string "partial" ?
Ie, not the integer of the choice ?

Yes indeed, a string. There is another atribute called something like "options" which contains a list of valid options (as strings). The entire classification scheme that goes with the selected ifctype(ifcBuilding) is stored inside the componentdefinition. So you can check validity right from the definition without having the original source scheme.

[blruuska]

Ah, very interesting, thanks brewsky!

[Dan Rathbun]

@brewsky said:

The entire classification scheme that goes with the selected ifctype(ifcBuilding) is stored inside the componentdefinition. So you can check validity right from the definition without having the original source scheme.

Oh that is right. I remember now. I did not like this when I realized it.

This is going to bloat model files.

Why did they leave them in each definition, when they could have attached only one schema to the definition list that needy definitions could reference? (rhetorical)

I realize they must be saved into components for 3DW & local libraries, but ...

[brewsky]

@dan rathbun said:

This is going to bloat model files.

Yes, I'm glad they DO store the scheme inside the model so you don't have to redistribute it seperately, but more than one "copy" in the model indeed seems bloated.

I'm curious what happens when you upgrade a model from IFC 2x3 to 2x4(when a scheme is available). I'm affraid you would have to re-assign every single property... and manually remove the old scheme to get rid of the duplicate classifications.

[tt_su]

@blruuska said:

Dan, Thanks for verifying. It is surprising that NotImplementedError wasn't raised, if that is the case here.

Ackh! Yea, something is amiss here. Not sure if we intended to support enumeration type in the initial release of the API - but if that's the cause it should have been NotImplemented. However, I might confuse this with the "choice" type. Maybe something changed in the last moment. I need to investigate.