The output currently generated by this program (I call it read_lgo 
because that's the name of the routine that contains main()) is two
ASCII formats that can be imported into MapInfo for Macintosh and Atlas 
Pro for Macintosh.  I suspect that the same files could be read into the 
corresponding DOS or MS-Windows products as well.  New formats can be 
added, but the code has to be patched somewhere (an if-else clause, 
probably, rather than a table entry with a function pointer, which I would 
use nowadays).

Both output formats generate two files, a geography file that contains the 
topology as ordered sets of points in latitude and longitude, and an 
attribute file that tries to glean whatever it can from the numerical 
attributes given in the DLG data.

BNA format (files bna.c and bna.h)

  I still don't know what the "BNA" means--the Atlas Pro documentation 
  says that Arc/INFO can handle it, but I think that's not true.

  The attribute file is tab-delimited text like what spreadsheet programs 
  generate when you Save As Text.  The first line is column headings; here 
  I hard-coded some categories that were of interest to me.  For each 
  geographic feature that is output, one line is added to the attribute 
  file.  The first column is a primary id that is keyed to the geography 
  file.

  The geography file is tab-delimited ASCII also.  Each feature begins 
  with a line containing a primary id, which links the feature to a line 
  in the attribute file, a name, which is "node", "area", or "line" unless 
  the feature is a political boundary whose name the program could 
  determine, and the number of points that follow.  The points follow, 
  with one point per line, x-coordinate (longitude) first, and west 
  longitude negative.  For area features, the order of coordinates is 
  significant; an area is traversed clockwise if it is a positive feature 
  (i.e. a normal boundary), and counterclockwise if the area describes a 
  hole in a normal feature.

  The program can output two different varieties of BNA files, one in 
  which the islands (i.e. the holes) are output as separate geographic 
  features (you determine whether a feature is a hole by looking at the 
  direction it traverses its bounded area--also "island" is given as the 
  name field of the feature's first line).  That is the format expected by 
  Atlas Pro (and, I suspect, all other Strategic Mapping products).  The 
  other variety appends the coordinates of the islands to the original 
  area; it traverses the outer boundary of the region clockwise, then 
  jumps to an inner boundary (island), traverses it counterclockwise, and 
  jumps back to the same point on the outer boundary.  This format is 
  supported by Tactician, another rather strange desktop mapping program 
  for Macintoshes.  [By the way, my boss is the one who likes Macs.  I use 
  one (in addition to DOS and UNIX machines), and I even write code for 
  them, but don't confuse me with a Mac fanatic.]

MIF format (files mif.c and mif.h)

  MIF stands for MapInfo Interchange Format.  This format is described in 
  MapInfo's manuals.  The program outputs version 1 MIF files.

  Like BNA format, the MapInfo format includes an associated attribute 
  file but the column headings are listed at the beginning of the 
  geography file, not in the attribute file.  Go figure.  Not 
  surprisingly, there is no primary ID; the order of entries in the two 
  files is critical; the first line in the attribute file describes the 
  attributes of the first feature in the geography file, and so on.  
  Delete a line in the attribute file and you're cooked.

  The geography file begins with a header that mostly describes the 
  attributes.  Each feature begins with a line indicating its type (POINT 
  for points, PLINE for lines, and REGION for areas or sets of related 
  areas).  For a point, the keyword POINT is followed immediately by the 
  coordinates, x (longitude) first, west longitude negative.  For a line, 
  the keyword PLINE is followed by the number of points in the line, and 
  that many subsequent lines contain the points, one per line (x first, 
  west negative, as before).  For an area, the keyword REGION is followed 
  by an integer indicating how many subregions there are (positive and 
  negative regions are all counted here).  Each region follows, beginning 
  with a line containing a single integer indicating the number of points 
  in the subregion, and that many lines following containing the points 
  themselves, one per line.  Positive areas are traversed clockwise, 
  islands or holes are traversed counterclockwise.  There is no other way 
  to determine from a MIF file whether a specific region contained in it 
  is positive or a hole.
  
  There MUST be a CR at the end of the MIF file.  MapInfo cannot cope with 
  a MIF file that does not end in a CR.  This is surprising because 
  MapInfo is otherwise a reasonably mature, sophisticated product (version 
  2, at least--version 1 was a dog).

There is a lot of stuff in this program that you may not need.  For 
example, it runs substantial checks on the topology of the input file, 
looking for topological errors (I have found none in the 1:2M files).  It 
also builds state boundaries (inexplicably, these were left out of the 
1:2M scale political boundary files!)  using code that must surely be 
impenetrable.

In its present form, the program cannot deal with DLG data that are not in 
an Albers projection as are the 1:2M data.  I would correct that in the 
future, but can't promise to.  I don't know whether this program works for 
1:100,000 or 1:24,000 scale DLG data.

Do check out the file Known_DLG_errors.  Most of the errors are in the 
attributes, but they alone can make your maps look pretty strange (like 
Long Island, NY is not coded as an island!).  The topology, by contrast, 
seems to have been checked before release.