So...I've been playing around with the asynchronous getElevation function:
Future<ElevationSample>ElevationPool::getElevation(const GeoPoint& point, unsigned lod)
I'm using it as follows:
bool osgEarthX::getHOT(double lon, double lat, float& hot)
hot = 0.0f;
bool valid = false;
GeoPoint location(_srs, lon, lat, ALTMODE_ABSOLUTE);
result = _ePool->getElevation(location);
hot = result.get()->elevation;
valid = true;
else // must be paging...
valid = false;
My first question, is this the correct usage of the function to get a response back if it is available?
My second question is if I make an elevation request, do I need to hang around until it is available or can I just return and let the pager do its thing and throw the result on the floor until the next time around?
In other words, if the request is not immediately available, I just want to return until I come around on the next time slice and issue the request again. In the next time slice, I'm hoping the previous request paged the tile in and when I issue the request again, it will be available.
Any feedback would be most appreciated. I want to make sure I'm using this function correctly and that it will meet my needs as described above...
Each call to getElevation spawns a new request with a new Future result. In your code you are discarding the Future<> immediately if the result isn't yet available. So there's no opportunity to keep checking it.
You might be getting lucky if the internal cache is updating from previous call, and then returning very quickly on a subsequent call ... but don't rely on luck :)
So...it sounds like I can't use it the way I'm trying to use it. If the result isn't immediately available, I need to return to the caller immediately so I don't stall the calling thread.
To make it work for my use case, it sounds like I will need to spawn a thread that waits for the future construct to return while I return to the calling thread. I can't stall the calling thread under any circumstances.
I guess my next question is this...
Does the asynchronous getElevation function provoke tile paging so the next time I make a request at the same location, the result will be available?
Okay. I understand what you're suggesting but my plugin interface expects a floating point elevation value to be returned to the caller. The reason for this is my terrain server software supports other terrain engines for doing elevation queries besides osgEarth. The particulars of the specific terrain underneath are abstracted away in each plugin. All the caller cares about is given a lat/lon, what is the elevation? The server has synchronous and asynchronous support.
What I could do for my osgEarth plugin is use an intermediate wrapper that gets the future<> returned and then extracts the elevation value out of the future<> when it is ready and returns that in the plugin interface.
On a related-note, is the call envelope->getElevation(…) thread-safe?