Thanks for the detailed breakdown, comments in line.
As for Ian's comment - I know James is a member, who is the other? And I
wonder how I can join - I have always viewed portrayal as the only real
area on the OGC stack where GIS gets accomplished (rather then just data
wrangling).
Saul Farber wrote:
Hey all,
I guess since I wrote this patch I ought to defend it a bit, at the
least just to play devil's advocate!
Ooch - I was thinking the geotools rendering system (and where it is
going) is in need of encouragement - rather then defense on anyones part.
First off, to address Ian's point, the label-shield patch improves
symbolization over a pair of symbolizers by allowing the graphic to
appear directly underneath the label in all cases. For example, how
would you symbolize a labeled interstate freeway with an interstate
shield underneath which has three labels along it's length? Something
like the attached image isn't possible (as I understand it) to render
on-the-fly with just two symbolizers.
More generally, isn't this the point of a good labeler? A more
standards-compliant way of implementing this functionality would be to
add a <Vendor name="labelURL">http://my-label-url</Vendor> tag to the
output, but isn't it more elegant and less code-intensive to just use
the well-designed and well-written <Graphic></Graphic> tag instead?
Label shields aren't exactly controversial, are they? It seems very
beneficial to be able to render appealing maps with nice colored
alpha-blended interstate road-shields underneath the labels, no?
I also suspected that this was something so basic that the SLD revision
working group would of hit it by now.
The reason I am casting around for a more general solution is this: I
suspect that we need better hooks
into where a labeling system actually places things. I am thinking here
where more then one "shield" is
combined to form the backdrop to a label.
In my specific situation, this is a real-world requirement which
geoserver needed to support in order for us to consider using it in our
production web-mapping environment. We also need to support SDE-stored
raster data--I'll be chatting with Alessio when that time comes...soon I
hope! This change doesn't shrink the available rendering options in
geotools/server, and if it caused any previously valid SLD documents to
become invalid, I would think that fact grounds for rejections. But it
doesn't *shrink* the space of render-able SLD documents, it simply
extends it in a logical manner to support a real-world need.
In the end, it's not of large consequence to myself or my organization
whether this patch gets accepted. It's a real-world necessity that this
functionality be present for us, so I'll simply maintain the patch
against whichever branch of geotools the geoserver trunk is using and
make it available for download to those who would like label shields.
It *is* of interest to me that this patch gets applied.
I want the geotools styling system to be capable, it is just important
to me that we have a long term plan. I recently looked at mapserver
configuration and was afraid ....
However, I think this functionality is a credit to geoserver. It makes
it able to generate better maps in a tiny way, and if the reason for
rejecting it is that it provides a proper superset the OGC specification
by extending SLD in a fairly logical manner, I think that's a pretty
weak reason.
I think I have covered the fact that I am not interested in holding back
development. Just in making sure
the is any kind of structure in place to catch these things. Hense my
vote changed from 0 (undecided) to
-1 not as written but willing to help.
Either way, geoserver completely rocks. This code is fantastic, and
when our multiple-server, load-balanced, 100,000-maps-a-day
infrastructure is up and running on a geoserver-based platform, I'll be
sure to post a good technical discussion of how we've set up our
"enterprise" (I also hate that word) mapping platform on an open-source
foundation.
:-) Oh come on you can sell "enterprise" things, you can't sell
"distributed computing" - I let the marketeers have their fun.
The one that scares me is that they can sell "location" but they can't
sell "GIS".
Great work guys, and I hope that you'll bring the label-shields code
under your wings. But if not, that's cool too...I'll figure some other
way to get this functionality to other folks who want it.
Tell you what you can do to help, do you like the interface/factory
breakdown I proposed? I think if we have
that we can both:
#1 - accept fun new changes
#2 - support development of silly things like SLD 1.1 (same thing in my
mind to point #1)
#4 - indicate with strong types where SLD 1.0 support is needed/required.
Cheers,
Jody
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
