[GRASS-dev] datumtransform.table question

[Michael Barton]

Glynn and Paul,

I'm hoping you can help me clear up an issue with datum transforms.

I've got the location wizard in wxgrass creating PROJ.4 strings and ready to
test it making new locations that way. I've run into an odd problem. I went
to test it using my home state of Arizona, wanting to see the PROJ.4 string
for UTM, zone 12, with a NAD83 datum.

The problem is in the datum transform table.

If I use the old g.setproj and pick UTM zone 12, I am prompted to enter a
datum transform. There are 6 choices, listed here...

Enter 'list' to see the list of available Parameter sets
Enter the corresponding number, or <RETURN> to cancel request
>list

Number  Details 
---
1       Used in whole nad83 region
        (PROJ.4 Params towgs84=0.000,0.000,0.000)
        Default 3-Parameter Transformation (May not be optimum for older
datums;
 use this only if no more appropriate options are available.)
---
2       Used in Florida
        (PROJ.4 Params nadgrids=FL)
        Transforms 'Old NAD83' to 'HPGN NAD83'
---
3       Used in Maryland
        (PROJ.4 Params nadgrids=MD)
        Transforms 'Old NAD83' to 'HPGN NAD83'
---
4       Used in Tennessee
        (PROJ.4 Params nadgrids=TN)
        Transforms 'Old NAD83' to 'HPGN NAD83'
---
5       Used in Wisconsin
        (PROJ.4 Params nadgrids=WI)
        Transforms 'Old NAD83' to 'HPGN NAD83'
---
6       Used in Washington - Oregon
        (PROJ.4 Params nadgrids=WO)
        Transforms 'Old NAD83' to 'HPGN NAD83'
---

When I pick #1 for Arizona, this create a location with PROJ.4 settings as
follows (retrieved with g.proj -j)...

+proj=utm
+zone=12
+a=6378137
+rf=298.257222101
+no_defs
+towgs84=0.000,0.000,0.000
+to_meter=1.0


However, the datumtransform.table file lacks transform #1. Here are all the
NAD83 entries. You can see, that they include transforms #2-6, but that #1
is missing.

nad83    "nadgrids=FL"           "Florida" "Transforms 'Old NAD83' to 'HPGN
NAD83'"
nad83    "nadgrids=MD"           "Maryland" "Transforms 'Old NAD83' to 'HPGN
NAD83'"
nad83    "nadgrids=TN"           "Tennessee" "Transforms 'Old NAD83' to
'HPGN NAD83'"
nad83    "nadgrids=WI"           "Wisconsin" "Transforms 'Old NAD83' to
'HPGN NAD83'"
nad83    "nadgrids=WO"           "Washington - Oregon" "Transforms 'Old
NAD83' to 'HPGN NAD83'"

Transform #1 seems to be a kind of generic one for NAD83, but is quite
useful programmatically. I've got error checking such that, if there is a
match for datum transforms between datum.table and datumtransform.table, you
need to pick a transform before continuing--the same as with g.setproj. This
prevents users from picking a datum without transforms when one is required.

I can drop this check, but it could be confusing to users to be presented
with a list of transforms, none of which fit their situation. It would be
better to have a generic transform, like #1, available so that there is
always something to pick if transforms show up.

Since datumtransform.table is created out of the same data used by
g.setproj, I'm wondering what happened to transform #1 in the example above.
Could this also be a problem with other datum/transform combinations?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton