<br><font size=2 face="sans-serif">As one more data point, I used some of our internal software to convert UTM, zone 16, NAD27 to Geographic, WGS84 and received the same results as OGR. The software is based on GCTP and our own datum layer.</font>
<br><font size=2 face="sans-serif"><br>
--------------------------------------------------------------------------<br>
Tim Beckmann tbeckman@usgs.gov<br>
Software Project Lead<br>
SAIC<br>
EROS Data Center, Sioux Falls, SD 57198<br>
605-594-2521 Phone<br>
605-594-6940 Fax<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Frank Warmerdam <warmerdam@pobox.com></b></font>
<br><font size=1 face="sans-serif">Sent by: gdal-dev-admin@remotesensing.org</font>
<p><font size=1 face="sans-serif">12/12/2003 08:18 AM</font>
<br><font size=1 face="sans-serif">Please respond to gdal-dev</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: gdal-dev@remotesensing.org</font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: [Gdal-dev] USGS vs. ESRI vs. OGR</font></table>
<br>
<br>
<br><font size=2 face="Courier New">Grabowski, Hank wrote:<br>
> I followed your advise to compare to the USGS tool. The conversion<br>
> results are listed below. As we can see, the ESRI and USGS tools match<br>
> identically (to the precision of ESRI which was lower than the USGS<br>
> solution). There is a convergence parameter from the USGS calculation<br>
> which is significantly larger than the error between OGR and ESRI/USGS.<br>
> Being a novice at this reprojection business, I don't know if that is<br>
> the bounds of the accuracy of the solution. I would tend to believe not<br>
> however, since a 40 minute minimum accuracy would be a multi-kilometer<br>
> error in position. On a hunch I looked at the two definitions used for<br>
> WGS84 by both OGR and ESRI, and their coefficients match to reported<br>
> accuracy. I'll continue investigating this issue if no one has any<br>
> ideas what could be causing it.<br>
> <br>
> UTM X 597196.62 Meters <br>
> UTM Y 4116325.5 Meters <br>
> <br>
> Product Lat Lon Convergence<br>
> Scale<br>
> DD MM SS.sssss DDD MM SS.sssss DD MM SS.ss<br>
> Unitless<br>
> USGS 37 11 24.57282 085 54 17.71610 0 39 43.15<br>
> 9.99716E-001<br>
> ESRI 37 11 24.57 085 54 17.72 <br>
> OGR 37 11 24.76 085 54 17.62 <br>
<br>
Hank,<br>
<br>
I am a bit confused. When I do UTM16 NAD27 to geographic NAD27 I get:<br>
<br>
cs2cs +proj=utm +zone=16 +datum=NAD27 +to +proj=latlong +datum=NAD27<br>
597196.62 4116325.5 (input)<br>
85d54'17.716"W 37d11'24.573"N 0.000 (output)<br>
<br>
It would *appear* that your locations for the USGS and ESRI are the NAD27<br>
lat/long location, not the NAD83 location unless the datum shift at the<br>
location is less than 1/100 of a second.<br>
<br>
I broke down the conversion into steps from UTM 16 NAD27 to Latlong NAD27,<br>
and then used "nad2nad" explicitly with the conus file just to be sure<br>
that my code for cs2cs wasn't mixing things up, and I get the same final<br>
OGR output coordinates you did. While the ESRI software uses a somewhat<br>
different grid shift file than ESRI, I believe that the PROJ/OGR software<br>
is doing the right thing given the values in the conus file.<br>
<br>
In summary, I question whether your USGS/ESRI numbers really represent<br>
applying a datum shift at all.<br>
<br>
Best regards,<br>
-- <br>
---------------------------------------+--------------------------------------<br>
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com<br>
light and sound - activate the windows | http://pobox.com/~warmerdam<br>
and watch the world go round - Rush | Geospatial Programmer for Rent<br>
<br>
<br>
_______________________________________________<br>
Gdal-dev mailing list<br>
Gdal-dev@remotesensing.org<br>
http://remotesensing.org/mailman/listinfo/gdal-dev<br>
</font>
<br>
<br>