[Proj] Default nadgrids handling for NAD27 <-> NAD83 conversions

Ed McNierney ed at topozone.com
Tue May 23 15:11:21 EDT 2006

Folks -

I finally chased down and fixed a nagging old bug in our NAD27/NAD83
processing.  We're using MapServer as an OGC WMS server and requesting
raster topo images.  Customers can request output as UTM NAD27 or UTM
NAD83; we specify the output projection using the EPSG code.  This
normally works fine, but requests for UTM NAD27 output in Puerto Rico
were failing.

If I requested an output image as EPSG:26919 (UTM Zone 19 North, NAD83)
everything worked fine; if I requested EPSG:26719 (UTM Zone 19 North,
NAD27), I got nothing.  All relevant grid shift files were properly
installed on the machine doing the processing.  Since the WMS interface
uses EPSG codes as shorthand for full PROJ definitions, I was not
specifying a +nadgrids parameter, but I always got the right result in
other cases.

I discovered that the "fix" was that pj_datums.c (line 87) uses a
default list of grid shift files, and the prvi grid shift file (the one
I needed) was not included in the default list.  The conus and alaska
files, along with the Canadian ones, are used by default, while the
hawaii, prvi, and Bering Sea islands are not.  The comments indicate
that Frank added this default list about three years ago to eliminate
the need for a +nadgrids parameter all the time.

This was a little hard to figure out, because it worked most of the
time.  I'm trying to figure out the best way to handle this situation,
specifically for users using EPSG codes who do not normally specify or
think about +nadgrids parameters.

One fix is to list all the common/known grid shift files in the
pj_datums.c code, at least where there is no conflict between files.
Another would be to edit the EPSG text file to explicitly include the
+nadgrids parameter for all projections that could possibly use it,
specifying only those grid shift files relevant to that projection.  I
don't know why a subset of the grid shift files (from the standard
distribution) is included in pj_datums.c, so I'm not sure of the best
way to handle this.  Suggestions would be welcome - thanks!

	- Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com / Maps a la carte, Inc.
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
ed at topozone.com
(978) 251-4242 

More information about the Proj mailing list