Get the data

Heads up on Original: the Commission does not publish this table on its own. It publishes Well Layers by County, which this was parsed out of — so Original gets you that whole file, not just this table. Every other format is this table alone.

Free. You will be asked to confirm an email address before the files are built — that is the only gate, and it is there so we can tell you when a large export is ready.

Preview the first 100 rows

What this is

The other end of the well: 1,396,053 mapped bottom holes, again with a NAD83 and a NAD27 coordinate and the API number. A well with more than one bottom -- a sidetrack, a re-entry, a multilateral -- has a row here for each, all pointing back at one surface hole.

For a vertical well the bottom is under the surface point and this adds little. For a horizontal it is the useful end: it is where the lateral actually is, which is what decides whose minerals are being drained and which section the production belongs to.

What you can do with it

Measure laterals, find every well whose bottom is under a given tract, or map production to where it comes from rather than to the pad it was drilled from.

Gotchas

api10 is NOT a zero-padded API. It is the eight-digit API with the sidetrack code appended -- '00132873H1' is API 00132873, sidetrack H1 -- so it is 8 characters on a well with no sidetrack and 10 on one that has. Join on `api` unless you specifically want to distinguish sidetracks.

1,395,998 of the 1,396,053 rows find their surface hole; 55 do not, which is RRC's own data and not a join problem.

1,021,109 find a row in the API-to-lease sheet, for the same reason as the surface set: a mapped point is not always a currently leased well.

Record layout

18 columns.

gis_well_bottom 18 columns

Record layout for gis_well_bottom — 18 columns
# Column Type RRC name Meaning Lookup
1 county_code text The three-digit county code, taken from the name of the package this row came out of -- well001s.dbf is county 001. 'FED' for the federal offshore bundle, which is a real part of the statewide layer: merging only the numeric counties silently drops every well in federal waters and still looks like a complete Texas layer.
2 bottom_id bigint RRC's integer key for this bottom hole. texas.gis_well_path points at it, and it is what distinguishes the several bottoms of a sidetracked or multilateral well from one another.
3 surface_id bigint The surface hole this bottom belongs to, joining back to texas.gis_well_surface. A well with one bottom has one row on each side; a sidetrack, a re-entry or a multilateral has several bottoms against one surface. 1,395,998 of 1,396,053 resolve.
4 symnum integer The symbol number RRC's map system draws this point with. It encodes well type and status and its meanings are in the digital map user's guide rather than in the file; reported as published.
5 apinum text The API number with the state prefix, twelve characters wide and holding ten -- '4200132761'. Texas is state 42. This is the full ten-digit API; `api` beside it is the same number without the prefix, and is the one to join on.
6 reliab text RRC's positional-reliability code for the bottom hole. See the surface table's note: the code list is not published, so the values are reported as they come.
7 api10 text NOT a zero-padded API. It is the eight-digit API with the SIDETRACK code appended -- '00132873H1' is API 00132873, sidetrack H1 -- so it is eight characters on a well with no sidetrack and ten on one that has. Join on `api` unless you specifically want to tell sidetracks apart; joining on this one silently drops every well that has no sidetrack code, or matches nothing at all, depending on which side you start.
8 api text The eight-digit API number, county then unique -- '00130641'. The same eight digits texas.api_well_map.api_no, texas.permits and the wellbore files carry, which is what makes a coordinate joinable to everything else on this site. 1,004,128 of the 1,379,242 surface holes find a row in the API-to-lease sheet.
9 long27 double precision Decimal degrees on NAD27. RRC writes the coordinate into the shapefile's ATTRIBUTE table twice, once on each datum, so both are carried here rather than one being derived from the other. NAD27 is the datum the published shapefile is actually on -- its .prj says GCS_North_American_1927 -- so this is the pair to use when checking this table against RRC's own file.
10 lat27 double precision Decimal degrees on NAD27. RRC writes the coordinate into the shapefile's ATTRIBUTE table twice, once on each datum, so both are carried here rather than one being derived from the other. See long27. Roughly 20 metres from the NAD83 pair beside it.
11 long83 double precision Decimal degrees on NAD83. RRC writes the coordinate into the shapefile's ATTRIBUTE table twice, once on each datum, so both are carried here rather than one being derived from the other. This is the pair the map preview and the GeoJSON download use, because NAD83 is within a metre of WGS84 and is what web mapping expects. Negative west of Greenwich; Texas runs about -106.6 to -93.5.
12 lat83 double precision Decimal degrees on NAD83. RRC writes the coordinate into the shapefile's ATTRIBUTE table twice, once on each datum, so both are carried here rather than one being derived from the other. See long83. Texas runs about 25.8 to 36.5.
13 out_fips text Whether the bottom hole falls outside the county's FIPS boundary, which happens where a lateral crosses a county line. One character.
14 cwellnum text The well number as carried on the completion, six characters. Not the API; this is the operator's own number for the well on its lease.
15 radioact text One character, set where RRC's records note a radioactive source left in the hole. Blank on the overwhelming majority.
16 wellid text The well number within the county, as RRC's map system holds it -- the 'unique' half of the API without the county prefix. Five characters.
17 stcode text The sidetrack code, two characters, blank on a well with no sidetrack. This is the suffix that api10 appends.
18 ingested_at timestamptz When the upstream pipeline last wrote this row. Not an RRC field — it is EZRRC's provenance stamp, and it is what the freshness badge is measured against.

