{"id":238,"date":"2007-07-24T01:12:48","date_gmt":"2007-07-24T06:12:48","guid":{"rendered":"http:\/\/crschmidt.net\/blog\/?p=238"},"modified":"2007-07-24T01:12:48","modified_gmt":"2007-07-24T06:12:48","slug":"understanding-googles-projection-slightly-anyway","status":"publish","type":"post","link":"https:\/\/crschmidt.net\/blog\/archives\/238\/understanding-googles-projection-slightly-anyway\/","title":{"rendered":"Understanding Google’s Projection… slightly, anyway"},"content":{"rendered":"

So, as a result of Custom Projection 6: Google Projection<\/a>, I got pinged by SharpGIS<\/a> on IRC, and told that the projection I had there was wrong.<\/p>\n

He helped me understand what he was using, and I let him know it still wasn’t helping me. So I set up a Virtual Earth + TileCache<\/a> demo, and he helped me find the missing piece, in the proj4 FAQ<\/a>:<\/p>\n

\nIn this case, and many other cases using spherical projections, the desired approach is to actually treat the lat\/long locations on the sphere as if they were on WGS84 without any adjustments when using them for converting to other coordinate systems. The solution is to “trick” PROJ.4 into applying no change to the lat\/long values when going to (and through) WGS84. This can be accomplished by asking PROJ to use a null grid shift file for switching from your spherical lat\/long coordinates to WGS84.<\/p>\n

+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs\n<\/p><\/blockquote>\n

The key here was the +nadgrids=@null, which I’d never seen anywhere before.<\/p>\n

The end result?<\/p>\n