[Fwd: 7-parameter datum transformation bug in Proj4js]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Fwd: 7-parameter datum transformation bug in Proj4js]

Andreas Hocevar
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 <[hidden email]>
To: Christopher Schmidt <[hidden email]>
CC: Mike Adair <[hidden email]>, mapbuilder-devel
<[hidden email]>
References:
<[hidden email]>
<[hidden email]> <[hidden email]>
<[hidden email]>



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 +nagrids=@null 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Fwd: 7-parameter datum transformation bug in Proj4js]

Michael Adair
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 <[hidden email]>
> To:     Christopher Schmidt <[hidden email]>
> CC:     Mike Adair <[hidden email]>, mapbuilder-devel
> <[hidden email]>
> References:
> <[hidden email]>
> <[hidden email]> <[hidden email]>
> <[hidden email]>
>
>
>
> 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 +nagrids=@null 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Fwd: 7-parameter datum transformation bug in Proj4js]

Andreas Hocevar
Mike,

I tested now in the Mapbuilder mergeModels example, and the two-step
transformation works perfect!

Unfortunately, I do not really find my way in the Proj4js code. So I
really would be glad if you could implement it.

I was using the correct towgs84 parameters for 31285 from
spatialreference.org.

Here is the result:
EPSG:31285: 440188.2300648418,5297903.630898789;
EPSG:900913: 1469589.6653622496,6045202.57460043; (direct)
WGS84: 13.20154857779409,47.81963737823047;
EPSG:900913: 1469589.6653590575,6076901.202067708; (2-step)

For the tests, I modified the convertPoints method in GmlRendererOL:

convertPoints: function(component, sourceSRS) {
  if (component.CLASS_NAME == 'OpenLayers.Geometry.Point') {
    console.log(sourceSRS.srsCode+": "+component.x+","+component.y+";
(direct)");
    var point = new OpenLayers.Geometry.Point(component.x, component.y);
    Proj4js.transform(sourceSRS, this.proj, point);
    console.log(this.proj.srsCode+": "+point.x+","+point.y+"; ");
    Proj4js.transform(sourceSRS, Proj4js.WGS84, component);
    console.log(Proj4js.WGS84.srsCode+":
"+component.x+","+component.y+"; ");
    component.transformed = false;
    Proj4js.transform(Proj4js.WGS84, this.proj, component);
    console.log(this.proj.srsCode+": "+component.x+","+component.y+";
(2-step)");
  } else {
    for (var i=0; i<component.components.length; ++i) {
      this.convertPoints(component.components[i], sourceSRS);
    }
  }
},

Regards,
Andreas.


Mike Adair wrote:

> 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 <[hidden email]>
>> To:     Christopher Schmidt <[hidden email]>
>> CC:     Mike Adair <[hidden email]>, mapbuilder-devel
>> <[hidden email]>
>> References:
>> <[hidden email]>
>> <[hidden email]> <[hidden email]>
>> <[hidden email]>
>>
>>
>>
>> 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 +nagrids=@null 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mapbuilder-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Fwd: 7-parameter datum transformation bug in Proj4js]

frangoro
In reply to this post by Andreas Hocevar
Buenas Ruben,

Estoy trabajando con Proj4js para realizar la transformación entre EPSG:23030 y EPSG:900913, no sé si tengo el mismo problema que tú, en mi caso realizo la siguiente conversión:

var punto = new OpenLayers.Geometry.Point(lon, lat);
Proj4js.transform(new Proj4js.Proj("EPSG:23030"), new Proj4js.Proj("EPSG:900913"), punto );

Esto no me hace correctamente la transformación, se desvía al menos varios cientos de metros, con lo que me pregunto si el problema será de Proj4js.

Gracias, atentamente, Fran.

In english:

When I convert 23030 to 900913 with Proj4js, I obtain a little displacement of 200 meter about.
¿this is a Proj4js problem?
My code is:
var punto = new OpenLayers.Geometry.Point(lon, lat);
Proj4js.transform(new Proj4js.Proj("EPSG:23030"), new Proj4js.Proj("EPSG:900913"), punto );

Thank in advance.
Loading...