If RTK is the live correction on the controller and PPK is that correction applied after you land, PPP and OPUS answer a different field problem: how do you get a known point when you never occupied a monument and you do not run your own base network?
PPP stands for Precise Point Positioning. OPUS is the National Geodetic Survey’s Online Positioning User Service. In practice, you log survey-grade GNSS observations, submit them after the flight, and use the returned coordinates to place a base, GCP, or checkpoint in the National Spatial Reference System (NSRS) — without a live radio, an NTRIP caster, or a CORS pull you process yourself.
Pilot Ledger is ops and CRM for commercial pilots, not a GNSS engine. This is the field explanation of what those services are doing when the job has no local monument and no RTK network of your own. For live corrections, read What Is RTK? Drone Mapping Explained. For post-processed corrections against a base or CORS log, read What Is PPK? Drone Mapping After the Flight.
Where PPP and OPUS sit next to RTK and PPK
RTK, PPK, PPP, and OPUS get stacked in sales decks as if they were four flavors of the same button. They are not.
RTK applies corrections while you fly. The rover hears a local base or an NTRIP stream and shows Fixed or Float on site.
PPK applies the same kinematic idea after the flight. The rover log is combined with a base or CORS log that covers the same time window. You learn Fixed versus Float in the processing report.
PPP estimates a precise position for a single receiver using precise satellite orbits and clocks, without a nearby base you own. The receiver still has to log usable observations. The service still has to return a solution you trust.
OPUS is NGS’s free web service for computing high-accuracy NSRS coordinates from survey-grade GNSS files you upload. For mapping pilots, the common use is not “fly OPUS on every photo.” It is: occupy a point long enough for a solid static solution, submit that log, and treat the returned coordinate as your known point for the job.
In short: RTK and PPK correct the rover relative to a reference. PPP and OPUS help you establish or refine that reference when you do not already hold a known monument or a network you control.
What PPP means in plain English
Raw single-receiver GNSS is usually good to meters. Mapping clients who overlay your ortho on a civil set do not want meters.
A second receiver (a base) is the classic fix: RTK or PPK uses that shared view to tighten the rover. PPP takes a different path. Instead of differencing against a nearby base you set, the processor uses precise orbit and clock products published for the constellation. One well-logged receiver can be positioned much tighter than the raw meter-level solution — after the session, not while you watch Fixed on a controller.
That is why PPP shows up on remote sites and days when NTRIP is unavailable and you never set a tripod on a known monument. Occupation length, multipath, antenna model, and constellation mix still decide whether the solution is usable. The field idea across services: one receiver, precise products, post-processed absolute position.
What OPUS is (and what pilots actually use it for)
OPUS is NGS’s Online Positioning User Service. You upload a GNSS file from a survey-grade receiver. OPUS processes it against the NOAA CORS Network and related NGS software, then emails a position in the NSRS.
The practical pilot pattern:
- Set a local GNSS base on an unknown but stable point (open sky, measured antenna height, logging for the whole sortie).
- Fly RTK or PPK relative to that base so the map holds together tightly relative to the base.
- After the flight, convert the base log (often to RINEX), submit it with the correct antenna type and height, and wait for the solution.
- Apply the OPUS coordinate — and the datum / epoch the report specifies — as the known position of that base, then reprocess or adjust so absolute placement matches.
That is the “known point without your own base network” story: your temporary base becomes known after OPUS, not because you occupied a brass disk before takeoff. Short noisy occupations, wrong antenna models, and non-survey-grade files do not become survey coordinates because the upload button worked. Read the quality notes the same way you would read Fixed versus Float in a PPK report.
What PPP / OPUS is good for — and what it is not
Good fits: a known coordinate for a temporary base on an arbitrary stable point; NSRS coordinates for GCPs or checkpoints occupied long enough with a survey-grade receiver; remote sites where NTRIP is weak; repeat jobs where absolute consistency over time matters. They place control in a national frame. They are not a different brand of photogrammetry.
What they are not:
- Not a survey license. A clean report does not authorize you to stamp a boundary or replace a licensed surveyor where the job requires one. It returns a coordinate estimate from GNSS processing.
- Not a free pass on GCPs and checkpoints. Many deliverables still need independent check shots you did not use to steer the solution. Absolute accuracy is where the map sits on the Earth; relative accuracy is how well the map holds together. PPP/OPUS can help absolute placement. They do not certify either by themselves.
- Not RTK while you fly. You will not get live Fixed from OPUS mid-sortie.
- Not a fix for missing logs. Wrong antenna height or type, or no usable observations, means nothing honest to submit.
- Not automatic datum matching. Align the report’s frame and epoch to the client’s drawing set before you call the overlay done.
Practical pilot workflow after the flight
1. Log on purpose. Confirm the base or static control receiver is logging raw observations, not only writing a geotag. Measure and record antenna height and type.
2. Fly the relative job. Use RTK if the live link holds. Use PPK if you need post-processed kinematic correction against that base or a CORS log. PPP/OPUS tell you where the reference sat; they do not replace that relative path for every photo.
3. Package, submit, apply, verify. Export RINEX (or the format your service requires). For U.S. NSRS work, OPUS is the common free path for static base and control logs. Wrong antenna selection in the upload form is a common way to get a precise-looking wrong answer. Wait for the report. Enter the returned position as the known coordinate of the base or control point, reprocess or adjust so the orthomosaic sits on that absolute, and keep the report with the job file. If the deliverable overlays a civil set, hold checkpoints you did not feed into the solution and report residuals.
Before you rely on the result: the occupation was long enough; antenna type and height match the upload form; relative RTK/PPK is planned separately from the absolute OPUS/PPP solution; you can read quality metrics in the report, not only the headline coordinate; independent checks exist for any map that must land on someone else’s control; and the report’s datum, realization, and epoch match the client’s drawing set.
None of that requires a geodesy degree. It requires treating PPP and OPUS as after-flight tools for a known point, not as a mode that forgives a missing log, a wrong antenna, or a deliverable with no checks.
If an OPUS report line, a PPP convergence note, or how to apply a base coordinate in your processing chain still is not clear, ask the follow-up on Ask Mav at pilotledger.com.