# Overview ## Batch Import Workflow (General → Samples → Measurements) Batch import has three sequential steps: (1) import General Data to create locations, (2) import Samples, (3) import Measurement Data — tests must be imported after their parent samples exist. Import wizard is triggered from the objects level via `Import General Data`; samples imported via `All Objects > Import Samples`; measurements via `Measurement Points > Samples (or Locations) > Import Measurement Data`. The import wizard has consistent steps: (1) Data Source (choose file + worksheet), (2) Parameter Links (map source columns to GeoDin fields), (3) Import (preview + execute). For sample import, users must add a column (e.g. named "Location") identifying the borehole each sample row belongs to — GeoDin uses this column to match samples to existing locations. For measurement import, users must build a concatenated identifier string (borehole + sample reference + from + to recovery depth) to match each measurement row to the correct sample — the column is typically named `MeasID` or similar. For the main measurement data type, bulk import is possible across multiple samples at once. For complex (sub) data types (e.g. UU curve, CU measurement data), import must be done one measurement point at a time; there is no bulk import for complex/nested data types. Batch import is supported for general data, samples, data sequences, and sample-level measurement tests. ## CSV & Excel Import Supported import file formats include Excel worksheets and CSV/text files. The easiest import path is to create an Excel table that resembles the tabular view of GeoDin — column headers matching either the long parameter name or the short database field name will auto-link via the `Automatic Link` button. Column mapping can be established via drag-and-drop from the GeoDin parameter list (left pane) onto the source header (right pane), or via auto-link if names match. Parameter mapping configurations can be saved as an ICF file and reloaded in subsequent imports to skip the manual mapping step. On import preview, invalid/out-of-range values are flagged in red; dictionary values that don't match existing entries are flagged but still importable. After mapping, the preview shows new data in green and overwritten data in purple/light green. Dictionary fields can be imported using either short codes (e.g. `CPT`) or full text values. Recommended preparation workflow: first export an existing data type from GeoDin to Excel to get a template with correct headers, then fill it in and re-import. User unit system toggle lives under `File > Unit System` — switches between Metric (SI) and US Customary; unit conversions (e.g. feet to metres) happen on the fly during import. ## CPT & Data Sequence Import (GEF, ASCII, Custom Filters) GeoDin has a dedicated ASCII CPT import filter built for historic company use. For generic depth-sounding data, users should use the "General Data" import section within Data Sequences (not the ASCII-specific CPT importer). CSV CPT import is NOT handled by the CPT-specific importer — users must use the generic Data Sequences import. GEF file format is supported natively for CPT data (GEF is a standard format used in the Netherlands and UK). Import filters for Data Sequences are user-created structures defining: depth column index, data-columns-begin column, number of data columns, decimal places, decimal delimiter, field separator, unit of depth column, and series name for each data column. The Import Filter dialog is opened via `Import > Import Filter > New Import Filter`. Filters are stored in the user's syslib configuration folder in a file called `Sony_Filter.sys` — this file can be shared between users to distribute filter configurations. The Data Sequences import has a constraint: data columns MUST be located to the right of the depth column in the source file. The Data Sequences import has NO option to skip/exclude specific columns during import — all columns right of depth are imported; users must delete unwanted series manually after import. Users can build their own custom import filters for arbitrary depth-indexed data such as "measurement while drilling" (penetration speed, tool pressure, injection pressure, torque, RPM). Data sequence series can be re-exported as CSV files — useful if users import, modify, and re-export. ## Excel Export as Import Template Source GeoDin can export any data table (general data, samples, measurement data) to Excel via the red-dot export button — the recommended way to see the expected headers/structure before preparing an import table. The tabular "All Objects" view under Data Management shows general data for all locations in a single sortable table — this view can be exported to Excel for template creation. Exported Excel files contain headers matching GeoDin's internal parameter names, ready for round-trip re-import. ## gINT Migration & Layer Data Import Gap gINT users historically populated layer data in Excel and imported to gINT — this Excel-based layer import is an explicit gap in GeoDin for the G1/Location object type and is a flagged critical feature request. The gINT `.mdb` object type was mainly for boreholes and CPT locations — GeoDin's G1 object type was built to mimic this workflow. GeoDin's AGS object type was built to mimic AGS group/header structure; importing AGS files "saves you this part of the job" because ground descriptions come through the importer automatically, unlike the manual-entry workflow required for G1 with non-AGS data. The layer-data import gap is acknowledged internally as "a topic that's been discussed" and "a felt issue we need to deal with at some point"; the commercial team tracks feature requests internally and ranks this one near the top. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.geodin.com/importing-data/import.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.