A Cautionary Star*Net Tale

Second time now I've bit myself with this little trick.?ÿ This one might hurt some.

I often start a project with some provisional position constraints in my Star*Net data file, then later change the constraints as a result of things like additional measurements or OPUS results.?ÿ Because I sometimes go back and forth between these constraints as I fool with the adjustment, I make use of the .DATA OFF and .DATA ON inline options to control which data is active.?ÿ But I also tend to have controlling PH positions with the ellipsoid height in meters while desiring output in feet, so I set the project up in feet and use the inline options .UNITS METERS and .UNITS FEETUS to accommodate the metric PH record.?ÿ

Here's an example of how that's gotten me in trouble twice now:

.DATA OFF
.UNITS METERS
# Record per CRTN, CSRC 2017.50 (NGS)
#
PH P268 38.2824683228 121.3847030804 -23.452 'P268
#
.DATA ON
# From OPUS Projects:
PH 2 38.315776636 121.481559040 -1.623 ! ! ! 'WMU1-N
#
.UNITS FEETUS

By carelessly putting that .DATA OFF line before the .UNITS METERS line I told the software that the ellipsoid height of point 2 was -1.623 feet instead of -1.623 meters.?ÿ The difference wasn't so large that any of the adjusted elevations jumped out at me as wrong, and I blithely sent the adjusted flight control data off to my aerial subcontractor.?ÿ By the time I noticed the blunder this evening he had already put in a day compiling the job.?ÿ Not sure what that's going to cost me yet.

See Jim.?ÿ See how Jim screwed up.?ÿ Don't be like Jim.