HAFAS Binary Interface Data Format - smurfy/fahrplan GitHub Wiki

There seems to be no publicly available official documentation for this data firmat. Due to being a binary one, it cannot be easily inspected for available data like with HAFAS XML. However, it has been (partially) reverse engineered.

The reply comes as binary data compressed in gzip format. So it has to be decompressed and then parsed.

Here's one description of decompressed data format (source):

File header:
0x00-0x01: Version (2B),
0x02-0x0f: Origin location block (14B),
0x10-0x1d: Target location block (14B),
0x1e-0x1f: Journey count (2B),
0x20-0x23: Service days position (4B),
0x24-0x27: String table position (4B),
0x28-0x29: Date (2B),
0x2a-0x2b: Unknown date, 30 days after Date (2B),
0x2c-0x2d: Unknown date, 1 day before Date (2B),
0x2e-0x35: Unknown,
0x36-0x39: Stations position (4B),
0x40-0x43: Comments position (4B),
0x44-0x45: Unknown (2B),
0x46-0x49: Extensions header position (4B)

Journey header (fixed position, directly after file header, 12B per journey):
0x4a-0x4b: Service days offset, together with the position in file header
it points to the service days block (2B),
0x4c-0x4f: Parts offset (4B),
0x50-0x51: Part count (2B),
0x52-0x53: Number of vehicle changes in this journey (2B),
0x54-0x55: Unknown (2B)
0x56-....: Next journey header

Location block (only used in file header):
+0x01-0x02: Offset in string table to the name of the location (2B),
+0x03-0x04: Unknown (2B),
+0x05-0x06: Type (1: station, 2: address, 3: POI, 2B),
+0x07-0x0a: Longitude of the stop multiplied with 1 million (integer, 4B),
+0x0b-0x0e: Latitude of the stop multiplied with 1 million (integer, 4B)

Service days block (position specified in journey and file header):
+0x00-0x01: Offset in string table of the service days string (2B),
+0x02-0x03: Service bit base, used to calculate a date offset in days (2B),
+0x04-0x05: Service bit length, used to calculate a date offset in days (2B),
+0x05-....: Service bits, each 1B, number defined by service bit length

Stations block (position specified in file header, 14B per stop):
+0x00-0x01: Offset in string table, where the name of the stop is stored (2B),
+0x02-0x05: ID of the stop (4B),
+0x06-0x09: Longitude of the stop multiplied with 1 million (integer, 4B),
+0x0a-0x0d: Latitude of the stop multiplied with 1 million (integer, 4B),
+0x0e-....: Next station

Comments block (position specified in file header and journey part block):
+0x01-0x02: Number of comments (2B),
+0x03-0x04, ...: Offsets in strings table to the comments (each 2B)

Extensions header (position specified in file header, 42B):
+0x00-0x03: Length of this header, normally 50B (4B),
+0x04-0x07: Unknown (4B),
+0x08-0x09: Sequence number, used when requesting more journeys (2B),
+0x0a-0x0b: Offset in string table of the Request ID string (2B),
+0x0c-0x0f: Journey details position (4B),
+0x10-0x11: Error code (2B),
+0x12-0x1f: Unknown (14B),
+0x20-0x21: Offset in string table of the encoding string (2B),
+0x22-0x23: Offset in string table (2B),
+0x24-0x25: Attributes offset (2B),
+0x2c-0x2f: Attributes position, if extension header length >= 0x30
(otherwise it is 0), at this position attributes indexes
are stored for  all journeys, each 2B. At position attributes
offset +  four times attributes index for a journey,
the offset in the string table to the journey ID can be found (4B)

Journey details header (position specified in extension header, 14B):
+0x00-0x01: Journey details version, 1 expected (2B),
+0x02-0x03: Unknown (2B),
+0x04-0x05: Journey details index offset, together with the position
in the extension header, this is the offset of the position
where journey details are stored for all journeys, each 2B (2B),
+0x06-0x07: Journey details part offset (2B),
+0x08-0x09: Journey details part size, 16 expected (2B),
+0x0a-0x0b: Stops size (2B),
+0x0c-0x0d: Stops offset (2B)

Journey details block (position specified by journey details
and extensions header, 4B per journey):
+0x00-0x01: Realtime status, a 2 here means "train is canceled" (2B),
+0x02-0x03: Delay (2B)

Journey details for parts blocks (position specified by journey details and
extensions header):
+0x00-0x01: Predicted departure time (2B),
+0x02-0x03: Predicted arrival time (2B),
+0x04-0x05: Offset in string table to the predicted departure platform (2B),
+0x06-0x07: Offset in string table to the predicted arrival platform (2B),
+0x08-0x0b: Unkinown (4B),
+0x0c-0x0d: First stop index (2B),
+0x0e-0x0f: Number of stops (2B)

Stops block (position speficied in journey details header and
journey details for parts blocks):
+0x00-0x01: Planned departure time at this stop (2B),
+0x02-0x03: Planned arrival time at this stop (2B),
+0x04-0x05: Offset in string table to the planned departure platform at this stop (2B),
+0x06-0x07: Offset in string table to the planned arrival platform at this stop (2B),
+0x08-0x0b: Unknown (4B),
+0x0c-0x0d: Predicted departure time at this stop (2B),
+0x0e-0x0f: Predicted arrival time at this stop (2B),
+0x10-0x11: Offset in string table to the predicted departure platform at this stop (2B),
+0x12-0x13: Offset in string table to the predicted arrival platform at this stop (2B),
+0x14-0x17: Unknown (4B),
+0x18-0x19: Offset in stations table, where data about the stop is stored (2B)

Journey part block (position specified in journey header):
+0x00-0x01: Planned departure time (2B),
+0x02-0x03: Offset in stations table,
where data about the departure stop is stored (2B),
+0x04-0x05: Planned arrival time (2B),
+0x06-0x07: Offset in stations table,
where data about the arrival stop is stored (2B),
+0x08-0x09: Type (1: Footway, 2: Train, Bus, Tram, ...),
+0x0a-0x0b: Offset in string table of the transport line string (2B),
+0x0c-0x0d: Offset in string table of the planned departure platform (2B),
+0x0e-0x0f: Offset in string table of the planned arrival platform (2B),
+0x10-0x11: Journey part attribute index (2B),
+0x12-0x13: Offset to comments for this journey part (2B)

Attributes block (position specified in extensions heaer and journey part block):
+0x00-0x01: Offset in string table to a key (eg. "Direction", "Class"),
which specifies the meaning of the following string (2B),
+0x02-0x03: Offset in string table to a value, meaning specified in last string (2B),
+0x04-....: Next attribute blocks, until the key string is empty

Also, there seems to be some additional information not present in the format description above that's extracted by public-transport-enabler project. File enabler/src/de/schildbach/pte/AbstractHafasProvider.java deals with both HAFAS XML and Binary interfaces.

Particularly interesting commits ATM are: a29fe3811e (canceled departures / arrivals), 6c02caf0f4 (disruptions?)