[Proj] NAD27 and WGS84 woes

Michal Migurski mike at stamen.com
Fri Nov 21 17:06:52 EST 2008

Hi Frank,

Thanks for your help.

>> The reference point I'm using is in Oakland CA, (37.804732,  
>> -122.258477). I'm expecting to see it projected to (565345,  
>> 4184205) but instead I'm getting (565278, 4184204), about 70m off.
> Mike,
> The result you are getting is congruent with no datum shift being  
> applied
> though I get (565276.44, 4184408.92) when I convert the above lat/ 
> long value
> assuming WGS84 to WGS84 instead of WGS84 to NAD27.
> If I do it properly using the normal NAD27 handling via the  
> continental US
> grid shift files:
>  cs2cs -I +proj=utm +zone=10 +datum=NAD27 +to +proj=latlong  
> +datum=WGS84
> I get (565373.10, 4184212.50).  This is still pretty far off what you
> were expecting, so I wonder if your expectations are wrong.  Or  
> perhaps 30
> meters the best you can accomplish with the data precision you have?

Frustrating, I don't know. I'm reading the FAQ's on datum shift files  
- FWIW, I'm using PROJ on a debian server where I've simply installed  
it all via Apt. I didn't build/install myself. Does the fact that my  
explicitly-given +towgs84 arguments have no effect mean anything here?  
Wouldn't those be replacements for missing grid shift files?

>> I'm trying to use this elevation data from USGS, I need to have it  
>> match the mercator projection used by OpenStreetMap:
>>    http://bard.wr.usgs.gov/htmldir/dem_html/
> Hmm, that may add some additional issues.

There certainly could be some error in those files. They do have a  
strange rotation going on; when I render bitmaps I can see slices of  
blank data around the edges, illustrated here:


Does that apparent rotation mean anything to you? I've seen it with  
quadrangles from other sources as well.

There's a creek fork in that image I'm considering a reference point  
at (387, 630). When I use the python module osgeo.gdal to project what  
I think should be the correct lat, lon (37.81844624, -122.20710754),  
it comes out a solid 50+ meters off, more than I expect from my  
potentially-sloppy eyeballing of google maps.

It seems that the USGS would be more accurate than this with a 10m  
dataset, so I'm trying to understand whether I'm doing something wrong.


michal migurski- mike at stamen.com

More information about the Proj mailing list