Folks,
Late last year and early this year I converted a series of DEMs in UTM
coordinates to an Albers Equal Area projection, and everthing worked well.
Soon after that (as near as I can tell) I updated my GRASS instrallation to
5.0.0pre2 and went on about my business. Just after the upgrade I ran a
series of reprojections from both lat long and UTM coordinates to UTM
coordinates. Everthing was fine.
Yesterday I converted a small sites file from UTM coordinates to the same
Albers projection. My reprojected sites ended up in Never-Never Land, which
is a long way from Texas. I got the same results reprojecting vector and
raster files.
I've made a number of changes to my GRASS installation and to the *.proj
group of modules in particular, so I debugged my way through the code to find
out why my results were so wrong. The problem doesn't appear to be due to
any change I made, but I suppose it might have been caused because I carried
over modules I modified for beta11 and inserted them unchanged into pre2.
pj_do_proj converts the input data from UTM to latlong (radians) using pj_inv
then reprojects from latlong to Albers using pj_fwd. The reprojection
produces Albers coordinates in feet.. pj_do_proj divides the Albers
coordinates by 0.3048 -- the "meters" constant from the PROJ_UNITS file for
the Albers location. That would be great if pj_fwd returned values in meters
and I wanted the results converted to feet, but since pj_fwd returned values
in feet the coordinates.
I should be able to correct my results just by changing the "meters" constant
in PROJ_UNITS to 1.. What I don't understand is how things changed so that
a system that worked just over a month ago is broken now. Any ideas?
Also, the input UTM coordinates in this case are supposed to be significant
to about 8 digits. The surveyors actually quoted the northings to 9 digits.
The conversion constant of 0.3048000000 that GRASS stuck in my PROJ_UNITS
files would introduce a usually unacceptable error in the meters->feet
conversion. We probably need a more precise constant built into the source.
I think 0.3048006096012 is about right.
Roger Miller
On Saturday 09 February 2002 09:10, I wrote:
pj_do_proj converts the input data from UTM to latlong (radians) using
pj_inv then reprojects from latlong to Albers using pj_fwd. The
reprojection produces Albers coordinates in feet.. pj_do_proj divides the
Albers coordinates by 0.3048 -- the "meters" constant from the PROJ_UNITS
file for the Albers location. That would be great if pj_fwd returned
values in meters and I wanted the results converted to feet, but since
pj_fwd returned values in feet the coordinates.
I should be able to correct my results just by changing the "meters"
constant in PROJ_UNITS to 1.. What I don't understand is how things
changed so that a system that worked just over a month ago is broken now.
Any ideas?
I wrote this before I actually made the change in the "meters" constant. I
made that change and it didn't fix the problem, so my assessment above of the
results from pj_do_proj is probably not right. At least, that isn't the
whole problem.
I'm still without a clue.
Roger Miller
On Saturday 09 February 2002 09:10, I wrote:
pj_do_proj converts the input data from UTM to latlong (radians) using
pj_inv then reprojects from latlong to Albers using pj_fwd. The
reprojection produces Albers coordinates in feet.. pj_do_proj divides the
Albers coordinates by 0.3048 -- the "meters" constant from the PROJ_UNITS
file for the Albers location. That would be great if pj_fwd returned
values in meters and I wanted the results converted to feet, but since
pj_fwd returned values in feet the coordinates.
I should be able to correct my results just by changing the "meters"
constant in PROJ_UNITS to 1.. What I don't understand is how things
changed so that a system that worked just over a month ago is broken now.
Any ideas?
I wrote this before I actually made the change in the "meters" constant. I
made that change and it didn't fix the problem, so my assessment above of the
results from pj_do_proj is probably not right. At least, that isn't the
whole problem.
I'm still without a clue.
Roger Miller
On Sat, 9 Feb 2002 09:10:14 -0700, Roger Miller <rgrmill@rt66.com> wrote:
[snip]
Also, the input UTM coordinates in this case are supposed to be significant
to about 8 digits. The surveyors actually quoted the northings to 9 digits.
The conversion constant of 0.3048000000 that GRASS stuck in my PROJ_UNITS
files would introduce a usually unacceptable error in the meters->feet
conversion. We probably need a more precise constant built into the source.
I think 0.3048006096012 is about right.
If we're going to be precise, then we'd need to differentiate which type
of foot we're talking about:
foot_type to_meters
==============+===================
Survey Foot | (1200/3937) (derived from: 1 m = 39.37 in)
Int. Foot | 0.3048 (derived from: 1 yd. = 0.9144 m)
1 Int. Foot = 0.999 998 Survey Foot
True, though, that for geodetic measures, it is usually the old foot, or
survey foot, that is meant.
--
Eric G. Miller <egm2@jps.net>