Selection representation context

[Noranius]

For the translation of ifc files to others, the selection of the geometry context would be helpful. The idea is to select the geometry representation context(s) by their ID(s). Hence, I have added this option to the IfcConverter.

In short, I have extended the initialize method IfcGeom:Iterator with an overload that it takes a set of strings as argument. During the initialization this set of geometry representation names is respected to select related representations.

[Moult]

Oh wow! I've been looking for a way to run create_shape or the iterator that only targets a particular context + subcontext + target_view - does this solve that problem?

[Noranius]

In case you mean to export a shape of an IFC file, which has a specific context, then you can try this. You can select multiple contexts. Just run IfcConvert with the -h parameter to get the help. There is a new option geometricRepresentationContext.

I haven't worked with target views, yet. Maybe you can provide some information about that?

[Moult]

I see in IfcConvert, I was hoping that this could also affect the Python bindings for create_shape or geometry iterator.

TargetView is an attribute of a representation subcontext. It has a similar purpose to the context name and the subcontext name. So, especially when creating drawings, it isn't enough to filter by context + subcontext (e.g. Model/Body or Plan/Annotation), it is also really important to filter by context + subcontext + target view (e.g. Plan/Annotation/PLAN_VIEW vs Plan/Annotation/SECTION_VIEW)

[Noranius]

Thank for that information. I'm working at my PhD currently and such information is very helpful 🙂.

Regarding the python bindings: many changes are in classes, which are not specified to IfcConvert, maybe you check the changes and ask again if necessary.

[aothms]

Hi @Noranius thanks for this. Sorry for the delays in replying. This is great. We kind of already had --plan and --model but it mixed various things and I think it's good to have more control over rep context.

Did you have a look at the logs on Travis:

https://travis-ci.org/github/IfcOpenShell/IfcOpenShell/builds/751025974

It appears that the PR introduced some issues on files:

0.12s$ /usr/bin/python2.7 tests.py

Traceback (most recent call last):

  File "tests.py", line 98, in <module>

    t = ifcopenshell.geom.tree(f, tree_settings)

  File "/usr/lib/python2.7/dist-packages/ifcopenshell/geom/main.py", line 134, in __init__

    ifcopenshell_wrapper.tree.__init__(*args)

  File "/usr/lib/python2.7/dist-packages/ifcopenshell/ifcopenshell_wrapper.py", line 556, in __init__

    this = _ifcopenshell_wrapper.new_tree(*args)

RuntimeError: Token $ at 2325 invalid string

The command "/usr/bin/python2.7 tests.py" exited with 1.

0.00s$ cd input

The command "cd input" exited with 0.

0.19s$ /usr/local/bin/IfcConvert -yv acad2010_walls.ifc acad2010_walls.glb

IfcOpenShell IfcConvert 0.6.0b0 (OCC 7.3.0)

Scanning file...

Done scanning file   

Parsing input file took 0 seconds

terminate called after throwing an instance of 'IfcParse::IfcInvalidTokenException'

  what():  Token $ at 2325 invalid string

/home/travis/.travis/functions: line 109:  9760 Aborted                 (core dumped) /usr/local/bin/IfcConvert -yv acad2010_walls.ifc acad2010_walls.glb

RuntimeError: Token $ at 2325 invalid string

Token 2325 in acad_2010_walls.ifc is

#10=IFCGEOMETRICREPRESENTATIONCONTEXT($,'PLAN',3,1.E-005,#9,$);
                                      ^

And indeed IfcGeometricRepresentationContext.ContextIdentifier is optional, so you better first check with hasContextIdentifier(). Unfortunately we never really went with boost::optionalstd::string in the attribute signature. But I will make that change in v0.7

Also instead of geometricRepresentationContext I'd prefer the simpler and shorter context for the command line arg.

I see in IfcConvert, I was hoping that this could also affect the Python bindings for create_shape or geometry iterator.

It would for iterator (more or less automatically I think, for that purpose maybe we should change the signature from std::set<std::string> to std::vector<std::string> less pure semantically, but the SWIG typemaps are nicesly setup only for vector). But not for create_shape() but that already has an option to specify the IfcRepresentation directly.

[Noranius]

Hi Aothms,
I'll have a look on that. Unfortunately, I have several other things on my desk currently. I'll get to this If the other stuff is ready.

Greetings
Noran

[Moult]

Bump on this PR :) I wonder if the new functionality in set_context_ids has any relevance on this?

[aothms]

Yes @Moult you're right. There is quite a bit of overlap. I forgot about this. @Noranius see 514c5eb

I like how @Moult used the settings to store the context ids. So that the iterator signature doesn't need to change. Maybe better would even be a designated IfcGeom::filter for it.

I actually like the strings a bit better as an interface because that would mean the same settings can be reused for different models.

But obviously strings are a bit more difficult to represent all criteria such as scale and targetview. So I can also understand the approach @Moult took.

I would propose we adapt this PR to interface with 514c5eb Basically just in IfcConvert to a quick resolve of the arguments passed from the command line to settings context_ids. From there on we can evaluate how we proceed.

Edit: are the volunteers to take this on? otherwise I'll work on it.

[Moult]

Bump :)