NOTE: These requirements were developed by State Geological Survey and USGS staff associated with the National Cooperative Geologic Mapping Program (NCGMP) and the National Geologic Map Database (NGMDB), to assist State, Federal, and University authors in preparation of deliverables and publications of various types of 3D information that conform, to the extent feasible, to the GeMS standard schema. Regarding submittal for repositing in the NGMDB’s Trusted Digital Repository, please refer to the document “Requirements for submitting GeMS-compliant map database” at https://ngmdb.usgs.gov/Info/standards/GeMS/, but recognize that only certain aspects of that document are applicable to 3D deliverables. If uncertain how to proceed, please contact ___.

# Contents

Introduction

- What is a “Model”?

Data Structure

- Required non-spatial tables

  - ElementTypeDict (required, default values)

  - DataSources (required)

  - MeasurementUnits (required, default values)

  - DescriptionOfModelElements (required)

- Tables Defining Spatial Data (minimum of one required, more as needed)

  - ModelElementValuePoints (as needed)

  - ModelElementValueLines (as needed)

  - ModelElementSurfaces (as needed)

  - Boreholes (as needed)

    - Vertical boreholes

    - Deviated boreholes (as needed)

- Additional optional tables

  - NoValueLines

- Cartoon example of data package

Appendix A. Default values of required tables

- ElementTypeDict

- MeasurementUnits

Appendix B. Content recommendations and expected questions

Additional narrative related to revisions and outstanding questions

-We have left some narrative comments to early community reviews throughout this document, identified in red in the word document, or “toggle-able”, italic sections on git. These comments draw attention to -outstanding questions or comments and catalog some revisions that were made based on earlier input.

-Summary of revisions to date:

- Early versions of this document combined two general purposes into one document; 1) current requirements for submitted 3D deliverable packages to the NGMDB, 2) early scoping of a potential standard (and implied set of validation requirements). Here we have split this into two components, this document represents the second part.

- Questions continually have come up that appear to revolve around the scope of this target data standard. Discussions span from the recovery of historic interpretations (e.g., contours), the storage of new interpretive models, measurement data relating to geologic properties (e.g., from well logs), and measurement observations used in modeling (e.g., well picks). Here we have attempted to narrow the focus based in part on analogy to GeMS and geologic maps – and in particular in comparison between GeMS (formerly NCGMP09) and GeoSCIML (formerly NADM). GeoSciML creates space for interpretive geologic maps and a wide variety of primary geologic observations; but it is quite complicated and abstract. GeMS is targeted at digitally mimicking the structural elements of a traditional geologic map product. We have attempted to add some clarity in a scoping section that this standard is intended to focus on capturing interpretive models, rather than trying to capture all component data.

- Early versions of this document focused on repurposing GeMS to be more accommodating of 3D data. This involved some creation of new tables and some reuse of existing tables. The general consensus was that this might be confusing for users and producers of data, and more complicated to maintain and validate. As a result this draft seeks to define a new data structure – one that shares a lot of design elements with GeMS, but is more targeted for 3D interpretive maps/models – and specifically and the use of that data. In many ways this has simplified the document and allowed us to trim some lengthy descriptions. Somewhat unlike GeMS, this schema is primarily focused on ensuring interoperability between datasets – documenting in the data itself what aspects of geology are being modelled (their descriptions, ages, names) and in particular how they are being measured (e.g., top elevation or thickness, feet or meters).

- A number of review comments requested more brevity in the first version of this document. We have attempted to make the content sections more concise, but left some lengthier narrative appendix content that was both bemoaned and appreciated.

- Review comments emphasized the value of starting with a simple structure of limited scope; to facilitate interoperability, promote early progress, make tool/ecosystem development easier, and evaluate what works and doesn’t.

- Early versions looked to bundle some continuous depictions of surfaces (e.g., rasters) within a GDB/GPKG. This was determined to be limiting in file types. A separate table is included that identifies these externally-stored files in a folder, and attributes them similarly to all other ‘data’ tables.

- Early versions of this document included scoping about formats for cross section data. GeMS also has space for cross sections, and associated tools for capturing cross section data in that format. For this reason we have excluded cross sections from this revision, as this document is attempting to focus on capturing content not effectively captured in GeMS.

- There was desire to have units explicitly documented in fields as in GeMS (LocationConfidenceMeters), thereby facilitating comparison of datasets. There was also concern about translating units from their native representation, potentially implying unrealistic precision (e.g., 5 ft intervals * 0.3048 m / ft = 1.524 m). Multiple unit fields were suggested, but also noted to be repetitive. Here we adopt the suggestion of providing a unit identifier potentially with a pick list/domain value. We expand this by forcing these identified units to be chosen from a ‘measurement units’ table (with some predefined values) that can provide explicit conversion between unit values and meters. Some data may best be expressed in km, ft, mi… furlongs… While a more complex structure this should guarantee that values are convertible between datasets with some simple joins, without requiring guessing at / varying field names. This table is pre-populated with common values.

- Borehole data remain somewhat divisive. There is a perspective that these are valuable data for modeling and that some folks have already promised borehole deliverables. There is the perspective that this is a potentially hugely complicated data structure, that often is associated with dedicated staff in large organizations. There is a suggestion that ‘picks’ could simply be included as points, though sometimes points would be overlaping. There is the perspective that other USGS groups (NIBI) are already indexing borehole information (though are not always providing geologic interpretations as analysis ready data). We have included here an extremely pared-down suggestion that allows contributors to store x,y,z lines and further narrows focus to just tabulating interpreted geologic ‘picks’ along those lines.

