We have put together an import mapping file that can be used to import Standard US and Standard US with Lab gINT Project Files (.gpj’s) into OpenGround.

The mapping file is intended to be used with the OpenGround US configuration pack.

The mapping file is provided as an example. If your organizations has modified the gINT Standard US files or the US configuration pack, the mapping file may need to be updated accordingly.

The mapping file can be downloaded here.

And can be uploaded as a gINT import mapping to either a project or configuration pack.

Additional information:

1. The ‘gINT Standard US with Lab’ files use the Lab Testing module for storing lab data, while the ‘gINT Standard US’ files include a TESTS table for storing lab data. The mapping file includes mappings for both the Lab Testing tables and the TESTS table. The irrelevant mappings are not used during the import process, allowing the mapping file to be used for both versions of gINT files.
2. The gINT SAMPLE table records are mapped to what we unofficially refer to as the “sampling activity” groups, which includes the OpenGround Coring Information, SPT, and Dynamic Sampling Run Details (Dynamic Sampling Run Details can be thought of as “other sample/sampling activity types”.) There are conditions in the mapping file to determine the appropriate group for each SAMPLE record to be imported to.

Generally, gINT SAMPLE records are not imported to the OpenGround Sample Information group in the mapping file. The exception to this is for SAMPLE records that contain data in the Other Tests field, in which case this data is imported into the Sample Information ‘Remarks’ header. The Sample Information group can be thought of as a table for capturing physical samples that have been tested in the laboratory (similar to the gINT LAB SPECIMEN table or TESTS table), rather than for capturing “sampling activity” details like SPT blow counts or Core RQD’s.

Instead, the records from the gINT LAB SPECIMEN table and TESTS table are imported to the Sample Information group. These records then serve as the parent records against which lab test data are stored.

The implication of this is that imported lab data is identified by just the ‘Depth Top’ key header (as it is within the gINT LAB SPECIMEN and TESTS tables). This is generally sufficient for most uses of the data. This approach also simplifies the mappings as all lab data is identified by depth both within gINT and OpenGround.

However, there may be cases where you would like additional information associated with the lab test data, such as Sample Numbers or Types. This is possible within a mapping file. It would require importing the gINT SAMPLE records to both the “sampling activity” groups, as well as the Sample Information group, so that additional key headers like Sample Reference and Type can be populated. It would also require more complex mappings to “lookup” the associated Sample Reference and Type for gINT lab data records so that the lab data is associated with the correct parent Sample Information record. There are different variations to how this could be done depending on how your organization has managed lab data within gINT and how you would like that data stored in OpenGround. For that reason, we have chosen to use the simple approach in the example file and import Sample Information and child lab data solely as Depth Top records. The mappings can be modified if you’d like to use alternative conventions.

3. Mappings for the Lab Testing tables generally import final calculated results only. Raw input values are generally not imported (except for tests where raw readings are typically presented as curves on graphs.)
4. Mappings are included for the gINT LITHOLOGY SOIL (Soil Components) and LITHOLOGY ROCK (Rock Components) component description tables. The gINT component description model does not exactly match the example component description model in the US configuration pack so not all fields are mapped. The mappings are intended as examples and can be modified as necessary for your organization’s purposes.
5. Like with all imports, Warnings will be presented to the user of any issues encountered. There may be warnings that some gINT system tables are not mapped. These can be disregarded.

In general, the mapping file has been set up with “Ignore” mappings to suppress Warnings for gINT fields that are not relevant for import into OpenGround (such as for raw lab readings, report configuration fields, gINT system fields like GintRecID, or to suppress “false warnings” which may occur if a field is mapped using an expression).

You may see Warnings for any data that is potentially relevant, but has not been mapped in the example file (such as for component descriptions – see above).

6. Well details are stored quite differently in gINT and OpenGround. The mapping file does include mappings to import the gINT WELL CONSTRUCTION information to the appropriate OpenGround groups. However, there are variations to how this data can be entered within gINT, which may result in some data not being imported appropriately in OpenGround.

To simplify, the mapping file focuses on importing the “below ground” details and ignore the “above ground” details (i.e. at negative depths for showing stickup/surface completion where data entry conventions may be most variable and least compatible with OpenGround).

If your organization used different well data entry conventions or modified the standard files, you will need to modify the mappings. If the imported data is likely to be of low quality/value for your organization, you may want to simply remove those parts of the WELL CONSTRUCTION  mappings.

Also, note that Pointers are not imported, and the gINT well Descriptions are all imported to the OpenGround Backfill Details group (because there is no way to reliably discern and map them appropriately to the Backfill Details vs. Monitoring Installation Pipe Work groups).

(And lastly, it's worth noting that the way the data gets imported is not how you would want to manually enter new Backfill/Pipe data into OpenGround. The way the graphics are “stacked” in gINT sometimes results in multiple adjacent records in the imported data that could be consolidated into a single record if entered directly.)

7. Some fields in gINT, particularly in the Lab Testing module are unitless (any consistent units can be used). An example would be Stress in CONSOL READINGS. You will want to check that you are using consistent units between gINT and OpenGround. If not, you can change potentially change the units for that header in OpenGround, or modify the mappings to convert the values.
8. Please refer to our Import Mapping documentation and Common Issues articles if you encounter issues.
9. The mapping file is provided as-is. Please QA/QC the imported data to ensure accuracy and suitability. Comments, suggestions, and error reports are appreciated.