Base Point Mismatch

[Joe Paulin]

Team,

After talking to Shawn, he is having me send my project for you to take a look at. My issue is that J-Field won't base process rover points that I collected static data on because for some reason the base position listed in the rover point data is very slightly different (4th decimal place) than the base point coordinates used during base/rover setup. There are a lot of points in this file - what I am concerned about is base point 502, rover point 379.

Let me know what else I can provide, project already sent to support - LS397, Paulin Survey

My work flow for points concerned: Point 500 entered as design with OPUS state plane coordinates.
Day 1: Base/Rover setup - Base point 500 selected from list, new base point created for day was 503, known coordinate. Collected points 321-359.

Day 2: Base/Rover setup - Base point 500 selected from list, new base point created for day was 502, known coordinate. Collected points 376-391.

I have been unable to base process any rover points that have static data associated for either day.

This point 379 isn't critical for me, my concern is more procedural - why are the base coordinates slightly different, why isn't it working?

Also, for the point ranges listed above, that were located using a known base point, in the point screen they are shown as AU in the fourth column. Should this rather be KN as these were shot from a known base?

Thanks for looking into this for me, let me know if you need more information. Thanks!

 

[Nate The Surveyor]

Just one question... did "it" just up and do this, or did you click in the field, or area of the ls, and enter any of those coord values manually?

 

[Joe Paulin]

Hi Nate,

On this job, I already had good OPUS derived control on site, so the only thing I entered manually was that existing point, 500, as a design point.

When I set up the base both days, in the base/rover setup I selected this point 500 by "list". Then J-Field stores a new base point for that setup. These two points are identical. However looking at the surveyed rover points, when I bring up the point details (all the statistics) it is here that the base points coordinates differ in the fourth decimal place and since they differ I think that is why I am unable to base process the rover points.

So to answer your question, I think "it" did this, not me. The main question is why.

 

[Michael Stazhkov]

Also, for the point ranges listed above, that were located using a known base point, in the point screen they are shown as AU in the fourth column. Should this rather be KN as these were shot from a known base?

Yes, this should be KN, but due to the same bug these points do not know their base and it's type. The bug is related to coordinate system transformation and I think will be fixed next week.

 

[Joe Paulin]

Thanks for the update Michael. If I change the base coordinates assigned to the rover point to match the base point exactly, do you think the base processing will work or is it a bigger issue than that?

 

[Michael Stazhkov]

Thanks for the update Michael. If I change the base coordinates assigned to the rover point to match the base point exactly, do you think the base processing will work or is it a bigger issue than that?

Acctually coordinates recorded in database are OK. The only reason is how J-Field compares the coordinates recorded in different coordinate systems and with different reference epoch time. So it is better not to change your data and wait for fix.

 

[Joe Paulin]

Thanks, will do.

 

[Vladimir Prasolov]

Hi Joe,
I'm investigating the issue.

• I found the project is based on static (NOT HTDP) coordinate transformation for Ohio North SPCS, also the default WGS84(ITRF2008) was selected manually as identical transformation. For USA users I would strongly recommend to use NGS HTDP transformation for correct managing epochs, especially when DPOS/OPUS is used. When project is creating then WGS84(ITRF2008) is set automatically to use HTDP. When SPCS is selected the HTDP is set by default except the case when geoid is selected. In current version HTDP transformation should be selected manually after geoid selection (it will be fixed soon). It is important due to default epoch for NAD83(2011) is 2010.0. Without HTDP it is impossible to work with currently processed data near epoch 2016.5. The time gap is too big.

• Regarding the project you sent us, we will try to fix it and return to you.

 

[Joe Paulin]

Vladimir,
Thanks for checking into this for me. Going forward, I will be sure to check that HTDP is selected after I select the geoid to be used. In your screenshot above, the "Input Ecoch" is selected and listed as 2010.0.
If I create a new job in the LS and select the Ohio State Plane North Zone from the list, after selecting the geoid and changing to HTDP, my screen shows "Current Epoch" with 2016.58644 listed. Is this ok?

 

[Vladimir Prasolov]