# Introduction

What follows is a working prototype for packaging subsurface data into a structure that mimics familiar and recognized conventions of the GeMS standard for geologic maps. Early reviewer comments were keen to draw distinction between data elements required for 3D geologic models and those used in describing geologic maps. For this reason we describe here a structure that can stand-alone from GeMS but should be quite familiar to those using and preparing geologic maps in that standard.

A note on naming …

For the time being, we refer to this as S3DS (pronounced; “seds” for “Subsurface 3D Schema”). Alternate names are enthusiastically welcomed,we just wanted a placeholder name to distinguish this content from GeMS.

The goal of this prototype standard is to organize the typical content of models of geologic horizons into a relational database structure and file package. These recommendations have an implicit scope and target type of content: the data structure described here is aiming to capture complete interpretive products and not raw data (i.e., the modelled base of unconsolidated Quaternary sediments, not the contents of mud logs). The hope is to encourage consistency in the packaging and delivery of files to ensure relevant content is interchangeable in the future, well documented, and can potentially be integrated across many contributions. We anticipate that significant challenges in this goal (beyond variability in geologic content) are related to a diversity of file formats, identification of what is being modelled, variation in measurement units, and variations in measurement dimensions, and have designed this prototype standard to explicitly document those properties.

## What is a “Model”?

Our intended definition of “model” is liberal, and is meant to relate to any interpretive geologic depiction derived from subsurface data.

In the narrowest definition, 3D geologic models are volumetric, space-filling representations of geo-objects (for example, strata, structures, and non-stratified geological bodies). This is a 3D analogue of a 2D map that fills the available space with geologic units and geologic objects (e.g. faults). Such 3D geologic models are typically built with software that use 3D topological data models and special interpolation methods.

In the broader sense that we adopt here, virtually all subsurface geo-object depictions are the result of modeling efforts that can involve geologic assumptions, reasoning, and constraints, as well as various computational algorithms. Relevant interpretive subsurface geologic data that could be broadly called “models” include (but aren’t limited too) structure contour and isopach maps, gridded surfaces interpolated from data, and constraining points even including “pseudo-well picks” that influence interpolations.

# Data Structure

The proposed data standard (Figure 1) can be split between a set of tables that define spatial data and a minimal set of non-spatial tables that define the geologic content being mapped and modeled (e.g., Figure 3). All non-spatial tables would be mandatory for a given dataset (though few may require users to enter data), but a submission may include one or more of the referenced spatial datatypes. We build upon the relational structure of GeMS by using relationships between non-spatial tables that provide definitions and descriptions of content referenced in spatial tables and by relying on plain-language, verbose field and table names. In some instances, we adapt GeMS tables almost verbatim.

The recommendations presented below strive to allow users of this data to understand and query data in a consistent way regardless of the specific data type; vector and raster (or TIN, etc) formatted representations of the geometry of a surface should have attributes that can be identified in a common way. These recommendations also seek to force producers of data to be explicit about what is being modelled and how measurements are stored. In the sections that follow we reference Tables as bold and Fields in italics.

As with GeMS, additional fields and tables are welcome if they are needed to communicate the science behind a particular study. The validation process will merely communicate a warning in these situations. However, please consider whether aspects of the existing structure can be utilized before seeking to add more nuance; conformity to the standard facilitates creating integrated and searchable systems which can help individual datasets be discovered.

Figure 1. Entity Relationship Diagram for the prototype “s3ds” standard. NOTE! This figure is out-of-date for the borehole tables in particular. There are now two types of borehole data captured in two seperate paired table structures; one for vertical and one for non-vertical wells. While the general structure is similar please don’t rely on this table for accurate documentation. See the discussion below and the files that define the tools themselves. We will work to update this figure as we converge on a structure.

## Required non-spatial tables

Described below are the four required non-spatial tables that define attributes of all data layers, ElementTypeDict, MeasurementUnits, DataSources, Glossary and DescriptionOfModelElements.

Additional details on changes in “non-spatial” tables…

Earlier versions attempted to drop the Glossary and free-text ‘type’ fields in data layers. Reviewers seemed keen on having a ‘type’ field to differentiate other types of data beyond what the existing fields can. A common example given was the diffrentiation of ‘pseudo-points’ used to drive model interpolations to reflect some geologic knowledge. It also seems possible that these could just be captured with datasources, but the ‘type’ solution seems familiar to creators and perhaps easier to parse for users. In this draft ‘type’ has replaced ‘symbol’ which was present in previous iterations. ‘type’ can still be used to symbolize content, but provides more flexibility than ‘symbol’ – which also wasn’t particularly useful across data types (e.g., can’t have a single ‘symbol’ for a raster dataset).

These five tables share a lot of commonalities with the required GeMS non-spatial tables. DescriptionOfModelElements is much like a slightly paired down DescriptionOfMapUnits. Glossary is identical, and DataSources nearly so. The ElementTypeDict is structurally similar to the GeoMaterialDict in GeMS, but defines the geometric nature of what is being modelled (as opposed to its composition).

