Reprojected WMS layers lose their layer attributes (esp. transparency)

[tbonfort]

Reporter: pgiencke@glc.org Date: 2005/09/07 - 20:20

When using a WMS layer with a projection that differs from the mapfile's
projection, the mapserver ignores the transparency/etc options for that layer
and simply draws the projected wms layer without options

Based on the some emails from the mailing list, it seems that
msDrawMap() skips msDrawLayer(), and calls
msDrawWMSLayerLow() directly for WMS layers, bypassing the
msDrawLayer() code for handling layer level transparency.

[tbonfort]

Author: dmorissette Date: 2005/09/08 - 19:59

*** Bug 1457 has been marked as a duplicate of this bug. ***

[tbonfort]

Author: dmorissette Date: 2005/09/08 - 20:16

Are you talking about MapServer's layer-level TRANSPARENCY setting or about the
WMS layer's TRANSPARENT=TRUE flag being ignored? 

I think it is true that the layer-level TRANSPARENCY setting has no effect on
WMS layers. Perhaps fixing that could be done at the same time as reworking the
msDrawMap() function in bug 774.

With respect to the WMS GetMap's TRANSPARENT=TRUE flag, by default MapServer
always turns it on in the GetMap request that it sends, so unless you're using a
format that doesn't support transparency (such as JPEG) then transparency should
be maintained. I seem to remember problems with the raster reprojection code
with some flavours of PNG because there are multiple ways to do transparency in
PNG images, but I thought those had been fixed.

I think the best would be if you could provide a complete mapfile that points to
a public WMS server that we can use to reproduce, otherwise there is not much we
can do.

[tbonfort]

Author: assefa Date: 2005/09/26 - 21:07

The layer level transparency was not used for reprojected layers due to a call 
of msDrawRasterLayerLow instead of msDrawLayer which has the transparency 
logic.
The fix was simple enough and should not interfere with bug 774.

Fixed in cvs head.