timchipman
commented
10 years ago The presentation pretty much states the obvious :) The same could be said about XML and most text encodings commonly in use. Zip-compressing text encodings is often more efficient space-wise than binary encodings or the zipped-equivalent, however there's no doubt that speed in loading/saving (and being able to selectively load/save objects within a file if in an indexed format) would improve usability of IFC data. Some of the overhead in IFC (e.g. IfcCartesianPoint) has been much improved with IfcTriangulatedFaceSet. Not sure how realistic it would be to ditch the IFC-SPF format for the Coordination View, as that is what applications and users have been working with for years. As the STEP format pre-dates Collada and JSON, I don't think there has ever been any motivation to "re-invent" anything but rather re-use what has already been defined -- at the time IFC leveraged geometry definitions from STEP (about 20 years ago), CAD systems were already supporting STEP for product modeling, which was pretty much all that was in use at the time for open geometry standards.
That said, there is a binary encoding available for IFC based on HDF-5, defined at ISO 10303-26. I don't know of any vendors supporting it; perhaps that's something that should be promoted? Kind of a chicken-and-egg scenario I guess, where there's not much motivation for anyone to support it until other software does.
TLiebich
To spark a discussion, I thought i'd share Anton Gerdelan's (@capnramses) recent presentation on some of the inefficiencies he sees in the IFC format.
http://antongerdelan.net/blog/slides/ifc_anton.pdf
An excerpt from the presentation, the following outlines some suggested alternate approaches.
Would like to keep discussion focused on what could be done within reason.