The table that is least comparable to those in GeMS is the MeasurementUnits table, which allows users to enter measurements in whatever distance unit is deemed appropriate – but forces users to specify how to convert that to a common unit.

### ElementTypeDict (required, default values)

The ElementTypeDict is a required, standardized(?) non-spatial table that defines the geologic and geometric nature of what is being measured. Pre-populated values for this table are provided in Table 10.

Justification for single classification vocabulary for types of horizons

Inventories of 3D data and early versions of this standard made clear the need for identifiers that describe the geologic nature of what is being measured (e.g., faults, unconformities, geologic bodies), the geometric nature of the measurement (e.g., thickness, top, base), and the dimension of measure (e.g., elevation, depth, thickness). These three quantities can’t fully be separated into independent categories in all instances (e.g., a measure of thickness can’t be derived for an unconformity surface, and doesn’t apply to tops), so here we have attempted to combine things into one vocabulary. This also likely simplifies data entry, standard maintenance, and perhaps querying.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
elementtypedict_id | INTEGER | FALSE |  | auto-generated primary key
elementtype | TEXT | TRUE | UNIQUE | Short text name used to identify this model type
hierarchykey | TEXT | FALSE | UNIQUE | Numeric, dash-delimited code specifiying hierarchy (e.g., 01-01 is a subset of 01)
definition | TEXT | FALSE |  | Description of this model element type

Table 1. ElementTypeDict table definition

### MeasurementUnits (required, default values)

The MeasurementUnits table provides conversions between defined units of measure used throughout the database and meters. Pre-populated values for this table are provided in Table 11.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
measurementunits_id | INTEGER | FALSE |  | auto-generated primary key
unit | TEXT | FALSE | UNIQUE | Short text name used to identify this measurement unit
multiplier_to_meters | DOUBLE PRECISION | FALSE |  | Number that can be multiplied by values with this measurement unit to convert to meters

Table 3. MeasurementUnits table definition

### DataSources (required)

The DataSources table provides reference information for all records used throughout the database.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
datasources_id | INTEGER | FALSE |  | auto-generated primary key
source | TEXT | FALSE | UNIQUE | recommendation citation
url | TEXT | TRUE |  | url for accessing source over the web
methoddescription | TEXT | TRUE |  | description of how data source was generated
notes | TEXT | TRUE |  | misc. notes

Table 2. DataSources table definition

Changes to Datasources table from GeMS

We have made two minor changes from the GeMS standard here. (1) datasources_id is just an incrementing integer – this removes the desire to make meaningful or concatenated datasourceids and emphasizes the relational design (2) we have added a ‘method description’ to allow for some narrative description of how data/models were put together.

### Glossary (required, can be empty)

The glossary table defines free text terms used throughout the dataset. Each data record has an optional type field that can be used to provide additional context for that feature. Any type value used throughout the database must have a corresponding term entered in the glossary with a definition and reference. For example, a particular top might be recorded as a ‘pseudo-point’ because it was used to force a result that conformed with geologic understanding (but wasn’t an actual observation). Another example might be the inclusion of surface traces of a contact, which can be recorded as a line of zero depth – but further context might be appreciated. As discussed below, these type values are optional, and therefore the glossary may be empty if none are populated throughout the dataset.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
glossary_id | INTEGER | FALSE |  | auto-generated primary key
term | TEXT | FALSE | UNIQUE | Short text descriptor used throughout the database, particularly in ‘type’ fields
definition | TEXT | FALSE |  | Definition for the term
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The foreign key to the datasources table for this record.

### DescriptionOfModelElements (required)

The DescriptionOfModelElements table defines the geologic entities that are present throughout the database. This is comparable to a “DescriptionOfMapUnits” table in a geologic map, with the difference that not all geologic entities modelled or observed are expected to be “map units”. Datasets of 3D geology are likely to have reason for tabulating both bodies of earth materials (e.g., geologic units) and bounding surfaces (e.g., unconformities, faults).

What the heck is a ‘model element’?

Early comments on drafts of this schema made it clear that there was concern about the use of the term “MapUnit” to describe the entities that 3D models focused on. Alternates to the naming “ModelElements” are welcome. Model elements was a generic name that wasn’t specific to the subsurface or to a horizon (e.g., horizons), something with a name that wasn’t easily conflated with a related term (e.g., surface like “land surface”), and something that was flexible for both bodies of earth materials and the boundaries of those bodies.

In this version of the prototype standard we have attempted to design ‘ModelElements’ and ‘ElementTypes’ to work in concert to capture what we expect to be a common scenario; a single product producing multiple measurements of a geologic entity. For example the base and thickness of unconsolidated Quaternary sediments. In this way a single named and described entity (e.g., the Madison Limestone) can be associated with measurements of multiple types (e.g., locations of the top, base, different types of thickness).

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
descriptionofmodelelements_id | INTEGER | FALSE |  | auto-generated primary key
modelelement | TEXT | TRUE | UNIQUE | Shorthand text code (akin to ‘MapUnit’) that identifies a model element
name | TEXT | FALSE |  | Name of the model element
age | TEXT | FALSE |  | Age of the model element
description | TEXT | FALSE |  | Description of the model element
hierarchykey | TEXT | FALSE |  | Numeric, dash-delimited code specifying hierarchy (e.g., 01-01 is a subset of 01)
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The foreign key to the datasources table for this record.

Table 4. DescriptionOfModelElements table definition

