Home  >> soaring  >> igc file format

IGC file format homepage


I've written a few different programs for creating and analysing the IGC-format log files used in soaring as the accepted transcript of the route of a flight, and this page collects reference information helpful to developers.

As a plea, if you read an IGC file into your software, just pick up the records and fields meaningful to you and ignore records and fields you don't care about. If you want but don't get a 'pilot date of birth' (this is an optional field in an IGC file, I kid you not) don't have your software crash... just continue with a default value. If you see a record in an IGC file you don't recognise, just skip it. 99.999% of what needs to be done with an IGC file comes from reading the timestamped 'B' tracklog records (time, lat, long, alt), everything else is pretty much irrelevant overhead for most purposes. 'B' records can have additional optional values tagged on the end (e.g. speed) so if you just need time, lat, long, alt please don't have your software crash because the 'B' record is slightly longer than you expected, just read the fields you want and ignore the rest of the line.

In summary, the IGC file format is like every other 'GPS trail' file format, in that it is basically a container for a series of plain-text time-stamped location records one-per-line giving:

<time> <lat> <long> <alt> 

To cut to the chase a real IGC file could be as below (although most software will require additional header records):


And to explain the basic record format, using commas to indicate the actual fields:

B: record type is a basic tracklog record
110135: <time> tracklog entry was recorded at 11:01:35 i.e. just after 11am
5206343N: <lat> i.e. 52 degrees 06.343 minutes North
00006198W: <long> i.e. 000 degrees 06.198 minutes West
A: <alt valid flag> confirming this record has a valid altitude value
00587: <altitude from pressure sensor>
00558: <altitude from GPS>

So if we call the 'B' record a 'trackpoint' record, you can see an IGC file without any would be fairly pointless (that's a pun, by the way). However, IGC files can contain quite a few other record types, each indicated by a unique first letter and similarly terminated by a newline. Nearly all of the additional records are placed at the beginning of the IGC file, recording the DATE the trackpoints were created (this is important as the B records only contain the TIME) and also the name of the user, registration of the aircraft involved, type of logger used, other general stuff of that nature. NONE of these records actually care about the content, e.g. what is written for the type of the logger, so if that record is irrelevant for your requirement the usual approach is to populate the record with something generic, rather than omit the record.

So an IGC file that pretty much all display software would be happy with could be:
AXXX sim_logger v2.31
HFCM2CREW2: not recorded
HFGTYGLIDERTYPE:Standard Libelle 201 B
HFFTYFRTYPE: sim_logger by Ian Forster-Lewis
HFGPSGPS:Microsoft Flight Simulator
HFPRSPRESSALTSENSOR: Microsoft Flight Simulator

You would need to check the spec to understand the meaning of each of these header records, but the important thing to know is that the green stuff is whatever you want it to be. Software reading the file may or may not display or discard the HFGIDGLIDERID (the 7th record i this example), but if your usage doesn't actually have a glider id then set it to XX or anything else you don't care about...

In terms of priority, assuming you're coming to this page because you want to understand the IGC file format, you see from above you can get an effective tracklog file quickly with the header records plus a string of 'B' trackpoint records. Be prepared for most software to throw away most of your carefully considered header information, but you want to include it for other shite software out there which crashes if the file doesn't have e.g. a HFGIDGLIDERID: record.

I re-structured the FAI IGC 'Appendix 1' document section detailing the file format into an HTML file with cross-referencing links within it, so that references to (for example) the crucial B record can be linked to the right part of the specification.