The ADF file format consists of two parts: The components of the container file and the details of each component. The ADF file is a zip file that contains multiple other compressed and uncompressed files. These files when taken together provide all of the data necessary to recreate the project data in a program that may wish to display CAD information, or model a construction project or allow for the creation and editing of the construction project data.

The container (zip file) consists of the following possible components:

Generally each block will exist as a single zipentry inside of a zipfile structure. This note describes the format of each block and it's relationship within the zip hierarchy. Heavy use of the zip path structure is used to place data blocks within the proper data structure scope to be interpreted by the application program.

The abstract hierarchy of an ADF file is as follows:

  - CM
      - Block Header
      - Surfaces
         - Block Header
         - surface point array
         - surface line array
         - surface point label array
         - surface line label array
         - surface point time/quality array
         - AgIslands
            - Block Header
            - Mesh
               - Block Header
               - FreePts (index array)
               - LineSet (index array)
               - Triangle point array
               - Triangles (index array)
            - Regions
               - Block Header
         - Annotation
            - Block Header
            - Annotation point array
            - Annotation line array (implied LineSet of all lines)
            - FreePts (index array)
      - Isopach
         < Same as Surface only block header has Surface names used for isopach,
          first name is reference surface>
      - Images
         - Block Header
         - Image

• Security
• Survey blocks

Each file will contain at least 1 ConstructionModel, possibly more than one. Each ConstructionModel will be named in with an arbitrary name. It is likely that the name of the ConstructionModel will match the original ESW name, but there is no requirement that this is the case. This name is then used to associate the other data (points, lines, etc). This allows the reading program to only read what is actually needed. Within each ConstructionModel there are a number objects, commonly known as layers but known as Surfaces. Each Surface will have it's own set of points and lines.

The hierarchical containment of object is encoded as the hierarchy of the elements within the zipfile. This allows certain programs to add or remove elements of the ConstructionModel in a trivial manner.

For example, assume an ADF file with a construction model named “Airway”, has a Surface called “Design” and an Isopach structure. The file structure may look like:

Info.txt                                      // An unnumbered file entry
Setting.bin                                   // A 1001 block
Benchmarks.bin                                // A 1002 block
Recover.bin                                   // A 1015 block
CL.aln                                        // A 1023 block
Layers.json                                   // An unnumbered file entry
Airway.cm                                     // A 1014 block
Airway/Design.surf                            // A 1012 block
Airway/Design/points.pts                      // A 1003 block
Airway/Design/lines.lnia                      // A 1005 block
Airway/Design/points.tim                      // A 1021 block
Airway/Design/points.ptlbl                    // A 1017 block
Airway/Design/lines.lnlbl                     // A 1018 block
Airway/Design/Island1.isl                     // A 1010 block
Airway/Design/Island1/mesh.msh                // A 1008 block
Airway/Design/Island1/mesh.pia                // A 1004 block
Airway/Design/Island1/mesh.lnset              // A 1006 block
Airway/Design/Island1/trimesh.pts             // A 1003 block
Airway/Design/Island1/trimesh.tri             // A 1007 block
Airway/Design/Island1/Regions.rgn             // A 1009 block
Airway/Design/Islandn.isl                      
Airway/Design/Islandn/mesh.msh                      
Airway/Design/Islandn/mesh.pia
Airway/Design/Islandn/mesh.lnset
Airway/Design/Islandn/trimesh.pts
Airway/Design/Islandn/trimesh.tri
Airway/Design/Islandn/Regions.rgn
Airway/Design/Anno.ann                        // A 1013 block
Airway/Design/Anno/points.pts                 // A 1003 block
Airway/Design/Anno/freepoints.pia             // A 1004 block
Airway/Design/Anno/Lines.lnia                 // A 1006 block
Airway/Design/Layers.json                     // An unnumbered file entry

<repeated for each surface name>

Airway/Isopach1.iso                           // A 1016 block
Airway/Isopach1/points.pts                    // A 1003 block
Airway/Isopach1/lines.lnia                    // A 1005 block
Airway/Isopach1/Island1.isl                   // A 1010 block
Airway/Isopach1/Island1/Regions.rgn           // A 1009 block
Airway/Isopach1/Island1/triprism.pts          // A 1003 block
Airway/Isopach1/Island1/triprism.tpri         // A 1019 block
.
.
. <same as surface>

<repeated for each isopach>

