An openly accessible database on physical measurement models in civil engineering

experiences, challenges and obstacles

Baris Wenzel*Measurement models differ from typical presentation models as used in architecture by their intended function. They were not built primarily to illustrate aesthetic properties, but rather to analyze and understand the complexities of load-bearing structures. Their use was common until the end of the 1970s to calculate complex structures such as bridges or cable net constructions. The rapid development of increasingly potent and inexpensive computers eventually replaced them almost completely. Nowadays, they are no longer used, except for dynamic load cases that are difficult to simulate, such as in wind tunnel tests or for acoustic tests. As the models were often tested to the point of material failure, and as civil engineering is often unaware of the importance of their own identity, there are few surviving models from the era of rapid technical progress, and so only a few models have made their way into archives or preserved collections holds a master’s degree in Architecture. He worked for several years as a computational designer mainly in infrastructure projects, where he developed a deep interest in geometry-relevant data structures. He is a PhD student at the University of Innsbruck, researching physical measurement models.

Eberhard Möller*,  Zoe Fränkle*, Benedict Osteratha, Benjamin Schmidb, Christiane Weberb

* Faculty of Architecture and Civil Engineering – Karlsruhe University of Applied Sciences
a  Department of Informatics – Karlsruhe Institute of Technology
b  Archive for Building.Art.History– University of Innsbruck 

Keywords: database, physical measurement models, entity relationship model 

Introduction

Measurement models differ from typical presentation models as used in architecture by their intended function. They were not built primarily to illustrate aesthetic properties, but rather to analyze and understand the complexities of load-bearing structures. Their use was common until the end of the 1970s to calculate complex structures such as bridges or cable net constructions. The rapid development of increasingly potent and inexpensive computers eventually replaced them almost completely. Nowadays, they are no longer used, except for dynamic load cases that are difficult to simulate, such as in wind tunnel tests or for acoustic tests. As the models were often tested to the point of material failure, and as civil engineering is often unaware of the importance of their own identity, there are few surviving models from the era of rapid technical progress, and so only a few models have made their way into archives or preserved collections.1

In the current research project Last witnesses – physical models in civil engineering, the last surviving models of the engineering practice are being located in order to document them and protect them from decay by developing preservation concepts. The research is part of the DFG-funded priority program 2255 cultural heritage construction. Scientists from the fields of construction history, engineering, restoration sciences and informatics from the University of Innsbruck, the Technical University of Munich, the Karlsruhe University of Applied Sciences and the Karlsruhe Institute of Technology are cooperating for this purpose. In the present paper, the experiences, challenges, and difficulties in dealing with the recording, documentation and, in particular, creation of a database for the objects preserved from engineering are reviewed with the aim of initiating a discussion.

Procedure

The main aspect of the DFG research project was to identify, in addition to the known surviving measurement models, any existing models that were unknown to the authors. For this purpose, a questionnaire was sent to more than 130 relevant institutes in the context, such as research institutions, museums and material testing institutes throughout Germany and Austria. The questionnaire for object detection served to identify possible measurement models and, in addition to basic data, also inquired about the hazard status in order to be able to create an appropriate action strategy, taking into account the urgency. The response was sorted into 3 categories: No model to report, respectively, no measurement model, potential measurement model, and no response. After the final evaluation of the data, unfortunately, no unknown measurement model could be found, only some further archival documents, which proved experiments with measurement models at some institutions.

Data formats

Intensive research was carried out on the known measurement models in digital databases and in archives and estates. After the material had been screened and evaluated, some of the plans, journals, hand drawings, photographs, slides and images were scanned and stored on a cloud. Likewise, interviews conducted in the course of the research or master’s theses on the models were stored on the server. Self-generated data, such as microscopy images of the damaged areas of the models, were also stored. The central components of the project, the physical models, could not simply be scanned due to their three-dimensional nature. In some cases, the models are very delicate, which is difficult to image even for a 3D scanner. Therefore, the creation of digital twins had to be done by other means. In addition to photogrammetry, digital formfinding methods and algorithms were used. The digital planar images are used for digital mapping of damage, but will also be used as a basis for digital exhibitions and VR applications in the future. In addition to point clouds, the creation process has produced data in 3dm format and other proprietary file formats. Initially, the geometry data, such as vertex coordinates, were fed into a SQLite database to allow for easy decoding in case one of the proprietary formats should not be readable at a later time. Initiated by a discussion with A. Nowak it was started to store the geometry data as OBJ format, since this serves the same purpose. It becomes evident that the use of a variety of data formats is possible, but also necessary, to capture the objects as completely as technically possible.

Ownership and copyright of the digital twins

