[Geoserver-devel] Style with pre-rendered legend

GeoServer GeoServer Developer
1

Hi,
among the current pull requests we have this one about having legends URL in capabilities
documents use a pre-cooked image.

The idea is pretty useful, sometimes GeoServer cannot generate a good legend for a layer,
and hand painted once often look better regardless.

The implementation pretty much gives UI to a LegendInfo object that we have in the model,
and which has been sitting doing nothing for ages (afaik).

The style page has a new element to add a legend:

Inline image 1

What is giving me pause is what you get when you click on “add legend”:

Inline image 2

So, basically one has to specify a remote url that will generate the legend image.
Now, this is no GUI’s fault per se, the LegendInfo object has those exact fields, and the code
in the GetCapabilities generators use LegendInfo url/width/height/format to build the
proper links.

However… it seems to be it’s quite against the general GeoServer philosophy to ask someone
to stand up a separate server to use pre-rendered legends… I was kind of expecting to get a file upload
tool that would have allowed the user to upload the legend image instead.

The other thing to take into account is that Mauro recently added support for multi-layer legends,
used by default for layer groups, but allowing also one to specify more than one layer in the
GetLegendGraphics request.
Now, with the pre-cooked legend, the code should go and fetch the pre-cooked legend and add it
to the multi-layer legend layout. And this presents issues, there is no guarantee that GeoServer
itself can reach to the specified URL.
For example, on my ADSL I would have to provide my internet domain address for anybody to
be able to reach the GetLegendGraphics URL, but from within the router, the same domain
cannot be reached…

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.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

2

I think SE 1.1 included support for an inline icon. I was hoping we would see that in the API as an Icon. I have yet to think through the consequences of having this in the data structure, as we should still be in position to follow the GetLegendGaraphic request which provides its own width and height.

Jody

(attachments)

image.png
image.png

···

Jody Garnett

On Sat, Nov 23, 2013 at 10:19 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
among the current pull requests we have this one about having legends URL in capabilities
documents use a pre-cooked image.

The idea is pretty useful, sometimes GeoServer cannot generate a good legend for a layer,
and hand painted once often look better regardless.

The implementation pretty much gives UI to a LegendInfo object that we have in the model,
and which has been sitting doing nothing for ages (afaik).

The style page has a new element to add a legend:

Inline image 1

What is giving me pause is what you get when you click on “add legend”:

Inline image 2

So, basically one has to specify a remote url that will generate the legend image.
Now, this is no GUI’s fault per se, the LegendInfo object has those exact fields, and the code
in the GetCapabilities generators use LegendInfo url/width/height/format to build the
proper links.

However… it seems to be it’s quite against the general GeoServer philosophy to ask someone
to stand up a separate server to use pre-rendered legends… I was kind of expecting to get a file upload
tool that would have allowed the user to upload the legend image instead.

The other thing to take into account is that Mauro recently added support for multi-layer legends,
used by default for layer groups, but allowing also one to specify more than one layer in the
GetLegendGraphics request.
Now, with the pre-cooked legend, the code should go and fetch the pre-cooked legend and add it
to the multi-layer legend layout. And this presents issues, there is no guarantee that GeoServer
itself can reach to the specified URL.
For example, on my ADSL I would have to provide my internet domain address for anybody to
be able to reach the GetLegendGraphics URL, but from within the router, the same domain
cannot be reached…

Opinions?

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.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

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Mon, Nov 25, 2013 at 11:31 AM, Jody Garnett <jody.garnett@anonymised.com>wrote:

I think SE 1.1 included support for an inline icon.

Inline icons in SE 1.1 are a way to embed a graphic inside the SLD as a
base64 encoded binary.
And there is, since SLD 1.0, the ability to have a rule refer to a icon
that would symbolize it.

Here instead we are talking about assigning an entire style its own legend,
so this is a multirule, entire style thing instead.
Not entirely fond of the idea because doing so breaks legend representation
of styles that have scale dependencies, but on the other side, it allows
for fully custom legends.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.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

-------------------------------------------------------

4

I would think uploading a static image would make the most sense as well. But I could see an argument for both static file and url. How about following.

···

In the file case we put the uploaded file into a well known location. And rather than use a full url just a file path. Looking at LegendInfo.getOnlineResource() i see a string. So something like “/styles/legend.png”.

In the url case we indeed would need to validate on input to ensure we can see the given url.

Finally the code that processes it would have to check wether the resource property is a full blown url or a static path. Perhaps we should add a new property to LegendInfo. Something like an enum that would specify the reference as either local or remote.

$0.02

On Mon, Nov 25, 2013 at 3:42 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

Geoserver-devel mailing list
Geoserver-devel@anonymised.comt
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

On Mon, Nov 25, 2013 at 11:31 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I think SE 1.1 included support for an inline icon.

Inline icons in SE 1.1 are a way to embed a graphic inside the SLD as a base64 encoded binary.
And there is, since SLD 1.0, the ability to have a rule refer to a icon that would symbolize it.

Here instead we are talking about assigning an entire style its own legend, so this is a multirule, entire style thing instead.
Not entirely fond of the idea because doing so breaks legend representation of styles that have scale dependencies, but on the other side, it allows for fully custom legends.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.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

5

I would think uploading a static image would make the most sense as well. But I could see an argument for both static file and url. How about following.

I wish we had a page to manage style resources (both for this and for the external graphics used in an SLD). If I was doing this from scratch I would would make a folder with the same name as each SLD file and use that as the basis for a relative path.

We would need to ensure legend.png was public at http://locahost:8080/geoserver/styles/legend.png or similar in order to use it in a GetCapabilities document.

Question: Are we expecting to resize this image ourself? Or just pass the value on in the GetCapabilities document or GetLegendGraphics output?

I think the schema already provided a difference for inline vs external reference (so we have a place to start for our enum).

I would prefer to move towards SE 1.1 rather than away. Let me check what they actually have:

<xsd:element name=“LegendGraphic” type=“se:LegendGraphicType”/>

<xsd:complexType name=“LegendGraphicType”>

xsd:sequence

<xsd:element ref=“se:Graphic”/>

</xsd:sequence>

</xsd:complexType>

And Graphic can an ExternalGraphic defined by either OnlineResource or InlineContent (sigh not directly helpful).

Jody

···

In the file case we put the uploaded file into a well known location. And rather than use a full url just a file path. Looking at LegendInfo.getOnlineResource() i see a string. So something like “/styles/legend.png”.
In the url case we indeed would need to validate on input to ensure we can see the given url.

Finally the code that processes it would have to check wether the resource property is a full blown url or a static path. Perhaps we should add a new property to LegendInfo. Something like an enum that would specify the reference as either local or remote.