GetLegendGraphic and LAYER parameter

[Bart van den Eijnden]

Hi list,

is there any work ongoing with SLD WMS (that determines if it's worthwile
to write up a change request for this).

Currently GetLegendGraphic only accepts 1 LAYER, and uses the parameter
named LAYER.

IMHO it would be great if GetLegendGraphic could accept multiple
comma-separated LAYERS like other WMS interfaces. This makes grouping of
layer client-side easier, i.e. if all interfaces behave in the same way and
parameter names are similar.

Another question, wfs-dev was migrated to the OGC public mailing lists, why
was wms-dev not migrated?

Best regards,
Bart

_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev

[Keith Pomakis]

bartvde@... wrote:

> is there any work ongoing with SLD WMS (that determines if it's worthwile
> to write up a change request for this).
>
> Currently GetLegendGraphic only accepts 1 LAYER, and uses the parameter
> named LAYER.
>
> IMHO it would be great if GetLegendGraphic could accept multiple
> comma-separated LAYERS like other WMS interfaces. This makes grouping of
> layer client-side easier, i.e. if all interfaces behave in the same way
> and parameter names are similar.

CubeWerx's approach to this was to define a vendor-specific GetLegend
request that accepts the following parameters:

      SERVICE=WMS
     &VERSION=<versionNumber>
     &REQUEST=GetLegend
     &LAYERS=<layerName>[,<layerName>...]
    [&STYLES=<styleName>[,<styleName>...]]
    [&SLD=<sldUrl>]
    [&SLD_BODY=<inlineSld>]
    [&SCALE=<scale>]
    [&FORMAT=<imageFormat>
    [&TITLE=<title>]
    [&BGCOLOR=0xRRGGBB]
    [&TEXTCOLOR=0xRRGGBB]
    [&TRANSPARENT={TRUE|FALSE}]
    [&EXCEPTIONS={INIMAGE|BLANK|WMS_XML|HTML|TEXT}]

As an alternative to SCALE, the client can instead pass the BBOX,
CRS, WIDTH and HEIGHT parameters of the corresponding GetMap request.
This has the added advantage that the server could conceivably generate
location-sensitive legends.

The difference between GetLegendGraphic and GetLegend is that
GetLegendGraphic returns only the icon representing the layer, leaving
it to the client application to label it with the layer name and to lay
out a legend appropriately, whereas GetLegend returns a fully-assembled
legend, complete with layer titles (rendered into the image) and even
an optional legend title.

Here's a live example:

    http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?CONFIG=gita&SERVICE=WMS&VERSION=1.3.2&LANGUAGE=en-CA,en-US,en&REQUEST=GetLegend&LAYERS=CENART%3AAustin,HYDRO_L%3AAustin,STREETCL%3AAustin,LANDUSE_90%3AAustin&STYLES=,,,&SCALE=25000&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DRGB&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

We have found that using GetLegend rather than GetLegend results in a
snappier user interface and puts less load on the server because only one
request has to be made to generate a legend, as apposed to one per layer.
A disadvantage, however, is that the client application doesn't have
full control over the look-and-feel of the legend (and can't make the
layer titles hyperlinks, etc.).

I would love to see this (or something similar) make it into the
specification.

.-------------------------------------------+-------------------------------.
| Keith Pomakis                             | E-mail: pomakis@...  |
| Senior Software Developer, CubeWerx Inc.  | Phone:  [phone] x204   |
| 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    [phone]        |
`---------------------------------------------------------------------------'
_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev

[Bart van den Eijnden]

Hi Keith,

in my experience there is also more useage of 1 legend image per layer, as
opposed to 1 legend image per key/rule. I have not seen a single
implementation where the legend is build client-side using this technique.
Is any example known to you?

Currently the GetLegendGraphic request is a bit polluted with functionality
from your GetLegend request, since if you leave out the Rule, you need to
get an image representative of all the rules, which basically is the result
of GetLegend.

I do agree it makes a lot of sense to have a BBOX in there so
view-dependent legends can be created.

It would be great if this can be "cleared up" in a future version of the
spec (but I would be in favour of having this in 1 request instead of
adding another similar request).

Best regards,
Bart

On Wed, 7 May 2008 09:39:54 -0400, Keith Pomakis <pomakis@...>
wrote:

> bartvde@... wrote:
>> is there any work ongoing with SLD WMS (that determines if it's
> worthwile
>> to write up a change request for this).
>>
>> Currently GetLegendGraphic only accepts 1 LAYER, and uses the parameter
>> named LAYER.
>>
>> IMHO it would be great if GetLegendGraphic could accept multiple
>> comma-separated LAYERS like other WMS interfaces. This makes grouping of
>> layer client-side easier, i.e. if all interfaces behave in the same way
>> and parameter names are similar.
>
> CubeWerx's approach to this was to define a vendor-specific GetLegend
> request that accepts the following parameters:
>
>       SERVICE=WMS
>      &VERSION=<versionNumber>
>      &REQUEST=GetLegend
>      &LAYERS=<layerName>[,<layerName>...]
>     [&STYLES=<styleName>[,<styleName>...]]
>     [&SLD=<sldUrl>]
>     [&SLD_BODY=<inlineSld>]
>     [&SCALE=<scale>]
>     [&FORMAT=<imageFormat>
>     [&TITLE=<title>]
>     [&BGCOLOR=0xRRGGBB]
>     [&TEXTCOLOR=0xRRGGBB]
>     [&TRANSPARENT={TRUE|FALSE}]
>     [&EXCEPTIONS={INIMAGE|BLANK|WMS_XML|HTML|TEXT}]
>
> As an alternative to SCALE, the client can instead pass the BBOX,
> CRS, WIDTH and HEIGHT parameters of the corresponding GetMap request.
> This has the added advantage that the server could conceivably generate
> location-sensitive legends.
>
> The difference between GetLegendGraphic and GetLegend is that
> GetLegendGraphic returns only the icon representing the layer, leaving
> it to the client application to label it with the layer name and to lay
> out a legend appropriately, whereas GetLegend returns a fully-assembled
> legend, complete with layer titles (rendered into the image) and even
> an optional legend title.
>
> Here's a live example:
>
>    
>

http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?CONFIG=gita&SERVICE=WMS&VERSION=1.3.2&LANGUAGE=en-CA,en-US,en&REQUEST=GetLegend&LAYERS=CENART%3AAustin,HYDRO_L%3AAustin,STREETCL%3AAustin,LANDUSE_90%3AAustin&STYLES=,,,&SCALE=25000&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DRGB&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

>
> We have found that using GetLegend rather than GetLegend results in a
> snappier user interface and puts less load on the server because only one
> request has to be made to generate a legend, as apposed to one per layer.
> A disadvantage, however, is that the client application doesn't have
> full control over the look-and-feel of the legend (and can't make the
> layer titles hyperlinks, etc.).
>
> I would love to see this (or something similar) make it into the
> specification.
>
>

.-------------------------------------------+-------------------------------.
> | Keith Pomakis                             | E-mail:
pomakis@...
>  |
> | Senior Software Developer, CubeWerx Inc.  | Phone:  [phone] x204

>  |
> | 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    [phone]    

>   |
>
`---------------------------------------------------------------------------'

_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev

[Bart van den Eijnden]

<20080507133954.GA23976@...> <9836c3dbba8842e5f5ba065cdf2a9632@...>
Message-ID: <9b6012efa2c2a88616f74c58c50a400d@...>
X-Sender: bartvde@...
Received: from b50-11.minvenw.nl [145.50.39.11] with HTTP/1.1 (POST); Wed, 07
        May 2008 16:29:20 +0200
User-Agent: RoundCube Webmail/0.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Additionally it would be great if you could request for higher resolution
legend images to use in e.g. PDF documents. Now the server determines the
width and height of the image, which is a bit limiting for print
production.

Best regards,
Bart

On Wed, 07 May 2008 16:21:26 +0200, <bartvde@...> wrote:
> Hi Keith,
>
> in my experience there is also more useage of 1 legend image per layer,
as
> opposed to 1 legend image per key/rule. I have not seen a single
> implementation where the legend is build client-side using this
technique.

> Is any example known to you?
>
> Currently the GetLegendGraphic request is a bit polluted with
> functionality
> from your GetLegend request, since if you leave out the Rule, you need to
> get an image representative of all the rules, which basically is the
> result
> of GetLegend.
>
> I do agree it makes a lot of sense to have a BBOX in there so
> view-dependent legends can be created.
>
> It would be great if this can be "cleared up" in a future version of the
> spec (but I would be in favour of having this in 1 request instead of
> adding another similar request).
>
> Best regards,
> Bart
>
> On Wed, 7 May 2008 09:39:54 -0400, Keith Pomakis <pomakis@...>
> wrote:
>> bartvde@... wrote:
>>> is there any work ongoing with SLD WMS (that determines if it's
>> worthwile
>>> to write up a change request for this).
>>>
>>> Currently GetLegendGraphic only accepts 1 LAYER, and uses the parameter
>>> named LAYER.
>>>
>>> IMHO it would be great if GetLegendGraphic could accept multiple
>>> comma-separated LAYERS like other WMS interfaces. This makes grouping
> of
>>> layer client-side easier, i.e. if all interfaces behave in the same way
>>> and parameter names are similar.
>>
>> CubeWerx's approach to this was to define a vendor-specific GetLegend
>> request that accepts the following parameters:
>>
>>       SERVICE=WMS
>>      &VERSION=<versionNumber>
>>      &REQUEST=GetLegend
>>      &LAYERS=<layerName>[,<layerName>...]
>>     [&STYLES=<styleName>[,<styleName>...]]
>>     [&SLD=<sldUrl>]
>>     [&SLD_BODY=<inlineSld>]
>>     [&SCALE=<scale>]
>>     [&FORMAT=<imageFormat>
>>     [&TITLE=<title>]
>>     [&BGCOLOR=0xRRGGBB]
>>     [&TEXTCOLOR=0xRRGGBB]
>>     [&TRANSPARENT={TRUE|FALSE}]
>>     [&EXCEPTIONS={INIMAGE|BLANK|WMS_XML|HTML|TEXT}]
>>
>> As an alternative to SCALE, the client can instead pass the BBOX,
>> CRS, WIDTH and HEIGHT parameters of the corresponding GetMap request.
>> This has the added advantage that the server could conceivably generate
>> location-sensitive legends.
>>
>> The difference between GetLegendGraphic and GetLegend is that
>> GetLegendGraphic returns only the icon representing the layer, leaving
>> it to the client application to label it with the layer name and to lay
>> out a legend appropriately, whereas GetLegend returns a fully-assembled
>> legend, complete with layer titles (rendered into the image) and even
>> an optional legend title.
>>
>> Here's a live example:
>>
>>    
>>
>

http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?CONFIG=gita&SERVICE=WMS&VERSION=1.3.2&LANGUAGE=en-CA,en-US,en&REQUEST=GetLegend&LAYERS=CENART%3AAustin,HYDRO_L%3AAustin,STREETCL%3AAustin,LANDUSE_90%3AAustin&STYLES=,,,&SCALE=25000&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DRGB&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

>>
>> We have found that using GetLegend rather than GetLegend results in a
>> snappier user interface and puts less load on the server because only
> one
>> request has to be made to generate a legend, as apposed to one per
> layer.
>> A disadvantage, however, is that the client application doesn't have
>> full control over the look-and-feel of the legend (and can't make the
>> layer titles hyperlinks, etc.).
>>
>> I would love to see this (or something similar) make it into the
>> specification.
>>
>>
>

.-------------------------------------------+-------------------------------.

>> | Keith Pomakis                             | E-mail:
> pomakis@...
>>  |
>> | Senior Software Developer, CubeWerx Inc.  | Phone:  [phone]
> x204
>
>>  |
>> | 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    [phone]  
>
>
>>   |
>>
>

`---------------------------------------------------------------------------'
>
> _______________________________________________
> wms-dev mailing list
> wms-dev@...
> http://lists.eogeo.org/mailman/listinfo/wms-dev
>

_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev

[Jon Blower]

Dear all,

I agree strongly that the GetLegendGraphic operation, and indeed SLD
and portrayal in general in WMS, needs attention.  GLG clearly needs
more flexibility (it's hard to design clients properly when the server
makes decisions about legend formatting and even size).

Regards, Jon

On Wed, May 7, 2008 at 3:29 PM,  <bartvde@...> wrote:

> <20080507133954.GA23976@...> <9836c3dbba8842e5f5ba065cdf2a9632@...>
>  Message-ID: <9b6012efa2c2a88616f74c58c50a400d@...>
>  X-Sender: bartvde@...
>  Received: from b50-11.minvenw.nl [145.50.39.11] with HTTP/1.1 (POST); Wed, 07
>         May 2008 16:29:20 +0200
>  User-Agent: RoundCube Webmail/0.1
>  Content-Type: text/plain; charset="UTF-8"
>  Content-Transfer-Encoding: 8bit
>
>  Additionally it would be great if you could request for higher resolution
>  legend images to use in e.g. PDF documents. Now the server determines the
>  width and height of the image, which is a bit limiting for print
>  production.
>
>  Best regards,
>  Bart
>
>
>
>  On Wed, 07 May 2008 16:21:26 +0200, <bartvde@...> wrote:
>  > Hi Keith,
>  >
>  > in my experience there is also more useage of 1 legend image per layer,
>  as
>  > opposed to 1 legend image per key/rule. I have not seen a single
>  > implementation where the legend is build client-side using this
>  technique.
>  > Is any example known to you?
>  >
>  > Currently the GetLegendGraphic request is a bit polluted with
>  > functionality
>  > from your GetLegend request, since if you leave out the Rule, you need to
>  > get an image representative of all the rules, which basically is the
>  > result
>  > of GetLegend.
>  >
>  > I do agree it makes a lot of sense to have a BBOX in there so
>  > view-dependent legends can be created.
>  >
>  > It would be great if this can be "cleared up" in a future version of the
>  > spec (but I would be in favour of having this in 1 request instead of
>  > adding another similar request).
>  >
>  > Best regards,
>  > Bart
>  >
>  > On Wed, 7 May 2008 09:39:54 -0400, Keith Pomakis <pomakis@...>
>  > wrote:
>  >> bartvde@... wrote:
>  >>> is there any work ongoing with SLD WMS (that determines if it's
>  >> worthwile
>  >>> to write up a change request for this).
>  >>>
>  >>> Currently GetLegendGraphic only accepts 1 LAYER, and uses the parameter
>  >>> named LAYER.
>  >>>
>  >>> IMHO it would be great if GetLegendGraphic could accept multiple
>  >>> comma-separated LAYERS like other WMS interfaces. This makes grouping
>  > of
>  >>> layer client-side easier, i.e. if all interfaces behave in the same way
>  >>> and parameter names are similar.
>  >>
>  >> CubeWerx's approach to this was to define a vendor-specific GetLegend
>  >> request that accepts the following parameters:
>  >>
>  >>       SERVICE=WMS
>  >>      &VERSION=<versionNumber>
>  >>      &REQUEST=GetLegend
>  >>      &LAYERS=<layerName>[,<layerName>...]
>  >>     [&STYLES=<styleName>[,<styleName>...]]
>  >>     [&SLD=<sldUrl>]
>  >>     [&SLD_BODY=<inlineSld>]
>  >>     [&SCALE=<scale>]
>  >>     [&FORMAT=<imageFormat>
>  >>     [&TITLE=<title>]
>  >>     [&BGCOLOR=0xRRGGBB]
>  >>     [&TEXTCOLOR=0xRRGGBB]
>  >>     [&TRANSPARENT={TRUE|FALSE}]
>  >>     [&EXCEPTIONS={INIMAGE|BLANK|WMS_XML|HTML|TEXT}]
>  >>
>  >> As an alternative to SCALE, the client can instead pass the BBOX,
>  >> CRS, WIDTH and HEIGHT parameters of the corresponding GetMap request.
>  >> This has the added advantage that the server could conceivably generate
>  >> location-sensitive legends.
>  >>
>  >> The difference between GetLegendGraphic and GetLegend is that
>  >> GetLegendGraphic returns only the icon representing the layer, leaving
>  >> it to the client application to label it with the layer name and to lay
>  >> out a legend appropriately, whereas GetLegend returns a fully-assembled
>  >> legend, complete with layer titles (rendered into the image) and even
>  >> an optional legend title.
>  >>
>  >> Here's a live example:
>  >>
>  >>
>  >>
>  >
>  http://demo.cubewerx.com/demo/cubeserv/cubeserv.cgi?CONFIG=gita&SERVICE=WMS&VERSION=1.3.2&LANGUAGE=en-CA,en-US,en&REQUEST=GetLegend&LAYERS=CENART%3AAustin,HYDRO_L%3AAustin,STREETCL%3AAustin,LANDUSE_90%3AAustin&STYLES=,,,&SCALE=25000&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DRGB&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE
>  >>
>  >> We have found that using GetLegend rather than GetLegend results in a
>  >> snappier user interface and puts less load on the server because only
>  > one
>  >> request has to be made to generate a legend, as apposed to one per
>  > layer.
>  >> A disadvantage, however, is that the client application doesn't have
>  >> full control over the look-and-feel of the legend (and can't make the
>  >> layer titles hyperlinks, etc.).
>  >>
>  >> I would love to see this (or something similar) make it into the
>  >> specification.
>  >>
>  >>
>  >
>  .-------------------------------------------+-------------------------------.
>  >> | Keith Pomakis                             | E-mail:
>  > pomakis@...
>  >>  |
>  >> | Senior Software Developer, CubeWerx Inc.  | Phone:  [phone]
>  > x204
>  >
>  >>  |
>  >> | 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    [phone]
>  >
>  >
>  >>   |
>  >>
>  >
>  `---------------------------------------------------------------------------'
>  >
>  > _______________________________________________
>  > wms-dev mailing list
>  > wms-dev@...
>  > http://lists.eogeo.org/mailman/listinfo/wms-dev
>  >
>
>
> _______________________________________________
>  wms-dev mailing list
>  wms-dev@...
>  http://lists.eogeo.org/mailman/listinfo/wms-dev
>
>

--
--------------------------------------------------------------
Dr Jon Blower Tel: [phone] (direct line)
Technical Director Tel: [phone] (ESSC)
Reading e-Science Centre Fax: [phone]
ESSC Email: jdb@...
University of Reading
3 Earley Gate
Reading RG6 6AL, UK
--------------------------------------------------------------
_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev

[Keith Pomakis]

bartvde@... wrote:
> in my experience there is also more useage of 1 legend image per layer,
> as opposed to 1 legend image per key/rule. I have not seen a single
> implementation where the legend is build client-side using this
> technique.  Is any example known to you?

More correctly, the most common use of GetLegendGraphic (I believe) is to
produce one legend image per layer AT A PARTICULAR SCALE.  This may match
several SLD rules, which would each be represented in the resulting image.

For example,

    http://frameworkwfs.usgs.gov/framework/wms/wms.cgi?SERVICE=WMS&VERSION=1.3.2&LANGUAGE=en-CA,en-US,en&REQUEST=GetLegendGraphic&LAYER=ROADS%3AFramework&STYLE=&SCALE=700000&FORMAT=image%2Fpng%3B+PhotometricInterpretation%3DRGB&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

versus:

    http://frameworkwfs.usgs.gov/framework/wms/wms.cgi?SERVICE=WMS&VERSION=1.3.2&REQUEST=GetLegendGraphic&LAYER=ROADS%3AFramework&STYLE=&SCALE=50000&FORMAT=image%2Fpng&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

If the SCALE parameter is omitted, all rules (regardless of scale) are
represented:

    http://frameworkwfs.usgs.gov/framework/wms/wms.cgi?SERVICE=WMS&VERSION=1.3.2&REQUEST=GetLegendGraphic&LAYER=ROADS%3AFramework&STYLE=&FORMAT=image%2Fpng&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

(In this situation, this particular server annotates the rule titles with
the scale ranges of the rules.  However, the specification doesn't require
this.)

While there is a RULE parameter that can be used to specify an exact rule
to generate an image for, this parameter isn't very useful for generic
WMS clients.  It requires the client to know what the rule names are,
which it can't unless either it's passing around a client-defined SLD
document or it performs a GetStyles request on the server (if the server
supports it) and analyzes the SLD document itself.  Fancy clients that
don't mind going through this extra work, though, can utilize the RULE
parameter so that it has more control over the general layout of the
legend.

> Currently the GetLegendGraphic request is a bit polluted with
> functionality from your GetLegend request, since if you leave out the
> Rule, you need to get an image representative of all the rules, which
> basically is the result of GetLegend.

No, the point of GetLegend isn't to generate an legend icon
representative of all the rules of a layer.  It's to generate an image
of a fully-assembled legend containing all of the selected layers (for
a particular scale, generally).

http://frameworkwfs.usgs.gov/framework/wms/wms.cgi?SERVICE=WMS&VERSION=1.3.2&REQUEST=GetLegend&LAYERS=STATE_OR_TERRITOR%3AFramework,ROADS%3AFramework,graticule%3AMapAnnotations&STYLES=,,&SCALE=1000000&FORMAT=image%2Fpng&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE

So I don't think the GetLegendGraphic request is polluted at all.  It has
all of the functionality for (and only functionality specifically for)
requesting the representative icon(s) for a single layer.

Now it MAY make sense to augment the GetLegendGraphic request so that it
also has the functionality of the GetLegend request (i.e., generating a
fully-assembled legend) rather than having two separate requests.  But
at the very least it's important that we remain clear about the
differences between returning a legend component and a complete legend.

.-------------------------------------------+-------------------------------.
| Keith Pomakis                             | E-mail: pomakis@...  |
| Senior Software Developer, CubeWerx Inc.  | Phone:  [phone] x204   |
| 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    [phone]        |
`---------------------------------------------------------------------------'
_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev

[Keith Pomakis]

bartvde@... wrote:
> Additionally it would be great if you could request for higher resolution
> legend images to use in e.g. PDF documents. Now the server determines the
> width and height of the image, which is a bit limiting for print
> production.

Yes, this is certainly worth considering.  This actually ties into a
change proposal that the WMS group is discussing for the next WMS
specification.  In a nutshell, it's the addition of an optional GetMap
parameter called PIXEL_SIZE or DISPLAY_RESOLUTION (I can't remember which
was decided upon), whose value is defined as "the size in millimeters of
an individual pixel of the intended display".  The default value of this
parameter is 0.28mm, which is consistent with the current SLD
specifications.  This parameter allows the server to adjust the
thickness (in pixels) of things appropriately (and in the case of a
GetLegendGraphic request, could allow the server to appropriately adjust
the size (in pixels) of the whole image as well).  For example, if the
server knows that it wants a certain line to be about 1mm thick, it could
render it four pixels thick by default, but if a high-resolution client
comes along and says PIXEL_SIZE=0.085 (which is about 300dpi), the server
can know to render the line 12 pixels thick.

Another alternative, of course, is for the GetLegendGraphic request to
support a vector format such as SVG.

.-------------------------------------------+-------------------------------.
| Keith Pomakis                             | E-mail: pomakis@...  |
| Senior Software Developer, CubeWerx Inc.  | Phone:  [phone] x204   |
| 15 rue Gamelin, Gatineau, Québec J8Y 3B5  | Fax:    [phone]        |
`---------------------------------------------------------------------------'
_______________________________________________
wms-dev mailing list
wms-dev@...
http://lists.eogeo.org/mailman/listinfo/wms-dev