Some of the information on the models was not readily available and handling some of the information for the planned database was difficult. For example, not only is the ownership of the actual measurement models often unclear and difficult to understand, but the legal status of the digital twins created is also oftenambiguous and differs, for example, depending on how the twin was created. Important here is the term work, which denotes a personal intellectual creation. It is often not clear whether a creative work has been created, so that German case law often deals with this question.2 A recorded measurement model can be protected by copyright. Similarly through the creation of a digital 3D model, a creative work can be created that can be protected by copyright law. If a 3D model is the target of a 3D scan and is created by reprocessing a point cloud, the 3D model is considered a creative work of art and the point cloud itself is considered only a tool. However, if an object is remodelled, no copyrights are breached.3 There are also cases that seem even more complicated. In the case of the creation of a twin, a special legal situation opened up during a visit to the company premises where the measuring model is located: The company that had once created the model has since been taken over by another company. The model remained on the premises, but never explicitly became the property of the acquiring company. The former owner no longer exists and the new owner is not the owner. Since the ownership situation cannot be clarified without further ado, we will not publish the relevant data for the moment.

Database structure

To create the database for the collected data on the physical measurement models, the DB Browser for SQLite4 program was used and was visualized in the form of an entity-relationship model in DBeaver5. Visual Studio6 and ASP.net Core7 with the View Controller (MVC)8 model were used for programming. The selected programs are commonly used in the context of database programming and are proven with positive experiences. The database is designed as a relational data structure in the second normal form (2NF), in which the data is stored atomically and each non-key attribute is functionally entirely dependent on each key attribute.9 In principle, as usual, entities, attributes and relations were used via the application of foreign keys. The central entity of the database is the model to be inserted. It contains simple text and number attributes, such as name, scale, section or creation period. The entire model can be uniquely identified via the primary key of the ID. Various foreign keys, such as ID material, ID condition or ID endangered, are used to relate the model to other tables. New tables have been created in particular for predefined, logical drop-down selections, such as endangered, condition, testing institute, or for 1:n relationships, such as project to model, and n:m relationships, like model and person. For 1:n relationships, an entry in one table is related to multiple entries in a second table. For example, a single project can have multiple models related to it. In n:m relationships, the relation exists in both directions. For example, one person can be involved in several models and several people can be involved in one model. Extensive planning using ER diagrams at the beginning helped to determine expected and probable dependencies among the data. Furthermore, an iterative workflow can be used to introduce new or changed relations, although a structured basis simplifies all further processes.

Entry form

To fill the database, a simple, user-friendly HTML web form was developed with the help of the programs and frameworks used to enter the data. The form contains predefined boxes to fill in, given selection options via drop-down menus, dynamic fields if, for example, there are several originators, or upload buttons for additional file formats. Basically, the form ensures a fast, easy-to-understand and standardized entry and, in particular, editing of data. A later manual modification of n:m relationships proves to be very complex, which is why the editing function via the form is very time-efficient. The form makes it possible to make an entry or to change an existing entry without having to understand the data structure.

Conclusion and outlook

We decided to create our own database structure in order to be able to customize it perfectly to our specific needs, also because there is no satisfactory solution for technical cultural assets of this kind on the market. Furthermore, we wanted to make ourselves as independent as possible from third-party providers. Questions such as on which server to host the data so that it is not lost after the end of the project still need to be finalized. Since the clarification of the copyrights will certainly take some time, we will only make a small part of the collected data publicly available and release the majority of the database only for registered users. The challenges and difficulties, as well as the effort to create our own database structure, show the desideratum of a nationally more uniform research data infrastructure, which is flexible enough to handle different object types, data formats, etc.

Bibliography
  1. Bühler, D. and Weber, C. (2021). ‘Epilogue: A future for models from the past’, in Addis, B. (ed.) Physical models. Their historical and current use in civil engineering design. Berlin: Wilhelm Ernst & Sohn, pp. 1025–1046. ↩︎
  2. Werk_(Urheberrecht). „Urheberrecht“, 5. Oktober 2023. https://de.wikipedia.org/wiki/Werk_(Urheberrecht). ↩︎
  3. Mayr, Manuel. „3D-Scan und urheberrechtliche Fragen“, December 2016. ↩︎
  4. Simplified database schema, which is based on SQL: https://sqlitebrowser.org ↩︎
  5. Database management tool: https://dbeaver.io ↩︎
  6. Development environment for programs: https://visualstudio.microsoft.com/de/ ↩︎
  7. Web development framework: https://learn.microsoft.com/de-de/aspnet/core/introduction-to-aspnet-core?view=aspnetcore-7.0 ↩︎
  8. Design pattern for website development: https://learn.microsoft.com/en-us/aspnet/core/mvc/overview?view=aspnetcore-7.0 ↩︎
  9. Schlageter, Gunter. Stucky, Wolffried. Datenbanksysteme: Konzepte und Modelle. B. G. Stuttgart: Teubner, 2. Auflage, 1983, S.178. ↩︎