{ "id": "2003-septemberoctober-making-sense-of-navy-aviation-crash-data", "slug": "2003-septemberoctober-making-sense-of-navy-aviation-crash-data", "url": "https://dwillis.github.io/uplink/article/2003-septemberoctober-making-sense-of-navy-aviation-crash-data.html", "year": 2003, "month": "September/October", "monthNum": 9, "headline": "Making sense of Navy aviation crash data", "kicker": "Tech tip...", "author_name": "Richard O'Reilly", "author_title": "", "affiliation": "Los Angeles Times", "summary": "The Los Angeles Times used the Naval Aviation Safety Database to investigate U.S. Marine Corps Harrier jet crashes, but encountered significant FOIA restrictions that excluded narrative fields and conclusionary information while providing only basic coded data.", "keywords": [ "database", "military", "FOIA" ], "topics": [ "Investigative Methods", "Public Safety", "Data & Databases" ], "technologies": [ "SAS", "UltraEdit" ], "full_text": "Making sense of Navy aviation crash data\n\nThe Naval Aviation Safety Database was one of the research sources for the Los Angeles Times' Pulitzer Prize-winning series on the U.S. Marine Corps Harrier attack fighter jet. The four-part series, published Dec. 15-2002, also won an IRE Certificate.\n\nReporters Alan C. Miller and Kevin Sack found the bulk of their material through numerous interviews and nearly 90 Judge Advocate General accident reports obtained under Freedom of Information Act requests. But an analysis of the Harrier through the Naval Aviation Safety data provided scope, context and nuance to the project.\n\nBrief summaries from the database are available on the Navy Safety Center Web site, www.safetycenter.navy.mil The full database must be requested via FOIA from Josie Bowden, 757-444-3520, ext. 7045 (JBowden@safety.center.navy.mil).\n\nIt took us months to get the database after filing the request. And when we received it, we found that data from 218 fields, about 27 percent of the 807 fields then in the database, were omitted on privacy and national security grounds. An appeal failed. What we got instead was the brief public summary of recent Harrier accidents supplied by e-mail. It was exactly the same data we could have copied from their Web site, which was useless for analytical purposes.\n\nVirtually all of the extensive narrative fields contained in the database were excluded. That had the effect of removing all conclusionary information. Personnel data on injuries, causes and even the severity of injuries was withheld. Gender, date of birth, rank and unit were provided. But the field containing first and last initials was omitted.\n\nAlso missing were fields that identified recurring problems, identified instances in which planes were not in compliance with Marine standards and in which problem parts had been cannibalized from other aircraft. A field that provided a detailed identification of the component damage or failure was omitted. However, a field that identified materials or components involved in the incident was provided.\n\nData on Marine aircraft are contained in the Navy database because Marine funding is routed through the Navy, and the Navy is responsible for maintaining safety data for the Marines.\n\nWhat the Navy eventually provided was a complex, well-documented, clean set of related data tables in tab-delimited format. There is a mix of data tables and code tables. Many of the fields in the data tables are coded. Code translation tables were provided for each of the coded fields we received. However, the translation tables for coded fields that were omitted also were omitted.\n\nA large-format table relationship sheet was provided, as was a table list text file and a data dictionary text file. The table list (with the file name av_tablist.rtf) gave a simple list of table names, field names, types and sizes and whether the field was omitted or not. The dictionary file (av_dicty.txt) gave an English translation of field names plus an explanation. For example, the field \"bank_degs_left\" in the table \"av_actt_at_esc\" was described as follows: \"LEFT BANK DEGREES-The left bank of the event aircraft in degrees at the time of escape.\"\n\nWhere fields were omitted in tables, the field place was held by a null value (hex 00) between the tab characters. That caused problems for me when reading the data into SAS. Therefore, I copied the original tables and then, using UltraEdit, did a search and replace across all the file copies in one operation to translate a tab-null-tab string into a tab-space-tab string.\n\nSome of the code fields proved to contain hierarchical codes, which were not explicitly documented. An example is \"incdt_phase_ops_c\" in the table \"av_incdt_occurn.\" It is described in the dictionary as \"Significant Incident Phase Operation~The phase of operation in which the event aircraft was engaged, at the time the coded subject significant incident occurred, in the evolution of the reportable event.\"\n\nAn example entry in the three-character field is \"33Z.\" The code translation table renders that as \"No further breakdown,\" which is meaningless. In the same code translation table, however, you find that \"3\" translates as \"Takeoff forward motion on run/catapult until attaining climb schedule.\" And \"33\" translates into \"Aircraft breaks ground climb schedule not yet attained.\" In other words, that single three-character field can be decoded into three separate, related meanings.\n\nThere are other examples. The five-character field \"imc_c\" in the table \"av_eng_cmpnt\" is described in the dictionary as \"Involved Material Component~Identifies the Naval Safety Center code relating to the category of the event aircraft's component or engine (power plant).\"\n\nOne such entry is \"T1007\", which is translated in the field code table as \"Compressor pressure limiter section.\" The \"T\" alone translates into \"Turbo-jet engine,\" and the first three characters, \"T10,\" mean \"Regulator-not detailed.\" Thus the code must be parsed to gain its full meaning.\n\nMy solution for all of the hierarchical codes (which were identified by inspecting the code table translations for partial string definitions) was to create new fields in the table to contain just the partial strings that had separate meanings. Thus I created an \"imc_a\" field that was only the first character of \"imc_c,\" and an \"imc_b\" field containing the first three characters of \"imc_c.\" This was easily done because all of the hierarchical fields contained the full complement of characters specified in the table list and dictionary files.\n\nThe Naval Aviation Safety Database contains records (more than 48,000 in the mid-2002 version we received) of \"events\" from Jan. 1, 1980, to within the last several months. An event can range from a no-damage, no-injury maintenance or operational problem that could have a safety impact and thus meets the criteria for reporting, to loss of an aircraft and its crew. The most dramatic events are those known as \"Class A,\" with at least $1 million in damage or fatal injury.\n\nThere are three primary trajectories for analyzing the data - events, persons or aircraft - each of which utilizes its own key field for table joins. Within those trajectories there are subsidiary keys that join more detailed tables. As a result, you can end up with a lot of tables joined together, which can lead to a lot of rows being added as details embellish what started out as a single row for a single event. Much of the data will be constant and repeated on those rows, such as the total cost of the event, or the event category, or even the tail number of the aircraft. Other fields on the rows will contain unique data, as when several different components are involved, causing several rows from the component table to be joined to the aircraft table.\n\nUltimately, it is necessary to recode and collapse data to analyze it accurately. There is a lot of missing data, beyond what was withheld. The data collected has undergone a number of revisions since 1980. Later events have more complete data than earlier events. Sometimes data is missing because it is not relevant to a particular event.\n\nTo compute accurate percents for occurrences, the denominator has to be just the events for which the data exists. For instance, some reports for Class A events involving the Harrier did not have any data on the components involved. I created a new logical field called Parts, with \"Yes\" meaning there was parts data and \"No\" when it was missing. Then when calculating the percentage of jet engine problems, for instance, I divided by the count of Parts = Yes.\n\nIn some cases I forced empty records to sort at the bottom of a list instead of the top by recoding a blank field to \"zzz.\"\n\nIf the summary being created involves a number of fields, it probably will be necessary to make several intermediate tables by doing record-by-record inspections and editing. That's because it probably will not be possible to sort across several fields and end up with the data desired from each field rising to the top of the sort.\n\nThe most important advice I can give is to be skeptical of every result you derive and try to figure out an alternate way to get it. If you come up with the same result two different ways, it is probably reliable. But if you get different results, you'll need to figure out why and fix it.", "provenance": { "extracted_by": "anthropic/claude-sonnet-4-6", "extracted_at": "2026-07-05", "verified": true }, "similar": [ { "slug": "1996-june-crash-course-on-plane-crashes", "score": 0.229 }, { "slug": "1999-december-successful-e-foia", "score": 0.208 }, { "slug": "2005-marchapril-peace-accidents", "score": 0.204 }, { "slug": "2006-november-december-on-the-foia-front", "score": 0.174 }, { "slug": "2000-januaryfebruary-uncovering-secrets", "score": 0.169 } ], "html_url": "https://dwillis.github.io/uplink/article/2003-septemberoctober-making-sense-of-navy-aviation-crash-data.html", "json_url": "https://dwillis.github.io/uplink/article/2003-septemberoctober-making-sense-of-navy-aviation-crash-data.json" }