How to correct points after the fact?

Depends what processing software you use, but sure, this is something that is generally pretty easy to do.

So is this procedure PPK then?  I guess I am trying to understand the basic process of transforming those offsetted points to corrected points in relation to a known point.

Emlid Studio.  I will have to figure it out as normally just do RTK.

https://docs.emlid.com/emlid-studio/

AVERAGE SINGLE used for Base.

What exactly does "average single" mean? Is the base not collecting static while broadcasting?

I have no idea how Emlid software works. But with most other software packages, if one or more of your rover observations has a published position, it's easy enough to "back in" the base position by applying the ECEF shift between observed & published to the base position.

I'm finding good answers here that may help.. I'm trying to understand if it's even possible to go back with KNOWN POINT DATA to correct points that were collected before having this known point data or do I have to go back out and measure a known point to shift everything:

community.emlid.com/t/reasons-for-a-coordinate-mismatch-and-how-to-fix-it/35141

blog.emlid.com/simple-intro-to-accuracy-and-precision/?_gl=1*qf91vt*_ga*MTYxMzgyMzg4Ny4xNjg2MDYxNDA5*_ga_958NJK16DK*MTY5MDkwNjQ3NS40LjEuMTY5MDkwNjU0NS41NC4wLjA.

community.emlid.com/t/how-to-correct-collected-points-with-a-new-base-position/31548

Correct the base, recompute the observed points. 

There are many ways to correct the base, the best is to simultaneously collect static as you RTK points.

Process your base, then recompute.

If you need to use a located point; back in your base and then recompute. In other words if the located point is N10E, 3.52' and 2.5' lower than a known value you wish to hold for that point recalculate the base S10W 3.52' and add 2.5' to the elevation. Then recompute observed points. 

You will not move any calculated points in the file, but it should move all observed points, some software will have quirks that won't allow some types of observed points to shift such as stake-out points in Trimble. 

In the scenario you have presented you are making 3d measurements between the base and the rover. If the position of the base is amended, the endpoints of the vectors shift right along with it by an equal amount.

Similar to the problem you presented last week, I would be using StarNet to make the recalculation. You could use your CAD to shift the points as a group, using the old and new base positions. 

 If the position of the base is amended, the endpoints of the vectors shift right along with it by an equal amount.

Actually Norman I would have to say it should or perhaps more "It Depends"

It is possible to store a point as only Lat/Long or XYZ in terms of the current projection - you now have nothing to recalc with 🙁

Also calculated points based on the observed do not necessarily update

And some recalcs can only be done in the office software

Each and every software package I have ever used has it quirks. I'm struggling to think of a foolproof process that applies across all.

Theoretically, I believe calc'ing a rotation in terms of lat/long, and applying that to all points should work universally

In my experience it's important to correct the native file. If you do this in a secondary file such as AutoCad or StarNet the connection to the base point is lost. And it's very important to shift the base to the correct position going forward. Usually our GPS files are not a one-off. Even if you're only surveying for that day and don't return for the project, there is a base point with static coordinates available for nearby work and a file of observations such as property monuments. 

Ok, set up Base on arbitrary unknown point using Average SINGLE for 2 minutes. (Did not have the manual known point at the time of point collection or a CORS NTRIP point to reference).

Otherwise known as an 'autonomous position'. The base position is not corrected to any network of CORS (assuming the OP is operating in the USA). Typically position will be in the 5-15' foot error range when compared to the corrected base or geographic position (lat/long) position.

Collected FIXED points using Rover with cm accuracy between BASE and ROVER.

The assumption being that the rover collected points were receiving the correction from the base in real time, aka RTK, real time kinematic. If no correction was received, these observations would require post processing against the base data to apply a differential correction to get the desired cm accuracy. By by stating these are 'fixed' solutions, implication is these are corrected.

Obviously, all the points including base point are offset a couple of meters in every direction from actual TRUE point on the global or local grid since AVERAGE SINGLE used for Base.

