asynchronous support for getElevation

classic Classic list List threaded Threaded
10 messages Options
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

asynchronous support for getElevation

Can anyone tell me what version of osgEarth asynchronous support for non-scenegraph elevation queries was introduced? It looks to be part of the ElevationPool class or API?

I'm currently using osgEarth 2.7 and it doesn't appear to be in this version. I need the asynchronous support but I want to minimize software changes to our software.

Any help or feedback would be appreciated...

Shayne
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

Shayne,
This commit
https://github.com/gwaldron/osgearth/commit/425b5346ec0ee54405a636261bbe8c02b7350e6d

It's in osgEarth 2.9+ I believe.
Glenn Waldron / Pelican Mapping
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

Thank you Glenn for the timely reply.
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

In reply to this post by gwaldron
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);

    Future<ElevationSample> result;
    result = _ePool->getElevation(location);
    if (result.isAvailable())
    {
        hot = result.get()->elevation;
        valid = true;
    }
    else // must be paging...
        valid = false;

    return valid;
}


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...

Thanks

Shayne
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

This post was updated on .
Shayne,
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 :)
Glenn Waldron / Pelican Mapping
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

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?

Shayne
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

Spawning a thread to wait on the Future kind of defeats the point of the Future :)

Why not just return the Future<> to the caller instead of an elevation?

Don't make any assumptions about what the ElevationPool is doing under the hood. It is very likely to change.
Glenn Waldron / Pelican Mapping
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

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?

Thanks for your feedback.

Shayne
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

ElevationEnvelope is NOT thread safe. The usage pattern is to create your Envelope, make one or more "spatially related" queries, and dispose of it.
Glenn Waldron / Pelican Mapping
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: asynchronous support for getElevation

Okay. Thanks for letting me know...

Shayne