Airway/Image1.agi                         // A 1011 block
Airway/Images/foo.jpg
Airway/Image2.agi                         // A 1011 block
Airway/Images/bar.pdf
Airway/ImageN.agi                         // A 1011 block
Airway/Images/foo2.png

<repeated for each image>

Airway/Survey1.surf                            // A 1012 block
Airway/Survey1/points.pts                      // A 1003 block
Airway/Survey1/lines.lnia                      // A 1005 block
Airway/Survey1/points.tim                      // A 1021 block
Airway/Survey1/points.ptlbl                    // A 1017 block
Airway/Survey1/lines.lnlbl                     // A 1018 block
Airway/Survey1/Island1.isl                     // A 1010 block - FIXED data
Airway/Survey1/Island1/mesh.msh                // A 1008 block
Airway/Survey1/Island1/mesh.pia                // A 1004 block
Airway/Survey1/Island1/mesh.lnset              // A 1006 block
Airway/Survey1/Island2.isl                     // A 1010 block - FLOAT data               
Airway/Survey1/Island2/mesh.msh                // A 1008 block                   
Airway/Survey1/Island2/mesh.pia                // A 1004 block
Airway/Survey1/Island2/mesh.lnset              // A 1006 block
Airway/Survey1/Island3.isl                     // A 1010 block - Autonomous data               
Airway/Survey1/Island3/mesh.msh                // A 1008 block                   
Airway/Survey1/Island3/mesh.pia                // A 1004 block
Airway/Survey1/Island3/mesh.lnset              // A 1006 block
Airway/Survey1/Island4.isl                     // A 1010 block - DGPS data               
Airway/Survey1/Island4/mesh.msh                // A 1008 block                   
Airway/Survey1/Island4/mesh.pia                // A 1004 block
Airway/Survey1/Island4/mesh.lnset              // A 1006 block
.
<repeated for each survey>

Airway/Pipes.pip                             // A 1025 block
Airway/Pipes/points.pts                      // A 1003 block
Airway/Pipes/freepoints.pia                  // A 1004 block
Airway/Pipes/lines.lnia                      // A 1005 block
Airway/Pipes/points.ptlbl                    // A 1017 block
Airway/Pipes/lines.lnlbl                     // A 1018 block

Airway/StakeList.stk                         // A 1024 block
Airway/StakeList/points.pts                  // A 1003 block
Airway/StakeList/points.ptlbl                // A 1017 block
Airway/StakeList/stakelist.dir               // A 1003 block (not actual point location but direction vector)

It's worth noting that Annotation Surfaces also have their own pts/pia/lnia objects and must obey the same data scheme as other Surface elements. You should also observe that an Isopach is a Surface (with the substitution of a 1016 block for 1012 Surface block), and the Isopach 1016 block has the Surface names used to generate the Isopach. (see 1016 for more information). The Survey is a surface with only point and line data. It is not compiled into a surface. Each Survey should have 4 islands each representing a Data quality level. It is possible that most of the Survey islands will be empty.

Some applications (noteably the SmartSuite applications on Android have some requirements):

• SmartDirt Limitation - An ADF file must contain either; 2 benchmarks with Lat/Long info in order to display user positions.

TO BE DEVELOPED: 2011-10-17 To avoid exposing critical IP of the ADF structure, we anticipate being able to encrypt the ADF using some secret key encryption (Blowfish) so the ADF file is not trivally reverse engineered. The actual mechanism for this will be done after the implementation of the ADF version 4 with enough capability to sufficiently support SmartDirt.

The following generic data rules apply across all data blocks and data types unless otherwise noted:

• All length values must be zero or greater. An ADF file is considered malformed if a length is negative. Applications may generate fatal read errors.
• All strings are stored as UTF-8. Reading program must not assume that string values are simple ASCII, although a major of labels may be the lower characters of the UTF-8 space. All string lengths are lengths of BYTEs in the string, NOT characters.

Each binary file contains blocks of data. Each block of data consists of an integer identifier and the block size. The identifier tells you what is in the block and knowing the block size lets you skip the block if you want to. The block identifiers are the following:

The identifiers and block sizes are assumed for all binary files, so further explanations will omit these tags.

The settings file contains information like the units 0 = feet, 1 = meters;

The benchmark file contains a block of data for each benchmark. Each benchmark is comprised of NEZ data, optionally LLA data, and a label. It is possible for a Benchmark to NOT have LLA, or a label. It is recommend all ADF files should have at least two benchmarks with LLA data, if possible.

The alignment files contain data that can be used to create a complex 2D alignment in plan view or profile view. These lines do not belong to any surface but can reasonably be imported or exported with benchmark data.

