Andreas,
I have a few updates to commit for proj4js but unfortunately I haven't
been able to solve this one yet. I'll try to have a look again on the
weekend.
Mike
Andreas Hocevar wrote:
> 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
