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 <[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
