FYI, to add to Leo's list of elaborations on direction_id, TriMet includes a route_direction.txt file, which includes route_id,direction_id,direction_name. I think there's a proposal (circa ~2008) out there for route_direction.txt. There is also (at least) 1 implementation for route_direction,txt in gtfsdb (
https://github.com). A route-direction file with named directions is useful where a route/direction has multiple end points (e.g. it would be hard to determine the proper direction/destination name, based on collecting & counting & concatenating head sign information at the trip level, and trying to come up with a destination name based on multiple different trip names, etc...). For example,
https://trimet.org/ride/stop_select_list.html?route=15 (and
https://trimet.org/schedules/w/t1015_0map.htm) has trips that terminate at 4 different destinations (e.g., Portland City Center, Thurman, Montgomery Park, or Yeon & 44th) ... so having someone manually name the route destinations, and have that named route direction in GTFS via a route_directions.txt (or directions.txt ala Trillium's file) is necessary ... there's no way I could imagine constructing that destination name w/out the benefit of route_directions.txt.
FWIW, the original proposal for direction_id in the trip table was timetable production, where a timetable would exist as a bi-directional pair (in most cases...uni-directional in some). Was easier to just specify 1 or 0 for the two directions in trips.txt, rather than trying to assign buckets of trips based on a stop list, since there were a handful of ambiguous corner cases (e.g., diamond routes and short-line trips might only share a stop or two with the predominance of other trips, such that assignment of a given trip to direction X or Y could be ambiguous at best).