ElevationEnvelope Performance Limitations

classic Classic list List threaded Threaded
6 messages Options
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

ElevationEnvelope Performance Limitations

Hey,

So I've been recently trying to efficiently add elevation map data and query it. Very similar to this post asked yesterday: http://forum.osgearth.org/Query-elevation-without-displaying-elevation-layer-td7592469.html.

When querying the data, sometimes the osgEarth::ElevationPool::getElevation(double lat, double lon) will stall the entire program for up to about a second before returning. The file IO is what I'm assuming is causing this behavior until it caches it in the pool. As a result, we've attempted to create both QThreads and even just regular std::threads in order to thread the osgEarth::ElevationPool::getElevation(lat, lon) function itself, but still the thread that runs osgEarth will stall during a new location's query. Is there any way to get around this with threading or does the file IO exact a high cost on the system during this file IO regardless of how it's handled?

For reference of what we already attempted:

1. We made an std::map<std::pair<int lat, int lon>, osgEarth::ElevationEnvelope*>

2. Each ElevationEnvelope represents only a single 1x1 lat/lon tile of elevation layer data, not the entire vector of layers (we figured out a weird way to do this by constantly resetting the non-rendered osgEarth::Map's ElevationLayerVector with a single ElevationLayer for each addition from our dted data file and creating a pool, tile by tile, and saving it to the std::map).

3. When the user queries a map coordinate for its elevation (when the mouse moves over any valid data), we query this std::map by truncating the mouse cords to ints that represent keys in the map and return the osgEarth::ElevationEnvelope for just that 1x1 tile.

We assumed breaking it up like we did in step 3 would increase the query speed since it wouldn't have to look through the entire pool, just a small chunk. That didn't seem to help much. The query just needs to work without stalling the main thread, we don't need constant updates like the MouseCoordsTool currently does with the intersection Ray Geometry. We also don't need perfect precision either, being a few meters off is good enough.

Based on the above stipulations are there any ways to speed up the querying operation or stop it from blocking? Or at least, some how save the ElevationPool from every execution like the ImageLayer tiles do with the map cache? I've figured out a way to pre cache map tiles in a kind of round about way. However, it can take a few hours to accurately do so, but I wouldn't be against doing something similar with the ElevationPool if it would be possible to save it and copy it to another project directory for future use.

Thanks for any help, we're really trying to push the engine as hard as we can and as efficiently as we can. If there's any obvious way using some third party tool like GDAL to do what we want, that might be the solution we need to figure out.
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: ElevationEnvelope Performance Limitations

Did you try the asynchronous method:

Future<ElevationSample> getElevation(const GeoPoint& p, unsigned lod=23);

It returns a "Future" construct; isAvailable() will return false until the result is ready.

It's quite possible that the underlying GDAL query is slow, especially for DTED which is a pretty old, slow format to process.
Glenn Waldron / Pelican Mapping
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: ElevationEnvelope Performance Limitations

I think I was using _envelope->getElevationAndResolution(point.x(), point.y());

I'll try Future<ElevationSample> getElevation(const GeoPoint& p, unsigned lod=23); tomorrow and get back to you on that. Thanks for the tip, that asynchronous part may be the answer.

Thanks for the help Glenn, like always! :)
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: ElevationEnvelope Performance Limitations

Hey Glenn,

This worked perfectly. The asynchronous call was exactly what we needed! One little tidbit of information I'd share though: Querying the same data from the ElevationPool differs in speed from a Projected versus a Geodetic map. It takes longer on a projected one. Do you know why this may occur? It's not too big of an issue, but our main use case is Projected over Geodetic, so we'd appreciate anything we can do to speed up making the Future<ElevationSample> from the ::get function become available any quicker.

As always, thanks!

- Blanky
jasonbeverage jasonbeverage
Reply | Threaded
Open this post in threaded view
|

Re: ElevationEnvelope Performance Limitations

It's probably just down to the re-projection that needs to be done if your elevation dataset isn't in the same projection as your map.  

On Thu, Mar 14, 2019 at 2:16 PM Blanky [via osgEarth] <[hidden email]> wrote:
Hey Glenn,

This worked perfectly. The asynchronous call was exactly what we needed! One little tidbit of information I'd share though: Querying the same data from the ElevationPool differs in speed from a Projected versus a Geodetic map. It takes longer on a projected one. Do you know why this may occur? It's not too big of an issue, but our main use case is Projected over Geodetic, so we'd appreciate anything we can do to speed up making the Future<ElevationSample> from the ::get function become available any quicker.

As always, thanks!

- Blanky



If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/ElevationEnvelope-Performance-Limitations-tp7592472p7592475.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: ElevationEnvelope Performance Limitations

Ahh okay, thanks Jason. I'll try re-projecting using GDAL or some other tools and see if it works. I'll update with results later.