I just want to be sure that the OPUS solutions I am getting back are in the latest realization of NAD83 (i.e. PA11) in our region/zone, which is UTM zone 5 North.
Long before the PA11 realization existed, our company has been establishing UTM control points by running static data collection with Trimble 4800 receivers and TSC1 controllers. Since the software on the TSC1 is really old, NAD83(PA11) is not an option as far as selecting a datum when I set up a job file in the controller. The default in the TSC1 is NAD1983 (CONUS) Mol. However, the OPUS solutions I get back claim to be NAD83(PA11) solutions.
We recently purchased a couple of Trimble Nomad Controllers running SurveyPro 5.3 software, which has the new PA11 realization as an option in the datum parameters. So the other day, I set up a job in the Nomad using NAD83(PA11), and set up a job in the TSC1 using NAD83(CONUS) Mol, and ran static for about 2.5 hours with each controller on the same point. The Nomad was attached to a 1st generation R8, and the TSC1 to a 4800. I was pleasantly surprised when I got the solutions back, and they were nearly identical with regards to the UTM coordinates (within 2 centimeters horizontal)!
So my question is, do the settings in your controller not matter when you are running a static survey (i.e. is OPUS able to give me an accurate PA11 solution regardless of what NAD 83 realization I select in my controller)? Or, does OPUS recognize the settings in your controller via the .dat or .T01 file, and account for the different datums/realizations when generating a solution?
This is not my area of expertise. I just want to be sure that I am getting true NAD83(PA11) solutions.
Thanks!
This is my area of expertise. And I have never heard of a PA11 realization of NAD83. Possibly you mean NAD83(2011)? In Survey Pro there are some opportunities to set up custom projections and name them anything the user wants. Sounds like maybe someone did that for you. In any event, data you collect for submission to OPUS is independent of settings in your data collector. You will need to convert your T01 files to RINEX format for submission to OPUS.
NAD83 is a datum. UTM is a projection. The terms are not synonymous.
Just a warning - if you send OPUS data that is in the right format OPUS will send you back a solution. I won't always be a good solution. Recognizing the difference isn't rocket science, but it does take some know-how. The results will be in ECEF, ITRF, NAD83(2011), and the appropriate UTM and State Plane Zones (in meters).
algallop, post: 336141, member: 8394 wrote: Or, does OPUS recognize the settings in your controller
OPUS uses the raw observed data to propagate positions from the CORS, so it doesn't matter what reference frame your controller is using.
Norman Oklahoma, post: 336146, member: 9981 wrote: This is my area of expertise. And I have never heard of a PA11 realization of NAD83. Possibly you mean NAD83(2011)?
The resulting CORS coordinates were published by NGS in September, 2011, and constitute a new realization referred to as NAD 83(2011/PA11/MA11) epoch 2010.00. The realization name has two parts: the datum tag in parentheses after NAD 83, and the epoch date in decimal years. The datum tag refers to the year the realization was completed (2011) and the tectonic plate to which the coordinates are referenced (2011 refers to the North America plate, PA11 to the Pacific plate, and MA11 to the Mariana plate).
James Fleming, post: 336152, member: 136 wrote: The resulting CORS coordinates were published by NGS in September, 2011, and constitute a new realization referred to as NAD 83(2011/PA11/MA11) epoch 2010.00. The realization name has two parts: the datum tag in parentheses after NAD 83, and the epoch date in decimal years. The datum tag refers to the year the realization was completed (2011) and the tectonic plate to which the coordinates are referenced (2011 refers to the North America plate, PA11 to the Pacific plate, and MA11 to the Mariana plate).
I have learned something new today. I was guessing the the OP was in Pennsylvania. Thanks. I suppose that OPUS would return a position in the NAD83(PA11) datum to a user on the Pacific plate then.
Jim Frame, post: 336147, member: 10 wrote: OPUS uses the raw observed data to propagate positions from the CORS, so it doesn't matter what reference frame your controller is using.
I was hoping that the raw data was not affected by the reference frame(s) on the controller, but I wasn't sure. Thanks for your help!
Simply stated... Any "rover" point is in the datum and reference frame of the "base" that it is constrained to.
Grid and ground coordinates don't exist in GPS; when you see them they are calculated values based on the underlying ECEF XYZ values. I can display coordinates any way I want on my data collector but the geodetic positions don't change.
Lee D, post: 336193, member: 7971 wrote: Grid and ground coordinates don't exist in GPS; when you see them they are calculated values based on the underlying ECEF XYZ values. I can display coordinates any way I want on my data collector but the geodetic positions don't change.
Technically, Geocentric XYZ Cartesian Coordinates (aka ECEF XYZ) ARE Ground (surface) Coordinates.
The 'vector' returned when 'inversing' two XYZ values, reflects (for all practical purposes) the same "slope distance" that one would get from a Total Station or any other EDMI (assuming intervisibility between the two points).
The direct mathematical relationship between an ECEF XYZ and a Latitude, Longitude, Ellipsoid Height (also a Ground/Surface Coordinate), is wholly dependent on the particular Ellipsoid used in the computation. We don't get into the whole Grid v. Ground Issue UNTIL "we" start transforming the Original GROUND/SURFACE Coordinate (XYZ/LLH) into some form of "projected grid coordinate system" based on a particular "developed (geometric) surface," that may or may not be a good choice for the project at hand.
Just my two bits...
Loyal
Norman Oklahoma, post: 336146, member: 9981 wrote: This is my area of expertise. And I have never heard of a PA11 realization of NAD83. Possibly you mean NAD83(2011)? In Survey Pro there are some opportunities to set up custom projections and name them anything the user wants. Sounds like maybe someone did that for you. In any event, data you collect for submission to OPUS is independent of settings in your data collector. You will need to convert your T01 files to RINEX format for submission to OPUS.
NAD83 is a datum. UTM is a projection. The terms are not synonymous.
Just a warning - if you send OPUS data that is in the right format OPUS will send you back a solution. I won't always be a good solution. Recognizing the difference isn't rocket science, but it does take some know-how. The results will be in ECEF, ITRF, NAD83(2011), and the appropriate UTM and State Plane Zones (in meters).
NAD83-PA11 is, I believe, a datum realization of the Pacific tectonic plate region (2011) - Hawaii, Samoas, etc; based on geoid99
Why would you want PA11 unless you're in Hawaii? Even in coastal California where we're technically on the Pacific Plate we still tie to the North American Plate, not the Pacific Plate, right? Is the OP located in Hawaii?
astrodanco, post: 374471, member: 7558 wrote: Why would you want PA11 unless you're in Hawaii? Even in coastal California where we're technically on the Pacific Plate we still tie to the North American Plate, not the Pacific Plate, right? Is the OP located in Hawaii?
The opening post stated that he was in UTM Zone 5 North. That sounds like Hawaii to me.
Just saying...
🙂
