Opened 19 years ago
Closed 17 years ago
#1119 closed defect (invalid)
WMS client makes non-square pixel request when cascading
Reported by: | Owned by: | mapserverbugs | |
---|---|---|---|
Priority: | high | Milestone: | 5.0 release |
Component: | WMS Client | Version: | 4.4 |
Severity: | major | Keywords: | |
Cc: |
Description (last modified by )
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.
Change History (6)
comment:2 by , 19 years ago
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
comment:3 by , 19 years ago
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?
comment:4 by , 19 years ago
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.
comment:5 by , 19 years ago
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.
comment:6 by , 17 years ago
Description: | modified (diff) |
---|---|
Resolution: | → invalid |
Status: | assigned → closed |
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?
Note:
See TracTickets
for help on using tickets.