Foot.inches

[echarlie]

No description provided.

[ojwb]

Happy PR birthday!

What did this stall on? It doesn't look like it was me, but if it was what do you need from me to progress?

[ojwb]

Walls syntax for this is e.g 6i3.5 for "6 foot and 3.5 inches" (and i6 for "6 inches"). These seem rather unintuitive to me as units normally come after the number, so the first reads like "6 inches and ... something". Neither is a notation I have seen elsewhere either.

We could about as easily support 6'3.5" which is at least a common notation (and perhaps allow 6'3.5 with the trailing " implied), and maybe 6" for 6 inches (or just require people write 0'6 or 0'6" which you'd probably write in the survey notes anyway to avoid " vs ' confusion (c.f. Spinal Tap's Stonehenge set!)

Maybe we should have a *set FEET ' and *set INCHES " - then if you really wanted the Walls syntax you could *set FEET i to get it. (Currently *set doesn't allow setting alphanumerics, but that could be relaxed for this case without huge problems - the most awkward one is that e.g *set blank xab means byte 0xab rather than setting it to x, a and b. We could require e.g. *set FEET x69 to specify i but that's quite cryptic. We could also allow any letters except x to be used literally, but you'd have to "escape" x as x78.)

I also wonder if having to specify this as a pseudo-unit is the right approach - currently that's needed because 3.3 for "3 foot 3 inches" is indistinguishable from 3.3 for "3.3 (decimal) feet", but if we followed Walls "set the default units, but have a syntax to override", so we could have *units length feet and then 3 would be "3 feet", 3.3 would be "3.3 feet", 3'3 and 3'3" would be "3 feet 3 inches".

On a similar note, maybe we should allow quadrant bearings to be used as an override. There doesn't seem to be ambiguity. I looked at the discussion in #7 and we didn't seem to discuss this back then (or not in the PR at least).

There's also percent scale clino readings, which could be specified as e.g. 20%.

I guess partly this comes down to whether people are likely to actually mix decimal feet and feet inches, or quadrant bearings and non-quadrant bearings, or angle and percentage gradients in one data set. If not, having to specify via *units means that accidentally entering 3.3 when you meant 3'3 gets caught.

The main "prior art" here is that for percentage clinos I went for *units clino percent rather than supporting a % suffix (and maybe adding *set percent %). I think that choice was largely based on only having seen them occur when people sometimes accidentally read the wrong scale on a dual scale clino, and requiring putting *begin *units clino percent ... *end around the wrong data line/lines for an exceptional case seemed a reasonable approach (and it's also simple if you always read as percent - e.g. because your clino only had a percent scale). I don't think I really contemplated this as setting a pattern for future additions of units which weren't simply a real number which was a scale factor away from metres/degrees.

I think having written down my musings on the subject, I find Walls unit overrides conceptually quite nice, but being explicit as a way to catch typos and similar errors is quite persuasive against that, and in practice I doubt it's common to have much of a mix of notations for any given reading type in a single survey trip of data.

[ojwb]

I've addressed my comments above, merged master to the branch and resolved the conflicts, then fixed some problems I noticed. The new testcase now passes.

One big question I have is whether 3.3 is the right syntax for this. If that's really what people surveying in feet and inches write down in their survey notes then I think the least terrible option is probably to support it, but if there's a commonly used syntax that doesn't look just like a decimal number then that seems a better option.

As noted above, Walls uses 3i3 for "3 feet and 3 inches" which is at least prior art but it seems a confusing notation to me, and I suspect is not a standard notation.

3'3 is at least very widely used in general, but I'm not sure about by cave surveyors.

[ojwb]

Another downside of using . for the feet/inches delimiter is that if we want to support a fractional number of inches we end up with . with multiple meanings within the same reading - e.g. 3.3.5 for "3 feet, 3 and a half inches" where the second dot is a decimal point but the first isn't. Using different delimiters such as 3'3.5 seems clearer.

[ojwb]

From chat, notation recorded in-cave is 4'5" most likely so aiming to support that directly seems a good approach.

[echarlie]

I think the reason I stalled on this initially is because I was going down the nasty path of using flags (and I'm not a C developer, so I made some errors) to pass the feet-and-inch handling through the system. That's been mostly obviated by support for feet and inches in survex by way of walls data. I was trying to not box myself in if someone did *units tape left right feetinches and *units up down meters or something equivalent.

I think something like 4'5" is most likely. I am wondering if we should allow that to be an implicit unit denotation that only works for *units tape feet, or maybe be more thoughtful. Reasonable data will probably look like 4'5", but unreasonable data (surveyors didn't realise they had a foot-inch tape) may look like 4.5...4.12 though I think overloading . is a bad idea. There also almost certainly is data in straight inches.

My inclination: *units tape inches or *units tape feetinches are probably the most reasonable flags to turn on this parsing mode: anything else should warn agressively.

[ojwb]

Allowing 4'5" with *units tape feet would be a departure from anything we currently support that I can think of - the closest analogs are probably that quadrant bearings require specifying explicitly via *units compass quadrants and that percentage clino requires *units clino percent.

(Incidentally, I wonder if we should support quadrant bearings in grads...)

In practical terms, a survey is very unlikely to use a mixture of decimal feet and feet+inches so having to bracket data leg(s) which were recorded a different way (perhaps a second longer tape or something) seems reasonable as it helps to highlight the exceptional situation, e.g.:

*begin example
*units tape feet
1 2  12.3 345 +06
2 3  23.4 123 -04
*begin
; pitch measured with longer foot/inch tape
*units tape footinches
3 4 234'5" - down
*end
4 5 34.5 234 -05
*end example

Perhaps tapes exist with feet and inches and one side and decimal feet on the other, but if you have one you really need to pick a side to use to avoid cock-ups (and I'd think surveyors try to avoid buying such tapes).