NMBGMR Draft Geologic Data Model - v. 1.0.3
POINTS: Well Data

Overview

Well spots are easy to represent as points on a map. However, a large amount of data can be associated with each well. Most of this data is best suited to input, query, and display via some kind of form. Data entry might need to occur before the precise location of a well has been established or conversely, the location of a well may be known before other attributes are avaliable. To that end, we have developed a well schema that allows for population of well attributes without an associated well spot. These attributes are related to each well using two GUIDs and 1:1 relationships: A 'WellPtGUID' is generated by the Well_point feature class and is the basis of a 1:1 relationship with a Well_Header table that stores basic identification attributes for wells. The Well_Header table generates a 'WellDataID' (GUID) that is used as the basis of 1:M relationships between the 'Well_Header' table and all other associated data. Using two GUIDs this way allows for dissconnected editing of both well spots and tabular attributes when that is appropriate, but also allows well attributes to be shown once the 1:1 relationship between the well spot and the header table has been established.

One aspect of well data that is difficult to manage is that there may be multiple datasets related to the same parameter. Sometimes, as with lithologic picks based on the interpretations of individual geologists, data from different sources can be contradictory. Because of this and because data can come from a variety of sources, we chose to store data as 'record sets'. Each recordset generates a unique GUID (RecordsetID) that relates associated data. Likewise, sample sets within a record set also generate a unique GUID (SamplSetID) so that multiple sample datasets from the same source (a record set), can be stored.

Our approach has resulted in less duplication of effort for our staff who handle a wide variety of well-related data collected from the same wells (e.g. geothermal data collected from petroleum exploration wells). Using a personal geodatabase to store our well data has allowed for the creation of Access data entry and querying forms that make using and entering data much easier than it is in a purely GIS environment. The only significant problem so far that we have encountered so far is that ArcServer doesn't work with 1:M relationship classes, which we rely on extensively.

It would be possible to use just the well-related part of our datamodel for those who already have a schema that suits their needs for other geologic data. The only portions of our larger geodatabase schema that are required by the Wells feature dataset are the 'Lithology' and 'Sources' tables and the coded value domains associated with any of the tables used.

Feature Class: Well_point

This 3-D point feature class represents wells of all types. The elevation of the point will be the elevation of the depth datum. Well Header information is related via the WellPtGUID field. Additional data about wells, in tables below, should be in a linked external table via the WellDataID field generated by the Well_header to Well_Records using the RecordSetID. The position of the well bore in 3-D can be stored in the Well_bore feature class and can be made from points in the Well XYZ feature class.

FeatureClass: Well_BoreLine

This m and z-enabled line feature class stores a representation in 3-D of the well bore. It can either be constructed from Well_XYZ downhole survey data, by connecting top and bottom well locations (if known), or by assuming a vertical bore and projecting the bottom hole position from the total depth. M-enabing well bore features allows determination of 3-D position from depth using routing funtions in the GIS. The zero depth position in 3-D will be the Depth Datum position for the well.

Topology

• A Well_Bore line should cover a Well_point.

Table: Well_Header

This table stores header data common to most wells. The Header table should be joined 1:1 with the Well_point feature class via the WellPtGUID. This table generates a WellDataID that is the top-level identifier for all well data. Using this identifier allows well data to be entered with or without the existence of a Well_point.

Table: Well_Location

This table stores coordinates of well locations. Downhole XYZ data should be stored in the Well_XYZ feature class which would include the locations stored in this table at zero depth. The location data in this table should be used to create well features in the Well_point feature class. This table can then be joined to the Well_point feature class via the Well_Records intermediate table to provide tabular output of coordinates for export to other applications.

Table: Well_Records

This is a lookup table for relating WellDataIDs generated by the Well_Header table to recordset identifiers created by this table for particular wells. This is accomplished via a composite 1:many relationship (or join) between Well_Header and Well_Records as well as composite relationships between the Well_Records table and other tables within a given recordset.

Table: Well_Bore

This table contains parameters regarding drilling bits, fluids used during drilling, and the resulting bore of wells. Data in this table are part of a recordset.

Table: Well_Casing

