bhowden

I think my problem is much simpler than yours with one hitch and one bit I still don't understand. There seems to be a one to one relationship between (2^ zoom level) and elevation. There is a one to one relationship between (2^ zoom scale) and m/pixel. Since I am coming from a projected window (in meters) and going to the mercator projection in VE (in meters), I don't think curvature will affect me. Even if it did, most of my numbers are < 100 km ground scale so the effect isn't to noticable. I do have the problem of my projection being different so as I move away from the centeral meredian of my projection, the view will rotate a bit but that is accounted for by the bounding box coming out a tiny bit larger. If I did my arithmetic correctly, this works out to:

altitude[in meters] = (654.1 * distance[in meters X or Y])/cos(latitude) * client pixels (width or height).

If I test the x and the y separately and take the largest elevation my window should be the minimum bounding rectangle that will include the old view. The hitch is that elevation in the control is above the geoid and the altitude in the calculation is the distance above the terain so I need the elevation of the terain to adjust. The window.status method of getting the elevation is a bit of a kludge as other parts of my app are updating it as well and the control seems to update it asyncronously.

The part I still don't understand is if I set the client size to be square and pick a location out in the middle of the ocean and get the view, zoom level, and elevation I get one set of numbers. If I leave everything the same and change the height to twice the width, same center, same zoom level, I get the same elevation but a different width (in degrees). Since the m/pixel is fixed, the same width client should return the same width on the ground but it is way off (say 20% at the zoom level I tested at). I must be missing something simple here but I don't see it rigtht now.

Brian