The review of Star*Net v8.01 in the November issue of POB is long on fluff and short on substance. I suppose if the reader knows nothing of LSA software it might be useful, but considering the magazine's target audience, I was surprised to see written a such a low knowledge level.
I plowed through it anyway -- it was lunchtime reading material -- and noted two items worth mentioning.
The first is the addition of the PRISM inline option. This allows the user to correct input data for EDM measurements recorded with the wrong prism offset. It's an option you shouldn't have to use often -- it addresses a field blunder that should happen rarely -- but it's useful enough that I incorporated the same functionality into my raw data reduction software many years ago.
The second is a statement that puzzles me. A ConnDOT staffer is quoted as saying that multiple level loops featuring stations in common can't be adjusted properly with Star*Net versions prior to v8.01. The version I use (v6) handles leveling observations as elevation differences between stations along with either associated distances or number of turns (the latter being a rough substitute for interstation distances), so loops are irrelevant to the adjustment. Perhaps he meant that some of the newer versions of the software have a means of reporting loop statistics derived from the adjustment, and that prior to v8.01 this feature didn't always work correctly. Could it be that the article is crowing about a bug fix?
> The first is the addition of the PRISM inline option. This allows the user to correct input data for EDM measurements recorded with the wrong prism offset.
That sounds like an easy feature to have added and one that would be useful sooner or later.
I'm not sure what the appeal of direction arrows on GPS vectors in the network plot is, though.
> I'm not sure what the appeal of direction arrows on GPS vectors in the network plot is, though.
I guess the arrows might be interesting if you do a lot of one-way ties, but most of my networks involve a lot of reciprocal observations, so I'd end up with a jumble of double arrows on screen.
> I guess the arrows might be interesting if you do a lot of one-way ties, but most of my networks involve a lot of reciprocal observations, so I'd end up with a jumble of double arrows on screen.
Exactly my thoughts. It's not *really* as if GPS vectors have other than a purely arbitrarily chosen direction. DX, DY, DZ from 1 to 2 should be identical to the inverse of 2 to 1.