NMWells Data Model - v. 1.0.6
Well Feature Classes & Attribute Tables

Overview

Note: This schema for well data is separate from the much simpler NMBGMR Geologic Data Model Well_point feature class. This schema could be used in conjunction with the Geologic Data Model or it could stand entirely alone for storing well data separate from a geologic map. You can download this XML geodatabase well schema as a zipped archive.

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 available. 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 'WellSpotID' is generated by the Well_Spots 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 disconnected 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 independently.

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 data model 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.

Change Log

1.0.4

• Split Well Data Model from Geologic Data Model

1.0.5

• Added Well_DST data

1.0.6

• Revised webpages for Geologic and Well Data model pages to show split schemas
• Added Well_Drillers table and associated relationship class
• Added "WorkType" CVD
• Added Range Domains: Month, Day, and Year
• Added field "PrdPoolCnt" (ProducingPoolCount) to Well_Header table
• Added field "PerfType" (PerforationType) and associated CVD to Well_PerfIntrv table
• Added field "DepthType" and associated CVD to Well_Casing table
• Added values "DHC" and "New" to WellStatus CVD

Feature Class: Well_Spots

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 WellSpotID 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 endpoint should cover a Well_Spot (the well spot elevation should be the elevation of the depth datum).

Table: Well_Header

This table stores header data common to most wells. The Header table should be joined 1:1 with the Well_Spots feature class via the WellSpotID. 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_Spots.

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_Spots feature class. This table can then be joined to the Well_Spots 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_Spotss 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_Spotss 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.

Table: WS_GeoChron

This table is used to provide more information for age dates of geologic materials referenced in various other feature classes. If need be, these dates could be linked to a more comprehensive geochronology data model that contains analytical data and discussion.

Table: WS_DSTheader

This table stores header data for Drill Stem Test observations. A drill stem test (DST) is a procedure for isolating and testing fluid composition, presssure, permeability, temperature and other properties of the geological formation around a borehole through the drill pipe. The basic drill stem test tool consists of a packer or packers, valves or ports that may be opened and closed from the surface, and two or more pressure-recording devices. (A packer is an expanding plug which can be used to seal off sections of the open or cased well, to isolate them for testing.) The tool is lowered on the drill pipe to the zone to be tested. The packer or packers are set to isolate the zone from the drilling fluid column, and testing measurement begins. The most common test sequence consists of a short flow period, perhaps five or ten minutes, followed by a buildup period of about an hour that is used to determine initial reservoir pressure. This is followed by a flow period of 4 to 24 hours to establish stable flow to the surface, if possible, and followed by the final shut-in or buildup test that is used to determine permeability thickness and flow potential. Flow history for DST tests is stored in the WS_DSTflowHist table (1:M relationship via DSTGUID). Information about the bore and casing are stored in other tables.

Table: WS_DSTintervl

This table stores Drill Stem Test observations. Each WS_DSTdata record represents measurements taken for a specific sample interval, identified by an DSTInterval GUID. Pressure measurements for each interval are stored in the WS_DSTpressure table in a 1:M relationship with WS_DSTdata.

Table: WS_DSTpressur

This table records pressure measurements and associated properties measured during DST tests and is related to the WS_DST_Header table via the FK: DSTGUID. There typically are two pressure transducers, one between the packers (BlankedOff) and one above the packers. However, there may be pressure readings from other transducers as well.

Table: WS_DSTflowHst

This table summarizes flow history for DST tests and is related to the WS_DST_Header table via the FK: DSTGUID.

Table: WS_DSTfldProp

This table summarizes fluid properties measured during DST tests and is related to the WS_DST_Header table via the FK: DSTGUID.

Well Intervals and Sample Data:

Completion Report Data

The New Mexico Oil Conservation Division (OCD) requires completion reports (C105 forms) for petroleum wells drilled in the state. The following tables record information provided by these reports. Some of the data on the C105 reports is stored in tables above as part of a RecordSet.