geological-survey-of-queensland / borehole-database Goto Github PK

1. Should this page be incorporated with the Geoproperties database page?
2. Should the Borehole sub-status be added to this page?

What the borehole database is not
The borehole database is not a borehole data management system. There are multiple commercial systems that meet the extended data requirements of specific industries.

What is the distinction between a borehole database and a borehole data management system? Are they not synonymous? Or are you using 'system' to mean 'collection of processes'?

So what are we using to manage the borehole data for our use and interpretation? Do you mean a borehole lifecycle management system? Even though it's being used to capture/store lifecycle information (e.g. status updates).

As the QWRC RN is an alias, this should be recorded in the borehole alias table, i.e.:

• borehole_alias = QWRC RN number
• borehole_alias_source = QWRC RN
• borehole_alias_reason = Historical number for water bores from the Queensland Water Resource Commission (or something similar).

Thoughts?

Terminology
A borehole is a narrow shaft bored in the ground.
But narrow relative to what? Is shaft the best word?

'Borehole' is synonymous with a range of terms including 'well', 'bore', 'drillhole and corehole. -< missing single quote marks.

A more accurate description would be "including the extraction of water, oil, and natural gas".
Boreholes are synonymous with a range of terms including well, bore, drillhole and corehole.

Derivation
For minerals the data schema being used for ingest is based on the GGIC data templates

The borehole database
"The Geological Survey of Queensland is creating a new database of boreholes to replace the borehole records that are currently held in the existing MERLIN system."
Inclination, Azimuth, and Well Design are a bundle of concepts.

• Petroleum: Relevant to view well design (e.g. deviated) at a high level and then view the directional survey data (hundred of lines of data) as linked data. The surface inclination and azimuth is largely pointless without further context.
  Would want to see
  Well 1 : Deviated | Surface Lat: -27.484939 Long: 149.008309 | Bottom Hole Lat: -27.484941 Long: 149.008315

• Minerals: Will probably never tell us of design. But will report a inclination and azimuth at surface and will want to see the same. (e.g. 60° Inclination at 274° azimuth from True North). A surface inclination such as this would tell us the well is an inclined well, but this is not the pertinent information for minerals focuses persons.
  Would want to see
  Drillhole DDH1: Inclined | Surface Lat: -27.484939 Long: 149.008309 | Inclination 60° Azimuth 274° from True North

• Coal is halfway between the two.

Inclination is also annoyingly dealt with differently by minerals and petroleum. Vertical is -90° in minerals and 0° in petroleum.

Borehole data elements
Association is better dealt with at the wellbore level. It is more useful to know what hole was the parent wellbore than just that a wellbore had a parent.

Move origin circumstance up to live with origin lat long and elevation

Other elements
QWRC RN ?
Rig release - include
hylogger ?
TD logger - doesn't hurt to include
Perforation - would link to separate engineering dataset

Borehole data mapping to industry reporting templates
Association should be at wellbore level
purpose/type = coal, petroleum, mineral
sub-purpose = Petroleum (exploration, appraisal, development), Coal (LOX etc)
status should be recorded in all or inferable from events

See azimuth and inclination comments above

surface circumstance -> origin circumstance

Borehole data mapping to standards
For petroleum bore_id the government borehole number
bore_name is a concatenation of well_name and well_num

Borehole vocabularies
move/add coalLog purpose into the sub-purpose. Will need collections in sub-purpose for pet, coal, min

Drilling method can be synonymous with bit type. But males more sense at the borehole or drilling interval level as an engineering dataset. each borehole may be drilled using several different methods.

borehole status. CoalLog isnt quite fit for our purposes. refer to status life cycle in borehole profile

borehole inclination (see comments above)

Reporting guideline lookup values
Needs a deeper review to get alignment across all reporting templates and guidelines.

The way it is described here, I do not think this is the right way to approach this and I am very concerned that there is not enough data captured. Why are we at a stage where this is being defined in the weeks before the solution vendor is being brought on? Surely what we want should have been specified in the tender, otherwise how do we know that the vendor can actually deliver a suitable system. If they’re just proposing to replicate SARIG for Queensland, that’s a backwards step of about 10 years, not a forwards step.