## Tables Defining Spatial Data (minimum of one required, more as needed)

Tables defining spatial data are structured to all be identifiable and differentiable based on a core subset of attributes:

datasourceid: The corresponding reference in the DataSources table for this record.

modelelement: The geologic entity that a record is relevant for, as described in the DescriptionOfModelElements table.

elementtype: The type of model element that is described by a record, for example “vertical thickness’ or “top (as elevation)”. Defined by the ElementTypeDict table.

valueunits: The measurement units relevant for the value column (or, for example, raster values). Defined by the MeasurementUnits table.

type: An optional, text descriptor for a record. Values in the type field must be identified in the glossary table. Values in type may be useful for symbolizing spatial data, or providing additional context for otherwise comparable records – for example denoting values obtained in different ways. Though this could also be recorded through the datasourceid, there was community suggestions that this could be a useful addition.

Everywhere… except for boreholes
An exception to this rule is the proposed borehole strategy; describing where a pick along that line is likely wrapped up in the coordinate system of that line (see further points under that section). Therefore, value units* is not entirely appropriate on that table.*

In addition to the data schema definitions described below, all these tables are expected to use the same coordinate system for spatial data.

### ModelElementValuePoints (as needed)

ModelElementValuePoints is intended to capture any point observation of the position or thickness of a model element. This may be observations from water wells, picks from boreholes (where there isn’t a desire to capture the actual borehole track), observations of a location at land surface, or control points created by a user to limit or guide an interpolation routine.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
modelelementvaluepoints_id | INTEGER | FALSE |  | auto-generated primary key
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
modelelement | TEXT | FALSE | REFERENCES descriptionofmodelelements(modelelement) | The ModelElement referenced by this record
elementtype | TEXT | FALSE | REFERENCES elementtypedict(elementtype) | The ElementType that is applicable for this record
value | DOUBLE PRECISION | FALSE |  | The value represented by this line
valueconfidence | DOUBLE PRECISION | FALSE |  | The confidence (in measurement units) represented by this line. Expressed as a half-interval on the appropriate measure of uncertainty.
valueunits | TEXT | FALSE | REFERENCES measurementunits(unit) | The measurement units for this measurement.
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The foreign key to the datasources table for this record.
shape | GEOMETRY(POINT,<CRS>) | FALSE |  | The geometry column for this spatial data

Table 5. ModelElementValuePoints table definition

### ModelElementValueLines (as needed)

Lines of equal value (e.g., thickness, depth, or elevation) were the traditional means of communicating the geometry of geologic horizons and still have uses today. ModelElementValueLines is intended to capture any line of constant value describing the position or thickness of a model element. Often this will be a representation of the geometry of a geologic surface or the thickness of a geologic body, however other uses may be possible. For example, lines of zero depth could communicate the location of surface traces of contacts used in modelling a horizon.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
modelelementvalueslines_id | INTEGER | FALSE |  | auto-generated primary key
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
modelelement | TEXT | FALSE | REFERENCES descriptionofmodelelements(modelelement) | The ModelElement referenced by this record
elementtype | TEXT | FALSE | REFERENCES elementtypedict(elementtype) | The ElementType that is applicable for this record
value | DOUBLE PRECISION | FALSE |  | The value represented by this line
valueconfidence | DOUBLE PRECISION | FALSE |  | The confidence (in measurement units) represented by this line. Expressed as a half-interval on the appropriate measure of uncertainty.
valueunits | TEXT | FALSE | REFERENCES measurementunits(unit) | The measurement units for this measurements
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The foreign key to the datasources table for this record.
shape | GEOMETRY(LINESTRING,<CRS>) | FALSE |  | The geometry column for this spatial data

Table 6. ModelElementValueLines table definition

For data packages that contain contour lines describing multiple entries in the DescriptionOfModelElements table, all content should be stored in a single feature class. Individual surfaces/measurements can be identified through queries to the ModelElement field.

### ModelElementSurfaces (as needed)

Raster, TIN, and other continuous, non-vector datasets do not have readily accessible attribute tables in the same way that vector datasets do. The ModelElementSurfaces table is designed to match an external file (identified by a filename) to the same attribute suite as other vector data. The filename should be the name of the file stored in a specially named folder at the equivalent directory level (Figure 2), described in more detail below.

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
elementsurfaces_id | INTEGER | FALSE |  | auto-generated primary key
modelelement | TEXT | FALSE | REFERENCES descriptionofmodelelements(modelelement) | The ModelElement referenced by this record
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
elementtype | TEXT | FALSE | REFERENCES elementtypedict(elementtype) | The ElementType that is applicable for this record
valueunits | TEXT | FALSE | REFERENCES measurementunits(unit) | The measurement units used by this record
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The DataSource referenced by this record
filename | TEXT | FALSE |  | The file name within the ‘surfaces’ subdirectory that this record references.

Table 7. ModelElementSurfaces table definition

### Surfaces file folder (as needed)

The ModelElementSurfaces table does not contain spatial data, rather it just defines datasets contained in a file folder stored in the same location as the database. These folders are named based on the dataset name - “<dataset name>_surfaces” – this unique naming allows multiple datasets to be stored in the same directory location. For example, a dataset named “Dataset.gdb” would have a corresponding “Dataset_surfaces” folder, should it be needed. The filename field in the ModelElementSurfaces folder should reference the filename (with extension) stored in this folder. In the example in Figure 2 the ModelElementSurfaces table would have a single record with a filename of “dakota_thickness.tif”.

