Reducing Astro Observations for Azimuth determination in Star*net (or not)

I would just average them an make one Bearing (B) record with error estimate. Just make sure you enter the correct type of bearing into Star*Net. It's my understanding that the Star*Net program assumes all entered directions are on grid basis (not geodetic) unless you use the ".MEASURED BEARING" inline function.

BTW, looking back through your previous thread you stated that you had a copy of Elgin & Knowles ASTRO*DISK83 DOS program. I have been looking for that program (along with their ASTRO*CARD program). Where did you find it?

Bow Tie Surveyor, post: 383527, member: 6939 wrote: I would just average them an make one Bearing (B) record with error estimate. Just make sure you enter the correct type of bearing into Star*Net. It's my understanding that the Star*Net program assumes all entered directions are on grid basis (not geodetic) unless you use the ".MEASURED BEARING" inline function.

BTW, looking back through your previous thread you stated that you had a copy of Elgin & Knowles ASTRO*DISK83 DOS program. I have been looking for that program (along with their ASTRO*CARD program). Where did you find it?

Thanks very much for the heads up about bearings; I'd completely forgotten about that. I'll prepare to give it a whirl with a single bearing.
Regarding E and G's DISK83 program: I think it might have been Lee Green who sent it to me (or a close version of it), but it may also have been Jerry Wahl. Let me dig around for it; I'll start a conversation with you when I find it.

I would put in each observation separately along with a weight.

I will be presenting a class/workshop at Trimble Dimensions in Novemberon azimuths. I proposed one for the last Dimensions conference, but they did not accept it. I proposed it again this year, and they were hesitant, not really seeing the need for astro azimuths, but I did convince them.

John Hamilton, post: 383558, member: 640 wrote:

they were hesitant, not really seeing the need for astro azimuths, but I did convince them.

For anyone with enough money to buy a full on GPS system, there probably is no need; I'm probably the odd duck there.
If you want to demonstrate a modern approach to establishing them though, I'd recommend something along lines of the Excel spreadsheet that Larry Scott has developed. It allows you to gather the data and evaluate quality of the observations in near real time. Truly amazing.

I still see a need. There are locations where it is not possible to set a pair of GPS points far enough apart to get a good azimuth. The survey of my property is a good example. The point TRAIL is in a railroad cut, where I wanted to both topo and tie in property evidence It has visibility to 01083A (GPS control with backsight just south of TRAIL), which is on top of the cut a short distance away. Tall trees on both sides of the trail preclude the use of GPS in the bottom of the cut. So, I observed a polaris azimuth to another point set further down the trail, and made a position tie to 01083A.

Also, while I will admit it is a remote possibility, what will people do if GPS/GNSS stopped working? I would imagine potential adversaries have plans to disrupt our navigation capabilities if they wanted to cripple us before an attack. Or, probably more likely, a solar storm like the one in 1859...

https://en.wikipedia.org/wiki/Solar_storm_of_1859

and

http://news.nationalgeographic.com/news/2011/03/110302-solar-flares-sun-storms-earth-danger-carrington-event-science/

An event of this magnitude could conceivably knock out a lot of satellites.

John Hamilton, post: 383564, member: 640 wrote: I still see a need. There are locations where it is not possible to set a pair of GPS points far enough apart to get a good azimuth.

Yes, it is often overlooked that short GPS pairs will often have poor azimuth uncertainties. For example, assuming 0.03' positional uncertainty between two GPS points, you would need the pair to be longer than a 1,000 feet to exceed the accuracy of an average solar azimuth (6") and longer than 4,000 feet to exceed the accuracy of an average Polaris observation (1"). This becomes obvious when you try to traverse between GPS pairs and come up with poor closures. A lot of the time the reason is, you started with a poor azimuth which only magnifies your positional error the further you traverse away from it. In Florida, the GPS pairs set during our densification projects were often only around 2,000 feet long (its flat here). Although, they list the precision out to the tenth of an arc-second, they are probably only good to 2-3 seconds.

Bow Tie Surveyor, post: 383906, member: 6939 wrote: Yes, it is often overlooked that short GPS pairs will often have poor azimuth uncertainties. For example, assuming 0.03' positional uncertainty between two GPS points, you would need the pair to be longer than a 1,000 feet to exceed the accuracy of an average solar azimuth (6") and longer than 4,000 feet to exceed the accuracy of an average Polaris observation (1"). This becomes obvious when you try to traverse between GPS pairs and come up with poor closures. A lot of the time the reason is, you started with a poor azimuth which only magnifies your positional error the further you traverse away from it. In Florida, the GPS pairs set during our densification projects were often only around 2,000 feet long (its flat here). Although, they list the precision out to the tenth of an arc-second, they are probably only good to 2-3 seconds.

And there are people who set two OPUS points for azimuth control..........Probably OK if, as you say, they are far apart, but that is often not feasible.

John Hamilton, post: 383558, member: 640 wrote: I would put in each observation separately along with a weight.

