Implement terrain checks

[hbeni]

Currently the plugin uses a simple radio model that checks a perfectly round geoid. It would be cool to check line of sight against a digital height model, so mountains will prevent vhf communications.

Maybe we can incorporate the SRTM/ASTER files for this.
Terrain data should be used to check line of sight obstruction by mountains/hills etc.

Probably some changes to the UDP fields HGT and ALT will be needed. the plugin should (remain to) operate internally on AGL[1].
ALT therefore needs to be converted to AGL by querying the terrain model, if possible.
For LOS-Checks both values then firstly need to be converted to real altitude (or the terrain model path values corrected for the difference).

has also todo with #15
See also links there!

---

[1] For two reasons: 1. because this gives better radio horizons when no terrain data could be obtained; 2. to keep backwards compatibility to previous plugin versions

[hbeni]

I read trough some of this topic. The needed data is in the gigabytes, alone for the 500m (which is mabe already too rough) spacing whole earth we have >500MB.

It is surely no option to bake this into the plugin, so we need another route here:
We may use some web service for querying. Here https://github.com/Jorl17/open-elevation/ looks promising.
We could host that alongside the fgfs mumble server / statuspage; but probably this is using memory heavily. open-elevation can answer the sampling of different points, so the plugin already may request sample points along the LOS of the signal and get all the height points on that sample path. Checking that is easy; it's the network time that bothers me. We may implement some additional client thread that calculates this periodically beforehand for each registered client "nearby" (250km radius? it probably makes sense to ignore terrain for very long distances...). That way, we just need to look if the sender is obstructed or not, and the calulations for that occur asynchronously.
If this info cannot be obtained (not caluclated so far, or some problem with the web api) we should assume "0" for the sample path, to make sure, comms are working in failsafe-mode.
Well and of course it as to be really fast as this checks are happening quite often.

[hbeni]

Alternatives (openelevation seems to be unmaintained):

• https://github.com/Developer66/open-elevation
• https://github.com/ajnisbet/opentopodata

[hbeni]

The ITM/Longley-Rice code that may be introduced by #15 can use terrain sampling data, that may be obtained with some of the methods brainstormed above. So probably its better to refactor the code to use ITM model before tackling this one here.

[hbeni]

Another idea would be to use some sort of backchannel to flightgear. In FGFS the addon could possibly craft answer packets to sample queries, and using the geo nasal library we can query arbitary points.
However, and thats the main reason I discarded that idea so far, I do not want such a tight coupling of the project to one simulator vendor.