Terminology
• While accurate, I have never seen anyone bother to describe a borehole as ‘a narrow shaft bored in[to] the ground.
• Water is a liquid
• Petroleum covers both oil and gas
• There are other synonyms missing for borehole (e.g. corehole)

Background
• Actors?
• GSQ’s borehole dataset is the point of truth for QLD government the others leverage off it

The borehole register
• From what is described overall in this document/page, the borehole register is not replacing MERLIN, it is only replacing a part of the MERLIN boreholes table and not even the minimum amount at that. It describes what amounts to the first two ‘screens’ in MERLIN borehole and has to expand beyond this. Otherwise, the solution is not fit for purpose.
• Linked datasets should be those where data comes in an additional defined format – e.g. las or dlis for wireline logs.
• Core and cuttings intervals are primary attributes of a borehole
• Sample intervals are primary attributes of a borehole that should then be linked to the results from the sampling/analysis

Simplifed data model diagram
• Hylogger data is linked data, not result data
• Status is entity data (it’s the activity level of the borehole)
• Producing stats is probably more engineering data, maybe operational data
• Permit that the borehole is drilled on is primary metadata and can then be linked to further data available relating to the tenure. This should be attributed, rather than constantly derived, as you’ll have to take time as well as space into account.
• Reports contain data, they aren’t data themselves
• Cores and cuttings are intervals, not results
• Result includes what (if anything it discovered)
• Are intervals engineering intervals? Or production intervals? Or sample intervals? Lithological intervals? Orientation (azimuth and inclination) intervals? Casing intervals? This is really ambiguous
• From the general description, it seems that all you’re proposing is that the borehole register contains just the entity data – this isn’t enough.
Conceptual data model
• Purpose and sub-purpose would map to type and subtype and these don’t have a start and end date. Otherwise there are issues around confidentiality periods when they are defined by activity. The Status should have start and end dates (e.g. producing or not).
• Azimuth and inclination are likely to be a log in a petroleum or CSG well. Not sure if minerals and coal are running deviation logs, though I have seen some coal deviation logs. Single field not enough for storing this.

Borehole data elements
• Need to have eastings and northings and zone for the location information too
• depth_datum would make more sense as origin_datum – much easier to see the association
• Azimuth and inclination are likely to be an associated log for petroleum and csg wells
• Require rig release date for petroleum wells
Borehole data elements that are inferred
• Bhf_wireline_logs is not a good record of the wireline logs and should not be simply migrated
o Wireline log information must be scraped from las files where possible and composite log scans where no las files are available
• Bhf_borehole_survey_plan is not up to date
• QDEX Reports number is not currently held in bhf_borehole_survey_plan – it should be in bibliography, but there’s a lot of mess in that space – had to be manual update. Link will need to come from QDEX system
• Results field is a pain and is in desperate need of an update. It’s not a sample or observation though. It’s an interpretation of what was found in a well and is not particularly useful as there is an economic implication in the interpretation
Other borehole data elements
• QWCRN – needed
• Rig release date – needed for petroleum wells
• 306 have it because it’s more a reflection of how many wells have been hylogged
• Total depth logger – needed
• Perforation – this is engineering/production information
• Comments – probably needs a lot of vigorous discussion and QA

Hi David, please see my comments in the uploaded Word doc.
Cheers,
John

Borehole Register Comments 2 October 2109.docx

@DavidCrosswellGSQ @KellyVance

As per discussion and agreement in the Borehole Reference Group meetings, there needs to be a fix for the origin_elevation and depth_datum:

REQUIREMENT: Capture and display the elevation of the origin (i.e. the point at which the well meets the surface) and capture the elevation of the depth datum. Alternatively, depth_datum could be captured as a measurement above the origin point.

The origin is the point at which the well meets the ground. The “depth datum” is the rotary table or other point (sometimes at GL, but most often above it) as is the noted reference datum point. This is stored in MERLIN Borehole and currently reported:

Liz GSQ Borehole Database Review 11 Oct 19.docx