What parameters can be found in each Ifc file?

What parameters or what information can one expect in every Ifc file?

IfcTyp, IfcName, IfcStorey... Base quantites?!

For example, I have noticed lately that in some Ifc files there are no base quantities and I thought they come natively with every Ifc export. I scrolled through the ifc export settings in Revit and saw that there is a possibility to deactivate the export of the base quantities. What is the utility of something like that?

Is there any good literature out there about the structure and the essentials of an ifc file? The building smart website is hard to digest.

Tagged:

Comments

  • IFC is basically a huge dictionary of "concepts" in the AEC industry. IFC also includes specifications on how these concepts may relate to one another to describe aspects of our built environment. For example, a "Building" is a concept, a "Site" is a concept, and IFC says that you can relate both of them together such that Site<->Building to digitally describe "A building is on a site" or "My site has a building on it".

    There are about a thousand IFC concepts, and hundreds of specifications on how they can be combined to create meaning. This is a lot of data. It is not something that has been well documented in literature, unfortunately, but many OSArch members can help you there.

    For different usecases, you may not need all the concepts, and you also might not need all the ways they can be combined. Especially with traditional BIM tools which have to translate proprietary unstructured data into ISO-standard OpenBIM, this creates a big problems for traditional closed vendors. buildingSMART's stopgap solution to this was to introduce something called an "MVD", or "Model View Definition". The objective was to specify what data should be captured in an IFC during this complex translation process. For example, for facility management data, you don't need many quantities. Even for many coordination activities, quantities are not important.

    Historically, omitting data and only specifying what's in an MVD makes life a bit easier for vendors and certification bodies. However, in practice, this translation process is full of problems, MVDs are very hard to write, validate, and users lack the knowledge to specify what they want. Even when the data is in there, most existing IFC tools are quite superficial and only let you access data up to a certain level. Well-intentioned users can only do so much when the export process is a black-box and the mapping process is complex, and MVDs are poorly documented, poorly validated, poorly certified, and so on. As you can see, even with the MVD concept, there is very little guarantee that an IFC is actually useful to a user.

    So back to your question, there is a little utility right now in decreasing the data in a file to accommodate vendors who just want to translate a bit of IFC data into their own proprietary system.

    However, given the number of free and open source IFC libraries for all programming languages, given the growing public test cases for certification instead of black-box certification programmes, and also given the growing evidence that native IFC is practical, you are absolutely right - MVDs, limiting data, and creating weird derivative exports makes no sense anymore.

    Borna_Molnarbitacovirkaiaurelienzhcvillagrasatlangcarlopav
  • Thank you Dion, once again, for your extensive answer!
    It really is a pity that all this complex IFC specifications is not better documented in literature. A big roadblock to broader implementation...
    I am looking at BIM from a construction management perspective, so I find quantities very important. And yes, a bit one sided from me to think that everybody needs the quantities. But I somehow always think more is better and then every use case can filter out the necessary information.

    A bit of background why I am asking this question... I am trying to create a django web application that would use ifcopenshell to parse the files, convert them to pandas and them visualize data using plotly and dash to give some broad insights in the data contained in the model. So a user would upload his file and get IfcSpace area per storey, volume of loadbearing elements per storey and stuff like that. Some walls, doors, and windows schedules.
    But since the quantities are not available in every ifc file I don’t think, this is going to work...

  • @Borna_Molnar I would go ahead and implement your application, and if the quantities are not available, just tell the user. Most users are pretty quick to acknowledge when data is missing and will do what they can to fix it, and even specify it contractually or make it part of their standard deliverable in the future. Users generally have good intentions. For the majority of traditional BIM apps, including quantities is quite trivial. If they are missing, it is often a single setting to fix it.

    You might want to chat with @fbpyr who has already implemented something similar to what you've described. Perhaps you two can collaborate!

  • @Moult thanks for hinting to this conversation.
    correct, this sounds very similar to what I am writing over here:
    a fastapi webapp with mongodb as database and brython as frontend. from brython we are able to hook into python dataviz libs like bokeh and altair or more precisely into their javascript frontend parts: bokehjs and vega-light. with this we can view/change/visualize (showing room surfaces and colorizing them by param values) the data - currently our focus is on IfcSpace data, but it should work the same way with many other ifc elements as well - just their data model would look differently. but since we feed it from different applications we do not upload the actual Ifc. instead we stream already filtered data of interest from clients to fastapi api. as such clients we currently use the aforementioned brython web frontend, OpenIfcShell, BlenderBIM, and Revit. Data can go either directions, so managers could also enter e.g. room requirements into web frontend and a colleague drawing in the model in rvt or in blenderbim can pull that data. clearly some data only makes sense to push from certain clients: e.g. room area from rvt or BlenderBIM.
    @Borna_Molnar when some data is not available (yet) it could still be fine to not write it (yet) and fill in the blanks later. we do this with the room outlines:
    a client can stream minimal room data (e.g. required is only ifcguid and name). when later we use rvt or ifcconvert to create the svg_path, then we will be able to draw the colorful room shapes and show their attributes as hover info. but that can happen at any later point, as long as the ifcguid is stable. (-;

  • @fpbyr from what I can gather your projects expands my idea because you also want to highlight the desired parametar or area in the model. That sound amazing! But I must say a lot of the terms you used flew over my head. I am a novice in the programing world. I have some knowledge in python but that is pretty much it. The plan is to outsource the django development in my case because I simply don't have the time to learn it. Or I just like to get an mvp going as fast as possible.

    But nevertheless... How far along are you? Does your project have a github? Is there a possibility to collaborate?

  • @Moult yeah I don't think I will stop with the development, because of this small snag...
    I have a few question about the quantities. Is there a broad way to check if the files is exported with quantities?

    My idea would be to iterate through the elements a look for quantities, but maybe there is a simpler way.

    Could it also be possible that for example the walls have quantities and windows do not?

  • Yes it is possible, typically walls should provide volume, where a single window with properly defined type is enough.

  • A small note that what quantities are needed for take-off on different elements depends on the type of element, the country, and the company. For example, volume for in-situ concrete walls is useful, but side area might be used instead for partition walls. Some windows may be simply counted, whereas some require width and height.

    stephen_ljchkoch
  • Yes, I am aware of that. As I said the plan is to implement some pretty broad QTOs for the beginning to gain a high-level overview for a feasibility study.

    But yeah, I am not sure on which data I can rely on for every model.

  • @Borna_Molnar said:
    ... What is the utility of something like that?

    For example we as architects have to be careful not to deliver anything we are not contractually bound to deliver. It is all about the responsibility and getting this wrong leads quickly to trouble. And since the rules for the quantities differ from country to country AND from software to software AND are hard to precisely control, it is really better to leave this to somebody getting paid well for this (cost estimator).

  • You can search IFC entities and properties on search.bSDD.buildingSMART.org

    tlangBorna_Molnar
Sign In or Register to comment.