Bug with mapObj.zoomScale() does not set the scale to the desired value.

[kfaschoway]

The function mapObj.zoomScale(...) does not set the scale to the desired value. If the desired scale is 20,000,000 then the function would set the scale to something slightly different like 20,000,063 after the function call.

[sdlime]

Assuming this is in PHP/MapScript. Those functions all originated there... I would think this is rounding error related. Given that MapServer requires square pixels it may not be possible to achieve a scale exactly with a given aspect ratio.

Steve

[dmorissette]

Can you please provide a test case to reproduce? A small mapfile + PHP script should be enough in this case.

BTW, you marked this ticket as version 5.2. Is this really the version you are using? Would it be possible for you to retest this with a more recent version?

[kfaschoway]

We retested with version 5.4.2 and got the same result. We are in the process of creating a suitable test case.

[aboudreault]

kfaschoway, I would like to check that ticket. Is your test case ready? Thanks!

[kfaschoway]

aboudreault, I have attached test data. Let me know if you need anything else.

[aboudreault]

Is my test script is ok? Is it supposed to fail?

$szMapFile =  "./test.map";
$oMap = ms_newMapObj($szMapFile);
$oMap->draw();
echo "Current Scale: ".$oMap->scaledenom."<br/>";
$p1 = ms_newPointObj();
$p1->setXY(100,50);
$r = ms_newRectObj();
$r->setextent(-1541932.35654056,-1756849.79208326,2966774.81854162, 3051857.38299892);
$oMap->zoomScale(20000000, $p1, 500,700, $r);
$oMap->draw();
echo "Modified Scale: ".$oMap->scaledenom;

output

Current Scale: 28452741.021
Modified Scale: 20000000

[kfaschoway]

I have attached a VS2005 C# app that does similar to your php code but for some reason the scaledenom does not get set to the desired value of 20,000,000. It returns as 20,040,080.1603206.

[dmorissette]

It is possible that PHP MapScript and SWIG MapScript handle things differently. Alan, can you redo the test with Python? That should call more or less the same SWIG wrapper code as C#.

[dmorissette]

May I also ask why this was filed as a PHP MapScript ticket if it happens with C#?

[kfaschoway]

I started it accidentally at MapServer C Library...look at comment 1.

[dmorissette]

Ah, I see that Steve switched the component. Sorry.

[aboudreault]

I confirm that the problem is related to the swig related bindings. Here's the python output:

Current Scale: 28452741.020975
Modified scale: 20040080.160321

[sdlime]

The swig stuff was a straight port of the PHP functions by Sean way back. Does PHP not return the same values as the swig bindings?

Steve

[aboudreault]

Steve, swig and PHP do not return the same values. The problem is that the dfDeltaExt is not calculated as it is in PHP. In PHP (PHP uses its own function to calculate the delta extents using scale: I modified the code below to easily compare it to swig):

dfDeltaExt=scale*((nTmp-1)/(self->resolution*msInchesPerUnit(self->units,dfGeoPosY)));

in the swig function:

dfDeltaExt=scale*nTmp/(self->resolution*msInchesPerUnit(self->units,0));

Is it ok to change the zoomScale function (and all other functions in mapzoom.i: zoomRectangle, etc.) to do the same calcul as PHP does (which I assume the right result) ?

[aboudreault]

FYI, I've already done the test and doing that change make the proper scaledenom after the function call. (Tested in Python).

[sdlime]

Keeping zoomScale consistent across the board is important so your change makes perfect sense to me. We should note the need to change those functions in both places somehow. Perhaps comments in both environments?

Steve

[aboudreault]

The Delta Extents is now calculated the same way as php does. I've also fixed the zoomRectangle function, which had the same bug and also an error check mistake.

Fixed and committed in r9444.