Geotechnical Data Management Software: Why Twenty Years of Boreholes Are Trapped in PDF Reports

Why a geotechnical group loses its own data

A senior engineer is starting foundation design for a site in a corridor the firm has worked for twenty years. She is nearly certain there are boreholes within 300 metres from a job in 2011 and another in 2017. Finding them means asking two colleagues who might remember the project name, searching a network drive, opening PDFs and reading logs off a scanned page. She gives up after 40 minutes and specifies four more boreholes. The client pays for ground investigation the firm already did.

Meanwhile the current job is running. Field logs come back from a driller's tablet in one app, or on paper if it rained. Samples go to two laboratories because the schedule needed classification quickly and the triaxials had a two week queue. One lab returns an Excel workbook, the other returns a PDF report with a spreadsheet attached that has moisture contents in a different column order. A graduate engineer retypes the results into the logging package, and somewhere in that retyping a depth gets transposed.

The products in this space are real and some are very good. Bentley OpenGround and its predecessor gINT are the long standing default, HoleBASE SI is strong in the markets that live on the AGS data exchange format, and Datgel builds serious extensions on top. What they are built for is the current project: capture data, produce a log, export a section. What they are not built for is a firm treating its investigation history as an asset, or absorbing lab feeds that will never standardise, or producing the specific deliverable a particular client has demanded for the last fifteen years.

Problem 1: the lab feed will never be standard, so stop waiting

The AGS format exists precisely to solve this and it works when everyone uses it. In practice, adoption varies by market and by lab, geoenvironmental labs often report through their own portals, and the small specialist lab doing your advanced triaxial testing sends a PDF because that is what their instrument software produces. Asking a lab to change its output for one client is a conversation that ends politely and changes nothing.

What a custom build does: an ingestion profile per laboratory. Each profile knows that lab's column meanings, units, test method references and the way they report a non detect or a failed specimen. Results land against the correct sample, which is identified by project, borehole, depth range and sample reference rather than by whatever the lab typed. Every ingest produces an exception report: samples sent but not returned, results returned for samples that were never dispatched, and values outside a plausible range for that soil description. That last check catches more real errors than any amount of careful typing, because a plasticity index that contradicts the field description is a machine detectable contradiction and a human reading a spreadsheet will not see it.

Where extraction earns its place is the PDF lab report. A model reading a test summary table into structured values, with anything uncertain routed to a review queue, removes the single most tedious task in the office. It should never write directly into the design dataset without a human accepting the batch.

Problem 2: the log is a drawing, and the drawing is the deliverable

Clients do not buy data, they buy logs, sections, factual reports and eventually parameters. Log presentation is governed by standards that vary by country and by client: hatching conventions, the sequence of columns, how a water strike is shown, whether SPT blows appear as increments or a single N value, which lab results are printed alongside the description. Firms often maintain several presentation styles because a long standing client demands theirs.

The packaged tools handle this through templates and they do it reasonably well. Where teams still lose days is the last mile: a client whose specification requires a column the template cannot express, or a factual report whose appendices must be assembled in a particular order with a particular numbering. So the log gets exported and then edited, and once it is edited it has diverged from the data.

What a custom build does: keep the data authoritative and treat every presentation as a rendering, never an editable artefact. If a client wants an unusual column, that is a template change, not a manual edit. The moment a log is edited outside the system you have two versions of the truth and one of them will be issued. This is a discipline decision as much as a software one, but software is what makes it enforceable.

Problem 3: the historical archive is the firm's most valuable asset and it is unusable

Twenty years of investigations sitting as PDF reports represent thousands of boreholes across a region where you keep working. That archive is a genuine competitive advantage: it lets you propose a smaller, smarter investigation, it de risks early advice, and it makes you look like the firm that knows the ground. It is worth nothing while it is unsearchable.

