> > I always collect data for OPUS but many times I have to start work with a here position and correct it after the fact. The closer I can get the here position the better.
>
> The rule of thumb I recall is that a 10-meter error in base position introduces a 1 ppm error in the vectors. Even a cheap WAAS-corrected handheld should be able to do better than that, often by a factor of 5. Given the other error sources inherent in the RTK approach, I wouldn't think that 1 ppm would be much of a problem.
Thanks. That was not really my issue though. I am staking out points. For what I am doing it is not the end of the world if they are not placed exactly where we wanted them as long as we know they are. For example my client may tell me to drill holes starting at X,Y and then every 100' along a NS line. If I use a here base position I may have the whole grid of holes shifted 5-10' from where they want them but it isn't a huge problem as long as I provide the true coordinates of where I drilled them which is easily doable via opus. I just am looking for ways to try and get my here position closer to the true position.
Of course we both know they work. My point was our experiences differ. I would guess the primary reason is location. Here in the northwest I find the conversions usually work well. As this world gets smaller we need to remember not to grab on to local results and typical numbers too hard. It can hamstring you if you find yourself in a different place...
Well, I guess defining "work" for me would be that using the conversion for say a HARN point set on a NAD27 monument would produce the NAD27 value, which it will not do.
I went through this for a FAA project long before getting GPS, the published numbers on monuments onsite would not match CORPSCON conversions, went round and round about it, finally me and the engineer actually discussed it with people who developed NAD83 and they said there is no conversion possible between the two systems so there was a rubber sheet file created.
So for survey value numbers I want surveyed points, not converted points, its' harder but that's why people hire me. Now for mapping quality numbers, the conversions are ok, sometimes not great, but usually ok.
If someone at NGS told you that NADCON was rubbersheeting they didn't know anything about the program. NAD 27 had significant amounts of regional distortion most of which was removed by the original NAD 83 adjustment - that being said every station in a given area had didn't levels of distortion. The process used in NADCON is to created two sets of grids one for changes in latitude and one for changes in longitude. Then the utility that creates the grids looks at all the geodetic control in the country and determines through a least squares process the most likely value for the positional change at each grid node (in the lower 48 that's every 15'). The control closest to the grid node would have the greatest influence and the further away another station was the less influence it has. Even though virtually all of the original NAD 27 station participated in the grid development it's still a model or a best fit and you will never match the original NAD 27 values exactly. The only way to match original values is to either use NAD 27 values in the adjustment, in which case the old distortions will rapidly appear in the adjustment or in the case of an older survey readjust it using the original observations.
Unfortunately all of the GPS receivers also have the transformations developed by what was then the Defense Mapping Agencey (DMA) and they are at best horrible (+/- 7 to 10m). For those that consider WAGS 84 and the original NAD 83 to be the same and use these transformation to get back to NAD 27 the results can be really stinky.
herman cain time
I do not have the facts to back this up, but.... I think you have the data you seek.
At the time in the survey when the base station fixes it's , record the LLH. Send a couple of hours and test it to see if it works. Test under similar conditions to your normal work
1 Locate the base via autonomous position
2 record the LLH
3 collect a set of rtk positions
4 stop the survey
for the test to work properly there probably needs to be enough time between the setups for the constellation to have changed in a meaningful fashion.
1 locate the base using the previous LLH
2 collect the same set
3 compare these values with the previous values
The autonomous position is an accurate position, but the question is what datum do you want to use. Opus is the best bet. It also affords a check on you base station location.
If someone at NGS told you that NADCON was rubbersheeting they didn't know anything about the program. NAD 27 had significant amounts of regional distortion most of which was removed by the original NAD 83 adjustment - that being said every station in a given area had didn't levels of distortion. The process used in NADCON is to created two sets of grids one for changes in latitude and one for changes in longitude. Then the utility that creates the grids looks at all the geodetic control in the country and determines through a least squares process the most likely value for the positional change at each grid node (in the lower 48 that's every 15'). The control closest to the grid node would have the greatest influence and the further away another station was the less influence it has. Even though virtually all of the original NAD 27 station participated in the grid development it's still a model or a best fit and you will never match the original NAD 27 values exactly. The only way to match original values is to either use NAD 27 values in the adjustment, in which case the old distortions will rapidly appear in the adjustment or in the case of an older survey readjust it using the original observations.
Yes this is exactly what they told me, rubbersheeting is my word for a more complex calculation, but don't really know a better one word description for it. It was really quickly obvious that the conversions weren't good enough to use from a surveying perspective. To get 27 data it was necessary to survey in 27, not survey in 83 and convert. It was very important to me back in the day to have 27 numbers and still today it is at times.
There are mine projects in NAD27 that CAN'T be converted because of permitting issues, and there are older DOT projects that pop up at times. Also oil & gas data is often on 27, now that's usually not real accurate and more mapping grade anyway.
My point is that as the NGS told me is there is no real calculation between the systems. And the conversion program WILL NOT give a 27 number.
As Dave said, the transformations in NADCON are the best available, but not good enough for survey. If I want good NAD27, I tie in NAD27 stations and do an adjusttment.
I recently looked at 4 first order triangulation stations in Montana. None of these has ever been GPS'd, but they do of course have NAD27, NAD83(86), and NAD83(92) coordinates.
The NADCON shifts (HARN-27) had a range of 1.151 m in northing and 1.127 m in easting, with standard deviations of 0.52 m and 0.51 m. MUCH larger than I would have expected for a given area. I don't have a triangulation diagram for that area, but there must be some bias in the NAD27 that wasn't there in the NAD83 adjustment.
As Dave said, the transformations in NADCON are the best available, but not good enough for survey. If I want good NAD27, I tie in NAD27 stations and do an adjusttment.
Exactly!!!
There are HARN points on tri stations out here, but mostly they occupied first order bench marks
I should add that I am more accustomed to seeing an accuracy of 0.15 m in the NADCON transformation here in the east (western PA).
I started doing GPS before NAD83(86) was released, NAD27 was all that we had to work with for control (and of course no CORS or HARN conveniently located along the highway). I did a lot of adjustments of NAD27 GPS networks, I would always solve for scale and azimuth bias, which could get quite large, relatively speaking. And of course back then there was no geoid model. We had to model the geoid by tying in benchmarks around the project, and computing tilts, sometimes various sets of tilts if the project was extensive or in an area of disturbed geoid. I would compute tilts, and then compare against astro stations in the area. Ya'll have it so easy nowadays..............
What NADCON does give is an approximation of the 27 values. My point is those values vary in quality and fitness for various purposes. I use them on 1A certificates once I've proven they meet the standard. I use them to align FIRM panels as well. They are also handy for search values when attempting to recover points from differing maps and eras. The fact they aren't perfect does not make them useless...
You are right, they are fine for most mapping. Just not for surveying. Although, since NADCON is "approved" (in the Federal register) as the official transformation, it can and has been used to transform points for survey if properly understood. In my example above I would definitely not due to the 1+ m floating around, but in a small area the shifts are liable to be fairly constant, and would probably match local control quite well if that local control came off of NSRS stations.
What NADCON does give is an approximation of the 27 values. My point is those values vary in quality and fitness for various purposes
We are on the same page, the numbers are an approximation, and even the disclaimer on the corpscon page highlights that they are. From memory I think they state something like to expect .17m of "error". That is pretty close to what I see on monuments that are near HARN points, but in other areas I see larger numbers up to 1.5m. So from what I've seen .17m is an optimistic number. But mileage probably varies. It's not that I have a problem with the product, it's just that I want users to understand what it is giving you. It's of course easy to check them, a no-brainer really, as it's easy to check what geoid models are doing in the area
NAD83(2011)-CLARIFICATION
A clarification is in order. I misspoke. What I meant to say was that the shifts from NAD27 to NAD83(86) had a range of 1+ meters (1.206 m N, 1.466 m E, stdev=0.53 m N, 0.630 m E). This to me indicates something seriously wrong with the NAD27 coordinates, not sure at all why the shifts varied so much. In the old days (until last year), I was able to extract observations from the NGS database and see what had changed or been added between the adjustments (new baseline, EDM, laplace station, etc). IT security eliminated that very valuable (to me) function.
I would be very leery of using the NAD27 values for these stations, because those 1+m distortions have to go somewhere.
NADCON does a very good job of fitting to these stations, because these stations were used to create the NADCON grid. However, that 1+m bias/distortion is still in there.
It should be noted that NADCON will agree very well with strong stations in the NSRS, for example first order triangulation. However, if one uses a USGS 3rd order station that is 30 miles from an NGS first order station, you could conceivably get 15+ feet of error (30 X 5280 X 0.0001). I have seen just such a problem around here. Similarly, USFS, or USCE, or DOT or other work may not fit the NADCON model well at all, because the NADCON model is based on NSRS stations which have NAD27 and NAD83. A USGS third order transit traverse would not be expected to be as close. It all depends on how well the other agencies works fits the higher order NGS control.
I'm using an R6-2 rover & TSC3 w/Trimble Access on the Western Data Systems VRS network, which broadcasts NAD83(2011) adjustments. I've downloaded, and can use, the Geoid12A file, but if I wanted to use a stand-alone base, where can I download the NAD83(2011) datum file? My TSC3 currently only has the NAD83(Conus)(Mol).
Thanks in advance for your help.
Really don’t want to revive the conversation about NAD27 (from my POV it had nothing to do with the original question), but I would like to ask everyone why Trimble doesn’t just use EPSG codes to identify the data collector’s coordinate system (like the rest of the geospatial world)… I think this very simple solution would help all surveyors make quick decisions about what coordinate system they would like their data collector to use to calculate reduced positions.
I could be off base here, but the OP was probably just asking: “which coordinate system do I set the data collector to if I want to see and export reduced NAD83(2011) coordinates?”
Well, the answer should be, set your data collector to EPSG:6318. One and done (and of course, set your base on a known NAD83(2011) control point so it all actually makes sense). At that point, we would rely on Trimble ACCESS to apply the proper geodetic transformations to get out of whatever flavor of WGS84 it actually collects in (imho, I SHOULD be able to easily state which one TA uses to collect all my GPS data.. I should be able to see Source and Destination EPSG codes, like Source EPSG:9754 and Destination EPSG:6318 - this way, I could verify that the little black box was at least telling me what I wanted to hear).
Instead, Trimble decided to riff off of what Autocad did, and they made their own barely legible, coded, provincial phrases that nobody really understands (if they were easy, someone on this thread would have said, set all the option like “this” to have Trimble ACCESS calculate/reduce NAD83(2011) coordinates.
If anyone reads this and can also provide an explanation for why Trimble thought it important for me to have access to 30 different Zimbabwean coordinate systems, I’m all ears. I generally don’t ask permission to route through the data collector’s file system, but I’m very tempted to find and delete all the geoids and coordinate system definitions in Azerbaijan and Finland that make absolutely no sense for me to have on my data collector out here in California.
If you’re wondering, I’m ranting because I’m trying to use the RTN method for collecting GPSonBM data, but of course the NAD83(PA2011) definition is the ONE definition that is apparently missing on the data collector… but I could survey in Tajikistan no problem! (although, having read thru the posts, I’m now nervous that if I found the NAD83(PA2011) definition and loaded it, TA has a bug that will double transform? Wtf?..good thing I’m volunteering me time to sort all this BS out.
@fugarewe you do not have to delete them those datums and coordinate systems that you will not use. Trimble sells equipment world wide so from a business side it is easier to have everything. You can handle this by making yourself a custom template that allows you to to choose just what you need to use. Or you can replace the coordinate system cnfig file with just what you want. Easily done. So if you only work in conus in one state you can do that. But hey i know a regular surveyor who works outside of conus and i imagine he is happy he has what he needs.
Now WGS84 I doubt anyone other than a few specific people are actually working in WGS84 in a “Survey Grade” arena. It use to drive me nuts when I would have a client come to me and say hey i have been asked to do this project in WGS84. I usually laugh because the firs question i have for the person asking my client to do this is. Which One. 2nd question is do you have a Need to Know. Truly if you so desire to work in wgs84 your really need to post process using the ephemeris. Not the one from NGS or whoever is doing that now days. The one from NGA. and you will have to understand the differences in those different ephemera to do it correctly. Or a known monument and good luck with getting that data. Now we all know that wgs84 and igs are moving closer together. The NAD83 grs80 ellipsoid not being geocentric to the center of the earth as the wgs84 (wgs84 ellipsoid). Throws a little bit of a wrench in that. But we do see hope with the new datum coming down the pipe. Now wgs84 confuses some because it is a system of systems. Wgs84 the reference frame datum. Wgs84 the ellipsoid whereas wgs84 the ellipsoid is very close to the size and shape of what we use in nad83 which is grs80. However there location is not the same.
someone else stated it very well wgs84 is fixed or realized through the monitoring stations around the world. Whereas nad83 to points on the North American plate. This stations you can see for yourself on gps.gov. You have NGA stations and airforce stations. You can kinda look at them as cors stations on steroids if you will. So many things go into the gps satellite so we all can benefit from it. Trust me lots of man hours and parts. But we as surveyors might be one of the smallest percentage of end users. PNT is a real thing and we we reap the rewards of those who work many hours continuously monitoring and analyzing and improving that system.
A quote I heard and i might not have this exactly correct but we can not perform transformations forever and think we can maintain that accuracy . I believe the new datum was long overdue and i am tickled to death to see velocities and geocentric and a geopotential system being implemented. It is the beginning of a new era and will come with some challenges and some re thinking and educating on our parts to use correctly. But we have a tremendous base of knowledge already so it should be fun.
Most surveyors don't know and/or don't care about EPSG codes. I wouldn't be able to tell you what the various codes are for the various NAD83 realizations, and I go back and forth pretty regularly in both survey and GIS products.
If anyone reads this and can also provide an explanation for why Trimble thought it important for me to have access to 30 different Zimbabwean coordinate systems, I’m all ears. I generally don’t ask permission to route through the data collector’s file system, but I’m very tempted to find and delete all the geoids and coordinate system definitions in Azerbaijan and Finland that make absolutely no sense for me to have on my data collector out here in California.
Trimble is a global geospatial provider. They don't know where you're going to survey.
In any case, the ability to customize the systems has always been available. It's not a complicated process and only needs to be modified rarely.
If you’re wondering, I’m ranting because I’m trying to use the RTN method for collecting GPSonBM data, but of course the NAD83(PA2011) definition is the ONE definition that is apparently missing on the data collector…
Are you trying to transform on the fly from ITRF2020 to NAD83(PA2011)? Unless you are attempting to do a datum transformation between global and local before projecting, all you need to do is select NAD83 and then input whatever LLH you need for your base.
As far as the RTN goes, what datum does it broadcast? I don't think I have ever seen one broadcast a datum that does not match the area being covered.
So if your RTN is on NAD83(PA2011), you would simply select US/NAD83 and whatever projection you need, and then you're good to go.
all you need to do is select NAD83
Ok, so if the OP was in fact curious about how to get Trimble ACCESS running on a TSC3 to show reduced NAD83(2011) coordinates on the screen, and to also export those reduced coordinates to a file… all you have to do is select NAD83?
Is that because the underlying parameters in the datum definition haven’t actually changed? Assuming we’re set up on control with published NAD83(2011) values, how does ACCESS know how to generate the correct coordinates that match the NAD83(2011) adjustment?
In other words, I can’t tell if you’re saying that ACCESS’s parameters for “NAD83” datum haven’t ever changed, so that’s why it’s ok to have such a generic name, or if you’re saying that they do get updated by Trimble, and we just have to know that when ACCESS says NAD83, it means NAD83(2011)… that seems really weird. Would it do the same if I wanted to survey in 1991.35 (a not un-common realization for around here)? Would I just need a RTN service broadcasting 1991.35 corrections?
A survey-grade GNSS (Global Navigation Satellite System) receiver determines the position of a point on the Earth's surface by receiving signals from multiple satellites and processing them to calculate precise coordinates. When it comes to datums like NAD83 (North American Datum 1983), there are different realizations or versions of the datum that have been established over time to account for the Earth's changing shape and improved surveying techniques.
To distinguish between NAD83 (2011) and other NAD83 realizations, a survey-grade GNSS receiver relies on the metadata embedded in the navigation message broadcast by the GNSS satellites. This metadata includes information about the reference frame and datum being used. The receiver interprets this information to determine the specific datum realization being used for the transmitted coordinates.
When configuring a survey-grade GNSS receiver, the user typically selects the desired datum or reference frame for their project or region. This selection ensures that the receiver applies the appropriate transformation parameters to convert the GNSS-derived positions to the specified datum. For example, if the user wants to work with NAD83 (2011), they would select that specific datum in the receiver's settings.
By correctly configuring the receiver to the desired datum, it can calculate positions that align with the specified reference frame, such as NAD83 (2011). This ensures that the collected survey data is consistent with the chosen datum and can be seamlessly integrated with other data sets that use the same reference frame.
Yes, real-time networks (RTNs) typically apply transformation parameters before broadcasting the data to receivers. RTNs consist of a network of continuously operating reference stations (CORS) that are equipped with GNSS receivers and are strategically located to provide coverage over a specific geographic area.
When a GNSS receiver connects to an RTN, it receives real-time correction data that improves the accuracy of its position solution. These corrections are necessary because factors such as atmospheric delays and errors in satellite orbits and clocks can affect the accuracy of GNSS measurements.
Part of the correction process involves applying transformation parameters to convert the raw GNSS data collected by the CORS stations to a consistent reference frame or datum. This ensures that all positions obtained from the RTN are in a standardized coordinate system.
The transformation parameters are typically determined through extensive surveying and geodetic analysis. They take into account the differences between the datum used by the GNSS system (such as WGS84) and the desired reference frame (e.g., NAD83). By applying these transformation parameters to the GNSS observations collected at the CORS stations, the data can be corrected to align with the specified reference frame.
Once the transformation parameters have been applied, the corrected data is broadcasted by the RTN to the GNSS receivers. The receivers can then use this corrected data, along with their own measurements, to calculate more accurate and consistent positions relative to the specified reference frame.
GNSS (Global Navigation Satellite System) manufacturers do not typically display the EPSG (European Petroleum Survey Group) designation or specific coordinate system information directly on their devices or interfaces for a few reasons:
-
User Familiarity: GNSS receivers are designed to be user-friendly and accessible to a wide range of users, including those who may not have a deep understanding of geodetic systems and coordinate reference frames. Displaying EPSG designations or technical details might overwhelm or confuse the average user, leading to a less intuitive user experience.
-
Simplified Interfaces: GNSS manufacturers often prioritize simplicity and ease of use in their device interfaces. Displaying detailed coordinate system information can clutter the interface and may not be relevant or necessary for many users who simply need accurate positioning information.
-
Standardized Outputs: GNSS receivers generally provide positions in a standardized format, such as latitude and longitude in decimal degrees or Universal Transverse Mercator (UTM) coordinates. These standardized outputs allow users to integrate the GNSS data into various applications and systems without explicitly needing to know the specific coordinate reference frame used by the receiver.
-
Automatic Datum Transformations: Many GNSS receivers can automatically handle datum transformations and coordinate conversions internally, without requiring users to manually select or configure a specific EPSG designation. By utilizing algorithms and built-in geodetic models, the receivers can provide positions in a desired reference frame, regardless of the GNSS datum being used.
While the specific EPSG designation may not be displayed on the device, GNSS manufacturers typically provide documentation or software tools that allow advanced users to configure the receiver for specific coordinate reference frames or perform custom transformations if needed.
To distinguish between NAD83 (2011) and other NAD83 realizations, a survey-grade GNSS receiver relies on the metadata embedded in the navigation message broadcast by the GNSS satellites.
I think false.
This may be true for RTK systems but not the satellites. The GPS system doesn't even know NAD83 exists, and works in WGS84(realization week number). Your equipment must convert to NAD if you want that.
I could ask a clarifying question, but I think that ChatGPT means the ITRF or whatever that the satellites broadcast. The GNSS has the NAD stuff, but it needs to know the basis for the XYZ coordinates from the satellites in order to to apply it.