Hi OSArch community.
I have used the website https://view.ifcopenshell.org/ to upload an IFC4 file to view it. I noticed that the svg floorplan generated in the bottom left reads the name of IfcSpace elements and also the area in m2. However, the IFC file does not have this information anywhere that I can tell. Is there a way to generate this automatically for all IfcSpace elements and report it using blenderBIM?
The floorplan generated using IFC Pipelines is likely (though I haven't confirmed) done with IfcConvert's SVG feature. One of the features that IfcConvert has is print-space-names and print-space-areas. The former prints both Name and LongName attributes. Therefore, the information must be in the IFC file. The latter prints a calculated area, which may not exist in the IFC file.
Currently, the automated area "guessing" tool in the BlenderBIM Add-on does not understand the concept of a "floor area" and therefore will give the incorrect area of an IfcSpace (instead, it will count the faces of all areas). Also, it is not possible to bulk quantify at the moment. I'll add it to the todo list. (Edit: there are manual quantification tools, but this is likely too cumbersome to be useful for you)
When you say export, do you mean export a SVG construction drawing, or export a schedule (e.g. in CSV), or export as a Qto in an IFC?
Thanks for the clarification Dion. Yes the area value is the one that I don't believe is contained in the IFC file. My intent was in exporting the IfcSpace data via CSV.
omg, why did I not realise https://view.ifcopenshell.org/ existed?
@brunopostle that's because it's brand new :) If you're interested, it's "IFC-Pipelines" in the Wiki free software directory - I've successfully tested running an instance on this server and it works well!
@Moult ahh, still very cool (though I can't whatever I do get SVG floorplans like this out of IfcConvert).
I notice that the model has a persistent-ish URI that anyone can click-on. This is just idle speculation, but wouldn't it be something if this had a walk mode, supported multiple users sharing their camera positions as avatars, had a chat console, allowed adding notes to walls and other entities, and, and, and...
As Dion mentioned, it's not correct yet
Also, [wishlist] it'd be better have a way to be able to set/write the user-defined equations, because some prefer to calculate areas and volumes different than software use
@edwinguerra the quantity guesser now understands "floor area" and will calculate the floor area of an IfcSpace correctly: https://github.com/IfcOpenShell/IfcOpenShell/commit/a1e5135a9ea93bef24de293dc182171d18f8e61e
There's also now a new feature that lets you select multiple objects and quantify them in bulk: https://github.com/IfcOpenShell/IfcOpenShell/commit/0a7c365d788c20c7147bf33715830b0a87cc783e
These fixes should resolve your issue - select all spaces, and click quantify, export a fixed IFC, and then you can export to CSV.
@brunopostle said:
@Moult ahh, still very cool (though I can't whatever I do get SVG floorplans like this out of IfcConvert).
This was a little more difficult than I expected: the options need to follow the filenames on the command-line, you have to add --exclude entities ifcspace otherwise it only draws IFCSPACE entities ??!?, and the SVG file has no font height, line width or fill information, so these have to be fixed in Inkscape. The output is nice:
IfcConvert project.ifc project.svg --print-space-names --print-space-areas --exclude entities ifcspace
A fun fact that it is actually important to draw IfcSpace entities in SVGs, to allow for colour coding spaces. This requires some styling and Z-index thinking to be useful, though.
Default draw order in svg depends on object's definition order in file.
When overlapping, last is draw over first.
So define ifcSpace first, then walls, openings and text as last.
Hope this helps with:
@Moult said:
This requires some styling and Z-index thinking to be useful, though.
Ah, now it makes sense not having any default style attributes, this should all be specified in CSS.
@edwinguerra said:
I have used the website https://view.ifcopenshell.org/ to upload an IFC4 file to view it. I noticed that the svg floorplan generated in the bottom left reads the name of IfcSpace elements and also the area in m2. However, the IFC file does not have this information anywhere that I can tell. Is there a way to generate this automatically for all IfcSpace elements and report it using blenderBIM?
I give it a try but seem no idea how to get the 'Floor plan' as you do, any idea how this is generated automatically ?
@paullee The spinning graphic in the middle suggests that it hasn't managed to finish processing your model
Thanks, it has been there forever :D
And for the Villa Savoye model, does not seems to have the spinning circle ...
Just tried again, not sure how, uploading just Ground Floor of the model have returned the floor plan on bottom left corner !
But uploading the full model with all floors return nothing ?
Any ideas of the difference ? Thanks :)
Perhaps ping @aothms ?
Yes, probably he is the only one who can find what is wrong in the IFC ...
@aothms see if you have a gap to have a look ? Thanks :D
(please see images in above post)
BTW, the IFC is produced in FreeCAD 0.20pre, git 25025.
@paullee said:
Just tried again, not sure how, uploading just Ground Floor of the model have returned the floor plan on bottom left corner !
But uploading the full model with all floors return nothing ?
@paullee said:
Any ideas of the difference ? Thanks :)
I only found the time to have a quick look, the files appear a bit different from what's on the server, but my guess is that it is related to the fact the building storeys do not have a placement. It's not forbidden by the schema, but it's really quite atypical and we need this information to get the floor plan heights and more.
#24=IFCBUILDINGSTOREY('3Ry6pP5vT37Pch4CyMOXO8',#5,'BldgPart__GF','',$,$,$,'BldgPart__GF',.COMPLEX.,0.15);
You can also test locally with a recent version of IfcConvert. I think an the server -qy --plan --model --section-height-from-storeys --door-arcs --print-space-names --print-space-areas --bounds=1024x1024 --include entities IfcSpace IfcWall IfcWindow IfcDoor IfcAnnotation is ran.
Does the storey need a real placement or just set the z-height? AFAIR just setting the z-height is somehow possible in the storeys.
@aothms I see plans for some models, i.e. this one is ok, but this one isn't.
Also the command-line usage for IfcConvert --help says: Usage: IfcConvert [options] <input.ifc> [<output>], whereas I find that I have to put the file-names before the options.
@aothms said:
but my guess is that it is related to the fact the building storeys do not have a placement. It's not forbidden by the schema, but it's really quite atypical and we need this information to get the floor plan heights and more.
@yorik this recalls me our talk about having floors represented in FC as App::Part objects, that have a placement :) Perhaps it's more adherent to typical IFC schema?
@carlopav said:
@yorik this recalls me our talk about having floors represented in FC as App::Part objects, that have a placement :) Perhaps it's more adherent to typical IFC schema?
Yes and no I think.. The app part is really a part, a compound, a piece, an object. The idea is that its subcomponents are just parts of it, nothing more. For me a floor is much more like a group: the "object" inside it is still the main object, they are still "alive". I played a bit with app parts too, but found it hides/swallows too much of the underlying components. So i kind of never went further with it. A floor is not really an object meant to be manipulated.. and the very rare times you need to move an entire floor at once, it's easy to move its contents too, so...
But of course all different workflows can coexist ;)
That said, our floor object does have a placement. We just need to export it to IFC. I'll look into it!
Login or Register to reply.