[GRASS5] A problem with the proj library?

[Roger Miller]

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