Storing information in CAD software
The CAD-corporations of the world are proving to the construction industry with aggressive marketing (up to 50% of company budgets) that 3D-7D data creation tools are (will be) well implemented in their programs (Archicad-Nevaris, Autodesk-BIM360, Renga-PilotBIM, Bentley-OpenBuildings).
To avoid annoying the large market of third-party applications and investors in BIM and PropTechs start-ups, CAD solution vendors are “forced” to create connectivity to their proprietary data in 3D solutions via API queries, ODBC or third-party plug-ins. Data in Closed BIM solutions is transferred via databases, and everything in the construction industry that deals with 3D-7D data is also transferred into a database format, which is now commonly referred to as BIM data work.
Therefore, most 4D-7D data management systems today work with relational database management systems (RDBMS): MS SQL, MySQL, PostgresSQL, Oracle, MS Access.
SQL (structured query language) is a declarative programming language used to create, modify and manage data in a relational database (RDBMS).
To make it possible to connect to external services (databases) and their internal services from the Closed BIM environment, CAD software developers try to translate the data into SQL table format.
Data storage in SQL
The main advantage of SQL tables over other types of information storage is that they support very large database sizes with high query processing speeds. SQL also integrates well with web applications and other data management tools. In 4D-7D and ERP systems, data has long been stored in tabular SQL databases, but CAD data in the form of 3D geometry has until recently been confined to visualisation work and has struggled to be stored in tabular and textual form.
One of the first implementations of storing geometric information in tabular form, with the creation of an SQL database, was the Postgres project.
Postgres – pioneers of data storage from CAD to SQL
A motivating example for Postgres developers in the early 1980s was the need for databases to support computer-aided design (CAD) tools for the microelectronics industry.
In a 1983 article, Stonebraker (founder of the open source Postgres project) and his students explained how the CAD (computer aided design) industry required support for new data types such as polygons, rectangles, text strings and “efficient spatial search, design hierarchies and multiple representations” in the same physical structures.
Unfortunately, the Open Source initiative of the Postgres project developers occurred 20 years before CAD programs with the possibility of creating this data. And because Postgres has always been an open source project, for a long time it was only aimed at research use, not production.
Although PostgreSQL is today the most popular independent open source database system and the fourth most popular database system, most CAD software developers today prefer to use SQLite and Microsoft SQL databases.
Revit – database in graphical representation
The acronym BIM (Building Information Modeling) is a marketing invention of Autodesk Corporation; it refers to the data handling techniques that are created when working with the Revit 3D solution.
The product Revit, the main programme of the last 20 years for designing and creating BIM data, is essentially a database of model elements in graphical representation (a set of data streams), thus creating a BIM information model.
When using Revit Server, you may notice that the program communicates with the project data via db3 format, indicating the use of a relational database – SQLite – to communicate with some back-end services.
Out of all the integration options with external services, Autodesk only allows the upload of proprietary RVT data via plug-ins, API connection or ODBC uploads.
ODBC (Open Database Connectivity) is a software interface (API) for accessing databases.
The opening of the incomplete API access to Revit functions has triggered the development of solutions that allow working with Revit via API queries: Grasshopper, Dynamo, pyRevit, Forge.
API (Application programming interface) – a description of the ways in which one computer program can communicate with another program.
The purpose of such plug-ins and the ODBC driver is to allow the data to appear as if the user was accessing an SQL database.
Creation of ArchiCAD and Tekla tools API
The virtual building project in ArchiCAD is now a database into which you can make SQL queries via ODBC driver and retrieve any necessary project information structured in tables. The ability to execute SQL queries in ArchiCAD has been available since version 7.0 2001.
The ArchiCAD database (like the Revit product) uses a proprietary format, so providing ODBC access requires a major development effort.
The ArchiCAD database consists of tables of levels 2-3 with a complex indexing scheme. Opening an object container in ArchiCAD allows you to edit its component scripts, which, without a basic knowledge of ArchiCAD’s internal programming language, GDL (Graphical Graphics Description Language), is not the best way to proceed. Experienced programmers can only get to read and write access to project data through C/C++ programming and using ArchiCAD’s incomplete API.
Archicad developers have also worked on an ODBC-SQL-ArchiCAD project with the ability to interface with other CAD programs. These interactions were meant to help link architects, planners, designers and cost estimators into a single system using CAD software. But the project was abandoned, perhaps because of the obvious limitations of working with other CAD software.
The current plan of the Archicad developers is to provide a kind of BIMcloud API where project data can be accessed in IFC format.
Reference taken from Nemetchek.com. “Known” as BIM (BOM) appeared on the website after 2005
The Tekla database (Tekla Structures), like other major CAD solutions, is not directly accessible. In 2020, Tekla developed an open API on the Microsoft.NET framework that now allows third party developers to write their own C# applications to manipulate data from Tekla Structures software. But, as with the Revit API or Archicad ODBC, the Tekla API works as a stripped-down toolkit to influence the program.
The problem of data interoperability in the construction industry
Through the use of proprietary formats, CAD vendors today do not allow access to 3D data that the user has created themselves in the programmes. Direct transfer of complete information from the 3D model to 4D-7D solutions is not possible today and to give at least some access to the data, corporations offer connectivity to “unstructured data sets” through tools: ODBC, plug-ins, services with API connectivity (to internal program functions) and incomplete IFC data format.
Data connections via plug-ins and APIs that do not work
When information is uploaded via plug-ins and APIs, usually only system parameters (base quantities) and element properties without geometry are uploaded, which makes it impossible to use the data offline in other 4D-7D systems (e.g. ERP, ECM, EPM).
We will talk more about what data is needed in the 4D-7D systems phase in the following articles.
In general, vendor ODBC tools and APIs do not give full access to the data, and their purpose was to isolate the external user from the database of all the properties of the elements that were created during the design process.
Corporations with data power are not prepared to lose control of their customers, which is why most professionals who try to extract volume information from models are now forced to develop their own plug-ins to connect to the data in 3D solutions and Excel spreadsheets to link the resulting data (without geometry) to existing 4D-7D solutions.
However, once data export via ODBC or a plug-in is set up, there is no guarantee that the next year, when a new version of the CAD program is released or the API libraries are updated, communication with the internal CAD program databases will work according to the same rules as in previous versions.
As a result, the construction industry suffers from a corporate monopoly over data, with the result that proprietary information about elements stored in proprietary formats is reflected in multi-billion dollar miscalculations on project construction timelines and costs.
Autodesk’s hegemony on data is being diluted by developers from European CAD corporations who, following the meteoric rise in popularity of Revit, are resurrecting Autodesk’s buried IFC project – a de jure transparent and interoperable data format.
Source: A. Boiko Medium
