From: John Halleck (John.Halleck_at_utah.edu)
Date: Tue Jan 16 2001 - 17:12:19 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA29582 for cavexml-outgoing; Tue, 16 Jan 2001 17:12:21 +0100 Received: from cor.oz.cc.utah.edu (nahaj_at_cor.oz.cc.utah.edu [155.99.2.2]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA29578 for <cavexml_at_cartography.ch>; Tue, 16 Jan 2001 17:12:20 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id JAA18754; Tue, 16 Jan 2001 09:12:20 -0700 (MST) Date: Tue, 16 Jan 2001 09:12:19 -0700 (MST) From: John Halleck <John.Halleck_at_utah.edu> To: Paul & Eleanor <goodhill_at_xmission.com> cc: cavexml_at_cartography.ch Subject: Re: Past words In-Reply-To: <3A63F302.66345F46_at_xmission.com> Message-ID: <Pine.GSO.4.05.10101160854450.11050-100000@cor.oz.cc.utah.edu> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk
> Garry Petrie wrote:
> [...]
> 3. SIMPLE UNITS FORMAT. Another place where exchange format can wrong
> is to attempt to present the data every conceivable measurement
> units.
My personal opinion:
It is the job of whatever parses and processes original text
to also do unit conversions. It is the job of that program
to know about most units. (Generally unit conversion is done
from a table anyway, a few more entries aren't going to break
anything.
Once something has produced (and marked) "standard" units, all the
remaining tools can just use them, and what kind of units they
came from doesn't make much difference.
Routines that output the data may need to know about units also,
but that should be just table lookups also.
Maybe I'm missing something here?
I've always seen (actually I'm lying... I've come to see...)
the stages of survey processing as (roughly, with necessary detail
ommitted): [ Remembering that this is just an opinion ]
"Original" data: Needs to be stored, needs to be availiable.
Proofreaders don't stand a chance if they don't have access.
Transscrxibed data. (What was typed in.)
Proofreaders need both the original and transscribed forms in
order to catch data entry errors.
"Raw Numbers" (The result of unit conversions, regularizing shot
directions, assigning point numbers, etc.)
The "unprocessed" numbers are useful for checking that the
routines that process the transscribed data are correct.
(Particulary in new projects where software is suspect.)
Munged numbers. (The result of processing the survey).
Needed in clean form for routines that display, manipulate,
extract, etc. from the survey.
My opinion is that they are all needed, and if they are in separate
files they will be separately lost.
Gary's note:
> > 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.
Paul's reply:
> These flags would I believe have to retain not only units but precision
> also.
I second this. If one is doing a pedanticly correct survey analysis
you need the precision of the original measurements. (But it really
doesn't matter too much what those units were.)
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET