OR/15/046 The user interface

Wood, B, Richmond, T, Richardson, J, Howcroft, J. 2015. BGS Groundhog® Desktop Geoscientific Information System External User Manual. British Geological Survey Internal Report, OR/15/046.

The user interface is divided into a series of panels. These panels can be undocked (split) if desired via Session > Windows > Dock/Undock All Windows.

Toolbar

The toolbar includes a conventional menu bar and a tabbed panel of buttons for loading, saving and manipulating data.

Menus

Session — various load/save options for assembling a workspace session
Interoperability — various options for import/export of non-GDE-format proprietary and standardized data formats
Tools — various useful data tools
Geology — tools to predict and deduce geological information from workspace data objects
Help — about Groundhog Desktop

Toolbar tabs

Data — workspace and data load/save buttons
Draw — editing and digitizing functions and settings
Calculate — prediction and deduction tools
Check — data checking tools

Workspace panel

The workspace panel is a tabbed panel providing access to the data objects loaded into the workspace. It has the following tabs.

Workspace

This tab provides a categorized list of loaded data objects displayed in a hierarchical workspace object tree control. Depending on the category and the level of object in the object tree, various context-specific menus are available via right-click.

Note that not all object types displayed in the tree are currently supported, and may vary across versions of the software.

When you load a project its data objects will be added to this workspace object tree. To navigate the workspace object tree simply click on the + icons to expand each level of detail. Depending on the type of the object and the level of detail, various context-sensitive popup menus are available via right-click.

Codes

This tab provides a reference list of geological rock layer codes referred to as the Coding Scheme, including some special codes such as “FAULT”. Picking a code from this list makes that code the active code for editing/digitizing. For details of how this list is created refer to the Dictionaries and Coding Scheme sections of this manual.

Log View

This tab provides a downhole log viewing window for borehole data. Refer to the Log View section of this manual for further details.

Grids

This tab is currently not used.

Map panel

The map panel is a container for any map windows you create. The map windows behave a little like tabbed windows in a web-browser. You can create as many map windows as you wish. For further details on map windows refer to the Map Window section of the manual.

To open a blank map window use Session > Windows > New Map Window then click on the zoom to full extent button.

Cross-section panel

The cross-section panel is a container for any cross-section windows you create. The cross-section windows behave a little like tabbed windows in a web-browser. You can create as many cross-section windows as you wish. For further details on cross-section windows refer to the Cross-Section Window section of this manual.

Workspaces and projects

All data in Groundhog Desktop are held either in a Workspace or a Project. A Workspace is a high-level set of static reference data that may be common to many projects (e.g. DEM, national rock coding scheme). A Project is a set of individual data files that are actively being worked on (e.g. cross-sections, maps, boreholes).

Supported Data Types

Groundhog currently supports (to varying degrees);

Dictionaries
Colour legends
Elevation grids (rasters)
Unstructured meshes (TINs)
Boreholes
Interpreted cross-sections (correlation linework and fault sticks)
Map linework (“croplines”)
Fault traces
Geological sequence tables
Images (including geo-registered images in map and section)
Web Map Services (WMS)
Shapes

For more details on each, refer to the relevant sections below.

For most of the above, Groundhog has its own XML-based data file format referred to as Geological Object Markup Language (*.goml). Generally it is not advisable to edit these data files manually — they are designed for data transfer and local project storage. XML schemas for some of the key objects are available on request via groundhog@bgs.ac.uk

Workspaces

Groundhog workspaces are folders containing related collections of commonly used reference data. A single workspace may support several Grounghog projects by containing all of the common reference data for those projects, such as a national or regional rock coding scheme and a digital terrain model.

The default workspace is held in a folder called WORKSPACE_DEFAULT within the installation directory. Any reference data files included in this folder will be added to the default workspace. You can create your own workspaces by compiling the desired files in a folder of your choice and selecting this folder when Groundhog starts up by using the “+” button in the workspace selection dialog. The pull-down list contains a list of all previously loaded workspaces to choose from.

