Hi David,
This makes sense to me. I Don't the ows5-kml stuff is really used...just
an experiment. So I could go ahead. Andrea can comment on if that code
is actually needed. If so it sounds like it will be easy enough to
rewrite to come inline with the api changes.
-Justin
David Winslow wrote:
> Okay, just down to the implementation details now. Right now, we avoid
> encoding placemarks that aren't rendered by the active SLD. To do this,
> we have the method that encodes the style return a boolean value to the
> calling code, which then uses that to decide whether or not to encode
> the placemark itself. In pseudocode:
>
> boolean encodeStyle(feature, sld){
> rules = filterRules(feature, sld);
> if (rules.isEmpty()) return false;
> encodeRules(rules);
> return true;
> }
>
> void encode(features, sld){
> for (feature in features){
> if (encodeStyle(feature, sld)) encodePlacemark(feature, sld);
> }
> }
>
> However, now we need to know whether or not there are any applicable
> rules *before* we start encoding the styles, so I'd like to split the
> operation up a bit:
>
> void encode(features, sld){
> for (feature in features){
> rules = filterRules(feature, sld);
> if (!rules.isEmpty()) encodePlacemark(feature, rules)
> }
> }
>
> And then encodePlacemark won't have to re-filter the rules when it comes
> time to encode. However, a number of methods that pull in the placemark
> metadata currently expect to be passed the entire style sheet. We could
> just pass both to the encodePlacemark method, but as long as I'm
> rewriting these calls I feel like we could rewrite these methods to
> expect the pre-filtered list, which would save a bit of work overall anyway.
>
> To recap:
>
> boolean encodeStyle(SimpleFeature, FeatureTypeStyle[]) =>
> List<Symbolizer> filterSymbolizers(SimpleFeature, FeatureTypeStyle[])
>
> void encodePlacemarkName(SimpleFeature, FeatureTypeStyle[]) =>
> void encodePlacemarkName(SimpleFeature, List<Symbolizer>)
>
> and so on for the other placemark metadata methods.
>
> The only objection I can think of is that the ows5 module in community
> will be broken by these changes. However, that module doesn't compile
> for me anyway right now, so it seems a minimal concern.
>
> Are there any other objections?
>
> David Winslow
>
>
> Justin Deoliveira wrote:
>> Ok, this definitely sounds like the way to go. I have updated GEOS-2448
>> accordingly.
>>
>> David, hopefully you did not spin too many cycles on the temp file approach?
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