Figure 2. Example file and database structure

Background on ModelElementSurfaces and in vs. out of database rasters

ModelElementSurfaces is technically a non-spatial table, but it defines spatial data and is not required like the other non-spatial tables (so it is included in this second section). Perhaps rather than differentiating ‘spatial data’ and ‘non-spatial data’ we should reference ‘data’ and ‘attributes’, or something along those lines

Early discussions around raster and other continuous model surfaces considered whether to store data inside the database or not. A challenge with internal storage is that it drastically limits file formats; rasters are currently probably the only stable option across ESRI/open spatial database formats. Early conversations also focused on how to identify what these rasters (and other formats) actually represent – including naming conventions of files and of ‘names’ in the “Descriptions…” table - and how to validate that they were correctly referenced and packaged. The strategy adopted here has two goals: (1) allow flexibility in file formats to accommodate rasters and more complex, true-3D surfaces (e.g., TIN or other meshes) (2) explicitly store the nature of a surface in a searchable table in a comparable way to other data.

A point for discussion: ModelElementSurfaces could be made spatial by having it be a footprint of the referenced data. Is this helpful though? Perhaps it helps show a user where content exists; but the content could also just be loaded - and the extent could be a derived quantity.

### Boreholes (as needed)

Borehole data are often associated with dedicated relational database structures to relate various attributes along a well path. Often, particularly in deviated wells, the actual spatial path of the well is a derived property of related deviation survey. It is beyond the scope of this data standard to capture this complexity, here we instead take a much more restricted view focused on tracking the location of boreholes and the interpreted geologic horizon locations (e.g., “picks”) along those tracks. This is accomplished with two tables; one a spatial table that defines the borehole locations and a second non-spatial table that defines the position along those lines that certain model element values were “picked” at. Note that subsurface picks that are not explicitly associated with a surveyed borehole are best stored in ModelElementValuePoints. There is no requirement to use the borehole tables to capture observations from boreholes; some data creators may prefer to just store x,y points with a depth (or elevation) value in the ModelElementValuePoints for simplicity.

In this prototype we adopt two independent strategies for vertical and deviated boreholes. While this creates complications for the standard, it potentially greatly simplifies the tabulation of data from vertical boreholes. Whether both of these options are needed in the future, or a compromise can be reached that accomodates both, will depend on community feedback. Both of these datatypes could also just be accomodated in the ModelElementValuePoints feature class; though with some redundant locations in the case of vertical wells.

Complications introduced by deviated wells…. should we have two borehole types?

Original suggestions where to simply accomodate boreholes as points, but early feedback requested a structure for boreholes - which in turn led to a desire to accommodate deviated boreholes. The simple suggestion for deviated boreholes (defined here as anything that can’t be assumed to be vertical at the scale of a dataset), was to request that data preparers produce the actual spatial track of the borehole as an x,y,z line extending into the earth. A related table can then describe the locations of picks as distances along that line; from which users could identify x,y,z values for further use. This requires a different data structure then then all other …value tables, because the units must be defined in the same units as the CRS of the line to make this calculation, and its not possible to provide values in elevation or depth because these could result in non-unique locations along the well (for example in horizontal wells).

While this x,y,z deviated borehole line suggestion works well enough, and in theory is extensible to vertical wells, it is much more complicated to populate and to use than what is necessary for a vertical well. In the case of vertical wells we can again use the standard valueunits, elementtype, etc fields associated with all other value tables. These data can also be populated in a straightforward way from existing tables recording, for example multiple intercept depths at a given well (as opposed to requiring potential translations between along-well coordinates). Furthermore, these vertical (or near-vertical) well datasets appear to be quite commonly used by many geologic surveys, and are ubiquitous in historical data.

In this current version we opt to include both these solutions, partly to survey who is interested in using what. Perhaps there is not that much appetite for deviated wells after all, and the strategy could be scrapped (the data then just captured in ModelElementValuePoints as needed). However we welcome feedback on this.

#### Vertical boreholes

For boreholes that are vertical, or effectively vertical at the scale of the map, we capture the location in a VerticalBoreholePoints table and the observation associated with that well in a VerticalBoreholePicks table. The VerticalBoreholePicks table shares a structure with other ModelElementValue… tables, however instead of a geometry column it has a foreignkey verticalboreholepointsid field that is reference to the primary key defined by the VerticalBoreholePoints table.

##### VerticalBoreholePoints

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
verticalboreholepoints_id | INTEGER | FALSE |  | auto-generated primary key
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
borehole_identifier | TEXT | TRUE |  | unique identifier for borehole
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The DataSource referenced by this record
shape | GEOMETRY(POINT,) | FALSE |  | The point identifying the borehole location

Table 8. VerticalBoreholePoints table definition

