Skip to content

IfcConvert: --bulding-storey filter#150

Closed
andersgb wants to merge 2 commits into
IfcOpenShell:masterfrom
andersgb:building-storey-filter
Closed

IfcConvert: --bulding-storey filter#150
andersgb wants to merge 2 commits into
IfcOpenShell:masterfrom
andersgb:building-storey-filter

Conversation

@andersgb

Copy link
Copy Markdown
Contributor

When converting large .ifc files to .obj, I wanted to select specific storeys. Is this a feature of general interest?

Especially the second commit is somewhat hacky, let me know if you want me to clean this up.

Enables filtering of products, alongside the existing
names_to_include_or_exclude and entities_to_include_or_exclude filters.

The added set does not follow the --include or --exclude commands, it
only includes. The argument for doing this is to enabling filtering of a
large sub-set of the IFC, e.g. a building or a storey. --include and
--exclude will then only affect the selection within this subset.

products_to_include being empty is interpreted as "no sub-set
selected", i.e. select entire IFC.
Which will filter away everything that is not contained in the selected
building-storey. Uses a simple substring match (std::string::find) on
with the provided argument.
@Stinkfist0

Stinkfist0 commented Oct 21, 2016

Copy link
Copy Markdown
Contributor

Hi. I made this a while back: Tridify@91051f0 (the original code here might contain some shortcomings that were fixed later on). I've been planning to submit it to here but never really got around to it yet. So my implementation one can do e.g. --include --names "Level 01" --with-children, but it also works for e.g. buildings or any aggregate types.

if (!building_storey.empty()) {
bool found_storey = false;
IfcParse::IfcFile *ifc_file = context_iterator.getFile();
IfcEntityList::ptr storeys = ifc_file->entitiesByType("IfcBuildingStorey");

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better use the templated version: ifc_file->entitiesByType<IfcSchema::IfcBuildingStorey>(), than you get a typed list back.

IfcEntityList::ptr storeys = ifc_file->entitiesByType("IfcBuildingStorey");

for (IfcEntityList::it i = storeys->begin(); i != storeys->end(); ++i) {
if ((*i)->getArgument(2)->toString().find(building_storey) != std::string::npos) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the typed instances, you can simply say storey->Name(). Beware that the attribute is optional, so check first with storey->hasName().


for (IfcEntityList::it i = storeys->begin(); i != storeys->end(); ++i) {
if ((*i)->getArgument(2)->toString().find(building_storey) != std::string::npos) {
std::cout << "Selecting " << building_storey << " for filtering..." << std::endl;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better use Logger::Message(Logger::LOG_NOTICE, so that users can set the verbosity

selected->ContainsElements();
std::cout << "IfcRelContainedInSpatialStructure size " << in_storey__->size() << std::endl;
IfcSchema::IfcRelContainedInSpatialStructure* in_storey = *(selected->ContainsElements()->begin());
context_iterator.includeProducts(in_storey->RelatedElements());

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be recursive. So that decomposed elements are also included.

@aothms

aothms commented Oct 21, 2016

Copy link
Copy Markdown
Member

Thanks for this. I made some comments about the code in-line.

The proposal by @Stinkfist0 is more general and I can imagine it is useful to consider for other cases, for example, to process a single wall with its openings and windows. Also the fact that it specifically selects by Name and has an option to select by GlobalId is nice to have.

Is there anyway we can unite these efforts?

@Stinkfist0

Stinkfist0 commented Oct 21, 2016

Copy link
Copy Markdown
Contributor

I plan to provide a PR in the near future of my implementation, I'm planning also adding --guid option (e.g. --include --guid 1UhvOtJ6T8Tgo1W$J1I_D$ 344O7vICcwH8qAEnwJDjSU --with-children, e.g. GUIDs referring to two storeys).

@andersgb

Copy link
Copy Markdown
Contributor Author

Great, thanks for the review. I don't really know what I'm doing, just hammered on this until I got something working. It seems the proposal of @Stinkfist0 is more general and it covers my specific need here as well. Maybe just close this PR for now?

And yeah, the --guid option would be very useful.

@aothms

aothms commented Oct 23, 2016

Copy link
Copy Markdown
Member

Maybe just close this PR for now?

Ok, better luck next time, thanks for your effort though.

@aothms aothms closed this Oct 23, 2016
@Stinkfist0

Copy link
Copy Markdown
Contributor

@aothms BTW, I'm not really a fan of --with-children name - would you have some better suggestion, something a bit more "IFC-like"?

@aothms

aothms commented Oct 24, 2016

Copy link
Copy Markdown
Member

Well, I agree.

It would be a grouping of the following relationships if I'm not mistaken: IsDecomposedBy, HasOpenings, FillsVoid, ContainedInStructure. I cannot really think of any umbrella term that matches this. Something like "relation" is obviously too broad.

I am also fine with something like --recurse if you like that better, but it isn't necessarily more informative.

@Stinkfist0

Copy link
Copy Markdown
Contributor

Perhaps something like containment would sound informative.

@aothms

aothms commented Oct 24, 2016

Copy link
Copy Markdown
Member

Perhaps something like containment would sound informative.

IMHO it would cover HasOpenings, FillsVoid, ContainedInStructure. IsDecomposedBy is really a different beast. E.g typically you have an IfcCurtainWall or IfcWindow with IfcMembers and -Plates, the curtain wall exists by nature of their decomposing elements, but does not really contain them I would argue.

My preference is for something general (recurse, children) and to document it properly in the help message.

@Stinkfist0

Stinkfist0 commented Nov 2, 2016

Copy link
Copy Markdown
Contributor

Maybe I'll just stick to the original name for now 😄 I'll start working on providing a PR soon.

Stinkfist0 added a commit to Tridify/IfcOpenShell that referenced this pull request Nov 8, 2016
…including/excluding decomposition and containment of filtered entities.

Usage example: IfcConvert Duplex_A_20110907.ifc Level1.dae --include --with-children --names "Level 1"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants