|
POSC Specifications Version 2.2 |
Epicentre Usage Guide Advanced Usage of Coordinate Systems |
[Coordinate System Table of Contents]
The description of basic usage in Section 3.1 primarily dealt with using coordinate systems. For the basic issues, there was no need to understand the coordinate system model beyond a few simple queries to access the data.
This section is designed for those who must create coordinate systems, and to document coordinate transformations between the coordinate systems.
The first part documents the entities necessary to store two types of the standard coordinate systems. In particular, it will document the storage of the geographic_coordinate_system, 'NAD27', and the projected_coordinate_system, 'NAD27 / Texas South Cen.' Then the coordinate transformation between these coordinate systems will be documented. This section should serve as a pattern for the instantiation of new coordinate systems and their transformations.
The last part gives an example of a transformation between geographic_coordinate_systems, of the Bursa-Wolf or Molodensky type. This transformation is given, for example, in UKOOA data, and it is important to know how to record and retrieve the transformation.
It should be noted that Section 3.4, "Projections and Projected Coordinate System formulas" and Section 3.5, "Geographic Coordinate System Transformations" can be used to get an understanding of transformations. Those documents also document the transformations covered in the standard data supplied by POSC, and define the parameters and transformation equations.
A geographic_coordinate_system is a latitude/ longitude coordinate system that measures locations on the surface of the Earth. The example of 'NAD27' will be used in this explanation. Epicentre puts together the parts of a geographic_coordinate_system as follows:
An ellipsoid is chosen - 'Clarke 1866'. The parameters of the ellipsoid are recorded in the Epicentre entity, ellipsoid. The ellipsoid is "attached" to the Earth. This is done through the Epicentre entity, geodetic_datum. This entity does not give any details of the datum. The only information stored is the name and the ellipsoid that is part of the datum. The datum name for our example is 'North American Datum 1927', or, for short, 'NAD27'.
The origin of the longitudes is given by specifying the prime meridian. For our example, the prime meridian is 'Greenwich'. This is stored in the Epicentre entity, prime_meridian. The information recorded is the name of the prime_meridian and its offset from the Greenwich meridian.
The final piece of information is that the axes will be latitude and longitude. All of these parts are "pulled" together by the entity, geographic_coordinate_system. This entity records a name, and ties together the above pieces of information about the coordinate system through relationships. See Section 3.3.2, "Forming a Geographic_coordinate_system".
It should be noted that Epicentre has an "extra piece" of information in the view of many geodesists. In particular, most geodesists identify the geodetic datum as the coordinate system. This view will apply to 95% of the standard coordinate systems. It applies, because there is one geographic_coordinate_system for each geodetic_datum.
But the few exceptions force the separation as seen in Epicentre. An example of the need for this is the Bogota datum. Colombia is a country that specifies the use of the Bogota prime meridian. Because of this specification, there are, in the Epicentre view, two coordinate systems associated with the Bogota datum. One is the coordinate system using Bogota as the prime meridian, the other is the coordinate system using Greenwich as the prime meridian.
The geographic_coordinate_system is defined on an ellipsoid. It is often necessary to work with maps on a planar surface. To do this, the latitude/ longitude values are "projected" onto a plane. The resulting values are coordinates in a projected_coordinate_system.
In the view of Epicentre, a projected_coordinate_system is nothing more than two axes (which are labelled as 'easting' and 'northing'). Thus it would be possible to form a projected_coordinate_system, 'Texas South Central', with an easting and a northing axis, and no other information. (See Section 3.3.3, "Forming a projected coordinate system")
A geodesists view is much stronger. In this view, there is always an associated transformation that converts an (latitude, longitude) into an (easting, northing).
But even this is not a full specification of the projection. It is also necessary to give the "from" coordinate system. That is, it is necessary to specify the geographic_coordinate_system that is supplying the latitudes and longitudes.
This information is pulled together by an Epicentre entity called applied_coordinate_transformation. This entity ties together the source coordinate system, the target coordinate system, and the transformation between them. (See Section 3.3.4.3, "Tying them all together".)
Most projections are defined for a single "source" and a single "target" coordinate system. Thus it is often the practice to give the same name to the transformation as to the target coordinate system (the term projection zone is often used). This identifies the projection transformation closely with the projected_coordinate_system. However, there are a number of cases where the same transformation is applied to different source coordinate systems. In the Epicentre view, this produces separate coordinate systems. Chief examples of this behavior are the use of UTM transformations with many different source coordinate systems. Another example would be the Australian map grid zones which apply both to the Australian Geodetic Datum 1966 and the Australian Geodetic Datum 1984.
Since this behavior is present, it has been decided that the target coordinate system name should represent not only the projection zone, but also the source coordinate system. In our example, the source coordinate system is 'NAD27', the target coordinate system is 'NAD27 / Texas South Cen.', and the coordinate transformation is 'Texas CS27 South Central zone'.
As explained above, Epicentre views the coordinate transformation as an entity of its own that can exist independent of any coordinate system. Thus, it is possible to define, for example, the UTM zones without specifying a particular geodetic datum. The transformation can then be applied to any geodetic datum within its area of applicability.
In most cases there is a single, tight relationship among the three entities. For example, the Lo19 projection zone is applied only to the Arc 1950 geographic_coordinate_system (datum), and produces the single projected_coordinate_system, 'Arc 1950 / Lo19', which is used in Southern Africa. The applied_coordinate_transformation would tie these three entities together. The coordinate_transformation would have only a single relationship to applied_coordinate_transformation.
A coordinate_transformation is defined by two parts. One part is the pattern and the other is a specific transformation. The pattern would describe the transformation method (see Section 3.3.4.1, "Storing the Coordinate Transformation Method") and the set of parameters that is appropriate for the method (see Section 3.4.3, "Projected coordinate system parameters"). The specific transformation would then be a named transformation zone, and the specific parameter values for that transformation (see Section 3.3.4.2, "Storing a particular coordinate transformation").
Using our example, there is a type of transformation called a Lambert Conic Conformal with Two Standard Parallels. This method is defined to have 7 parameters, one of which, for example, is the Longitude of Origin. This pattern applies to any transformation of this type.
To deal with the specific case of 'Texas CS27 South Central zone', we would identify this transformation of the type, Lambert Conic Conformal with Two Standard Parallels. We would then specify the seven parameter values. For example, the Longitude of Origin would be set to 99 deg W.
The transformation types and their parameter sets are documented in Section 3.4, "Projections and Projected Coordinate System formulas".
Express-I is used in the following examples to document the instance storage
The Express-I given in this chapter is not complete. In particular, the documentation assumes that particular reference values exist. These will be referenced by giving enough information to allow a select statement to find the instance.
The following information is necessary to instantiate a geographic_coordinate_system.
Geodetic Datum NAD27 These are all standard instances in the Epicentre data base. It is necessary only to select these. Note that 'NAD27' is an abbreviation for North American Datum 1927. The EPSG (European Petroleum Surveyor's Group) recommended the use of the abbreviation for this and many other geodetic datums. POSC is following that practice. The full name is recorded as a geodetic_datum_alias.
---> Begin example: Storing Geographic coordinate system
PRV_Clarke_1866 = ELLIPSOID {
identifier (M) --> 'Clarke 1866';
semimajor_axis --> QUANTITY {
value --> 6378206.4;
ref_unit_of_measure --> @PRV_m; };
semiminor_axis --> QUANTITY {
value --> 6356583.8;
ref_unit_of_measure --> @PRV_m; };
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
(* this ellipsoid is defined with semimajor_axis and
semiminor_axis. Most ellipsoids are defined with
semimajor_axis and inverse_flattening. Inverse_flattening
would be ndt_real value with no units *)
PRV_Greenwich = PRIME_MERIDIAN {
identifier (M) --> 'Greenwich';
greenwich_longitude --> ANGLE_QUANTITY{ -- ndt_plane_angle
value --> 0.0
ref_unit_of_measure --> @PRV_dega; };
description --> 'Longitude: 0 degree 00 minute 00.000 second';
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
PRV_gd_NAD27 --> GEODETIC_DATUM {
identifier --> 'NAD27';
ellipsoid --> @PRV_Clarke_1866;
ref_naming_system --> @PRV_EPSG_preferred_name;
description --> 'Fundamental Point: Meade's Ranch.
Latitude: 39Deg 13 Min 26.686 Sec N.
Longitude: 98 Deg 32Min 30.506 Sec W (of Greenwich)';
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
(* Now it is necessary to create two axes - one
which will be latitude, the other longitude *)
lat = GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property --> @PRV_latitude;
source --> @PRV_POSC;
description --> 'NAD27 latitude'; };
long = GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property --> @PRV_longitude;
source --> @PRV_POSC;
description --> 'NAD27 longitude'; };
(* Tie all of these together into a coordinate system *)
PRV_NAD27 = GEOGRAPHIC_COORDINATE_SYSTEM {
identifier (M) --> 'NAD27';
geodetic_datum --> @PRV_gd_NAD27;
prime_meridian --> @PRV_Greenwich;
ref_coordinate_system_constraint(M) --> @PRV_geographic_2d_system;
coordinate_system_axis -->LIST ( @lat, @long );
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
(* For completeness, the geodetic_datum_alias: *)
gd_full = GEODETIC_DATUM_ALIAS {
identifier --> 'North American Datum 1927';
geodetic_datum --> @PRV_gd_NAD27; };
---> End example: Storing Geographic coordinate system
The Epicentre view of a projected coordinate system is not a complete geodetic specification. In order to completely specify the coordinate system, it will be necessary to give the coordinate transformation type, the coordinate transformation values, and the source (from) coordinate system. This is provided in Section 3.4, "Projections and Projected Coordinate System formulas".
To satisfy the Epicentre view, all that is needed is the name and the axes.
In forming the name of the projected coordinate system, the EPSG has included the source coordinate system. This is for naming convenience. Without including this name, there were conflicts in coordinate system name. Even though the source coordinate system is included in the name, it is not a good practice to count on parsing the coordinate system name to determine this information.
The axes of the coordinate system are called 'easting' and 'northing.' The terms 'x', and 'y' are often used loosely in the field. These can be ambiguous. In general, 'easting' corresponds to 'x', and 'northing' corresponds to 'y'. But there are enough exceptions to this rule to make the practice suspect. The terms easting and northing, however, are unambiguous.
Also, it should be noted that the axes generally carry a single unit of measure. This is often determined by statute. In order to honor these requirements, Epicentre has created properties for easting and northing that are restricted to the single unit of measure. For our example, the unit of measure is US Survey Feet, and the corresponding properties will be 'easting in ftUS', and 'northing in ftUS'.
---> Begin example: Storing Projected coordinate system
(* Create two axes - one which will be
easting, the other northing *)
east = GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property --> @PRV_easting_in_ftUS;
source --> @PRV_POSC;
description --> 'NAD27 / Texas South Cen. easting'; };
north= GENERAL_COORDINATE_SYSTEM_AXIS {
ref_quantity_property --> @PRV_northing_in_ftUS;
source --> @PRV_POSC;
description --> 'NAD27 / Texas South Cen. northing'; };
(* Tie all of these together into a coordinate system *)
PRV_NAD27_/_Texas_South_Cen. = PROJECTED_COORDINATE_SYSTEM {
identifier (M) --> 'NAD27 / Texas South Cen.';
ref_coordinate_system_constraint(M) --> @PRV_projected_2d_system;
coordinate_system_axis --> LIST ( @east, @north);
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
---> End example: Storing Projected coordinate system
There will be three steps in storing a coordinate transformation. The first will be to store the method. See Section 3.3.4.1, "Storing the Coordinate Transformation Method". This includes storing the method name and the set of parameters that go with the method. The documentation on Coordinate Transformations gives the set of equations that use the method and the set of parameters. In our example, the method will be a Lambert Conic Conformal with two standard parallels. There are seven parameters that go with that method.
The second step will be to store the particular transformation of interest. See Section 3.3.4.2, "Storing a particular coordinate transformation". This will include a name for the transformation, and values for the parameters. In our example, the transformation will be named 'Texas CS27 South Central zone', and the seven parameter values are:
The third step will be to tie this particular coordinate transformation to the two coordinate systems. See Section 3.3.4.3, "Tying them all together". The source coordinate system will be the geographic_coordinate_system, 'NAD27', and the target coordinate system will be the projected_coordinate_system, 'NAD27 / Texas South Cen.'.
---> Begin example: Storing coordinate transformation methods
PRV_mapproj = REF_COORDINATE_TRANSFORMATION {
kind (M) --> 'map projection';
description --> 'A transformation that converts points on
a graticular surface to points on a plane.
The same set of parameters defines the inverse mapping.';
source (M) --> @PRV_POSC; };
PRV_Lambert_Conic_Conformal_(2SP) = COORDINATE_TRANSFORMATION_METHOD {
ref_coordinate_transformation (M) --> @PRV_mapproj;
identifier (M) --> 'Lambert Conic Conformal (2SP)';
description --> 'A transformation between geographic and
projected coordinate systems, which conformally
maps an ellipsoid onto a cone whose central axis
coincides with the polar axis. The method uses
two standard parallels.';
source (M) --> @PRV_POSC; };
(* below is one of the seven parameters that need to be instantiated.
In Epicentre, there are 52 parameters to select from. *)
PRV_longitude_of_origin = REF_COORDINATE_TRANSFORMATION_PARAMETER {
name --> 'longitude of origin';
description --> 'The longitude of the projection origin. The
projection origin is the point of definition of an
orthogonal grid constructed on a map projection. Where
the longitude of false origin is not given as a parameter,
the grid coordinate value corresponding to the longitude
of origin is defined by the false easting.';
ref_parameter_attribute --> @PRV_location;
source (M) --> @PRV_POSC; };
(* Of the 52 parameters to select from in Epicentre, the appropriate
7 will be chosen. This next entity will tie these seven to the method,
Lambert Conic Conformal (2SP) *)
PRV_longitude_of_origin_lcc2 = COORDINATE_TRANSFORMATION_PARAMETER {
ref_coordinate_transformation_parameter (M) --> @PRVlongitude_of_origin;
coordinate_transformation_method (M) --> @PRV_Lambert_Conic_Conformal_(2SP);
source (M) --> @PRV_POSC; };
PRV_latitude_of_first_standard_parallel_lcc2 = COORDINATE_TRANSFORMATION_PARAMETER {
ref_coordinate_transformation_parameter (M) --> @PRV_longitude_of_first_standard_parallel;
coordinate_transformation_method (M) --> @PRV_Lambert_Conic_Conformal_(2SP);
source (M) --> @PRV_POSC; };
(* The above two entities are repeated five more times for the other parameters *)
-> End example: Storing coordinate transformation methods.
The above section will probably not be necessary, since the major coordinate transformation methods have been stored. However, the methods in this section will be needed quite often, even though most projection zones are included in the standard instances. It is still incumbent upon the user to insure that the particular transformation that was applied to the data agrees with the standard method both as method type and with the appropriate set of parameter values.
This section deals with the projection transformation. A later section will demonstrate how to store other types of transformation methods. In particular, it will deal with redatuming transformations, such as Bursa-Wolf, and affine transformations.
---> Begin example: Storing coordinate transformation values
(* Begin by identifying the particular method, then store the values for the method *)
PRV_Texas_CS27,_South_Central_zone = COORDINATE_TRANSFORMATION {
identifier (M) --> 'Texas CS27, South Central zone';
coordinate_transformation_method --> @PRV_Lambert_Conic_Conformal_(2SP);
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
(* the parameter, latitude of origin *)
PRV_ctv_longitude_of_origin = COORDINATE_TRANSFORMATION_VALUE {
coordinate_transformation (M) --> @PRV_Texas_CS27,_South_Central_zone;
coordinate_transformation_parameter (M) --> @PRV_longitude_of_origin_lcc2;
location_value --> LOCATION {
coordinate_system --> @PRV_greenwich;
value --> ( -99.00000000 )
ref_unit_of_measure --> ( @PRV_dega); }; -- 99 deg W longitude
source (M) --> @PRV_POSC; };
(* And the parameter, latitude of first standard parallel... *)
PRV_ctv_latitude_of_first_standard_parallel = COORDINATE_TRANSFORMATION_VALUE {
coordinate_transformation (M) --> @PRV_Texas_CS27,_South_Central_zone;
coordinate_transformation_parameter (M) --> @PRV_latitude_of_first_standard_parallel_lcc2;
quantity_value --> QUANTITY{
value --> 28.383333333;
ref_unit_of_measure --> @PRV_dega; };
source (M) --> @PRV_POSC; };
(* Continue for the other five entities. *)
(* Note that the longitudes are of type location, because
they need to define the origin. The other values are all
of type quantity (value and unit of measure) *)
---> End example: Storing coordinate transformation values.
The three parts are constructed: the source coordinate system (NAD27), the target coordinate system (NAD27 / Texas South Cen.), and the coordinate transformation between them (Texas CS27, South Central zone). The final step is to tie them together. This is done using the applied_coordinate_transformation entity.
Note that this entity specifically differentiates between the source and target coordinate systems. For some transformations - the Lambert Conic Conformal being one - this differentiation is not important. This is because the method and the set of parameters define two transformations - one which will convert (latitude, longitude) into (easting, northing), and the other which will convert (easting, northing) into (latitude, longitude). In other cases, though, it is critical that the source and target (the "from" and "to") coordinate systems be identified. The affine transformation and the Bursa-Wolf transformation are examples.
---> Begin example: Applying the coordinate transformation.
PRV_apply = APPLIED_COORDINATE_TRANSFORMATION {
source_coordinate_system (M) --> @PRV_NAD27;
target_coordinate_system (M) --> @PRV_NAD27_/_Texas_South_Cen.;
coordinate_transformation (M) --> @PRV_Texas_CS27,_South_Central_zone;
source (M) --> @PRV_POSC;
source_reference --> @PRV_EPSG; };
---> End example: Applying the coordinate transformation.
Redatuming is a transformation from one geographic_coordinate_system to another. In its simplest form, it involves a shift (DX,DY,DZ) of the geocentric coordinates (these being the only three parameters)2. A more complex form adds the possibility of rescaling and of axes rotations. This more complete method will be the one demonstrated, the first being subsumed into the second (zero rescaling, zero rotations). Note that it is critical for these transformations that the source and target coordinate systems be identified. See Section 3.5, "Geographic Coordinate System Transformations".
|
Note 2: Of course the input and output data are latitude, longitude, and, possibly, elevation. The parameters, however, are for cartesian coordinates. The transformation between ellipsoid coordinates and cartesian coordinates is built into the method. |
There are two transformation methods involved. Actually, there are two ways of looking at the same method. Because of these different views, the literature (of applying the method) has differing ways to distinguish the views. Epicentre is taking the approach of considering them two different transformation methods.
The two views depend on how you view a rotation about an axis. Consider a point on an (x,y) graph. Rotate the axes a little, and consider the same point in this new coordinate system. A little thought will show that a rotation of the axes in one direction "looks like" a rotation of the point in the other direction. Both views - coordinate axis rotation and point vector rotation - are valid, and both views are used. However, it is necessary to apply the view consistently, and to identify which view you are taking.
Epicentre's answer is to identify the "point vector rotation" view with a transformation type, Bursa-Wolf. The other view is identified with the transformation type, coordinate frame rotation. Thus, by picking between these methods, you are choosing the view that is used.
Section 3.5, "Geographic Coordinate System Transformations" documents the mathematics involved in a datum shift from WGS84 to ED50 (using the International 1924 ellipsoid). This section will demonstrate how that transformation is documented in Epicentre. Note that this specific transformation is not presently included in the standard instances, although the Bursa-Wolf method is included.
As with the previous coordinate transformation example, there are three parts to recording a coordinate transformation, all of which are shown in the example below.
---> Begin example: Storing Bursa-Wolf example
(* Everything below is a documentation of what is
recorded in standard instances until the part that
stores the COORDINATE_TRANSFORMATION *)
PRV_affine = REF_COORDINATE_TRANSFORMATION {
kind (M) --> 'affine';
description --> 'A transformation defined by a linear
transformation plus a translation.';
source (M) --> @PRV_POSC; };
PRV_Bursa_Wolf = COORDINATE_TRANSFORMATION_METHOD {
ref_coordinate_transformation (M) --> @PRV_affine;
identifier (M) --> 'Bursa-Wolf';
description --> 'A 3-dimensional affine transformation between
geocentric coordinate systems. The rotations view the
difference between the point in the new coordinate
system vs. the same point in the old system. See also
coordinate frame rotation.';
source (M) --> @PRV_POSC; };
(* below is one of the seven parameters that need to be instantiated.
In Epicentre, there are 52 parameters to select from. *)
PRV_rotation_z = REF_COORDINATE_TRANSFORMATION_PARAMETER {
name --> 'rotation z';
description --> 'In an orthogonal (or affine) transformation, the
rotation about the z (third) axis as viewed from the
origin looking along the axis. The particular method
defines which direction is positive, and what is being
rotated (point or axis).';
ref_parameter_attribute --> @PRV_any_quantity;
source (M) --> @PRV_POSC; };
(* Of the 52 parameters to select from in Epicentre, the appropriate 7
will be chosen. This next entity will tie these seven to the method, Bursa-Wolf *)
PRV_Bursa-Wolf_rotation_z = COORDINATE_TRANSFORMATION_PARAMETER {
ref_coordinate_transformation_parameter (M) --> @PRV_rotation_z;
coordinate_transformation_method (M) --> @PRV_Bursa_Wolf;
source (M) --> @PRV_POSC; };
(* The above entity is repeated six more times for the other parameters *)
(* Now identify the particular method and its parameters. This begins
the information that is NOT stored as standard instances.*)
wgs84toed50 = COORDINATE_TRANSFORMATION {
identifier (M) --> 'BW: WGS84 - ED50';
coordinate_transformation_method --> @PRV_Bursa_Wolf;
source (M) --> @RV_myIdentifier; };
(* the parameter, rotation z*)
parrotz= COORDINATE_TRANSFORMATION_VALUE {
coordinate_transformation (M) --> @wgs84toed50;
coordinate_transformation_parameter (M) --> @PRV_Bursa-Wolf_rotation_z;
quantity_value --> QUANTITY{
value -->.156
ref_unit_of_measure --> @PRV_seca;};
source (M) --> @RV_myIdentifier; };
(* And the other parameters in a similar manner*)
(* Now tie the transformation to the coordinate system *)
applyWGS84toED50 = APPLIED_COORDINATE_TRANSFORMATION {
source_coordinate_system (M) --> @PRV_WGS84;
target_coordinate_system (M) --> @PRV_ED50;
coordinate_transformation (M) --> @wgs84toed50;
source (M) --> @RV_myIdentifier; };
---> End example: Bursa-Wolf example.
Following are sample sql queries to access various information about the coordinate transformations.
To find all the coordinate_transformation_methods that are stored:
select identifier from all coordinate_transformation_method;
To find all the coordinate_transformation_methods of type affine:
select identifier from all coordinate_transformation_method where ref_coordinate_transformation.kind = 'affine';
To find all parameters, and descriptions for the Bursa_Wolf method:
select ref_coordinate_transformation_parameter.name, description from all coordinate_transformation_parameter where coordinate_transformation_method.identifier = 'Bursa-Wolf';
To find all the coordinate transformations of type Lambert Conic Conformal (2SP)
select identifier from all coordinate_transformation where coordinate_transformation_method.identifier = 'Lambert Conic Conformal (2SP)';
To find all the coordinate transformations with 'Texas' in their name:
select identifier from all coordinate_transformation where identifier like '%Texas%';
To find the parameter values for the coordinate transformation, 'Texas CS27, South Central zone':
select coordinate_transformation_parameter.ref_coordinate_ transformation_parameter.name, quantity_value, location_value from all coordinate_transformation_value where coordinate_transformation.identifier = 'Texas CS27, South Central zone';
Note that this last query may differ between implementations for the following reasons: 1) The query asks for both quantity_value and location_value. One of these is NULL for each parameter value. The return will depend on how the implementation handles the NULL values. 2) The location value and the quantity value are both complex data types. The implementation may require special calls to "break into" the data types to return their pieces of information.