##### VerticalBoreholePicks

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
verticalboreholetrackpicks_id | INTEGER | FALSE |  | auto-generated primary key
verticalboreholepointsid | INTEGER | FALSE | REFERENCES verticalboreholepoints(verticalboreholepoints_id) | Identifier to the vertical borehole point table this pick references
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
modelelement | TEXT | FALSE | REFERENCES descriptionofmodelelements(modelelement) | The ModelElement referenced by this record
elementtype | TEXT | FALSE | REFERENCES elementtypedict(elementtype) | The ElementType that is applicable for this record
value | DOUBLE PRECISION | FALSE |  | The value represented by this line
valueconfidence | DOUBLE PRECISION | FALSE |  | The confidence (in measurement units) represented by this line. Expressed as a half-interval on the appropriate measure of uncertainty.
valueunits | TEXT | FALSE | REFERENCES measurementunits(unit) | The measurement units for this measurements
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The foreign key to the datasources table for this record.

Table 9. VerticalBoreholePicks table definition

Naming of vertical boreholes

The deviated borehole tables were originally named differently from all other ‘model element value’ classes because their structure was so different. This new naming just attempts to differentiate vertical and non-vertical boreholes, while also indicating that they are comparable in some ways. Perhaps there is some different naming that could bring all these tables into greater semantic consistency to emphasize their similarity.

#### Deviated boreholes

For boreholes where it is important to record some deviation from the surface intercept, we capture the location in a DeviatedBoreholeTracks table and the observation associated with that well in a DeviatedBoreholePicks table. The DeviatedBoreholeTracks table captures x,y,z lines extending into the earth that depict the path of a particular borehole (e.g., as calculated from a deviation survey). The DeviatedBoreholePicks table captures the location of modelelement intercepts along that track. This simple structure is intended to capture the basics of deviated boreholes in a mostly GIS environment, but it necessitates a slightly different data structure from all other ModelElement.. value tables. This is because we are not fundamentally measuring some aspect of the geology in some broader global reference frame (e.g., elevation, depth, thickness), but instead along the reference frame of the line defining the borehole.

##### DeviatedBoreholeTracks

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
deviatedboreholetracks_id | INTEGER | FALSE |  | auto-generated primary key
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
borehole_identifier | TEXT | TRUE |  | unique identifier for borehole
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The DataSource referenced by this record
shape |  | FALSE |  | geometry column (x,y,z line)

Table 10. DeviatedBoreholeTracks table definition

##### DeviatedBoreholePicks

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
vertivalboreholepicks_id | INTEGER | FALSE |  | auto-generated primary key
deviatedboreholetracksid | INTEGER | FALSE | REFERENCES deviatedboreholetracks(deviatedboreholetracks_id) | Identifier to the deviated borehole table this pick references
type | TEXT | TRUE | REFERENCES glossary(term) | An additional descriptive term that can optionally be added to this record. May also be useful for symbolization. Defined in the glossary table.
downhole_distance | DOUBLE PRECISION | FALSE |  | The distance down the referenced borehole line that this observation occurs
modelelement | TEXT | FALSE | REFERENCES descriptionofmodelelements(modelelement) | The ModelElement referenced by this record
elementtype | TEXT | FALSE | REFERENCES elementtypedict(elementtype) | The ElementType referenced by this record
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The DataSource referenced by this record

Table 11. DeviatedBoreholePicks table definition

Further questions surrounding boreholes

We include a borehole identification number field, though its unclear how this should be populated. It seems important to include to be able to compare this data to more exhaustive records, but without adding a lot more other tables how do we know what borehole identifier is used? Perhaps just some soft recommendations about how to format this? In the example in figure 3 I just prefix the identifier with a text shorthand for the identifier type “uid:XXXXXXX…”. Perhaps a few recommendations for those shorthand codes?

As mentioned in comments above, ‘elementtype’ ends up being strange in deviated boreholes… in the proposed data model its not really possible to have a thickness; as that wouldn’t be a measured distance along the track. Similarly keen-eyed folks will notice that there is no ‘units’ value; because the units are assumed to be the same as the coordinate system units in order for the downhole_distance measure to be relevant.

A challenge inherit in this deviated borehole strategy is that the simplest way to validate / display / query / use the location of points along lines is by actually plotting the pick locations. This would be done by finding the coordinate that corresponds to some distance along the line stored in the BoreholeTrackPicks table. This is greatly aided if the along-line distance is measured in the same measurement units as the x,y,z coordinates along the line (e.g., meters along the borehole and UTM meters). This also likely works best if x,y,z lines are recorded in a consistent orientation (e.g., from the surface down). These things are just a bit messier to validate for than the typical relational integrity things.

## Additional optional tables

### NoValueLines

Portrayals of the geometry of geologic surfaces often contain information about the location of folds, fold axis, interpolation boundaries, or other linear annotations of geologic significance. The novaluelines table is intended to capture these features. This feature class is defined with a lot of flexibility for exactly what needs to be populated, but at a minimum records need a type value and a datasourceid. Optionally, it is recommended to denote the modelelement that corresponds to features like faults and fold axes.

Justification for NoValueLines

Some reviewers had noted the value of capturing faults associated with different geologic datums (and in the course of outreach on other national datasets this has come to be frequently requested). This had been a relatively minor point during discussion though, and so didn’t capture as much discussion as other points focused on the data of modelled surfaces.

In the course of inventorying available datasets for assessing this format a few statewide datasets turned up. Many included some type of line data that was not contours. These primarily included faults, folds, map boundaries. In some publications many faults or folds were present that corresponded to different modelled geologic horizons. In others features wheren’t related to any geologic datum (e.g., boundaries).

We therefore decided to only require a ‘type’ value (and datasourceid) in this table, allowing for an optional description of which model element is impacted, and optionally which aspect of that (e.g., top, base).

