From: John Halleck (John.Halleck_at_utah.edu)
Date: Tue Jan 23 2001 - 20:27:24 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA03944 for cavexml-outgoing; Tue, 23 Jan 2001 20:27:10 +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 UAA03940 for <cavexml_at_cartography.ch>; Tue, 23 Jan 2001 20:27:09 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id MAA23049 for <cavexml_at_cartography.ch>; Tue, 23 Jan 2001 12:27:24 -0700 (MST) Date: Tue, 23 Jan 2001 12:27:24 -0700 (MST) From: John Halleck <John.Halleck_at_utah.edu> To: cavexml_at_cartography.ch Subject: Re: LRUD: 'From' or 'To' ? (fwd) Message-ID: <Pine.GSO.4.05.10101231226490.9398-100000@cor.oz.cc.utah.edu> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk
I saw someone reply to the orignal, so I guess it did go to the list....
So I'll forward the reply to the list.
---------- Forwarded message ----------
Date: Tue, 23 Jan 2001 12:25:56 -0700 (MST)
From: John Halleck <nahaj_at_u.cc.utah.edu>
To: Richard Knapp <gyp_caver_at_yahoo.com>
Cc: John Halleck <John.Halleck_at_utah.edu>
Subject: Re: LRUD: 'From' or 'To' ?
On Tue, 23 Jan 2001, Richard Knapp wrote:
I didn't see the list in the address list, so I'm replying privately.
> > Seriously, there are cases (Such as very back sighting conditions) where
> > there could be many different observations of (for example) azimuth.
>
> Hmmm.. I have not heard of such instances. Would this be used in cases where you repeat a
> measurement a few times then take the average? How do you handle it now?
Averaging the shots is a simple minded way to do it.
(A full proper adjustment would not do this, and would need the information
from the repeats in order to correctly calculate variance of the azimuth,
and therefore the variance of the shot.)
I'll admit that that is not anything like the usuall case, but I think
elements is the right approach because it CAN handle such things. And
doing things more elaboratly is going to happen with time.
If you really need examples, consider the covariance matrix of two shots
connecting these points, one computed from DAI and the other computed
from a triangulation or trilateralization...
> > Formats that make assumtions about how shots are normally done are going
> > to make it so I can't represent data I already have
>
> There isn't any restriction on how many azimuth or direction elements are allowed unless
> specifically stated in the DTD or Schema (please correct me if I'm wrong here).
Change the DTD from something like ... (distance azimuth inclination) ...
to something like ... (distance|azimuth|inclination)+ ...
Admittedly, this would pass shots that were missing values, but if that's what
is in the book, that is what we should parse out of it. The fact that it
doesn't work for survey processing is something that the survey processing
pass should report. (And, if you think about it, trilatereralizations are
all of the form of just distances between points.)
> > Just attributes has problems....
>
> It is a rather large issue in XML right now (elements vs attribute) so I thought I would ask. Seems
> like having elements isn't the problem; just elements with CDATA instead of specified attributes.
> ie
>
> <azimuth>
> 90
> </azimuth>
>
> isn't as good as
>
> <azimuth value="90"/>
I agree... The second is better in my opinion.
I'd personally much prefer to go from (Our old LBCC format):
...
a 1.0+-0.0002 2.0 - 4.0
10.0 180.0 0.0
- 170.0 -
- 179.0 -
b 2.0 2.0 3.0 4.0
to (With units normalized, and assuming some default
variences for the instruments.)
...
<original>a 1.0 2.0 - 4.0</original>
<point name="a" id="1" />
<section>
<left value="1.0" variance="0.0002"/>
<right value="2.0"/>
<floor value="4.0"/>
</section>
<original> 10.0 180.0 0.0</original>
<original> - 170.0 -</original>
<original> - 179.0 -</original>
<shot>
<distance value="10.0"/>
<azimuth value="180.0"/>
<inclination value="0.0"/>
<azimuth value="170.0"/>
<azimuth value="179.0"/>
</shot>
<original>b 2.0 2.0 3.0 4.0</original>
<point name="b" id="2" />
<section>
<left value="1.0">
<right value="2.0">
<floor value="4.0">
</section>
...
Where computing (co)variances of the shots, orientation of sections, etc
is all done by later passes that understand their tiny part of the world..
> FWIW.
Huh?
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET