Provide way to exclude survey data from processing

[Alastair Gott]

Would it be possible to define a new command for comments which go across multiple lines. *ref seems to terminate when a new line is made. whereas it might be nice to be able to use a *ref/*endref command to keep the comment within a wrapper.

From my lack of knowledge I think it would be a change to the read_string command ​http://eclipseclp.org/doc/bips/kernel/iochar/read_string-5.html by changing the SepChars? to "*endref".

but then I don't know the first thing about coding, let alone C.

[Olly Betts]

*ref is not a general commenting mechanism (that's ;) - *ref is intended to record some sort of identifier from another system - e.g. if you store original survey notes in a filing cabinet, you can put the folder number in *ref in the .svx file so somebody can find the original survey notes easily should they need to check for a transcription error. Or if the data is from an electronic device, you could record the filename of the data exported from that device. I'd not expect that information to need multiple lines.

The proposed *refmulti ... *endref also doesn't really fit well with the rest of the file format.

[Alastair Gott]

It's not really me that wants the mod. but from my understanding of their problem, they want to comment out a portion of survey data, presumably because it's now redundant (but they don't want to delete it).

and I also don't think they want to take the data out of the current file structure, just comment out the bits which have now been resurveyed. I've pointed out to them that they can try and use Kate text editor to amend several lines at the same time with the ;

which I think is now what they are going to do.

Thinking outside of the box for them, would it be possible to use the *set EOL <character> to tell survex to keep treating the text after a ; as a comment until the EOL is put in.

Then after the data that you need commenting you reset the *set EOL back to (x0Ax0D)

So would this be a solution for them?:

survey data to include
data …….tape compass ….
…….

*set EOL (^powersign) [or *set EOL (5E)]
;comment survey data not including
…….
….Loads of lines of survey data
…….
end of survey data not including
^
*set EOL (x0Ax0D)

survey data to include
data …….tape compass …….
…….
*end

Or am I over thinking this?

[Alastair Gott]

file I broke trying to use two EOL statements within a survey.

[Alastair Gott]

file I broke trying to use two EOL statements within a survey.

[Alastair Gott]

This is not the survey which this feature is needed for, but thought I'd have a try.

[Olly Betts]

It's quite hard to use *set eol to switch to a different end of line as it changes the parsing of the end of its own line. It's less mind melting if you just want to add some extra end of line characters.

This works though:

*set eol ^^;

*fix should_be_ignored 0 0 0

^*set eol x0ax0d

*fix 1 0 0 0

Notes: The second ^ on the first line is the end of that line. Then the ; starts a comment which ends at the ^ before the next *set.

I notice that *set eol ^ ^; fails to work, as the *set adds the space as an end of line character. I'm not sure if that's a bug or a feature.

But this doesn't seem a great answer to the problem - changing the end of line will mean that cavern's idea of line numbers won't align with what a text editor thinks, which will be confusing - for example this warning is reported as line 4, but is actually for the final line of the example (line 7):

cmd_seteol.svx:4: warning: Unused fixed point “1”

It also means you can't safely use ^ (or whatever character you pick) in comments safely, as it'll become an end of line if wrapped by *set eol ^^; ... ^*set eol x0ax0d and drop out of the long comment that creates.

I would just stick a ; at the start of each line of data I wanted to disable in this way, but that does require using a text editor which is capable of doing that easily (or a lot of tedious and potentially error-prone repetitious key strokes to do manually).

This use case should be better supported I think - perhaps via a flag (DEACTIVATED perhaps) or a new data style. Using a flag would potentially allow us to still parse such data to ensure it's syntactically valid, which is probably useful. Compass has an X flag which is documented as X - Exclude this shot from all processing:

​https://www.fountainware.com/compass/HTML_Help/Compass_Editor/surveyfileformat.htm

[Olly Betts]

There's actually an entry on the TODO list for:

legs: "commented out" flag? syntax check data but otherwise ignore

[Olly Betts]

It occurs to me we have a STYLE_IGNORE internally, which ignores non-command lines and is set as the style when a *data command fails to parse so you don't get an avalanche of errors and/or warnings due to trying to parse data lines which the failed *data was meant to set the style for.

It should be easy to expose that so *data ignore ignores data lines until the next *data (or scoped by *begin...*end, e.g.:

*begin
*data ignore
; There's a blunder in this section so we resurveyed it.
4 5 8.03 263 +01
5 6 5.04 359 -03
6 7 7.45 017 -07
7 8 11.40 - down
*end

[Olly Betts]

Implemented in [63ae487c3774235108687d74a7af0c104dcdd4f3], will be in 1.4.11.