[gdal-dev] gdal datum shift

[Frank Warmerdam]

On 11-04-12 06:07 PM, Brian Wilson wrote:
> Trying to get a raster to go from NAD83 to NAD27 with gdalwarp. Can't see any
> way to tell how it is choosing to do it. Is this documented anywhere?  Is there
> any way to make it verbose so I can tell if it's trying?
>
> I ran it through strace and watched it open a file called gdal_datum.csv but of
> course can't tell what it's trying to do.
>
> I found this post from Frank which implies it tries to be smart and figure out
> the transforms without my help:
> http://fwarmerdam.blogspot.com/2010/03/in-last-few-weeks-i-believe-i-have-made.html
>
> But it's not working and since I don't know how to tell what it's doing I can't
> intelligently ask for help. :-)
>
> Thanks for your patience with a n00by
>
> Brian
>
> Command I am using:
>
> gdalwarp -of HFA -co COMPRESSED=YES -t_srs
> ESRI::NAD_1927_StatePlane_Oregon_North_FIPS_3601.prj 11s5w34f_color_ne.sid
> 11s5w34f_color_ne_nad27.img
>
> Output is in the right coordinate space (it's moved from meters to feet) but
> has that familiar 10 or so meter shift we get around like the NAD83-NAD27
> transform failed.
>
> The input file SRS looks like this
>
> Coordinate System is:
> PROJCS["NAD_1983_HARN_StatePlane_Oregon_North_FIPS_3601",
>      GEOGCS["GCS_North_American_1983_HARN",
>          DATUM["NAD83_High_Accuracy_Regional_Network",
>              SPHEROID["GRS_1980",6378137,298.257222101]],
>          PRIMEM["Greenwich",0],
>          UNIT["Degree",0.017453292519943295]],
>      PROJECTION["Lambert_Conformal_Conic_2SP"],
>      PARAMETER["False_Easting",2500000],
>      PARAMETER["False_Northing",0],
>      PARAMETER["Central_Meridian",-120.5],
>      PARAMETER["Standard_Parallel_1",44.33333333333334],
>      PARAMETER["Standard_Parallel_2",46],
>      PARAMETER["Latitude_Of_Origin",43.66666666666666],
>      UNIT["Meter",1],
>      AUTHORITY["EPSG","102326"]]

Brian,

I believe the problem is the source datum name
"NAD83_High_Accuracy_Regional_Network".  I believe
this is *not* recognised as essentially NAD83 and so
the source datum is treated as unknown and no datum
shifts are done.

It can be helpful to run gdalwarp with the commandline
option "--debug on" in which case the debug output should
include the PROJ.4 rendering of the source and destination
coordinate system.

At a very low level you can also define the PROJ_DEBUG environment
variable to the value ON and PROJ.4 will report some details on what
datum files are opened.

I think you are going to have to provide a source coordinate
system with the -s_srs commandline switch to gdalwarp that
defines a more conventional NAD83 based coordinate system.  You
might also want to file a ticket on this issue.  Ideally we
would be smarter about treating NAD83 HARN as equivelent to NAD83
for most purposes.

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