|
POSC Specifications Version 2.2 |
Epicentre Standard Values Change to Standard Values |
Classification of well log curves is being done in a way that is consistent with other classifications:
Thus, it is now possible to classify a well log curve as both a bulk density curve and a porosity curve. Also, it is possible to classify a curve as (for example) a mechanical caliper curve, and it inherits a classification as a caliper curve, since a mechanical caliper is a type (in the hierarchy) of caliper curve.
All of these are in the files well_log_trace_class for the names of the classes, and well_log_trace_class_classification for the classification hierarchy.
Also, an extensive list of the proprietary codes for well log traces has been developed. These are in well_log_trace_class_alias. They are organized into groups defined by the company and by regular logs or measurement while drilling (MWD):
Because of the length of the file, Schlumberger Well Services is actually broken into five files, alphabetically.
In order to allow version control, two new optional attributes were added to standard instances. These attributes are version and status.
In general, a deprecated value will have (in the description attribute) the value which is replacing it.
Because this is the first use of these parameters, all standard instances will be considered to be of version 2.1 or later.
POSC/Caesar supplied many entries that will be used for classification of equipment and materials. These were put into Epicentre en masse. This affects five entities:
The additions can be found by selecting for name of equipment_class, facility_class, or material_class, where classification_system.name = 'POSC/Caesar'.
A number of facility_class instance values have been changed from current to provisional. The values affected tend to be those classifying wells, wellbores, and completions.
There is a proposed workshop in the Fall of 1997 which is to deal with these instance values. The change to 'provisional' is in anticipation of this workshop. At the workshop, we intend to "start from scratch" in setting up the class values for these facilities.
The change to provisional does not mean that the values will later be deprecated. They may be accepted as they exist by the workshop.
The SDTS document contains a list of the SDTS preferred names for geographic features. In addition, it contains a list of "other names" that are used. In this second list, the document gives the preferred name to be used.
For example, the preferred list has "watercourse." The second list has "river," and gives "watercourse" as the preferred name to use.
The preferred names have been included in ref_geographic_feature for the last several releases. This release adds the names from the second list. These names are in ref_code_alias along with the preferred name that should be used.
In this sense, these are not entirely aliases for the preferred name.
Ref_geographic_feature had a value, bay in previous versions. It was noticed that "bay" is one of the alternate names (preferred name = "inlet") in the SDTS list. Thus, "bay" has been deprecated as a ref_geographic_feature value, and appears in ref_code_alias.
The entity, ref_evaluated_flow_stream replaces the previous ref_target_performance_profile.
Classes for use in classifying document specifications have been added. These include document_specification_class and document_spec_class_classification. These allow documents to classified by their content (similar to keywords), by their life cycle (is this a planning document, a report on an actual survey, processed data, data to be archived, etc.) and/or by the security status.
All class values have been made provisional pending comments.
The Epicentre entity, uncertainty_class, is used to express a degree of uncertainty about a decision or relationship. It was made open in version 2.2 to allow a standard set of values to be asserted.
POSC has introduced two sets of values for use. The first, which has a classification_system name of 'POSC certainty levels,' is a relative listing, and consists of the values high, medium high, medium, medium low, and low. The second uses more descriptive terms, and has a classification system of 'POSC certainty terms.' Its values are certain, likely, maybe, doubtful, uncertain, and unknown.
Go to standard values for uncertainty_class to view the values and their definitions.
A new reference entity has been added so that the type of core can be described. The new entity is ref_core.
Two new reference entities have been added to support production reports. They are ref_generic_fluid_component and ref_generic_fluid_phase.
A new reference entity, ref_product_flow_network_group , has been created to allow groupings of (usually) wells to be used as product flow network units. The main use will be with five, seven, or nine spot patterns; but Epicentre allows any reasonable grouping to be made.
A new classification entity, reserves_class , has been created to replace the two reference entities, ref_proved_reserves_category and ref_unproved_reserves_category. The values in the two reference entities have been moved into reserves_class. In addition, two classification systems have been introduced, POSC proved reserves and POSC unproved reserves to support these two categories.
A new reference entity, ref_geologic_object_association , has been created and values have been instantiated.
This reference entity allows you to say how one geologic object is associated to another. For example, a surface may be the "top" of a volume.
In using this reference entity, the meaning is how the primary object relates to the secondary. In the above example, the primary object would be the surface and the secondary object would be the volue.
The value 'ultimate' was added to ref_transient_period. It has the meaning of "all time without limit."
Three instances of ref_business_associate were deprecated. These are 'integrated oil company', 'e and p company', and 'service company'. The appropriate treatment is to use the instance, 'company', and to use ref_business_service to describe the services provided by the company.
Added the new unit of measure, microradian (urad), to support the scale factor parameter for some of the geodetic transformations. This also required the addition of the unit of measure conversion and the addition of the microradian to ref_quantity_type: factor.
Added two new units of measure - psi2.d/cp.ft3 and psi2.d2/cp.ft6 - to support two new instances of ref_quantity_type (See next change). These units support the quantity types of Darcy flow coefficient and nonDarcy flow coefficient.
Added quantity types to ref_quantity_type. These are the Darcy flow coefficient and nonDarcy flow coefficient.
Also added were units of measure and their conversions to SI units.
v2.1 of Epicentre removed adjoin from ref_object_intersection. However, the definition of 'empty' contained a reference to adjoin. v2.2 changes the definition to remove this reference.
Ref_phone_number has been changed. It was noted that many items in the list could be at the home or the office. Examples are the voice phone, fax, emergency numbers, etc.
It was decided to split the home/ office information into another reference entity: ref_address_qualifier. The instances of ref_address_qualifier are 'home' and 'office.' Since this is an attribute of address (not just the phone number), it is also possible to qualify email addresses and mailing addresses as home or office.
The instance values in ref_phone_number of 'office' and 'home' have been deprecated.
In addition, the instance value 'mobile' has been introduced to replace the instance value 'cellular.' It is thought that cellular is less general than mobile. The value, 'cellular,' has been deprecated.
Several new values have been introduced:
Definitions of these are given in Ref_phone_number
A re-evaluation of the meaning of typical_activity and activity_class led to the decision that the instance values in typical_activity are really classifications.
The instance values in typical_activity have been moved to activity_class.
Previous versions of Epicentre used connected_to and connected_from to describe how facility components were connected. When there is no real semantic meaning to the "to" and "from" terms, it was ambiguous how to properly "connect" the pieces.
This was changed by introducing a new epicentre entity, wellbore_component_facility_connection, with attributes "wellbore_component_facility", "connected_from", and "ref_wellbore_component_facility_con". The first two attributes define the two components that are connected, and the third says what the connection looks like. In particular, ref_wellbore_component_facility_con has instance values of 'above', 'below', 'inside', and 'outside' to describe the connection.
Use of both terms: 'electric potential' and 'electrical potential' prompted the desire to pick one only. The one chosen was electrical potential. Changes were made to reflect this decision:
Caliper was an instance of ref_quantity_property. However, it is a tool, and not a property. The instance value was changed to caliper diameter in order to be a quantity name rather than a tool name. The value, caliper, is deprecated.
In addition, the reference to this ref_quantity_property was changed in ref_property_kind.
Values were added to ref_quantity_property to support fluid flows:
This is a technical change. Five named data types were required to meet a specification for values in ref_property_set. Ref_property_set did not contain these values. They were added.
The five new values are:
In order to support more classifications, values were added to support drilling fluid (mud) classifications. The values were taken from a World Oil article from June 1996. This also shows an example of how to instantiate Trade Name products as typical_materials.
They occur in classification_system and material_class
In addition to these values, an example is given that uses these values to characterize two typical_materials. These two materials are of subtype, solid_additive_type, and represent trade name materials. In order to give meaning to the trade names, ref_naming_system had values added to it representing the manufacturer.
The US state postal codes had previously been defined as being in the naming system of 'US digraph.' This naming system was also being used to describe the two character codes for countries, as set up by the US government. This caused a problem, because the same code might be used for a country and for a state. For example, the code for both Albania and Alabama is 'AL'.
In order to make the combination of code :: ref_naming_system unique, the naming system for states was changed to US state code.
The classification system value, 'seismic array pattern', was added to classification_system. Nine kinds of patterns were added to facility_class. All of these values were taken from Sheriff's book, Encyclopedic Dictionary of Exploration Geophysics. The nine array patterns are:
A new reference entity ref_seismic_acquisition_vertex was added. The instance values allow one to seismic station or source location as the origin of a local coordinate system. This is often done when a coordinate system is build with respect to a seismic line or 3d survey. For example, a common coordinate system is "distance along the line," for which the first shot station would be the origin (0 point) of the coordinate system.
ref_descriptive_property in conjunction with ref_property_kind allows one to use strings. It is particularly useful when the data falls into a frame. For example, you might have a well log that gives porosity values, but also has comments in the side of lithologic or geologic nature. These comments can be captured by using the "comment" value of ref_property_kind.
The three added values are:
Examples of its use:
To record the comment, "Fine-grained sandstone, calcareous, dead-oil," use the 'lithology' value.
To record the comment, "Highly-crossbedded clean sands," use the 'geology' value, since crossbedded is a geologic term.
To record the comment, "Plug contaminated by improper handling," use the 'comment' attribute, since this is a general comment.
The following sections are changes made to geopolitical features and their aliases.
Most of these changes were prompted by the problem with the Congo. As you probably know, on May 28 (or thereabouts), rebel forces completed their takeover of Zaire, and renamed their country to "Congo." This prompted a problem with our database, since there is already a country named the Congo.
The problem is how to deprecate the name, Congo, for one country, and to make it current for another. The technical problem is that we cannot have two instances of Congo - one current and one deprecated - because of our uniqueness rules. The solution that we are proposing will be the following:
Here is the result of these changes. A person will now be able to query only the earth_surface_feature_alias in order to get all of the alias names for a country. There is no need to query geopolitical_feature to get one name, and earth_surface_feature_alias to get the rest of the names. In addition, since there is an effective date and expiry date in earth_surface_feature_alias, it is possible to keep track of the history of the name changes.
See the sections below for more more specific changes that have been made.
The identifier for geopolitical feature was of data type ndt_name, which was restricted to 40 characters or less. This meant that two ISO names could not be used (conventional long form).
The following two changes were made. The "common name", which was a shortened form, was deprecated, and the "conventional short form," the ISO name, was made current:
The following five additions were made to earth_surface_feature_alias:
On approximately 28 May 1997, rebel forces captured the government of Zaire, and renamed the country to Congo. This international political event precipitated an equally impressive crisis in the Epicentre database. The problem is that there is already a country named "Congo," and it is not possible to have two such countries.
We set the following policies to deal with this issue:
The following changes will be noticed:
Comments on the above procedure would be welcome.
The following sections are changes made to coordinate systems and coordinate transformations. These reflect, for the most part, changes made by the European Petroleum Survey Group (EPSG). For information about this group and about their collection of geodesic information, see their web page at http://www.petroconsultants.com/epsgweb/epsg.htm
Ref_map_projection is not being used. It is referenced in projected_coordinate_system, but is not being used. It's meaning is not clear.
The EPSG has recommended that it be deprecated.
Ref_axis_orientation is not being used. It is referenced in coordinate_system_axis, but is not being used. It's meaning is not clear.
The EPSG has recommended that it be deprecated.
A new type of method, polynomial, has been added to the methods already defined. It is intended to support polynomial fits that take R2 into R2.
In order to remain in step with the EPSG, the following changes were instituted in coordinate_transformation_method.
All references to these methods have also been changed. The references are in coordinate_transformation, coordinate_transformation_parameter, and coordinate_transformation_value.
Added the following coordinate transformation:
The EPSG consolidated the coordinate transformation parmater names to be more consistent across the transformation methods. The main changes were
In addition, there was consolidation of the parameter names for the geocentirc translations, Molodenski, abridged Molodenski, position vector transformation, and coordinate frame rotation.
The parameters for the 2nd-order polynomial function, 3rd-order polynomial function, and 4th-order polynomial function were introduced by the EPSG. POSC chose to use the parameters, but changed the names from what was given by the EPSG. For example, to calculate the new x (xnew) value and new y (ynew) value from the old x and y (xold, yold) using the 2nd-order polynomial function:
let dxnew = xnew - (ordinate 1 of target evaluation point)
dynew = ynew - (ordinate 2 of target evaluation point)
dxold = xold - (ordinate 1 of source evaluation point)
dyold = yold - (ordinate 2 of source evaluation point)
then
dxnew = x-axis translation + ax * dxold + ay * dxold
+ axx * dxold**2 + axy * dxold * dyold + ayy * dyold**2
dynew = y-axis translation + bx * dxold + by * dyold
+ bxx * dxold**2 + bxy * dxold * dyold + byy * dyold**2.
The EPSG uses a different notation for the coefficient parameters.
Alaska CS27 zone 1 had values of false easting and false northing as 5000000 ftUS and -5000000 ftUS respectively. These values are correct if the units of measure were metres. However, since the units of measure for this transformation are US Survey feet, the values should be 16404166.67 ftUS and -16404166.67 ftUS respectively.
The reference data has been corrected to these values. There are no deprecated values. The version attribute for these values has been set to 2.2, and the status flag is current.
The three Morocco zones, Sud Maroc, Nord Maroc, and Sahara, all had the longitude of origin set to 6 gr E (+6 gr). The correct value should be 6 gr W (-6 gr).
The reference data has been corrected to these values. There are no deprecated values. The version attribute for these values has been set to 2.2, and the status flag is current.
India zone 0 had values that were the values for India zone I. These have been changed to the appropriate values:
The reference data has been corrected to these values. There are no deprecated values. The version attribute for these values has been set to 2.2, and the status flag is current.
The Cape datum, which is used in South Africa, had the wrong ellipsoid. It incorrectly had Clarke 1880 (RGS). It should be Clarke 1880 (Arc).
This has been corrected in v2.2. The instance of Cape has had the epicentre_version updated to 2.2. No instances have been deprecated, since it is possible to have only one Cape datum.
The coordinate_transformation, R.S.O. Borneo, had its name changed FROM the longer version, Rectified Skew Orthomorphic Borneo, to the shorter form. The EPSG had set the full name as the name of the transformation, but had also given the shorter name as the preferred name. The standard policy of Epicentre is to use the shorter, preferred name.
In transcribing the original information, the longer name was mistakenly use. This version corrects that by using the shorter name.
This has been corrected in v2.2. The original instance has been deprecated.
The coordinate_transformation, Singapore Grid, had an incomplete set of values recorded. The complete set of values now appears.
The coordinate_transformation, Trinidad Grid, mistakenly had the longitude of natural origin equal to 0. The correct value, 61 20 00 W now appears (-61.33333 dega).
There are three Austrian projections, of type Transverse Mercator. One of the parameters of this method is the longitude of natural origin. In order to make sense of this longitude, it is necessary to know which prime meridian it is with respect to.
The original values were given with respect to the Greenwich. While the values were correct in this system, it is more correct to give the values with respect to Ferro. This change has been made.
No instances have been deprecated.
There are four Colombian projections, of type Transverse Mercator. One of the parameters of this method is the longitude of natural origin. In order to make sense of this longitude, it is necessary to know which prime meridian it is with respect to.
The original values were given with respect to the Bogota. While the values were correct in this system, it is more correct to give the values with respect to Greenwich. This change has been made.
The ellipsoid_alias entity was instantiated. Following is a list of ellipsoids and their aliases. The alias instance values can be found in the standard values.
| ellipsoid | alias |
|---|---|
| Clarke 1880 (RGS) | Clarke Modified 1880 |
| GRS 1967 | International 1967 |
| GRS 1980 | International 1979 |
| International 1924 | Hayford 1909 |
| WGS 84 | WGS84 |
Sweden bases its data on the Stockholm prime meridian. In order to support this, the geographic coordinate system, RT38 (Stockholm) was added.
It is also necessary to support the Swedish projection transformation: Swedish National Grid. This was instantiated along with its transformation values, and all of its related instances (such as axes, etc.)
Kuwait has geographic_coordinate_systems based on three geodetic_datums. They are KOC (alias: Kuwait Oil Company), KUDAMS (alias: Kuwait Utility), and NGN (alias: National Geodetic Network). The last two of these have been added.
In addition, there are four projection zones based on these datums:
| geodetic datum | projected coordinate system | transformation (projection zone) |
|---|---|---|
| KOC | KOC Lambert | Iraq zone |
| KUDAMS | KUDAMS / KTM | Kuwait TM |
| NGN | NGN / UTM zone 38N | UTM zone 38N |
| NGN | NGN / UTM zone 39N | UTM zone 39N |
Romania has geographic_coordinate_systems based on two geodetic_datums. They are Dealul Piscului 1933 and DealulPiscului 1970. These have both added.
In addition, there are two projection zones based on these datums:
| geodetic datum | projected coordinate system | transformation (projection zone) |
|---|---|---|
| Dealul Piscului 1933 | Stereo 1933 | Stereo 1933 |
| Dealul Piscului 1970 | Stereo 1970 | Stereo 1970 |
All the coordinate systems, datums, and transformations are new, and have been added in v2.2.
Two datums were added for Greece. They are Greek and GGRS87. GGRS87 is the EPSG preferred name for the geodetic_datum_alias Greek Geodetic Reference System 1987.
In addition, a new prime meridian, Athens, was added.
Three new geographic coordinate systems were formed. They are
A new coordinate transformation, Greek Grid, was created for GGRS87. It has also been instantiated in Epicentre. It is of type Transverse Mercator.
When the transformation is applied to GGRS87, it produces the new projected coordinate system, GGRS87 / Greek Grid. It is noted in the remarks for this instance that the oil industry generally uses ED50 / UTM zone 34N and ED50 / UTM zone 35N.
The vertical reference, Piraeus86, is introduced. A vertical coordinate system, Piraeus, is instantiated using this datum.
Coordinate transformations are instantiated between the geographic coordinate systems:
Geodetic datum ATS77 (Average Terrestrial System 1977) has been added to support coordinate systems in New Brunswick. The coordinate system corresponding to this datum is ATS77 also.
Three projected coordinate systems were instantiated using projections on this coordinate system. They are:
Originally, the grid zones in South Africa and southern Africa were labelled as Lo13 to Lo35. These have been changed. They have been deprecated, to be replace by the following:
It should be noted in passing that the parameters for the Namibian transformations are German legal metres, rather than the international metre.
The projected coordinate systems related to these have also been changed.
A new geodetic_datum was developed for Russia: Pulkovo 1995. This supplements the old datum that was used in the Soviet Union: Pulkovo 1942.
Along with the datum is the geographic_coordinate_system, also with the name Pulkovo 1995.
In addition, the old datum had 58 projection zones using the Gauss-Kruger transformation. These were supplemented with a corresponding 58 projection zones based on the new datum, and also using the Gauss-Kruger projections.
Note: For consistency, the names of the old projection zones were changed from "Pulkovo / Gauss..." to "Pulkovo 1942 / Gauss..."
The old projection zone names were deprecated. The new names, as well as the newly created coordinate systems, had the epicentre_version set to 2.2.
Epicentre has four types of vertical datums. Two require standard instances. These are vertical reference datum, which are datums generally set by countries or groups of countries based on a network of observations and calculations; and the geoid, which is an approximation of sea level. It should be noted that the vertical reference datums also are based on the geoid, but they are generally additionally determined by a set of observations. The other two types of vertical datums are the ellipsoid, which we obtain through a reference to a geodetic datum. These are not specifically instantiated as vertical datums, but are referenced in various local spatial coordinate systems through the vertical depth system axis. The final type of vertical datum is a local vertical datum, which is a local value, and represents a local reference point that a surveyor has established for his references.
The specific geoids remain unchanged. In version 2.2, we have added several new instances of vertical reference datums, and have deprecated two, to match the naming conventions of the EPSG. The two deprecated are NAVD29, which has been replaced by NGVD29, which stands for National Geodetic Vertical Datum 1929, and is used in the US; and Newlyn which has been replaced by ODN, which stands for Ordnance Datum Newlyn.
Note: In version 2.2, there is only one vertical reference that is instantiated as a geoid. It is "Mean Sea Level." All others are instantiated as vertical_reference_datums.
Based on the geoids and vertical reference datums that EPSG has supplied, new vertical coordinate systems have been created.
Following is a list of these new coordinate systems, and, where appropriate, the alias (or long name).
See the above section for more information on the datums
The name of the European Reference datum was changed to the full name of European Terrestrial Reference System 89 (in geodetic_datum_alias) with a short name of ETRS89 (in geodetic_datum).
The corresponding geographic_coordinate_system also had its name changed to ETRS89.
The old values were deprecated.
Projected Coordinate Systems based on the ETRS89 geodetic_datum were added. The projections used are UTM zones 28N to 38N.
Many of the more commonly used geodetic transformations (transformations from one geographic coordinate system to another) have been defined by the EPSG. These transformations are also call redatuming transformations, since they change from one datum to another.
It must be pointed out that these are standard, but only approximate. It may be necessary to derive your own set of parameters for more accuracy.
The following standard values were affected:
In addition, it was necessary to add a new unit of measure, the microradian (urad), to support the scale factor parameter.
The ref_coordinate_system_constraint value of depth time system incorrectly only had one axis. This was changed so that it now properly has two axes.