Stop printing N-nodes info by default

[Wookey]

Survex has reported how many nodes of each N there are in the processed data since it was created. This was a neat touch, but mostly more of a curio than important data.

As laser splay-surveying becomes more popular then number of node-sizes is rising (there is now a 35-node in the Austria dataset), and you pretty-much get a screenfull of this stuff scrolling the important info about cave length and warnings off the screen.

I really think that printing this out on stdout is now much more unhelpful than helpful and we should probably stop doing it unless someone asks for it. It's been annoying (to me at least) for a long time, but the distoX surveying style really has pushed it over the edge.

There is a related matter of putting the 'calculated statistics' somewhere more useful than just in the output stream, especially if we add area and volume (see ​https://trac.survex.com/ticket/80 )

[Olly Betts]

I wonder if the real issue here is more that splays are treated as legs here (and in the count of legs above).

I know in CUCC we used to find these useful as a way of spotting cock-ups in the data, though I'm a bit hazy on exactly what sort. But perhaps without the splay contamination they still are useful - you'd not get a whole screenful, and they would indicate how many actual legs are tied into a junction. If nothing else, they'd point up if someone's put in a load of splay data without it being flagged as splays!

[Olly Betts]

(Whatever we do, I think this is useful to keep this available for the testsuite as it provides an easy extra check that the data was processed as expected.)

[Olly Betts]

Or we add something to the testsuite that gives a roughly equivalent check there.

This has been open ~9 years now and nobody else has chimed in or independently brought up the issue that the node stats are not really useful if you use a lot of splays (as people increasingly do) which does rather suggest nobody is actually interested in them. So perhaps we should just remove them (and if people moan we could have aven calculate and report them from the data it has loaded, or do it as part of a command line tool).

Aside from this reporting, the shape value reported here is only used in one place, which is part of checking for unused fixed points. I think that check is actually done at the wrong place though as currently this:

*fix 1 0 0 0
*fix 2 0 0 0
2 3 1 0 0
*solve
1 4 1 90 0

confusingly warns:

cmd_fix_bad2.svx:1: warning: Unused fixed point “1”

This is because we check while running through the data after solving, but when *solve is used we can't know if a fixed point gets used after the *solve.

I can't see any an argument for warning in this case so I think this is a bug.

Perhaps we can instead set an UNUSED_FIX flag if *fix refers to a station which didn't already exist and then clear that whenever we attach a leg to a station. Then we scan over the stations at the end and report any with this flag still set.

[Olly Betts]

I've fixed that bogus warning in e315359e3d7c9796b70ccda267184afc686f50fa. The currently tracked shape value is now only used to report the node stats.

Now going to review which testcases benefit from us checking the node stats.

[Olly Betts]

It's not easy to reliably search for, but the only fix I found where the regression test is via the node stats is eb04711dc016aa51c8c0945b1feac87437cd9613 (trac seems to fail to show the diff for some reason) but that doesn't really count as the bug was that the reported node stats counted the fake leg used internally to implement a *fix with SDs (also I didn't add a regression test; I'm much more rigorous about that now than I was in 2001).

The counts of legs, stations, loops and components are helpful in some places - I think I was maybe thinking about that in comment:2.

So maybe removing them is fine for the testsuite too.

[Olly Betts]

Fixed by c77682a19bc4cfdd263ee29117e2f7261e421220.