What this joins to

The Railroad Commission never states these keys anywhere in the files. They are the reason the data is hard to use, so here they are with the exact columns on both sides.

Mapped Well Locations (Bottom Hole) joins to Mapped Well Locations (Surface) on Surface ID — many rows here share a single row there.

starts at the surface hole

The two ends of the same well. A well with one bottom has one row on each side; a sidetrack, a re-entry or a multilateral has several bottoms against one surface. 1,395,998 of the 1,396,053 bottom holes find their surface hole. The 55 that do not are RRC's own data, not a key problem -- surface_id is the Commission's internal id for the point and both sides are integers, so there is no cast, no padding and nothing to normalise. This is the edge that measures a lateral: the surface coordinate and the bottom coordinate are both here, so the distance between them is a subtraction.

mapped-well-bottom-holes.surface_id = mapped-well-surface-locations.surface_id

Mapped Well Locations (Bottom Hole) joins to Statewide API Data (dBase) on API = API number — many rows here share a single row there.

is the well leased as

The same join from the other end of the well, and the more useful of the two for a horizontal: it puts the lease against where the well actually produces rather than against the pad it was drilled from. 1,021,109 of the 1,396,053 bottom holes find a row, for the same reason the surface edge misses -- a mapped point is not always a currently leased well. Join on `api`, not `api10`: api10 carries the sidetrack code appended and is 10 characters only on wells that have one.

mapped-well-bottom-holes.api = statewide-api-data-dbase.api_no

Mapped Well Locations (Bottom Hole) joins to Mapped Well Paths on Bottom ID — one row here matches many rows there.

ends at the bottom hole

187,206 of the 187,229 mapped paths find their bottom hole. Integers on both sides. With the surface edge above, this is what pairs the two ends of a deviated well when a surface hole has more than one bottom and the pairing is not obvious.

mapped-well-paths.bottom_id = mapped-well-bottom-holes.bottom_id

Where this comes from

Published by
Texas Railroad Commission — the original page
Original format
Shapefile ArcView shapefile — several files that must be kept together.
RRC publishes
Updated twice a week (Twice a week, with the county shapefile packages.)
RRC download link
GoAnywhere MFT
Record layout manual
Our table
texas.gis_well_bottom

EZRRC is an independent mirror of public-domain data published by the Texas Railroad Commission. It is not affiliated with or endorsed by the RRC. For any legal or regulatory purpose, verify against the official RRC release.