BIM and IFC comparison

[Moult]

Hey guys! I just want to start by saying that your work is awesome! However (here it comes!) I think it is important to have a more comprehensive comparison of dotbim and IFC so that people understand the strengths of each and know which to use for their purpose. The table seemed a little simplistic right now. Would you be interested in updating the README comparison table with some of these differences?

1. Serialisation. dotbim is JSON only. IFC is serialisation agnostic, including SPF, JSON, XML, HDF5, TTL, SQLITE, ZIP. Obviously the latter adds complexity (both docs and implementation) in exchange for portability.
2. Schema definition. dotbim seems to be described with C#. This is great for those in the C# ecosystem and comes with the lib prepackaged. Outside, especially on Linux, perhaps not so fun. IFC is defined in EXPRESS, UML, and OWL, but actual language classes/bindings are provided by third party library developers. Again, a tradeoff in a rapid hello world in a language and tech stack flexibility.
3. Scope. dotbim seems to optimise simplicity: meshes with key value pairs. IFC is designed for more domains: structural analysis, profile libraries, energy analysis, tasks and sequencing, textures, facility management, building operations, events, procedures, lifecycle flows, cost databases and schedules, and so on. These primarily non-geometric usecases are what make IFC cool, but as a trade off, comes with an extra 99 pages of docs :)
4. Classification. dotbim seems to be classification agnostic, this is pretty awesome! IFC comes built-in with an implicit classification system (though it can be ignored) which is sometimes a requirement of other standards (e.g. COBie). This difference makes dotbim far easier to use as you don't need to learn another vocabulary, but can be harder to collaborate if people use different classifications.
5. Ecosystem. Early days, but exciting days, for dotbim! Obviously with a 25 year headstart and a ton of funding IFC has its creepers everywhere for better or for worse and the apps and developer libraries that exist are more mature.
6. Standardisation. dotbim is not an ISO standard. IFC is. This means dotbim is much more nimble and can adapt to user needs faster. However, it also means that governments and neutral parties or those who need stability are more likely to prescribe IFC. As an ISO standard, it also integrates other standards: gbXML explicitly references IFC for energy analysis, Brickschema has a two-way IFC integration for building management systems, IFC textures and shaders are compatible with X3D and glTF, and so on. So whereas dotbim can translate to other things, it probably won't quite get the "native" integration that ISO standards do.

It's probably good to have IFC on the comparison table because IFC is stupidly popular, but at the same time has such a strikingly different audience: things like ISO, tech agnosticism, and an appetite for building scope that is downright scary - but many people either don't know what IFC can do, or they do, but they legitimately want a more lightweight solution.

To emphasize what makes dotbim truly awesome, it'd be good to perhaps add some other libraries that have a similar scope to dotbim (as opposed to IFC which is at the other end of the spectrum). Maybe https://hypar-io.github.io/Elements/index.html Hypar Elements or Speckle Objects https://speckle.guide/dev/objects.html comes to mind.

Keep up the great work! I've added dotbim to https://wiki.osarch.org/index.php?title=AEC_Open_Data_Standards_Directory :)

[paireks]

Hi Dion!

First of all: thanks a lot for spending time to look at it! It means a lot to me!

Regarding comparison to IFC: yeah, this table is kind of simplified explanation for people to show the motiviation why we're doing it. Many people don't get the point of it, many others don't like an idea of having another format if there is one existing already. So it is kind of small table so someone can see it, look at it, and say: okay, so it contains geometry and data, but with 1 page documentation. Something like this ;)

1. Yeah, IFC is a schema that allows to use it within XML, JSON, (even though in 99% it is SPF) etc. From my point of view staying with only one (JSON) makes it much easier. If we'd allow multiple, then it means multiple implementations for each of the serialization, I don't want that :)
2. Definition is both this C# library, but also that readme.md of this repo, you will find explanation there. The difference is also the fact that we have already viewer and creators to make sure that it is still easy to use. I believe that there is also something for Typescript. I was thinking of doing it for Python as well, but at the same time it looks so simple, that I'm not sure if it is even necessary :D It is something like creating 6 classes with properties.
3. Exactly.
4. Yeah, you're 100% right.
5. Yes. Actually the fact that IFC is for so long makes it really powerful at the same time.
6. Yes, it is not ISO standard and it won't be.

Currently we're testing it on Revit here: https://github.com/harrycollin/dotbim-revit, and few hours ago it turned out that Revit exporter of geometries could be developed by @harrycollin during, I don't know, 4 hours it was? So one of the goals would be to try different platforms and see how fast we can develop some stuff around it.

PS: I'm a huge fan of BlenderBIM, was using it constantly during development of tools for IFC.

Thank you once again for comments, and for adding it to wiki.osarch!
Wojciech

[Moult]

Thanks so much for the response! Yes, the point wasn't to say "X is better" but instead to describe the differences to help people spot the differences. As you say many people don't get the point of it, and that's because they've heard of IFC (or others) but they don't know enough about the details to compare or understand that these target different usecases. So I thought perhaps the table could be revised to help describe to those unfamiliar with the technicalities of the offerings out there that "hey guys, there's a clear need here for both sides of the spectrum". This changes the rhetoric from "choose X over Y" into "We need both X and Y for different purposes".

So the list above is definitely a list of differences, not change requests :) I totally agree that for dotbim's ethos, it should definitely focus on one serialisation like JSON. Don't change your design strategy - it's a great one and something missing in our industry.

Minor tech nitpick: for point 2 I was referring to computer interpretable schema definitions, so text docs don't quite count :)

[paireks]

I've added link to this issue in the readme.md in the BIM vs IFC chapter so anyone could see it if more comparison is needed :) Thank you once again ;)