Inputs

Introduction

For clarity, we refer to ‘inputs’ as the inputs to map2loop and map2model libraries and ‘augmented data’ as the products of map2loop. The augmented data in turn form the inputs to the target 3D geological modelling engines. All temporary inputs and outputs from the related map2model library are wrapped within the map2loop library.

The information contained in a geological map falls into three categories of geometric data: positional data such as the position of faults, intrusive and stratigraphic contacts; gradient data, such as the dips of contacts or faults and finally spatial and temporal topological data, such as the age relationships between faults and stratigraphic units. As modellers we combine all of these direct observations with conceptual information: knowledge from near-by areas; our understanding of the tectonic history of the region, including assumptions regarding the subsurface geometry of faults and plutons, and generic geological knowledge (such as our understanding of pluton emplacement mechanisms) to provide sufficient constraints to build a 3D geological model. Often, these concepts are communicated via geological cross-sections supplied with the map, however these are typically based on limited or no additional data as they combine the conceptual ideas mentioned above with local positional and gradient information derived from the map, although they can now routinely be validated using regional geophysical datasets such as gravity and magnetics (Spampinato et al., 2015; Martin et al., 2013). Even when we have seismic reflection data in basins, the role of conceptual biases cannot be ignored (Bond et al., 2007; Bond, 2015) In addition, the map will usually supply a stratigraphic column that provides a more direct but simplified representation of stratigraphic relationships.

In this library we draw inspiration from existing manual workflows and structural decision-making processes by developing a suite of algorithms that allow us to automatically deconstruct a geological map to recover the necessary positional, topological and gradient data as inputs to different 3D geological modelling codes. Some of the code simply reproduces the 3D modelling packages’ abilities to import different datasets, however much of it is dedicated to extracting information that is contained within the map but rarely extracted from it in a systematic fashion, as it can be rather tedious to do so, although systems such as GMDE certainly help (Allmendinger, 2020).

The libraries described here retrieve information from GIS layers or online servers, clean and decimate the data if needed, and then go through a series of data analysis steps to extract information from GIS layers stored locally or on online servers. This information includes: the local stratigraphy, the geometries of the basal contacts of units, and faults, estimates of local offsets along faults, and estimates of local formation thickness. Once these and other information have been extracted, they are output as standard formats (Graph Meta Language (GML), csv, geotif and ESRI shapefile formats) so that the target 3D modelling systems can use them as they are.

Once the input parameters are defined, the entire workflow is automated, so all decisions about choices of parameters are made up front and the consequences of these decisions can be directly analysed in terms of the augmented outputs of the map2loop code, or via the 3D models that can themselves be automatically built from these augmented outputs. Once the Configuration File has been generated, and the workflow control parameters defined in the map2loop Control Script, all further actions are fully automated, from accessing the input data, up to and including the construction of the 3D model using LoopStructural or GemPy.

In the example we present in these docs, we use the 2016 1:500 000 Interpreted Bedrock Geology map of Western Australia and the WAROX outcrop database (GSWA, 2016) as sources of the data needed to build a first-pass model of the region around the Rocklea Dome in the Hamersley Region of Western Australia. The area consists of upright refolded folds of Archean and Proterozoic stratigraphy overlying an Archean basement cut by over 50 NW-SE trending faults that form a part of the Nanjilgardy Fault System (Thorne and Trendall, 2001).

In the following subsections, the descriptions of the six sources of input data used by map2loop and map2model, are deliberately generic, as these two libraries uses a configuration file that allows the user to define which fields in the GIS layers or WFS servers contain which information. A Jupyter notebook (http://jupyter.org) helps the user to create this HJSON format configuration file from the input layers (Utility 1 - Config file generator.ipynb). The minimum input data required to run map2loop is described in the section Minimum input data requirements.

Minimum input data requirements

Vector Geospatial File Data Formats:

‘DXF’: ‘raw’, ‘CSV’: ‘raw’, ‘OpenFileGDB’: ‘r’, ‘ESRIJSON’: ‘r’, ‘ESRI Shapefile’: ‘raw’, ‘GeoJSON’: ‘rw’, ‘GeoJSONSeq’: ‘rw’, ‘GPKG’: ‘rw’, ‘GML’: ‘raw’, ‘MapInfo File’: ‘raw’

r=read, a=append, w=write

• geology polygons with stratigraphic code and rock type info (required)

• fault polylines (required)

• bed dips as points in dip, dip direction (required)

• mineral deposit layer (required, but can use defualt empty layer)

• fold axial trace layer (optional)

Geology Polygons (or Multipolygons):

• no gaps or overlaps between polygons, nodes from neighbouring polygons coincide (we have code to fix errors when the mismatch is smaller than the minimum node spacing).

• Stratigraphic Coherency: - Ideally the map should consist of polygons which all have the same stratigraphic heirarchical level, e.g. all formations, all groups, all members etc. This is often not the case, and it makes unravelling the stratigraphy more complex, as the parent and child may appear in the same map, so the age sorting needed to build the model becomes ambiguous. National or state-level stratigraphies, and even stratigraphies described on map sheet legends are by definition simplifications of the the local system extracted by map2loop. map2loop uses the local stratigraphy first and then uses the regional stratigraphy (if available) as a guide to reduce the uncertainty.

  Attributes with (data type) and {code} (see section Configuring map2loop parameters):

  • Fine Scale Stratigraphic coding, e.g. formation name (str) {‘c’}

  • Coarser Scale stratigraphic coding, such as its parent, e.g. group (str) {‘g’}

  • Alternate Coarser Scale stratigraphic coding, e.g. group (str) {‘g2’}

  • Relative or absolute maximum age of Fine Scale Stratigraphic Code (float) {‘max’}

  • Relative or absolute minimum age of Fine Scale Stratigraphic Code (float) {‘min’}

  • Litho code to help determine if rock is intrusive (str) {‘ds’}

  • Litho Code to help detemrine if this is a sill-like body (str) {‘sill’}

  • Unique ID of polygon (str) {‘o’}

Fault Polylines:

• single polyline per fault (no multipolylines)

• nodes on faulted boundaries coincident with geology polygon nodes

  Attributes

  • Text that identifies polyline as a fault (str) {‘fault’}

  • Dip of fault (str or float) {‘fdip’}

  • Dip Direction of Fault (str or float) {‘fdipdir’}

Bedding Points:

• single points (no multipoints)

  Attributes

  • Dip (float) {‘d’}

  • Dip Direction or Strike (float) {‘dd’}

  • Code to show what convention is used: Strike RHR, or DD at the moment (str) {‘otype’}

  • Code to show what type of foliation: Bedding, S1 etc. (str) {‘sf’}

  • Code to say this unit is overturned (str) {‘bo’}

Mineral Deposits: (Optional, can use default data from Notebook 3)

• single points (no multipoints)

  Attributes

  • Site Code (str) {‘msc’}

  • Name of deposit (str) {‘msn’}

  • Type of feature: open pit, occurence, abandoned etc., (str) {‘mst’}

  • Code to show what main commodity: Fe, Iron, etc. (str) {‘mtc’}

  • Code to show what main commodity class: Industrial, Metal, etc. (str) {‘mcom’}

Fold Axial Trace Polylines: (Optional)

• single polyline per trace (no multipolylines)

  Attributes

  • Text that identifies polyline as a fold axial trace (str) {‘feature’}

  • Code that defines fold as syncline (str) {‘syn’}