This page last changed on Jun 20, 2013 by jive.

Overview

GetLegendGraphic BBOX+SRS parameter to reflect the map on screen.

Proposed By

Jody Garnett

Assigned to Release

Slated for master release, intended back-port for 2.3.3.

State

Under Discussion, In Progress, Completed, Rejected, Deferred

Motivation

When dealing with complicated styles (1000 line+) the GetLegendGraphic response becomes un-usable due to the large number of Rules involved. While there is some support for a SCALE parameter to automatically filter Rules, this is still not sufficient for complicated styles.

Example

This proposal is to cut down the GetLegendGraphic result reflect only the features that are drawn on screen.

This proposal is in the discussion phase to confirm scope with customer, scope and funding TBD.

Proposal

This proposal intends to treat GetLegendGraphics in a similar fashion to GetFeatureInfo (providing additional parameters from the associated GetMapRequest to allow the result to more accurately be determined).

BEFORE AFTER

The above style can be simplified using the SCALE parameter, however when zoomed into an area that does not show landmarks an alternate approach is needed.

  • BBOX - defined as per GetFeatuerInfo/GetMap
  • SRS - defined as per GetFeatureInfo/GetMap
  • And can benefit from the following additions
    • WIDTH / HEIGHT / DPI from GetMap can be used to calculate the scale
    • SCALE - scale override

Note in the event of conflict (say on width and height) we can use LegendOptions.

The following work is expected:

  1. Parse additional GetMap parameters
    • Establish bounds (using BBOX and SRS)
    • Calculate SCALE (or use user supplied value)
  2. For each Layer:
    1. Short List Rules
      • Process Rules according to SCALE
      • Construct a Query for Each remaining Rule
      • Check if resulting FeatureCollection isEmpty()
    2. Cut down the style to only list the short-listed rules
  3. Pass the Resulting Layers+Styles to the normal GetLegendGraphics code

And update the documentation with an example:

Excluded:

  • Exclude case-by-case PointSymbolizer graphics generated by attribute reference. While this would be nice, it is not needed by our customer at this time.
    To implement we would need to fetch all the features, and process down to the PointSymbolizer level in order to short-list unique Graphics generated and come up with a Set of Symbols for each Rule. Not quite sure how to determine name for each symbol.
  • Exclude limiting the raster legend to the current map. (This proposal is limited to feature content).
  • Exclude themes generated using Categorize, Interpolate and Recode. Current work is limited to representation of Rules only. Note the rendering code is in place to handle these functions, but as of yet they are not in common use.
    • Recode represented as per Raster Legend VALUES
    • Interpolate represented as per Raster Legend RAMP
    • Catergorize represented as per Raster Legend CLASSES

Alternatives:

  • Alternative: Two stages, first stage with WPS to generate a JSON recipe for the legend graphic, second stage would be to submit the JSON recipe to GSIP 81 - GetLegendGraphic as text (JSON). This is too risky as the status of GSIP 81 is unknown.

Feedback

This section should contain feedback provided by PSC members who may have a problem with the proposal.

Backwards Compatibility

This functionality is only engaged when the optional parameters are supplied, leaving no known backwards compatibility issues.

This section may need updating if any changes are required to utility classes.

Voting

Alessio Fabiani:
Andrea Aime:
Ben Caradoc-Davies:
Christian Mueller:
Gabriel Roldán:
Jody Garnett:
Jukka Rahkonen:
Justin Deoliveira:
Phil Scadden:
Simone Giannecchini:

Links

[JIRA Task|]
[Email Discussion|]
[Wiki Page|]


TigerNY.png (image/png)
TigerNYFiltered.png (image/png)
GeolUnitGetLegendGraphic.png (image/png)
Document generated by Confluence on May 14, 2014 23:00