WMS client makes non-square pixel request when cascading

[ty_wilson@…]

Problem
We have run into a problem cascading OGC compliant WMSes from USGS while using 
the following configuration of Mapserver:

MapServer version 4.4.0-beta3 OUTPUT=GIF OUTPUT=PNG OUTPUT=WBMP SUPPORTS=PROJ 
SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT INPUT=EPPL7 
INPUT=GDAL INPUT=SHAPEFILE

Explanation
When acting as a WMS client of an OGC compliant WMS that is serving up data in 
a different projection, Mapserver improperly makes a non-square pixel request.  
While the cascaded WMS BBOX request parameter is correctly reprojected and 
defines a new aspect ratio, the corresponding WMS WIDTH and HEIGHT request 
parameters are not.  The original WIDTH and HEIGHT are passed along instead.

Solution
On line #731 of mapwmslayer.c in the function msBuildWMSLayerURL, replace

msSetWMSParamInt(   psWMSParams, "WIDTH",   map->width);

with

msSetWMSParamInt(psWMSParams, "WIDTH",   (int)(map->height * (bbox.maxx-
bbox.minx)/(bbox.maxy-bbox.miny)));

One line #1133, replace

map->width);

with

(int)(map->height * (pasReqInfo[iReq].bbox.maxx-pasReqInfo[iReq].bbox.minx)/
(pasReqInfo[iReq].bbox.maxy-pasReqInfo[iReq].bbox.miny)));

Solution Developers
Ty Wilson and Wim Ibes, with the North Central Research Station of the USDA 
Forest Service, debugged this problem and developed this bug fix.

[dmorissette]

Before we apply the patch, can you please provide a mapfile and corresponding
GetMap request that can be used to reproduce and test this? A mapfile with a
single WMS client layer should be sufficient.

[ty_wilson@…]

Daniel,
 