This table contains parameters regarding the casing of wells. Data in this table are part of a recordset.

Table: Well_XYZ

This table stores 3-D downhole survey coordinates. For wells with only top and bottom locations in three dimensions, there will only be two records. This feature class can be used to create a 3-D polyline of the well bore. The XY datum and Z datum are stored as part of the same recordset.

Table: Well_XY_Datum

This table stores datum recordset information for the XY coordinate system and attributes regarding accuracy. Currently only applicable to the Well_XYZ down-hole coordinate data. The Well_Location table has it's own datum attributes.

Table: Well_Z_Datum

This table stores datum recordset information for the Z coordinate system, depth coordinate system, and attributes regarding accuracy. It applies to all records in a recordset that specify depth. If multiple depth datums are used in a primary data source, that data must be split into multiple recordsets.

Table: Well_LthStrat

This non-spatial table stores lithology picks. Each separate source of pick data is represented by a unique recordset. Duplicate picks from different sources are to be expected, but must be evaluated to determine the best pick and if a given pick should be excluded.

Surfaces of stratigraphic tops can be constructed from 3-D points via this method:

1. Populate the GeoID field with a code for each stratigraphic unit of interest (i.e. 'Je' for Entrada).
2. Join Well_LthStrat to Well_Z_Datum using RecrdSetID and subtract the Depth2top from DatumElev to get the Elev_Top (for vertical wells).
3. Save edits, stop editing, and remove the join between Well_LthStrat and Well_Z_Datum.
4. Join Well_LthStrat to Well_Records (use the 'join based on relationship class' option).
5. Create a definition query for Well_LthStrat to restrict the data to a particular formation without 'excluded' values (e.g. [GeoID] = 'Je' and [Exclude] = 0). Export the results to a new table in the geodatabase (e.g. 'Je_picks'). Note that dbase tables will not work because they do not support GUIDs. Repeat for all units of interest.
6. Join Well_points to the picks table(s) from step 4 -- choose to only keep matching results of the join (this is an 'inner join').
7. Export the matching Well_points as tops points for each formation (e.g. Je_tops) to a new projected feature dataset (use Lambert conformal conic) with a defined vertical cooordinate system.
8. Optional: Use the 3D analyst toolbar to convert these points into 3D point feature classes.
9. Visualize the formation-top surface by adding the points to a terrain dataset (or create a dem). Terrains can be only be created in ArcCatalog within projected feature datasets. Either add 3D points from previous step or use the pick elevation field to define the z coordinates for the terrain.
10. Flag any changes or fixes to be made using the 'CheckPick' boolean and/or comments, exclude the problem picks.
11. You can join the 'Tops' points to original datasets to facilitate revisions.
12. If the problem picks are due to typos, fix them. For newly interpreted picks, create a new recordset to store your new picks and cite yourself as the source.
13. Reiterate until you are happy with the picks.

Table: Well_History

This table stores information regarding the history of wells. These data include owner, operator, driller, recompletions, changes in status, etc.

Table: Well_PetroDat

This non-spatial table stores petroleum-specific data. Each source of data represents a unique recordset.

Table: Well_LogData

This non-spatial table stores a record of what log data is available (Log Metadata). Each log represents a recordset. Digital logs would be stored in their native format.

Table: Well_LithLog

This non-spatial table stores lithologic log data for wells. Multiple lithology logs are separate recordsets.

Table: Well_Samples

This table stores metadata about physical samples, sample data sets, or measurements taken from particular well intervals. Each record specifies a depth or depth interval and records the presence/absence of particular sample type or analyses. For sample sets, this table can record the range of depths for the sample set or measurement set. Data at specific depth within the sample set depth range, like porosity or temperature, is then stored in related tables.

Table: WS_WaterTable

This non-spatial table stores water table data for a sample set. This table is not related to WS_Interval data because the data of interest is a depth.

Sample Data:

Completion Report Data

Issues:

• Check Boxes for Directional and Deviation Surveys at OCD? DwnHoleSur is already in Well_Header, what is the difference between directional and deviation surveys?
• Perforation data relationships to production data need to be looked at.
• All of the numeric depth fields should be able to use the Z_datum table for units and reference frame.