Vladimir,
Thanks for checking into this for me. Going forward, I will be sure to check that HTDP is selected after I select the geoid to be used. In your screenshot above, the "Input Ecoch" is selected and listed as 2010.0.
If I create a new job in the LS and select the Ohio State Plane North Zone from the list, after selecting the geoid and changing to HTDP, my screen shows "Current Epoch" with 2016.58644 listed. Is this ok?

Hi Joe,
Please click "Current Epoch" (it will toggle to "Input Epoch") and input 2010. Current test version does that automatically.

 

[Joe Paulin]

Will do.
How will this affect all of the work that I have done in the past on this job and other jobs as I had no knowlegde in the past that this needed to be done?

 

[Joe Paulin]

Could someone educate me on HTDP and Input/Actual Epoch so that I may understand more clearly?

Thanks for your time.

 

[Adam]

Joe, this is how Shawn explained it to me some time back.


The North American plate is moving slowly relative to the Earth poles. NGS treats the North American Plate as fixed. This means that the transformation parameters must change from NAD83 to the Earth (WGS84). There are 14 parameters: dX, dY, dZ, rotX, rotY, rotZ, dScale and rates for parameter.

These parameters treat the entire continent as homogenous, that California is moving at the same rate as Georgia. This assumption is ok, but we know through the CORS that different parts of the plate move in different directions and at different rates. Think of a boat floating across the lake. The whole boat moves, but you can feel it torque and twist as the external forces of the waves act on it. Treating all points on the boat as homogenous is a functional assumption, but to get more precision, we might model how the different parts of the boat move independently of each other, as well as how the boat moves as a hole. HTDP does this on a continental scale. NGS still applies the 14 parameter shift to determine where NAD83 is relative to WGS84 at a particular moment in time, but it also applies regional velocities determined from long term CORS observations. Today, when OPUS provides us with a position, it actually processes all of the vectors in WGS84 (ITRF2008) and adjusts the vectors to determine the position of the user. It then uses HTDP to determine the NAD83 position at epoch 2010.

Users in the United States should (unless there is reason to do otherwise) use HTDP as the transformation from WGS84 to NAD83 and should use an epoch date of 2010 as this is the current official epoch of NAD83(2011).

 

[Sean Joyce]

Will do.
How will this affect all of the work that I have done in the past on this job and other jobs as I had no knowlegde in the past that this needed to be done?

We still need the question answered as to the effect on work we have done. I am currently setting the epoch manually but before I and I think many of us just set the Geoid with the current epoch and surveyed. What happens when we revisit a job?

 

[Adam]

You can test this with the LS Sean, just go change the coordinate system epoch date and look at coordinates. I looked and compared at my house it's not much.

 

[Sean Joyce]

thanks Adam
actually I have done changed the epoch and gone back to a job and noticed no real difference but I will look at the list like you said.

 

[Joe Paulin]

Thanks for the explanation - this helps me. Again, so that I understand correctly, the HDTP setting and Epoch date setting will be defaulted to HDTP and 2010.0 in the next software release? This isn't something that end users would want to set each time (even though I enjoy learning about this!)

 

[Joe Paulin]

Phew, I'm glad I work in boring ol Ohio...not much movement in the last six years!

 

[Joe Paulin]

So just changing the epoch date from 2016.5871 to 2010.0 results in a change of one of my coordinates (Stark County for the Ohioans here) as follows (rounding to the nearest hundredth):
N:+0.02'
E:-0.04'
Elev:+0.02'

It's not huge, but enough that I want it to be right from here on out.
What that means for me is paying attention to the epoch date from here on out. The good thing is with how J-Field handles things, I can always open up old jobs, check the epoch date, change if necessary and re-export if needed.

 

[Matt Johnson]

Thanks for the explanation - this helps me. Again, so that I understand correctly, the HDTP setting and Epoch date setting will be defaulted to HDTP and 2010.0 in the next software release? This isn't something that end users would want to set each time (even though I enjoy learning about this!)

Yes these will be the defaults. The same state plane coordinate system can be used for many projects so it only needs to be setup once.