Why scripting/automating tasks is a smart thing?
As we move more and more into the digital age the concepts continue evolving with regards to instrument flight procedure design (IFPD), some of the designers around the world are still working completely in a manual environment and in this case we are not talking about pen and paper which is mostly OK still for training events but using some sort of computer assisted design tool (CAD), geographic information system (GIS), spreadsheets or a combination of all of them together maybe even with other tools.
Although fully automated systems that can integrate with existing databases and industry interoperability standards are important and we all try to acquire these tools, it also true that many countries are not able to afford the asking price for software and still produce their designs without any level of automation. Spreadsheets usually become the first encounter with trying to automate tasks by using them to do calculations for different parameters and areas which are then translated into the selected CAD/GIS platform for the drawing and then analysis for obstacles is done either completely manual or some sort of workflow is established in order to get some calculations back into the spreadsheet to get a final result. This works great when you have a single airport or a few dozen obstacles.
Scripting to gain more control
The next level of automation is to bring some of the calculations and manual drawing together into the software we are using through the scripting or programming language using the built in tools that are exposed. In this stage we are not really providing an user interface (UI) or worrying too much on the user experience (UX), so the UI/UX is not really that pretty and probably does not automatically validate most or all of the data so it still relies on the instrument flight procedure designer to input the correct values and parameters in order to get the expected result. Experienced procedure designers and organizations may like the flexibility of having their own commands written for their workflow instead of having to adapt to the COTS tool philosophy which may be different.
New procedure designers specially those without adequate training will not benefit from this way of doing things. The lack of COTS “wizard” settings that sometimes offset insecurities on what to do or use is not available, but then again using completely automated design brings in the risk that a designer without the required knowledge is pulling out designs based on “passing” software hard coded rules. For the most part these rules are OK and even more conservative than what PANS OPS Doc 8168 Vol II or even the RNP AR manual require.
QGIS with some python scripting
Custom development of in-house instrument flight procedure design scripts that help in automation can benefit organizations for many reason, it can be that they just want to check independently some of the COTS calculations or it may be regulators who do not need a full fledge high end automated system to review procedures but whatever it is you can achieve pretty good initial results by investing some time doing scripting in a programming language you may feel comfortable.
For the most part we use python since we are heavily into the use of GIS tools like QGIS, in the following video we show just a proof of concept of what we have done that works for us
Scripting tasks is a great way to enhance automation and to come into the digital era, if you or your organization are still requiring a COTS then there are several out there in the market you can choose from but even with those sometimes you will need to do some data preparation of either terrain, imagery or even obstacles to be able to use them. Give it a try we are sure you can benefit from it
FLYGHT7 can help you with advice, training or design on your next instrument flight procedure design or even your aeronautical charting needs. Contact us if you require further information
Happy Procedure Designing!