Documentation

Documentation for Bedrock.

Definition of Bedrock

In an abstract sense, the main principles on which something is based. [1]

In the real world, the bedrock is the hard area of rock in the ground that holds up the loose soil above. [1]

In many civil engineering projects, the identification of the bedrock through digging, drilling or geophysical methods is an important task, which greatly influences (foundation) design. [2]

Sources: [1] Bedrock | Cambridge Dictionary, [2] Bedrock | Wikipedia

Bedrock, this open source software project, forms the foundation for for ground investigation data, subsurface modelling and Geo-BIM.

With Bedrock you can get your data from any Ground Investigation data format into a GIS database 🗺️, from a GIS database into Speckle 🟦, and from Speckle into all the software we work with in the AEC industry 🏗️.

The purpose of Bedrock is NOT to become THE standard for geotechnical data, because we don’t need 15 instead of 14 competing standards:

14 competing standards become 15 competing standards | xkcd.com/927
Source: https://xkcd.com/927

For example, us geotechnical engineers who are used to working with AGS data know that the “ISPT group” is a table that describes an In-Situ Standard Penetration Test and we know what headings, i.e. columns that AGS group, i.e. table has. Therefore, Bedrock doesn’t change that the naming of those columns. Bedrock just makes sure that the data is structured in a sensible way, such that Ground Investigation data from multiple sources can be converted into a GIS database.

A GIS database with Ground Investigation data contains tables that describe the Ground Investigation 'Project', the 'Location's where GI data was collected, the 'Sample's and 'InSitu' measurements taken at these 'Location's, and the 'Lab' tests that were performed on the collected 'Sample's.

The 'Project', 'Location', 'Sample', 'InSitu' measurement and 'Lab' test tables are related to each other: each lab test belongs to a sample, which belongs to a GI location, which belongs to a project. These relationships can be visualized in a hierarchy like this:

'Project'
 └───'Location'
     ├───'InSitu'
     └───'Sample'
          └───'Lab'

These relationships are represented in the database tables with so-called “foreign keys”. For example, the results of an Atterberg Limits Lab test, i.e. Liquid Limit and Plastic Limit tests, that originated from an AGS file would be in stored in the 'Lab_LLPL' table. Each row in this table represents the Atterberg Limit test results performed on a specific sample. Each row knows to which project, GI location and sample it belongs through its project_uid, location_uid and sample_uid respectively.

This relational database (linked tables) with Ground Investigation data becomes a GIS database by assigning a (3D) GIS geometry to each of the rows in each of the database tables (except for the 'Project' table).