POSC Specifications
Version 2.2
Epicentre Standard Values
Change to Standard Values

Changes from v2.1 to v2.2

Summary of Changes

New classifications of well log curves.

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):

  1. Atlas Wireline Services
  2. Reeves Wireline, formerly BPB Wireline Services
  3. Halliburton Logging Services
  4. Numar
  5. Schlumberger Well Services
  6. MWD-Anadrill
  7. MWD-Halliburton
  8. MWD-Baker Hughes Inteq
  9. MWD-Sperry Sun

Because of the length of the file, Schlumberger Well Services is actually broken into five files, alphabetically.

Go To Top


Two new (optional) attributes added.

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.

Go To Top


Add class entries from POSC/Caesar project.

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'.

Go To Top


Make Some Facility Class Values Provisional.

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.

Go To Top


Added SDTS aliases for ref_geographic_feature.

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.

Go To Top


Ref_evaluated_flow_stream replaces ref_target_performance_profile.

The entity, ref_evaluated_flow_stream replaces the previous ref_target_performance_profile.

Go To Top


Added document specification classes

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.

Go To Top


Added uncertainty classes

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.

Go To Top


New reference entity: ref_core.

A new reference entity has been added so that the type of core can be described. The new entity is ref_core.

Go To Top


New reference entities: ref_generic_fluid_component and ref_generic_fluid_phase.

Two new reference entities have been added to support production reports. They are ref_generic_fluid_component and ref_generic_fluid_phase.

Go To Top


New reference entity: ref_product_flow_network_group.

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.

Go To Top


Reserves_class replaces ref_proved_reserves_category and ref_unproved_reserves_category

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.

Go To Top


Added ref_geologic_object_association.

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.

Go To Top


Add ultimate to ref_transient_period

The value 'ultimate' was added to ref_transient_period. It has the meaning of "all time without limit."

Go To Top


Deprecate overly descriptive ref_business_associate.

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.

Go To Top


Added new unit of measure.

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.

Go To Top


Add quantity types of Darcy and nonDarcy flow coefficients.

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.

Go To Top


Remove adjoin from ref_object_intersection

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.

Go To Top


Change ref_phone_number

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

Go To Top


Move typical_activity to activity_class

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.

Go To Top


Added ref_wellbore_component_facility_con

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.

Go To Top


Change electric potential to electrical potential

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:

Go To Top


Change caliper to caliper diameter

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.

Go To Top


Added values to ref_quantity_property

Values were added to ref_quantity_property to support fluid flows:

Go To Top


Added values to ref_property_set etal

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:

Go To Top


Added values to classification_system and material_class

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.

Go To Top


Added value to ref_naming_system

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.

Go To Top


Added seismic array patterns to classifications

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:

Go To Top


Added new reference entity ref_seismic_acquisition_vertex

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.

Go To Top


Added values to ref_descriptive_property, ref_property_kind

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.


Go To Top


Changes in Geopolitical Features and their Aliases.

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.

Go To Top

Long names are now possible.

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:

  1. Macedonia becomes "The former Yugoslav Republic of Macedonia"
  2. South Georgia, South Sandwich Islands becomes "South Georgia and the South Sandwich Islands"

The following five additions were made to earth_surface_feature_alias:

  1. Socialist People's Libyan Arab Jamahiriya
  2. Commonwealth of the Northern Mariana Islands
  3. Democratic Republic of Sao Tome and Principe
  4. Democratic Socialist Republic of Sri Lanka
  5. United Kingdom of Great Britain and Northern Ireland

Go To Top


Change in the Congo.

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.

Go To Top


Changes in coordinate systems and coordinate transformations.

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

Go To Top


Deprecated ref_map_projection

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.

Go To Top


Deprecated ref_axis_orientation

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.

Go To Top


New type of coordinate transformation

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.

Go To Top


Changed coordinate transformation methods

In order to remain in step with the EPSG, the following changes were instituted in coordinate_transformation_method.

  1. Lambert Conic Conformal (Helmert) was changed to Lambert Conic Conformal (2SP Belgium). This instance is used by only one transformation: Belge Lambert 72.
  2. Swiss Oblique Mercator was changed to Swiss Oblique Cylindrical. This instance is used by only two transformations: Swiss Old Grid and Swiss New Grid and
  3. Mercator was changed to Mercator (1SP) and Mercator (2SP). The set of parameters for the two methods are slightly different. The only coordinate transformation using the Mercator is Netherlands East Indies Equatorial Zone which uses the Mercator (1SP) method.
  4. Added polar stereographic to the list of coordinate transformation methods. This supports standard polar stereographic projections at the North pole and the South pole.
  5. Added six new methods (coordinate_transformation_method):
    • longitude rotation to rotate the longitude value and keep the latitude and/or elevation constant.
    • geocentric translation to translate, without rotation, the center of an ellipsoid.
    • abridged Molodenski. A modification of the Molodenski.
    • 2nd-order polynomial to handle Rē -> Rē transformations of the 2nd order.
    • 3rd-order polynomial to handle Rē -> Rē transformations of the 3rd order.
    • 4th-order polynomial to handle Rē -> Rē transformations of the 4th order
  6. Changed two methods to match the EPSG terminology (coordinate_transformation_method):
    • Molodenski. Changed from Molodensky.
    • position vector transformation. Changed from Bursa-Wolf. rotation

All references to these methods have also been changed. The references are in coordinate_transformation, coordinate_transformation_parameter, and coordinate_transformation_value.

Go To Top


New Coordinate Transformations.

Added the following coordinate transformation:

Go To Top


Consolidated coordinate transformation parameter names.

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.

Go To Top


Alaska CS27 zone 1 had wrong values

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.

Go To Top


Morocco zones had wrong value.

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.

Go To Top


India zone 0 had wrong values.

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.

Go To Top


Cape datum had wrong ellipsoid.

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.

Go To Top


R.S.O. Borneo

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.

Go To Top


Singapore had an incomplete set

The coordinate_transformation, Singapore Grid, had an incomplete set of values recorded. The complete set of values now appears.

Go To Top


Trinidad Grid had wrong longitude of origin

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).

Go To Top


Austrian projections should reference Ferro.

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.

Go To Top


Colombian projections should reference Greenwich.

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.

Go To Top


Add Ellipsoid aliases

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

Go To Top


Add Swedish data

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.)

Go To Top


Add Kuwait data

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

Go To Top


Add Romania data

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.

Go To Top


Add Greek Data

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:

Go To Top


Add New Brunswick Data

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:

Go To Top


Southern and South Africa grid zones changed.

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.

Go To Top


Add new Russian Coordinate Systems

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.

Go To Top


Added and Changed Vertical Datums

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.

Go To Top


Added New Vertical Coordinate Systems

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

Go To Top


Changed EUREF89 to ETRS89

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.

Go To Top


  • Added ETRS / UTM coordinate systems for Europe

    Added ETRS / UTM coordinate systems for Europe

    Projected Coordinate Systems based on the ETRS89 geodetic_datum were added. The projections used are UTM zones 28N to 38N.

    Go To Top


    Added Geodetic Transformations

    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.

    Go To Top


    Correct error in ref_coordinate_system_constraint

    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.

    Go To Top



    Last Modified: August 5, 1997
    © Copyright 1997 POSC. All rights reserved.