{"id":4692,"date":"2013-09-12T13:44:55","date_gmt":"2013-09-12T13:44:55","guid":{"rendered":"https:\/\/etlsolutions.com\/?p=4692"},"modified":"2017-04-05T14:58:14","modified_gmt":"2017-04-05T13:58:14","slug":"whats-in-a-name-well-identification-in-ep-data-management","status":"publish","type":"post","link":"https:\/\/etlsolutions.com\/whats-in-a-name-well-identification-in-ep-data-management\/","title":{"rendered":"What\u2019s in a name? Well identification in E&P data management"},"content":{"rendered":"

By Chris Griffin, Professional Services Director.<\/p>\n

In Romeo & Juliet, William Shakespeare wrote, \u201cWhat\u2019s in a name? That which we call a rose by any other name would smell as sweet.\u201d Well, when it comes to petroleum data management, names are all about numbers and, most importantly, well identification numbers. It appears that wells that smell the same may not actually be the same well, unless of course it\u2019s been re-drilled.<\/p>\n

Recently, we\u2019ve seen an increase in the number of customers asking how we deal with well identification.\u00a0 It seems to be an on-going issue as more Data Managers aim for improved data quality.\u00a0 Enhanced data quality rules and new data stores are driving this requirement.<\/p>\n

This week, the PPDM organisation launched a revised standard, API Number 2013, to ensure that wells in the United States are identified correctly.\u00a0 The table below shows an extract definition from their news release<\/a>:<\/p>\n

\"PPDM<\/p>\n

Click here<\/a> to view the news release<\/p>\n

While these revised standards are very welcome, non-standard identifiers continue to be a significant information management challenge.\u00a0 There is also the issue of tackling well identification outside the United States.<\/p>\n

We address these challenges for our customers in a number of ways:<\/p>\n

In Transit<\/em><\/p>\n

Validation of the data can be carried out using data quality rules, prior to loading into data stores. These deployments can be nested into existing architecture to provide seamless data validation.<\/p>\n

In Store<\/em><\/p>\n

The existing data can be validated in store to ensure that the current data is fit for purpose, and identify areas which may have degraded over time. An area such as duplicate wells is only one of a number of areas that can be validated. The duplicate wells may require matching on other attributes which can be weighted and limited by percentage to ensure a valid match. The attributes used for this can include attributes such as: state, county, latitude, longitude, spud date, field etc.<\/p>\n

This in-store validation can also include cross system validation to ensure that the information in one or more systems is correct. This is common when we come to migrate data to a new target system, as the target usually requires information from a number of database sources and, of course, everyone\u2019s favourite: the spreadsheet. This source data must be verified in its own domain and between the systems.\u00a0 It may also require lookup checks against the target reference data, prior to being classed as fit for purpose and hence fit for migration.<\/p>\n

Further reading<\/h3>\n\n
\n

<\/p>