Errrr. No. Not if the correction was received real time. This statement suggests that no correction was received, in which case post processing is required.

Is it possible to readjust/fix or transform all these points to where they should be in relation to a KNOWN point after the fact if I have coordinate / ellipsoid / orthometric data from a known point on public record?

Absolutely. Just translate the whole shebang over to the know point's public record values for the point you had the base on or the point you collected on the point of public record if that's what you want to do, under the assumption that they are all in the same projection. But if none of your rover collected points and vectors have been corrected to the base's location and all are otherwise just random autonomous positions, well, you've got yourself something quite a bit short of a survey. It's something of a pebble in my shoe that people rely on RTK without any knowledge of post processing that data for QC or trouble shooting. 

Good luck!

Thanks!

Absolutely. Just translate the whole shebang over to the know point's public record values for the point you had the base on or the point you collected on the point of public record if that's what you want to do, under the assumption that they are all in the same projection.

@williwaw

Nailed it!

I guess I am just having trouble understanding exactly how to get the rover points (which are cm accurate from the base) corrected/adjusted to a known point after the fact properly.  Starting with the base off by a few meters in autonomous mode obviously made this more difficult than it should be.

Next time I will try to set the base over a known point using public record data if the point is nearby to collect rover points.  No CORS or NTRIP access yet which would be a lot easier.  The known point was several miles away and usually is.  This would be simple if the known point was within the area of the survey.

I also failed to note the base's derived autonomous point (if I need to return to same base point later and manually enter that point data again, or even if this point is required to adjust?) EDIT: I see the base position was in fact recorded through the software.

I can always just start over the proper way, but was wondering if any of this is even possible for future reference.

If a known point or benchmark is several miles away, what is the typical procedure for setting a new BM for use close by without CORS or NTRIP?  Seems PPP would be off a foot or so after a long observation time and waiting period and not cm accurate?

Thanks all for the help.

If a known point or benchmark is several miles away, what is the typical procedure for setting a new BM for use close by without CORS or NTRIP?  Seems PPP would be off a foot or so after a long observation time and waiting period and not cm accurate?

PPP (or OPUS) can easily get down to the 1-2cm range with only a few hours of observation. This does require decent sky visibility i.e., don't set that base in an area with obstructions.

Starting with the base off by a few meters in autonomous mode obviously made this more difficult than it should be.

It shouldn't be difficult at all. It may just be a software issue, because almost all the post-processing programs I have worked with allow you to enter in the updated base position and then click a recompute button to shift all the vectors at the same time. Should take less than a minute after the OPUS/PPP report comes back.

The bottom line is, there's not reason to go trying to find passive marks to set your base up on unless it's required by a project. Not only are you going to burn way more time doing so, but that methodology is already more or less outdated, and will definitely be outdated once the new datums are released in 2025. Connection to, and positioning in, the modernized NSRS will only be through CORS i.e., active control as opposed to passive control.

(Now, that having been said, don't jump your base all over the place for a single project and end up with a bunch of disconnected OPUS solutions for all your control. Tie those points together if you're going to run with a network. That's what OPUS projects or post-processing software is for...)

It's simple, you need to know exactly how far off your positions are, correct the base in the software file that much. Recompute the file using the corrected base value. 

That's all there is to it. 

If you can't figure out how far off the coordinates are, nothing can help correct the values.

It is possible to store a point as only Lat/Long or XYZ in terms of the current projection - you now have nothing to recalc with

In theory, if you have coordinates of the end points in a known projection it should be possible to reverse engineer the ▲xyz vector values. Granted, nobody would ever want to do that.

Theoretically, I believe calc'ing a rotation in terms of lat/long, and applying that to all points should work universally

At least when working in North America and within a relatively small area, the rotational difference between the GPS native WGS84 and the NAD83 datum orientation is so trivial that no rotation will be necessary. It would be a translational-only amendment. Someone may correct me, but I'm not sure that there is any difference at all, rotationally.