From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Fri Jul 19 2002 - 08:20:24 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 7A20915930 for <cavexml-outgoing_at_ethz.ch>; Fri, 19 Jul 2002 12:33:21 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 17BB415918; Fri, 19 Jul 2002 12:33:16 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 234CA15915 for <cavexml-loopcheck_at_ethz.ch>; Fri, 19 Jul 2002 12:33:13 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 3831515918; Fri, 19 Jul 2002 12:33:05 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 7968315915 for <cavexml_at_cartography.ch>; Fri, 19 Jul 2002 12:33:04 +0200 (CEST) Received: from relay1.melbpc.org.au (newglider.melbpc.org.au [203.12.152.9]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 22C2615919 for <cavexml_at_cartography.ch>; Fri, 19 Jul 2002 12:32:57 +0200 (CEST) Received: from localhost.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by relay1.melbpc.org.au (8.12.5/8.11.6) with ESMTP id g6JAGCft042050 for <cavexml_at_cartography.ch>; Fri, 19 Jul 2002 20:16:12 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Fri, 19 Jul 2002 16:20:24 +1000 From: Peter MATTHEWS <matthews_at_melbpc.org.au> In-Reply-To: <003b01c22e56$c6380360$c7ab07c3_at_argussoft.ru> Message-Id: <5.1.0.14.1.20020719160945.01d513c0@popa.melbpc.org.au> Received: from relay1.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by localhost.melbpc.org.au (AvMailGate-2.0.0.6) id 42012-2EB50FE5; Fri, 19 Jul 2002 20:15:45 +1000 Received: from peter.melbpc.org.au (a2-32.melbpc.org.au [203.12.157.32]) by relay1.melbpc.org.au (8.12.5/8.11.6) with ESMTP id g6JAFZSA041996 for <cavexml_at_cartography.ch>; Fri, 19 Jul 2002 20:15:43 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Subject: Re: Data model : branches and nodes To: cavexml_at_cartography.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Sender: matthews_at_popa.melbpc.org.au X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
At 16:29 18-07-02 +0400, Alexander Nickolsky wrote:
>Here is some text from the definitions:
>------------
>Branch
>A survey network element which is a sequence of one or more Legs which join
>two adjacent Nodes in the network.
>Typical fields: node1 name, node2 name, leg(s).
>Node
> A survey network element which is a Position of a Station which is the
>meeting point of more than two Legs, or which is otherwise needed in
>manipulating the network.
>Typical fields: name, legs connected.
>--------------
>
>I think that separation nodes and branches as special classes of legs and
>stations is
>nothing but data duplication. I don't see any clear reason to do this.
>If we are joining data from different surveys together, some Stations can
>become Nodes. But the data from different surveys should be separated
>in the whole file. Thus we will see Station that is Node without any reason
>at all, looking at the single survey data. I agree that some Stations might
>have a kind of special meaning, but they have names and this special
>meaning could be associated with their names.
>I think that Node and Branch are completely useless.
>The same is about Spur.
I have included the concepts of Node, Branch and Spur because some people
use them when manipulating survey data, e.g. for some methods of loop
closure analysis. For example a single Branch could replace a whole string
of non-bifurcating Legs/Shots. If your work did not involve using Branches,
etc, then you would ignore those entities completely. However because our
CaveXML standard has to allow for all users and their needs if it is to be
accepted, then I feel we need to consider them in the overall scheme. But
no one is forced to use them. We can discuss the issue in detail when we
come to them.
Peter
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:01 CEST