I will be presenting a class/workshop at Trimble Dimensions in Novemberon azimuths. I proposed one for the last Dimensions conference, but they did not accept it. I proposed it again this year, and they were hesitant, not really seeing the need for astro azimuths, but I did convince them.

Are you planning on demonstrating the actual process? I.e., doing some solar or stars and reducing the observations?

If you ignore the 04-Jun obs, there's only 1.1" spread in four observations to average. It won't matter much.

And a star shot returning so close a value to several sunshots, you can hold the average of the 4 azimuth obs fixed, unless you have azimuth observations, at other stations in your network.

And, we know that's an Astro Az converted to approximate Geo Az. And, you've compared your multiple astro azimuth obs to a pair of NGS GPS points. Which was better than 3".

Larry Scott, post: 383963, member: 8766 wrote: If you ignore the 04-Jun obs, there's only 1.1" spread in four observations to average. It won't matter much.

And a star shot returning so close a value to several sunshots, you can hold the average of the 4 azimuth obs fixed, unless you have azimuth observations, at other stations in your network.

And, we know that's an Astro Az converted to approximate Geo Az. And, you've compared your multiple astro azimuth obs to a pair of NGS GPS points. Which was better than 3".

Hey Larry: Welcome back from sea (or wherever you were, lol). OK. I'll dump June 4th and average. Since I have these from your sheet converted to UTM, should I use UTM zone 18, translate them to Vt SPC, or just leave everything Geodetic for now? Can't find how to do the "measured bearing" thing Bow Tie refers to in the Starnet manual.

Convert Geo az to VT SPC, grid az.

Geo azimuth is in the output, and Geo to SPC is one step.

John Hamilton, post: 383558, member: 640 wrote: I would put in each observation separately along with a weight.

I will be presenting a class/workshop at Trimble Dimensions in Novemberon azimuths. I proposed one for the last Dimensions conference, but they did not accept it. I proposed it again this year, and they were hesitant, not really seeing the need for astro azimuths, but I did convince them.

Looks Like I am NOT presenting a session on azimuths, they want me to do one on dam deformations . I really want to do the azimuth one, I did the deformation session twice before and also presented it in Hong Kong and Montevideo at FIG meetings.

John Hamilton, post: 384289, member: 640 wrote: Looks Like I am NOT presenting a session on azimuths, they want me to do one on dam deformations . I really want to do the azimuth one, I did the deformation session twice before and also presented it in Hong Kong and Montevideo at FIG meetings.

Once again, Azimuths get no respect...

Larry Scott, post: 383969, member: 8766 wrote: Convert Geo az to VT SPC, grid az.

Geo azimuth is in the output, and Geo to SPC is one step.

The central meridian is at 072-30-00w. My observation point is at 072-35-00 (5 minutes west of the CM). The Latitude is 43-40-29.
So, Should I use this formula for Transverse Mercator? or the one for Lambert? See here:

Using this formula, I get -00-03-27 for the convergence to Vt SPC.
If I subtract that negative number from my average geodetic azimuth (327-58-32.85), I get 328-01-59.85, which I'd call 328-02-00. Sound right?

rfc, post: 384524, member: 8882 wrote: The central meridian is at 072-30-00w. My observation point is at 072-35-00 (5 minutes west of the CM). The Latitude is 43-40-29.
So, Should I use this formula for Transverse Mercator? or the one for Lambert? See here:

Using this formula, I get -00-03-27 for the convergence to Vt SPC.
If I subtract that negative number from my average geodetic azimuth (327-58-32.85), I get 328-01-59.85, which I'd call 328-02-00. Sound right?

Yes, the convergence is negative where you are, so you would subtract that from geodetic to get grid. i get 328-02-00 as well.

Projection type depends on your SPCS zone. Vermont and New Hampshire would be transverse Mercator.

Scott Zelenak, post: 384563, member: 327 wrote: Projection type depends on your SPCS zone. Vermont and New Hampshire would be transverse Mercator.

Thank you Scott and Bow Tie.:)

So, armed with the fixed azimuth to a distant point derived via astro observations, I would create a .dat file in Star*net, as follows:

B 500-House 328-02-00
C 500 428158.317741 1618337.887148 1000 ! ! !
# And then turn a bunch of sets between that distant point to another point in the network, like so:

DB 500
DN House 00-00-00
DN 100 68-23-58
DE
DB 500
DN 100 248-23-47
DN House 179-59-42
DE
DB 500
DN House 00-00-00
DN 100 68-23-56
DE
DB 500
DN 100 248-23-40
DN House 179-59-53
DE
DB 500
DN House 00-00-00
DN 100 68-23-59
DE
DB 500
DN 100 248-23-48
DN House 179-59-51
DE

I understand that if I fix the location of 500, then everything else in the network would adjust (i.e. rotate), around that point.
Am I on the right track so far?

I think you can get rid of all those extra DEs and DB 500s in the middle and pack that into 14 lines.
And why fix 500? The LSA will determine its position if that's part of a larger file.
You'd have to look at a minimally constrained network first. Fix one point and an azimuth then fix more points as/if needed.