Fix an issue for WMS requests with width or height of 1, which made MapServer throwing an exception 'Invalid image extent, minx=nan, miny=nan, maxx=nan, maxy=nan', because of division by null.
Fix an issue for WMS requests with width or height of 1, which made M…
…apServer throwing an exception 'Invalid image extent, minx=nan, miny=nan, maxx=nan, maxy=nan', because of division by null.
I'm not sure this is the correct fix for this issue, as from what I understand a 1 pixel request is going to be undefined given mapserver's extent model. see also #2843, #2175, #3697, #1916 , #2015 and probably a few others :)
however, as this PR is to fix exceptions to requests that are being sent by existing clients, I think we can afford to be non rigourous, knowing that this will only affect 1px requests.
I'm thinking the right fix is to simply trap the case width=1, height=1 and then set ox=oy=0. The result will be an extent where minx=maxx and miny=maxy, a point (or a single pixel). An extent like that is valid elsewhere in the code. @dmorissette
Now I know where the requests come from: at least QGis 1.8.0 and ArcMap 10 use the max extent from the capabilities document when zooming out and scale down the image size instead - from the view size down to 1x1 pixels. So this behavior won't happen for worldwide dataets, but for small-scaled datasets this error willhappen now and then.
@sdlime Setting ox,oy=0 doesn't work, unfortunately. It's because msAdjustExtent does return nan as cellsize.
Even if the case of 1 pixel is not defined in the current box model, a single pixel will have a cellsize. Actually, min-max, isn't it?
Cellsize should be 0 plus minx=maxx and miny=maxy coming out of this function. If set explicitly does that cause problems elsewhere?
I don't think cellsize should be 0 as this is a WMS request in which minx != maxx, so it does have a cellsize that could be computed from the original WMS BBOX before switching to the MapServer coordinate model as @mkofahl pointed out. Could we not force the return value to be the cellsize computed from the WMS BBOX?
The problem is with this extent model (borrowed from ERDAS back in the day), a cellsize of 0 is correct. If the goal is to get an response then I"m curious what happens with cellsize 0.
From: Daniel Morissette [email@example.com]
Sent: Thursday, April 11, 2013 8:22 AM
Cc: Lime, Steve D (MNIT)
Subject: Re: [mapserver] Bugfix for wms requests with width or height of one (#4629)
I don't think cellsize should be 0 as this is a WMS request in which minx != maxx, so it does have a cellsize that could be computed from the original WMS BBOX before switching to the MapServer coordinate model. Could we not force the return value to be the cellsize computed from the WMS BBOX?
Reply to this email directly or view it on GitHubhttps://github.com/mapserver/mapserver/pull/4629#issuecomment-16233820.
I don't see how cellsize=0 along with minx=maxx and miny=maxy can be anything other than undefined, as you'd be going through the same codepaths if your request is WIDTH=1&HEIGHT=1&BBOX=-180,-90,180,90 and WIDTH=1&HEIGHT=1&BBOX=-1,-1,1,1
stepping through the code...
the failing step may actually be at https://github.com/mapserver/mapserver/blob/master/mapwms.c#L1684 , where the extent is set such that minx=maxx and miny=maxy. From then on it is impossible to compute a valid scale or cellsize.
proposed workaround for #4629
#4632 looks fine to me regarding the reported error.
I didn't test #4632 but it looks like a better fix at first sight. Thank you @tbonfort
Fix for WMS requests with width and height of 1 (#4629)
applied to 6-2 and master in 3d37bd8