Bulk Obstacle Evaluation / Analysis Feature for large datasets

Further to the blog last year about obstacle evaluation/analysis is seems that users have an abundance of data sources, this data is coming from surveys, satellites and even the USA Space Shuttle did a radar topography mission that obtained digital elevation models. More recently lasers are being used in surveying to create a data-set of 3D representations. One thing in common here is that this data is getting very large in size.

In recent years the CPU’s in out computers are becoming very powerful as the manufactures have started to find more space and have added more cores allowing the computer to have more processing capabilities. This started a while back with dual cores and as as I write this blog AMD have just release a third generation Ryzen Threadripper which has 64-cores(128 threads) running 2.9 to 4.3GHz. There is also some scope to use any spare processing power in your graphics card (using the GPU) but perhaps save that for another blog day.

To support this growing processing power in the CPU, programmers now have to write the software to make use of the cores. Before it was easy as it all run in a single thread of execution and our source code got executed line by line. If you want to read more about how this new concept work, take a look at this article by Microsoft titled Asynchronous programming with async and await; this uses cooking a breakfast as an example.

In FPAssistant SDK there is now a new class called BulkObstacleEvaluation and this will perform obstacle analysis using collections of obstacles and 3D surfaces. The analysis can be instructed to execute in a single or multi-threaded operation, the difference between the time taken to do the required calculations.

Here is the standard Windows task manager showing CPU usage and this is showing a bulk obstacle assessment calculation in a single threaded mode and we can see the cores in the CPU are not all working at maximum.

But when using a multi-threaded option that in the screen shot below we can see that all the 8 cores are running at maximum (see red clouds).

This timing difference can be seem more when in the FPAssistant Unit Testing we can see a data-set of 30,000 obstacles being analysed against two facets it takes 13 seconds instead of 43 seconds.


Computers will get more powerful as time goes by but to use this extra power the software must be programmed to make use of the cores, as you can see above the FPAssistant SDK does make use of the cores in your CPU.

2020-02-06T13:34:06+00:00February 6th, 2020|FPAssistant SDK/API News|