Graphical User Interface to Add Custom Navigational Data to Base AIRAC Package

We shall use your suggestion for potential enhancements and new functionality. So, please be as detailed as you can.

Only one issue per thread so that others can easily see what has been reported.

The particular use case I’m interested in solving is “Conducting a Company GPS approach to a private (uncharted) helipad”.

To do so, there are three different features that are really needed (and are essentially corequisites, otherwise they’re not too useful individually)

  1. Allow users the opportunity to create custom airports and other navigational fixes with the appropriate metadata for navigation (country, transition altitude, field elevation, mag var, etc.)
  2. Allow users the opportunity to code custom procedures based on ARINC 424 standards
  3. Allow users a means to review coded procedures from Step 2 graphically (showing flight path envelope and terrain clearance in a user-friendly guide.

So to expand a little bit:

1. Allow users the opportunity to create custom airports and other navigational fixes with the appropriate metadata for navigation (country, transition altitude, field elevation, mag var, etc.)

This covers a few things, including (but not limited to):

  • Airfields and heliports/helipads
  • RNAV fixes
  • Nav Aids (GNSS representations of them at least, realizing that Nav Data doesn’t necessarily imply the physical existence of the Nav Aid)
  • Airspaces
  • Routes (low level or high level)

The primary intended function is to allow a user to addend their custom airports where no such data exists in the base AIRAC. A great example is as follows. Duluth MN only has one helipad shown, the St Mary’s Helipad (which doesn’t even exist in the FAA AF/D, nor is it in Navigraph’s nav data):
image

In contrast, there are 3 entirely independent helipads, all of which carry traffic:

Operators conducting HEMS flights in Duluth are no stranger to IMC; it’s gray and bleak 70% of the time when it’s not scorching summer 3 weeks a year. Operators will depend on this data being in their nav systems in order to be able to reliably approach them safely. Which brings us to our next subject:


2. Allow users the opportunity to code custom procedures based on ARINC 424 standards

Just recently (2015), Boston MedFlight achieved approval to conduct company Instrument Approaches into various heliports around the Boston area. This allows them to take advantage of their GPSs to navigate a busy metropolitan airspace (in potentially IFR conditions).

For a user to be able to conduct a custom RNAV approach based on existing nav data for their aircraft can prove beneficial for multiple reasons:

  1. Some airports only have approaches to specific runways for OpSpec certified operators. Allowing a simmer to create a similar approach allows them to take advantage of the benefits those operators are allowed to take advantage of.
  2. Some airports may not have any approaches published at all despite them existing (e.g., poorly published data, in the example of China, e.g.). This opens up access to those airports that would otherwise require VFR conditions to be accessed.
  3. If an airport was added by a user from point 1 above, it is likely that an approach will be needed (whether or not one is published).

Of course, competency of the user in generating an instrument approach is going to be a sticking point; it’s unlikely any simmer took a TERPS class, so that brings us to Point 3 to make any of Point 2 accessible to the average user:


3. Allow users a means to review coded procedures from Step 2 graphically (showing flight path envelope and terrain clearance in a user-friendly guide.

Whether you follow the ICAO Doc 8618 or FAA Order 8260.3, Obstacle Clearance isn’t a visually intuitive thing, not to mention the rules around them can be convoluted. I picture something that can turn this visually difficult-to-process thing:


to something more intuitively depicted in the context of the terrain and airport:
image


To summarize: there’s a lot of power with current Nav Data, but there’s more capability waiting to be offered to simmers like us that like going out of the ordinary and doing something more niche. In doing so, I’m asking for tools that aren’t only useful to us Heli Simmers, but can be used by other simmers for their own applications (whether its OpSpec stuff into PAJN where Alaska Airlines has a secret instrument approach, or they’re flying in China where there is no Nav Data and users will have to work together to paint an imaginary picture).

I hope this gets considered by the Navigraph team, despite being inherently multiple (potentially inseparable) requests.