The Points file should consist of a point count and then each point NEZ and a possible label (character count and then characters with ending character). Zip files will probably contain a 3DPoints.pts file as well as possibly having dnmesh and/or ogmesh pts files if the file was written with triangles for a island.

The Directions file should consist of a VertexBearing count and then each Bearing EN (Z always 0.0) where X and Y represent the X and Y values for a direction towards a reference point..

The PIA block will contain an pts array index, the number of points and then the series of point indices in the array.

The LNIA block varies from the PIA block by possibly having a label at the end of the block for the line's label.

Images can be read here.

The CM file contains a number of other data blocks. First are Lineset blocks and Triangle blocks which are used by Mesh blocks. Then Lineset blocks that are used by Region blocks. Then Lineset blocks that are used by Annotation blocks. Then Island blocks which use the Mesh, Regions and Annotation blocks immediately preceding it. The read assumes one is reading into an array of types and indices into the arrays are found in the blocks. This is followed by an existing surface Surface block consisting of a PIA block for any images that may have been read earlier as well as a PIA block. Next is a design surface Surface block (including preceding Island blocks). Finally is a Construction Model block consisting of PIA blocks for surfaces, annotations, the indices for the PTS array, and Lineset array.

Under the CM is a stakelist which consists of a points file, a label file, and a directions file for the points in the stakelist. The directions file is the same format and BlockID number as the points file but the values are X, Y and Z(0.0 always) where X and Y represent the X and Y values for a direction towards a reference point.

The info block contains identification information and version informaton for the ADF file. It also may contain application specific information or user specific information. An example info block is:

agtek.filetype=adf
agtek.vendor=AGTEK Development Corporation
agtek.adf.version=4
agtek.sourcefile=Example.esw

This data is formatted as a properties file (key=value). In Java these are read as Properties files, in C++ there exist library code (currently in ACCESS Lib to read and write this information). Key names (e.g. com.example.prop_name) are based around the accepted “reverse dns” structure. This allows new properties to be added with minimal collisions between companies (should this format ever be opened up to third parties). The following rules of naming for keys and values exist:

• Any key name beginning with “agtek” is a name defined by the ADF standard. Applications may use predefined ADF properties, but may not invent new ones.
• Any key name beginning with “com.agtek” is a name defined within the Agtek company and no other company may use them.
  • Agtek may parcel out the namespace for different applications or technologies. For example:
  • com.agtek.smartsuite.
  • com.agtek.Earthworks4D.
• Organizations external to Agtek must use their reverse DNS to prefix their properties.
• Any program reading these values must understand and respect all “agtek.*” properties, program may ignore any other properties that are not recognized.
• Any program writing changes to the Info.txt block must preserve all properties, even those which are not understood.
• It is recommended that any value containing “=” or newline characters be URL encoded for safety. All readers must URL decode all values.
• Unrecognized values are regarded as strings.

The following values are defined for this version of the ADF file type.

Settings.bin is a zipfile entry containing important settings about the ConstructionModels within this ADF. The zipentry is always named Settings.bin

Block Header:

• Block Code 1001 : Int32
• Block Size : Int32

Settings contain:

• isMetric - Bool32

A benchmark block is a zipfile entry which is a series of benchmarks. The entry is always named Benchmarks.bin. Each benchmark has the following complete set of data (including block header):

Block Header:

• Block Code 1002 : Int32
• Block Size : Int32

Benchmark data:

• X location - Double 64 (Easting)
• Y location - Double 64 (Northing)
• Z location - Double 64
• hasLLA - Bool32
• Optional
  • Lattitude - Double 64
  • Longitude - Double 64
  • Altitude - Double 64
• Label length (in characters, 0 or more) - Int32
• UTF-8 Label characters

The Recovery block is a zipfile entry, which refers to recovery data. The data will describe two benchmarks and the data necessary for an alignment. The entry is always named Recovery.bin. A Recovery block contains only two benchmarks, and each benchmark has the following data complete set of data (including block header):

Block Header:

• Block Code 1020 : Int32
• Block Size : Int32

Benchmark data:

BM0

• X location : Double 64 (Easting)
• Y location : Double 64 (Northing)
• Z location : Double 64
• Latitude location : Double 64 (radians)
• Longitude location : Double 64 (radians)
• Altitude location : Double 64 (meters)
• RX location : Double 64 (Cartesian delta from Base Station)
• RY location : Double 64 (Cartesian delta from Base Station)
• RZ location : Double 64 (Cartesian delta from Base Station)
• Label length (in characters, 0 or more) : Int32
• UTF-8 Label characters