Typical data resources include;

Dictionaries — usually at least a rock coding scheme
A colour legend file
Grids — e.g. a digital terrain model

Workspace data resources can be included in two ways;

By physically placing the data file within the workspace folder
By adding a file path to the data file into the RESOURCES.txt file

The RESOURCES.txt file is a tab-separated file held within the workspace folder and comprising one data resource linkage per-line;

DATA TYPE	NAME	PATH/URL	EXTRA INFO
GRID	Terrain Model	C:\Data\terrain.asc	MODEL_CAP
DICTIONARY	London Formation Codes	C:\Data\LondonCodes.godic
WMS	UK Geology Web Map Service	http://...etc

Note: RESOURCES.txt contains no headers. They are included above for clarity.

For GRID type objects, the extra info of “MODEL_CAP” sets that grid as the reference terrain model for the workspace. This can be changed interactively within the user interface if necessary.

Dictionaries

A dictionary is simply a list of names with corresponding definitions (values). They are commonly used by Groundhog to look up descriptions of abbreviated or coded values, for example;

SSG	Sherwood Sandstone Group

Cu	Copper

Dictionaries are held in XML format with a file extension of *.godic (Geological Object DICtionary). The format is as follows;

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<dictionary_entry name="SST" value="Sandstone" />

<dictionary_entry name="MDST" value="Mudstone" />

<dictionary_entry name="LMST" value="Limestone" />

</dictionary>

</GeologicalObjects>

Groundhog needs at least one dictionary which is referred to as the rock layer coding scheme (see next section).

Dictionaries can also be imported from a tab-separated text file where the first two columns of the file are the NAME and the VALUE. Further columns will simply be ignored.

Coding scheme

