The IFC Diagram

What a lovely combination of circles, rectangles, squares, octogans, and an inverted triangle the above diagram is. It sort of reminds me of a kid’s shapes exercise from school.

But of course it’s much more than that, it’s actually a diagram showing how to represent what we do in the AEC industry in a digital way. In this post I’m going dig a bit more into what each part of the diagram means.

IFC is like an onion

It has layers, and once you start to peel those layers back, it might make you cry if you don’t know what you’re doing.

Each layer builds upon the layer below, so I’m actually going to talk about each layer in the opposite order than shown in the diagram. The list below is ordered from most generic layer to the most specific layer:

Resource layer – generic things…

View original post 488 more words

The impossible problem of naming things

Constructing Data

Is there any situation more socially awkward than not knowing someone’s name and having to describe them to someone else?

“Erm, you know that tall guy? Kinda slim? Talks fast? Short brown hair? In the engineering department?”

Even deciding what attributes to use to describe them is fraught with difficulties.

And in Building Information Modelling is there anything more contentious than how to name something?

No system ever seems to satisfy everyone’s requirements. The British Standard, Publicly Available Standard, and International Standard documents do a good job but they’re far from perfect. Whether it’s zone, document type, or classification system, there’s always some part of it that just doesn’t seem to work properly for users.

Files, library objects, layers, instances of objects, and even classification systems themselves suffer from this problem.

Why?

Why is it so difficult to name things?

Many decry “dinosaurs” who don’t want to change, or the…

View original post 595 more words

glTF and Construction – Part 2: 3D for Everyone

Constructing Data

In the last post we discussed how IFC is a wonderful flexible format but that the flexibility comes at the cost of requiring a lot of resource to display the 3D model. This is because when 3D models are rendered they are always broken down into a mesh of 2D triangles floating in 3D space. Currently vendors use cloud computing to do this processing and then send the pre-calculated model to your devices to view quickly and easily.

The big problem is that each vendor stores and transmits their processed and pre-calculated models in a different way so the only way to view them is using the viewer specific to that format and vendor. We end up with a binding of viewers and storage systems because everyone is using different formats which massively reduces integration and choice for users. Decreasing choice and competition, increasing costs, and reducing productivity.

This is…

View original post 1,328 more words

IFC for the Layman – Part 4: Properties

Constructing Data

In Part 2 we looked at the Root template and how it has 3 children: Object Definition, Relationship, and Property Definition. Within Part 2 we looked into Object Definition, in Part 3 we looked at Relationship, and so to complete the set here’s a post on the Property template.

So far we’ve dealt with many attributes, things like descriptions, IDs, and names. However, we appear to be missing an awful lot of additional information and the templates look kind of sparse when it comes to the extra design and construction details we’d usually expect to find in a construction and facilities management project.

Things like fire rating for walls, material grade for concrete, pipe thickness, and other information that is essential but have no specific attributes or templates available for them. In this post we’ll find out how to add these additional properties.

Exactly what…

View original post 1,209 more words

IFC for the Layman – Part 3: Relationships

Constructing Data

In the last post we looked at how the IFC templates are organised and learned that they aren’t a flat list but are actually connected together like a great big family tree. The child templates would “inherit” attributes from their parent which allows us to reuse attributes which increases the predictability of how data is formatted.

This post is about how the completed or filled in templates connect together to form a construction and facilities management project.

Unlike the IFC templates a building shouldn’t be thought of as only a simple tree. I know what you’re thinking, software like Navisworks or Solibri often show a big tree structure from Site to Building to Building Storey to Parts. This is also how many other pieces of software force you to think of a building.

This might be a useful way for architects to think about buildings, but it’s hardly optimal for…

View original post 895 more words

IFC for the Layman – Part 2: Exploring the family tree

Constructing Data

This post I’m going to go into more detail about how the Industry Foundation Classes (i.e. templates of things in construction and facilities management: see IFC for the Layman Part 1) are built up. They aren’t, as you may think, a long flat list of separate templates but rather a big connected family tree of parent and child templates.

Bare in mind that throughout this post we’re only referring to how the templates themselves are organised, we’re not going to talk about how they’re filled in or how filled in templates relate to each other to build up a description of an actual construction or facilities management project. That’s coming up in Part 3.

Inheritance

From our parents we can inherit all sorts of things from genetics to, if we’re lucky, money. IFC templates can be parents as well that pass information to their children (just don’t ask how IfcBabies are…

View original post 2,956 more words

IFC for the Layman – Part 1: What’s in a name?

Constructing Data

Most people know Industry Foundation Classes (IFC) as simply a file format that many pieces of software can export out to, but what actually IS it and what about makes some people so excited about IFC?

The existing documentation and official information is somewhat ironically not well structured or clearly explained, their intended audience is for knowledgeable and experienced data engineers only.

The IFC documentation: keeping 1990s web design alive

This blog post (and others to follow) aims to give a clear introduction into what IFC actually is for the layman. The intended audience for this post is anyone in the construction industry and I’ll be assuming zero knowledge of programming or information management. I’m also not going to be discussing BIM management processes or how to use IFC with any particular piece of software.

Along the way I’ll introduce important ideas that shape how IFC works but do my best…

View original post 1,472 more words

glTF and Construction – Part 1: Secrets of the Cloud

Constructing Data

The glTF file format is a new 3D model viewing format that has gained endorsements from such tech giants as Microsoft, Google, and Facebook. It already has a vast array of open tools available and is supported by many pieces of software.

glTF is described as the JPEG of 3D models.

glTF is taking off in the visual effects world, but why should we in the construction industry care about it?

The last decade has seen a revolution in the amount of 3D modelling that takes place in the construction industry. We are producing vast quantities of 3D models with high levels of detail and the scale and complexity is only going to increase in the future.

And seeing as no one knows 3D models better than the visual effects industry, if they’re getting excited about glTF, it’s most likely well worth us looking at it too.

In this mini…

View original post 1,398 more words

Playing with git

cd ~/public_html/ mkdir deal2Rai cd deal2Rai/ git clone https://github.com/GreatDevelopers/dealii.git cd dealii git checkout dealii-8.1 cd deal.II/examples/ mkdir gdStep-1a cp step-1/*.* gdStep-1a/ cd gdStep-1a/ // Edit files cmake . make make run // Remove extra files rm grid-* git status git config --global --edit git commit --amend --reset-author git commit -m "Example step-1 is simplified and devided in to two parts" git push -u origin dealii-8.1

LibreDWG


sudo apt-get install build-essential autoconf libtool texinfo swig python-dev

sh autogen.sh

./configure --enable-trace

make

sudo make install

make check

export LIBREDWG_TRACE=3

cd examples

./testSVG yourdwgfile.dwg > yourconverteddwgfile.svg