BM1

• X location : Double 64 (Easting)
• Y location : Double 64 (Northing)
• Z location : Double 64
• Latitude location : Double 64 (radians)
• Longitude location : Double 64 (radians)
• Altitude location : Double 64 (meters)
• RX location : Double 64 (Cartesian delta from Base Station)
• RY location : Double 64 (Cartesian delta from Base Station)
• RZ location : Double 64 (Cartesian delta from Base Station)
• Label length (in characters, 0 or more) : Int32
• UTF-8 Label characters

General recovery information

• occupy point : Int32
• Instrument height : Double 64
• Rod height : Double 64
• Slope North : Double 64
• Slope East : Double 64
• State Plane Correction : Double 64
• Alignment file type : Int32
• Rotation Angle : Double 64 (radians)
• Centroid North : Double 64 (meters)
• Centroid East : Double 64 (meters)
• Centroid Field North (Lat) : Double 64 (meters)
• Centroid Field East (Lon) : Double 64 (meters)

Much of the general recovery data is legacy. Currently the only parameters used in the recovery are NEZ, LLA and StatePlaneCorrection. The rest are calculated or set to default values.

The Alignment block is a zipentry within the zipfile hierarchy, which refers to 2D Alignment data. This data is at the top level because it is not part of any surface and where it can be easily exported. Of note is that this data can represent either horizontal or vertical alignment data. Within the data is a flag indicating what type of data it is.

Block Header:

• Block Code 1023 : Int32
• Block Size : Int32

This block will consist of:

• Type : Int32 (0 = HAL, 1 = VAL)
• Number of characters : Int32
• 0-N characters, name of Alignment: UTF-8 character sequence

Segments

• Number of Segments in the alignment : Int32

The series of segments are as follows. All segments will contain the following initial values:

