I have a feature request from the BC Gov't for a "fix" for using WMS links in Google Earth. The problem is the when the user tilts their view significantly to the point that the horizon is in view, the size of the bbox for the request becomes enormous. This causes the server to switch the layers being displayed, based on the change resolution, the result being that as the user tilts the view, the data they were looking at disappears and they are left with a low-resolution view in the foreground, all so that the distant background to the edge of the horizon is "visible". If the layers are not scale-dependent, the result is just as bad and the request takes forever to process because of the large number of features included in the large BBOX.
The way that has been suggested to fix this is to provide the camera look-at parameters, available from GE, to Geoserver as format_options, so that it can adjust the bounding box "appropriately". The degree of adjustment could be controlled by an additional scaling factor. I have been given some code to use for the actual trigonometry of the bbox adjustment, I'm not sure exactly how it works yet but I think it is relatively intuitive how it could be done.
Here is an example of the <Link> that might be used in the kml to describe the access to this modified geoserver:
<viewFormat>BBOX=[bboxWest],[bboxSouth],[bboxEast],[bboxNorth]&format_options=camera:[lookatLon],[lookatLat],[lookatRange],[lookatTilt],[lookatHeading]</viewFormat>
<viewRefreshMode>onStop</viewRefreshMode>
<viewRefreshTime>0.5</viewRefreshTime>
</Link>
So I am proposing adding one format_option, "camera", with an array of 5 doubles for it's value. I think it makes more sense to include all of the values as a single option because it won't work without all of them - having them separate might be more readable and self-documenting but somewhat implies that they could be used separately, which is not the case.
Another format_option, perhaps "camera_scaling" would be a double providing the scale factor to the bbox-recalculation code. Or alternatively, it could be a 6th double on the end of the "camera" array.
When the camera option is present and valid, the effective BBOX of the request would be modified based on the camera parameters. In the case of a straight-down view, the bbox should be unchanged from the original request.
Apparently, Virtual Earth is "smarter" and doesn't make such big requests when the camera is tilted heavily, so this function is to help Google Earth behave similarly.
I mentioned this on GeoServer earlier and had a bit of positive feedback. I think this is a useful feature, I'm hoping to get approval from the team and would appreciate any direction, recommendations, or requirements for the implementation. I was thinking this might be a small enough feature that I don't need to do a GSIP for it but if you would like to see this formalized I can do so.
Thanks,
Chris