Hi all,
I've been doing some work on automated regionating for KML output in a community module. I'd like to move that code into the main KML map producer. I've written up a GSIP at http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer
Of course, comments/questions/general feedback are welcome. It would be nice to be able to vote on this at next week's IRC meeting.
-David
Hi David,
The "protocol" part looks good, using the format_options and stuff. I would perhaps elaborate a bit on how you intent to do the merge at the code level. Is it going to be a subclass? Is it going to become part of the current KMLVEctorTransformer? etc...
-Justin
David Winslow wrote:
Hi all,
I've been doing some work on automated regionating for KML output in a community module. I'd like to move that code into the main KML map producer. I've written up a GSIP at http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer
Of course, comments/questions/general feedback are welcome. It would be nice to be able to vote on this at next week's IRC meeting.
-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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,483dcbef242754901796417!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Hi David; I could not tell what your three format options were up to...; in particular what is a "regionating algorithm"? Is that how you are trying to figure out the language?
Here is my guess...
sld - the language used by the SLD file (you can have multiple languages in a single SLD file...)
attribute - checking an attribute on a feature by feature basis?
geo - making some guess based on where in the world feature is? Are you going to store some kind of "langauge" map - if so what about bi-lingual countries (ie Canada) or worse South Africa with 17 official languages...
Questions:
- I am not sure why the language is not taken from the request (ie the HTTP header?)
- Is there anything here for people working with a POST request?
You are talking about changes to reduce the number of duplicated classes; can you give us some kind of BEFORE and AFTER?
David Winslow wrote:
Hi all,
I've been doing some work on automated regionating for KML output in a community module. I'd like to move that code into the main KML map producer. I've written up a GSIP at http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer
Of course, comments/questions/general feedback are welcome. It would be nice to be able to vote on this at next week's IRC meeting.
-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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Jody Garnett wrote:
Hi David; I could not tell what your three format options were up to...; in particular what is a "regionating algorithm"? Is that how you are trying to figure out the language?
Sorry, I guess I've been working on regionating so long I've forgotten there are people who don't know what it is. Regionating is the process of dividing up features in a dataset so that as some client (ie google earth) requests maps it only receives information about a limited set of features, that fills in as you increase the zoom level. (This is nice for bandwidth-saving and end-user-experience-enhancing purposes.) There's some more info linked from the GSIP page now.
Here is my guess...
sld - the language used by the SLD file (you can have multiple languages in a single SLD file...)
attribute - checking an attribute on a feature by feature basis?
geo - making some guess based on where in the world feature is? Are you going to store some kind of "langauge" map - if so what about bi-lingual countries (ie Canada) or worse South Africa with 17 official languages...Questions:
- I am not sure why the language is not taken from the request (ie the HTTP header?)
- Is there anything here for people working with a POST request?
Sorry about the confusion here; some info about the different algorithms is included as well. I am not sure whether/how format_options are supported for POST requests. However, I think the typical use-case for regionating code will involve a seeded cache (since it is focused on making things easy for casual users) so dealing with custom requests may be a lesser concern.
You are talking about changes to reduce the number of duplicated classes; can you give us some kind of BEFORE and AFTER?
This has also been added to the GSIP page. Thanks for the comments!
-David
David Winslow wrote:
Hi all,
I've been doing some work on automated regionating for KML output in a community module. I'd like to move that code into the main KML map producer. I've written up a GSIP at http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer
Of course, comments/questions/general feedback are welcome. It would be nice to be able to vote on this at next week's IRC meeting.
-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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4040,483dee828231628642973!
David Winslow ha scritto:
Hi all,
I've been doing some work on automated regionating for KML output in a community module. I'd like to move that code into the main KML map producer. I've written up a GSIP at http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer
Of course, comments/questions/general feedback are welcome. It would be nice to be able to vote on this at next week's IRC meeting.
KML support is getting so big that it is really starting to ask
for its own module (hello Justin 
)
As for merging stuff directly inside the KMLVectorTransformer, I'm
having some reservations. I understand it's the easiest way to
get that done, but at the same time this would add to a class
that's already 1200loc. I'm wondering if it would be possible
to split up some more code in pluggable separate classes, so
that you would use one for standard KML, another for regionated
KML, and so on.
To give you another idea, some time ago Jason Pickering asked
the KML to be split along the values of one or more attributes,
building a classification tree that could be seen from GE as
a tree control, stuff like roads with childs as "major roads",
"local roads", and so on.
I believe having some pluggability in how the generated KML is
organised (besides the regionating strategy, but more on the
lines of flat, regionalted, classified) would be good from
a maitentance and understandability point of view.
I'm not asking this to be done this way, just that you consider
this as an alternative and see if it could lead to a cleaner
(and more extensible) implementation without expanding too
much the scope of your work.
Cheers
Andrea
Andrea Aime wrote:
David Winslow ha scritto:
Hi all,
I've been doing some work on automated regionating for KML output in a community module. I'd like to move that code into the main KML map producer. I've written up a GSIP at http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer
Of course, comments/questions/general feedback are welcome. It would be nice to be able to vote on this at next week's IRC meeting.
KML support is getting so big that it is really starting to ask
for its own module (hello JustinAs for merging stuff directly inside the KMLVectorTransformer, I'm
having some reservations. I understand it's the easiest way to
get that done, but at the same time this would add to a class
that's already 1200loc. I'm wondering if it would be possible
to split up some more code in pluggable separate classes, so
that you would use one for standard KML, another for regionated
KML, and so on.To give you another idea, some time ago Jason Pickering asked
the KML to be split along the values of one or more attributes,
building a classification tree that could be seen from GE as
a tree control, stuff like roads with childs as "major roads",
"local roads", and so on.I believe having some pluggability in how the generated KML is
organised (besides the regionating strategy, but more on the
lines of flat, regionalted, classified) would be good from
a maitentance and understandability point of view.I'm not asking this to be done this way, just that you consider
this as an alternative and see if it could lead to a cleaner
(and more extensible) implementation without expanding too
much the scope of your work.Cheers
Andrea!DSPAM:4040,483fc940286101137850744!
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. 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.)
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.
-David
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
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 todayCheers
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
I've added these ideas and a couple of others to the wiki at http://geoserver.org/display/GEOS/GSIP+21+-+KML+Vector+Transformer+Refactoring . I haven't looked at the entire KML transformer family of classes yet, just the vector transformer, so there may be some further additions when I do. Still, fire away with the feedback.
-David
David Winslow wrote:
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 todayCheers
AndreaOkay, 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 likepublic 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 ofpublic 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
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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4040,4841b5e8135121030819293!