From: Garry Petrie (gp_at_europa.com)
Date: Tue Jan 16 2001 - 06:02:49 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id GAA25486 for cavexml-outgoing; Tue, 16 Jan 2001 06:11:53 +0100 Received: from io.europa.com (IDENT:root_at_io.europa.com [216.65.131.2]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id GAA25482 for <cavexml_at_cartography.ch>; Tue, 16 Jan 2001 06:11:48 +0100 Received: from europa.com (ip85.gte15.rb1.bel.nwlink.com [209.20.244.85]) by io.europa.com (8.11.1/8.11.1) with ESMTP id f0G5BjX04002 for <cavexml_at_cartography.ch>; Mon, 15 Jan 2001 21:11:45 -0800 (PST) Message-ID: <3A63D5F9.8060208@europa.com> Date: Mon, 15 Jan 2001 21:02:49 -0800 From: Garry Petrie <gp_at_europa.com> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en,pdf To: cavexml_at_cartography.ch Subject: Past words Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk
I dug this up while cleaning my disk at work today, just happened
to have a bearing on today's discussion. I believe Taco Van Ieperen
wrote it.
Garry Petrie
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
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:51 CET