![]() |
Geoida |
Observation Conventions and Types for Traverse and Network |
When processing traverse or network observation data using any of the standard Survey menu processing options (except Radiations), the Process Extracted Observations option in the Advanced Processing menu, or importing observations from an Extract file into the Least Squares Network Adjustment option, Geoida uses a point-numbering convention to determine observation type. Therefore when entering data into the Traverse option or editing any Extract file generated as a result of running one of the above options, this convention must be maintained and will be subsequently interpreted as follows:
Observation Type |
Instrument Station (At) |
Reference Station (RO) |
Observed Point (To) |
Angle | At | RO ‡ | To |
Example: | 101 | 100 | 102 |
Direction b/s |
At | RO ‡ | RO |
f/s 1 | At | RO | To |
f/s 2 | At | RO | To |
Example (1 set): b/s |
101 | 100 | 100 |
f/s 1 | 101 | 100 | 102 |
f/s 2 | 101 | 100 | 103 |
Azimuth / bearing | At | 0, blank or At ‡ | To |
Example 1: | 101 | 102 | |
Example 2: | 101 | 0 | 102 |
Example 3: | 101 | 101 | 102 |
Distance / Ht Diff * | At | 0 or blank | To |
Example 1: | 101 | 102 | |
Example 2: | 101 | 0 | 102 |
‡ |
|
* |
A distance or height difference observation may be incorporated into any other observation type |
Note - Several independent traverses may be contained within each Traverse option data set or Extract file. The first traverse detected in a data set determines whether all subsequent traverses in the same data set are treated as bearing traverses or angle traverses - if there is a mixture of bearing and angle traverses they should be entered into different data sets or Extract files so that their modes are not misinterpreted. |
Sections below
|
Determination of Traverse Type
According to the point-numbering convention as established in the table above, traverse types are determined in this way:
Bearing traverse
Two formats are recognised:
Format for second and following records:
Angle traverse
However, there are two variations to an angle traverse in which either
Angle traverse with starting reference bearing In case 2 for
the angle traverse above, it is possible to compute a fictitious
location for the RO so that a valid reference bearing can be
computed from coordinates. As the first record for the traverse, an
observation in the form of the second bearing observation format
(see above) may be inserted such as:
This observation will be treated as a horizontal angle observation as normal, but because the reference bearing between the instrument station and the RO (actually the same point) will be zero, the forward bearing (entered as a horizontal angle) will be the correct reference bearing required and the distance will then allow coordinate values to be computed for the RO - the coordinates will not be correct (unless the distance was correct) but any bearing computed between the first instrument station and the RO along the reference line will be correct. The record following should then be for the first horizontal angle observed as turned between the RO and the first traverse point, but because the RO point number for this observation is now different from the observed To-point in the previous record, a new traverse start will be detected but a correct reference bearing can now be computed for it.
Azimuth to unfixed RO in least squares adjustment
Commencing a traverse by specifying a reference bearing or by computing false coordinates for the RO as described above, may lead to a difficulty if adjusting the data with least squares. All points to which observations are made in a network adjustment must already exist, either as fixed control points, or as unfixed points which will be subject to adjustment. If an azimuth observation is included (such as for the starting reference bearing for a traverse as described above) to a reference point whose coordinates are unknown but for which fictitious values have been either entered or computed using only an estimated distance, and there is no other observation (eg a distance along the same line or an observation from another point) made to the same point (i.e. it is uncontrolled), then there is no way for Geoida to verify that the point's existing coordinates are within the point tolerance. As a consequence, the least squares adjustment to the network may actually diverge and not reach a solution. This could happen if the original coordinates for the point in question were changed by a swing being applied to the azimuth due to the adjustment of the network, such that the azimuth to the point now computed the point outside of tolerance.
Such a situation could be helped by fixing either the point or the azimuth observation, or by ensuring that there was at least one other observation made to the point, for example, by reversing the direction of any angle observation which had previously included the point as the RO and now making the RO the forward observed point and thus subject to a tolerance test.
Detecting new traverse starts and side-shots
Bear in mind that Geoida can also handle side-shot observations when included amongst traverse observations.
A side-shot will be determined where:
A new traverse start is determined by the following
circumstances (no adjustment applied):
Bowditch adjustment - In addition to the above conditions,
when the traverse data is to be adjusted using the Bowditch
setting, a traverse section will immediately conclude when an
observation is made to a fixed point or to a point already computed
on a previous section. See also next heading.
Excessive traverse sections detected - If a set of traverse
observation data is broken into what seems to be too many smaller
traverse sections, it may be a result of sets of multiple
observations (eg directions) from the same setup including
side-shot observations to points that are either fixed or already
computed on one or more previous traverse sections. This situation
would be expected in more complex networks.
To verify if this is the situation, check the number of traverse sections detected when computed in None adjustment mode - if the number of detected traverse sections is now less, Geoida may be wanting to adjust onto points already computed on earlier section/s and also observed in subsequent sections. This is normal and to be expected BUT may be worsened if the observations are not arranged correctly at each setup - the correct arrangement of multiple observations at one setup is un-fixed side-shots first, followed by the foresight to the next traverse station, and fixed points or previously-observed points last. In other words, move any observations to fixed or previously-observed points to the END of sets of angles made from the same stations.
Note that if the observations are directions and Geoida breaks up the data into a greater number of adjustable sections, observations made at the same setups may become separated from the direction observations to their associated reference points. This will not be a problem UNLESS a set's reference observation is NOT exactly zero, in which case the Extract file should be edited and a copy of the reference observation at each setup be inserted prior to any observations following an observation to a fixed point or a point on an earlier traverse section where the traverse section has been closed.
If the survey is a network then it will be far better to adjust by Least Squares anyway - using traverse options will normally be just to check closures etc and derive provisional coords prior to a Least Squares Network adjustment.
Converted from CHM to HTML with chm2web Standard 2.85 (unicode) |