[GRASS5] datum conversion problems

GRASS GIS GRASS GIS developer
1

Folks,

This is a little long, but please stay with me.

I am working on a project in which I need to convert data locations measured
in UTM coordinates using NAD 27 to UTM coordinates using NAD 83. The
resulting coordinates are used to select an elevation from a digital
elevation model in UTM coordinates using NAD 83 with a 10-m spacial
resolution and a vertical resolution of 0.1 meters. The results I produce
need to be reproduceable by other parties using other software and any
differences between our results must be negotiated. Potentially millions of
dollars can swing on a systematic error.

So far the results are not reproduceable and negotiations are progressing.

I have long regarded the conversion programs from the National Geodetic Survey
(NGS) as being authoritative. The Corpscon program released by the Army
Corps of Engineers produces results that are identical to results from the
NGS software. I think Corpscon is little more that an GUI for the NGS
software. The nad2nad program that accompanies the Proj package produces
results that are within about 1 cm of the results from the NGS software.

The s.proj (Grass 5.3) and v.proj (Grass 6.0.1) programs produce results that
are systematically different from the results of the NGS program. In my data
set, the eastings differ by a very consistent 13 meters.

About 3 years ago I adapted the grass [rsv].proj programs to do the nad27 <->
nad83 conversion. I recall that at that time I benchmarked the process
against the NGS software. Subsequently the [rsv].proj modules were modified
to perform more general transformations using the pj_transform function in
the Proj library. The pj_transform function returns results that are
different from the results returned by nad2nad, or the NGS software.

My first question is probably more appropriate for the Proj developers, but
I'll ask it here first, hopefully avoiding the need to join Yet Another
Mailng List. Which provides the more correct result for converting nad27 to
and from nad83, nad2nad.c or pj_transform?

My second question regards CVS. I wanted to reconstruct the old 5.0 versions
of v.proj so that I might review the method I used and confirm its results.
The HTML gateway to CVS shows information for the old version, but that
program refers to functions that aren't present in the code or in the proj
library. Could that code have been lost from CVS?

I am concerned by what appears to me to be an avoidable inaccuracy in GRASS,
but my problems are small compared to my cooperators problems. They are
using ESRI software and are unable to reproduce the NGS results within wide
margins. I asked a friend of mine who regularly uses ESRI software to
benchmark the results against the NGS software. She used a few different
methods and found that the nad83 locations reported by the ESRI ArcEditor
software were not close to the NGS results. Differences were as large as 100
meters.

The ESRI software is closed source, so it is impossible for my cooperators to
defend their results -- something they are painfully aware of.

Roger Miller

2

Hello Roger

Roger Miller wrote:

[...]

About 3 years ago I adapted the grass [rsv].proj programs to do the nad27 <-> nad83 conversion. I recall that at that time I benchmarked the process against the NGS software. Subsequently the [rsv].proj modules were modified to perform more general transformations using the pj_transform function in the Proj library. The pj_transform function returns results that are different from the results returned by nad2nad, or the NGS software.

My first question is probably more appropriate for the Proj developers, but I'll ask it here first, hopefully avoiding the need to join Yet Another Mailng List. Which provides the more correct result for converting nad27 to and from nad83, nad2nad.c or pj_transform?

Frank Warmerdam implemented pj_transform() in PROJ.4 as a more general wrapper around various datum transformation functions, the stuff in nad2nad.c being one of them. From 5.3.0 on I changed GRASS to use this function internally when re-projecting in order to handle datum transformations in a more general manner. Which functions are used depends on the contents of the PROJ_INFO files for your two locations. It might shed some light if you can post them here (for both locations). Use g.projinfo in 5.3 or g.proj -p in 6.x

In particular, make sure you have the line
nadgrids: conus
in your NAD27 location. That's the only think I can think that would have changed the functionality; see the warning at the end of the 5.3.0 release announcement http://www.geog.uni-hannover.de/grass/announces/announce_grass530.html

(copied below for convenience)

Note on changes in datum transformation functionality for locations using the 'nad27' and 'nad83' datums

Released versions of GRASS 5.0.x from 5.0.0pre4 onward (i.e. up to and including 5.0.3) have included the capability to perform NAD27<-->NAD83 datum conversions. This was done using the published NADCON conversion tables, if and only if the line 'datum: nad27' appeared in the PROJ_INFO file for one location and 'datum: nad83' in the other. Even if datum transformation parameters were specified (e.g. dx, dy, dz) they were ignored and the NADCON tables used. In GRASS 5.3 any datum transformation parameters present in the PROJ_INFO file will be used. These are likely to be less accurate than the NADCON transformation (unless g.setproj is re-run for the location and the NADCON parameters specifically selected). Many more datum transformation options are available in this release of GRASS and g.setproj should be re-run if in any doubt that the location is using the most up-to-date datum parameters.

My second question regards CVS. I wanted to reconstruct the old 5.0 versions of v.proj so that I might review the method I used and confirm its results. The HTML gateway to CVS shows information for the old version, but that program refers to functions that aren't present in the code or in the proj library. Could that code have been lost from CVS?

5.0.3 is the most recent version to still contain the nad27 <--> nad83 only datum transformation functionality. You should be able to check it out from CVS as follows:
cvs -z3 co -r release_03_11_2003_grass5_0_3 grass

Good luck
Best regards

Paul

3

On Sunday 27 November 2005 10:34, Paul Kelly wrote:

In particular, make sure you have the line
nadgrids: conus
in your NAD27 location. That's the only think I can think that would
have changed the functionality; see the warning at the end of the 5.3.0
release announcement
http://www.geog.uni-hannover.de/grass/announces/announce_grass530.html

Paul,

Thanks very much. Running g.setproj on the nad27 location fixed the problem.

I've just got to complain about this...

Could the developers find a less obscure place to document this change than in
the release announcement? This is a change that probably effected every
GRASS 5.0 user in North America -- apparently not a large number. I have
found no documentation in the GRASS 5.3.0 distribution that mentions the
change or the need to rerun g.setproj for (probably) all of their North
American locations. The GRASS 6.0.1 distribution includes a text document on
migrating from GRASS 5.0 to GRASS 5.7 and it says nothing at all about the
need to rerun g.setproj.

Is there any documentation out there on the proj library api? Before posting
my original letter I wrote an example program that ran pj_transform in
isolation. I read the available documentation on the proj library, in the
source code and in the header files and they said nothing about the need to
provide a "nadgrids" parameter for anything. There are also quite a few
other details in the library that could use some significant documentation.

Finally, I expect that most users in North America will regard it as an error
if an nad27<->nad83 conversion is done with something other than the nad
grids. I don't know why GRASS would allow for other operations.

Roger Miller