The coding scheme is a list of rock layer codes from which you can select for editing and digitizing. They are held as a Dictionary object. Groundhog ships with a pre-defined coding scheme based on the BGS Lexicon of Named Rock Units (http://www.bgs.ac.uk/lexicon/), but you can import your own codes from a tab-delimited text file (see Dictionaries), or create your own coding scheme dictionary file in the workspace (WORKSPACE_DEFAULT\CODING_SCHEME.godic).

Colour legend file

Colours are held in a tab-separated text file called LEGEND.txt in the workspace folder (WORKSPACE_DEFAULT\LEGEND.txt). You can add colours to the Groundhog workspace by adding to this file, or create your own file. The format is;

CODE	RED	GREEN	BLUE	ORNAMENT IMAGE
AAFS-AFSY	255	147	51	texture_library/a.jpg
ABBR-BREC	255	117	84	texture_library/b.png
ABBR-BRSS	255	117	84	C:\image.jpeg

Colours are defined in the RGB colour model http://en.wikipedia.org/wiki/RGB_color_model where values for each colour are between 0 and 255.

Elevation grids

Groundhog supports regular grids for elevation models, for example a Digital Terrain Model. At least one grid to define the “model cap” (normally a terrain model) is required as this will be used to auto-generate profiles for the cross-section windows.

Groundhog has its own binary format for grid data which enables it to maintain a permanent reference to a master terrain model and query the necessary elevations and profile as required — for example when a new cross-section is created or loaded. This format is a binary version of an ESRI-style ASCII grid file (http://en.wikipedia.org/wiki/Esri_grid) and is very efficient because you can have a regional or national DTM coverage registered with Groundhog without any computer memory issues. Groundhog will automatically query this data layer as necessary.

Loading Grid Data
ASCII grids (*.asc) can be imported via Interoperability > Import menu and will be automatically converted to the Groundhog binary format in the background. The object will be added to Reference Objects > Grid Coverages in the object tree. ASCII grids must have a header laid out in the following format;

ncols 2000

nrows 2500

xllcorner 1000000

yllcorner 1200000

cellsize 25

NO_DATA_VALUE -9999

154.6 157.2 159.8 161.4 162.7 164.3 165.4……[DATA…etc]

Groundhog will attempt to save a binary copy of the imported grid in the same folder as the ASCII file. If this is not possible (e.g. because the ASCII is in a read-only folder), Groundhog will instead save the binary file into the current workspace folder. If the grid is large the conversion process may take a few moments.

To add a new binary grid to your workspace so that they are always available make sure to add a reference to it into the RESOURCES.txt file, otherwise you will need to re-load the grid each session. Use one line pre-grid entry. If you wish to set the grid as the default capping grid, append the term “MODEL_CAP” to the end of the row. Note that the values in the row are tab-separated, e.g.

GRID A Grid C:\Data\Grid_1.obgrid MODEL_CAP

GRID Another Grid C:\Data\Grid_2.asc

If you add an ASCII grid to the RESOURCE.txt file it will be automatically converted to binary. The next time the workspace is loaded Groundhog will automatically find the corresponding binary grid file for the ASCII listing, so there is no need to update the RESOURCE.txt file after the conversion process.

IMAGES

Groundhog supports JPEG and PNG format image files which can be loaded via Session > Load Reference Objects > Image. If the image has a world file it will be automatically detected and the image can then be displayed in a map window in the correct geographic location (geo-registered). Note that Groundhog does not support rotated images.

Loaded images can also be registered into a cross-section window interactively. This is particularly useful when digitizing. Refer to the Cross-Section Window section of this manual for further details.

WEB MAP SERVICES

Groundhog is a rudimentary WMS client, allowing certain BGS-published WMS services to be displayed in the map window(s). The URL to the WMS should be included in the workspace RESOURCES.txt file, e.g.

WMS BGS_Detailed_Geology https://map.bgs.ac.uk/arcgis/services/BGS_Detailed_Geology/MapServer/WMSServer

Loaded WMS services will be added to the Reference Objects > Web Map Services folder in the workspace object tree. The default workspace of Groundhog comes with a link to the BGS digital geological map as a WMS so this should automatically appear in the tree.

To display the WMS in the map window, right-click (on the WMS layer of interest) > View WMS Layer In Map.

Note that Groundhog has no capability for Latitude/Longitude, so can only support WMS services which can respond to requests in a cartesian grid coordinate system (e.g. British National Grid).

Projects

Projects are what you normally work with day-to-day to load and save the data you are working on. Project data is held in XML data files. For this, Groundhog has its own XML- based data file format referred to as Geological Object Markup Language (*.goml). Generally it is not advisable to edit these data files manually — they are designed for data transfer and local project storage.

Each GOML file contains objects of a single type, for example boreholes or cross-sections. When data is saved out as a Groundhog project a Geological Object Project file (*.GOP) and a series of GOML files is created, one per object type;

Project1.gop
Project1.cross-sections.goml
Project1.boreholes.goml
Project1.faults.goml
Project1.croplines.goml

Note the naming convention. The first part of the file name is the name of the project, and the second part (shown in bold above) is the data type. Never re-name files manually because Groundhog relies on this naming convention to find all linked data files.

To load a project, simply pick the .gop file via Session > Load Project or click on the load button in the toolbar data tab.

All GOML files associated with the project will be automatically loaded. To load GOML data files individually use Session > Load Geological Objects > From GO File menu. Data in other formats can often be imported and exported via the Interoperability menu (see the Interoperability section of this manual for further detail). Certain reference data can be loaded via Session > Load Reference Objects.

To save a project use Session > Save Project or click on the save button in the toolbar data tab.

When saving a project, if you retain the existing project file name when you press save the previous versions of the data files will be over-written.

You are strongly advised to save your work regularly. Do not wait until the end of the day to save all of your work. You are also strongly advised to increment the project name from time-to-time to ensure you have a series of project backups should the saved-out data become corrupted, e.g.

Project1_v1.gop
Project1_v2.gop
…
Project1_vn.gop

Project data files are generally quite small, so keeping a series of backups should not present any data volume issues and superfluous backups can be deleted manually if desired.