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 , 15 years ago
comment:2 by , 15 years ago
Cc: | added |
---|
comment:3 by , 15 years ago
Cc: | added |
---|---|
Milestone: | → 5.6 release |
Is this something you could check Frank?
follow-up: 5 comment:4 by , 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).
follow-up: 6 comment:5 by , 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
comment:6 by , 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 , 14 years ago
Milestone: | 5.6 release → 6.0 release |
---|
comment:8 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.
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.