Support super overlays in GeoServer
-----------------------------------
Key: GEOS-1034
URL: http://jira.codehaus.org/browse/GEOS-1034
Project: GeoServer
Issue Type: Improvement
Components: Google Earth KML Output
Affects Versions: 1.6.0-alpha2, 1.5.0-RC4
Reporter: Chris Holmes
Assignee: Justin Deoliveira
Priority: Critical
Fix For: 1.5.1, 1.6.0-beta1
Ok, so I did some research in to super overlays and how we might get them to work in GeoServer.
First off, some helpful places to look. First: http://code.google.com/p/regionator/ Needs gdal to run the super overlay stuff. But the schema they use to make superoverlays is what we want to use. 256x256 tiles, that pop on when zooming in.
What I did was generated the KML files with the super overlays, and replaced the 32.jpg hrefs with hrefs calling a remote WMS server. This definitely worked, the remote server generates just the images needed.
Next I tried out pointing it at a TileCache - that only returns valid WMS tiling Client stuff - and lo and behold at least some of it worked!
Next step was to get it fully working. Realized the ones that weren't working were requesting the exact image created by gdal, instead of the full area as created by the algorithm to divide up the earth in to tiles. So changed the code to use the 'qid' bounds instead of the data bounds, and then all tiles worked. The key code change to this is in superoverlaykml.py of the regionator:
- (n,s,e,w) = tile.NSEW()
- href = '%s.%s' % (region.Id(),self.__fmt)
+ (n,s,e,w) = region.NSEW()
+ href = 'http://sigma.openplans.org/tilecache-1.3/tilecache.py?LAYERS=sigma&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&FORMAT=image/png&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&bbox=%s,%s,%s,%s' % (w,s,e,n)
In their version it gets the bounds coordinates from the tile, in ours it gets it from the region (this is what made some work but not all before - all tiles that filled a region worked fine). Then all we do is plug in the WMS url instead of the local tile name.
So the cool thing is they're already using the same scheme that we use for WMS tiling. And thus we can start with a python TileCache, hopefully then use it with jython, and then use our own when it comes online. For the first we may need to allow users to specify an alternate base URL for their WMS base.
So the algorithm for creating a new KML superoverlay with a WMS is really easy. You just make a href for the ground overlay at the current zoom level to the WMS request for the layers, and then split it in to 4 bounding boxes of equal size that have hrefs to the KML superoverlays of those.
For the first shot, we can basically just rely on the WMS min/max scale denominators to turn off layers. Like we never really have to stop generating new KML hierarchies. Eventually we can let people set the depth, and indeed return raw vectors at a certain depth, ect. We also don't have to match the exact tile sizes, we just always return the full tile sets, since the WMS will only return the images that are there (I think we need to be sure to set transparent to true though).
So the first step is to just create some superoverlay code that always starts fully zoomed out (I think the way regionator is supply -180 -180, 180 180 - which I didn't understand, but I think they divide this in to 4, while the WMS tiling client way is to say there are two top level tiles, and they then get split in to 4. But either way you do it you end up with the same tiles the next one down). Then you just stick that tile hierarchy at a full WMS request (or you can leverage the new WMS reflector to make those calls a bit cleaner in the code, its defaults should work out well for this).
The downside of this approach is it doesn't zoom to the area you're at at all. It won't let you start at some zoomed in area I don't think. And it won't automatically preview just the area that the data is available. So the next step is to figure out how to go from an arbitrary bounding box to somewhere in the hierarchy. Once you're in the hierarchy everything should take care of itself, it just recursively points down the zoom chain. Oh, you may need a bit of 'draw order', but you can just keep track of depth, or calculate depth based on scale or some such. But to get in to the hierarchy you'll have to get it to snap to the zoom level and bounds that it needs to be to recurse properly down. OpenLayers should have code to do this, since their rubber band zoom must do some similar calculations.
Ok, I'm running out of steam, and that's all I can remember at the moment. Oh, but a few more little resources. Check out the qidboxes that the regionator stuff makes. Those are the right bounds you need, where your superoverlays should fall. They should just link to the WMS, instead of the linestring. Also there's some code in: https://sourceforge.net/projects/glmapserver/ that does super overlays in java. Shouldn't use it directly, as I don't think they quite follow the same schema as regionator and wms tiling, but could be useful for inspiration. But yeah, the regionator code should be a main source of inspiration. Just remember we don't have to generate all the files they do, we just need to set up the hierarchy to be built on the fly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira