Don Brown has an interesting post on the hassles that aerial survey flights can create for ATC. He also touches on the hassles of direct, off-airway routings. I thought about posting a comment, but didn't think I could get my points across in 300 words or less, so ...
Don's first observation is how much of a pain aerial survey flights can be for controllers. I've flown a number of survey flights and let me tell you, they are a pain for the pilots and camera operators, too. I'm sure working these flights as a controller is tedious, but imagine the concentration required to maintain altitude +/-20 feet and course within 10 meters for hours at a time. Add to that the problems created by turbulence, an occasion cloud shadow, the odd traffic alert, camera malfunctions, and a mapping site located smack-dab in the middle of an arrival path for two major Bay Area airports. It's clear that no one is having fun.
Aerial survey flights are a lot of work for everyone involved, starting with the GIS person who lays out the job. During my survey flying, I've been fortunate to have received excellent and understanding service from the controllers in Northern California as well as from airline crews that had to alter their course or altitude while we bored holes in the sky, back and forth.
I had one mission that involved a bunch of east-west lines right over the top of Travis AFB and the Travis Alert Area. The controller did a pretty good job, but he kept asking what we were doing and which direction we were going. I explained at least three times that we would be flying east-west lines, gradually working our way from south to north, but he couldn't visualize it. I tried explaining it different ways while simultaneously flying my photo lines. It was distracting, but I finally managed to word it in a way that he understood. Or maybe he just gave up trying to understand?
I'd say any sort of training that helps controllers appreciate aerial survey missions is probably a good thing. One silver lining during that Travis flight was that someone reported hearing an emergency locator transmitter (ELT) signal and I began monitoring the guard frequency on our second radio. As we went back and forth, I was able to give the controller a pretty good idea of where the signal was strongest.
On the subject of direct, off-airway routings, there are several problems the FAA needs to address. It's obvious that the aviation navigational landscape is changing and the ATC system is not providing pilots and controllers with enough tools to keep up with the changes. Here are just a few examples:
Any pilot who uses a GPS receiver knows that the FAA's way of identifying airports on charts with three-character identifiers is ambiguous, especially when there is an airport and a VOR station with the same name. This could be solved if the FAA would just use four-character ICAO airport identifiers on the charts they publish. That way, pilots and controllers would have a better idea of when they were referring to, say, the Santa Rosa Airport (KSTS) versus the Santa Rosa VOR (STS).
The FAA has started to create routes specifically designed for RNAV-equipped aircraft. T-routes, Q-routes, and GPS MEAs on established airways are all steps in the right direction. But T-routes and Q-routes mimic the old Victor airway paradigm and don't really address random, off-airway routings.
The section 5-1-8(c) of the AIM has specific suggestions for pilots who wish to file direct routes between VORs and off-airway routings. It briefly explains how you can file VOR to VOR or use off-airway routings. One requirement is that an off-airway route must contain at least one waypoint within each Air Route Traffic Control Center (ARTCC) through which the flight will travel, but I imagine from a controller's perspective this can be like finding a needle in a haystack.
The AIM explains that you can use latitude and longitude coordinates to specify off-airway waypoints, but lat/long is a pain for pilots and controllers alike. Just yesterday I had an instrument pilot show me his DUATS-generated IFR navigation log, which contained a couple of automatically generated lat/long waypoints. When he asked me how he would go about entering them into his Garmin 530W, I cringed. I thought about delving into how you first need to create a user waypoint and then enter the latitude and longitude, a digit at a time, but there is need to know and nice to know. User waypoints defined with lat/long is not a need to know item, in my opinion.
Pilots need to do some careful pre-flight planning to be sure their direct route stays at least 3 miles from restricted and prohibited airspace as well as military operation areas (MOAs). APOAs new Internet Flight Planer is definitely a step in the right direction. Using it, pilot's should be able to layout direct, off-airway routings that meet all the requirement specified in the AIM. But what about controllers? What tools do they have?
A big problem with off-airway routes is that these routes are often hard for controllers and pilots to understand and visualize. As Don correctly points out, who the hell knows where lat/long fix 3217/8326 is actually located? Without some known context, a landmark, an airport, or a VOR, it's just a string of numbers. It seems to me that controllers would benefit from a tool or feature that would allow them to quickly resolve an unfamiliar airport identifier, fix, or lat/long waypoint to a position on their radar screen. I remember sitting next to an ZOA controller during a facility tour several years ago and seeing how he could select an aircraft target on his screen, press a button, and see that aircraft's projected track. Wouldn't it be cool if a controller could select a target, press a button, and see the aircraft's current IFR routing appear on their screen? Maybe this feature already exists, but based on what I hear controllers say, I doubt it.
The more things change, the more they stay the same. I wrote a while back about how ATC's automation often can't accommodate flight plans with RNAV, off-airway routings. It seems that most controllers don't even know which targets on their screen are RNAV capable. Pilots often have no choice but to accept a clearance and, once airborne, begin asking the controller for a shortcut, reminding or informing the controller that they are RNAV-capable.
Pilots and controllers live in intersecting, yet different worlds. Most pilots don't fully appreciate the constraints under which controllers operate, the rules and procedures they need to follow, and the complexities of managing a bunch of aircraft traveling different directions at different speeds. Controllers often have a hard time understanding the operational constraints that pilots face, too. And the primary way these two worlds communicate with each other is through a half-duplex radio system. Given all this, it's amazing that things work as well as they do.
Wouldn't it be nice if someone came up with a way to reconcile some of the differences between these two worlds? I'm not touting NexGen, I'm interested in hearing what my readers have to say. What features or tools do you think are needed for the new aviation navigational world we seem to be entering? What do you think would help GA pilots?