[GRASS5] A problem with the proj library?
rgrmill at rt66.com
Sat, 9 Feb 2002 09:10:14 -0700
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
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.