Hey all,
I've got the support to do some improvements to the GetLegendGraphic operation. I've outlined the changes (all are optional additions) at this page:
http://docs.codehaus.org/display/GEOS/GetLegendGraphic+Improvements
I'd love to hear any feedback or issues/questions with these changes. Here's a really brief recap:
* Add optional vendor-specific parameters for labeling font, size and anti-aliasing
* Support labelling of TextSymbolizers a bit better
* Better detection of 'label-able' rules, and the labels that should be used for a particular rule (using the <Title> instead of the <Name> if available, etc.)
Thanks for any attention you can spare.
--saul
Farber, Saul (EEA) ha scritto:
Hey all,
I've got the support to do some improvements to the GetLegendGraphic
operation. I've outlined the changes (all are optional additions) at
this page:
http://docs.codehaus.org/display/GEOS/GetLegendGraphic+Improvements
I'd love to hear any feedback or issues/questions with these changes.
Here's a really brief recap:
* Add optional vendor-specific parameters for labeling font, size
and anti-aliasing * Support labelling of TextSymbolizers a bit
better * Better detection of 'label-able' rules, and the labels that
should be used for a particular rule (using the <Title> instead of
the <Name> if available, etc.)
All suggestions look like an improvement to me, so +1.
I'm just wondering, would a format like:
LABEL_FONT=name[,style[,size[,antialias]]]]
work better in the long run?
I'm asking because I'm considering something like this for
output format options, where we have many possibly different
options for various output formats, and we don't want to
have a long list of vendor params for each one (but have just
one, to rule them all).
I know Justin preferred something like
VENDOR_PARAM=opt1:val1,opt2:val2,...
but I'm not sure ":" is an allowed char (I think it's not, but
haven't checked).
Cheers
Andrea
Andrea Aime wrote:
Farber, Saul (EEA) ha scritto:
Hey all,
I've got the support to do some improvements to the GetLegendGraphic
operation. I've outlined the changes (all are optional additions) at
this page:
http://docs.codehaus.org/display/GEOS/GetLegendGraphic+Improvements
+1 from me Saul, Great work!!
I'd love to hear any feedback or issues/questions with these changes.
Here's a really brief recap:
* Add optional vendor-specific parameters for labeling font, size
and anti-aliasing * Support labelling of TextSymbolizers a bit
better * Better detection of 'label-able' rules, and the labels that
should be used for a particular rule (using the <Title> instead of
the <Name> if available, etc.)
All suggestions look like an improvement to me, so +1.
I'm just wondering, would a format like:
LABEL_FONT=name[,style[,size[,antialias]]]]
work better in the long run?
I'm asking because I'm considering something like this for
output format options, where we have many possibly different
options for various output formats, and we don't want to
have a long list of vendor params for each one (but have just
one, to rule them all).
I know Justin preferred something like
VENDOR_PARAM=opt1:val1,opt2:val2,...
but I'm not sure ":" is an allowed char (I think it's not, but
haven't checked).
Well they are allowed in wfs type names so I am not sure why they would
not be allowed here. Or am i missing the point?
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,46655a9061954901796417!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Well they are allowed in wfs type names so I am not sure why they would
not be allowed here. Or am i missing the point?
Nope, you're absolutely right. I wasnt' thinking about that, that's all 
Cheers
Andrea
I would love to have an option for an dynamically-generated legend for
coverages that shows a color scale and quantities:
http://smoke-fire.us:8080/geoserver/data/images/O3_surf_0_legend.png
Alex
Looks great to me too.
Andrea Aime wrote:
Farber, Saul (EEA) ha scritto:
Hey all,
I've got the support to do some improvements to the GetLegendGraphic
operation. I've outlined the changes (all are optional additions) at
this page:
http://docs.codehaus.org/display/GEOS/GetLegendGraphic+Improvements
I'd love to hear any feedback or issues/questions with these changes.
Here's a really brief recap:
* Add optional vendor-specific parameters for labeling font, size
and anti-aliasing * Support labelling of TextSymbolizers a bit
better * Better detection of 'label-able' rules, and the labels that
should be used for a particular rule (using the <Title> instead of
the <Name> if available, etc.)
All suggestions look like an improvement to me, so +1.
I'm just wondering, would a format like:
LABEL_FONT=name[,style[,size[,antialias]]]]
work better in the long run?
I'm asking because I'm considering something like this for
output format options, where we have many possibly different
options for various output formats, and we don't want to
have a long list of vendor params for each one (but have just
one, to rule them all).
I know Justin preferred something like
VENDOR_PARAM=opt1:val1,opt2:val2,...
but I'm not sure ":" is an allowed char (I think it's not, but
haven't checked).
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4005,46655a9161942143011171!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Andrea,
Without commenting on the deeper ramifications of generalized vedor parameters (VENDOR_PARAMS=opt1:value1,opt2:value2), I think that your specific suggestion below is a great one. I'll update the 'changes discussion' page accordingly. Thanks for the quick feedback!
--saul
I'm just wondering, would a format like:
LABEL_FONT=name[,style[,size[,antialias]]]]
work better in the long run?
Farber, Saul (EEA) ha scritto:
Andrea,
Without commenting on the deeper ramifications of generalized vedor
parameters (VENDOR_PARAMS=opt1:value1,opt2:value2), I think that your
specific suggestion below is a great one. I'll update the 'changes
discussion' page accordingly. Thanks for the quick feedback!
Good. Thinking about it, I think I'd prefer a form such as
VENDOR_PARAMS=opt1:value1,opt2:value2
Let's elaborate a little
Cons:
* it's more verbose
Pros:
* it's more explicit
* it allows just one param to be specified, whilst the other forces
you to specify the first one if you had to specify just the
second
In the case of fonts I don't see that much difference between the two,
but I think the explicit one would be better on the output format
params case, where you may want to specify just the compression level,
dithering/not dithering, the compression method, and so on.
I would prefer to have just one way to specify a complex vendor param,
if possible, that's why I'm suggesting the explicit one.
Cheers
Andrea