Cockpitvisit, awesome tool, thank you very much! This is so incredibly useful!

Here are my comments and things I stumbled across during a few days of use.

I understand that your data sources do not differentiate between code-shares and flights by subsidiaries. That is the only real drawback I found so far. I normally want to include flights from subsidiaries/regionals but usually exclude code-share flights such as SYD-JNB operated by Quantas when I limit the network to Star Alliance, for example. Well, I understand it's one minor limitation that it looks like we'll have to live with.

The setting to include regionals and code-shares in the results is very important. At the same time the full meaning and scope of this term will not be clear to the uninitiated (like me). Most will not bother to read this thread (I'm surprised about your patience with all these "give me a Mac version", "how do you zoom without a mouse", etc.). May I still suggest to change the tooltip for the menu entry to "Show codeshares and regionals (recommended)", adding the underlined part? I think it's safer to have it on than off as default for people who don't fully understand what it actually does.

For the benefit of those who actually do read this thread, I will point out three important lessons I learned when I felt there were routes missing in the database. First is to activate above setting and see if that brings up the flights. Second, if that is not sufficient, make sure the subsidiaries are not operating under their own code (JQ and 3K, BL or AK and FD, D7 come to mind). Third, make sure it's not a seasonal route. For example, I thought that NH SDJ-OKA, NZ SYD-RAR and NZ NAN-CHC among others were missing. Well, they're not, it's just that those routes are not operational for the current month, June 2011.

Speaking about seasonals, I still find them to be very important pieces of information. I remember that you previously turned down the request to include several months worth of route data, citing the amount of data involved as the reason. I suppose that's the amount of data you need to process, not the size of the routes.dat file? It's my understanding that you currently process one month of data. Would it be possible to add 2 weeks worth of data each about three and six months out? I think that should take care of the seasonal routes without a six-to-12-fold increase in overhead for you.

The following routes ARE indeed missing and I was wondering if there is a way for you to add them; extended long-hauls. NZ1 LHR-LAX-AKL or UA846 EZE-IAD-SFO come to mind. These kinds of connections can be very beneficial for award bookings since they consume only one segment despite the actual two flights (who share the same flight number).

One very minor let-down was that custom airline groupings are reset on restart of the program and switching the sorting of the airlines in the drop-down box. The latter one is a bit unexpected.

PZ needs to be added to the Star Alliance members in alliances.dat

Is this still an issue? I think it would be fairly straight-forward, all entries are unique keys in a database. I'll assume that under normal circumstances flights need only be added (after all, you did find the routes in a current timetable). "sort routes-from-scraping.dat routes-manually-added.dat | uniq > routes.dat" would prepare the new routes.dat for distribution. It would still be fairly easy even if there was a need to delete or change routes from the ones you automatically collect. Let me know if I can help you with this. Maybe this is the right way to tackle the extended long-hauls if collecting them automatically is too cumbersome?