Opened 14 years ago

Last modified 14 years ago

#3441 new defect

Allow DEFAULT layers to be optionally drawn at the top of a WMS layer list

Reported by: pramsey Owned by: mapserverbugs
Priority: normal Milestone: 6.0 release
Component: WMS Server Version: unspecified
Severity: normal Keywords:
Cc: jmckenna

Description

As it stands now, the logic for WMS layer processing is to first draw all DEFAULT layers, in the order they appear in the map file, then draw the requested WMS layers in the order they are requested. This is fine, mostly, because DEFAULT layers are usually used as an underlay. However, sometimes, in watermarking usually, they are used as an *overlay*.

This patch adds (another) wms_ keyword to the layer metadata options to allow default layers to be drawn last rather than first. The new keyword is

  "wms_watermark" "true" 

Attachments (1)

wms_watermark.patch (2.2 KB ) - added by pramsey 14 years ago.

Download all attachments as: .zip

Change History (6)

by pramsey, 14 years ago

Attachment: wms_watermark.patch added

comment:1 by pramsey, 14 years ago

Any comments / concerns about adding this?

comment:2 by jmckenna, 14 years ago

I did not realize that default layers were actually processed first. (asks myself, is this documented somewhere???)

Otherwise it's a nice addition.

(notes again to myself: this should be mentioned in the FAQ http://www.mapserver.org/faq.html#how-do-i-add-a-copyright-notice-on-the-corner-of-my-map)

comment:3 by sdlime, 14 years ago

I don't get the logic behind drawing all the default layers first. I'd rather change that to something like:

  • default layers defined at the before any requested layers, are drawn first (in mapfile order)
  • then WMS layers in the order requested
  • default layers defined after any requested layers, are drawn last (in mapfile order)

We should be able to figure out the raw layer indexes for the requested layers and then use that to create a proper layer ordering... My 2 cents.

Steve

comment:4 by dmorissette, 14 years ago

There is no logic behind the current approach other than it being a quick solution to avoid what sounded like a complicated problem... Your suggestion sounds great to me. I just wish we thought about it before.

comment:5 by sdlime, 14 years ago

Do you think it's ok to change this behavior? In 5.6? In 6.0? Who can make it?

Steve

Note: See TracTickets for help on using tickets.