• Type of segment : Int32 (0 = tangent, 1 = arc, 2 = spiral, 3 = parabola)
• Visibility : Int32 (0 = off, 1 = on)
• Begin Pt (the exact meaning of the coordinate values depends on the segment type (Northing/easting, Station/Offset)
  • - x : Double64
  • - y : Double64
• End Pt
  • - x : Double64
  • - y : Double64

Specific segment types will contain:

Tangent

• no additional information

Arc

• Turn direction: Int32 (0 = left, 1 = right)
• Radius Pt
  • - x : Double64
  • - y : Double64

Spiral

• Turn direction: Int32 (0 = left, 1 = right)
• Spiral length : Double64
• Spiral radius at beginnning : Double64 (0.0 means infinite)
• Spiral Radius at end : Double64 (0.0 means infinite)
• Beginning Direction (Unit vector tangent to the curve at the beginning)
  • - x : Double64
  • - y : Double64
• Ending Direction (Unit vector tangent to the curve at the end)
  • - x : Double64
  • - y : Double64

Parabola

• PVI (Point of Vertical Intersection)
  • - x : Double64
  • - y : Double64

Station Equations

• Number of Station Equations : Int32

for each Station Equation:

• length : Double64 (Not sure this field is a good idea)
• Back Station : Double64
• Ahead Station : Double64

Offsets

• Number of offsets : Int32

for each Offset:

• length: Double64 (Again, Not sure this field is a good idea might need to be station)
• offset : Double64

The PTS point block is a zipfile entry, which is a series of vertex points to be referenced by other blocks which are part of a surface.

Block Header:

• Block Code 1003 : Int32
• Block Size : Int32
• Number of points : Int32

The series of points are as follows:

• X location - Double 64 (Easting)
• Y location - Double 64 (Northing)
• Z location - Double 64

The DIR directions block is a zipfile entry, which is a series of angles representing the direction to a reference point. This is used by a stakelist point.

Block Header:

• Block Code 1003 : Int32 …. NOTE that this is the same value as the PTS block ID
• Block Size : Int32
• Number of points : Int32

The series of points are as follows:

• X location - Double 64 (X)
• Y location - Double 64 (Y)
• Z location - Double 64 (Always zero, 0.0)

The PIA point block is a zipfile entry, which refers to a “.pts” block with the same name at the same level of surface hierarchy. The points referred to by this block are considered as “free points” in the Surface surface.

Block Header:

• Block Code 1004 : Int32
• Block Size : Int32
• Index of vertex array : Int32
• Number of points : Int32

The series of points are as follows:

• point index : Int32 (the index into the associated“.pts” list).

The LNIA point block is a zipfile entry, which refers to a “.pts” block with the same name at the same level of the hierarchy. An LNIA zipfile entry contains a series of LNIA blocks. Each block contains:

Block Header:

• Block Code 1005 : Int32
• Block Size : Int32
• Number of lines : Int32

Each line starts with

• Number of points : Int32

The series of points in the line are as follows:

• point index : Int32 (the index into the associated “.pts” list).

The point label block is a zipfile entry, which is the list of point labels. Each label is associated to a point in the pts block via an index. This zipfile entry is a single block that contains:

Block Header:

• Block Code 1017 : Int32
• Block Size : Int32
• Number of labels : Int32

The series of point labels are as follows:

• point index : Int32 (the index into the associated “.pts” list).
• Label length (in characters, 0 or more) : Int32
• UTF-8 Label characters

The line label block is a zipfile entry, which is the list of line labels. Each label is associated to a line in the LNIA block via an index. This zipfile entry is a single block that contains:

Block Header:

• Block Code 1018 : Int32
• Block Size : Int32
• Number of labels: Int32

The series of line labels are as follows:

• line index : Int32 (the index into the associated “.lnia” list).
• Label length (in characters, 0 or more) : Int32
• UTF-8 Label characters

The point time/quality block is a zipfile entry, which is the list of point time and quality values for each point that has this information. Each time/quality pair is associated to a point in the pts block via an index. This zipfile entry is a single block that contains:

Block Header:

• Block Code 1021 : Int32
• Block Size : Int32
• Number of time/quality pairs : Int32

The series of point labels are as follows:

• point index : Int32 (the index into the associated “.pts” list).
• Time value (UTC) : Int64
• Quality value : Int32 - Autonomous (1000), DGPS (1001), Float (1002), Fixed (1003), Unknown(1004)

The image block is a zipfile entry, which contains the positioning data for an image and the image name. This .AGI file will contain the corresponding name of the image that will reside within the zipfile. An image will be an entity of the Construction Model.

The page number starts at one(1). Page numbers are ignored for formats that don't support multiple pages or frames. The four coordinates are used to define the rotation, scale and translation of the image. The 4th is used as a convenience. The actual image will be found in the Images directory.

This zipfile entry is a single block that contains:

Block Header:

• Block Code 1011 : Int32
• Block Size : Int32
• Image name length: Int32 ( in characters )
• Image name: UTF-8 Label characters
• Page number: Int32 Starts at 1.
• TopLeft X: Double64
• TopLeft Y: Double64
• TopLeft Z: Double64
• TopRight X: Double64
• TopRight Y: Double64
• TopRight Z: Double64
• BottomRight X: Double64
• BottomRight Y: Double64
• BottomRight Z: Double64
• BottomLeft X: Double64
• BottomLeft Y: Double64
• BottomLeft Z: Double64

The image tile set is an optimization for mobile and small memory platforms. The original image is broken into smaller images (tiles) that can be handled (held in memory) by the mobile platform. TileSets are optional, but if an image is too large, an application may not be able to process and display an original image if it is too large.

A TileSet is composed of a TileSet block and one or more tile images. Each tile image is a proper subset of the original image in this Image section. Tiles are also required to be sized such that their sizes are exact powers of two (e.g. 2, 4, 8, 16, 32, 64, 128, etc). While any size is possible the practical size are in the range of 256 .. 1024 range for tiles (based on empirical testing on Android platforms).

While the input image may not have an exact power of two size for either X or Y, the process of producing the tiles should resample the image appropriately so the tiles do not overlap. There will M x N tiles depending on how big the tiles are and how they are resampled from the original. M & N must be at least 1, but there is no restriction on their values. (The condition N==M==1 is degenerate and should not exist, there is no point in doing so).

Android applications are coded to prefer TileSets over base images. Any application writing a new image must clear or regenerate TileSets.

A TileSet block looks like:

• Block Code 1022 : Int32
• Block Size : Int32
• Number of tiles : Int32

For each tile a set of:

• Tile-entry-name length: Int32 ( in characters )
• Tile-entry-name : UTF-8 string (e.g. tile1.jpg, tilea.png)
• TopLeft X : Double64
• TopLeft Y : Double64
• TopLeft Z : Double64
• TopRight X: Double64
• TopRight Y: Double64
• TopRight Z: Double64
• BottomRight X: Double64
• BottomRight Y: Double64
• BottomRight Z: Double64
• BottomLeft X: Double64
• BottomLeft Y: Double64
• BottomLeft Z: Double64

Example TileSet structure in memory looks like:

Airway/Images/img.jpg
Airway/Image1.agi              // A 1011 block
Airway/Image1/TileSet          // A 1022 block
Airway/Image1/tile1.jpg
Airway/Image1/tile2.jpg
Airway/Image1/tile3.jpg
Airway/Image1/tile4.jpg
Airway/Image1/tile5.jpg
Airway/Image1/tile6.jpg

The CM data file is a zipfile entry, which consists of a Island Block, a Surface Block, a Island Block, a Surface Block, and a Construction Model block. The Island Block will contain Mesh Blocks, Region Blocks, Annotation Blocks and the actual Island Block.

Block Header:

• Block Code 1014 : Int32
• Block Size : Int32

The data consists of:

• Number of characters : Int32
• 0-N characters, name of Reference surface: UTF-8 character sequence (Surface that survey shots may be compared to. Typically a Design type surface, but not always)

The Reference surface should match the name of a surface in the Construction Model. That Surface should be used as a reference when generating display information such as when a survey shot is taken and the UI needs to show something like “Cut 2.5 feet” to indicate that 2.5 feet of material needs to be removed at the survey spot in order to reach the desired elevation.

The data populating a Construction Model is discovered by listing all “.mdl” blocks which are immediate children of the CM. For example, the CM “Airway” has 3 sub surfaces name “Design”, “OG”, “Alternate”:

Airway/Design.mdl
Airway/Design/<components of Design surface>
Airway/OG.mdl
Airway/OG/<components of OG surface>
Airway/Alternate.mdl
Airway/Alternate/<components of Alternate surface>

The Annotation block is a zipfile entry contained within a Surface hierarchy. The entry is always named

Annotation.ann

Block Header:

• Block Code 1013 : Int32
• Block Size : Int32

An annotation set will be a Surface sub-hierarchy with the following sub-entries:

• .pts
• .pia
• .lnia

An example of an annotation collection is:

Airway/Design/Anno.ann                        // A 1013 block
Airway/Design/Anno/points.pts                 // A 1003 block
Airway/Design/Anno/freepoints.pia             // A 1004 block
Airway/Design/Anno/Lines.lnia                 // A 1006 block

The Surface block is a zip file entry contained in the the Construction Model hierarchy. The data describes the Surface type, and is provided with a sub-hierarchy of associated data.

The Surface zip entry is named

NAME.surf

Where “Name” is the name of the Surface and is often supplied by a human user. There is no restriction that the name match the Surface type, although it is considered bad practice (and darned confusing) to name an “Existing” type of surface something like “Design”, and vice versa.

The structure of the .surf block is as follows:

Block Header:

• Block Code 1012 : Int32
• Block Size : Int32

The data consists of:

• Surface type : Int32
  • Existing = 0
  • Design = 1
  • Isopach = 2
  • Survey = 3
  • Progress Topo = 4
  • Other = -1

In addition the time on the zip entry will be used by ProgressTopo surfaces to order the progress topo surfaces (assuming there are more than one).

A Surface will be a sub-hierarchy of data making up the surface. The Surface will always contain the following block/zipentries, which must be named as follows:

• points.pts
• lines.lnia

The Surface will also contain zero or more instances of Annotation and Image sub-hierarchies.

There will be zero or more island collections, in addition to the associate lines and points. An example of a Surface hierarchy follows (see other sections for descriptions of the sub-hierarchies):

Airway/Design.surf                            // A 1012 block
Airway/Design/points.pts                      // A 1003 block
Airway/Design/lines.lnia                      // A 1005 block
Airway/Design/Island1.isl                     // A 1010 block
Airway/Design/Island1/mesh.msh                // A 1008 block
Airway/Design/Island1/mesh.pia                // A 1004 block
Airway/Design/Island1/mesh.lnset              // A 1006 block
Airway/Design/Island1/trimesh.pts             // A 1003 block
Airway/Design/Island1/trimesh.tri             // A 1007 block
Airway/Design/Island1/Regions.rgn             // A 1009 block
Airway/Design/Islandn.isl                      
Airway/Design/Islandn/mesh.msh                      
Airway/Design/Islandn/mesh.pia
Airway/Design/Islandn/mesh.lnset
Airway/Design/Islandn/trimesh.pts
Airway/Design/Islandn/trimesh.tri
Airway/Design/Islandn/Regions.rgn
Airway/Design/Image1.img                // A 1011 block contains image name Image1.jpg
Airway/Design/Images/foo.jpg
Airway/Design/Image2.img                // A 1011 block contains image name Image2.pdf
Airway/Design/Images/bar.pdf
Airway/Design/ImageN.image                // A 1011 block contains image name ImageN.png
Airway/Design/Images/foo2.png
Airway/Design/Anno.ann                        // A 1013 block
Airway/Design/Anno/points.pts                 // A 1003 block
Airway/Design/Anno/freepoints.pia             // A 1004 block
Airway/Design/Anno/Lines.lnia                 // A 1006 block

The Isopach block is a zipfile entry contained in the the Construction Model hierarchy. The data describes the Isopach and is largely the same as a Surface with the names of the Surfaces used to originally construct the Isopach. It has it's sub-hierarchy of associated data. The mesh data contained within the Isopach must be interpreted differently than normal a Surface, as the elevations are actually deltas and not absolute elevations.

The Isopach zipentry is named

NAME.iso

Where “Name” is an arbitrary name such as Isopach1. A ConstructionModel may contain zero or more Isopach entries, although it is likely that only one instance of an Isopach is likely to occur within any single ConstructionModel.

The structure of the .iso block is as follows:

Block Header:

• Block Code 1016 : Int32
• Block Size : Int32

The data consists of:

• Surface type : Int32
  • Isopach = 2
• Number of characters : Int32
• 0-N characters, name of Reference surface: UTF-8 character sequence (Surface that survey shots may be compared to. Typically a Design type surface, but not always)
• Number of characters : Int32
• 0-N characters, name of Difference surface : UTF-8 character sequence (Surface that Reference is compared against in order to create Cut/Fill color map. Typically an Existing type surface.)

A Isopach will be a sub-hierarchy of data making up the Surface. The Surface will always contain the following block/zipentries, which must be named as follows:

• points.pts
• lines.lnia

The Surface will also contain zero or more instances of Annotation and Image sub-hierarchies.

There will be zero or more island collections, in addition to the associate lines and points. A surface of the Isopach contains the pre-computed elements of the isopach; the trimesh of the iso surface and triangular prisms for volumetric calculations.

An example of a Surface hierarchy follows (see other sections for descriptions of the sub-hierarchies):

Airway/Isopach1.iso                           // A 1016 block
Airway/Isopach1/points.pts                    // A 1003 block
Airway/Isopach1/lines.lnia                    // A 1005 block
Airway/Isopach1/Island1.isl                   // A 1010 block
Airway/Isopach1/Island1/
Airway/Isopach1/Island1/Regions.rgn           // A 1009 block
Airway/Isopach1/Island1/trimesh.pts           // A 1003 block
Airway/Isopach1/Island1/trimesh.tri           // A 1007 block
Airway/Isopach1/Island1/triprism.pts          // A 1003 block
Airway/Isopach1/Island1/triprism.tpri         // A 1019 block

The Island object is a zipfile entry and sub-hierarchy contained with the Surface hierarchy.

Block Header:

• Block Code 1010 : Int32
• Block Size : Int32

Each Island zipfile entry is named:

• *SN.isl**

The data consists of:

• Meshable : Int32 Flag used to indicate that the data within this island can be used to create a mesh. Zero indicates the data is not to be used in a mesh. Note that this flag may not exist for islands created by earlier versions of the software. If the block size is zero the flag is not there.

Where “SN” is an arbitrary island name. This name may or may not be shown to the user and is used to associate the island data to the island object.

Each island sub-hierarchy contains:

• mesh.msh
• mesh.pia
• mesh.lnset

These zipentries describe the island and refer to points (.pts) and lines (.lnia) in the Surface. Islands do not contain their own points.

An island may contain (0 or 1) instances of a TriMesh. If these are present it relieves the reading program from the burden of calculating a TriMesh. The TriMesh is composed of two additional zipentries:

• trimesh.pts
• trimesh.tri

The TriMesh contains it's own set of points because the TriMesh calculation creates new intermediate points, and to avoid creating “garbage” points in the Surface, these are not added to the Surface's point block. Reading programs may choose to share these points in memory to reduce footprints, but must take care to not write out TriMesh points in the Surfaces point block when writing and ADF.

An example of the island sub-hierarchy is:

Airway/Design/Island1.isl                          // A 1010 block
Airway/Design/Island1/mesh.msh                     // A 1008 block
Airway/Design/Island1/mesh.pia                     // A 1004 block
Airway/Design/Island1/mesh.lnset                   // A 1006 block
Airway/Design/Island1/trimesh.pts                  // A 1003 block
Airway/Design/Island1/trimesh.tri                  // A 1007 block
Airway/Design/Island1/Regions.rgn                  // A 1009 block

The Mesh block is a zipentry within the Island hierarchy, which indicates an island mesh. The data describes lines, and “free” points.

Block Header:

• Block Code 1008 : Int32
• Block Size : Int32

A mesh object is composed of the following zipentries within the island:

• mesh.msh
• mesh.pia
• mesh.lnset

These entries are always named as detailed here.

An example of a mesh structure is as follows

Airway/Design/Islandn/mesh.msh                      
Airway/Design/Islandn/mesh.pia
Airway/Design/Islandn/mesh.lnset

The Region block is a zipentry within the Island sub-hierarchy, which contains Region data. The data describes lines. The lineset will consist of one perimeter line and one or more holes. The index to the perimeter line (LNIA index) is given in the RGN block.

Block Header:

• Block Code 1009 : Int32
• Block Size : Int32

The Region block consists of

• Number of region lines : Int32

Each region line consists of

• Type of region : Int32
  • Perimeter = 0
  • Hole = 1
  • Adjustment = 2
  • Cut-Fill = 3
  • Balance = 4
• line index : Int32

This is all contained in the region block

The LineSet block is a zipentry, which refers to a collection (set) of lines. The data are indices into a line array (lnia) where each index represents a line. Which LNIA is referenced by this lineset is determined by the lineset's position within the zipfile hierarchy. See other entry descriptions for information.

Block Header:

• Block Code 1006 : Int32
• Block Size : Int32

Each LineSet will contain

• Number of lines in the set : Int32

The series of lines are as follows

• Index of the line : Int32

The Triangle block is a zipentry within the zipfile hierarchy, which refers to Triangle data. The data area indices into a Vertex (.pts) array where each index represents a point. The list will be a multiple of 3, thus creating triangles. (Closing of a triangle is assumed)

Block Header:

• Block Code 1007 : Int32
• Block Size : Int32

This block will consist of:

• Number of the Triangle points : Int32 (note: This value is number of triangles * 3)

The series of triangle points are as follows

• Index of the point : Int32

The Triangle prism block is a zipentry within the zipfile hierarchy, which refers to Triangle Prism data used within the Isopach. The data area indices into a Vertex (.pts) array where each index represents a point. The list will be a multiple of 3, thus creating triangles. (Closing of a triangle is assumed). Unlike normal triangle data, the elevations (Z) of the triangles are not absolute triangles. These values are delta elevations between the two surfaces used in the isopach calculations.

Block Header:

• Block Code 1019 : Int32
• Block Size : Int32

This block will consist of:

• Number of the Triangle points : Int32 (note: This value is number of triangles * 3)

The series of triangle points are as follows

• Index of the point : Int32

The Stakelist section is a simple section of files for points and point labels with an additional direction file if the Staking Rose for any point has a specific direction (or rotation). The STK file is as follows:

Block Header:

• Block Code 1024 : Int32
• Block Size : Int32
• Number of staking points : Int32

The Pipes section is essentially an annotation “surface” that contains information about pipes. This data does not describe a surface but takes advantage of the surface data structure. The PIP file is as follows:

Block Header:

• Block Code 1025 : Int32
• Block Size : Int32

The Layers file contains information on how certain layers of information should be displayed. An example of such a file follows:

{				
  "version": 1,			
  "layers": 			
    [ 		
      {	
        "name" : "data lines",
        "layertype": “DATALINES”,
        "visible" : false,
        "selectable" : true,
        “color: “0x445566FF”
      },	
      {	
        "name" :"perimeters",
        "layertype": “PERIMETERS”,
        "visible" : false,
      },	
      {	
        "name" : "annotation",
        "layertype": “ANNOTATION”,
        "visible" : false,
        “color: “0x0”
      },	
      {	
        "name" : "report regions",
        "layertype": “REPORTS”,
        "visible" : false,
        “color: “0x882211FF”
      }	
    ]		
}				

A Layers.json found at the root level of the ADF is for benchmarks and potential other, to be determined, “global” information. A Layers.json found within a surface folder is for the various layers that may be included with a surface, such as perimeters and report regions. A Layers.json found within a construction model folder (i.e. as a peer to the surface folders) is for extra layers such as cut/fill lines and stakelist points.

The information is presented in json format of key:value pairs.

The following values are defined for the layertype: