|
POSC Specifications Version 2.2 |
Epicentre Usage Guide Basic Understanding of Coordinate Systems |
[Coordinate System Table of Contents]
Epicentre supplies a set of standard coordinate systems, as well as providing the user with the means to create his own coordinate system.
Standard geodetic coordinate systems in use throughout the world provided with Epicentre have been identified by the European Petroleum Survey Group (EPSG) in cooperation with POSC. Several surveyors from the US have also participated in reviewing the work. The coordinate systems identified by the EPSG represent agreement by a number of major oil companies and service companies as to the appropriate names and parameters of these coordinate systems. The work done by this group is also being sent to other organizations outside the petrotechnical business who are interested in standardizing the names and parameters of coordinate systems.
Because of the already widespread agreement on these coordinate systems, it is advisable that they be used whenever possible. It is recommended that each company should examine its own set of coordinate systems - as well as supplementary information like ellipsoids and geodetic datums - to match its names and parameters with the standard set as supplied by POSC from the EPSG.
See diagram on Types of Coordinate Systems
There are five types of coordinate systems defined in Epicentre. Three of these relate to position and will be of particular concern to the general user. These are the geographic, projected, and local spatial. For a more in-depth introduction to coordinate systems, see Section 3.2, "Coordinate systems - A Deeper Understanding". It is recommended reading for anyone who wishes to be familiar with earth based coordinate systems.
The geographic coordinate system is a latitude and longitude coordinate system. It is closely identified with and related to the concept of a geodetic datum, although Epicentre makes a technical distinction between the geodetic datum and the coordinate system. Whenever data is given in latitude and longitude, a geographic coordinate system is the type of coordinate system which applies.
The projected coordinate system represents the projection of a geographic coordinate system onto a plane. State Plane coordinate systems in the US, and coordinate systems based on Universal Transverse Mercator (UTM) projections are examples of projected coordinate systems. The coordinates of a projected coordinate system are popularly given as (x,y), however POSC and the EPSG members are more explicit. POSC has specified the axes as (easting, northing) in which the semantics of easting and northing indicate the direction of the axes. Although "easting" generally coincides with "x", and "northing" generally coincides with "y", there are enough exceptions to require the user to be careful.
The third type is the local spatial coordinate system. In general, these are coordinate systems of limited, local extent that may eventually be related to one of the standard coordinate systems mentioned above. For this reason, POSC is not supplying many standard local coordinate systems. An exception is a set of six vertical only coordinate systems that are optional, but which if used, will allow standardization throughout the industry. These are described in Section 3.1.2.5, "Vertical Coordinate Systems".
It is intended that all of the appropriate coordinate system information be present in Epicentre, and that the use of the coordinate systems be easy. The techniques below will give the detail necessary for the user to make basic use of the coordinate systems. More advanced usage will require knowledge beyond this tutorial, and may be found in Section 3.3, "Advanced Usage of Coordinate Systems".
In Epicentre, all standard earth surface coordinate systems have the feature that the horizontal coordinates are in a separate coordinate system from the vertical. That is, there is no coordinate system supplied as a standard coordinate system that will allow one to give a three coordinate location of (latitude, longitude, elevation). This is done by two coordinate systems - one for the (latitude, longitude) and another for the elevation1.
|
Note 1: This is not a requirement of Epicentre. It is based on recommended usage. It is possible, if one desires, to set up a coordinate system with three axes combined. |
The order of the coordinate values is also important. The standard geographic coordinate systems generally give the axes in the order of (latitude, longitude). The standard projected coordinate systems generally give them in the order of (easting, northing).
Also note that the coordinate transformation is not a part of the coordinate system. Coordinate transformations are defined separately from the coordinate systems. There is an Epicentre entity Applied_coordinate_transformation that ties a specific coordinate transformation to the source and target coordinate systems. For example, there is a geographic coordinate system called NAD83, and a projected coordinate system called 'NAD83 / Florida East'. There is a specified coordinate transformation called 'Florida CS83 / East zone', as well. The Applied_coordinate_transformation ties these three instances together. Thus, the Epicentre interpretation is as follows: The coordinate transformation, 'Florida CS83, East zone', transforms the coordinate system 'NAD83' to the coordinate system 'NAD83 / Florida East'.
Finally, appreciate that the distinction between the coordinate transformation and the resulting projected coordinate system is not always made in the oil industry. In particular, Epicentre recognizes that the UTM transformations are coordinate transformations, and not coordinate systems. The user may have to go an extra step to create the coordinate system from a UTM transformation2. This distinction is not academic, since, a UTM transformation applied to NAD27 will give different locations than the same UTM transformation applied to NAD83. See Section 3.1.7, "Using a UTM Transformation" for an example.
|
Note 2: Epicentre supplied the definition of all the UTM coordinate transformations by giving the names and set of parameter values. It also supplies some commonly used projected coordinate systems based on some UTM transformations. |
See Section 3.1.8, "Storing Locations" for an example of using coordinate systems to store location data.
Six vertical coordinate systems are given with Epicentre. One is for use as a measured depth coordinate system, and four others are for elevations or true vertical depths. The sixth is used when the type of depth is unknown.
Terminology conventions are that elevations refer to positive upwards, whereas depths refer to positive downwards (with only one exception).
In addition, elevations and depths are meaningful only if the zero level (reference elevation) is known. Three of the coordinate systems use Mean Sea Level (an instance of a geoid) as the reference, while the other three have no specified reference. For a location in these other two to make any sense, it is necessary to give the zero reference value3. Examples of such reference values would be ground level, kelly bushing, rotary table, etc.
|
Note 3: The third is the 'unknown elevation', which means that the reference is unknown. |
Table 3-1 gives the names, reference elevations, and positive directions of the supplied vertical coordinate systems. On review, it becomes apparent that the first two, "sea level elevation" and "subsea tvd", are the same. Convention specifies that sea level elevation be used to describe elevations of surface objects, such as wells, benchmarks, etc., while subsea tvd is used to give depths, negative downwards, of points below the Earth's surface. The coordinate system "tvd from sea level" is used when the "subsea tvd" values are given positive downwards rather than negative downwards. These conventions are typical of usage (and misusage) of the terminology in the oil industry. It is recommended that the user always determine which convention is being applied to the data she is given, and to choose the correct vertical coordinate system. (Reliance on the "term" can cause errors, since I have seen some 'subsea tvd' values given as positive downwards, as well as the more conventional positive upwards).
|
vertical coordinate system name |
reference datum |
positive ... |
|
sea level elevation |
Mean Sea Level |
upwards |
|
subsea tvd |
Mean Sea Level |
upwards |
|
tvd |
|
downwards |
|
measured depth |
|
downwards |
|
tvd from sea level |
Mean Sea Level |
downwards |
|
unknown vertical |
unknown |
downwards |
The "tvd" coordinate system, as defined by Epicentre, is hardly ever used, since it has no reference zero. Its use is generally in conjunction with a measured depth that is converted to a true vertical depth, but is not redatumed to sea level. Finally, the "measured depth" is defined as the distance as measured along a well path. Thus, it requires a well path as well as a zero reference to make sense. More will be given on measured depths in Section 3.1.9, "Using Vertical Coordinate Systems and Measured Depths".
Most databases assume often rather loosely a unit of measure for an attribute. Epicentre does not. However, Epicentre does allow the database to restrict the allowable units of measure.
The EPSG often takes advantage of this feature by restricting the allowable units of measure to a single one. For example, any coordinate system based on a UTM transformation must be in metres. (*Exception: Offshore Gulf of Mexico has four UTM-like transformations given in units of US survey feet.4) Consequently, it is imperative to know what the appropriate unit of measure is for a given coordinate system axis in a projected coordinate system.
|
Note 4: Because the resulting coordinate systems use U.S. Survey Feet, they are not strictly UTM coordinate systems and UTM coordinate transformations. To emphasize this, the transformations are labelled 'BLM…' rather than 'UTM…' |
Note that the unit is given for an axis, and not the coordinate system. An example below gives the Level Two SQL statement to find the property for an axis. The restriction in general only applies for projected coordinate systems. The property name for an axis is usually self-describing for the unit of measure. For example, the property for the 'NAD27 / Texas North easting axis' is "easting in ftUS". Thus the only legal unit of measure for eastings in the 'NAD27 / Texas North' coordinate system is US survey feet (ftUS). (* Note: A US survey foot, 'ftUS', is different from the foot, 'ft' (International foot). They differ by 2 parts per million.)
The standard coordinate systems are documented in the Epicentre Browser that comes with the POSC Version 2.0 CD. Find the list in the standard instances of Geographic_coordinate_system, Projected_coordinate_system, or Local_spatial_coordinate_system.
The coordinate system names may be found by directly querying the database. The logical queries for various sample sets of information are given below:
select identifier from all geographic_coordinate_system where source.name = 'POSC';
select identifier from all projected_coordinate_system where source.name = 'POSC';
select identifier from all projected_coordinate_system where name like 'NAD%' and source.name = 'POSC';
This command works because all the state plane coordinate system identifiers start with either NAD27 or NAD83, the geographic coordinate systems upon which these projected coordinate systems are based.
select identifier, coordinate_system_axis.ref_quantity_property.name from geographic_coordinate_system,where identifier = 'NAD27';
select geodetic_datum.identifier, identifier from geodetic_datum_alias where identifier like '%South America%';
This command will display the (two) South American geodetic datums, and their short names. In Epicentre, the shorter names where they exist are the identifiers of datums and coordinate systems. Where there is no short name, the full name is the identifier.
An alternate method to do the same thing is
select identifier, geodetic_datum_alias.identifier from geodetic_datum where geodetic_datum_alias.identifier like '%South America%';
select identifier, geodetic_datum_alias.identifier from geodetic_datum where geodetic_datum_alias.identifier is not NULL;
This command displays all the Geodetic_datum identifiers, and their aliases, where Geodetic_datum_aliases have been defined.
Having determined which coordinate system you want to use, it is important that it is referenced in the appropriate place. Generally, a coordinate system is referenced when storing a location value or when creating a grid for storing a frame. (See Section 3.1.8, "Storing Locations".)
For example, in storing a location in Alaska, you are required to give the reference to a coordinate system. When storing the value, you insert the reference to 'NAD27 / Alaska zone 4' in the coordinate system part of the location value.
In addition to specifying the coordinate system, you must also know how to give the location value. In this case, the coordinate system, 'NAD27 / Alaska zone 4', has two axes whose properties are (respectively) 'easting in ftUS', and 'northing in ftUS'. Thus, you would specify (in proper order), the easting value in units of ftUS, and the northing value in units of ftUS.
Note that you do not need to give any other information about the coordinate system to use it. In particular, you do not need to know anything about the coordinate transformation. Those values are stored in Epicentre for reference information, and do not need to be re-stored in order to use a coordinate system.5
|
Note 5: However, if a coordinate system is not in the Epicentre reference table, its name and all of its defining components should be provided so that the location is properly specified. |
Section 3.1.8, "Storing Locations" gives a complete example of storing locations in the reference coordinate systems.
Many companies have "codes" or other names for the coordinate systems that are used in Epicentre. It is useful to store these codes for later reference.
Epicentre permits the storing of codes, or "aliases," for most important geodetic objects. For example, the aliases for ellipsoids would be stored in Ellipsoid_alias. The following example stores the code, 'ASP4', which represents the Alaska State plane zone 4 coordinate system, known in Epicentre as 'NAD27 / Alaska zone 4'.
---> Begin example: Storing coordinate system alias6
|
Note 6: All examples of instances will be in Express-I format. |
ASP4 = COORDINATE_SYSTEM_ALIAS {
identifier (M) --> 'ASP4';
ref_naming_system (M,K) --> @RV_MyCompany_code;
coordinate_system(M) --> @NAD27_/_Alaska_zone_4;
(* the instance in Epicentre *)
description --> 'Code name for Epicentre NAD27 / Alaska zone 4
projected coordinate system.'; };
---> End example: Storing coordinate system alias
It is expected that only a geodesist will create a new geographic or projected coordinate system. However, it may be that a user will need to create a local spatial coordinate system.
Figure 3.1: Description of local coordinate system
As an example, consider that we choose a particular crossroad in a field J as an origin, and will set the x-axis along one road (that runs approximately northeast), and the y-axis perpendicular to this road (heading approximately northwest). All locations will be referenced to this coordinate system. See Figure 3-1.
The following assumptions apply to the Express-I instantiation for this local spatial coordinate system example:
Begin example: Local coordinate system for Field J.
(* Step 1: Create two axes. *)
axis1 = GENERAL_COORDINATE_SYSTEM_AXIS{
ref_quantity_property(M,K) --> @PRV_x;
description --> 'My local coordinate system x axis.';
source --> @RV_MyCompany;
coordinate_system <-- (@myCoord); };
axis2 = GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property(M,K) --> @PRV_y;
description --> 'My local coordinate system y axis.';
source --> @RV_MyCompany;
coordinate_system <-- (@myCoord); };
(* Step 2: Create a General_earth_surface_point as the
origin. This is the point on the road. *)
origin = GENERAL_EARTH_SURFACE_POINT{
SUBOF (vertex)
identifier(K) --> 'origin of Field J coordinate system';
ref_other_earth_point(M) --> @RV_local_coordinate_system_origin;
description --> 'Intersection of crossroads, northernmost point.'; };
(* Step 3: Create a Local_spatial_coordinate_system,
using these axes, and the origin *)
myCoord = LOCAL_SPATIAL_COORDINATE_SYSTEM{
identifier (M) --> 'Field J coordinate system';
ref_coordinate_system_constraint(M) --> @PRV_local_2d_system;
description --> 'A coordinate system developed for Field J.
This is used because we don't know the
geodetic locations, and need to express
everything in local coordinate locations.';
coordinate_system_axis --> LIST(@axis1, @axis2);
vertex --> @origin;
source --> @RV_MyCompany;};
---> End example: Local coordinate system for Field J.
Note that no location was given for the origin. Everything is referenced to this origin. However, if the origin is later located - either in a geographic or projected coordinate system, or both, a Pty_location can be created to specify its location in this geodetic system. Furthermore, later knowledge can also be used to specify a coordinate transformation that will convert the points in the local coordinate system into a projected or geographic coordinate system. Until that information is known, the points can only be located in a local sense.
In Epicentre the conversion between Geographical coordinates and Projected or grid coordinates, and the conversion of Geographical coordinates from one geodetic datum to another are both termed coordinate transformation although the forms of these transformations are totally dissimilar. See a diagram explaining the various transformations.
Generally a user would not be concerned with the mechanics of a coordinate system transformation. These are defined and their parameters are included within Epicentre. Because these are standard transformations, it is generally only required that the user know the names of the coordinate systems to be used. These are the identifiers of Epicentre. The appropriate parameter set is then secured through the identifiers and used in the transformation.
The formulas by which coordinates may be converted between a Geographic coordinate system and a projected coordinate system according to the coordinate transformation method are treated in another article. Section 3.2.3, "Projected Coordinate Systems"and Section 3.2.4, "Redatuming Transformations - Basics", give further understanding on coordinate system transformations.
However, there are occasions when the coordinate transformations that are applied to get a projected coordinate system may be of interest. These are found by querying the Applied_coordinate_transformation entity which records this information. An example is given below.
The coordinate transformation that is applied to get a projected coordinate system may be of interest. The tie among the two coordinate systems (the "to" coordinate system and the "from" coordinate system) and the coordinate transformation between them are given in the Applied_coordinate_transformation entity. The example below shows the use of this entity to determine the "to" and "from", or "source" and "target", coordinate systems, and the transformation between them.
select coordinate_transformation.identifier, source_coordinate_system.identifier, target_coordinate_system.identifier from all applied_coordinate_transformation where target_coordinate_system.identifier like '%Texas South%';
This example will display the coordinate transformation, and the source and target coordinate systems, for all coordinate systems that contain "Texas South." There are four in Epicentre: for Texas South, Texas South Central, both as applied to NAD27 and NAD83. With this information, it is now possible to gain some details on the appropriate coordinate transformation (such as Texas CS27, South zone, for example). See Section 3.3, "Advanced Usage of Coordinate Systems" for more details.
UTM is not a coordinate system. It is a set of coordinate transformations. When this is applied to a Geographic_coordinate_system, it generates a projected coordinate system. For example, UTM zone 3N applied to NAD27 will produce a projected coordinate system named 'NAD27 / UTM zone 3N' in Epicentre. Similarly, UTM zone 3N applied to NAD83 will produce a different projected coordinate system named 'NAD83 / UTM zone 3N'. Since a given point on the Earth will have a different (latitude, longitude) value in NAD27 than it has in NAD83, the (easting, northing) values in their projections will also be different.
Several widely used pairs of UTM zone projections and their geographic coordinate systems have been established in Epicentre V2.0. However, it may be necessary to apply a UTM transformation to a geographic coordinate system to form a coordinate system that has not been defined in Epicentre.
select coordinate_transformation.identifier, source_coordinate_system.identifier, target_coordinate_system.identifier from applied_coordinate_transformation where coordinate_transformation.identifier like 'UTM%';
This will display the coordinate transformation, and the source and target coordinate systems, for all coordinate transformations that start with the letters "UTM", and which cover all the standard supplied coordinate systems. If the projected coordinate system you need is not in the list, you need to create your own, as shown below.
The following example will create a projected coordinate system, 'GD49 / UTM zone 58S', from Geographic_coordinate_system, 'GD49', and Coordinate_transformation, 'UTM zone 58S'. It assumes that POSC has supplied both the Geographic_coordinate_system instance: 'GD49', and the Coordinate_transformation instance: 'UTM zone 58S'. Of course, the appropriate reference entities (@PRV_ and @RV_) are also supplied.
---> Begin example: UTM Coordinate System for GD49
(* Step 1: Create two axes. *)
axiseasting = GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property(M,K) --> @PRV_easting_in_metres;
description --> 'GD49 / UTM zone 58S easting axis';
source --> @RV_MyCompany;
coordinate_system <-- BAG(@UTM58S); };
axisnorthing = GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property(M,K) --> @PRV_northing_in_metres;
description --> 'GD49 / UTM zone 58S northing axis';
source --> @RV_MyCompany;
coordinate_system <-- BAG(@UTM58S); };
(* Step 2: Create a projected coordinate system *)
UTM58S = PROJECTED_COORDINATE_SYSTEM {
identifier(M) --> 'GD49 / UTM zone 58S';
(* concatenate geographic CS plus coordinate transformation *)
ref_coordinate_system_constraint(M) --> @PRV_projected_2d_system;
coordinate_system_axis --> LIST (@axiseasting, @axisnorthing);
source --> @RV_MyCompany;
target_for <-- SET (@applytrans); };
(* Step 3: Tie together all parts with
Applied_coordinate_transformation *)
applytrans = APPLIED_COORDINATE_TRANSFORMATION {
coordinate_transformation(M,K) --> @PRV_UTM_zone_58S;
(* a standard, already loaded and defined, transformation *)
source_coordinate_system(M,K) --> @PRV_GD49;
(* a standard, already loaded and defined,
geographic_coordinate_system. *)
target_coordinate_system(M,K) --> @UTM58S;
(* the just created projected_coordinate _system *)
source (M) --> @RV_MyCompany; };
---> End of Example: UTM Coordinate System for GD49.
A location consists of the following:
A reference to an instance of a coordinate system
The units must also correspond properly. Both the latitude and the longitude are of property type 'plane angle'. There is a reference entity, Ref_quantity_type, that gives a set of units that are allowed for property type 'plane angle'. They are: radians, degrees, minutes, seconds, gons, and grads. If you try to store a value with units of metres, the database will not allow it.
As another example, the Projected_coordinate_system, 'NAD27 / Florida East', has axes of 'easting in ftUS', and 'northing in ftUS'. It is required that you must give first the easting value, and then the northing value. Both 'easting in ftUS' and 'northing in ftUS' allow only a single unit - 'ftUS' = US Survey feet. Not allowed would be m (metres) or ft (international feet). Only US survey feet is allowed.
Consider a well (Jones/Hawking #2) located in Louisiana at latitude 29.63448 N, longitude 90.17756 W. In State Plane coordinates, it would be "NAD27 / Louisiana South", and would be located at (easting, northing) = (2366873 ftUS, 415020 ftUS). This example also indicates that its elevation would be 88 ft above sea level (ground level). For the elevation, the 'sea level elevation' coordinate system will be used.
Note that three locations will be given to this well: the (latitude, longitude) surface location, the (easting, northing) surface location, and the elevation.
-> Begin example: Jones/Hawking #2 locations
(* Step 1: Store the well, with its name, if not already stored. *)
JH2 = well {
identifier(M,K) --> 'Jones/Hawking #2';
ref_naming_system --> @PRV_lease_name;
(* a common name associated with the lease the well is on *)
ref_existence_kind(M,K) --> @PRV_actual;
ref_well_structure_rule --> @PRV_simplex;
well_surface_point <-- @surf_loc; };
(* Step 2: Identify a surface location vertex - where the well is *)
surf_loc = well_surface_point {
well(M,K) --> @JH2;
pty_location_1d <-- SET(@elev);
pty_location_2d <-- SET(@latlong, @eastnorth); };
(* Step 3: Give the various locations *)
(* Note that we are using existing coordinate systems,
and using the default origin of the coordinate system.
So we only have to point to the instance of the coordinate
system and do not use the optional vertex. *)
elev = PTY_LOCATION_1D {
well_surface_point(K) --> @surf_loc;
data_value(M) -> LOCATION {
coordinate_system(M)-> @PRV_sea_level_elevation;
coordinates(M) --> LIST ( 88. );
ref_unit_of_measure (M) --> LIST ( @PRV_ft );
}; };
latlong = PTY_LOCATION_2D {
well_surface_point(K) --> @surf_loc;
data_value(M) -->LOCATION {
coordinate_system(M) --> @PRV_NAD27;
coordinates(M) --> LIST (29.63448, -90.17756);
(* note: W long is negative *)
ref_unit_of_measure(M) --> LIST (@PRV_dega, @PRV_dega);
(* dega = angular degrees *)
}; };
eastnorth = pty_location_2d {
well_surface_point (K) --> @surf_loc;
data_value(M) --> LOCATION {
coordinate_system(M) --> @PRV_NAD27_/_Louisiana_South;
coordinates(M) --> LIST(2366873, 415020);
ref_unit_of_measure(M) --> LIST (@PRV_ftUS, @PRV_ftUS);
}; };
-> End example: Jones/Hawkins #2 well locations.
Measured depths are distances measured along a wellbore path. The distances are measured from a reference point - usually the kelly bushing - but often some other reference point such as the rotary table, ground level, derrick floor, or, occasionally, sea level. In order for a measured depth to make sense, you must know both the wellbore path and the reference point.
An important principle in Epicentre is that points in different coordinate systems cannot be directly compared; additional information must be known. This principle is also true with measured depths. For example, a point in one wellbore cannot be compared with a point in another wellbore unless it is known that both wells are nearly vertical, or, more accurately, if the conversion (i.e., transformation) of the values to true vertical depth are known. For this reason, we make the primary recommendation that each wellbore have its own measured depth coordinate system. That principle can be compromised in some cases, as will be explained shortly.
Consider an example with two wells, one nearly vertical, and the other, horizontal. Also, consider a point at measured depth 11,000 ft in the horizontal well, and another at 10,000 ft in the nearly vertical well. Even if their reference datums are the same, one cannot make any meaningful statement about which point is deeper. The principle is that we cannot compare these values unless we put them into a common coordinate system-for example,' subsea tvd'. Then we can ask comparison questions such as, "Which one is deeper?"
POSC recommends two approaches for using measured depths. For wells that you want to "work with," we recommend that each wellbore has its own measured depth coordinate system. Examples of how to create one and how to use it will be given below. However, there will be thousands, if not millions, of wells which you will not work with. For these, you may only want to record a fact like "this measurement is a measured depth with reference kelly bushing." An example in Section 3.1.9.4, "Using the Standard Measured Depth Coordinate System" shows how this is done.
Assume that the well (Jones/Hawkins #2 from section 2.8.1) has already been stored. This example will store a wellbore, '00', its reference datum (assumed to be the kelly bushing), and create a measured depth coordinate system. In creating the coordinate system, the kelly bushing "point" will be used as the origin or the coordinate system.
-> Begin example: Jones/Hawkins #2, 00, md coordinate system.
wb = WELLBORE {
identifier(M,K) --> '00';
ref_naming_system --> @PRV_two_digit_API;
ref_existence_kind(M,K) --> @PRV_actual ;
well(M,K) --> @JH2; (* from section 7.1 example *)
create_wellbore_position <-- SET(@kb); };
(* Step 1: create a wellbore point - for this
example, of type 'kelly bushing' *)
kbref = KELLY_BUSHING_REFERENCE {
(* other subtype, if appropriate *)
ref_existence_kind(M,K) --> @PRV_actual;
wellbore (M,K) --> @wb;
position_in_wellbore <-- SET(@kb ); };
kb = GENERAL_WELLBORE_POINT {
SUBOF (POSITION_IN_WELLBORE)
identifier(K) --> 'Elevation Reference';
wellbore(M,K) --> @wb;
wellbore_component_facility --> @kbref;
description --> 'The kelly bushing, to be used as a
reference datum for measured depth measurements
in this wellbore.';
ref_wellbore_point --> @PRV_kelly_bushing; };
(* Step 2: create an axis for the md coordinate system *)
mdaxis = MEASURED_DEPTH_SYSTEM_AXIS {
SUBOF (COORDINATE_SYSTEM_AXIS)
ref_quantity_property(M,K) --> @PRV_measured_depth;
source --> @RV_MyCompany;
coordinate_system(K) <-- (@mdcoord); };
(* Step 3: create the coordinate system *)
mdcoord = LOCAL_SPATIAL_COORDINATE_SYSTEM{
SUBOF (COORDINATE_SYSTEM)
identifier(M) --> 'Jones/Hawkins #2, 00 md';
ref_coordinate_system_constraint(M) --> @PRV_measured_depth_system;
coordinate_system_axis --> LIST (@mdaxis);
source(M) --> @RV_MyCompany;
vertex --> @kb; };
(* this specifies that the KB is the origin of the coord system *)
-> End example: Jones/Hawkins #2, 00, md coordinate system.
Sample problem continued: The Jones/Hawkins well/wellbore above has a marker pick, Top of Anumu Formation, at a measured depth of 8546 ft. We need to create a wellbore point corresponding to the Top of the Anumu, and then give its location with a pty_location.
-> Begin example: Top of Anumu measured depth
(* Step 1: Create the vertex which will have the measured depth value *)
top_anumu = GENERAL_WELLBORE_POINT {
SUBOF (WELLBORE_POINT)
identifier(M) --> 'Top Anumu';
(* note. This identifier has to be unique within a wellbore.
In general, it is bad to use "Anumu" as part of this
identifier. There will be a relationship to a geologic_feature
--the Anumu boundary - which will give this information. But
to keep this example simple, I will use this as the identifier *)
wellbore(M,K) --> @wb; (* from example in section 1.9.1)
ref_wellbore_point --> @PRV_geologic_pick;
pty_location_1d <-- SET (@md_top_anumu); };
(* Step 2: Give the value in a pty_location *)
md_top_anumu = PTY_LOCATION_1D {
wellbore_point(K) --> @top_anumu;
data_value(M) --> LOCATION {
coordinate_system(M) --> @mdcoord; (* created in example above *)
coordinates(M) --> LIST (8546.) ;
ref_unit_of_measure (M) -->LIST (@PRV_ft); };
}; };
-> End example: Top of Anumu measured depth
Sample problem continued: Assume that the point in the example above has a subsea tvd of -8215 ft. Note that the subsea tvd is given as a negative value. This is an oft followed, but not universal convention.
For this example, we can use the already created vertical coordinate system, 'subsea tvd', as identified in Section 3.1.2.5, "Vertical Coordinate Systems". The only step here is to give the pty_location, and have it reference the wellbore point created above, and the coordinate system already created.
-> Begin example: Top of Anumu, subsea tvd.
tvd_top_anumu = PTY_LOCATION_1D {
wellbore_point(K) --> @top_anumu;
(* from example in section 1.9.2 *)
data_value(M) --> LOCATION{
coordinate_system(M) --> @PRV_subsea_tvd;
coordinates(M) --> LIST (-8215 );
ref_unit_of_measure(M) --> ( @PRV_ft); };
}; };
-> End example: Top of Anumu, subsea tvd.
When data is to be stored, but the well is not to be "worked" extensively, it may be possible to use the standard 'measured depth' coordinate system (see Section 3.1.2.5, "Vertical Coordinate Systems") rather than create a coordinate system for every wellbore. This might be a useful approach when a scout ticket is received, and it gives "tops."
Using this measured depth coordinate system violates the principle that points in the same coordinate system can be compared. Unless there is outside information (for example, all the wells are nearly vertical), these measured depths cannot be compared. But with that understanding, it is possible to store measured depth values in this coordinate system.
Recall that the information needed for a measured depth value to make sense includes both the wellbore and the reference datum. Since we will be creating a Wellbore_point which is in a wellbore, the wellbore will be known. But the reference datum needs to be explicitly given. This will be done by creating a wellbore point as the elevation reference. It will have a Ref_wellbore_point value that is appropriate; e.g., "kelly bushing", "ground level", etc. For this example, assume it is the "rotary table". The data_value from the Pty_location_1d will contain a reference to this point8. This reference has not been used in previous examples - it is optional. Its meaning is that it represents the "origin" to be used for this particular value. It is a convenient way of shifting the origin of a general coordinate system without having to create a new coordinate system with a different origin.
|
Note 7: In the previous example, the reference datum was stored with the coordinate system. In this example, it is stored with the data values. |
Sample problem: Assume there are two tops with measured depths: Top of Anumu, 8116 ft; Top of Ratchet, 8244 ft. Both are referenced to 'rotary table'. The well is API number 123456789000.
-> Begin example: Using the standard measured depth coordinate system
(* Step 1: Create the well and wellbore, if not already done *)
well1 = WELL {
identifier(M,K) --> '1234567890';
ref_naming_system --> @PRV_API;
ref_existence_kind(M,K) --> @PRV_actual;
wellbore <-- SET (@wellbore); };
wellbore1 = WELLBORE {
identifier(M,K) --> '00';
ref_naming_system --> @PRV_two_digit_API;
ref_existence_kind(M,K) --> @PRV_actual;
well(M,K) --> @well1;
position_in_wellbore <--SET (@rt, @scout_top_anumu, @scout_top_ratchet); };
(* Step 2: Create the reference elevation point in the wellbore *)
rt = GENERAL_WELLBORE_POINT {
identifier(K) --> 'Elevation reference';
wellbore(M,K) --> @wellbore1;
ref_wellbore_point --> @PRV_rotary_table;
description --> 'This point is the elevation reference point
from the scout ticket for the top of the anumu
and the top of the ratchet.'; };
(Step 3: Create the two wellbore points that are tops *)
scout_top_anumu = GENERAL_WELLBORE_POINT {
SUBOF (WELLBORE_POINT)
identifier(K) --> 'Top Anumu';
wellbore(M,K) --> @wellbore1;
ref_wellbore_point --> @PRV_geologic_pick;
pty_location_1d <-- SET (@md_scout_top_anumu); };
scout_top_ratchet = GENERAL_WELLBORE_POINT {
SUBOF (WELLBORE_POINT)
identifier(K) --> 'Top Ratchet';
wellbore(M,K) --> @wellbore1;
ref_wellbore_point --> @PRV_geologic pick;
pty_location_1d <-- SET (@md_scout_top_ratchet); };
(* Step 4: Give the values in a pty_location *)
md_scout_top_anumu = PTY_LOCATION_1D {
wellbore_point(K) --> @scout_top_anumu;
data_value(M) --> LOCATION {
coordinate_system(M) --> @PRV_measured_depth;
vertex --> @rt; (* elevation reference created above *);
coordinates(M) --> LIST(8116.) ;
ref_unit_of_measure(M) --> (@PRV_ft); }; };
md_scout_top_ratchet = PTY_LOCATION_1D {
wellbore_point(K) --> @scout_top_ratchet;
data_value(M) --> LOCATION {
coordinate_system(M) --> @PRV_measured_depth;
vertex --> @rt; (* elevation reference created above *);
coordinates(M) --> LIST(8244.) ;
ref_unit_of_measure(M) --> (@PRV_ft); }; };
-> End example: Using the standard measured depth coordinate system