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
|
<html>
<head>
<title>PROJ.4 - Frequently Asked Questions</title>
</head>
<body BGCOLOR="#FFFFFF">
<h1>PROJ.4 - Frequently Asked Questions</h1>
<!-------------------------------------------------------------------------->
<h2><a name="proj_docs">Where can I find the list of projections and their arguments?</a></h2>
There is no simple single location to find all the required information. The
PostScript/PDF documents listed on the <a href="index.html">main</a> PROJ.4
page under documentation are the authoritative source but projections and
options are spread over several documents in a form more related to their
order of implementation than anything else.<pp>
The <b>proj</b> command
itself can report the list of projections using the <tt>-lp,</tt> option,
the list of ellipsoids with the <tt>-le</tt> option, the list of units with
the <tt>-lu</tt> option, and the list of built-in datums with the <tt>-ld</tt>
option.<p>
The <a href="http://www.remotesensing.org/geotiff/proj_list/">GeoTIFF
Projections Pages</a> include most of the common PROJ.4 projections, and
a definition of the projection specific options for each.<p>
<!-------------------------------------------------------------------------->
<h2><a name="nad2783">How do I do datum shifts between NAD27 and NAD83?</a></h2>
While the <b>nad2nad</b> program can be used in some cases, the <b>cs2cs</b>
is now the preferred mechanism. The following example demonstrates using
the default shift parameters for NAD27 to NAD83:<p>
<pre>
% cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
-117 30
</pre>
<p>
producing:<p>
<pre>
117d0'2.901"W 30d0'0.407"N 0.000
</pre>
<p>
In order for datum shifting to work properly the various grid shift files
must be available. See below. More details are available in the
<a href="gen_parms.html#nadgrids">General Parameters</a> document.<p>
<!-------------------------------------------------------------------------->
<h2><a name="datumshifting">How do I build/configure PROJ.4 to support datum shifting.</a></h2>
After downloading and unpacking the PROJ.4 source, also download and unpack
the set of datum shift files. This would be a file like
<a href="ftp://ftp.remotesensing.org/pub/proj/proj-datumgrid-1.3.zip">
ftp://ftp.remotesensing.org/pub/proj/proj-datumgrid-1.3.zip</a>. This
file should be unpacked <i>within</i> the <tt>proj/nad</tt> directory.
Then proceed with the configuration, build and install. This will ensure
that the build system knows about the grid shift files, and applies the
ascii to binary preprocessing step.<p>
On Windows the extra <tt>nadshift</tt> target must be used. For instance
<tt>nmake /f makefile.vc nadshift</tt> in the <tt>proj/src</tt> directory.
<p>
A default build and install on Unix will normally build knowledge of the
directory where the grid shift files are installed into the PROJ.4 library
(usually /usr/local/share/proj). On Windows the library is normally built
thinking that C:\PROJ\NAD is the installed directory for the grid shift files.
If the built in concept of the PROJ.4 data directory is incorrect, the PROJ_LIB
environment can be defined with the correct directory.<p>
<!-------------------------------------------------------------------------->
<h2><a name="nad2783_debug">How do I debug problems with NAD27/NAD83 datum shifting?</a></h2>
<ol>
<li> Verify that you have the binary files (eg. /usr/local/share/proj/conus)
installed on your system. If not, see the previous question.
<p>
<li> Try a datum shifting operation in relative isolation, such as with the
cs2cs command listed above. Do you get reasonable results? If not it is
likely the grid shift files aren't being found. Perhaps you need to define
PROJ_LIB? <p>
<li> The cs2cs command and the underlying pj_transform() API know how to
do a grid shift as part of a more complex coordinate transformation; however,
it is imperative that both the source and destination coordinate system be
defined with appropriate datum information. That means that implicitly or
explicitly there must be a +datum= clause, a +nadgrids= clause or
a +towgs84= clause. For instance "cs2cs +proj=latlong +datum=NAD27 +to
+proj=latlong +ellps=WGS84" won't work because defining the output coordinate
system as using the ellipse WGS84 isn't the same as defining it to use the
datum WGS84 (use +datum=WGS84). If either the input or output are not
identified as having a datum, the datum shifting (and ellipsoid change) step
is just quietly skipped!<p>
<li> The PROJ_DEBUG environment can be defined (any value) to force extra
output from
the PROJ.4 library to stderr (the text console normally) with information on
what data files are being opened and in some cases why a transformation fails.
Note that PROJ_DEBUG support is not yet very mature in the PROJ.4 library.<p>
<li> The "-v" flag to cs2cs can be useful in establishing more detail on
what parameters being used internally for a coordinate system. This will
include expanding the definition of +datum clause. <p>
</ol>
<!-------------------------------------------------------------------------->
<h2><a name="epsg">How do I use EPSG coordinate system codes with PROJ.4?</a></h2>
There is somewhat imperfect translation between 2d geographic and
projected coordinate system codes and PROJ.4 descriptions of the
coordinate system available in the <tt>epsg</tt> definition file that
normally lives in the <tt>proj/nad</tt> directory. If installed (it is
installed by default on Unix), it is possible to use EPSG numbers like this:
<pre>
% cs2cs -v +init=epsg:26711
# ---- From Coordinate System ----
#Universal Transverse Mercator (UTM)
# Cyl, Sph
# zone= south
# +init=epsg:26711 +proj=utm +zone=11 +ellps=clrk66 +datum=NAD27 +units=m
# +no_defs +nadgrids=conus,ntv1_can.dat
#--- following specified but NOT used
# +ellps=clrk66
# ---- To Coordinate System ----
#Lat/long (Geodetic)
#
# +proj=latlong +datum=NAD27 +ellps=clrk66 +nadgrids=conus,ntv1_can.dat
</pre>
The <tt>proj/nad/epsg</tt> file can be browsed and searched in a text editor
for coordinate systems. There are known to be problems with some coordinate
systems, and any coordinate systems with odd axes, a non-greenwich prime
meridian or other quirkyness are unlikely to work properly. Caveat Emptor!<p>
<!-------------------------------------------------------------------------->
<h2><a name="datum_37">How do I use 3 parameter and 7 parameter datum shifting</a></h2>
Datum shifts can be approximated with 3 and 7 parameter transformations.
Their use is more fully described in the
<a href="gen_parms.html#towgs84">towgs84</a> discussions.<p>
<!-------------------------------------------------------------------------->
<h2><a name="locale">Does PROJ.4 work in different international numeric locales?</a></h2>
No. PROJ.4 makes extensive use of sprintf() and atof() internally to translate
numeric values. If a locale is in effect that modifies formatting of
numbers, altering the role of commas and periods in numbers, then PROJ.4
will not work. This problem is common in some European locales.<p>
On unix-like platforms, this problem can be avoided by forcing the use
of the default numeric locale by setting the LC_NUMERIC environment variable
to C. <p>
eg.
<pre>
$ export LC_NUMERIC=C
$ proj ...
</pre>
<!-------------------------------------------------------------------------->
<h2><a name="sphere_as_wgs84">Changing Ellipsoid / Why can't I convert from WGS84 to Virtual Earth Mercator?</a></h2>
The coordinate system definition for Virtual Earth Mercator is as follows,
which uses a sphere as the earth model for the mercator projection.
<pre>
+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs
</pre>
But, if you do something like:
<pre>
cs2cs +proj=latlong +datum=WGS84
+to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs
</pre>
to convert between WGS84 and mercator on the sphere there will be substantial
shifts in the Y mercator coordinates. This is because internally cs2cs is
having to adjust the lat/long coordinates from being on the sphere to being
on the WGS84 datum which has a quite differently shaped ellipsoid.<p>
In this case, and many other cases using spherical projections, the desired
approach is to actually treat the lat/long locations on the sphere as if
they were on WGS84 without any adjustments when using them for converting
to other coordinate systems. The solution is to "trick" PROJ.4 into applying
no change to the lat/long values when going to (and through) WGS84. This
can be accomplished by asking PROJ to use a <i>null</i> grid shift file
for switching from your spherical lat/long coordinates to WGS84.<p>
<pre>
cs2cs +proj=latlong +datum=WGS84
+to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
+x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs
</pre>
Note the strategic addition of <tt>+nadgrids=@null</tt> to the spherical
projection definition.<p>
Similar issues apply with many other datasets distributed with projections
based on a spherical earth model - such as many NASA datasets, and also
(I think) the Google Maps mercator projection.<p>
<!-------------------------------------------------------------------------->
<hr>
Requests to add items to the frequently asked questions list
<a href="http://bugzilla.remotesensing.org/enter_bug.cgi?product=PROJ.4">
can be entered</a> in bugzilla.<p>
</body>
</html>
|
