Hi, I'm completely new to this forum and surveying in general. My office had a need for some surveying and it fell to me to learn how to do it, so please bear with me. I've taught myself a lot (I think) over the month and a half I've been learning but I'm sure I have a lot to know still. We have a Trimble setup of three R3 receivers with A3 antennas and Recon controllers. Post-processing is through Trimble Business Center updated to 2.70. The goal of my project is to survey some wells to within 2 cm vertical accuracy. The horizontal is not as big of a concern, but higher accuracy is always better regardless. I surveyed about 30 wells over two weeks using several monumented HARN sites as control points for the base receiver. Post-processing in the office this week, I discovered that the base receiver data gives a location for one of the HARNs sites as approx. 250 ft. southeast of the location given by the NGS data sheet I imported. Another site is given approx. 30 ft. south of where the NGS data sheet says it is. In both cases, though, the vertical difference between the observed data and the published data is within 3 ft. Is it possible the data sheets are incorrect? I don't think my antenna heights are off, and these measurements were taken on clear days (albeit a little windy) out on the open prairie with no obstructions. Plus the one that is 250 ft. off I sort of had 2 independent observations in that I had to take a break and stop the base station to change out a battery and then restart the survey, effectively creating two points. The antenna and tripod were not moved, just switched out batteries on the receiver. Both points are about 250 ft. off. Sorry for the long post, but wanted to be as detailed as possible. Any help or advice is appreciated!
I think you did something wrong.
> Hi, I'm completely new to this forum and surveying in general. My office had a need for some surveying and it fell to me to learn how to do it, so please bear with me. I've taught myself a lot (I think) over the month and a half I've been learning but I'm sure I have a lot to know still. We have a Trimble setup of three R3 receivers with A3 antennas and Recon controllers. Post-processing is through Trimble Business Center updated to 2.70. The goal of my project is to survey some wells to within 2 cm vertical accuracy. The horizontal is not as big of a concern, but higher accuracy is always better regardless. I surveyed about 30 wells over two weeks using several monumented HARN sites as control points for the base receiver. Post-processing in the office this week, I discovered that the base receiver data gives a location for one of the HARNs sites as approx. 250 ft. southeast of the location given by the NGS data sheet I imported. Another site is given approx. 30 ft. south of where the NGS data sheet says it is. In both cases, though, the vertical difference between the observed data and the published data is within 3 ft. Is it possible the data sheets are incorrect? I don't think my antenna heights are off, and these measurements were taken on clear days (albeit a little windy) out on the open prairie with no obstructions. Plus the one that is 250 ft. off I sort of had 2 independent observations in that I had to take a break and stop the base station to change out a battery and then restart the survey, effectively creating two points. The antenna and tripod were not moved, just switched out batteries on the receiver. Both points are about 250 ft. off. Sorry for the long post, but wanted to be as detailed as possible. Any help or advice is appreciated!
The data sheets represent a snap shot in time of the published position and the accuracy tolerance should be listed on said sheets accordingly. Were you Holding the coordinate values from the published sheet on your base station in your base setup or you going with one point autonomous position? If you were holding the published coordinate during your survey did you check into any other published control?
In your post processing you should be holding the published coordinates. You need to explain your field procedures a bit more to determine whats going on.
Skie
The chance that the datasheets are off as much as you indicate are about a thousand times less than the chance there is something wrong with your survey and/or computation process. I've always found FBN or CBN accuracy to be as stated on the datasheet.
> The data sheets represent a snap shot in time of the published position and the accuracy tolerance should be listed on said sheets accordingly. Were you Holding the coordinate values from the published sheet on your base station in your base setup or you going with one point autonomous position? If you were holding the published coordinate during your survey did you check into any other published control?
> In your post processing you should be holding the published coordinates. You need to explain your field procedures a bit more to determine whats going on.
Jered,
I'm not sure what you mean by holding the coordinates in the base station setup, so I'm pretty sure I didn't do that. All I did was locate the HARN point, set up the base station to start collecting data, and then went around to the wells and did fast static surveys over each of them. Then I brought it all back to the office and imported everything into TBC. The way I assumed I would process the data and correct for the inaccuracies in the base station was to merge the base station points with the point created when I imported the NGS data sheet. This was how I did it in a trial run using two HARN points, one for base and one for rover, to verify I was doing things right. When I did that (same field setup and merging the base station points with NGS data sheets in TBC), I got to within 2-3 mm of the elevations published for the HARN sites on their data sheets.
Are you sure they were all HARN ? It sounds more like you used some non-HARN elevation bench marks with scaled horizontal coordinates. Scaled means measured from an X on a topo map, and then rounded or truncated to whole seconds of lat-lon, so they are off an average of 100 ft and sometimes worse.
Getting the elevations to match is tricky because GPS doesn't inherently measure the same kind of elevation (NAVD88) that is on the data sheets, and the conversion requires more accurate gravity values than are often known. It's a complicated subject that you need to study quite deeply to understand the difference. GPS should match the X,Y,Z of a HARN data sheet, though.
GPS properly done may find the relative heights of two points to better accuracy than the absolute elevation.
Your questions indicate that you may be in way over your head. Accurate transfer of orthometric heights via GPS isn't a trivial undertaking. If you're persistent and can manage the legal aspects, you can probably pull it off, but below are some considerations that immediately come to mind:
1. Is this for internal use, or will you be passing the results along -- directly or otherwise -- to another party? There may be licensure and/or area-of-competency requirements to be met.
2. How far apart are the points (survey control and wells)?
3. Are you familiar with NOS-NGS-58 and 59? These set forth guidelines for accurate height transfer via GPS.
4. Know your geoid model and how to apply it.
5. Know your equipment and how to specify it in TBC.
6. Use fixed-height tripods! Bad antenna heights are the bane of height transfer; they can screw up otherwise good observations, and mask bad ones.
7. Good luck!
Yep, they were all HARN. They all had NGS data sheets and were posted on the South Dakota DOT map of HARN sites and level routes. I found them all as described in the data sheets. Is the method I am using for post-processing in TBC correct- importing the data sheets and merging them with the points from the base station observations? If not, how do I correct for the error in the GPS observations so that they match or closely match the HARN data? I understand that getting accurate elevations is very difficult, but I was hoping I could at least do as you said and find very accurate heights between two points, and since one of them was a HARN with a known (or at least officially published) location, I could get the elevation of the other, or even just using the NGS INTG program to get GEOID12A heights and calculate from there with the lat and long. Any suggestions on field and post-processing methods to accomplish this would be useful. I already have to go out and re-survey anyways, so I really want to do it right this time.
If you want to start on a HARN point, then setup a file in TBC with a projection (UTM, State Plane, something) and then enter the HARN points into the file with point numbers.
Then set on the point with that point number so that your survey is already attached to the HARN point. Most HARN points are a bench mark (actually all the ones I've ever used) and some are a triangulation point that is also a bench mark. Those triangulation points usually come with three other monuments that look almost exactly like the HARN point and will be described on the data sheet. You may have set up on one of the reference monuments or an azumith mark (although the azumith mark is generally farther away than 250').
TBC can be tricky-you may be using autonomous points that the receiver started itself with; however those are usually within a few meters and not 250'.
> Your questions indicate that you may be in way over your head. Accurate transfer of orthometric heights via GPS isn't a trivial undertaking. If you're persistent and can manage the legal aspects, you can probably pull it off, but below are some considerations that immediately come to mind:
>
> 1. Is this for internal use, or will you be passing the results along -- directly or otherwise -- to another party? There may be licensure and/or area-of-competency requirements to be met.
>
> 2. How far apart are the points (survey control and wells)?
>
> 3. Are you familiar with NOS-NGS-58 and 59? These set forth guidelines for accurate height transfer via GPS.
>
> 4. Know your geoid model and how to apply it.
>
> 5. Know your equipment and how to specify it in TBC.
>
> 6. Use fixed-height tripods! Bad antenna heights are the bane of height transfer; they can screw up otherwise good observations, and mask bad ones.
>
> 7. Good luck!
Jim,
I probably am in over my head at the moment, but that's why I'm here. Right now this data is for internal use, but if I can be certain it is reliable and accurate, it may eventually make it into a database for public use (I work for a state govt. agency). I tried to plan the survey so the control points are no more than 10 miles from the wells since I know that can reduce accuracy and requires longer occupation times. The furthest any well is from its control point is about 14 miles. I am not familiar with NOS-NGS-58 and 59, though I may have seen them in some of my research and self-training. The data sheets I have are in NAD83(2011) and GEOID12A, so that's what I'm using in post-processing. Specifying equipment in TBC could be an issue. For example, I'm not sure how to verify what antenna calibration is being used in processing, or how to change it. From what I understand, NGS is now using absolute calibration, but I don't know how to ensure that is what I am using. I would love to have a fixed height tripod (a couple wells on uneven ground took me 45 min- 1 hr to level the tripod), but unfortunately all we have is slid leg ones. This equipment was purchased before I started working here, and I don't know if anyone really knew how complicated and knowledge-specific it was going to be to use. I'd love to get some professional training, but there isn't time for that at the moment.
What's the PID of the one that measured so far off?
"I'd love to get some professional training, but there isn't time for that at the moment."
First, let me welcome you to this site. You will find an incredible wealth of information here, and 99% of the comments made will be in an attempt to help you. That being said, it is my opinion that you are certainly in over your head, and I'm pretty sure you know it. No time for training?! How can there not be time for training? Do your superiors have any idea how much it could cost them by forcing you to do something you don't know how to do? This is one of my pet peeves with GPS equipment. A monkey can turn it on, run around and gather data, and voila! - we have good data! Unfortunately, that's not how it works. There are a myriad of errors you can easily make. I am not suggesting that you are a monkey, but I will warn you that you can get yourself into a deep hole in no time. I have encountered national firms that have no idea what they have done for the last 10 - 15 years, and are now beginning to feel the effects, it will cost them millions to rectify, if that can even be done. If you don't know the quality of your data you will be impaired by it forever. In my state you would be practicing without a license - I presume that you have checked your state rules and think you are not. You need to find or hire someone who knows what they are doing or you are taking an incredible risk. Please be careful.
> > The data sheets represent a snap shot in time of the published position and the accuracy tolerance should be listed on said sheets accordingly. Were you Holding the coordinate values from the published sheet on your base station in your base setup or you going with one point autonomous position? If you were holding the published coordinate during your survey did you check into any other published control?
> > In your post processing you should be holding the published coordinates. You need to explain your field procedures a bit more to determine whats going on.
>
> Jered,
> I'm not sure what you mean by holding the coordinates in the base station setup, so I'm pretty sure I didn't do that. All I did was locate the HARN point, set up the base station to start collecting data, and then went around to the wells and did fast static surveys over each of them. Then I brought it all back to the office and imported everything into TBC. The way I assumed I would process the data and correct for the inaccuracies in the base station was to merge the base station points with the point created when I imported the NGS data sheet. This was how I did it in a trial run using two HARN points, one for base and one for rover, to verify I was doing things right. When I did that (same field setup and merging the base station points with NGS data sheets in TBC), I got to within 2-3 mm of the elevations published for the HARN sites on their data sheets.
"I'm not sure what you mean by holding the coordinates in the base station setup,"
No Worries. By setting up points in a job file beforehand with the published coordinates preprogrammed in, that would allow you to occupy that point and check to other published points. The way you did it by just setting up and going still works because you can simply post process with TBC holding the published values. Hand Enter in the published point in TBC and disable the field value from the collector file for that point. You can shoot me an email (listed in profile) if you have more specific questions.
I would send any observation over 2 hours in to OPUS just for a check. The OPUS elevation may not precisely match the Harn elevation but it would still be a good check.
James
> I tried to plan the survey so the control points are no more than 10 miles from the wells since I know that can reduce accuracy and requires longer occupation times. The furthest any well is from its control point is about 14 miles.
The NGS-58/59 guidelines specify 45 minutes of data for no more than 10 km lines, and I've found 1 hour to be more practical at that distance. 10 miles is about 16 km; 14 miles is about 22 km, so you're outside the guidelines right off the bat. I'd go at least 2 hours for 16 km, and 3 hours for 22 km (about 14 miles). You may be able to get by with less, but since there's no widely-accepted specification to point to, I advise erring on the side of caution.
> I am not familiar with NOS-NGS-58 and 59, though I may have seen them in some of my research and self-training.
I recommend getting familiar with them.
> For example, I'm not sure how to verify what antenna calibration is being used in processing, or how to change it. From what I understand, NGS is now using absolute calibration, but I don't know how to ensure that is what I am using.
Project Settings|Baseline Processing|General|Antenna model. You'll be able to select NGS Absolute from the drop-down menu. (P.S. I haven't found this using the ribbon interface yet. The above pertains to the classic interface.)
As a general approach to accurate GPS height transfer:
1. Set up the TBC project (units, location, geoid model, processing style, etc.) Specify a processing style that uses a fixed integer solution, NGS absolute antenna models, precise ephemerides, and a 15° elevation mask. (You may want to change the mask later, but 15° is a good place to start.)
2. Send at least one data file from each station to OPUS-S or OPUS-RS.
3. Download precise orbits. Rapid is fine; no need to wait for final unless you have the time.
4. Import all data into the TBC project.
5. Add a new coordinate to each point using the ITRF values from OPUS and mark it control quality. The purpose of this is twofold: it minimizes cumulative errors produced by observation flowout during processing, and it references the starting positions to the same reference frame as the precise orbits.
6. Disable extraneous vectors. For a small project this isn't an issue, but if you have lots of receivers running for lots of sessions, there's too much data to plow through. Weed it out into a manageable network configuration.
7. Process the remaining vectors. Look for outliers in the results (pay careful attention to antenna heights!).
8. Compare reciprocal vectors. You should have at least 2 vectors for each station pair, observed on different days with a minimum 3-hour constellation separation. See if the local vertical differences meet the desired criterion (2 cm in this case). If not, reobserve until you get a pair that do.
9. Determine orthometric height constraints. This is where knowledge, experience and luck converge, especially if you're in a dynamic area.
10. Adjust all enabled vectors. You'll probably want to constrain to NSRS2011 rather than ITRF for the horizontal values. Review the results (the knowledge and experience thing again).
11. Publish.
(This is off the top of my head, I may have left something out.)
In most states, the accuracies you are trying to obtain and then publish would be classified as "authoritative positions" and can only be performed by a licensed land surveyor. Even though you are working for a "governmental" agency, you could be classified as practicing beyond what would be considered as GIS quality data and getting into the area reserved for licensed professionals.
dliviskie,
Welcome to the site. I cannot add much to what the others have said. They have given good, solid advice.
It really sounds like you are being asked to produce control quality results, with little or no training. What you are being asked to do by your superiors, is within the realm of someone who has been practicing GPS control quality procedures for many years.
I would strongly suggest that this project be subcontracted out to a competent individual, with the stipulation that you are able to tag along and observe field procedures and post processing procedures.
It does not sound like you have the proper field equipment to achieve what you need. You mentioned that one of the locations took you 45 minutes to level the tripod. That sounds like a fixed two meter rod with bipod would have made that occupation much easier.
Please take the advice that has been offered here. The agency that you work for will benefit more from subbing this particular project out, and building a good base to work from, than you struggling through, and possibly starting out with bad data.
Good luck
ditto. practicing without a license. Hire someone with one.
Howdy,
My first thought was that the large horizontal discrepancies are due to observing the wrong monument. Monuments established in pre-GPS days included reference marks and azimuth marks. The disk clearly shows the type of monument. The designation stamped on the disk should be carefully examined as well. The NGS data sheet indicates the exact stamping and disk type.
Another concern, expressed by others, was that the monuments were NOT in fact, high accuracy points. Not all points published by NGS have high accuracy positions; some are scaled. Look at the data sheet. How was the value shown as the current position determined? Look at the horizontal and ellipsoid height accuracies published on the data sheet. If no such values are shown, it is not a HARN. If the values are more than a few centimeters, it was not well determined.
You also state an ACCURACY goal of two-centimeters in the height component. As indicated in other responses this is a quite rigorous standard. Combining different antenna types, distances to reference stations, the type of solution obtained during processing all are important. Are the occupation times sufficient for the processor to solve for the integer unknowns? Are there multi-path issues at sites? Are antennas and the antenna reference point height correctly identified/determined? Once again, was the correct monument occupied.
If you have any concerns about your processing, you should submit data to an automated GPS processing tool. OPUS-RS is best for short occupation times. If you are unable to get good agreement with OPUS-RS in your processing something is wrong. Unlike commercial processors, the NGS OPUS an OPUS-RS and other tools like AUSPOS, AAPS, GAMIT, GAPS and CSRS-PPP apply models not included in the commercial tools. The packages listed are also rigorously documented and compared against one another.
In closing, I recommend that you examine the data sheets for the points you used. Read the associated file DSDATA.TXT for an explanation of all entries on the data sheet. As for your GPS processing software, process their sample data set and see how close you can repeat their results. Alternatively, submit your data to an automated processing tool and likewise process the same data and see how close your results are to the tool's. Careful attention to detail is essential. Carefully record antenna model numbers. Carefully note (and photograph for future reference) the disk of the point you observe. Does the type of disk, setting and stamping agree with the data sheet.
Processing tool links:
OPUS GPS processing tool - NGS processors OPUS (static) and OPUS-RS (rapid static).
SCOUT GPS processing tool - Scripps Institution of Oceanography (UCSD) upload data via ftp then choose file via a webpage
http://csrc.ucsd.edu/cgi-bin/SCOUT.cgi
AUSPOS GPS processing tool - Australian processor using web-based form for input
http://www.geod.nrcan.gc.ca/products-produits/ppp_e.php - Online Global GPS Processing Service (CSRS-PPP) of Geodetic Survey Division of Canada
http://apps.gdgps.net/apps_file_upload.php - NASA GDGPS processing tool. Results returned immediately after file uploaded.
http://gaps.gge.unb.ca/ - University of New Brunswick's GAPS (GPS Analysis and Processing Software)
Hope this helps,
DMM
Export each file as a rinex and submit to either OPUS-S (if you have two hours) or OPUS-RS (if you have at least 20 minutes). Just be careful to input the HI and antenna type carefully. This will give you and independent check and take things outside of your processing environment.
Okay, now lets process in TGO.
Create a project with no data nor datasheets. Insure the projection settings, AND units match the data sheets for the HARN monuments. Big difference in US Survey feet or International feet. Lot's of small , but important gotcha's.
Then create points, by hand, for each HARN point and fix them X,Y (horizontal). Most of the HARNS I've used do not have the vertical but if you do then fix the vertical as well. I usually input the ellipsoid for the HARNS (and make sure you have ellipsoid heights set in the project settings). Make sure you are using a GEOID model, whis is often not the default and sometimes you will need to download and install a GEOID model in software that has not used one before.
Then you can toggle the software to show computed verticals (ortho).
Download your files one at a time, carefully checking your HI's, antenna type and NAME. Make the name the same as the point fixed in your project for each HARN occupation.
Then process the vectors. Check the stats of each line.
Then adjust and it should all come together.
That's my basic take and there are a multitude of other things that experience has me doing when processing points. I don't like single vector baselines and would also download several CORS files to give you more of a network to each point.
Even with hours of data then a single line to a point still is not much better than a RTK vector, in my opinion. It's better, for sure, but gives you very little confidence. Especially since you clearly are new to the game. You need a lot of extra checks to help build confidence in your software and your methods.
Deral