wallscavesurvey / walls Goto Github PK

The Walls Manual says that LRUDs can contain an optional 5th number that is facing azimuth. However, it also accepts a 6th number:

a	b	5	0	0	*1 2 3 4 100 200*

I'm guessing that when there are two azimuths, the first is the azimuth of the left wall distance and the second is the azimuth of the right wall distance. However a single azimuth is called a "facing direction", which I assume means the angle that the LRUD plane is facing, so a facing angle of 30 would mean left is toward 300 and right is toward 120. I haven't been able to confirm any of this.

Notes

Since adding a 7th number produces the error message "Too many LRUD distances", I can only assume this number is explicitly accepted.

The 6th number is clearly parsed as an angle because using an invalid unit like 200q produces the error message "Bad angle or azimuth qty", whereas an invalid unit on the first four numbers produces the error message "Wrong format for length qty".

While Walls allows the C flag as the 5th or 6th element (with or without a single facing direction), a C flag after two azimuths produces the "Too many LRUD distances" error again, which I assume is a bug.

Emergency changes to the model are expected to e released late this month

While there is nothing wrong with an inclination of -0, it is bad that Walls accepts it with no warning, because it could indicate a data entry blunder (for example, someone meant to type -0.9 but accidentally typed -0.0).

In both walls and wallsmap

The Walls Manual does state that (,v) and (h,) are accepted, but doesn't mention that (,) is allowed. I assume (,) doesn't override the variance in either direction.

The Walls Manual has examples of specifying an LRUD at a station:

A	*3 4 5 6*

However, it also allows - to be used in the from or to station field, which is undocumented:

-	C	*3 4 5 6*
D	-	*3 4 5 6*

I can confirm it interpreted these as LRUD at station lines because it produced the non-fatal error message "LRUD at station - ignored. Facing direction can't be determined."

Currently Walls exports VRML1 which is outdated.
Need to get more clarification from Osama Gobara about how this fits into his workflow

According to Peter's presentation today, the auto-generated file names can overwrite existing files. We should make it pick nonexistent filenames.

Walls allows typing -- to indicate an LRUD measurement is omitted. But it also accepts less than four measurements, like *2 3 4* without warning the user. It even accepts zero measurements **, < >, etc. It also infers an omitted measurements when there are commas with no number between, like *,,,*.

This is bad because whoever entered the data may have omitted a measurement by accident. For example they may have typed *2 3 4* when they meant *2 3 4 5*, or <1,2,,4> when they meant <1,2,3,4>. There is quite a bit of questionable data in the wild because of this. Walls should warn the user and encourage them to explicitly indicate a measurement is omitted by using --.

(from Peter Sprouse)
regardless of whether copying or moving the file

I had thought the parser stops parsing an inline note at #, but the following compiles just fine and does create a foo segment:

#FIX	A	0	0	0	/test #14 #segment foo

Oddly enough, using something like #sege produces the confusing and untrue error message "Use only #SEG on vector lines".

Note:#FLAG directive lines allow #seg, #segment, etc. in their inline notes, and don't interpret it as an inline segment directive.

the walls.sln has references to sefin project that dosn't exist
walls-master\sefin\sefin.vcxproj

While this makes sense, it is undocumented; the Walls Manual states only that inclination/vertical offset may be omitted when it is zero and Order=DA, AD, EN, or NE.

For whatever, reason, .zip files exported by Walls (File > Create/Send project ZIP file...) don't open correctly on Windows; most of the files in the archive don't show up in Windows, even though all of the files extract correctly on MacOS.

This comment from Walls32/zip.cpp doesn't exactly inspire confidence:

// THIS FILE is almost entirely based upon code by info-zip.
// It has been modified by Lucian Wischik. The modifications
// were a complete rewrite of the bit of code that generates the
// layout of the zipfile, and support for zipping to/from memory
// or handles or pipes or pagefile or diskfiles, encryption, unicode.
// The original code may be found at http://www.info-zip.org
// The original copyright text follows.

So my plan is to replace it with the latest official InfoZIP code.

Right now compass import isn't working, because I don't have the wallcss project in this repo. I was having a bunch of compile issues with it, so I thought maybe it was incomplete.

While David's copyright on his code remains even after his passing, the license covering the use of this source code should be decided by the appropriate parties (if it hasn't already) and should be clearly stated.

Thank you for ensuring that the legacy of his work will continue to help cavers all over the world!

According to the walls manual,

Unprefixed names can have a maximum of eight characters and must not contain any colons, semicolons, commas, pound signs (#), or embedded tabs or spaces.

However, the following survey data compiles just fine:

a	<1	5	90	30	*3 4 5 6*
<1,1#,10,180,0,(*,*),<4,5,6,3,100,1000>
1#,2#,5,270,0

DistoX allows users to capture front and back compass reading. At the same time front and back distance is collected. It would be useful to add this option for distance measurements in Walls. i.e. front and back distance.

Peter showed me in a roundtripped map for Jaguar Claw that some station labels are off in the middle of nowhere.
He says it's never caused serious problems, it just looks ugly

Peter Sprouse reports that sometimes with certain books selected in the project tree, when he tries to change the colors for the segments he's unable to get the colors to actually change.