What a custom build does: extract the archive and index it spatially. Location, depth, stratum descriptions and key test results come out of the old reports through a combination of text extraction and human verification, then sit in a map interface where a new project's site boundary returns every prior investigation within a radius, with a link to the original report. Firms are often nervous about the extraction quality. The honest answer is that you do not need perfect. You need enough to know that boreholes exist at that location and roughly what they found, because the engineer will open the original report anyway. Attempting perfect extraction of every value is where these projects go over budget, and it is unnecessary.

Order the work by value: extract the corridors and cities where you bid most often, not the whole archive chronologically. A regional consultancy we worked with found the payback came almost entirely from three urban areas.

Problem 4: the handover from factual data to design parameters is undocumented

A geotechnical report contains characteristic values: an angle of friction, an undrained shear strength profile, a settlement modulus. Those values come from a set of test results filtered by an engineer's judgement, discarding a suspect specimen, weighting a correlation, choosing a design line through a scatter. That reasoning usually lives in a spreadsheet on one engineer's machine, and when the design is questioned two years later nobody can reconstruct which results were included and why.

What a custom build does: make parameter selection a recorded step. The engineer picks the dataset, applies filters that are captured, draws the design line and records the justification, and the output is a parameter set with a permanent link to the exact test results behind it. Reissue that report a year later after four more boreholes and the system shows what changed. This is the part no packaged tool attempts, and it is the part that carries professional liability, which is why technical directors sponsor it once they see it.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the project and borehole data model, field logging on tablets with offline capture, laboratory ingestion profiles with exception reporting, and automated log and section production in your standard presentations runs $60,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding the spatial historical archive with extraction, client specific deliverable formats, laboratory scheduling and turnaround tracking, parameter selection with recorded justification, and export to design software runs $160,000 to $420,000 phased over 6 to 12 months.

What pushes the number up: the number of distinct presentation standards you must support, because each one is real drafting work. The size and condition of the historical archive, particularly if it is scans rather than digital PDFs. Instrument level integration, for example reading cone penetration test output directly rather than importing a file. And offline field capture in genuinely remote conditions, which is more engineering than it sounds.

What keeps it down: exporting and importing AGS wherever your market uses it rather than inventing an interchange format, and starting with your two highest volume labs rather than all seven.

Build versus buy, and when the packaged tools win

Buy if you run under about 15 investigations a year, use one or two labs, and produce logs to a single common standard. gINT, OpenGround, HoleBASE SI and Datgel's extensions cover that well, the licence cost is modest against a build, and there is a pool of engineers who already know them. Buy also if your firm has no appetite to own a system, because a data platform without an internal owner degrades within two years.

Build when two or more of these are true. First, you run enough investigations that lab data entry is a recognisable cost line. Second, you receive results from more than three laboratories in incompatible formats. Third, you hold a historical archive in a region you keep working and cannot search it. Fourth, a major client requires deliverables your current tool cannot produce without manual editing. Fifth, you want parameter selection recorded because a professional liability review has made that uncomfortable.

The distinguishing question is whether you see ground investigation data as a project artefact or a firm asset. If it is a project artefact, buy a logging package and move on. If it is an asset, meaning you expect it to win work and reduce risk across future projects in the same ground, then it needs to live in a system you control with the extraction, indexing and search that a logging package was never designed to provide.

How to choose a developer for geotechnical data software

Ask whether they know what AGS is. If your market uses it and they have not heard of it, they will invent an interchange format and you will spend the next two years explaining to clients why you cannot send them a standard file.

Ask how a sample is identified. The right answer involves project, hole, depth range and sample reference as a composite, because lab references are not stable and clients renumber holes between phases. A developer who proposes a single sample id issued by the system has not dealt with a lab returning results under their own numbering.

Ask how they would approach the historical archive and listen for whether they scope it by value or by volume. Anyone proposing to extract every value from every report perfectly is going to overrun. The right answer starts with location, depth, strata and headline results in your busiest geographies.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue. At Digital Heroes the client owns the code from the first commit. Your borehole archive is the firm's accumulated knowledge of the ground under a region, and it should not sit in a system somebody else controls the keys to.