Field | Data type | Is nullable? | Constraints | Definition
--- | --- | --- | --- | ---
novalueslines_id | INTEGER | FALSE |  | auto-generated primary key
type | TEXT | FALSE | REFERENCES glossary(term) | A descriptive term for this record. May also be useful for symbolization. Defined in the glossary table.
modelelement | TEXT | TRUE | REFERENCES descriptionofmodelelements(modelelement) | The ModelElement referenced by this record
elementtype | TEXT | TRUE | REFERENCES elementtypedict(elementtype) | The ElementType that is applicable for this record
datasourceid | INTEGER | FALSE | REFERENCES datasources(datasources_id) | The foreign key to the datasources table for this record.
shape | GEOMETRY(LINESTRING,<CRS>) | FALSE |  | The geometry column for this spatial data

Table 12. NoValueLines table definition

## Cartoon example of data package

Figure 3. Cartoon of geologic block model showing populated tables identifying some observations and model results. Not included in this image are the “type” fields and values that can optionally populate the spatial data tables, depicted in green, or the corresponding glossary. NOTE! This figure is out-of-date for the borehole tables in particular, though it still depicts the general strategy (a location table and a ‘picks’ table). There are now two types of borehole data captured in two seperate paired table structures; one for vertical and one for non-vertical wells. While the general structure is similar please don’t rely on this table for accurate documentation. See the discussion below and the files that define the tools themselves. We will work to update this figure as we converge on a structure.

# Appendix A. Default values of required tables

Questions about controlled values

Should these be strictly controlled vocabularies or allowed to grow as needed? Certainly seems that early on it would be good to allow them to grow to accommodate cases we didn’t think of. At the same time including some default values will likely help explain what these tables are (and may be all most users need). The problem with flexibility in new elementtypes in the long run is that non-standard values will limit the ability to query between / compare datasets in a procedural way.

Once we agree that these tables are a good idea, we can hash out if/how to update/edit tables accordingly.

### ElementTypeDict

Values of ElementType will be pre-populated as shown below. These values were populated with a hierarchy that groups like measurement types; however some values in the hierarchy have null ‘elementtype’ so that they can not be used as a value. For example, ‘top’ could be defined in (at minimum) two ways – so the generic value ‘top’ is not an option.

elementtypedict_id | elementtype | hierarchykey | definition
--- | --- | --- | ---
1 |  | 01 | Measurements of geologic bodies.
2 |  | 01.01 | Top: the uppermost bounding surface of a geologic entity
3 | top (as elevation) | 01.01.01 | The top of a geologic entity measured as elevation above sea level.
4 | top (as depth) | 01.01.02 | The top of a geologic entity measured as distance below land surface.
5 |  | 01.02 | Base: the lowermost bounding surface of a geologic entity
6 | base (as elevation) | 01.02.01 | The base of a geologic entity measured as the elevation above sea level.
7 | base (as depth) | 01.02.02 | The base of a geologic entity measured as the distance below land surface.
8 |  | 01.03 | Thickness of geologic bodies
9 | stratigraphic thickness | 01.03. 01 | The current thickness measured in the direction of dip (aka isopach)
10 | depositional thickness | 01.03.02 | The thickness at the time of deposition
11 | vertical thickness | 01.03.03 | The thickness measured vertically (aka isochore)
12 |  | 02 | Geologic surfaces of zero volume.
13 |  | 02.01 | Fault: a fracture or zone of fractures along which there has been displacement.
14 | fault (as elevation) | 02.01.01 | Fault as measured as elevation above sea level.
15 | fault (as depth) | 02.01.02 | Fault as measured as distance below land surface.
16 |  | 02.02 | Unconformity: A surface of erosion or non-deposition that separates younger strata from older rocks.
17 | unconformity (as elevation) | 02.02.01 | Unconformity as measured as elevation above sea level.
18 | unconformity (as depth) | 02.02.02 | Unconformity as measured as distance below land surface.

```Table 13. Default values of ElementTypeDict table

### MeasurementUnits

While new values can be added, the following values of MeasurementUnits will be pre-populated as shown below.

measurementunits_id | unit | multiplier_to_meters
--- | --- | ---
1 | meters | 1
2 | feet | 0.3048
3 | kilometers | 1000
4 | miles | 1609.34
5 | yards | 0.9144
6 | furlongs | 201.168
7 | inches | 0.0254

```Table 14. Prepopulated values of MeasurementUnits table

# Appendix B. Content recommendations and expected questions

In the section that follows we address some expected questions. These questions and responses are intended to provide data preparers with guidance that extends beyond the structure of the submitted data into how content is populated. The intent with these recommendations is not to suggest anything isn’t allowed, but to encourage practices that will make data produced by different authors readily usable in a consistent way.

#### What coordinate systems and datum should be used?

