One suggestion, right now there is no connection for people browsing to the flight numbers and letters. We just know a flight has been diverted. I suggest adding an extra data point about # of people diverted. Not sure what is available, so maybe how many people on board isn't, but based on plane type, you could probably add "up to X amount of people on board". Now one is like "wow 150 people landing at an airport they were not scheduled to!" Make it more human and compelling.
Also there are more flights diverted in a day than I would have thought!
I clearly remember when I finally let my initial prototype run on a laptop for a day and ignored it, an old HP laptop just chugging away parsing flight plan data, plugged in and running too hot in my office. By the next day I had > 20 diversions, with no notable weather, and assumed I had a bug in my logic.
Lots more to do here, including adding some weather details and someday predictive analytics. Thanks again for checking it out and the feedback.
The data processing is handled by two EC2's running Java to parse the FAA's flight plan feed. Peak midday that's running about ~65msgs/sec, a reduced and manageable number because I'm filtering for major airlines only (no GA, no bizjet, etc). The cleaned-up and filtered flight plan data heads to both Postgres for storage as well as SQS.
Consuming the SQS messages is a Python app that's crunching flight plans and confirming each flight is still heading to it's original destination (thanks redis!). If the destination airport changes, the flight gets flagged and some add'l business logic runs.
Ultimately you get the frontend (Django) presented here with a sprinkling of terrible JS to get the map and some timeline data.
I've been hacking with the FAA's SWIM data feeds for a few years now and hope to start sharing more of the technical details. Happy to answer any questions or hear some feedback!
