On Mon, Dec 24, 2007 at 11:20:04AM -0500, Mike Adair wrote: > Andreas, > > I've been looking into this and I think there is a problem with the > Google CS and the datum transformation (Richard and Frank - please feel > free to jump in here and set me straight). The Google projection > doesn't really define a datum from what I can gather so I think it's > invalid to try and do a datum shift with it. The datum shift for > EPSG:31285 going to/from WGS84 seems to work without a problem.
Note that at the time of FOSS4G, EPSG:900913 projections worked flawlessly. I confirmed this by testing them against the OpenLayers internal reprojection formulas. > So what I've done in proj4js is to allow a 'datum=none' parameter (and > added that to the Google def string) which will bypass the datum > transformation if it is set for either source or destination coordinate > system. I believe that this matches up to the [EMAIL PROTECTED] hack described at http://proj.maptools.org/faq.html#sphere_as_wgs84 . > From my test cases, I'm still seeing differences on the order > of 100m in the y value and I'm wondering if that's the best we can do in > this case. Probably not, though it may mean pursuing a different behavior for proj4js than for proj. (This is, for example, the path that GeoServer has taken, defining an entirely new projection type specifically for Google.) Regards, -- Christopher Schmidt Web Developer ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mapbuilder-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
