I’m building a GCS that responds to TERRAIN_REQUEST from Ardupilot vehicles, by replying with the relevant TERRAIN_DATA messages for each request.
I’m trying to get the altitude from DAT files available on https://terrain.ardupilot.org/. For example, after unzipping https://terrain.ardupilot.org/continentsdat3/Islands.zip, there are many .DAT files, e.g. N16W170.DAT.
After reading how this file is generated (terraingen/terrain_gen.py at b878e8bbb76df598d58d91cb17eb3263e6d51b49 · ArduPilot/terraingen · GitHub), I understand that:
- we don’t use 8x8 (simpler) so that we can pack both the data and the metadata in 1 disc block (2048 bytes) to get faster disk IO
- these data files (
.dat) contain multiple blocks - each block contains 7x8 of mavlink grids (56 in total) . Note: 7 wide/x, 8 tall/y.
- each mavlink grid contains 4x4 (16 in total)
- each grid item is a int16, representing the altitude
However, the mavlink docs for terrain protocol illustrate that the data is 8x7 (8 wide/x, 7 tall/y).
Therefore, it seems to me I would need to calculate/interpolate every value needed for the TERRAIN_DATA, because the values are not packed in the same way. That seems a bit inefficient? I believe if the data files were consistent with the terrain protocol format, we would be able to just read bytes from disk and send it to the vehicle over mavlink, without interpolation? So even the Ardupilot flight controller would have to do this when it reads the DAT files from disk? Or could there be a bug in the DAT file implementation?
Does that make sense?
