[OSRS-PROJ] Re: PROJ.4 and NAD conversions

[Frank Warmerdam]

Dave Blasby wrote:
> Frank, I've been using PROJ.4 for doing NAD conversions.  I've come
> across a few problems:
> 
> 1. In "pj_datums.c" - I think the line that's currently :
> 
> "NAD27",    "nadgrids=conus,ntv1_can.dat",           "clrk66",   
> "North_American_Datum_1927",
> 
> should be:
> 
> "NAD27",   
> "nadgrids=stgeorge,stlrnc,stpaul,conus,alaska,prvi,hawaii,ntv1_can.dat",          
> "clrk66", 
>                                 "North_American_Datum_1927",
> 
> I'm assuming that the order is important, so I put the most 'precise'
> first.  All of these configuration (.lla) files are in the standard
> setup, but arent actually used by PROJ.

Dave,

Have you tried some of the stgeorge, stpaul, alaska, prvi or hawaii
files?  I haven't and so have hesitated to include them.  Also, currently
PROJ.4 blows a gasket if it can't find any of the files, and loads them
all when it first encounters a request for NAD27 regardless of whether
they are for the area of interest.  That means if we change the definition
it will increase the memory footprint (potentially substantially?) for
all users.

> An even better fix would be for the ./configure to change this line
> automagically.
 >
> 2. I've also been doing some conversion of points "in the middle of
> nowhere".  When PROJ finds a point without a corresponding grid, it
> throws a -38 (couldn't load grid file) error.  This is a wise thing to
> do - after all, you cannot actually re-project the point. 
> Unfortunately, it sucks to suddenly have your projection fail.  
> Currently, if I get a -38 error, I re-run a slightly modified version of
> pj_transform() that doesnt do the datum conversion.  Unfortunately, if
> you dont do the datum conversion (pj_datum_transform) you also dont do
> the ellipsoid translation.  Is it possible to add another version of
> pj_transform thats a bit wiser than pj_transform wrt missing grid files? 

I have modified pj_apply_gridshift() to report the problem to stderr (if
PROJ_DEBUG is defined in the environment) when no grid matches.  What
do you think the system should do if nothing matches?  Just do the ellipsoid
shift and quietly proceed?  I don't feel very comfortable with that.

It is a problem that as it stands PROJ.4 has no easy way of doing ellipsoid
shifts without doing grid shifts.

I am cc:ing this to the PROJ.4 list to see if others have opinions on how
PROJ.4 should handle some of these situations.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent


----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.