Explanation of Mountainous Area and example calculation for a single point
One of the most asked questions we receive either through social media or while we provide training on PANS OPS is about the fact that DOC 8168 Vol II requires to consider that procedures that are designed for use in mountainous areas need to use an increased minimum obstacle clearance (MOC) of as much as 100%.
The rules are not really consistent also along PANS OPS, in some places it gives the procedure designer interpretation on how much to add as increase, in others it exactly mandates a specific number, but one thing is clear before doing anything there needs to be a defined area where this needs to be applied and this seems to be up to a certain point “made at discretion” by IFPD designers even if there is definition for it in the documents.
Lee-side turbulence is one of the phenomena to watch out in mountainous areas. You can read more Orographic influence on the leeward side about this here
The information about mountainous areas and increases is to be included in the State’s Aeronautical Information Publication (AIP) in GEN 3.3.5 Minimum Flight Altitude however most States just publish vague statements and hardly even mention the mountainous areas defined for the country. Not that ICAO provides a particularly good example also in the specimen AIP in DOC 8126 which just makes a reference to ENR 3 ATS Routes.
The definition of Mountainous area and how it is to be determined is buried in DOC 8168 VOL II in Chapter 1 Definitions, that is the only place where this is declared, and it is probably the less likely place most people will go to try to understand it. The definition is quite simple, but its application is sometimes not so easily understood, and this is without considering that most of PANS OPS uses complicated English explanations that could be simplified
Mountainous area. An area of changing terrain profile where the changes of terrain elevation exceed 900 m (3 000 ft) within a distance of 18.5 km (10.0 NM).
DOC 8168 VOL II 7th Edition
To illustrate the above definition let us do an example on what it means. We will use SRTM 90m data just as it is easily available and its relatively easy to handle and we will extract 10 NM bounding box (BBOX) around the TMA LA MESA, Honduras to work with. This will allow us to do calculations for mountainous terrain valid within the TMA LA MESA Airspace
Process could be to extract minimum bounding geometry for the TMA in a projected coordinate system as we need to use NM, buffer it 10 NM and then again get the minimum bounding geometry of the buffer to get the nice square magenta outline. Be sure to always make the resulting extraction match the extent of the bounding geometry used as “cookie cutter”
We also removed no data values that were encoded with -32767 and negative values by using the QGIS raster calculator using the following expression, you might need to consider if negative values make sense in your particular area though.
("DTM@1" >= 0)*"DTM@1"where DTM@1 is the name of your DTM. Similar results can be obtained in other software
The first part of the expression just selects anything that is above 0 m and it assigns True (1) or False (0) then we multiply it by the original value and we get a cleaned up DTM with values only above 0 m AMSL. If your country has negative heights then a bit more careful consideration may be required
The above will facilitate to work with as this type of analysis produces an intense workload on our computer and it requires a lot of computational power, we can adjust by dividing the tasks into smaller pieces we can then merge to obtain the complete picture. As terrain does not change very often this is probably an analysis that will need to be done just occasionally and be re-used until new terrain data becomes available.
First we draw a circle of 10 NM around a point, in this case we will use the VOR/DME SAP and extract the raster within it
Running the raster statistics for this extract provides the following values
Here is the same image showing the min and max value points which are influencing on the decision to declare the location of the navaid as mountainous.
Max value – Min Value > 900 m
1214 – 8 > 900 m
1206 > 900 m
TRUE
Now the above analysis is just valid for the location of the VOR/DME SAP! This means we need to repeat the same process for each raster pixel in our DTM. Just for completeness here is a small explanation on what a raster is at mapschool.io
Each of those small squares aka pixels will need its centroid to be calculated, then a circle of 10 NM drawn around it and extract the DTM cells within that circle to extract the minimum and maximum values and then do the difference of those to check if it is more than 900 m. If that is the case that pixel is classified as fulfilling the criteria to be considered mountainous terrain. In essence repeating the process described for the VOR/DME SAP but how many times?
In our DTM LA MESA sample it contains approximately more than 4 million points for the whole area so this is where most procedure designers just say this is impossible to do, we can’t do 4 million times the same process to get the result, and this is not even considering this is just one TMA not the whole country.
This is where the power of using software like GIS, MATLAB or programming something in Python or R. Since most Instrument Flight Procedure Designers will not have the ability to code this explanation is based on using QGIS with GRASS, they are both opensource software and you just need to download the latest installer and double click the QGIS with GRASS option enabled to launch it
For most users, the 64-bit installer for Windows work but if you use Linux or Mac, it will run also on those platforms you just need to select the appropriate packages. So, this is the first win you are not paying a license to use it and you can install in your preferred operating system.
Until now we have just made an example for a single point, in the next part we are going to be extending this concept for the complete TMA using more advanced GIS concepts using QGIS.
0 Comments