Re: Splitting SHOT into constituent members

New Message Reply About this list Date view Thread view Subject view Author view

From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Wed Jan 24 2001 - 16:02:35 CET


Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id PAA09220 for cavexml-outgoing; Wed, 24 Jan 2001 15:59:59 +0100
Received: from sun0.aic.nrl.navy.mil (sun0.aic.nrl.navy.mil [132.250.84.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA09216 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 15:59:58 +0100
Received: from aic.nrl.navy.mil (pc31.aic.nrl.navy.mil [132.250.84.181]) by sun0.aic.nrl.navy.mil (8.9.3+Sun/8.9.3) with ESMTP id JAA29503 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 09:59:59 -0500 (EST)
Message-ID: <3A6EEE8B.6070602@aic.nrl.navy.mil>
Date: Wed, 24 Jan 2001 10:02:35 -0500
From: Ralph Hartley <hartley_at_aic.nrl.navy.mil>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010122
X-Accept-Language: en
To: cavexml_at_cartography.ch
Subject: Re: Splitting SHOT into constituent members
References: <057601c085a1$46e9f320$0a3c10ac_at_gordon>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-cavexml_at_karto.baug.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch

Julian Todd wrote:

> I don't see why, if you have a very clear location of your survey
> stations, you can't go through the whole cave passage with just
> compass and clino, and come back another day and take
> all the tape measurements with a friend?

I believe this has been done. I think it was one of those "don't YOU
have the tape?" things. As I remember hearing the story, the results
were less than ideal.

> If you suspect an error
> in the survey you normally look for a single measurement rather
> than the whole shot as being the source of the problem.
> Some measurements, such as depth measured by a cave diver,
> can't really be associated to a shot, because they are of a single station.
> What shot would you force it into?
>
> So, the current way everyone is thinking about is:
>
> <shot from=88, to=88a>
> <tape>5.5<units t=metres/></tape>
> <compass>45<comment>dodgy</compass>
> <clino>78<intr serialno=099999A/><readby name=toad/></clino>
> <backsight>
> <clino>-76<readby name=jim/></clino>
> </backsight>
> </shot>
>
>
> Superficially this would become
>
> <tape from=88, to=88a>5.5<units t=metres/></tape>
> <compass from=88, to=88a>45<comment>dodgy</compass>
> <clino from=88, to=88a>78<intr serialno=099999A/><readby name=toad/></clino>
> <clino from=88a, to=88>-76<readby name=jim/></clino>

However this form discards some information that is sometimes important,
that the data was collected as part of a single shot. For a start, if
there were a comment that applied to the whole shot (e.g. "tight"),
where would you put it?

A more serious problem is that there are common types of errors that DO
apply to the shot as a whole, and not to the individual measurements.
One common exapmle of this is a reveresed shot, where from and to should
be interchanged throughout. Even more serious, and sadly very common,
error is a bad tie in. Here each measurement is perfectly OK but one of
the stations is incorrect. This can be a transcription error, the
station may have been misidentefied by the surveyors, or the point tied
to might not be a pre-existing station at all. This is common when one
of the stations is from an older survey.

To fix such errors, you really need to know which measusements are part
of the same shot.

Also there may occationally be more than one shot connecting a single
pair of stations, either correctly and deliberately (reshooting to find
an error) or unintentionally and disastrously (two parties used the same
station numbers, or one party looses count). In the latter cases, the
loss of structure caused by disagregating the measurements from the
shots could make the confusion virtually unrecoverable.

>
> The only other reason to group these measurements up (apart from
> saving your "from" and "to" attributes in 2/3 of the XML records)
> is because that set of data defines a single shot vector.
>
> Now, I believe that the computer can sort through all the data pertaining
> the relative locations of stations "A" and "B" and work all this out
> for itself.

But as the examples above illustrate, there are situations where this
gives the wrong answer.

> There are also other methods of measurements where there is
> no such shot grouping. Trilateration, for example, where the data is
> only tape measurements (when there are enough of them, the
> geometry becomes rigid). And cave diving depth data where
> the following non-excusive data defines a so-called shot vector:
>
> <depthgauge station=A depth=5.15/>
> <tape from=A to=B distance=18.8/>
> <compass from=B to=A bearing=89.0/>
> <depthgauge station=B depth=8.32/>

I do agree that data that is only associated with one station (such as
depth guage readings or gps fixes) should be recorded that way.

That's the cause of the infamous "RLUD question". LRUD is really
assosiated with a station, not a shot, but left and right need a
direction to be defined, so some information from a shot is needed. The
eternal question is WHICH shot? The preceding shot, the next one, or
some combination? What if there is more than one shot to or from the
station? What if there is less than one (The first station in the cave,
a dead end, the last before beer and pizza calls, the survey resumed
months or years later when the previous station is not marked)?

If I was designing survey practice from scratch (I am not) I would have
an aditional field in the book, direction in tens of degrees.
"12/5/1/1/0" would mean left=5 right=1 up=1 down=0 when facing the
direction 120 degrees (recording a third digit would make people feel a
duty to measure it). Maybe SE/5/1/1/0 (to the nearest 45 degrees) is better.

Ralph Hartley


New Message Reply About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:53 CET