Load classification system via ruby code

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.