Here they are.  I've tried to rip out most of the extraneous stuff from 
the mapfile.  I know I didn't get it all, but this should work.  I've 
included a local county boundaries layer that does not get reprojected 
(i.e. it's already in epsg:2163) for comparison.
 
Thanks,
 
-Ty
 
sample.map
******************************************************
#
# Start of map file
#
MAP
 DEBUG ON
  NAME SAMPLE
  STATUS ON
  EXTENT 460000 260000 500000 300000
  UNITS METERS
  SHAPEPATH "data"
  IMAGECOLOR 255 255 255
  TEMPLATEPATTERN "sample"
  IMAGETYPE PNG
 
  #
  # Projection definition, consult the PROJ.4 documentation for 
parameter discussion
  PROJECTION
     "init=epsg:2163"
     "nadgrids=conus"
  END
 
  #
  # Start of web interface definition (including WMS enabling metadata)
  #
  WEB
  LOG "mapserver.log"
    HEADER templates/header.html
    TEMPLATE "set in index.html"
    FOOTER templates/footer.html    
    MINSCALE 1000
    MAXSCALE 1550000
    IMAGEPATH "C:\app\httpd\apache\htdocs\_ms\workshop\tmp\"
    IMAGEURL "/_ms/workshop/tmp/"
    METADATA
      WMS_TITLE "UMN MapServer Itasca Demo"
      WMS_ABSTRACT "This is a UMN MapServer application for Itasca 
County located in north central Minnesota."
      WMS_ACCESSCONSTRAINTS none
      # change this value to match your setup
      WMS_ONLINERESOURCE 
"http://myserver.com/cgi-bin/mapserv.exe?map=C%3A%5Capp%5Chttpd%5Capache%
5Chtdocs%5C_ms%5Cworkshop%5Citasca.map&"
      WMS_SRS "EPSG:2163"
      WFS_TITLE "UMN MapServer Itasca Demo"
      WFS_ONLINERESOURCE 
"http://myserver.com/cgi-bin/mapserv.exe?map=C%3A%5Capp%5Chttpd%5Capache%
5Chtdocs%5C_ms%5Cworkshop%5Citasca.map&"
      OWS_SCHEMAS_LOCATION "http://ogc.dmsolutions.ca"
    END
  END
 
  #
  # Start of layer definitions
  #
 
  LAYER
    NAME "counties"
    TYPE RASTER
    STATUS OFF
    CONNECTION 
"http://gisdata.usgs.net:80/servlet/com.esri.wms.Esrimap?
servicename=USGS_WMS_REF"
    CONNECTIONTYPE WMS
    METADATA
      "wms_srs"             "epsg:4326"
      "wms_name"            "County"
      "wms_title"           "USGS WMS County"
      "wms_server_version"  "1.0.0"
      "wms_format"          "image/png"
      "wms_style"     ""
      "wms_transparent"     "true"
    END
  END
 
  LAYER
    NAME ctybd
    TYPE POLYGON
    STATUS OFF
    DATA cntybd2
       REQUIRES "![drgs]"
    CLASSITEM 'fips'
    CLASS # every other county in the state
      EXPRESSION /./ 
       STYLE 
        OUTLINECOLOR 0 0 255
      END
    END
    DUMP TRUE # allow GML export
    PROJECTION
     "init=epsg:2163"
     "nadgrids=conus"
    END
    METADATA
      WMS_TITLE "Local County Boundary"
      WFS_TITLE "Local County Boundary"
    END
  END
 
END # Map File
 
sample getmap request
*************************************************
myserver.com - - [08/Dec/2004:16:43:07 -0600] "GET 
/cgi-bin/mapserv?map=C%3A%5Capp%5Chttpd%5Capache%5Chtdocs%5C_ms%5Cworkshop%
5Csample.map&SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYERS=counties,ctybd&BBOX
=711789.375,-
892797.28125,2127961.5154303513,87202.71875&WIDTH=867.0441676104191&HEIGHT=600&S
TYLES=&TRANSPARENT=TRUE&format=png24 
HTTP/1.1" 200 118652

[dmorissette]

I made a few tests and it seems that the real problem here is that the remote
server doesn't seems to support non-square pixels (is it really "compliant"?).

If you follow the code in msDrawWMSLayerLow() (mapwmslayer.c), you'll see that
the same map->width and map->height are used to generate a worldfile which is
used to reproject the GetMap image from the remote server. If we applied the
patch that you propose then we would have to change the code that generates the
worldfile as well.

I'm not sure what we should do about this... perhaps we could create a new
metadata that could be set in a WMS client layer to tell MapServer that the
remote WMS server doesn't support non-square pixels?

[ty_wilson@…]

I'm fairly certain the remote server is "compliant".  I've seen the same 
problem with several others as well (USGS, JPL, etc.).  I'm currently away from 
my office so I can't provide you with much to support this claim at the 
moment.  I'll follow up tomorrow. I logged the aspect ratios of initial REQUEST 
image and BBOX as well as cascaded REQUEST image and BBOX.  The first two 
match, the second two don't (hence a non-square pixel request).  The problem is 
that the two image aspect ratios match when they shouldn't.

Regarding your second comment, you will see that I have suggested modifying map-
>width in msDrawWMSLayerLow() accordingly (see the reference to line #1133).  
Those two lines of code (i.e. #731 &  #1133), that scale map->width in order to 
ensure that the cascaded REQUEST map->width/map->height = cascaded REQUEST bbox 
width/height, were all that I changed in order to fix the problem.

[ty_wilson@…]

Oops!  My apologies, you are correct.  The WMS server in question is not OGC-
compliant because it does not support non-square pixel requests.  I mistakenly 
assumed it was because it was an ArcIMS server ;-)  The JPL servers that I 
mentioned are compliant and do not exhibit the same problem.

Interestingly, that misunderstanding is what drove my explanation and, 
therefore, the proposed solution to the given problem.  However, it turns out 
that it is the solution to a different problem, namely the one you mentioned 
regarding creating new metadata for use by Mapserver when calling WMS servers.  

With the proposed solution, that metadata is not necessary.  It appears that 
this fix corrects requests made to servers that don't support non-square pixel 
requests but does not break requests to those that do.  This is actually a 
critical issue for us since much of the data we are cascading comes from ArcIMS 
and pre-4.4.0-beta3 Mapservers.

[hobu]

Reading through, it looks like this bug is invalid because ArcIMS is not WMS compliant. There is a way you can force ArcIMS to do the right thing, and it has been described in a subsequent FAQ.

 http://mapserver.gis.umn.edu/docs/faq/reaspect-false

Or, is this bug being held open to add *client* support for requesting square pixels from non-compliant servers?