Digitized-lines (.dig) file format

Output from my program Digitise is always in .dig format, as is output from my map-projection utility program Projector.
This format is read and used by all my graphical mapping programs (FiniteMap, NeoKineMap, RetroMap),
by my F-E grid-editor OrbWin, by my neotectonic-kinematics program NeoKinema, and by my paleotectonic-kinematics program Restore.  

Although it is not yet a recognized GIS-community standard, the .dig format is extremely simple and flexible.
If you acquire digitized lines in some other format, you can easily write a short utility program to convert them.
For example, I offer utility program SHP_toFrom_xyDIG, which converts ESRI Shapefiles (*.shp) and associated dBase files (*.dbf) into .dig files (and vice versa).
Perhaps you could use a commercial GIS program to Export any useful file(s) that you have found, choosing Save As Type: ESRI Shapefile .shp (and .dbf) files, from which the utility just mentioned will produce .dig files.

What makes the .dig format so simple is that it only represents lines: degenerate “lines” consisting of a single point; straight lines defined by two end-points; and/or jagged multi-point “polylines.”
It does not try to represent smooth curves, areas, or text.
Also, no graphical line-attributes (e.g., color, width, continuity, ...) are stored here; only (optional, but strongly recommended) text labels are allowed.
Therefore, a polyline in a .dig file is just a list of (x, y) or (longitude, latitude) coordinate pairs from a 2-D space (Cartesian plane, or spherical surface),
followed by a standard end marker “***” at the beginning of the next file-record.

There is no hard limit on the number of points in each polyline, although some of my programs may need to be recompiled if the number exceeds 4000.
It is legal (but not very useful) to have only one, or zero, points in a polyline.
There is no limit to the number of polylines in a file.

It is extremely easy to merge two .dig files; you simply concatenate them.
At a Windows command prompt (similar to the old DOS-prompt or UNIX-prompt interfaces), you can do this by typing something like:
      COPY faults1.dig+faults2.dig all_faults.dig
Or, you can combine two .dig files using any plain-ASCII text editor program, like NotePad or EditPad Pro.
If you have used text labels to identify your polylines (as recommended), then you can use any simple ASCII text editor to edit the files and delete or replace polylines.

Scientific notation (exponential format) is used for the coordinates so that values never go off-scale.
Six significant digits are used in order to give 10 m resolution on the Earth.
(There would be no point in attempting higher precision, because my programs treat planets as spheres and ignore their rotational ellipticity.)

If (longitude, latitude) format is used, note these conventions:
All values are in degrees (and decimal fractions of degrees).
North latitude (measured from the equator) is positive, and South latitude is negative.
East longitude (measured from the Greenwich meridian) is positive.
West longitudes are usually negative, but they can also be given as positive East longitudes in the range 180~360.

After struggling with the general problem of how to distinguish a text label from a pair of numbers (and do it identically in 3 programming languages), I hit upon a simple, though inefficient rule:
Text labels must start with a non-whitespace character in column 1.
Number pairs must begin in column 2 with a leading sign (+ or -).
If you depart from these rules, some of my programs may be able to interpret your .dig file, but others may fail.

If you use Fortran, it is easy to write the number pairs with:
FORMAT (1X, SP, 1P, E12.5, ',', E12.5) in Fortran 77, or
FORMAT (1X, SP, ES12.5, ',', ES12.5) in Fortran 90+.

The following box displays the first 25 lines of a typical .dig file.
(This one consists of digitized fault traces in degree units.)
Note the required "***" end-marker, which must occur in the first 3 bytes of the line.
(The explanatory message following the "***" bytes on the same line can be whatever you like.)
Lines 1 and 22 are text labels to identify the polylines that follow them. Such labels are optional.

F1302R
 -1.05289E+02,+3.46860E+01
 -1.05298E+02,+3.47768E+01
 -1.05288E+02,+3.48878E+01
 -1.05286E+02,+3.50316E+01
 -1.05286E+02,+3.51756E+01
 -1.05281E+02,+3.52886E+01
 -1.05275E+02,+3.53434E+01
 -1.05286E+02,+3.54419E+01
 -1.05260E+02,+3.55517E+01
 -1.05270E+02,+3.55918E+01
 -1.05289E+02,+3.56336E+01
 -1.05267E+02,+3.56759E+01
 -1.05245E+02,+3.57181E+01
 -1.05237E+02,+3.57895E+01
 -1.05261E+02,+3.58552E+01
 -1.05235E+02,+3.59543E+01
 -1.05206E+02,+3.60516E+01
 -1.05191E+02,+3.60975E+01
 -1.05201E+02,+3.61451E+01
*** end of polyline ***
F0917R
 -1.06924E+02,+3.42904E+01
 -1.06891E+02,+3.43457E+01
 -1.06822E+02,+3.44201E+01
  [...listing truncated....]