1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
w<html>
<head>
<title>PROJ.4 - General Parameters</title>
</head>
<body BGCOLOR="#FFFFFF">
<h1>PROJ.4 - General Parameters</h1>
This document attempts to describe a variety of the PROJ.4 parameters
which can be applied to all, or many coordinate system definitions. This
document does not attempt to describe the parameters particular to particular
projection types. Some of these can be found in the GeoTIFF
<a href="http://www.remotesensing.org/geotiff/proj_list/">Projections
Transform List</a>. The definitative documentation for most parameters
is Gerald's original documentation available from the main PROJ.4 page. <p>
<h2><a name="false_easting_northing">False Easting/Northing</a></h2>
Virtually all coordinate systems allow for the presence of a false easting
(+x_0) and northing (+y_0). Note that these values are always expressed in
meters even if the coordinate system is some other units. Some coordinate
systems (such as UTM) have implicit false easting and northing values.<p>
<h2><a name="pm">pm - Prime Meridian</a></h2>
A prime meridian may be declared indicating the offset between the prime
meridian of the declared coordinate system and that of greenwich. A prime
meridian is clared using the "pm" parameter, and may be assigned a symbolic
name, or the longitude of the alternative prime meridian relative to
greenwich. <p>
Currently prime meridian declarations are only utilized by the
pj_transform() API call, not the pj_inv() and pj_fwd() calls. Consequently
the user utility <b>cs2cs</b> does honour prime meridians but the <b>proj</b>
user utility ignores them. <p>
The following predeclared prime meridian names are supported. These
can be listed using the cs2cs argument <b>-lm</b>.<p>
<pre>
greenwich 0dE
lisbon 9d07'54.862"W
paris 2d20'14.025"E
bogota 74d04'51.3"E
madrid 3d41'16.48"W
rome 12d27'8.4"E
bern 7d26'22.5"E
jakarta 106d48'27.79"E
ferro 17d40'W
brussels 4d22'4.71"E
stockholm 18d3'29.8"E
athens 23d42'58.815"E
oslo 10d43'22.5"E
</pre>
Example of use. The location long=0, lat=0 in the greenwich based
lat/long coordinates is translated to lat/long coordinates with Madrid
as the prime meridian. <p>
<pre>
cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=madrid
0 0 <i>(input)</i>
3d41'16.48"E 0dN 0.000 <i>(output)</i>
</pre>
<h2><a name="towgs84">towgs84 - Datum transformation to WGS84</a></h2>
Datum shifts can be approximated by 3 parameter spatial translations (in
geocentric space), or 7 parameter shifts (translation + rotation + scaling).
The parameters to describe this can be described using the <b>towgs84</b>
parameter.<p>
In the three parameter case, the three arguments are the translations to the
geocentric location in meters.<p>
For instance, the following demonstrates converting from the Greek GGRS87
datum to WGS84.<p>
<pre>
% cs2cs +proj=latlong +ellps=GRS80 +towgs84=-199.87,74.79,246.62 \
+to +proj=latlong +datum=WGS84
20 35
20d0'5.467"E 35d0'9.575"N 8.570
</pre>
The EPSG database provides this example for transforming from WGS72 to WGS84
using an approximated 7 parameter transformation.<p>
<pre>
% cs2cs +proj=latlong +ellps=WGS72 +towgs84=0,0,4.5,0,0,0.554,0.219 \
+to +proj=latlong +datum=WGS84
4 55
4d0'0.554"E 55d0'0.09"N 3.223
</pre>
The seven parameter case uses <i>delta_x</i>, <i>delta_y</i>, <i>delta_z</i>,
<i>Rx - rotation X</i>, <i>Ry - rotation Y</i>, <i>Rz - rotation Z</i>,
<i>M_BF - Scaling</i>. The three translation parameters are in meters as
in the three parameter case. The rotational parameters are not in physical
units. They are something like the sine of the rotational angle times the
ellipoid axis length, but I don't know the exact details of how to derive
these from a physical description of the rotation. What I do know is that
they match the parameters used for transformation method 9606 in the EPSG
database. The scaling is apparently the scale change in parts per million.<p>
A more complete discussion of the 3 and 7 parameter transformations can be
found in the EPSG database (trf_method's 9603 and 9606). Within PROJ.4
the following calculations are used to apply the <b>towgs84</b> transformation
(going to WGS84). The x, y and z coordinates are in geocentric coordinates.
Three parameter transformation (simple offsets):
<pre>
x[io] = x[io] + defn->datum_params[0];
y[io] = y[io] + defn->datum_params[1];
z[io] = z[io] + defn->datum_params[2];
</pre>
Seven parameter transformation (translation, rotation and scaling):
<pre>
#define Dx_BF (defn->datum_params[0])
#define Dy_BF (defn->datum_params[1])
#define Dz_BF (defn->datum_params[2])
#define Rx_BF (defn->datum_params[3])
#define Ry_BF (defn->datum_params[4])
#define Rz_BF (defn->datum_params[5])
#define M_BF (defn->datum_params[6])
x_out = M_BF*( x[io] - Rz_BF*y[io] + Ry_BF*z[io]) + Dx_BF;
y_out = M_BF*( Rz_BF*x[io] + y[io] - Rx_BF*z[io]) + Dy_BF;
z_out = M_BF*(-Ry_BF*x[io] + Rx_BF*y[io] + z[io]) + Dz_BF;
</pre>
Note that EPSG method 9607 (coordinate frame rotation) coefficients can be
converted to EPSG method 9606 (position vector 7-parameter) supported by
PROJ.4 by reversing the sign of the rotation vectors. The methods are
otherwise the same.<p>
</body>
</html>
|