Please use a consistent coordinate reference system and one with an EPSG-defined authority (https://epsg.io/) so that your data can easily be interacted with/reprojected in various GIS systems. In other words, please avoid custom or ESRI-defined coordinate systems.

There is value for many basic operations on surfaces in having horizontal and vertical units defined in the same dimensions. For example, computing the slope of a raster surface or measuring the (3D) distance between two points. These operations are simpler when the coordinate system uses the same dimensions as the values used to measure elevation/depth (i.e., meters).

Importantly, the strategy described in the BoreholeTracks and BoreholeTrackPicks tables also relies on the down-hole distances described in BoreholeTrackPicks being in the same units that are used to store the coordinates of the BoreholeTrack for this reason, it is also important to define projected coordinate systems that use a reference unit (e.g., feet or meters) that matches that used to identify the downhole_distance value of the BoreholeTrackPicks table.

#### What content should the spatial data include?

In general this prototype standard is geared towards interpretive information, even in things like point and borehole data. However, there is utility to both raw, uninterpreted observations and interpolated surfaces. We leave it to the authors to determine which content to include in a package to best represent the geometry of horizons studied. It may be useful for future users of your dataset to have access to the raw point data from wells you used to interpolate a surface, but there may be data privacy concerns. To the extent its helpful, consider the analogy of what you would include in a geologic map – the map is still useful without a record of every site you visited in the field.

#### What format should I use to represent continuous surfaces?

Both rasters and contour lines can describe continuous surfaces, as can TINs or other meshes. We again defer to authors on which is most appropriate, however we encourage authors to consider what content is lost (or invented) by transforming data from its native representation. If you produced a gridded surface of the top of a horizon, some information is lost by simplifying this to contours. If you digitized an old contour dataset, new content is created when converting that dataset into a raster representation.

#### What level of precision should I use for my subsurface data?

Users are cautioned that making even simple calculations within attribute fields that use double precision create values with unrealistic levels of precision, for example a feet-to-meters conversion might produce a depth value that is reported with four significant figures. Users are cautioned to consider the likely magnitude of vertical uncertainty in their subsurface data that might arise from all possible sources of error and format their data accordingly.

#### How should I decide on the basic attributes of raster datasets?

There are a handful of special considerations with raster data:

Coordinate systems. See the discussion above, but there are many applications / analyses where it is helpful to have the value field dimensions of the raster (e.g., elevation or depth) match the dimensions of the XY coordinate system. Similarly, it is much more intuitive and informative to read the cell size of a raster in meters than in degrees (e.g., 10 m cells vs. 1/3 arc-second cells). Projected coordinate systems that use meters accomplish this.

No data values. Take care to validate no-data-values when translating raster data between formats. Floating point conversion errors and data format conversions can sometimes drop information about no-data-values or round / interpolate no-data-values. These can influence which areas are classified as no-data and/or introduce irrelevant data into a raster. Remember that rasters are stored as rectangles; a raster that appears as an irregular shape is just a rectangle padded with no-data values – so it will be a similar file size as a version without an irregular, cropped shape.

Cell size. Much like map scale is a useful control on data density and generalization in a geologic map, cell size of a raster dataset should be carefully considered based on the purpose of the map. For every halving of the cell size, the size of a raster file will increase by a factor of four (or a little less with compression). We encourage authors to find a reasonable cell size for the scope of the product of interest and the level of data density; undersampling can miss important structures while oversampling creates a burdensome dataset without accompanying detail. We highlight three heuristics that may help authors evaluate this:

1. When generating rasters largely through interpolating data, compare the number of pixels in the resultant product to the number of control points. More control points than pixels may imply there could have been more interpretation, vastly more pixels than control points could imply that the data is over-interpreted. You may need to adjust this if your data density is very heterogeneous across the study area.

2. Compare the cell size to the smallest geologic feature you think your data can reveal. If your model is not able to highlight buried channels ~20-30 m across there is likely little need for a 10 m or better raster. In particular, avoid letting the availability of high-resolution DEMs guide your cell size if you are primarily modeling something beneath the surface. Instead, let the data density of subsurface geology inform those decisions.

3. What is the “scale” of the product? Is this something that you would print at 1:500,000? If so, a 500 m pixel would be 1 mm across (a typical monitor resolution might be ~4-8 pixels per mm).

When using projected coordinate systems (e.g., cell sizes in units of meters) consider rounding your cell sizes to whole numbers for simplicity (e.g., 10 m instead of 9.8 m)

#### What depiction of surface elevation should I include? Depth? Elevation?

We defer to authors to generate surfaces they expect to be most useful to their community. However, we do encourage care when attempting to convert between depth and elevation and suggest avoiding it as a post-processing step. Take the case of a deep, relatively undeformed horizon. The authors assemble the relatively sparse well-data that penetrated to this deep horizon, and then interpolate the depths to this horizon across the state – resulting in a smooth depiction of the depth of some broad geologic structure. The authors then decide it would be more useful to convert this to an absolute elevation surface, so simply subtract the depths from a statewide digital elevation model that contains a lot of detailed topography. The result is an elevation map that includes a lot of high-frequency content (e.g., valleys, ridges) that are not necessarily features in the deep geologic surface, but that the original depth map didn’t capture so were imposed onto the resulting elevation map from the topographic data.

#### What content should I describe in a DataSources or DescriptionOfModelElements table vs. metadata?

We have expanded the traditional GeMS DataSources table with a methoddescription field for providing short descriptions about process for generating data (as distinct from, for example, citation information). While an accompanying report and/or metadata give more space and structure for describing how a dataset was created, it may be helpful for users if you also include in the DataSources table a short description of how a surface was modelled or otherwise interpreted. This has the advantage of always being packaged with the model itself, and being easily consulted while the data is being used. The Description field in the DescriptionOfModelElements table should primarily focus on the geologic entity being modelled.