[Geoserver-devel] KML/GWC integration improvements

GeoServer GeoServer Developer
1

Hi,
lately I've been quietly working on improving a bit
our KML generation story.

The first result of that work can already be found in
2.0.x in terms of defaults configurability: I've added
a panel in the WMS service configuration that allows
to set defaults for the reflector and the KML generation
in terms of:
- default reflector mode (refresh, superoverlay, ...)
- default superoverlay sub-mode
- whether to generate placemarks by default
- whether to generate placemarks over raster outputs
   when the number of vector features exceeds the KMSCORE
- setting the KMSCORE
See attached screenshot.

Now we (Chris and me) want to push a little further ahead in
terms of GS/GWC integration. As you may know GWC can
cache and generate regionated hierarchies for both
vector and raster data. However GeoServer own KML
output does not leverage that.

What we would like to do is to create yet another sub-mode
for the superoverlay generation called "cached" that
defers to GWC as much as possible, provided that
the current KML request params match what GWC cache,
and would fall back on "auto" behavior if the params
are not compatible.

Raster wise this would be a solid improvement as
raster superoverlays are working fine and GWC would
give a serious speedup to that use case.

Vector wise we still want to introduce the option,
though it's not going to be a default since we
all know vector super-overlays are not working
that well these days.

Given this evident difference between raster and vector
I plan to provide separate defaults for vectors
and raster in the WMS service GUI to allow
admins to use superoverlays by default on raster data
without have to bring in the vector as well.

There is also the catch that GWC cannot do LRU cleaning
of tiles at the moment, so for the moment we would
not enable the cached mode by default for rasters either
to avoid the uncontrolled generation of tiles on disk.
But it would be there for all admins to use (and same
goes for vectors, super-overlay normally works fine
if all you have is small amounts of data)

I haven't seen much interest on KML lately on this
list so I was unsure whether to talk about this or just
go and implement, but here it is, I think it's right
to give everybody the possibility to weight in, even if I
don't expect much of a reaction (feel free to prove
me wrong!! :wink: )

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

(attachments)

wms-kml-options.png

2

The improvements sound really good to me. A big +1 on the work. However does not work on this scale warrant a more official proposal? You bring up the good point that there has been not much devel interest in KML lately but I don't think that means it is fair game. Perhaps kml should be moved to unsupported temporarily to open it up for more fluid development? As of now though it is still part of the core and used pretty widely and this is a pretty major change. Perhaps I am wrong though.

2c.

-Justin

On 3/9/10 8:37 AM, Andrea Aime wrote:

Hi,
lately I've been quietly working on improving a bit
our KML generation story.

The first result of that work can already be found in
2.0.x in terms of defaults configurability: I've added
a panel in the WMS service configuration that allows
to set defaults for the reflector and the KML generation
in terms of:
- default reflector mode (refresh, superoverlay, ...)
- default superoverlay sub-mode
- whether to generate placemarks by default
- whether to generate placemarks over raster outputs
when the number of vector features exceeds the KMSCORE
- setting the KMSCORE
See attached screenshot.

Now we (Chris and me) want to push a little further ahead in
terms of GS/GWC integration. As you may know GWC can
cache and generate regionated hierarchies for both
vector and raster data. However GeoServer own KML
output does not leverage that.

What we would like to do is to create yet another sub-mode
for the superoverlay generation called "cached" that
defers to GWC as much as possible, provided that
the current KML request params match what GWC cache,
and would fall back on "auto" behavior if the params
are not compatible.

Raster wise this would be a solid improvement as
raster superoverlays are working fine and GWC would
give a serious speedup to that use case.

Vector wise we still want to introduce the option,
though it's not going to be a default since we
all know vector super-overlays are not working
that well these days.

Given this evident difference between raster and vector
I plan to provide separate defaults for vectors
and raster in the WMS service GUI to allow
admins to use superoverlays by default on raster data
without have to bring in the vector as well.

There is also the catch that GWC cannot do LRU cleaning
of tiles at the moment, so for the moment we would
not enable the cached mode by default for rasters either
to avoid the uncontrolled generation of tiles on disk.
But it would be there for all admins to use (and same
goes for vectors, super-overlay normally works fine
if all you have is small amounts of data)

I haven't seen much interest on KML lately on this
list so I was unsure whether to talk about this or just
go and implement, but here it is, I think it's right
to give everybody the possibility to weight in, even if I
don't expect much of a reaction (feel free to prove
me wrong!! :wink: )

Cheers
Andrea

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

Justin Deoliveira ha scritto:

The improvements sound really good to me. A big +1 on the work. However does not work on this scale warrant a more official proposal? You bring up the good point that there has been not much devel interest in KML lately but I don't think that means it is fair game. Perhaps kml should be moved to unsupported temporarily to open it up for more fluid development? As of now though it is still part of the core and used pretty widely and this is a pretty major change. Perhaps I am wrong though.

Existing code paths would not be touched, it would be a bit
of glue in the reflector path to build network links straight to GWC,
some code to check if the link makes sense (if the request
can be passed down, if it's compatible) and a set of GUI
elements to configure it.

Hum.... right, I did not say I actually had no intention
to do the same work in the "normal" KML GetMap requests.
If we implement that in normal KML GetMap requests as well
we need to add some glue there too.
I don't expect this to grow the patch significantly though.

Do you see this as major changes?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

Well admittedly I don't have an understanding of the changes so maybe a proposal is pushing it. It was just the way it was described it made it seem like the changes were significant. And there was also the implication that since KML was not under active development lately that things could go ahead with no objection.

Anyways like I said, just my 2c as I don't have the same understanding of the changes. If you say the changes do not warrant a proposal then that is good enough for me :slight_smile:

-Justin

On 3/9/10 9:20 AM, Andrea Aime wrote:

Justin Deoliveira ha scritto:

The improvements sound really good to me. A big +1 on the work.
However does not work on this scale warrant a more official proposal?
You bring up the good point that there has been not much devel
interest in KML lately but I don't think that means it is fair game.
Perhaps kml should be moved to unsupported temporarily to open it up
for more fluid development? As of now though it is still part of the
core and used pretty widely and this is a pretty major change. Perhaps
I am wrong though.

Existing code paths would not be touched, it would be a bit
of glue in the reflector path to build network links straight to GWC,
some code to check if the link makes sense (if the request
can be passed down, if it's compatible) and a set of GUI
elements to configure it.

Hum.... right, I did not say I actually had no intention
to do the same work in the "normal" KML GetMap requests.
If we implement that in normal KML GetMap requests as well
we need to add some glue there too.
I don't expect this to grow the patch significantly though.

Do you see this as major changes?

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Justin Deoliveira ha scritto:

Well admittedly I don't have an understanding of the changes so maybe a proposal is pushing it. It was just the way it was described it made it seem like the changes were significant. And there was also the implication that since KML was not under active development lately that things could go ahead with no objection.

What I meant was, the change should not be big, and since there has
not been much KML interest lately I may be wasting people time,
but since it's new functionality I wanted to tell everybody what
I was doing anyways.

Anyways like I said, just my 2c as I don't have the same understanding of the changes. If you say the changes do not warrant a proposal then that is good enough for me :slight_smile:

I don't think it is, but developing it might prove me wrong.
What about you review the patch once it's ready, so we can both
look into it and see if it's GSIP worthy?

In the meantime, any comment, from anyone, on the actual functionality
introduced?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.