This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages)
|
Filename extensions | .adf |
---|---|
Developed by | Esri |
Type of format | GIS |
The Esri TIN format is a popular yet proprietary geospatial vector data format for geographic information system (GIS) software for storing elevation data as a triangulated irregular network. It is developed and regulated by Esri, US. The Esri TIN format can spatially describe elevation information including breaking edge features. Each points and triangle can carry a tag information. [1] [2] A TIN stored in this file format can have any shape, cover multiple regions (e.g. islands) and contain holes (e.g. lakes). [3]
In 2007 a reverse-engineered description of Esri TIN format came to light. [4] Since then, the Virtual Terrain Project, an open-source software, has implemented support for reading the format, without the need of ArcGIS being installed. [5]
The Esri TIN format is a digital vector storage format for storing elevation information including breaking edge features. The Esri TIN format was introduced with ArcView GIS.
The Esri TIN format consists of a collection of files with specific filenames and a common filename extension, stored in the same directory. Most of the files are mandatory files (tdenv.adf, tedg.adf, thul.adf, tmsk.adf, tmsx.adf, tnod.adf, [5] tnxy.adf [5] and tnz.adf [5] ), optionally a file containing the coordinate system and projection information (prj.adf) and files containing point tag information (tnval.adf and tndsc.adf) and triangle tag information (ttval.adf and ttdsc.adf) [1] [2] can be given.
The endianness of most of the files is big-endian. tmsk.adf, tmsx.adf and tdenv.adf have mixed endianness.
The endianness of the file tndsc.adf and tnval.adf is little-endian.
A TIN with n points (incl. superpoints) and k triangles, the file sizes calculate to:
Contains and array of X and Y coordinate values, one pair for each point of the TIN. The data set for each point can be described by the following structure:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–7 | double | big | X coordinate value |
8–15 | double | big | Y coordinate value |
Contains an array of Z coordinate values, one for each point of the TIN. The values are in same order as the values in tnxy.adf and together store the 3 dimensional coordinate of each point of the TIN. The data set for each point can be described by the following structure:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | float | big | Z coordinate value |
Contains an array of indices to the points that form the triangles of the TIN, 3 indices for each triangle. The indices are in the range of 1 to the number of points ([1, # of points]). The front face of a triangle (usually the upper side) is that face, that has the 3 points/corners ordered clockwise when viewed. The data set for each triangle can be described by the following structure:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Index of the first point of a triangle |
4–7 | int32 | big | Index of the second point of a triangle |
8–11 | int32 | big | Index of the third point of a triangle |
Contains information about the topology of the triangles and the type of their edges.
There is an entry for each triangle with each 3 indices, that point to the position (number of the index) in tnod.adf file to identify the triangle, that shares an edge with the triangle described by the current data set, and the point of that triangle, that form that edge.
For each triangle in tnod.adf exists a data set at the same file location in tedg.adf. Each of the values point to the location in tnod.adf, where the point is specified (the index of that point) that form an edge. At the same time, since the location in tnod.adf and tedg.adf correspond, each of the values point to the location in tedg.adf, where the location of the value is specified. Rule: If edge a of triangle A points to edge b of triangle B, then edge b of triangle B must point to edge a of triangle A. Since edge definition in tedg.adf and point definition in tnod.adf of each triangle are at the same location the files, the indices in tedg.adf point to the point definition in tnod.adf of the neighbouring triangles.
The indices encode the actual index and type of the edge. The actual indices are not file offsets in bytes, but rather in int32 values, in the range of 1 to the number of points ([1, # of points]). If the value is negative (bit 31 is set) the edge is a breaking edge. Furthermore, bit 30 of the int32 values is used to determine if the edge is a hard or soft breaking edge. If the actual index would be 1234 (0x000004D2) then a hard breaking edge would be encoded as -1234 (0xFFFFFB2E) and a soft breaking edge as -1073743058 (0xBFFFB2E). The edge definition of the neighbouring triangle must mirror the edge type. ATTENTION: This behaviour has changed since ArcGIS 10. Please compare with the information given in section 'Format changes and files new with ArcGIS 10'.
The data set for each triangle can be described by the following structure:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Encoded index of point definition (index of a point) of the neighbouring triangle in tnod.adf that form an edge with the first point of the triangle |
4–7 | int32 | big | Encoded index of point definition (index of a point) of the neighbouring triangle in tnod.adf that form an edge with the second point of the triangle |
8–11 | int32 | big | Encoded index of point definition (index of a point) of the neighbouring triangle in tnod.adf that form an edge with the third point the a triangle |
This file contains information that could be seen as a mix of file header and statistic data.
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Number of points (regular points and superpoints) |
4–7 | int32 | big | Number of triangles |
8–11 | int32 | big | Number of indices and separators in thul.adf |
12–15 | int32 | big | 0 (in version 9) / number of breaking edge entries in teval.adf (version 10) |
16–19 | int32 | big | Number of triangles, not masked in tmsk.adf |
20–23 | int32 | big | Number of regular points |
24–27 | int32 | big | Number of superpoints |
28–31 | float | big | Minimum height (Z value of the lowest point; zmin) |
32–35 | float | big | Maximum height (Z value of the highest point; zmax) |
36–39 | int32 ? | big | Unknown, different values encountered |
40–47 | double | big | Minimum extent in X direction (xmin) |
48–55 | double | big | Minimum extent in Y direction (ymin) |
56–63 | double | big | Maximum extent in X direction (xmax) |
64–71 | double | big | Maximum extent in Y direction (ymax) |
72–79 | double ? | big | Unknown, always 0 |
80–87 | double ? | big | Unknown, different values encountered |
88–91 | int32 | big | Unknown, always 70001 (version 9) / 90001 (version 10); maybe a version number |
92–95 | int32 | little | Number of used tags (incl. tag 0 for superpoints) |
96–99 | int32 ? | big | Unknown, always 0; maybe unused |
100–103 | int32 ? | big | Unknown, always 0; maybe unused |
Contains an array of indices and separators, that defines the outer boundary of the TIN and its holes. The indices are in the range of 1 to the number of points ([1, # of points]). The separators are -1 (0xFFFFFFFF) and zero (0).
If the TIN is constructed using superpoints (usually the first 4 points), thul.adf lists the indices of these points and then -1 (0xFFFFFFFF). After the separator follows one or more lists of indices that form bounding polygons (outer boundaries) and maybe holes (inner boundaries). These lists are separated by zero (0) values.
If the TIN does not contain superpoints, thul.adf starts with the -1 (0xFFFFFFFF) separator, which is followed by one or more lists of indices that form bounding polygons (outer boundaries) and maybe holes (inner boundaries). These lists are separated by zero (0) values.
The indices and separators are 4 byte integer values (int32), stored in big-endian byte order.
Contains an array of bits (stored in 4 byte integers) that specify the visibility of the triangles of the TIN. This can be used to hide the triangles inside of terrain holes or outside the terrain (outside the outer boundaries).
The file is stored using the same structures (header and records) as a shapefile, but since it only stores the visibility values of the triangles many fields of the header are used.
The file header is fixed at 100 bytes in length and contains 17 fields; nine 4-byte (32-bit signed integer or int32) integer fields followed by eight 8-byte (double) signed floating point fields:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | File code (always hex value 0x0000270a) |
4–23 | int32 | big | Unused; five uint32 |
24–27 | int32 | big | File length (in 16-bit words, including the header) |
28–31 | int32 | little | Version 0 ; probably unused |
32–35 | int32 | little | Shape type 0 ; probably unused |
36–43 | double | little | Minimum X extent (always 0.0) ; unused |
44–51 | double | little | Minimum Y extent (always 0.0) ; unused |
52–59 | double | little | Maximum X extent (always 0.0) ; unused |
60–67 | double | little | Maximum Y extent (always 0.0) ; unused |
68–75 | double | little | Minimum Z extent (always 0.0) ; unused |
76–83 | double | little | Maximum Z extent (always 0.0) ; unused |
84–91 | double | little | Minimum M extent (always 0.0) ; unused |
92–99 | double | little | Maximum M extent (always 0.0) ; unused |
The file then contains at least 2 records. Each record is prefixed with a record-header of 8 bytes:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Record number (1-based) |
4–7 | int32 | big | Record length (in 16-bit words) |
Following the record header is the actual data.
Record 1: The data of record number 1 is 2 word long and contains only the size of the data of record number 2 in 4 byte integers, stored as 4 byte integer (big-endian) itself.
Record 2: The data of record number 2 contain the following variable length structure:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Number of integer in the mask array |
4–7 | int32 | big | Unused; always 0; maybe an offset (bits, bytes or integers?) into the mask array, where the actual mask bits start |
8–11 | int32 | big | Number of used bits in the mask array |
12– | uint32[] | big | Mask array |
Bit 0 (least significant bit) of the first integer contains the visibility flag (invisible if set to 1) of the first triangle defined in tnod.adf. Bit 1 of the first integer contains the visibility flag (invisible if set to 1) of the second triangle, and so on. All 32 bits of the integers get used (no sign bit).
Record 0: Records with the record number 0 must be ignored.
The index file contains the same 100-byte header as the tmsk.adf file, followed by any number of 8-byte fixed-length records which consist of the following two fields:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Record offset (in 16-bit words) |
4–7 | int32 | big | Record length (in 16-bit words) |
Using this index, it is possible to seek backwards in the tmsk.adf file by, first, seeking backwards in the index (which is possible because it uses fixed-length records), then reading the record offset, and using that offset to seek to the correct position in the tmsk.adf file. It is also possible to seek forwards an arbitrary number of records using the same method.
Depending on the information stored in the TIN, some extra files are needed.
Contains the coordinate system and projection information. The file can be either in the Esri flavour of the well-known text representation of coordinate reference systems format (WKT), a simple keyword-value notation (Keyword: Projection, Datum, Spheroid, Units, Zunits, Xshift, Yshift, Zone,...) or have a single line {B286C06B-0879-11D2-AACA-00C04FA33C20}, which signifies an unknown coordinate system.
Contains an array of 24 byte big data set, one for each used tag. The data set contains the tag and the number of points with that tag. Each data set is structured as follows:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | little | Number of the entry; starting with 1 |
4–7 | int32 | little | Tag value |
8–11 | int32 | little | Unused; always 0; maybe reserved for extending tag values to 64 bit |
12–15 | int32 | little | Number of points with the tag |
16–19 | int32 ? | little | Unused; always 0 |
20–23 | int32 ? | little | Unknown; always 0 in ArcGIS 9, different values in ArcGIS 10 |
Contains are array of 4 byte integer value, one for each (tagged) point of the TIN. The values are stored in little-endian byte order. Superpoints have the value 0 (zero). Points without a tag (e.g. points added by breaking edges) must be stored last in the TIN, and don't have an entry in this file.
Since ArcGIS 10 there were some changes in the TIN file format. 2 new files (teval.dbf and tnodinfo.dbf) and 1 file got remained.
The file structure remains the same, just the field containing the number of breaking edges is additionally used.
Contains an array of 2 byte integer values. One short for each point. The purpose is still not publicly known. So far it seems to be some kind of bitmask or code, describing the usage of the point. The values seem to be stored in big-endian byte order.
Value | Hexadecimal value | Usage |
---|---|---|
2 | 0x0002 | Superpoint |
4 | 0x0004 | Regular point |
24 | 0x0018 | ? |
88 | 0x0058 | ? |
132 | 0x0084 | ? |
280 | 0x0118 | ? |
284 | 0x011C | ? |
376 | 0x0178 | ? |
516 | 0x0204 | ? |
772 | 0x0304 | ? |
796 | 0x031C | ? |
Contains an array of data sets defining the breaking edges of the TIN, two for each breaking edge (one for each direction). Each data set is 16 byte long and structured as follows:
Bytes | Type | Endianness | Usage |
---|---|---|---|
0–3 | int32 | big | Index of point definition (index of a point) and edge definition (index of the edge) of the neighbouring triangle in tnod.adf or tedg.adf that form a breaking edge |
4–7 | int32 | big | Index of point definition (index of a point) and edge definition (index of the edge) of the current triangle in tnod.adf or tedg.adf that form a breaking edge |
8–11 | int32 | big | Type of the breaking edge (4 for hard edges, 2 for soft edges) |
12–15 | int32 | big | Unused; always 0 |
Since ArcGIS 10 this file has changed a little. It still contains a dataset for each triangle, and the references/indices of regular edges are unchanged, but the encoding of breaking edges is different. Breaking edges are still marked using negative values, but the index don't point to the file position in tnod.dbf and tedg.dbf anymore, instead the absolute of the value is the number of the entry of the breaking edge in teval.dbf. The encoding of soft edges has moved to teval.dbf, too.
In this article the term 'superpoint' is used at several locations. In the absence of an official file format description this term was chosen to reflect the properties of these points. (They could also have been called 'metapoint', 'extrapoint', 'infinity point' and many more.) An superpoint in the context of the Esri TIN file format is an additional point added by the ArcGIS software during triangulation/generation of the TIN. ArcGIS usually adds 4 of these points, one each west, north, east and south of the regular TIN points, at an extremely high distances. The superpoints are usually the first points in the point files tnxy.adf and tnz.adf. The triangles that are built with these points are usually masked (made invisible) in the tmsk.adf file.
In computing, endianness is the order or sequence of bytes of a word of digital data in computer memory. Endianness is primarily expressed as big-endian (BE) or little-endian (LE). A big-endian system stores the most significant byte of a word at the smallest memory address and the least significant byte at the largest. A little-endian system, in contrast, stores the least-significant byte at the smallest address. Bi-endianness is a feature supported by numerous computer architectures that feature switchable endianness in data fetches and stores or for instruction fetches. Other orderings are generically called middle-endian or mixed-endian.
The Resource Interchange File Format (RIFF) is a generic file container format for storing data in tagged chunks. It is primarily used to store multimedia such as sound and video, though it may also be used to store any arbitrary data.
The BMP file format or bitmap, is a raster graphics image file format used to store bitmap digital images, independently of the display device, especially on Microsoft Windows and OS/2 operating systems.
The Lempel–Ziv–Markov chain algorithm (LZMA) is an algorithm used to perform lossless data compression. It has been under development since either 1996 or 1998 by Igor Pavlov and was first used in the 7z format of the 7-Zip archiver. This algorithm uses a dictionary compression scheme somewhat similar to the LZ77 algorithm published by Abraham Lempel and Jacob Ziv in 1977 and features a high compression ratio and a variable compression-dictionary size, while still maintaining decompression speed similar to other commonly used compression algorithms.
A GIS file format is a standard for encoding geographical information into a computer file, as a specialized type of file format for use in geographic information systems (GIS) and other geospatial applications. Since the 1970s, dozens of formats have been created based on various data models for various purposes. They have been created by government mapping agencies, GIS software vendors, standards bodies such as the Open Geospatial Consortium, informal user communities, and even individual developers.
The archiver, also known simply as ar, is a Unix utility that maintains groups of files as a single archive file. Today, ar
is generally used only to create and update static library files that the link editor or linker uses and for generating .deb packages for the Debian family; it can be used to create archives for any purpose, but has been largely replaced by tar
for purposes other than static libraries. An implementation of ar
is included as one of the GNU Binutils.
A Java class file is a file containing Java bytecode that can be executed on the Java Virtual Machine (JVM). A Java class file is usually produced by a Java compiler from Java programming language source files containing Java classes. If a source file has more than one class, each class is compiled into a separate class file.
A FourCC is a sequence of four bytes used to uniquely identify data formats. It originated from the OSType or ResType metadata system used in classic Mac OS and was adopted for the Amiga/Electronic Arts Interchange File Format and derivatives. The idea was later reused to identify compressed data types in QuickTime and DirectShow.
TeX font metric (TFM) is a font file format used by the TeX typesetting system. It is a font metric format, not an outline font format like TrueType, because it provides only the information necessary to typeset the font such as each character's width, height and depth. The actual glyphs are stored elsewhere. This is not unique to TeX; Adobe's AFM files and Windows' PFM files use the same technique.
STL is a file format native to the stereolithography CAD software created by 3D Systems. STL has several backronyms such as "Standard Triangle Language" and "Standard TessellationLanguage". This file format is supported by many other software packages; it is widely used for rapid prototyping, 3D printing and computer-aided manufacturing. STL files describe only the surface geometry of a three-dimensional object without any representation of color, texture or other common CAD model attributes. The STL format specifies both ASCII and binary representations. Binary files are more common, since they are more compact.
The shapefile format is a geospatial vector data format for geographic information system (GIS) software. It is developed and regulated by Esri as a mostly open specification for data interoperability among Esri and other GIS software products. The shapefile format can spatially describe vector features: points, lines, and polygons, representing, for example, water wells, rivers, and lakes. Each item usually has attributes that describe it, such as name or temperature.
In computer graphics, a triangulated irregular network (TIN) is a representation of a continuous surface consisting entirely of triangular facets, used mainly as Discrete Global Grid in primary elevation modeling.
Well-known text (WKT) is a text markup language for representing vector geometry objects. A binary equivalent, known as well-known binary (WKB), is used to transfer and store the same information in a more compact form convenient for computer processing but that is not human-readable. The formats were originally defined by the Open Geospatial Consortium (OGC) and described in their Simple Feature Access. The current standard definition is in the ISO/IEC 13249-3:2016 standard.
PLY is a computer file format known as the Polygon File Format or the Stanford Triangle Format. It was principally designed to store three-dimensional data from 3D scanners. The data storage format supports a relatively simple description of a single object as a list of nominally flat polygons. A variety of properties can be stored, including color and transparency, surface normals, texture coordinates and data confidence values. The format permits one to have different properties for the front and back of a polygon. There are two versions of the file format, one in ASCII, the other in binary.
An NRG file is a proprietary optical disc image file format originally created by Nero AG for the Nero Burning ROM utility. It is used to store disc images. Other than Nero Burning ROM, however, a variety of software titles can use these image files. For example, Alcohol 120%, or Daemon Tools can mount NRG files onto virtual drives for reading.
An Esri grid is a raster GIS file format developed by Esri, which has two formats:
ArcMap is the main component of Esri's ArcGIS suite of geospatial processing programs, and is used primarily to view, edit, create, and analyze geospatial data. ArcMap allows the user to explore data within a data set, symbolize features accordingly, and create maps. This is done through two distinct sections of the program, the table of contents and the data frame. In October 2020, it was announced that there are no plans to release 10.9 in 2021, and that ArcMap would no longer be supported after March 1, 2026. Esri are encouraging their users to transition to ArcGIS Pro.
A variable-length quantity (VLQ) is a universal code that uses an arbitrary number of binary octets to represent an arbitrarily large integer. A VLQ is essentially a base-128 representation of an unsigned integer with the addition of the eighth bit to mark continuation of bytes. VLQ is identical to LEB128 except in endianness. See the example below.
A georelational data model is a geographic data model that represents geographic features as an interrelated set of spatial and attribute data. The georelational model was the dominant form of vector file format during the 1980s and 1990s, including the Esri coverage and Shapefile.
Concise Binary Object Representation (CBOR) is a binary data serialization format loosely based on JSON authored by C. Bormann. Like JSON it allows the transmission of data objects that contain name–value pairs, but in a more concise manner. This increases processing and transfer speeds at the cost of human readability. It is defined in IETF RFC 8949.