Ticket #75 (closed defect: fixed)

Opened 12 years ago

Last modified 9 years ago

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

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

Change History

Changed 11 years ago by assefa

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. 

Changed 11 years ago by assefa

  • status changed from new to closed
  • resolution set to fixed
Closing the bug. 

Changed 11 years ago by claude.philipona@…

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

Changed 10 years ago by claude.philipona@…

  • status changed from closed to reopened
  • resolution fixed deleted
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.

Changed 10 years ago by assefa

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 ?

Changed 10 years ago by assefa

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

Changed 10 years ago by dmorissette

  • cc morissette@… added
  • status changed from reopened to closed
  • resolution set to wontfix
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.

Changed 10 years ago by claude.philipona@…

  • status changed from closed to reopened
  • version changed from 3.5 to 4.0
  • resolution wontfix deleted
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

Changed 10 years ago by claude.philipona@…

Test case bug symbolscale

Changed 9 years ago by daniel.faivre@…

  • 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

Changed 9 years ago by assefa

  • status changed from reopened to closed
  • resolution set to fixed
Correction done in current cvs version. Marking it as Fixed.

Changed 9 years ago by dmorissette

  • 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.