Starnet 8 HARN

> I have been processing my Coors GPS Sessions ...

Would that be the smaller "Banquet" size cans? Sessions that are either too short or (in the case of Coors GPS) above six units in duration, can be problematic.

Kent,
I always misspell that. The sessions we more than long enough, 5 hours. I think they are trying to do coordinate conversions inside starnet 8 even though that's not what they should be doing. Its odd to say the least. Now I will go drink a Coors, which they get out of Texarkana when they're thirst in Atlanta I believe.

> I have been processing my CORS GPS Sessions using theirs Lats and longs in Starnet. ...
I don't have StarNet 8, so I have not experienced this. The StarNet Manual is pretty good and will probably have an explanation.

You should be able to examine the projection parameters that Star*Net uses. I'm unable to think of a good reason why there would be a separate projection for the HARN.

Transporting CORS east of Texas is bootlegging.

Not exactly sure if you are saying you manually typed in CORS coordinates or whether there is an option in the program to retrieve them from the NGS site.

Given the existence of tools to tranform coordinates between different versions of NAD83 (HARN, 2007, 2001) perhaps it uses GEOCON to do an inappropriate transformation?

Perhaps the folks at StarNet decided to get all high tech and transform coordinates from the reference epoch to the date of observations?

Looks a problem to pose to them.

> Given the existence of tools to tranform coordinates between different versions of NAD83 (HARN, 2007, 2001) perhaps it uses GEOCON to do an inappropriate transformation?
>
> Perhaps the folks at StarNet decided to get all high tech and transform coordinates from the reference epoch to the date of observations?

From taking a look at a Star*Net v8 tutorial, it appears that the folks at MicroSurvey have added "datum transformations" to the coordinate system menu, which is probably the root of the problem described. It would not have been a problem with v6.

Have you contacted their tech support?

Yeah, I have but they claim they are doing the conversion correctly, problem is I don't want any conversion. They have no way of even knowing what I put in kinda hard to convert something that way. Just a heads up for anyone using it.

I've tried 8.0 & 8.1, & worked hard to replicate custom projections that run great in the older versions, but to no avail, so I'm just sitting on V 7.2.whatever. Maybe as you point out there are more problems hiding there in the new interface for projections, so thanks.

I've been a little put out when I tried their support team & to me there seems to be just a bit of an Emporer's New Clothes mentallity there.

Guess I was spoiled working with the old ownership - I remember a weekend I emailed Ron late Saturday afternoon hoping for a little input Monday & as I was working in the office Sunday morning he called to give me a hand. Legendary support, that.

> Yeah, I have but they claim they are doing the conversion correctly, problem is I don't want any conversion. They have no way of even knowing what I put in kinda hard to convert something that way. Just a heads up for anyone using it.

Surely there is some way of disabling the coordinate "datum" transformations. I mean, if you are in the SPCS projection of NAD83, why wouldn't all positioned entered and returned be treated as NAD83?

> I've been a little put out when I tried their support team & to me there seems to be just a bit of an Emporer's New Clothes mentallity there.

> Guess I was spoiled working with the old ownership - I remember a weekend I emailed Ron late Saturday afternoon hoping for a little input Monday & as I was working in the office Sunday morning he called to give me a hand. Legendary support, that.

Yes, Ron was great. A large part of why Star*Net versions 1 through 6 were so excellent is that he tried to keep the program as simple and flexible as possible and always retained backwards compatibility. Oh, the code actually working didn't hurt a bit, either. This "datum transformation" feature sounds distinctly un-Sawyerish.

>Oh, the code actually working didn't hurt a bit, either. This "datum transformation" feature sounds distinctly un-Sawyerish.

Yeah, they're working hard to add features which, it seems to me, will eventually make it simpler for a new user to get to a higher profiency level faster than before. That said, at least for me, there is way too much of the 'Golly, Gee Whiz' fluff which, as we all know, makes for a lot of code & inherent coding errors, but not much real performance gain.

Still, I'll keep mailing my yearly maintenance fee, if for no other reason, its not this weeks flavor of Trimble or Leica software, which I hope will keep Ron's baby alive until I retire.

> Yeah, they're working hard to add features which, it seems to me, will eventually make it simpler for a new user to get to a higher profiency level faster than before. That said, at least for me, there is way too much of the 'Golly, Gee Whiz' fluff which, as we all know, makes for a lot of code & inherent coding errors, but not much real performance gain.

I must be missing something, because I can't really imagine a use for "datum transformation" within a least squares survey adjustment program. It only invites something nutty to happen.

If you want to add datum transformations as a tool outside the adjustment, fine, but as a matter of design philosophy, it seems like a dumb choice.

> I must be missing something, because I can't really imagine a use for "datum transformation" within a least squares survey adjustment program. It only invites something nutty to happen.
>
> If you want to add datum transformations as a tool outside the adjustment, fine, but as a matter of design philosophy, it seems like a dumb choice.

Yep. I'm just not going to really "get" the OP's nuts & bolts problem, or dig in to try to, but they added what they call a new "Coordinate System Module" at the front end in the first screen of the Project Options. For me its a "Golly, Gee Whiz" somewhat vaporous essense of fluff. Probably very impressive to the GIS'ers / Surveyor kinda wanna-bees & maybe ultimately useful to all, time will tell? For now though I'll hold on v 7.2 ish & hope there are others with the patience to sort it out.

> Probably very impressive to the GIS'ers / Surveyor kinda wanna-bees & maybe ultimately useful to all, time will tell? For now though I'll hold on v 7.2 ish & hope there are others with the patience to sort it out.

At one time, Michael Sage, who had worked with Ron Sawyer, was helping MicroSurvey with v7, which I thought was a hopeful sign that it would keep the virtues of earlier versions. I'm pretty sure that I offered my opinion that what Star*Net really needed was a focus on data import options, to support as many common data collector and GPS vector formats as possible and to forget about trying to add useless complexity just to give the marketing people something to write about.

No there is no way to disable it. My coordinates are fine if I use a NAD83 and not HARN. I only selected HARN for reporting purposes knowing they are closer to the latest adjustment. What is really odd if you use Starnet's optional listing file "changes from entered provisional coordinates". I normally process extra CORS into my network as a check leaving them float, but the don't show that their coordinates have shifted even though the held points are the same in both files but the checks shots are floating around .8, so they must be applying the shift to only the free stations and at the end of the adjustment so starnets listing file doesn't see it happen.