From: John Halleck (John.Halleck_at_utah.edu)
Date: Fri Feb 23 2001 - 22:20:15 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA32665 for cavexml-outgoing; Fri, 23 Feb 2001 22:20:14 +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 WAA32661 for <cavexml_at_cartography.ch>; Fri, 23 Feb 2001 22:20:13 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id OAA04896 for <cavexml_at_cartography.ch>; Fri, 23 Feb 2001 14:20:16 -0700 (MST) Date: Fri, 23 Feb 2001 14:20:15 -0700 (MST) From: John Halleck <John.Halleck_at_utah.edu> To: cavexml_at_cartography.ch Subject: (oops, I can't type) was Re: Stations are primary In-Reply-To: <Pine.GSO.4.05.10102231404470.3316-100000_at_cor.oz.cc.utah.edu> Message-ID: <Pine.GSO.4.05.10102231418570.3316-100000@cor.oz.cc.utah.edu> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
On Fri, 23 Feb 2001, John Halleck wrote:
OOps.
> [...]
> Stations also need unique identities in (as you put it) when it comes
Stations also need unique identities when it comes
> to error analysis. If there are multiple shots between the same
> two points, and you later analyse the survey, you'll need to be able
> to tell users which of those shots you belive to be in error, and just
> "a shot from A to B" isn't enough in this case. (Although I guess
> a program could say, as people do, "Shot from A to B from Wednesday's
> Survey.")
>
> This is, of course, not a hypothetical case... there is a shot
> in the Mudslide Room in LBCC that has been shot three times now.
> (Becuase it was blundered twice!)
>
> Unique identities have many uses, and I agree that their use for
> stations is critical. But they have good uses for stations also.
stations is critical. But they have good uses for shots also.
> An optional ID for a "shot" (Whatever that is.) might be usefull.
>
> > [...]
> > How do those programs work now? They must have **some** way to tell if a
> > station is new (within a file) or is the same as a previous station. If
> > they didn't, how could they do anything with the data? If station names
> > are assumed unique within (Survex) files (1, 2, 3, ...) that's fine,
> > base the station IDs on those. When merging files, maintain that
> > uniqueness by prepending the file name (or a hash of it), except when
> > you know (by whatever means you use now) that two stations in different
> > files are the same (this is just one possible implementation). You can
> > keep track of file names by having one big namesystem with names that
> > combine filename and number, or separate namesystems for each file.
>
> I'll still argue for a numeric ID (with some prefix) on grounds of
> symplicity of algorithms to combine the files...
>
> > [...]
>
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET