Spatially Adjusted

Tag: IFC

  • Open Environments and Digital Twins

    The GIS world has no idea how hard it is to work with data in the digital twin/BIM world. Most GIS formats are open, or at works readable to import into a closed system. But in the digital twin/BIM space, there is too many close data sets that makes it so hard to work with the data. The loops one must go through to import a Revit model are legendary and mostly are how you get your data into IFC without giving up all the intelligence. At Cityzenith, we were able to work with tons of open formats, but dealing with Revit and other closed formats was very difficult to the point it required a team in India to handle the conversions.

    All the above is maddening because if there is one thing a digital twin should do, is be able to talk with as many other systems as possible. IoT messages, GIS datasets, APIs galore and good old fashioned CAD systems. That’s why open source data formats are best, those that are understood and can be extended in any way someone needs. One of the biggest formats that we worked with was glTF. It is widely supported these days but it really isn’t a great format for BIM models or other digital twin layers because it is more of a visual format than a data storage model. Think of it similar to a JPEG, great for final products, but you don’t want to work with it for your production data.

    IFC, which I mentioned before, is basically a open BIM standard. IFC is actually a great format for BIM, but companies such as Autodesk don’t do a great job supporting it, it becomes more of interchange file, except where governments require it’s use. I also dislike the format because it is unwieldy, but it does a great job of interoperability and is well supported by many platforms.

    IFC and GLTF are great, but they harken back to older format structures. They don’t take advantage of modern cloud based systems. I’ve been looking at DTDL (Digital Twins Definition Language) from Microsoft. What I do like about DLDT is that it is based on JSON-LD so many of those IoT services you are already working with take advantage of it. Microsoft’s Digital Twin platform was slow to take off but many companies, including Bentley Systems, are leveraging it to help their customers get a cloud based open platform which is what they all want. Plus you can use services such as Azure Functions (very underrated service IMO) to work with your data once it is in there.

    Azure Digital Twins
    Azure Digital Twins

    The magic of digital twins is when you can connect messaging (IoT) services to your digital models. That’s the holy grail, have the real world connected to the digital world. Sadly, most BIM and digital twin systems aren’t open enough and require custom conversion work or custom coding to enable even simple integration with SAP, Salesforce or MAXIMO. That’s why these newer formats, based mostly on JSON, seem to fit the bill and we will see exponential growth in their use.

  • BIM File Format Fun

    If you ever thought it was difficult to work with GIS file formats, you haven’t explored the world of BIM. With Cityzenith I’m getting back into converting BIM and it’s making me nogstagic for Esri’s File Geodatabase or LIDAR formats. One of our core features at Cityzenith is drag and drop BIM model import. We’re supporting COLLADA, FBX, IFC, OBJ and CityGML for now but it seems every time I talk with a user they want to import some very proprietary BIM format. I won’t even get into the issues with importing Autodesk’s Revit but look how hard it is for even Safe FME.

    The great thing about most of these 3D formats (beyond Revit) is they are relitively open and there are many tools for reading and writing them. But the sheer amount of formats means that you’ve got to plan for these in your software workflows. IFC and FBX do a great job of saving a lot of the BIM data on export while formats such as COLLADA basically drop everything except the structure. Most of the time this isn’t an issue because BIM files have so much data in them that really isn’t important for a planning and development tool such as Cityzenith, but we want to grab much of this to allow our users to perform analysis on building information.

    We also want to grab floors of the building and basic structure beyond just the building shell. When we’re integrating IoT feeds into buildings, having the floors or rooms is critically important. IFC is the hope and the failure of openBIM. In an attempt to be everything to everyone, you end up with a bloated format but one that will address all your needs. Being able to programatically pull out floors and rooms of a BIM model requires a ontology for us to work with and IFC sticks to one that we can work with.

    But any consultant will tell you, each user(client) has their own unique ontology that you have to work with. Safe Software has been dealing with this for years and has done an amazing job of working with these little idiosyncrasies that enter not only file formats but the models that humans create in them. It’s been really fun getting back into BIM and BIM file formats full time. BIM to GIS (or GIS to BIM) is hard but that challenge and making it simple and repeatable for all users is going to make it very exciting.