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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
<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>
<hr>
<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>
<hr>
<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>
<hr>
<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 in seconds of
arc. 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>
<hr>
<h2><a name="nadgrids">nadgrids - Grid Based Datum Adjustments</a></h2>
In many places (notably North America and Austrialia) national geodetic
organizations provide grid shift files for converting between different
datums, such as NAD27 to NAD83. These grid shift files include a shift to
be applied at each grid location. Actually grid shifts are normally computed
based on an interpolation between the containing four grid points.<p>
PROJ.4 currently supports use of grid shift files for shifting between
datums and WGS84 under some circumstances. The grid shift table formats are
ctable (the binary format produced by the PROJ.4 nad2bin program),
NTv1 (the old Canadian format), and NTv2 (.gsb - the new Canadian and
Australian format).<p>
Use of grid shifts is specified using the "nadgrids" keyword in a coordinate
system definition. For example:<p>
<pre>
% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=ntv1_can.dat \
+to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
-111 50
EOF
111d0'2.952"W 50d0'0.111"N 0.000
</pre>
In this case the /usr/local/share/proj/ntv1_can.dat grid shift file
was loaded, and used to get a grid shift value for the selected point. <p>
It is possible to list multiple grid shift files, in which case each will be
tried in turn till one is found that contains the point being transformed.<p>
<pre>
% cs2cs +proj=latlong +ellps=clrk66 \
+nadgrids=conus,alaska,hawaii,stgeorge,stlrnc,stpaul \
+to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
-111 44
EOF
111d0'2.788"W 43d59'59.725"N 0.000
</pre>
<h3>Skipping Missing Grids</h3>
The special prefix <b>@</b> may be prefixed to a grid to make it optional. If
it not found, the search will continue to the next grid. Normally any
grid not found will cause an error. For instance, the following would
use the ntv2_0.gsb file if available, otherwise it would fallback to using
the ntv1_can.dat file. <p>
<pre>
% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=@ntv2_0.gsb,ntv1_can.dat \
+to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
-111 50
EOF
111d0'3.006"W 50d0'0.103"N 0.000
</pre>
<h3>The null Grid</h3>
A special <b>null</b> grid shift file is shift with releases after 4.4.6 (not
inclusive). This file provides a zero shift for the whole world. It may
be listed at the end of a nadgrids file list if you want a zero shift to
be applied to points outside the valid region of all the other grids.
Normally if no grid is found that contains the point to be transformed an
error will occur.<p>
<pre>
% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=conus,null \
+to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
-111 45
EOF
111d0'3.006"W 50d0'0.103"N 0.000
</pre>
<pre>
% cs2cs +proj=latlong +ellps=clrk66 +nadgrids=conus,null \
+to +proj=latlong +ellps=GRS80 +datum=NAD83 << EOF
-111 44
-111 55
EOF
111d0'2.788"W 43d59'59.725"N 0.000
111dW 55dN 0.000
</pre>
<h3>Downloading and Installing Grids</h3>
The source distribution of PROJ.4 contains only the ntv1_can.dat file. To
get the set of US grid shift files it is necessary to download an additional
distribution of files from the PROJ.4 site, such as
<a href="ftp://ftp.remotesensing.org/pub/proj/proj-nad27-1.1.tar.gz">
proj-nad27-1.1.tar.gz</a>. Overlay it on the PROJ.4 source distribution,
and re-configure, compile and install. The distributed ASCII .lla files
are converted into binary (platform specific) files that are installed.
On windows using the <tt>nmake /f makefile.vc nadshift</tt> command in
the <tt>proj\src</tt> directory to build and install these files. <p>
It appears we can't redistribute the Canadian NTv2 grid shift file freely,
though it is better than the NTv1 file. However, end users can download it
for free from the NRCan web site at
<a href="http://www.geod.nrcan.gc.ca/software/ntv2_e.php">
http://www.geod.nrcan.gc.ca/software/ntv2_e.php</a>. After
downloading it, just dump it in the data directory with the other
installed data files (usually /usr/local/share/proj). <p>
<h3>Caveats</h3>
<ol>
<li> Where grids overlap (such as conus and ntv1_can.dat for instance) the
first found for a point will be used regardless of whether it is appropriate
or not. So, for instance, +nadgrids=ntv1_can.dat,conus would result in the
canadian data being used for some areas in the northern United States even
though the conus data is the approved data to use for the area. Careful
selection of files and file order is necessary. In some cases border spanning
datasets may need to be pre-segmented into Canadian and American points
so they can be properly grid shifted.<p>
<li> There are additional grids for shifting between NAD83 and various
HPGN versions of the NAD83 datum. Use of these haven't been tried recently
so you may encounter problems. The FL.lla, WO.lla, MD.lla, TN.lla and WI.lla
are examples of high precision grid shifts. Take care!<p>
<li> Additional detail on the grid shift being applied can be found by
setting the PROJ_DEBUG environment variable to a value. This will result
in output to stderr on what grid is used to shift points, the bounds of the
various grids loaded and so forth.<p>
<li> PROJ.4 always assumes that grids contain a shift <b>to</b> NAD83
(essentially WGS84). Other types of grids might or might not be usable.<p>
</ol>
</body>
</html>
|
