Does this seem suff...
 
Notifications
Clear all

Does this seem sufficient?

13 Posts
3 Users
0 Reactions
192 Views
bushaxe
(@bushaxe)
Posts: 645
Member
Topic starter
 

I have a topo job on the north and south banks of a land cut for a tidal waterway. The water portion has been completed by a hydro crew at high tide on MLLW. Most of the bank is covered by trees. But I was able to find two open spots on each bank where I have placed control points for TS work. I have conducted one GNSS observation on those 4 points plus 1 Tidal Benchmark last Friday. The Tidal BM will be used to establish the relationship between NAVD88 and MLLW. I will eventually marry the two data sets into one surface model and deliver to the design engineer. I plan to run another observation on all 5 points for redundancy today or tomorrow, weather dependent.

Because this site is a highly eroding bank of sand, I shortened my first set of GNSS observations to 1-hour. My thinking is that the job is earthwork in an ever changing environment and 1-hour observations would be sufficient for design and quantity calculations.

I am interested if you guys think two 1-hour sessions on all 5 points is sufficient for this job?

Sent from my iPhone using Tapatalk

 
Posted : April 25, 2017 4:02 am
leegreen
(@leegreen)
Posts: 2196
Supporter
 

Please explain by "one GNSS observation on those 4 points plus 1 Tidal Benchmark".

Was this Static with a single receiver, or two? Do you have nearby CORS? Are going to post process yourself or use OPUS?

" Do you guys think two 1-hour sessions on all 5 points is sufficient for this job? "

Depends on how long your baselines are.

My suggestion is to use 5 static GNSS and occupy all 5 points simultaneously for 1 hour using fixed 2m poles. Or use a minimum of 3 and leap frog.

 
Posted : April 25, 2017 5:17 am
leegreen
(@leegreen)
Posts: 2196
Supporter
 

My suggestion is to use 5 static GNSS and occupy all 5 points simultaneously for 1 hour using fixed 2m poles. Or use a minimum of 3 and leap frog.
Then post process the static data myself, with vertical constraint on the Tidal Benchmark.

 
Posted : April 25, 2017 5:47 am
bushaxe
(@bushaxe)
Posts: 645
Member
Topic starter
 

leegreen, post: 425284, member: 2332 wrote: My suggestion is to use 5 static GNSS and occupy all 5 points simultaneously for 1 hour using fixed 2m poles. Or use a minimum of 3 and leap frog.
Then post process the static data myself, with vertical constraint on the Tidal Benchmark.

Okay - had to get in the field and get things going since my initial post.

Friday I was by myself and did not want to leave any equipment out of my sight. So 1-hour static observation on the BM single receiver. Then I moved up to points A and B and performed simultaneous observations. Then moved up to points C and D and performed simultaneous observations.

Today I have help. Currently running simultaneous observations on BM, A, and B. Will then move receivers from BM and B up to C and D, leaving Receiver running on A the entire time. All other observations are slightly over 1-hour.

Have only used OPUS up to this point but thinking of trying a trial version of Carlson GNSS package to take advantage of all available satellites. As I believe OPUS is GPS only.

BM is approx. 2.4 miles from site. CORS approx. 6.3 miles from site and about 4 miles from BM.

See sketch.

Sent from my iPhone using Tapatalk

 
Posted : April 25, 2017 7:54 am
leegreen
(@leegreen)
Posts: 2196
Supporter
 

OPUS is not going to work for you. With those short baselines 1 hour is way more than enough static data. With L1/L2 GPS & Glonass in open sky, you can get as little as 15 minutes static, using 5 or 10 second epochs. More is better

With two receivers you should simultaneously measure each vector of the polygon A to B to C to D to A, just like a closed conventional traverse. It sounds like you plan on doing this. Then post process or have someone with experience help you.

The CORS will not help you get onto to NAD83 horizontal, do not constrain it for vertical, since it is wrong vertical.

 
Posted : April 25, 2017 8:12 am

leegreen
(@leegreen)
Posts: 2196
Supporter
 

Correction: CORS will help you get on to NAD83 horizontal, but NOT on the vertical you want, Tidal Benchmark.

 
Posted : April 25, 2017 8:29 am
bushaxe
(@bushaxe)
Posts: 645
Member
Topic starter
 

The BM references NAVD 88 and MLLW. I'm thinking if I have NAVD 88 from Static GPS/GNSS I've got what I need for vertical conversion.

As far as open sky - the BM is near a hotel sign. Its off the corner, but it worries me. Thats why I was thinking of GNSS and the 1-hour observation.

Sent from my iPhone using Tapatalk

 
Posted : April 25, 2017 8:32 am
leegreen
(@leegreen)
Posts: 2196
Supporter
 

Best to constrain on an original BM, then check into the CORS. They will almost be different, every time.

Suggest you set a TBM where you have wide open sky, no obstructions, then a short level loop to the original BM. You never want multipath when using GNSS (Static or RTK) for differential leveling. Vertical is more affected by multipath than horizontal.

Give me a call, I can help post process it for you.

 
Posted : April 25, 2017 8:39 am
bushaxe
(@bushaxe)
Posts: 645
Member
Topic starter
 

Thanks for the help Lee. I think you're saying set a TBM somewhere close to the original BM with wide open sky, run a static observation, and run a level loop from TBM to the original BM. Doing this checks the vertical value obtained through the static observation on the BM and that I should do this because of the potential for multipath at the original BM.

Sent from my iPhone using Tapatalk

 
Posted : April 25, 2017 10:00 am
leegreen
(@leegreen)
Posts: 2196
Supporter
 

BushAxe, post: 425339, member: 11897 wrote: Thanks for the help Lee. I think you're saying set a TBM somewhere close to the original BM with wide open sky, run a static observation, and run a level loop from TBM to the original BM. Doing this checks the vertical value obtained through the static observation on the BM and that I should do this because of the potential for multipath at the original BM.

BushAxe,

Yes, that's exactly what I'm saying.

 
Posted : April 25, 2017 10:10 am

MightyMoe
(@mightymoe)
Posts: 10038
Supporter
 

The rule of thumb for static is 10 minutes plus 1 minute per mile for minimum time of observation. The idea that you need 2-4 hours is something more tied to OPUS than Static control between project control points. I would rather have shorter times and redundant setups. Setting up over the same points more than once with different receivers and tri-brachs will produce more defensible results. Measure hi's metric and feet.

Be sure to have more than one bench mark and apply the Geoid Model.

 
Posted : April 25, 2017 10:31 am
bushaxe
(@bushaxe)
Posts: 645
Member
Topic starter
 

MightyMoe, post: 425346, member: 700 wrote: The rule of thumb for static is 10 minutes plus 1 minute per mile for minimum time of observation. The idea that you need 2-4 hours is something more tied to OPUS than Static control between project control points. I would rather have shorter times and redundant setups. Setting up over the same points more than once with different receivers and tri-brachs will produce more defensible results. Measure hi's metric and feet.

Be sure to have more than one bench mark and apply the Geoid Model.

"10 minutes plus 1-minute per mile" from what? Length of traverse? Distance from CORS?

Sent from my iPhone using Tapatalk

 
Posted : April 25, 2017 10:45 am
leegreen
(@leegreen)
Posts: 2196
Supporter
 

10 minutes plus 1-minute per mile of Baseline. Distance between the occupied point and your longest vector to another occupied point or CORS in the network.

 
Posted : April 25, 2017 10:51 am