Opened 15 years ago

Closed 14 years ago

#3138 closed defect (fixed)

WMS Client w/resampling results in stretched image

Reported by: jimk Owned by: mapserverbugs
Priority: normal Milestone: 6.0 release
Component: WMS Client Version: svn-trunk (development)
Severity: normal Keywords:
Cc: sdlime, warmerdam, aboudreault

Description

Using MapServer as a WMS client (from at least as far back as 4.10.0 up to trunk), with the layer projection == the remote WMS server projection == the map projection, and PROCESSING "RESAMPLE=[anything]" returns oddly stretched images for many (but not necessarily all) combinations of mapext/mapsize.

Changing any of the layer projection (and WMS server projection), map projection, or removing the PROCESSING line results in a normal image.

It looks like the calculation of RAW_WINDOW is messed up because in the case of src=dest projections, the RAW_WINDOW should be the entire source image requested from the WMS server.

Note: the image requested from the WMS server (from the URL listed in the debug output) is as expected.

This looks like it may be related to #723, #771, #773 but seems slightly different. I have checked that IMAGEPATH is set correctly, however I do not see a .wld file being created. This appears to be because in msDrawWMSLayerLow (mapwmslayer.c:1352) it skips setting up the .wld file if the projections match, but the resampling code depends on the world file (so GDAL can setup the GeoTransforms)

[Tue Sep 29 14:49:29 2009].200062 HTTP request: id=97, http://gis...
 ...
[Tue Sep 29 14:49:31 2009].256242 HTTP: After download loop
[Tue Sep 29 14:49:31 2009].256281 msHTTPExecuteRequests() timing summary per layer...
[Tue Sep 29 14:49:31 2009].256392 Layer 97: 0.001 + 1.698 + 0.351 = 2.050s
[Tue Sep 29 14:49:31 2009].256738 msDrawRasterLayerLow(L.13.1.2): entering.
[Tue Sep 29 14:49:31 2009].336151 msResampleGDALToMap in effect: cellsize = 373.247033
[Tue Sep 29 14:49:31 2009].336908 msDrawGDAL(L.13.1.2): using RAW_WINDOW=524 486 157 304
[Tue Sep 29 14:49:31 2009].336984 msDrawGDAL(): red,green,blue,alpha bands = 1,2,3,4
[Tue Sep 29 14:49:31 2009].911886 msDrawMap(): Layer 97 (L.13.1.2), 0.655s
[Tue Sep 29 14:49:31 2009].911994 msDrawMap(): Drawing Label Cache, 0.000s
[Tue Sep 29 14:49:31 2009].912036 msDrawMap() total time: 2.739s
[Tue Sep 29 14:49:32 2009].60215 msSaveImage() total time: 0.148s
[Tue Sep 29 14:49:32 2009].60531 mapserv request processing time (loadmap not incl.): 2.888s

Lines around mapwmslayer.c:1352 (for reference)

    if (lp->data) free(lp->data);
    lp->data =  strdup(pasReqInfo[iReq].pszOutputFile);

    if (!msProjectionsDiffer(&(map->projection), &(lp->projection)))
    {
        /* The simple case... no reprojection needed... render layer directly. */
        lp->transform = MS_FALSE;
        /* if (msDrawRasterLayerLow(map, lp, img) != 0) */
        /* status = MS_FAILURE; */

Change History (8)

comment:1 by jimk, 15 years ago

Always performing the else clause of the if statement at mapwmslayer.c:1352 resolves the problem, but is probably less efficient that it should be.

comment:2 by sdlime, 15 years ago

Cc: warmerdam added

comment:3 by dmorissette, 15 years ago

Cc: aboudreault added
Milestone: 5.6 release

Is this something you could check Frank?

comment:4 by warmerdam, 15 years ago

Going through the general resampling case is quite expensive from a performance point of view, so lets not go this way too quickly.

I would like to see an example of the problem this bug is about. We would need a map file referencing a public WMS and the mapserv QUERY_STRING (url) that produces the odd output. It would also be helpful to have an image which is the results you get, and another that is the result you expect (which you might generate by commenting out the call noted above).

in reply to:  4 ; comment:5 by jimk, 15 years ago

Replying to warmerdam:

I think the key here is the raster resampling code expects the source image (returned by the WMS server and saved in IMAGEPATH) to have a valid geotransform and that doesn't happen unless MapServer also places a world file next to the source image and MapServer currently doesn't place a world file next to the source image unless the projections differ.

If "PROCESSING RESAMPLE=..." is not given, then things work fine as is (because the resampling code is never triggered). I don't want to slow down this case.

With the following example in trunk I get a white image with resampling and a correct image without resampling (comment out the processing line). With the "fix" I get a correct image with and without resampling.

MAP

#QUERY_STRING="map=test.map&layers=all&mapsize=600+600&mapext=491800+4976300+493800+4978300"

NAME 'WMS'
IMAGETYPE JPEG

PROJECTION
        "init=epsg:26915"
END

WEB
    IMAGEPATH "/tmp"
END

LAYER
  NAME 'fsa2008'
  STATUS DEFAULT
  TYPE RASTER
  CONNECTIONTYPE WMS
  CONNECTION 'http://geoint.lmic.state.mn.us/cgi-bin/wms?'
  PROJECTION
        "init=epsg:26915"
  END
  METADATA
    "wms_server_version" "1.1.1"
    "wms_srs" "EPSG:26915"
    "wms_format" "image/jpeg"
    "wms_name" "fsa2008"
  END
  PROCESSING "RESAMPLE=AVERAGE"
END

END

in reply to:  5 comment:6 by jimk, 15 years ago

BTW: I found this while setting up MapServer as a WMS proxy so that I could re-project external WMS services to additional coordinate systems than what they directly provide. I wanted PROCESSING "RESAMPLE=AVERAGE" so that labels and line work stayed more readable than with the default. I noticed the problem when I asked requested through the proxy when using the native projection of the source layer.

comment:7 by dmorissette, 14 years ago

Milestone: 5.6 release6.0 release

comment:8 by jimk, 14 years ago

Resolution: fixed
Status: newclosed

Fixed in r9839.

Changed it to create a world file if a re-projection is necessary or if resampling is requested. If projections match and no resampling is requested the "fast" code path will continue to be used.

Note: See TracTickets for help on using tickets.