Re: Stations are primary

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

From: John Halleck (John.Halleck_at_utah.edu)
Date: Thu Feb 22 2001 - 21:31:11 CET


Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA25914 for cavexml-outgoing; Thu, 22 Feb 2001 21:31:19 +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 VAA25910 for <cavexml_at_cartography.ch>; Thu, 22 Feb 2001 21:31:13 +0100
Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id NAA10204 for <cavexml_at_cartography.ch>; Thu, 22 Feb 2001 13:31:11 -0700 (MST)
Date: Thu, 22 Feb 2001 13:31:11 -0700 (MST)
From: John Halleck <John.Halleck_at_utah.edu>
To: cavexml_at_cartography.ch
Subject: Re: Stations are primary
In-Reply-To: <3A957188.8010309_at_aic.nrl.navy.mil>
Message-ID: <Pine.GSO.4.05.10102221318120.26224-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 Thu, 22 Feb 2001, Ralph Hartley wrote:

Wonderfull well written summary of your ideas. Thank you.

> Date: Thu, 22 Feb 2001 15:07:36 -0500
> From: Ralph Hartley <hartley_at_aic.nrl.navy.mil>
> Reply-To: cavexml_at_cartography.ch
> To: cavexml_at_cartography.ch
> Subject: Stations are primary
>
> The more I have thought about CaveXML, the more I am drawn to the
> conclusion that the primary element must be the station, not the shot.

  Note that the LS adjustment is naturally point (station) oriented.

  As my internal angles paper also indicated, rearranging
  data from shots (as recorded) to point oriented is needed to do some
  forms of error analysis (looking for magnetic anomolies).
  
> [...]

> Also, different programs may each need to have their own names for the
> stations, and the names may not be compatible (one may require names to
> start with a letter, another may use numbers only), or the names might
> overlap (foo and bar both have a station named "1" but they are
> different stations).

  That is one of the things that having a unique station number can
  be used for. (And having the input program handle equivalences
  by making the numbers the same means that later programs don't
  have to care.)

> [...]

> Alternatively, From and To could be attributes with type IDREF. That
> depends on how grouping and default values for measurements are done,
> which is an orthogonal issue.

  Although having them as IDREF's constrains the form that they may have.

> [...]

> The down side of this is that the CaveXML file contains elements that
> don't come directly from the survey book. An editor, when a shot is
> added, needs to check if the stations already exist. If so it uses the
> old id for the station, otherwise it needs to generate a new station
> element.
 
  Some program is going to have to do this some time, it may as well
  be the original editor, so that the other programs need not care.

  What we don't have is a data processing model that spells out
  what tasks are which program's responisbility.

> The up side is that all this is very easy to generate automatically.

  Amen.

> Starting with unique station names, it is easy to generate station
> elements using those names for both the id and a name. If data comes in
> from different sources, name collisions don't cause a problem because
> the station ids can be reassigned from scratch (they are strictly local
> to a file) without loosing track of any of the old names.

  If they are numbers (with a possible prefix), and they run 1..N when
  there are N unique points, then the algorithm to combine two files
  and preserve that property in the result is trivial.
 
> I don't see a real need for the station id's to follow any particular
> pattern, sequential numbers, globally unique identifiers etc., but of

  If they do (as I mentioned above) then it can make for simpler algorithms
  for later processing programs.)

> course that is permitted, or they can be added as another set of names.
> All that is *needed* is that ids be unique within one file. Stations in
> other files could be handled by a station element that contains a
> reference to the other file; within this file it would be referred to by
> its local id.

> [...]


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

This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET