FORMAT IDEAS This document is part of discussion for developing a file interchange format for cave survey data. The motivation for developing YET ANOTHER format is that all the currently available formats have problems. There are three commonly used or proposed formats for exchaning cave survey data. They are RSD, SEF, and HTO. Let look at each format in detail. 1. RSD. RSD means Raw Survey Data. This interchange format was developed and used with early versions of SMAPS up to SMAPS version 4.X. It had several problems. First of all it did not support cave name or survey name designations other than in comments. On input, it required that each survey be placed into a separate file. It also had no organization or directory structure information. 2. SEF. SEF stands for SMAPS Exchange Format or Survey Exchange Format. It was used in SMAPS version 5.X. This was an attempt to improve the RSD format. Unfortunately, instead of simply extending the concept of RSD, SEF is a whole new language with lots of new constructs. SEF went overboard in the direction of trying to support every conceivable format. Data could appear in any order and numerical data could be represented in several formats. For example, numbers could be represented as fixed field values of various widths. They could also be represented as numerical strings with a special character as the delimiter. Unfortunately, each field on a line could have a different field width or a different delimiter. The only conceivable reason for supporting so many different number formats is to insure that SEF will read numbers generated by virtually any computer language. Unfortunately, this flexibility has very little practical benefit. In additions, there are other stumbling blocks. For example, null or missing data fields can be represented by spaces, so you cannot parse a line of data by simply reading a series of numbers. Also, there is no way to specify a cave name other than in a comment. Finally, the directory structure specified in an SEF file is very specific to SMAPS's internal directory structure and somewhat ambiguous. For example, SEF directories can represent part of a cave, a whole cave, several connected cave or several unconnected caves. In SMAPS the user controls the meaning of the of the directory structure by placing a highlight at the top of the tree. All these options and ambiguities make SEF difficult to reliably parse. It also makes it very difficult to be certain that a particular parser will properly translate all possible format combinations. Every one who has written an SEF translator has had to struggle with these ambiguities. 3. HTO. HTO stands for Hierarchical Tagged Objects. This was proposed as the next file interchange format for SMAPS. To date, it hasn't been implemented as a part of SMAPS. Some other programmers have implimented it or experimented with it, but SEF is more widely used. Again, it was an attempt to fix the problems of SEF. Unfortunately, instead of simply correcting the problems of SEF, HTO is a whole new language with totally new constructs. HTO does get rid of the complex number formats, but it adds a convoluted nested structure that requires call back routines or some kind of recursive descent parser to translate. It is also not particularly human readable. For example, the following line represents a single survey shot in HTO. (CT:(CTF:B22)(CTT:B23)(CTD:234)(CTFA:121.1)(CTFI:-8)) LESSION TO BE LEARNED Each of the formats described above has serious problems. As a result, we would like to begin work on a new standard that will solve some of the problems encountered with other format. In our discussions, we have identified several important goals. 1. SIMPLE. One of the biggest problems with the current survey exchange standards is that they try to anticipate every conceivable situation. As result, the standards are so complex that they defeat the purpose of creating a simple method of exchanging data. As an example of the problems that occur with an ambiguous format, look at SEF. I have personally tested seven different SEF translators and every one has a problem reading one or more of my test files. The fundamental problem with SEF is that it has so many options that is difficult to test all of the combinations. The basic structure of a survey exchange standard should be based on a simple, unambiguous format. No "call-back" routines or recursive descent compilers should be required parse the data. 2. SIMPLE NUMBER FORMAT. One of the places where survey formats go wrong is trying to support every conceivable number format. For example, SEF supports various combinations fixed field and character delimited numbers. This kind of flexibility would allow you to read numbers from a wide range of langauges and media, but in this day and age, it has no practical use. As a result, a file exchange format should use a simple, regular number format. The details don't matter, but only one number format should be used throughout the format. I can easily write one routine in just about any language that will read almost any number format. However, I don't want to have to write and test routines that will read six different number formats. I have a bias toward comma delimited number strings. They are easy to parse and they are widely used in data bases. 3. SIMPLE UNITS FORMAT. Another place where exchange format can wrong is to attempt to present the data every conceivable measurement units. There are literally dozens of units that cavers use to measure cave surveys. Parsing units like degrees and minutes or feet and inches adds another layer of complexity to the data transfer process. As a result, all data should be presented in a fixed set of units. All of these units can be reduced to simple common measures like meters, and degrees. A set of flags can be used to save the specifications for the original data format. As a long as enough digits of precision are saved, the original units can be easily restored once the data is transfered. 4. FIXED ITEM ORDER. One of the biggest problems with exchange formats is configurable data order. The rational for using configurable data order is that cave surveyors use a variety of formats when entering data in a survey book. However, processing files with a configurable item order add another layer of complexity to the tranlator. However, presenting the data in the original order is really the responsibility of a survey editor, not an exchange file format. Making the item order fixed makes the translator much easier to write. A set of flags can be used to save the original data order. 5. HUMAN READABLE. The exchange format should be written in simple ASCII text and should be human readable. Making it human readable makes it self documenting, makes it easier to debug problems and also makes it accessable to other programs like word processors, spread sheets, data bases etc. It also makes it possible for the files to be transmitted over the internet. 6. EASY TO PARSE - This goal is implied by some of the other goals listed above, but it is important to emphasize that the format should be easy to parse. One of the main purposes of a file interchange format is to be able to exchange data between ALL of the cave survey programs. If people cannot write a simple program to parse the data, then few people will adopt the standard. The fewer people that adopt the standard, the less useful it will be. 7. EXTENSIBLE. Because it is impossible to anticipate all the needs of a cave surveyors, the format should be extensible. The extensibility should be structured in such a way that extensions to the format do not result in chaos. For example, extension could be placed inside of "begin-end" pairs so that older translators can ignore new data items. THE PROCESS One of the problems with all of the earlier exchange file formats is the authors invited input rather late in the process. For example, the caving community was invited to make comments on the details SEF and HTO, after the basic structure of the format had already been established. This meant that the fundamental contructs and basic structure was not open to negotiation. If the whole concept and structure of SEF been open to discussion from the begining, SEF probably could have been simplified. This would have made it much more robust and useful. As a result, we want to open the process early before any constructs are set in stone. The items outlined above are basic guidelines and they are open to discussion and negotiation. One final point. Our goal with this project is rather limited. What we are trying to develop here is file exchange format, not the ultimate format for saving or handling survey data. As a result, the format does not have to cover every conceivable situation. What we are try to create is a robust, and practical data exchange format. ======================================================================== CURRENT WORKING FILE FORMAT In the process of forming this group, several specific ideas have been presented for the format. As a result, we have taken the time to flesh out some of the initial ideas into the basic framework of a standard. What we have so far is fairly detailed, nevertheless, it is simply a starting point and is not set in stone. This means that new ideas and even radical changes of direction are welcome. However, please try focus on the goals list above. In particular, let's try to keep things simple. I. GENERAL INFORMATION. A. CHARACTER SET. All files will use the standard 8 bit ASCII character set. ASCII characters with numerical values greater than 127 decimal can be use to specify special characters such as non-English characters with diacritcal marks. All lines are terminated with the combination of a Carriage Return and a Line Feed. B. UNITS. All units will be in meters and degrees. The original units for a survey will be specified in a separate set of flags. C. TOKENS. The basic format of all data items is: token=value Where the "token" is an ASCII string, and the value is an ASCII string or ASCII representation of a numerical value. This is similiar to the Windows "INI" file strings. Tokens are case sensitive. As a result, the token "SurveyData" is not the same as "SURVEYDATA". Tokens normally terminate with the end of the line. Tokens with arguments longer than one line can be created using "backslash" (\) as a meta character. A backslash at the end of a line indicate that the data is continued on the next line. For simplicity sake, all tokens will be written in English. This suggestion runs the risk of being viewed as being Anglo-centric, however, it would be difficult to try to encompass all of the worlds languages and still be able to come up with a simple format. D. BLOCK STRUCTURE. Generally speaking, the data will be organized into blocks. Each block will have a begining token and ending token which will enclose the data. For example: begin=blocktype ... data goes here end=blocktype This format allows extensions to be added without making old translators obsolete. For example, if a translator encounters a block of data that it does not understand, it simply skips to the corresponding "end" token. E. DATA TYPES. There are only four basic data types: ASCII string, integers, reals and "non-numbers". 1. Strings. Strings consist of the normal ASCII printable and white space characters. String are normally terminated by the end of line. Strings longer than one line can be created using "backslash" (\) as a meta character. 2. Integers. In the file, integers appears as the ASCII representation of signed 16 bit numbers. They normally have a range of values between -32768 to +32767. 3. Reals. In the file, reals appear as the ASCII representation of floating point numbers. The values are assumed to be standard 8 byte IEEE float point numbers in the range of 4.19E-307 and 1.67E308. The ASCII representation of these numbers will be: a. Any number of leading non-numerical characters. b. Any number of leading plus or minus signs. c. One or more integer digits. d. An optional decimal point. e. Zero or more fractional digits. f. An optional 'E' or 'e' character. g. Any number of leading plus or minus signs. h. One or more optional exponent digits. j. At least one non-numerical character as terminator. 4. Non-Numbers. In some instances, you will have numeric fields that also require non-numerical values. For example, in the Left or Right passage dimensions data, there may be a passage instead of a wall. This would make the passage dimension very large or infinite. As a result, certain non-numeric values can appear in a numeric field. Non-numbers are represented the ASCII string "NAN" which standard for "Not A Number." E. FIXED DATA ORDER. Generally speaking, all data will be presented in a fixed order. For example, individaul data items like Azimuth, Length, Inclination etc. will always appear in the same order in the file, no matter what the original data order was. Flags will be used to specify the original enter order of the original data. This concept is specifically designed to simplify parsing and eliminate any ambiguity in the data. F: NO MISSING DATA ITEMS. Inorder to simpilfy parsing and eliminate ambiguity, there will be no missing fields. This means that even if the data is missing, unavialable, or irrelevant the field will still exist. In situations where the data is missing, unavailable or irrelevant, any number can be inserted as a place holder. In some instances, "non-numbers" must be used for missing data items. G. UNCORRECTED DATA. All data is assumed to be uncorrected raw data. H. STATION NAME LENGTH. Station names are assumed to be 16 characters or less. II. FILE STRUCTURE. There are six basic parts to an exchange file: Header Block, Folders, Surveys, Comments, Constrained Stations, Surface Data and Proprietary Data. (There is a sample file at the end of this document that illustrates the format of a complete file.) Here is a detailed description of the file format: A. HEADER BLOCK. The header block is the first section of the exchange file. The header block contains general information about the exchange file format version and the program that generated the current particular file. Here are the commands. 1. FILE FORMAT VERSION NUMBER. The file format version number specifies which version of the Exchange File Format was used to generate the file. Here is an example: FileVersion=1.0 2. PROGRAM NAME. This token specifies the program that generated the file. Here is an example: Program=On Station 4.1 B. FOLDERS. Folders are a method of organizing cave data into a hierarchial "tree" of directories. A folder is an object that can hold a number cave surveys. It can also hold other folders. Since a folder can hold other folders, data can be nested into a "tree" structure. In other words, data can be organized into a logical, hierarchical structure. Here is an example of a two level directory structure: Begin=Folder FolderName=Big Cave Begin=Folder \ FolderName=Little Cave | Inner nested folder | End=Folder / End=Folder There can only be one top level or root folder per file. All other folders must be nested inside the root folder. At this point, station names in one folder are not isolated from the station names in other folders. In other words, the scope of all station names is global. This means that all station names must be unique across all folders. C. SURVEYS. Surveys are blocks of data that contain the actual measured data for a particular segment of the cave. Surveys are enclosed in the standard begin-end pairs: Begin=Survey End=Survey Each survey block can be divided into several sections. Here is a detailed description of each section and the data items contained in each section: 1. Survey Header. The survey header provides basic information about the survey. a. Survey Name. This is in-cave name of a particular survey. It is usually the alphabetic prefix for the station names in the survey. A typical survey name could be "AB". For example: SurveyName=AB b. Survey Date. This the date the survey was actually done. The format of the date should be YYYY/MM/DD, where YYYY represents four digits for the year, MM represents two digits for the month and DD represents two digits for the day. Each part of the date is separated by the the forward slash (/) character. For example: SurveyDate=1996/12/25 c. Survey Description. This item is used to give a description of the survey. Any text can be inserted here. For example: SurveyDescription=This is a test survey d. Declination. This item is used to specify the local magnetic declination. This number is added to all azimuth readings to align the cave data to true north. The value is specified in degrees. For example: Declination=-13.5 e. Data Order. This item specifies the order in which the original data appeared in the survey book. It is generally used by a survey editor to simulate the appearance of the survey book. The order is specified by individual ASCII characters in a seven character string. Each character represents an particular data item. The significance of each character is as follows: L = Tape U = Up Dimension A = Azimuth D = Down Dimension I = Inclination or Depth Gauge R = Right Dimension L = Left Dimension The order of the station names associated with a shot is always assumed to be From and To. In the case where backsight data is present, the order is assumed to be the same as the foresight data. The following example shows a data order of Length, Azimuth, Inclination Up, Down, Right and Left: DataOrder=LAIUDRL f. Length Units. This item specifies the units of measure that were used to originally measure the shot length. It is generally used by a survey editor to simulate the appearance of the survey book. Units can be M=Meter, F=Decimal Feet, and I=Feet And Inches. The following example specifies Feet and Inches for the survey: LengthUnits=I g. Azimuth Units. This item specifies the units of measure that were used to originally measure the shot azimuth. It is generally used by a survey editor to simulate the appearance of the survey book. Units can be D=Degrees, G=Grads, M=Mills, and B=Bearing. The following example specifies Bearing for the survey: AzimuthUnits=B h. Inclination Units. This item specifies the units of measure that were used to originally measure the shot inclination. It is generally used by a survey editor to simulate the appearance of the survey book. Units can be D=Degrees, Degrees and Minutes=M, G=Grads, and Percent Grade=P. The following example specifies Degrees and Minutes for the survey: InclinationUnits=M i. Depth Gauge Units. This item specifies the units of measure that were used to originally measure the depth gauge. It is generally used by a survey editor to simulate the appearance of the survey book. Units can be M=Meter and F=Feet. The following example specifies Meters for a survey: DepthUnits=M 2. Survey Instrument Information. The next section of the survey data contains information about the instruments that were used measure the survey. a. Compass Name. This item specifies a unique name for the compass that was used to survey the data. This item is used identify a compass in case the compass has an error or bais. There is a separate item for the Front and Back compass. The Front Compass is used to measure the forward azimuth, the Back Compass is used to measure the backsighted azimuth. Here is an example: FrontCompass=Suunto #1234 BackCompass=Jim's Compass b. Compass Correction. This item specifies a correction factor for the compasses used on the survey. It is used to correct errors or biases in compass readings. The value specified here is added to the azimuth value during processing. The value is specifed in degrees. Here is an example: FrontCompassCorrection=0.0 BackCompassCorrection=-3.2 c. Compass Standard Error. This item specifies the standard deviation for the compasses used on the survey. This is a statistical measure of the accuracy of the instrument and surveyor. Generally speaking, it gives an error range and probability for the instrument. For example, if the standard deviation is one, then the errors for the instrument will fall in the one degree range 68% of the time. Here is an example: FrontCompassStandardError=1.0 BackCompassStandardError=2.0 d. Inclinometer Name. This item specifies a unique name for the inclinometer that was used to survey the data. This item is used identify inclinometers incase the inclinometer is defective or has a bias. There is a separate item for the Front and Back inclinometer. The Front Inclinometer is used to measure the forward inclination, the Back Inclinometer is used to measure the backsighted inclination. Here is an example: FrontClino=Suunto #1234 BackClino=Jim's Inclinometer e. Inclinometer Correction. This item specifies a correction factor for the Inclinometeres used on the survey. It is used to correct errors or biases in Inclinometer readings. The value specified here is added to the inclination value during processing. The value is specifed in degrees. Here is an example: FrontClinoCorrection=0.0 BackClinoCorrection=-3.2 f. Inclinometer Standard Error. This item specifies the standard deviation for the inclinometers used on the survey. This is a statistical measure of the accuracy of the instrument. Generally speaking, it gives an error range and probability for the instrument. For example, if the standard deviation is one, then the errors for the instrument will fall in the one degree range 68% of the time. Here is an example: FrontClinoStandardError=1.0 BackClinoStandardError=2.0 g. Tape Name. This item specifies a unique name for the tape that was used to survey the data. This item is used identify tapes in case the tape is inaccurate in some way. Here is an example: Tape=Colorado Grotto Tape h. Tape Correction. This item specifies a correction factor for the Tapes used on the survey. It is used to correct errors or biases in tape readings. The value specified here is added to the length value during processing. The value is specifed in meters. Here is an example: TapeCorrection=0.0 i. Tape Standard Error. This item specifies the standard deviation for the tapes used on the survey. This is a statistical measure of the accuracy of the instrument. Generally speaking, it gives an error range and probability for the instrument. For example, if the standard deviation is one, then the errors for the instrument will fall in the one degree range 68% of the time. Here is an example: TapeStandardError=0.1 j. Depth Gauge Name. This item specifies a unique name for the depth gauge that was used to survey the data. This item is used identify tapes in case the tape is inaccurate in some way. Here is an example: DepthGauge=Steve's Gauge k. Depth Gauge Correction. This item specifies a correction factor for the Depth Gauge used on the survey. It is used to correct errors or biases in the depth gauge readings. The value specified here is added to the depth gauge value during processing. The value is specifed in meters. Here is an example: DepthCorrection=0.0 i. Depth Gauge Standard Error. This item specifies the standard deviation for the depth gauge used on the survey. This is a statistical measure of the accuracy of the instrument. Generally speaking, it gives an error range and probability for the instrument. For example, if the standard deviation is one, then the errors for the instrument will fall in the one degree range 68% of the time. Here is an example: DepthStandardError=0.1 3. Personel. This section list each person that has participated in the survey. It also lists the duties performed by the surveyor. For example, one of the common jobs performed would be "Instrument Person." At this point, there is space for six surveyors. All six items must be present even if less than six person participated in the survey. Extra personel items are simply left blank. Here is an example: Person1=Taco Van Ieperen Duty1=Lead Tape Person2=Larry Fish Duty2=Instruments Person3=Martin Heller Duty3=Book Person4=Garry Petrie Duty4=Backsights Person5=Donald Davis Duty5=Insights Person6= Duty6= 4. Survey Data. This section contains the actual survey data measurements. The data for each shot appears in a fixed order and units. The original units and order is specified in the survey header. The survey data is enclosed in standard begin-end pairs: begin=shots end=shots Each shot data item begins with the token "Shot=". The individual data items for the shot are separated by white space characters. White space characters are Tab (09 hex) or Space (20 hex). Each can be followed by zero or more shot comments. Shot comments begin with the token "ShotComment=". 1. From Station Name. This item is an ASCII string specifing the name of the "from" survey station. 2. To Station Name. This item is an ASCII string specifing the name of the "to" survey station. 3. Shot Length. This item is the distance between the "from" and "to" stations in meters. 4. Forward Compass Angle. This item is the azimuth angle in degrees measured from the "from" station 5. Forward Inclination. This item is the inclination angle in degrees measured from the "from" station. 6. Back Compass Angle. This item is the azimuth angle in degrees measured from the "to" station 7. Back Inclination. This item is the inclination angle in degrees measured from the "to" station. 8. Up Dimension. This item is the distance between the "from" station and the ceiling of the cave. If there is another passage in this direction instead of a wall, the non-numerical string "passage" can be used to indicate large distances. 9. Down Dimension. This item is the distance between the "from" station and the floor of the cave. If there is another passage in this direction instead of a wall, the non-numerical string "passage" can be used to indicate large distances. 10. Left Dimension. This item is the distance between the "from" station and the left passage wall. If there is another passage in this direction instead of a wall, the non-numerical string "passage" can be used to indicate large distances. 11. Right Dimension. This item is the distance between the "from" station and the right passage wall. If there is another passage in this direction instead of a wall, the non-numerical string "passage" can be used to indicate large distances. 12. Shot Attributes. Shot attributes are used to give certain properties to individual shots. For example, you might want to exclude a shot from being included in the total length of a cave. Attributes consist of any number of ASCII characters enclosed in parenthesis. If no attributes are use, empty parenthesis must be present. The individual attribute are as follows: S = Surface Survey. C = Exclude From Closing. L = Exclude From Length Totals. X = Total Exclusion From All Processing. P = Exclude From Plotting. Y = Splay Shot. As an example, the attribute (CLS) would indicate that the shot should not be closed, should be excluded from the length totals and was a splay shot. Here is an example of survey data: Begin=Shots Shot=A1 A2 23.5 33.1 4.5 0.0 0.0 5.0 3.1 2.0 3.5 () ShotComment=First Shot Shot=A2 A3 13.5 44.5 0.5 0.0 0.0 1.0 4.1 3.0 2.5 () ShotComment= Shot=A3 A3A 11.0 3.1 -14.5 0.0 0.0 4.0 3.1 2.0 3.5 (CLS) ShotComment= Shot=A3 A3B 23.5 113.1 24.5 0.0 0.0 5.0 3.1 2.0 3.5 (CLS) ShotComment= End=Shots D. DIVE SHOTS. Dive shots are used to hold underwater cave surveys shots where the inclinometer is replaced with underwater depth gauge. Depth gauges measure the depth under the surface of the water by water pressure. The information for a dive shot is identical to a normal shot except that it contains a depth measurement and there is no back compass or back inclination: DiveShot=from to length compass depth up down right left (attributes) The depth specifies the total depth under the surface of the water for the To station. Depth is alway expressed in meters. Stations under the surface of the water have negative numbers for depths. Any station above the surface of the water will have positive depths. E. CONSTRAINED STATIONS. Constrained stations are stations are stations whose location is fixed relative to some outside reference point. In other words, it is the X,Y,Z distance to a fixed reference point. As an example, a fixed station location could be the distance from a local building, a land survey bench mark or a standard references like UTM. Coordinates for these stations should not be changed by the loop closures process. Constrained stations are enclosed in the standard begin-end pairs: Begin=Constrained Stations End=Constrained Stations Each constrained station consists of three data items: a. Constrained Station Name. This is the name of the station whose location is constrained. For example: StationName=ABC23 b. Constrained Station Comment. This item contains an ASCII string which is a comment about the constrained station. c. Station Location. This item holds the actual coordinates of the station. The coordinates are specified in meters and are real numbers separated by white space characters. The order of the coordinates is North, East and Vertical. Here is an example: StationLocation=3278.6 1273.4 345.6 Here is a complete example of constrained stations: Begin=Constrained Stations StationName=AB17 ConstraintComment=Downstream entrance. StationLocation=3123.5 1654.3 234.5 StationName=E1 ConstraintComment=Upstream entrance. StationLocation=1122.5 1343.3 356.5 End=Constrained Stations F. SURFACE DATA. Surface data is used to model surface terrain features. Surface data provides a series of elevation points along a grid which defines the surface topography. You can specify the location of the geographic location of the corner of the grid, and the spacing of the elevation points. At this point, the grid is assumed to be square. Surface data is enclosed in the standard begin-end pairs: Begin=SurfaceData End=SurfaceData A suface data block consists of several items. Here is a detailed description of each item: a. Grid Location. This item is the location of the southwest corner of the grid. This location is specified in meters and are generally relative to some location on the surface of the earth. For example, it could be relative to a local building, land survey bench mark or other land survey standard references like UTM. Here is an example: SurfaceSouthCorner=500 SurfaceWestCorner=500 b. Grid Dimensions. These items specify the number of rows and columns in the grid. The item "NumberOfBlocksEast" specifies the number of west-east rows of data. The item "NumberOfBlocksSouth" specifies the number of south-north columns. Here is an example: NumberOfBlocksSouth=5 NumberOfBlocksEast=9 b. Grid Size. This item specifies the spacing between elevation points in meters. Since the grid is square, the west-east spacing is the same as the south-north spacing. Here is an example: SurfaceGridSize=100 c. Grid North. This value specifies the variation between the UTM grid north and the geodetic (true) north. This is designed to compensate for the distortion inherent in the cylindrical projections such as UTM. The value is added to angle of lines in the grid. Here is an example: GridNorth=0 d. Declination. This item is used to specify the local magnetic declination. This number is added to the angle of the grid lines to align the grid to true north. The value is specified in degrees. For example: Declination=-13.5 e. Surface Elevations. This item specifies the elevations of the grid points. The number of grid points and the dimensions of the grid are determined by dividing the length and width of the grid by the grid spacing. The surface elevations are enclosed in their own begin-end pair and the surface data begins with the token "SurfaceHeight=". The elevations start in the Northwest corner of the grid and runs West to East and from North to South. Long lines can be extended onto the next line with backslash "\" characters. Here is an example: Begin=SurfaceHeights SurfaceHeights= 3320 323 3150 3050 3950 3760 3640 3540 3400\ 3320 3220 3160 3080 3040 3000 3970 3990 3440\ 333 3280 3245 3200 3125 3020 3995 3000 3600\ 3300 3250 3235 3200 3130 3040 3950 3020 3800\ 3323 3200 3195 3190 3155 330 3000 3940 3990\ End=SurfaceHeights End=SurfaceData G. PROPRIETARY EXTENSIONS. The Propriety Extension feature allow special data that is not universally supported by the standard to be included in the exchange file. To include proprietary data you simply enclose it in special begin-end pairs which specify the program that created the data: ProprietaryExtension=COMPASS ProprietaryEnd=COMPASS Tranlators that do not support the particular proprietary data can simply skip to the end of the block. SAMPLE FILE. The following data is a sample exchange file. It has been divided into sections to help clarify the meaning of the data. 1. FILE HEADER BLOCK -------------------------------------------------------------------- FileVersion=1.0 Program=COMPASS ProprietaryExtension=Karst ProprietaryEnd=Karst 2. BEGINING OF A FOLDER -------------------------------------------------------------------- Begin=Folder FolderName=folder name 3. BEGINING OF SURVEY AND SURVEY HEADER -------------------------------------------------------------------- Begin=Survey SurveyName=ABC SurveyDate=1996/11/26 SurveyDescription=Test survey data Declination=0 DataOrder=LAIUDRL LengthUnits=I AzimuthUnits=B InclinationUnits=M DepthUnits=M 4. INSTRUMENT DATA -------------------------------------------------------------------- FrontCompass=Suunto 1232 FrontCompassCorrection=0 FrontCompassStandardError=2 BackCompass=Suunto 1232 BackCompassCorrection=0 BackCompassStandardError=0 FrontClino=Jim's Suunto FrontClinoCorrection=0 FrontClinoStandardError=2 BackClino=Jim's Suunto BackClinoCorrection=0 BackClinoStandardError=2 Tape=Jim's Tape TapeCorrection=0 TapeStandardError=.1 DepthGauge=Grotto Gauge DepthCorrection=0 DepthStandardError=.1 5. PERSONNEL DATA -------------------------------------------------------------------- Person1=Taco Van Ieperen Duty1=Book Person2=Larry Fish Duty2=Tape Person3=Garry Petrie Duty3=Instruments Person4= Duty4= Person5= Duty5= Person6= Duty6= 6. SURVEY DATA -------------------------------------------------------------------- Begin=Shots Shot=A1 A2 23.5 33.1 4.5 0.0 0.0 5.0 3.1 2.0 3.5 () ShotComment=First Shot Shot=A2 A3 13.5 44.5 0.5 0.0 0.0 1.0 4.1 3.0 2.5 () ShotComment= Shot=A3 A3A 11.0 3.1 -14.5 0.0 0.0 4.0 3.1 2.0 3.5 (CLS) ShotComment= DiveShot=A3 B1 23.5 113.1 -24.5 5.0 3.1 1.1 4.5 (CLS) ShotComment=Begining of the sump DiveShot=B1 B2 33.5 12.5 -33.5 6.0 4.2 3.5 4.0 (CLS) ShotComment= End=Shots 7. END OF SURVEY -------------------------------------------------------------------- End=Survey 8. CONSTRAINED STATION DATA -------------------------------------------------------------------- Begin=Constrained Stations StationName=A1 ConstraintComment=This is a fixed station StationLocation=3212.5 1230.5 511.3 End=Constrained Stations 9. SURFACE GRID HEADER -------------------------------------------------------------------- Begin=SurfaceData SurfaceSouthCorner=500 SurfaceWestCorner=500 NumberOfBlocksSouth=5 NumberOfBlocksEast=9 SurfaceGridSize=90 GridNorth=0 Declination=13.0 10. SURFACE GRID DATA -------------------------------------------------------------------- Begin=SurfaceHeights SurfaceHeights= 3320 323 3150 3050 3950 3760 3640 3540 3400\ 3320 3220 3160 3080 3040 3000 3970 3990 3440\ 333 3280 3245 3200 3125 3020 3995 3000 3600\ 3300 3250 3235 3200 3130 3040 3950 3020 3800\ 3323 3200 3195 3190 3155 330 3000 3940 3990\ End=SurfaceHeights End=SurfaceData 11. END OF CURRENT FOLDER -------------------------------------------------------------------- End=Folder