On Fri, May 10, 2013 at 1:46 AM, Mark Leslie <mark.les...@lisasoft.com>wrote:
> Here is a Draft GSIP for review. We are proposing to add two optional
> parameters to the GetLegendGraphics handler to allow the specification of a
> bounding box and associated srs. These would then be used to determine
> what symbology will actually be used when rendering a those bounds and
> produce a legend graphic only with what will be displayed on the map.
>
>
> http://geoserver.org/display/GEOS/GSIP+95+-+GetLegendGraphics+BBOX+and+SRS+parameter
>
>
> We are hoping to validate our approach before we quote our customer to
> make sure we're going down the right path, so any feedback would be greatly
> appreciated.
>
The proposal sounds reasonable.
Excluding rasters completely seems imho a bit too much, a simple
implementation that checks the BBOX against the
raster original envelope is just a bit more than a one liner and gets you
90% of the functionality (a full fledged implementation
would have to read a scaled down version in that area and see if the
returned coverage is empty, but it would also fall
prey of different behaviors in the readers, some might return a null value,
others might return a value filled with nodata).
Anyways, your choice, not a blocker, just wanted to point out it might not
be hard at all.
The case of excluding attribute generated by attribute reference is
probably not worth mentioning: the getLegendGraphics
code is not able to generate a legend in that case, at least if the case is
having the attribute in the external graphics url.
If instead we are talking about attribute based filters, I guess combining
them with the bbox will do the trick, no?
As for categorize/interpolate/recode, the current code is not able to
generate a legend anyways.
About the two stage alternative approach that would depend on GSIP 81:
Carlo (cc'ed) abandoned the GSIP
at the community level because of lack of feedback, but he actually
implemented it in a fork of GeoServer
that he's maintaining for a customer and it's in use, don't know if it can
be revived or not.
Ah, one thing performance wise: styles with multiple FeatureTypeStyle tend
to contains the same rule
filters in the different FTS (think of a road style that needs to depict a
highway with cased lines), there
is potential for optimization if the results are somehow cached during the
transformation.
A DuplicatingStyleVisitor subclass should do the trick, and it could
contain, now or in the future, the filter
evaluation caching logic. Just thinking out loud, by no means a requirement.
Cheers
Andrea
--
==
GeoServer training in Milan, 6th & 7th June 2013! Visit
http://geoserver.geo-solutions.it for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
