3D terrain for BlueSky

[yaofuzhou]

Hi,

I have been working on introducing the features of 3D terrain and skyline and their associated functionalities to BlueSky.

I want to give a brief description of what I have in mind and I would appreciate if creators and the community of BlueSky can tell me how to best integrate these new features with BlyeSky.

So far I have 3D terrain ready and it works as follows:

1. User specifies a bounding box using S, W, N, E coordinates. This would be the area of interest.
2. Terrain elevation data is queried from Open Topography with bounding box, a free Open Topography API key, and a resolution setting (30 m or 90 m).
3. Depending on the choice of resolution, my relatively new MacBook can deal with 7400 km^2 or 65000 km^2 at a time without significant optimization of my codes
4. The terrain elevation data for the interested area is taken in by scipy.interpolate.LinearNDInterpolator, and an interpolation function interpo_terrain is returned for further use.
5. Another function point_terrain(self, lat, lon) is defined based on interpo_terrain to yield the value of elevation at any given (lat, lon) within the interested area (0 elsewhere).
6. The above is implemented a singleton class named DEM (short for Digital Surface Model), and the instance is called terrain.
7. A small test program is provided outside DEM. It draws a 3D terrain map using point_terrain(self, lat, lon) with, say, 1000,000 random points inside the interested area and allows the user a way to visualize. An example of NYC (terrain only, skyline not included).
8. Test on my MacBook indicates that each call of point_terrain(self, lat, lon) cost well less than 1 ms.

My goal is to -

1. Implement a BlueSky command radar altimeter. This would be the most obvious use case of the 3D terrain feature.
2. Design and implement GPWS (Ground Proximity Warning System) based on radar altimeter and other existing features of BlueSky.

My goal in the longer term is to -

1. Implement 3D skyline using a similar approach with data from OpenStreetMap. I have an algorithm tested to pre-process skyline data so that they work well with existing terrain data, but to implement it will take some time. Would love the share the idea if someone is interested in codeveloping this feature.

Questions:

1. Where to put the codes for 3D terrain? My guess would be bluesky/bluesky/tools (if this were a permanent feature) or bluesky/plugins (if this were an optional feature).
2. I guess the terrain data should be stored under bluesky/bluesky/resources/navdata? Options can be implemented somewhere to keep/delete/re-download the data whenever it applies.
3. At what point during runtime should the 3D terrain feature be activated? Downloading terrain data and initializing the interpolation functions can take up to a few minutes.
4. How should one best implement the new BlueSky command radar altimeter? Specifically, 1) how would you store the returned above-ground-level attitude for further use (say, in GPWS functionalities), and 2) what would be a native way to display/present/log the returned above-ground-level attitude when the command is issued?
5. What are other use case for the features of 3D terrain and skyline?

Thank you for any feedback!

[jooste]

Dear @yaofuzhou,

Thanks for the update on your interesting work. I think that elevation data functionality would be a useful addition to the main functions of bluesky. If this only involves user/scenario-initiated (stack) commands it can easily be fully integrated without plugins. If it required a periodic function we might have to consider putting this into a 'core plugin': something that you can disable if you don't need it, but is part of the main distribution of bluesky.

Since the data comes from online storage, I would use bluesky's cache functionality to locally cache the data.

your other questions need some further discussion / brainstorming. It could be that someone is interested in altitude above terrain for each aircraft at any time, which means it needs an additional aircraft state. If it adds non-negligible computational load this needs to be something you can toggle.

[yaofuzhou]

Dear @jooste

Thank you for your feedback! It sounds like implementing the 3D terrain as a core plugin would be the most reasonable option.

We can let the users to activate the 3D terrain feature either upon starting the program via settings.cfg, and/or let them do so during runtime with BlueSky built-in command. Feel free to let me know if you have a preference.

While I should better familiarize myself with the BlueSky codes, in case you have off the top of your head a list of modules that I should be looking into implementing the plugin, please kindly share with me. This may significantly speed up my progress.

In any case, I will show you my own branch of BlueSky when I have more progress. Thank you!

[yaofuzhou]

Just realized that there is already instructions on building plugins :)

[yaofuzhou]

Dear @jooste ,

A pull request has been made with instructions on how to test the TERRAIN plugin. Please review at your convenience and feel free to provide any feedback.

Thank you,

Yaofu