Bug in prefix hierarchy handling?
Cooper, Ben
ben.cooper@siemens.com
Fri, 16 Jan 2004 13:42:45 -0000
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C3DC36.9F4ACCD0
Content-Type: text/plain
Interesting - but it's not you - the files are OK.
Notice also that the .err file has it right, but the .3d representation on
screen is confused. Problem with caverot?
I've noticed that the problem comes and goes depending on whether or not a
loop exists in the survey data. If you break the two loops, the problem
goes away. To see what I mean, comment out the two lines that join the two
loops, as follows:
In file 204.svx, comment out the equate of insignificant2.6 and
micturation.8 as follows:
;*equate trunk.insignificant2.6 domes.micturation.8
In file trunk/insignificant2.svx, rename second occurrence of station 0 to
station 8, and add *equate, and then comment out the *equate to break the
loop, as follows:
7 8 5.04 327 -48.5
;*equate 8 0
It is then very easy to experiment in connecting or disconnecting these two
loops. With either loop connected, the strange trunk.trunk.trunk problem
appears, but with both loops broken, the naming is as expected. You can
also visually see the loop closure error - very large (c. 30m) between
insignificant2.6 and domes.micturation.8!
- Ben Cooper
-----Original Message-----
From: David Loeffler [mailto:dl267@hermes.cam.ac.uk]
Sent: 15 January 2004 23:08
To: survex@survex.com
Subject: Bug in prefix hierarchy handling?
Can anyone tell me what's going on with the attached survey data (taken from
a reorganised version of the CUCC Loser dataset)?
Processing 204.svx with cavern seems to confuse it mightily as to which
stations should have which prefixes, and in the resulting .3d file the
station which should rightfully be '204.midlevel.pendulum.10' comes out as
'204.midlevel.trunk.trunk.trunk.pendulum.10'!
Why does cavern think that 'trunk' should contain everything else, including
itself? Have I made a stupid mistake somewhere, or is this a bona fide bug?
(If it's relevant, I'm using 1.0.27 under Red Hat Linux; I was originally
using 1.0.22 which shows the same behaviour, and upgrading didn't fix it.)
David
------_=_NextPart_001_01C3DC36.9F4ACCD0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.45">
<TITLE>RE: Bug in prefix hierarchy handling?</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Interesting - but it's not you - the files are =
OK.</FONT>
<BR><FONT SIZE=3D2>Notice also that the .err file has it right, but the =
.3d representation on screen is confused. Problem with =
caverot?</FONT>
</P>
<P><FONT SIZE=3D2>I've noticed that the problem comes and goes =
depending on whether or not a loop exists in the survey data. If =
you break the two loops, the problem goes away. To see what I =
mean, comment out the two lines that join the two loops, as =
follows:</FONT></P>
<P><FONT SIZE=3D2>In file 204.svx, comment out the equate of =
insignificant2.6 and micturation.8 as follows:</FONT>
<BR><FONT SIZE=3D2>;*equate trunk.insignificant2.6 domes.micturation.8 =
</FONT>
</P>
<P><FONT SIZE=3D2>In file trunk/insignificant2.svx, rename second =
occurrence of station 0 to station 8, and add *equate, and then comment =
out the *equate to break the loop, as follows:</FONT></P>
<P><FONT SIZE=3D2>7 =
8 5.04 =
327 -48.5</FONT>
<BR><FONT SIZE=3D2>;*equate 8 0</FONT>
</P>
<P><FONT SIZE=3D2>It is then very easy to experiment in connecting or =
disconnecting these two loops. With either loop connected, the =
strange trunk.trunk.trunk problem appears, but with both loops broken, =
the naming is as expected. You can also visually see the loop =
closure error - very large (c. 30m) between insignificant2.6 and =
domes.micturation.8!</FONT></P>
<P><FONT SIZE=3D2>- Ben Cooper</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David Loeffler [<A =
HREF=3D"mailto:dl267@hermes.cam.ac.uk">mailto:dl267@hermes.cam.ac.uk</A>=
] </FONT>
<BR><FONT SIZE=3D2>Sent: 15 January 2004 23:08</FONT>
<BR><FONT SIZE=3D2>To: survex@survex.com</FONT>
<BR><FONT SIZE=3D2>Subject: Bug in prefix hierarchy handling?</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Can anyone tell me what's going on with the attached =
survey data (taken from a reorganised version of the CUCC Loser =
dataset)?</FONT></P>
<P><FONT SIZE=3D2>Processing 204.svx with cavern seems to confuse it =
mightily as to which stations should have which prefixes, and in the =
resulting .3d file the station which should rightfully be =
'204.midlevel.pendulum.10' comes out as =
'204.midlevel.trunk.trunk.trunk.pendulum.10'!</FONT></P>
<P><FONT SIZE=3D2>Why does cavern think that 'trunk' should contain =
everything else, including itself? Have I made a stupid mistake =
somewhere, or is this a bona fide bug?</FONT></P>
<P><FONT SIZE=3D2>(If it's relevant, I'm using 1.0.27 under Red Hat =
Linux; I was originally using 1.0.22 which shows the same behaviour, =
and upgrading didn't fix it.)</FONT></P>
<P><FONT SIZE=3D2>David</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C3DC36.9F4ACCD0--