OPUS: Online Positioning User Service

website upgrade expected Wednesday 19 June

Improved page layout & link to prior frame on published solutions. Enjoy, and please report any issues.

What is OPUS?

This Online Positioning User Service (OPUS) provides simplified access to high-accuracy National Spatial Reference System (NSRS) coordinates. Upload a GPS data file collected with a survey-grade receiver and obtain an NSRS position via email.

OPUS requires minimal user input and uses software which computes coordinates for NGS' Continuously Operating Reference Station (CORS) network. The resulting positions are accurate and consistent with other National Spatial Reference System users.

Your computed NSRS position is sent privately via email, and, if you choose, can also be shared publicly via the NGS website. To use properly, please familiarize yourself with the information below.

Handouts: See also OPUS one-pager.

Uploading

Using OPUS requires just five simple steps:

1. EMAIL Enter the email address (e.g., your.email@domain.com) where you want OPUS to send your solution report.
2. DATA FILE Provide OPUS a GPS observables data file in any format (for automatic conversion to RINEX format by UNAVCO's teqc converter) or convert it to RINEX yourself first. OPUS also recognizes compressed (UNIX or Hatanaka.yyd) or zipped (gzip or pkzip) files, including multiple data files in a single zip archive. OPUS accepts receiver epoch rates of 1,2,3,5,10,15 or 30 seconds, all of which are decimated to 30 seconds for processing. Note: Though your data file may already contain survey metadata, including antenna type, height, and mark information; these are IGNORED as we have found they are inconsistenly formatted.
3. ANTENNA TYPE Select the antenna brand and model you used. This allows OPUS to determine the appropriate antenna calibration model for processing. Take care! Selection of an incorrect or default antenna may result in a height error as large as 10 cm. See antenna calibration to help find an exact match.
4. ANTENNA HEIGHT Enter the vertical height in meters of your Antenna Reference Point (ARP) above the mark you are positioning, as shown in the image above right. The ARP for your antenna type, usually the center of the base or tripod mount, is illustrated at antenna calibration. If you enter a 0.0 antenna height, OPUS will return the position of your ARP.
5. OPTIONS Press OPTIONS to customize the way your solution is performed and/or reported. Your selections will override the optimized OPUS defaults and should therefore only be employed by experienced users.

PROCESSOR

OPUS provides three distinct processing softwares optimized for different data types:

STATIC: For OPUS static processing, your data file must contain at least 2 hours but not more than 48 hours of data.
RAPID-STATIC: For OPUS rapid-static processing, your data file must contain at least 15 minutes but not more than 2 hours of data, with all four observation types (L1,L2, P1 (or C1), and P2) present at each epoch used.
KINEMATIC: Not yet available.

These processors are described in more detail below.

How does it work?
OPUS will use either a static or rapid-static process, depending on the duration of your data file.

Static: Files over 2-hours in duration are processed using PAGES static software. Your coordinates are averaged from three independent, single-baseline solutions, each computed by double-differenced, carrier-phase measurements from one of three nearby CORS.

Rapid-static: Shorter data files, under 4-hours, may be processed using RSGPS rapid-static software. Rapid-static processing employs more aggressive algorithms to resolve carrier phase ambiguities, but has more stringent data continuity and geometry requirements; therefore there are some remote areas of the country in which it will not work. See accuracy and availability map.

Accuracy

How accurate is it?

Under normal conditions, most positions can be resolved to within a few centimeters. Estimating the accuracy for a specific solution is difficult, however, as formal error propagation is notoriously optimistic for GPS reductions. Systematic errors, such as misidentification of antenna type or height, are not detected. Local multipath or adverse atmospheric conditions may also negatively impact your solution.

Static: Static processing provides peak-to-peak errors for each coordinate (X, Y, Z, Φ, λ, h, and H). These describe the error range, the disagreement between the 3 baseline solutions, as shown below.

One advantage of peak-to-peak errors is that they include any error from the CORS reference coordinates. To support a stable national datum, the CORS NAD 83 coordinates are updated less frequently than the ITRF. Your solution will usually show slightly larger errors in NAD 83 than in ITRF.

TO DO: Add discussion of RMS.

see Availability & Accuracy map

Rapid static: Absent any warning messages, the best estimates of coordinate accuracy are the standard deviations reported by single baseline analysis. Our experiments indicate that the actual error is less than these estimated accuracies more than 95 percent of the time.

TO DO: More discussion of the reported accuracy metrics for OPUS-RS is needed here.

How to improve your accuracy:

Observe longer: A longer-duration session provides OPUS a better opportunity to accurately fix ambiguities and mitigate multipath error. The graph below shows the correlation between session duration and accuracy.
Observe again: A second, independent observation which yields a similar solution is an easy way to increase confidence in your results. Maximize independence by using a different observer, different equipment, on a different day, at a different time of day.
Wait a day: OPUS will use the best CORS and orbits available at the time you upload. While most CORS are archived within 30-minutes past the hour, some aren't available until the next day. Rapid orbits, available at 17:00 UTC that next day, may offer a slight improvement in your accuracy.
Process the data yourself: Manual data processing with suitable software will include custom cycle slip editing, outlier deletion, experimentation with tropospheric parameters, variable cut-off angle, and different constraints of the carrier phase ambiguities to integer values.

What to look for in a quality solution:

While there are no absolute rules, most accurate OPUS solutions contain the following:

orbit used = precise or rapid
> 90% observations used
> 50% ambiguities fixed
your antenna type and antenna height are correct
Static: overall RMS < 3 cm
Static: peak to peak errors < 5 cm.
Rapid Static: No warning messages.

Quality indicators that are suspiciously low
Normalized RMS that is suspiciously high.
Coordinate standard deviations that are suspiciously high.

Since RSGPS uses the double-differenced ionospheric delays at the CORS to interpolate to the delays at the rover, it may perform poorly? or fail? during periods of high ionospheric disturbance. In general, it is best to avoid performing any GPS survey during geomagnetic storms that cause large and variable ionospheric refraction. Geomagnetic storm alerts are issued by NOAA's Space Environment Center, so that the surveyor may avoid collecting data during these unusual events.

Similarly, RSGPS performs a simple geographic interpolation to predict the tropospheric delay at your GPS location. Under normal conditions this works well. However, it may not work well during the passage of a strong weather front, and these situations should be avoided.

Solution Formats

Three solution formats are available; standard, extended, and published. Samples are provided below:

`NGS OPUS SOLUTION REPORT ======================== 9999 OPUS DISCLAIMER OPUS DISCLAIMER OPUS DISCLAIMER OPUS DISCLAIMER` error and warning messages are appended here
`USER: Your.email@domain.com` Your email address	`DATE: October 27, 2004` The date and time you used OPUS
`RINEX FILE: 7615289n.04o` Your data file name	`TIME: 18:49:54 UTC` Coordinated Universal Time
`SOFTWARE: page5 0407.16 master7.pl` The software we used	`START: 2004/10/15 13:37:00` The first observation in your data file
`EPHEMERIS: igr12925.eph [rapid]` The orbit file we used	`STOP: 2004/10/15 18:10:00` The last observation in your data file
`NAV FILE: brdc2880.04n` The navigation file we used	`OBS USED: 8686 / 8804 : 99%` Usable / total observations in your data file
`ANT NAME: ASH700829.3 SNOW` Your selected antenna type	`# FIXED AMB: 41 / 42 : 98%` For static: Fixed / total ambiguities in your data file For rapid static: quality indicators from network and rover mode solutions (ambiguities are always 100% fixed)
`ARP HEIGHT: 1.295` Your selected antenna height	`OVERALL RMS: 0.020 (m)` For static: The formal statistical root mean square (RMS) error of your solution For rapid static: a unitless normalized RMS
Your position: earth-centered cartesian coordinates in the International Terrestrial Reference Frame (ITRF). The North American Datum of 1983 (NAD83) is also reported, if applicable. Accuracies below are reported as either peak-to-peak errors (static) or standard deviation estimates (rapid static) All initial computations are performed in ITRF. Your NAD83 coordinates are derived by transforming ITRF vectors into the NAD83 reference frame and recomputing the 3 independent and averaged positions (not a direct transformation of the ITRF coordinates; a direct transformation could be considered more accurate, but wouldn't fit your surrounding NAD83 network as well.) For both ITRF and NAD83, the reference coordinates for each CORS are derived from the NGSIDB and are updated using crustal motion velocities from HTDP (Horizontal Time-Dependent Positioning software to your data file's epoch. Your final ITRF coordinates retain this observed epoch, while your NAD83 coordinates are transformed again to the standard epoch date of January 1, 2002.
`REF FRAME: NAD83(CORS96)(EPOCH:2002.0000)`	`ITRF00 (EPOCH:2004.7887)`
`X: -552474.327(m) 0.015(m)`	`-552475.001(m) 0.015(m)`
`Y: -4664767.953(m) 0.021(m)`	`-4664766.631(m) 0.021(m)`
`Z: 4300548.721(m) 0.024(m)`	`300548.654(m) 0.024(m)`
ellipsoidal coordinates (latitude, longitude, ellipsoidal height) and accuracies
`LAT: 42 39 59.51026 0.007(m)`	`42 39 59.53576 0.008(m)`
`E LON: 263 14 44.18589 0.013(m)`	`263 14 44.14967 0.013(m)`
`W LON: 96 45 15.81411 0.013(m)`	`96 45 15.85033 0.013(m)`
`EL HGT: 314.705(m) 0.041(m)`	`313.753(m) 0.033(m)`
The North American Vertical Datum of 1988 (NAVD88) orthometric height, if applicable, along with the geoid model used
`ORTHO HGT: 340.240(m) 0.041(m)`	`[Geoid03 NAVD88]`
Your position: Universal Transver Mercator (UTM) coordinates. State Plane Coordinates (SPC) are also reported, if applicable. Also reported are the associated zone IDs, meridian convergence, point scale, and combined factor
`UTM COORDINATES`	`STATE PLANE COORDINATES`
`UTM (Zone 14)`	`SPC (4002 SD S)`
`Northing (Y) [meters] 4726229.423`	`43336.983`
`Easting (X) [meters] 684026.367`	`893325.488`
`Convergence [degrees] 1.52234197`	`2.46893915`
`Point Scale 1.00001666`	`1.00004366`
`Combined Factor 0.99996731`	`0.99999430`
`US NATIONAL GRID DESIGNATOR: 14TPN8402626229(NAD 83)` The US National Grid coordinates and referenced datum are reported, if applicable
`BASE STATIONS USED` The CORS we used as reference stations and the nearest mark from the NGS Integrated Data Base (NGSIDB) are reported along with their positions and distances from your position.
`PID DESIGNATION`	`LATITUDE LONGITUDE DISTANCE(m)`
`AI1569 NLGN NELIGH CORS ARP`	`N421224.250 W0974743.043 99724.2`
`DF7469 SDSF EROS DATA CORS ARP`	`N434401.727 W0963718.541 119065.7`
`AH5054 OMH1 OMAHA 1 CORS ARP`	`N414641.765 W0955440.671 120751.8`
`NEAREST NGS PUBLISHED CONTROL POINT`
`NM0874 D 276`	`N423846. W0964505. 2286.4`
`The numerical values for this position solution have satisfied the quality control criteria of the National Geodetic Survey. The contributor has verified that the information submitted is accurate and complete.` Because OPUS is automated and assumes your entries are valid, we add this disclaimer to all solutions.

Solution Error Messages

I got a warning message that the IGS Precise Orbit was not available at the time of processing, but the "rapid" was used. What does that mean??: We will not have the "final" IGS Precise orbit until the International GPS Service (IGS) completes a full week (Sunday through Saturday). This final precise orbit is the combination of seven analysis centers worldwide. It can take these analysis centers several days to upload the orbit to the IGS so the availabilty of a Sunday orbit can be 19 days. The IGS rapid orbit is used in the absence of the IGS precise orbit. However, this is not cause for alarm since the IGS rapid is nearly as "good" as the IGS precise. How does this relate to positions on the ground?
Since most OPUS baselines are less than several hundred kilometers, the differences between using the IGR (rapid orbit) and the IGS (precise orbit) is barely detectable if at all. Because of this, OPUS has discontinued this warning message (1/1/2004). For more information see IGS.
Some of my attempts to submit data generates a return email saying, "The observations to slip ratio is too low. There were an unusually high number of cycle slips in the data set. Aborting ..." (Code 1012). What does this mean, and how can I correct it?: This error message primarily indicates that your carrier phase data set contains too many cycle slips to assure an automated hands-off processing to obtain accurate results. The data may still be useful, but will require human intervention to efficiently resolve the cycle slips. Perhaps nearby radio interference or obstructions have caused an unusual amount of cycle slips.
I am trying to upload a rinex file and I am getting a message that there are illegal characters in the file name.... This is a new one on me - what am I doing wrong?: The problem is probably not with the file name, but with the path name. OPUS is run on a UNIX machine, and it can only read path names that contain numbers, letters, the period, dash, and the underscore. If you move your file to another directory, it should be able to be uploaded.

FAQs

I uploaded data. Why no response?: Solutions are usually sent within a few minutes, but it may take more than an hour to complete if traffic is heavy or your file is large. You will eventually receive either a solution or a failure message. Take care to enter your email address correctly and check your spam filters.
My nearest CORS weren't used. Why not?: OPUS tries to use your nearest CORS, but tests the integrity of each dataset, and will expand the search area until enough quality data are found. Also note some CORS data are not available until the following day. You may use OPUS options to force include or exclude specific CORS.
Is antenna type required?: While strongly recommended, if you leave the antenna type blank your data will be processed with a "null" model, meaning xx
What is the ARP height for Leica antenna model SR 399, with GRT44 tripod mount?: If you have this type of antenna mounting, the ARP height can be determined by using the following equation: Height of ARP (meters) = 0.350 + tape measurement (meters) "Tape Measurement" is the distance in meters from the bottom of the hook in the antenna mounting to the monument.
Why do so many antenna types include the term "NONE"?: NONE means no radome. We use antenna names as adopted by the International GPS Service (IGS). The field (columns 17-20) where NONE is located represents the radome used. The 4 character Id used can be: NONE (or blank), SPKE, SNOW, SCIS, SCIT, LEIC, SPKE, CONE, TCWD, UNAV, TZGD, etc. See the IGS antenna list for acceptable antenna codes.
My NAD83 coordinates are missing. Why?: Sometimes OPUS uses CORS from outside the NGS CORS network that only have ITRF positions and no listed NAD83 positions. Your resulting positions will be just as good as if all CORS were used, except the NAD83 positions will not be listed. You may wish to go to the NGS home page, click on "Products and Services", and download the program HTDP. This program converts positions between different reference frames.
How do the NAVD88 heights from GEOID09 compare with heights from GEOID03 or GEOID99?: Newer geoid models provide improved orthometric height accuracy. Upgrade your older GPS heights as follows: NAVD88_{new geoid} = NAVD88_{old geoid} - new geoid ht + old geoid ht.
Use the geoid toolkit to compute geoid heights for your project area.
What are the quality indicators on the data sheet?: A quality indicator is the average value of the w-ratio at the last three epochs of data. The w-ratio is a measure of how well the LAMBDA algorithm was able to determine the correct integer ambiguities. There are two of them because OPUS-RS uses the RSGPS program twice. The network mode run uses only data from the CORS; its purpose is to determine the ionospheric and tropospheric refraction for the time and location of your data set. The rover mode run uses the information from the rover run to find your position. Values of the quality indicators below 1.0 should be taken as warning signs. However, low quality indicators by themselves don't tell the whole picture - it is possible to have low quality indicators along with low standard deviations (located to the right of each position component) and still have a good solution.
What is the normalized RMS?: This quantity is also known as the reference standard deviation (the square root of the reference variance), the standard deviation of the observation of unit weight, and other names. It is a unitless quantity, and its expected value is 1.0. Values of the normalized RMS greater than 1.0 mean that the weights assigned to some or all of the observations were too large. This can happen if your data set or one or more of the CORS contains particularly noisy data. Most runs of OPUS-RS produce a normalized RMS of 1.0 or less, meaning that the noise in the data was actually less than would be indicated by the assigned weights.
How are the weights assigned in rapid-static?: In OPUS-RS, the weight of an observation is the inverse of the square of the observation's standard deviation. For one way phases observations, the standard observation of an L1 observation is 0.019 meter/sin(elevation angle), and the standard observation of an L2 observation is 0.0244 meter/sin(elevation angle). For one way range observations, the standard deviation is initially set at 0.05 meter/sin(elevation angle) for P1 and 0.064 meter/sin(elevation angle) for P2. However, the range observations are filtered to detect noisy data and multipath. Noisy range data may be downweighted by assigning a larger standard deviation. In addition, OPUS-RS contains a priori constraints on all the parameters. The assigned standard deviations are 0.4 meters for double difference ionospheric refraction delays, 0.025 meters for the correction to the nominal tropospheric delay, 1.44 meters for the correction to a priori value of an L1 double difference ambiguity, and 2.3 meters for the correction to a priori value of an L2 double difference ambiguity.
What happened to the peak-to-peak errors?: OPUS-RS uses a simultaneous least squares adjustment of all the available data (CORS plus your data files), while regular OPUS uses three single baseline adjustments. The simultaneous solution is the more theoretically correct approach, but it doesn't produce the peak to peak errors. It does produce standard deviations for the coordinates of your receiver but these are almost always too optimistic to be useful. The covariance matrix of your receiver from the adjustment is available in the extended solution.
How has OPUS evolved? (Release Notes)

Publish Your OPUS Solutions

Publishing helps maintain local ties to the National Spatial Reference System, and, by linking observations, strengthens the models used to translate between modern and legacy mapping products.