Andrea Aime wrote:
> David Winslow ha scritto:
> ...
>>
>> Hi Andrea,
>>
>> I get the impression that you are thinking of regionated KML as a
>> single file containing all the features, separated into different
>> Documents with appropriate level-of-detail configurations for each
>> feature grouping.
>
> No no, I know what superoverlays are, sorry I leaved the doubt.
>
>> One point of the regionating process is to avoid spending bandwidth
>> and client-side resources on features that the end user won't be able
>> to see anyway, so it's a filter on the features that are included in
>> the document at all; with the assumption that NetworkLinks will be
>> used to pull in the appropriate tiles as the client zooms in.
>> Grouping the features into separate documents is something completely
>> orthogonal (although having this hierarchy in a regionated tile
>> hierarchy would probably not work well; the treeview is pretty much
>> overwhelmed by all the NetworkLinks for even a few zoomlevels' worth
>> of data from a regionated hierarchy. You can check out the demo at
>> http://geo.openplans.org:8080/geowebcache-unstable/service/kml/topp:glin_benzo.geosearch-kml.kmz
>>
>> to see what I mean.)
>
> My point with the classification example was not to imply it
> was related somehow to regionating, but only to show there is
> "features" pressure building on the KML module, this implies
> it's getting more and more complex. I just wanted to express a concern
> and present an idea (pluggability) to avoid the transformer
> class explosion.
>
>> In general I'm not opposed to code cleanup, but I think it would be a
>> pretty large increase in scope for me to add the feature you're
>> talking about.
>
> Classification was just meant as an example, not as a request for you
> to implement it. Same goes for increased modularity of the kml
> transformers, I just wanted to throw the concept on the plate and see
> if any bright idea came out.
> I'm painfully aware of how under pressure each one of us is, last thing
> I want is to overly increase your scope. You're right that modularizing
> more KML generation is probably gong to take some sizeable time...
> I believe sooner or later we'll have to cross that bridge, but it does
> not have to be today ;)
>
> Cheers
> Andrea
>
> !DSPAM:4040,4841a108105301137850744!
>
Okay, this clears things up a bit. I am not sure I have a good idea of
what parts of the KML transformer are appropriate for extension, perhaps
we could put together a list of (potentially silly) features that we'd
like to at least have the potential to support before I put too much
time into investigating a refactor of that code. Counting the
classification you've mentioned, there are three aspects of the
generated KML that have been mentioned already as candidates for
extension points:
* Filters on what data is included (aka RegionatingStrategies.) My
regionating code already includes an interface,
RegionatingStrategy, intended to allow easy addition of new
filtering policies. My current code just uses a chain of if's to
choose between the three strategies that I have implemented, but
refactoring this to a full-fledged Spring extension point would be
fairly straightforward. RegionatingStrategy currently lives at
http://svn.codehaus.org/geoserver/trunk/geoserver/community/geosearch/src/main/java/org/vfny/geoserver/wms/responses/map/kml/RegionatingStrategy.java
if you'd like to take a look.
* Extra XML nodes to attach to Placemarks (for example, <atom:link>
elements to help Google's GeoSearch identify features and avoid
duplicates in their index.) The code that handles this in the
GeoSearch module is currently all in methods that have just been
added to the KMLVectorTransformer. I guess for this we would want
to have a PlacemarkListener interface which would have
implementations for each of the details we currently include, and
further information could be added by registering other listeners
through spring. If we allowed each listener to have some string
identifier then we could add some format_option to toggle them as
well. This would probably look like
public interface KMLPlacemarkListener {
public void writeNode(OutputStream out, SimpleFeature f);
}
* Classification. This feels a bit harder (since it would actually
change the structure of the produced KML, from having 1 document
to N documents). I think the most straightforward approach here
would be to sort the features for each request by whatever
attribute is being used to classify them, and then start a new
document whenever the KML producer encounters a value of that
attribute that doesn't match the previous value. But we might
want to do something smarter (for example, maybe we want to
cluster towns alphabetically, or classify on a numeric field) so
the condition for starting a new document would be the extension
point. I guess this would be a KMLClassificationPolicy interface
along the lines of
public interface KMLClassificationPolicy {
public SortBy[] getSortBy(MapLayerInfo layer);
public boolean terminateClass(SimpleFeature f);
}
Here I'm thinking of extensions as being some classes that are
registered in spring and then the kml transformer delegates tasks to
them, rather than extending the KML vector transformer as currently is
done. If there's a nicer way to deal with this, feel free to enlighten
me :) A nice thing about keeping it as one class that is customized
through spring extension points is that we should be (mostly) able to
introduce the extension points incrementally to avoid a sudden plunge
where everything is broken at once.
I guess there are also some things in the vector transformer that might
want to be factored out and generalized away from the KML producer
entirely, such as the methods that find the style rules that apply to a
particular feature at a particular scale.
This has mostly been off the top of my head so far, I'll look at the
actual code in a bit more depth sometime this week. I feel like it may
make sense to have 'make KML easy to work with' as a separate GSIP though ;)
-David
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
