Hi
there are just some ideas to access data of an ifc-file in a homepage or webservice. Even for getting some areas or parsing more detailed data with relations. XML is quite easy readable… but a lot of files are not yet xml and there is not a easy way to convert them online. So is there any project to get a ifc-file into a mysql database with php for example?
Thanks for your help and hints,
Robert
Hi Robert,
Maybe this can help with:
Kind regards,
Ehsan
I read before but I thought it is only meant to replace the ifcDoc-Tool or to generate a compatible new schema?
No, is the same
And XML is not a good idea when it comes to web-based files and solutions
IFC is more “object-oriented” and less relational but I think this issue will solve soon (However, some useful projects like IfcOpenShell are exist today)
And SQL servers like MySQL have limitations in this area today and just support simple geometries and have limitations in "Geometry DATATYPE"s
But for sure MySQL has a great community and will solve the limitations in the near future
Best,
Ehsan
Most web platforms use local command-line tools (such as IfcConvert from the IfcOpenShell project) to parse an uploaded IFC file into something else. This is usually split between converting the geometry and the properties.
For 3D geometry visualisation in a Web-viewer, developers usually fall back onto a known format (e.g. GLTF or Collada) but they may apply a custom format (often stored in JSON or a custom Database). This is true for BIMserver.org, BIMsync.com, BIM 360/Forge, BIMvalue.com etc… docs.XBIM.net uses their intermediate format wexbim. No Web-viewer directly shows you an IFC file. Even Autodesk doesn’t show you an RVT or NWD file directly.
For the non-geometrical information, this can be converted into a database, custom XML-format or (more often these days) json files.
And only after that pre-processing on the server (in the backend) will the server present you a viewable model with geometry and information.
This is in fact not that different from Desktop Viewers, although they may do this directly in memory within the application itself. What you see in the viewer is simply a mesh-representation of the geometry in the IFC-file, to be able to show something on screen.
@stefkeB So I know that or can feel that you see the same obstacles I see these days.
As you mentioned correctly those geometries (even GLTF or Collada) are not web-based geometries and there’s a need to develop web-based geometries
And also, XML-format or (more often these days) json files are not good for web-based usages, they are inefficient and slow, even json method.
What I don’t fully understand is why you suggest that we need to develop new web-based geometries. GLTF precisely was meant as (yet another?) common 3D format to exchange 3D scenes (scenegraph, geometry, shaders, meshes, animations).
It is open and royalty free and applying many of the tricks needed to work in online applications as well as for desktop. To me, it seems to replace Collada, which is a more open format than FBX and they are more modern versions of X3D and before that VRML.
You are not able to store all possible STEP geometry from IFC inside these mesh-based formats, but you can turn IFC file geometry into GLTF and display that in a viewer (web or desktop). For 3D geometry this is all you need. For 2D geometry, I still see limitations.
While I appreciate buildingSMART and their standards, I don’t think they are the best placed to develop an alternative to this. The Khronos Group has backing from about the whole industry, so they know a thing or two about 3D geometry and visualisation.
I’m thinking of new methodologies/technologies that modern web browsers use, like WebAssembly
I’m thinking about performance and smoothness and I have some doubts about JSON-based technologies
I talk about IFC-file on a city scale, not just a building or two.
First of all, do we accept that all the solutions we see in the market related to IFC are just one-way solutions or not?
They are just read-only methods and solutions and I’ve focused on this topic —> I’m talking about the need for web-based read-write solutions
I don’t get what WebAssembly is doing in this comparison. It is a technology that allows more native (compiled?) executable code within a browser.
The format to describe the 3D geometry (e.g. extracted out of IFC-files) is not dependent on the execution code. E.g. GLTF is already quite optimised. And you can always compress files further when needed (if the format itself is not yet highly compressed).
Why do you see JSON or XML (as standard file formats to transfer generic information) being a limiting factor? My colleagues developers use these formats all the time, as part of API calls or custom information transfer between applications, apps, databases and services. The calls are often transferred as compressed and encoded strings, which makes them as small as they get.
Is it possible to read all the discussions here and provide your insights there or here?
What I believe and I think you also mentioned about in your view, “IFC was developed for desktop software and still has some limitations for web-based solutions. Indeed IFC is not suitable for CRUD web-based solutions”
In the near future when it comes to “Digital Twin(s)” and “IoT” the size of the file, and the size of data/information exchange and the number of queries become vitally important.
What I want these days is: “Be able to design/edit building and building elements/products on the web browser. Something like Autodesk FormIt”
Sorry but I agree with stefkeB that I cannot see any relation to my question, whether there are scripts to import/parse stepfiles into a database. Everything else is OT and would be nice if you discuss this somewhere else - thank you.
Unfortunately I guess this will prove to be difficult if done on client-side. One of the main problems I came across when trying to get some web things done with IFC is its general lack of proper parsers and machine interpretable formats of its structure. It is quite chocking but most IFC parsers are coded “manually” (by humans, they don’t comply to the schema described in EXPRESS), which is why IFC is not even properly interoperable between most desktop softwares. Getting the data structure as described in the EXPRESS schema and then deriving an IFC parser in JavaScript or WebAssembly would be a good start IMHO, but guess what: it is nearly impossible to find any good EXPRESS parser either…
I guess that is why most big companies rather spend time on implementing “translation” solutions or middleware, since it is more budget-friendly than implementing an EXPRESS parser or JavaScript IFC library (and I am not even getting into the complexity of the IFC data structure itself, which is absolutely non-trivial).
Also, I personally believe that IFC is not suited to the AECO industry at all, but that’s just my opinion 
Credit: Pierre Monico
The most enlightening comment that I’ve received regarding using IFC on/around the web came from @jonm who correctly pointed out that any non-trivial IFC file is just too big to be used in the browser. We could use tools like IFC-gen to generate javascript code for representing IFC types, and parsers for reading STEP files, but you’d find all kinds of other challenges awaiting you once you parsed the file.
Here’s a good one. How do you create geometry? You’d need a client-side geometry library that can create geometries according to the IFC spec. This is the reason that any infrastructure for dealing with IFC currently processes the IFCs on the server, and spits out glTF, JSON, and other web-friendly stuff. This is a totally reasonable way to handle this problem. IFC stored in STEP files is not designed for transmission over the internet, and deserialization and display in the browser.
Web assembly helps only insofar as you could take existing code written in languages like C++ for working with IFC and compiling it to work in a web client. But I doubt the outcome would be something anyone would be happy with because those code bases were designed for a different time and different use cases. You’d basically be building a desktop application which runs in a browser, which doesn’t take advantage of the benefits of building for the web in the first place. I understand the gist of your question though as wanting, like everyone does, a silver bullet to make bringing IFC to the web easier.
BSI does have a “modernization” project currently under way that takes into account the desire for more of these workflows to be web based. The discussions include modernization proposals for the core IFC schema and the introduction of “tool kits” to provide client and server technologies for transmitting and storing IFC data.
Because Hypar can’t wait around for any of that we’ve built our own pipeline using libraries built with IFC-gen for reading/writing IFC, server-side geometry processing, and serialization to glTF and JSON.
Hi, I guess I’m late to the party.
Anyways…You can do a “dirty paring” relatively easy.
In other words:
If you know what you’re looking for, you can skip the rest
Or, another way to describe it
Just hard code the relationships you want, ignore the rest
I’m currently building a parser that handles User Defined IFC Property Sets.
The logic behind my code is somewhat “dirty”. I DO NOT build the entire IFC schema/relationship.
Instead, I only implement IfcPropertySingleValue, IfcRelDefinesByProperties, and IfcPropertySet. Mapping the relation is super easy (in this example). I just followed the EXPRESS schema defined by IFC2x3 TC1.
However, my solution is very limited. Depending on what kind of “data” you want, different approaches are needed. But, simple Property Sets are easy to parse.
You can take a look at my GitHub Repo for more info. I have demo as well.
Best regards
André Wisén
Hi everyone,
I just came across this conversation and I wanted to mention two things based on your comments:
I don’t get what WebAssembly is doing in this comparison. It is a technology that allows more native (compiled?) executable code within a browser.
Well, webAssembly is useful because it’s fast, and for converting your web browser into a Revit-like application, you can’t just rely on JS for model processing. Hence, I think it is worthy of mention it in this conversation.
…there are just some ideas to access data of an ifc-file in a homepage or webservice…
To answer your question, I just found out the project IFC.js, in which they use (you guessed it!) WebAssembly to parse an .ifc file and render it on the browser! They use the three.js library for 3D rendering.
Kudos to Antonio González Viegas, who is making an amazing job there!
Regarding the question IFC → MySQL parser, I was also looking for something like that…and I believe it may be easier to collaborate in the IFC.js project and develop an export to .sql functionality once they parse the IFC with C++, rather than doing a direct IFC to SQL.
Please give it a try and let me know what you think.
Regards,
Adrián
P.S: It is my first post here and I tried to put some links to the GitHub repo, but they don’t work 
sorry for that!
Hey @adrisanchu just posting the Github links which I assume you tried to do:
We are documenting its progress here: IFC.js - Wiki.OSArch - and both developers of web-ifc and web-ifc-viewer (IFC.JS) are active on the OSArch.org live chatroom