Opened 22 years ago

Closed 20 years ago

Last modified 20 years ago

#75 closed defect (fixed)

strange behaviour when we zoom out beyond the extent

Reported by: assefa Owned by: assefa
Priority: high Milestone:
Component: MapScript-PHP Version: 4.0
Severity: normal Keywords:
Cc: claude.philipona@…, pspencer@…, daniel.faivre@…

Description

I've observed a strange behaviour when we zoom out beyond the extent with
php-mapscript. This problem appears only if the width/height ratio of the EXTENT
is bigger than width/height ratio of the mapsize. Actually the map rendered is
totally off the EXTENT limit. This totally reproducible. Let me explain the
situation more in detail:

PHP-Mapscript used:
MapScript Version (Spet 13, 2001)
MapServer version 3.5 (pre-alpha) OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
SUPPORTS=PROJ SUPPORTS=TTF SUPPORTS=WMS INPUT=EPPL7 INPUT=JPEG INPUT=OGR
INPUT=GDAL INPUT=SHAPEFILE

EXTENT in .map file (unit meters)
490000 70000 840000 310000
MAXSCALE 2000000

which gives
Width_EXTENT: 350000
Height_EXTENT: 240000

Ratio Width_EXTENT/Height_EXTENT= 1.4583

----> CASE 1: ratio_MAPSIZE > ratio_EXTENT (no bug, comportement is normal):
we choose a map size:
Width_MAPSIZE 600
Height_MAPSIZE 400

which gives a ratio of 1.5 so ratio_MAPSIZE > ratio_EXTENT

We assume that the maxscale is set big enough so that when we zoom out, 
mapserver
has to reajust to the EXTENT (in this example 2000000 is ok)

Now we zoom out and we see that everything is normal. It comes a point when
mapserver reajust automatically the BBOX to the EXTENT. The map is always
properly placed inside the extent.
returned BBOX: 490000 70000 840000 310000


----> CASE 2: ratio_MAPSIZE < ratio_EXTENT (buggy):
we choose a map size:
Width_MAPSIZE 600
Height_MAPSIZE 500

which gives a ratio of 1.2 so ratio_MAPSIZE < ratio_EXTENT

We assume that the maxscale is set big enough so that when we zoom out, 
mapserver
has to reajust to the EXTENT (in this example 2000000 is ok)

Now we zoom out and we see that mapserver doesn't reajust properly when go 
beyond
the EXTENT, mapserver doesn't reajust properly to the max EXTENT: Suddenly, 
there
is a strong offset to the top, the map is almost totally off the extent limit. 
If
we take a look at the returned BBOX, we see that mapserver has set y_max_extent
to y_min_bbox, and a strange number to y_max_bbox:
returned BBOX: 490000 310000 840000 361333.33333333


This totally reproducible. I could also reproduce with gmap (with modification 
of
mapsize). I'm almost  sure that it is bug, but not knowing the source code that
well I couldn't find it. It seems to appear at least with zoompoint () and
zoomscale().

Attachments (1)

test_bug_symbolscale.tar.gz (8.0 KB ) - added by claude.philipona@… 21 years ago.
Test case bug symbolscale

Download all attachments as: .zip

Change History (12)

comment:1 by assefa, 22 years ago

Corrected a bug related to zoompoint/zoomscale. (php_mascript.c r1.89).
Claude, If you have the chance please give it a try and let me know. 

comment:2 by assefa, 22 years ago

Resolution: fixed
Status: newclosed
Closing the bug. 

comment:3 by claude.philipona@…, 22 years ago

I finally had the chance to check and the rpoblem seems to be resolved. This 
strange behaviour cannot be reproduced anymore.

comment:4 by claude.philipona@…, 21 years ago

Resolution: fixed
Status: closedreopened
Hello Assefa,
The bug descirbed in this page (bug 75) seems to have come back to life (sinc 
then I don't know excatly. But there is the exact same behaviour with version 
3.6.4 (linux. win not checked). Version seems to have the same symptoms too. I 
didn't check in the source yet.

comment:5 by assefa, 21 years ago

Claude,

 I have done the tests using gmap and setting the map size to 400/400 (which
gives ratio_MAPSIZE < ratio_EXTENT) and trying to zoomout. Results seems to be
correct. 
I have tested this using the latest 3.6 relase on Windows.
Do you have a simple was that I can use to reproduce it ?

comment:6 by assefa, 21 years ago

Cluade Is this still an issue ? If not I will close the bug.

comment:7 by dmorissette, 21 years ago

Cc: morissette@… added
Resolution: wontfix
Status: reopenedclosed
I'll mark as WONTFIX for 3.6.  
Please reopen and provide more details if there is a way to reproduce this with 
version 4.0.  If we reopen then we should also change the bug version to 4.0.

comment:8 by claude.philipona@…, 21 years ago

Resolution: wontfix
Status: closedreopened
Version: 3.54.0
As the problem was persitent, I finally took some time to investigate more in 
details the zoomscale problem.
The problem appears with the use of the fonction "zoomscale", but only when the 
last parameter MaxGeoref extent (rectObj) is used.

Symptom we zoom out, zoomscale doesn't properly set the y extent, when:
- the last parameter MaxGeoref extent (rectObj) is used
AND
- we reach a scale that would lead to an image with too big maxy or too small 
miny compared to the MaxGeoref extent (that comes for example from the EXTENT 
set in mapfile)
AND
- image ratio (width/height) is smaller than MaxGeoref extent ratio.

I will upload a test case and it can also be tested here:
http://c2cpc3.camptocamp.com:85/test3/map_build.php

As it appears only when the last parameter is used, the should come somewhere 
from line 2533-2600 in php_mapscript.c

by claude.philipona@…, 21 years ago

Attachment: test_bug_symbolscale.tar.gz added

Test case bug symbolscale

comment:9 by daniel.faivre@…, 20 years ago

Cc: daniel.faivre@… added
I think that this bug come from line 3049 of php_mapscript.c

        if (self->extent.maxy > poMaxGeorefExt->maxy)
        {
line 3049:  self->extent.miny = poMaxGeorefExt->maxy;
            oNewGeorefExt.miny = oNewGeorefExt.maxy - dfDeltaY;
        }

It should be: self->extent.maxy = poMaxGeorefExt->maxy;

Daniel FAIVRE

comment:10 by assefa, 20 years ago

Resolution: fixed
Status: reopenedclosed
Correction done in current cvs version. Marking it as Fixed.

comment:11 by dmorissette, 20 years ago

Cc: spencer@… added
It seems that this could cause nasty side-effects in some existing apps, so I
have backported the fix to 4.2 as well.
Note: See TracTickets for help on using tickets.