Mike,
is there any progress on this issue? I want to integrate Google Maps in
one of my projects, and it would be great if this was fixed.
Were my suggestions from the previous posting useful?
I think the logic should be something like that (at least for transverse
mercator):
if (targetProj == EPSG:9009123 && sourceProj.ellps != "wgs84") {
point.transform(sourceProj -> EPSG:4326);
point.transform(EPSG:4326 -> targetProj);
}
Please excuse this non-API code, I just wanted to show the logic.
Regards,
Andreas.
-------- Original Message --------
Subject: Re: [Mapbuilder-devel] 7-parameter datum transformation bug in
Proj4js
Date: Mon, 24 Dec 2007 23:44:46 +0100
From: Andreas Hocevar <[EMAIL PROTECTED]>
To: Christopher Schmidt <[EMAIL PROTECTED]>
CC: Mike Adair <[EMAIL PROTECTED]>, mapbuilder-devel
<[email protected]>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Christopher Schmidt wrote:
> On Mon, Dec 24, 2007 at 11:20:04AM -0500, Mike Adair wrote:
>
> Note that at the time of FOSS4G, EPSG:900913 projections worked
> flawlessly. I confirmed this by testing them against the OpenLayers
> internal reprojection formulas.
>
I think it works only for transformations from/to projections that use a
WGS84 datum.
>> 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 do not think that this is a good idea, for the reasons described below.
> I believe that this matches up to the [EMAIL PROTECTED] hack described at
> http://proj.maptools.org/faq.html#sphere_as_wgs84 .
>
Hm. From looking at the OpenLayers reprojection code between 4326 and
Spherical Mercator, I would guess that conversions between the two are
just a conversion from degrees to meters with a stretch in y-direction,
increasing with the distance to the equator. This leads me to the
conclusion that Spherical Mercator is based on a WGS84 datum, with a
different ellipsoid shape in y-direction only.
>> 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.
>>
This is the usual y difference between projections based on the MGI
Bessel datum (like EPSG:31285) and WGS84-based projections. You will
experience the same difference when converting from EPSG:31285 to
EPSG:4326 without datum transformation.
> 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.)
>
I think this should also be done in proj4js: if 900913 is requested as
source or target projection, reproject to/from 4326 instead, and apply
the OpenLayers transformation code before/after that conversion.
Of course, this is just an idea from me, knowing that I do not know too
much about reprojecting coordinates.
Regards,
Andreas.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
mapbuilder-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
