ShapeObj->project doesn't re-project Shapes created from WKT

[stoeckmann]

ShapeObj->project doesn't re-project when ShapeObj was created using ms_shapeObjFromWkt(), although ShapeObj->project method returns MS_TRUE.

This won't work:

$etrs32 = ms_newProjectionObj("proj=tmerc,lon_0=9,ellps=GRS80,k=0.9996,units=m,datum=WGS84,x_0=2500000"); $etrs33 = ms_newProjectionObj("proj=tmerc,lon_0=15,ellps=GRS80,k=0.9996,units=m,datum=WGS84,x_0=3500000");

$Shp = ms_shapeObjFromWkt("POINT(3383442 5933645)"); $Shp2->Project($etrs33,$etrs32); print $Shp2->toWkt();

RETURNS: "POINT (3383442.0000000000000000 5933645.0000000000000000)" (these are the source coordinates, not the destination ones)

But this works:

$etrs32 = ms_newProjectionObj("proj=tmerc,lon_0=9,ellps=GRS80,k=0.9996,units=m,datum=WGS84,x_0=2500000"); $etrs33 = ms_newProjectionObj("proj=tmerc,lon_0=15,ellps=GRS80,k=0.9996,units=m,datum=WGS84,x_0=3500000");

$Line = ms_newLineObj(); $Line->addXY(3383442,5933645); $Shp2 = ms_newShapeObj(0); $Shp2->add($Line); $Shp2->Project($etrs33,$etrs32); print $Shp2->toWkt();

RETURNS CORRECTLY: "POINT (2780993.2288354267366230 5940576.6376133039593697)"

[warmerdam]

Working to reproduce this problem using python mapscript but getting messed up in GEOS stuff. Migrating to 5.0.1.

[warmerdam]

Steven,

I have built PHP MapScript against MapScript 5 and the script seems to work. In particular I use:

<?php

dl("php_mapscript.so");

$etrs32 = ms_newProjectionObj("proj=tmerc,lon_0=9,ellps=GRS80,k=0.9996,units=m,datum=WGS84,x_0=2500000"); 
$etrs33 = ms_newProjectionObj("proj=tmerc,lon_0=15,ellps=GRS80,k=0.9996,units=m,datum=WGS84,x_0=3500000");

$Shp = ms_shapeObjFromWkt("POINT(3383442 5933645)"); 

$Shp->Project($etrs33,$etrs32); 

print $Shp->toWkt();

?>

and I get:

POINT (2780993.228835426736623 5940576.63761330395937)

Perhaps this was fixed since you ran into the problem? I don't think we are still doing point releases on 4.10.x so I think the answer is "appears to work in 5.0". Please reopen if you can reproduce on 5.0.

[warmerdam]

It turns out this report is a duplicate of #2107 which was fixed.