 |
 |
OPUS: Online Positioning User Service |
 |
 |
This Online Positioning User Service (OPUS) provides you with simplified
access to high-accuracy National Spatial Reference System (NSRS) coordinates:
all you need is a clear view of the sky and a survey-grade Global Positioning System (GPS) receiver.
OPUS processes your GPS data files with the same models and tools which
help manage the Nation's Continuously Operating Reference Station (CORS)
network, resulting in coordinates which are both highly accurate and highly
consistent with other users. Your computed NSRS position is sent privately
via email, and, if you choose, can also be shared publicly via the NGS
database.
OPUS is highly automated and requires minimal user input. To use properly,
please familiarize yourself with the information below. |
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 24 hours of data.
- RAPID-STATIC: For OPUS rapid-static processing, your data file must
contain at least 15 minutes but not more than 4 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?
The processing method used to obtain your solution is dependent upon the content
and duration of your data file. For dual-frequency observation files of 4-hours
or longer, static processing is performed with NGS' PAGES
software. Your coordinates are averaged from three independent single-baseline
solutions computed by double-differenced, carrier-phase measurements between
your data file and each of 3 surrounding CORS.
Shorter dual-frequency data files, between 15-minutes and 4-hours duration,
are processed rapid-statically using RSGPS software. RSGPS
employs more aggressive algorithms to resolve carrier phase ambiguities but
has more stringent data continuity and geometry requirements; therefore, there
are many remote areas of the country in which it will not work.
How accurate is it?
Under ideal conditions, OPUS can easily resolve most positions to within centimeter
accuracy. Estimating the accuracy for a specific data file is difficult, however,
as formal error propagation is notoriously optimistic for GPS reductions. Instead,
the peak-to-peak error, or error range, is provided for each coordinate component
(XYZ, Φλh and H). The peak-to-peak error is the difference between the maximum
and the minimum value of a coordinate obtained from the 3 baseline solutions, as shown at right.
Please
note that peak-to-peak accuracy estimates depend upon freedom from systematic
error. Any misidentification of the antenna type or height, local multipath
or adverse atmospheric conditions will not be averaged away by the 3 "independent"
CORS solutions. The advantage of the peak-to-peak error measure is that the
error range also reflects any error in the CORS reference coordinates. On the
average, one should obtain larger peak-to-peak errors in the NAD 83 coordinates,
when compared to the ITRF coordinates. This is due to the procedures used to
derive the CORS coordinates. To serve our users,
the NAD 83 coordinates of the National CORS are updated less frequently than
ITRF coordinates. However, this also results in the NAD 83 coordinates being
somewhat less accurate.
For rapid static: Absent any warning messages, the best estimates of coordinate
accuracies 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, RSGPS statistics.
How to improve your accuracy:
OBSERVE
LONGER: A longer-duration session provides PAGES a better opportunity
to accurately fix ambiguities and mitigate multipath error. See the graph
at right for the correlation between session duration and accuracy.
- RESUBMIT AFTER ORBITS IMPROVE: OPUS will solve your position
using the best CORS and ephemeris files available. Due to the latency involved
in archiving CORS and determining orbits, data uploaded within a day of observation
may find fewer CORS and predicted or ultra-rapid, rather than rapid or precise
orbits. Note, rapid and precise orbits yield essentialy identical OPUS results,
assuming you are within a few 100 km from the CORS. Click here for an estimate
of orbit latency.
- PROCESS THE DATA YOURSELF: Manual data processing through
suitable software can include manual cycle slip editing, outlier deletion,
incorporation of local meteorological measurements, and experimentation with
allocation of tropospheric parameters, variable cut-off angle, and different
constraints of the carrier phase ambiguities to integer values.
Sample OPUS solution report, with explanation added for each item:
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 |
This position was
computed without any knowledge by the National Geodetic Survey regarding
equipment or field operating procedures used.
Because OPUS is automated and assumes your input is valid, we add this
disclaimer to all reports |
What to look for in a quality solution:
While there are no absolute rules, most accurate OPUS solution reports contain
the following:
- ephemeris used = precise or rapid
- > 90% observations used
- > 50% ambiguities fixed
- overall RMS < 3 cm
- peak to peak errors < 5 cm.
- your antenna type and antenna height are correct
OPUS-RS: Examine all warning messages. Warning messages are issued for:
- Quality indicators that are suspiciously low
- Normalized RMS that is suspiciously high.
- Coordinate standard deviations that are suspiciously high.
Since RSGPS uses the DD ionospheric delays at the CORS to interpolate to
the delays at the rover, it may not work during periods of high ionospheric
disturbance. In fact, it is best to avoid performing any GPS survey during
geomagnetic stgorms that cause large and variable ionospheric refraction.
Geomagnetic storm alerts are issued by NOAA's Space Environment Center (http://www.sec.noaa.gov),
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.
- 1) I see there is a 2 hour minimum for a request, what is the maximum?
- There is a 24 hour maximum request at this time
- 2) OPUS selected 3 CORS site for me, but they are not the closest sites
to my location; what is the process for picking the 3 CORS sites used?
- There are approximately 5 tests done for compatibility between the given
location and the CORS sites; e.g., if the time block requested is compatible
with the CORS site, if there is a high multi-path environment, etc. OPUS starts
with the closest site(s) to your given location, and conducts these tests
on each site for its compatibility to these 5 tests, and if the closest site
is not compatible, OPUS then continues to search out sites until it is able
to find 3 sites that are compatible, and uses them.
- 3) I submitted my data file, but haven't received anything back yet.
- If OPUS fails upon processing your data, you should get an email stating
so. If you do not receive an email, it is either because you entered the wrong
email address, or your company has a spam filter that rejects OPUS reports.
OPUS is run from a UNIX machine that is not Windows compatible, so we can't
hit a hyperlink to send a request to your organization asking to put on the
allowed list.
- 4) I got an email saying NO ORBIT DATA AVAILABLE; what does this mean?
- This means the orbit data hasn't been received from IGS yet, and will be
done so within 24 hours, please re-submit your request at a later time.
- 5) 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 on the IGS and its products visit
them at http://igscb.jpl.nasa.gov
- 6) Do I have to enter an antenna type?
- We recommend you choose the correct antenna type, as it will allow us to
apply the correct antenna phase patterns. If no antenna type is applied, your
data request will still be processed, but the height component of the solution
will not be as accurate.
See May 2003 Question of the Month
- 7) What is the "normal" turnaround time for a data set?
- The usual turnaround time for a data set is 2-3 minutes, depending upon
the file size; it may take as long as a couple hours, for very large file
sizes (e.g., 4+ hours of 1 second data).
- 8) 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.
- 9) I have a Leica antenna model SR 399, with mounting GRT44 for tripod
set-up, how do I compute the height of the ARP (Antenna Reference Point) above
the mark (monument) as requested by OPUS?
- 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.
- 10) How do I get my data into RINEX format?
- You can use the same software that the National Geodetic Survey uses to
convert the raw data. UNAVCO has developed the software called TEQC
(pronounced TEK) and is freely available at:
http://www.unavco.org/facility/software/teqc/teqc.html
- 11) How do I know which State Plane Coordinates Zone to select?
- If you are not interested in State Plane Coordinates, choose the default
( 0 none). If you know the approximate position of your GPS receiver and
want to find the proper state plane coordinate zone, use the Geodetic Toolkit
facility on the NGS website by navigating www.ngs.noaa.gov->Geodetic Toolkit->
State Plane Coordinates ->Find Zone.
- 12) Why doesn't my OPUS solution contain NAD83 positions?
- 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.
- 13) What is this new item called the US National Grid?
- The USNG item in the NGS Tool kit explains
the US National Grid. This new method of representing position has been endorsed
by the Federal Geographic Data Committee. NGS is promoting the US National
Grid by showing values on the OPUS data sheet.
- 14) Will OPUS be available to those who are using L1 only?
- We would like to have a L1 version of OPUS , but preliminary testing indicates
that our current programs are not suitable for L1 processing. We may resume
in the future the programming and testing of L1 OPUS. We have a pseudorange
version of OPUS called OPUS-GIS which is currently being tested and can use
either L1 or L1/L2 data and gives results accurate to a meter or two. We hope
to have this version available in late 2007.
- 15) How do I transform orthometric heights NAVD88 currently given by
OPUS using GEOID03 to the orthometric heights computed using the old GEOID99?
- This problem can be resolved by getting the differences of geoid heights
between GEOID03 and GEOID99. At each point, there will be a bias on the geoid
height of the two geoids that should be taken into consideration. For example,
if you want to transform orthometric heights from NAVD88 (GEOID03) to NAVD88
(GEOID99) you should apply the following equation: NAVD88 (GEOID99) = NAVD88
(GEOID03) + (GEOID03 - GEOID99) The value of NAVD88(GEOID03) is given directly
by OPUS. The values of the geoidal heights (GEOID03 and GEOID99) can be interactively
computed from NGS Geoid Web page. For this task
you need to know the geographic location of the point, e.g. its geodetic coordinates.
At this time NGS does not have a program to do this computation and you must
calculate them individually point by point.
- 16) During recent solutions that were sent along, beside the antenna
name it shows the word NONE. Why is this?
- 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.
- 17) Why do my Trimble Dat files fail in OPUS?
- You have the option to submit receiver native format data. This has been
possible through the use of TEQC software. Most manufacturer native format
data continues to be accepted by OPUS. However we have recently become aware
of possible errors in the translation of the new Trimble DAT file format that
is common with R5 and R7 receivers. We therefore can no longer support submission
in this format. Users with this equipment must convert their data into RINEX
format using Trimble software and resubmit it.
If you need assistance in converting your data please contact Trimble support
at: http://www.trimble.com/netrs_ts.asp
- 18) 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 - OPUS-RS
- 1) Will OPUS-RS take L1 data?
- OPUS-RS takes only L1/L2 data. OPUS-RS requires that at least four four
observation types be present in your data file. These may be L1, L2, P1,and
P2, or L1, L2, C1, and P2. A mapping grade version of OPUS, called OPUS Mapper,
is being developed, and it will be able to take L1 data.
- 2) I saw your 92% and 97% confidence message on my printout. How can
I be more sure of my results?
- These messages have been removed. Better accuracy messages are now being
provided.
- 3) What is the maximum time period for a session, and could the same
file be put through OPUS-RS that is put through OPUS?
- OPUS-RS is set to not run and return a message for datasets over 4 hours.
Also, OPUS suggests a minimum of 2 hours, so it is possible to send datasets
between 2 hours and 4 hours to both utilities.
- 4) OPUS-RS has been in a testing or "Prototype" phase for over one year.
Is this version finished, or set in stone?
- OPUS-RS has undergone thousands of tests, so we have officially released
it for operational use by the public. However, it is still being refined so
you may notice some changes in the future.
- 5) 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.
- 6) 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.
- 7) How are the weights assigned in OPUS-RS?
- 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.
- 8) 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 report.
- 9) How soon should I submit my observations to OPUS-RS for processing?
- Roughly speaking, OPUS-RS should provide reasonably accurate coordinates
for data-collection points located in the 48 coterminous states if you wait
at least 2 hours after completing your GPS observing session before submitting
the collected data to OPUS-RS for processing. OPUS-RS may provide more accurate
coordinates, if you wait longer to submit your data. Little or no increase
in accuracy should be obtained by waiting more than 28 hours.
More precisely speaking, to process a submitted GPS dataset, OPUS-RS
needs (1) corresponding GPS data from at least three CORS and (2) corresponding
GPS satellite orbits. Moreover, OPUS-RS uses CORS data that spans a time
interval which extends the time span of your data by as much as 26.4 minutes
in each direction. OPUS-RS uses this extra span of data to accurately estimate
atmospheric parameters that characterize the refraction delays experienced
by your GPS data. Now, most CORS data are collected hourly within 30 minutes
after the turn of the hour. However, some CORS data are collected only daily
within 4 hours after midnight at Greenwich, England. Hence, NGS recommends
that you do NOT submit your GPS data to OPUS-RS until at least 30 minutes
after the turn of the first hour which occurs at least 26.4 minutes after
the end of your observing session. The chances of having GPS data available
from more CORS are improved, if you submit your GPS data to OPUS-RS at
least 4 hours after the first Greenwich midnight following the end of your
observing session. NGS studies reveal that the accuracy of OPUS-RS results
generally improves with the use of data from additional CORS. Hence, OPUS-RS
will use data from as many as nine CORS, if these data are available (and
if these CORS are within 250 km of your GPS location). Also, the accuracy
of OPUS-RS results should be better if this utility is able to use the `postfit'
satellite orbits, as opposed to the `predicted' satellite orbits, generated
by the IGS. The IGS releases new orbits four times per day at 3:00, 9:00,
15:00, and 21:00 relative to Greenwich time. Moreover, each release contains
postfit orbits for up to 3 hours before the release time. Hence, you never
have to wait more than 9 hours (and you may only have to wait as little
as 3 hours) to have OPUS-RS process your GPS data with postfit orbits.
Note that accuracy differences between postfit and predicted IGS orbits
continue to shrink as understanding of the underlying physics has improved
over the years.
- 10) How has OPUS evolved?
-
An incomplete change log:
view