February 3, 2021. Presenters/Panelists: Joe Evjen, Dan Gillins, Dave Zenk, Galen Scott, Rick Foote
Below, 71 questions asked during the forum, which fall into 10 topics:
| Questions #01: 02 each --> | general |
| Questions #02: 08 each --> | upload |
| Questions #03: 05 each --> | antennas |
| Questions #04: 09 each --> | data formats |
| Questions #05: 04 each --> | processing |
| Questions #06: 09 each --> | heights |
| Questions #07: 07 each --> | projects |
| Questions #08: 06 each --> | RTK / RTN |
| Questions #09: 09 each --> | sharing |
| Questions #10: 12 each --> | recovery |
Q: Could you send any of the links that you can from this webinar?
A: YES. The forum was videotaped. This link and the NGS Presentations Library have downloadable powerpoint slides with embedded links.
Q: Will the upcoming new datums affect how I use OPUS?
A: YES, for the better hopefully. New datums will allow simplifications to OPUS options and should usher in new functionality, as new frames and tools are built around how OPUS works. Fundamentally, OPUS won’t change, it will still process your data in the ITRF reference frame, and convert that to regional frames for reporting and other options.
Q: in the future we will be able to save our preferences so they auto populate on the entry page?
A: YES. While our goal is to make preferences less necessary, by using the data file embedded metadata, there are no explicit plans to remove the form’s existing session cookies, or the existing Option > My Profile, as explained at OPUS/about.jsp#uploading
Q: OPUS used to have a user profile setting. Is that something that might come back?
A: YES, BUT profiles haven’t gone away, they are still available under Upload > Options.
Q: What is the minimum occupation time for a static survey to be successfully submitted in OPUS?
A: For now, two hours is the shortest data file that OPUS-S will accept. Longer data files, 4-5 hours, provide better results. We are actively testing the new GNSS processing engine, and may lower this limit if experiments prove it wise.
Q: HOW SIGNIFICANT IS IT TO PROCESS YOUR OPUS SOLUTION 24 HOURS AFTER COLLECTION?
A: IT DEPENDS. OPUS will use the best CORS and orbits available at the time you upload your data. While most CORS are archived within 30-minutes past the hour, some aren't available until the next day. If you process your data in less than 24 hours after collection, OPUS will use Ultra-Rapid orbits. Rapid orbits, available at 17:00 UTC the next day, will offer a slight improvement in your accuracy. Final orbits, available weeks later, offer only slight benefit to solutions in areas with usable CORS nearby.
Q: OPUS seems to be holding up files for several hours at a time and then running through quickly. The "waiting" grows while the "completed" stays the same for hours. Is that normal?
A: NO. Check the timestamp on the ‘OPUS Today’ graphic, is it updating for you? OPUS can process several solutions per minute, but is popular, so backlogs are common. Your solutions are accommodated in the order received, though if you’ve uploaded several, your rate may be tempered to allow others equal access.
Q: I would like to submit several hundred datasets through OPUS every evening. Is there a limit to the number of datasets you like an organization to submit to OPUS on a daily basis?
A: NO(!) OPUS currently has no usage limits, and does have techniques for managing heavy users. We are investigating ways to make OPUS more usable for users with many files per day; the resulting product should be easier to use, but this may invoke usage caps, if popularity causes the tool to slow down.
Q: Would it be possible to read the RINEX header for initial form filling in the antenna model and height fields?
A: YES, in future versions OPUS will use metadata properly recorded in the RINEX header as default values, replacing NONE antenna @ 0.0 meter height. Users can elect to override these new defaults with optional, manual entries or user profiles.
Q: Could an updated opus solution include State Plane coordinates in International ft, rather than meters?
A: YES, simply select the upload option > formats > extended format to see state-selected foot units. As this has been a very popular suggestion, NGS may consider making feet more prominent when we redesign OPUS output for the new reference frames.
Q: what is the man machine interface. is that the touch button panel?
A: YES, MMI is the side of the antenna with the user interface, one of several possible North Reference Points (NRP) described at ANTCAL/#faq5
Q: Did he say that the antenna needed to be pointed to the north?
A: YES, NGS recommends that when conducting a GNSS survey, your antenna’s North Reference Point (NRP) should be oriented to true north. See Antenna Calibrations to look up your antenna’s ARP and NRP.
Q: Why turn the Antenna to the North while collecting data?
A: This allows the antenna calibration to properly account for your antenna’s azimuthal bias, if any.
Q: How accurate does the north orientation need to be?
A: IT DEPENDS on how much azimuthal bias exists in your antenna calibration. Many manufacturers design their antennas to have only small biases, in which case it shouldn’t matter much, but if you are building a CORS, guidelines ask you to look up your magnetic declination, so that you can use a magnetic compass and account for the small difference from true north. You can look up your antenna’s azimuthal bias from the Antenna Calibrations website.
Q: Is Antenna model or Code included in the data file? If the antenna type is included in the data file, why do we need to provide it separately to opus?
A: GOOD POINT. Future versions of OPUS will use metadata properly recorded in the RINEX header as default values, replacing NONE antenna @ 0.0 meter height. Users can still elect to override these new defaults with optional, manual entries or user profiles, but this should simplify data upload for many of them.
Q: Do you plan to add BeiDou data in OPUS? if yes, When?
A: YES, the 2021 GNSS upgrade to OPUS will accommodate BeiDou , Galileo, and GLONASS. However, OPUS also requires that IGS or NCN base stations record BeiDou signals; this is still rare, and it may take years for base stations near you to upgrade. As of day 328 of year 2020, 100% of our NCN network recorded GPS, 85% recorded GLONASS, 34% recorded GALILEO, and 0% recorded BEIDOU.
Q: The RINEX program I use removes all constellations except GPS. Can we use through RINEX all possible constellations?
A: YES, RINEX3 was developed to support many GNSS constellations, whereas RINEX2 supports only GPS and GLONASS.
Q: With the new multi-constellation OPUS will we be able to specify what constellations are used?
A: YES, an upload option will allow you to exclude constellations. You can also manually edit RINEX to strip out whole constellations or individual satellites.
Q: Since you mentioned RINEX 3 and "other 3rd party software" (teqc), can you explain that OPUS server uses a program to convert from RINEX 3 to RINEX 2?
A: OPUS now uses GFZRNX - RINEX GNSS Data Conversion and Manipulation Toolbox to down-convert any RINEX3 to RINEX2 . When OPUS multi-GNSS launches, it will use both RINEX2 and RINEX3 directly.
Q: Does the Rinex conversion version matter?
A: NO AND YES. NO TODAY, any RINEX version ‘should’ deliver identical results, assuming they are properly recorded. LATER YES, as use of GNSS signals beyond GPS+GLONASS will require RINEX3, and the multi-GNSS version of OPUS coming in 2021.
Q: Is there a link to information to explain the difference between RINEX, RINEX2, and RINEX 3 formats? I found this: https://www.gisresources.com/rinex-receiver-independent-exchange-format/
A: RINEX formats are now specified by the International GNSS Service. You may enjoy the visualizations at gage.upc.edu/Rinex_v2.11 and Rinex_v3.01 and the GUI for manipulating RINEX at http://teqc.silkwerks.com/ Note, these are NOT NGS products.
Q: When will we be able to use RINEX 3? I tried it today. It gave me an error message saying it required 2.11.
A: TODAY, OPUS accepts RINEX3, but be aware that OPUS uses the third-party software GFZRNX to down- convert it to RINEX2. LATER IN 2021, a multi-GNSS version of OPUS will become available for testing and comment, which will ingest RINEX 3 or 2 directly.
Q: RINEX 3.05 SUPPORTED?
A: PROBABLY. The version of GFZRNX OPUS uses explicitly states support up to 3.0.4. Reviewing the change log for RINEX 3.04 -> 3.05, almost all changes are documentation. This, plus the lack of an update for GFZRNX suggests that RINEX 3.05 should be viable.
Q: Will OPUS upload Trimble native .T02 files ?
A: NO, they will have to be converted to .DAT or RINEX before submitting to OPUS. Support for vendor-specific formats is waning, as the enabling 3rd party translator TEQC is past end-of-life. The future is RINEX!
Q: IGb2014 support?
A: YES. OPUS uses IGS+NCN coordinates aligned to IGb2014, but labels them ITRF2014.
Q: NGS should use more CORS for better positioning and HTDP accuracy in the Caribbean?
A: OKAY. Both the NCN and IGS networks accept new base stations of sufficient quality, and NGS does have an interest in monitoring intraframe deformations across the Caribbean. NGS operates very few base stations of its own, but instructions for nominating local stations are at Guidelines for Establishing and Operating CORS
Q: HTDP Horizontal Crustal Motion? Is this acronym correct?
A: ALMOST. HTDP = Horizontal Time-Dependent Positioning
Q: Can OPUS remove satellites that have too many slips?
A: YES, OPUS attempts to detect and remove cycle slips. You may also choose to use 3rd party software to remove satellites from the data file before uploading it to OPUS.
Q: In Texas the Peak to Peaks have gotten "worse" going from Geoid 12B to 18. For example: 0.02m to now about 0.06 or 0.07m with Geiod 18. Is this more a result of the Geoid quality in Texas or the way OPUS calculates the Peak to Peak, or a combination of both? Thank you.
A: BOTH. The adoption of GEOID18 has made OPUS heights better now than ever before, but OPUS concurrently chose a more conservative calculation for their accuracy. OPUS began using GEOID12B+18’s more conservative geoid uncertainty grids with a new, more conservative equation, which uses the OPUS observation duration in hours (T), solution (RMS), and ellipsoid height solution range (p2p) to estimate the ellipsoid height accuracy, and combine it in quadrature with the geoid height uncertainty:
Our estimation is, mathematically,
ORTHO HGT p2p = sqt[ (sqt[(RMS /1.5)2 +(3.7 /sqt(T))2 +(ellip_hgt_p2p /1.6929)2 ])2 +(2sigmaGeoid /1.96)2 ]*1.96
This equation is more conservative than the old, resulting in median orthometric height peak to peaks jumping from approx. 2 cm to 5 cm. This has been shown to be conservative for 86% of GPSBM observations nationwide, when holding the published orthometric height as truth.
Q: Does OPUS Ellip Ht Pk-Pk to Ortho Ht uncertainty now take into account the geoid uncertainty at that specific location? There was at one time a fixed scaling using Pk-Pk by the wrong factor. Joe may recall participating in that discussion on the SurveyorConnect forum.
A: YES, see the answer above.
Q: Is the vertical peak-to-peak an appropriate indicator of orthometric height uncertainty, or is there a piece of info in the OPUS report that would be better to use?
A: HARD TO SAY. As compared with traditional geodetic control, a single OPUS solution lacks the observation redundancy necessary to determine the accuracy of the computed height. None of the possible metrics correlate strongly with accuracy. As seen in the answer and graph above, the orthometric height ‘peak-to-peak’ value reported on the OPUS solution is often VERY conservative, though not always for about 14% of GPSBM solutions. NGS will need to tackle this when redesigning both the NGS datasheet and next version OPUS solution reports; fortunately the mathematical relationship to the next vertical datum will be simpler.
For accurate results, use good field technique in ideal (good sky visibility) conditions, and conduct multiple observations, at different times of day.
Q: any chance the NGS provides tools to customize geoid model elevations?
A: See NGS GEOID Pages for historic geoid models. Geoid models are interchangeable with simple equations. For geoids based on the same ellipsoid, NAVD88 new geoid = NAVD88 old geoid - new geoid ht + old geoid ht. For geoids based on different ellipsoids, you must also add in the vertical separation between the ellipsoids, which you can determine from tools like our HTDP.
Use the ‘interactive computations’ tools in geoids linked above, or accessed via vdatum.noaa.gov to compute geoid heights for your project area .
Q: When will OPUS allow user selecting geoid model?
A: NEVER? OPUS stopped this after GEOID03. To use other geoids, see the answer above. Would this be useful? Send your use case to ngs.opus@noaa.gov
Q: geoid separation reports?
A: The geoid separations aren’t explicitly stated in OPUS solutions, but can be derived from the equation N=h-H, where h and H are the OPUS report’s EL HGT and ORTHO HGT respectively. You can use the computation tools at any NGS GEOID Page to lookup modeled geoid separations directly.
Q: Regarding the Geoid accuracy in Texas. Will the factors limiting Texas accuracy affect the Geoid for SPCS2022?
A: Somewhat. The next vertical datum, NAPGD2022, will happily free us from many of the age and access issues suffered by Texas bench marks, by replacing decades-old leveling with newer, more accessible geoid-based heights. However, large-scale changes in land and water mass will continue to slowly change the geoid. NGS is starting a GEOID Monitoring Service (GEMS) to provide time dependent maintenance of the next vertical datum.
Q: I have a published First and Second Order Benchmarks that are also NCN. Can I submit those to OPUS-Share for use in the GPS on Benchmark campaign?
A: YES and NO. YES, as we plan on using all GPSBM data shared through Dec 31, 2021. However, if your station already has a PID, and published NAD83 and NAVD88 heights, it is already recognized as a GPSBM from the datasheet. If your station is a CORS and has a published NAVD88 orthometric height, we already plan to include it as a GPSBM in the transformation model. See our Dec 10, 2020 webinar GPS on Bench Marks for NSRS Modernization.
Q: To convert our local NAVD 88 BMs to the new 2022 Datum in a couple of years, will it be as simple as uploading our RINEX files to OPUS in 2022?
A: SIMPLER! While OPUS can serve for this purpose, if you already have an ellipsoid height for the mark, NGS will provide conversions to translate that into new orthometric heights, as well as a lower-accuracy transformation tool to convert leveled NAVD 88 orthometric heights directly. So, you will have the choice to reprocess (OPUS) or convert (NCAT).
Q: California surveyor here. How does OPUS Projects handle crustal motion?
A: OPUS-Projects assigns a velocity to every mark in a project based upon the “class” of the mark.
Note that the HTDP and the ITRF2014/IGb14 estimates include modifications, at least to some extent, events that modify these velocities. Here, interpret events as invariably meaning “significant” earthquakes.
At every data epoch, the mark a priori coordinates and velocity are projected to the epoch of the data thereby, from the point of view of the processing, minimizing the impact of crustal motion and other deformation especially if one uses CORSs as reference marks. The coordinates at the mean epoch of the data that result from the processing are projected to the appropriate reference frame and epoch using the aforementioned velocity models and HTDP.
Q: Can the CORS used for troposphere info be automatically picked by OP in any of the newer versions?
A: YES, it is highly likely that a future version of OPUS will (help) make the choice for a distant CORS. No release date is currently available, but the research and coding necessary to make this possible is underway.
Q: Are there any plans to update the FAA Advisory Circular AC 150/5300-16B to show the requirement of using OPUS Projects?
A: YES, the latest version of the FAA AC 150/5300-16B and accompanying Errata Sheet https://www.faa.gov/airports/resources/advisory_circulars/index.cfm/go/document.current/documentNumber/150_5300-16 show this change in the vector processing requirement. Vector Processing Requirements can be found in the AC-16B, Section 7.8
Q: I am trying to reprocess a campaign from Mar. 2018 and all of the CORS stations I usually use in SW Virginia are unavailable for processing in OPUS Projects. Is there a way to find out if there was some kind of massive system disturbance on that day?
A: YES, the CORS network provides a data availability tool to view individual stations, or you can scan the FTP site to see all stations which have data for any day within geodesy.noaa.gov/cors/rinex/2018/.
The NOAA CORS Network (NCN) is a cooperative network. The NCN data center acts as a common distribution point for the data from the included CORSs, but, in almost all cases, the NCN does not operate the CORSs. Each CORS has an associated station log (available through the NCN data center: https://geodesy.noaa.gov/CORS/) containing information about and a history of hardware at each station. Those logs could be used to search for commonalities, like hosting organization or nearly-simultaneous hardware changes, that could indicate a point-of-contact or point to a source. Spot checking, there are several host organizations responsible for the stations in SW Virginia arguing for a station specific issue. Spot checking a few CORSs in SW Virginia, all appear to be operational through March, 2018 except VABG which went offline February 1, 2018 and didn’t start sharing data reliably again until May 5, 2019. There is no indication of cause in its station log, so you would need to reach out to the host organization mentioned in its log.
Q: I tried to run an OPUS Projects network of 74 network primary control points for a major project in 36 sessions (538 static occupations) from June 8, 2016 to October 10, 2016. Mark Schenewerk advised me that Opus Projects was acting like it couldn't handle that much data. Is that accurate? Is that really too much data?
A: POSSIBLY. Slide 28 of the OPUS-Projects manager training intro slide deck ( geodesy.noaa.gov/pub/opus-projects/intro.pdf) states There are practical limits to a project’s maximum size. About 100 marks in a single session. Number of data files < a few hundred.
So, 583 static occupations is certainly encroaching into the “gray area” that is the practical limit for the web interface. But if the project web pages are still displaying themselves, then no - the project is not too big.
What are the symptoms? The web page display, particularly the manager web page display, will display, but the detailed contents are slow to populate. If the project continues to grow, your browser will start to a message like "This page cannot be displayed" from Internet Explorer or "Aw, Snap" from Chrome or ”Webpage is slowing down your browser: wait or quit” from Firefox.
What can you do? This is a browser issue. There is nothing that can be done from the NGS web server side. If possible, logically subdivide the project temporally or spatially creating smaller sub-projects. If this is not possible, consider switching to Firefox. Although NGS does not endorse any browser, Firefox currently seems to be more tolerant because of its “wait” option. Try working on the project in off hours. That might result in lower load on your local network and, indirectly, result in faster loading into your browser.
Q: Within OPUS Projects: 1) any plans to add a more user friendly way to evaluate individual CORS station integrity? (As opposed to opening additional web pages) 2)plans to output a datasheet of user submitted marks with images, coordinates, description, etc?
A: 1) YES, the CORS team is now addressing ways to share more base station performance metrics with users and OPUS, which should result in improved default selections and user-controlled and default base station selections.
2) YES, see https://beta.ngs.noaa.gov/datasheets/passive-marks/ which, along with OPUS shared solutions, are a prototype for datasheets delivered for the next reference frame.
Q: COULD YOU PLEASE EXPAND ON YOUR ANSWER ABOUT THE "SURVEY PROPOSAL" PROCESS?
A: See the Survey Project Proposal page; this form describes your intended survey project, enabling NGS to provide you with a tracking ID usable in OPUS projects, as well as customized guidance and support.
Q: One of future items of OPUS to provide solutions for projects (both RTK/Static) how will this compare to post processing software packages such as GrafNav? Is it meant to parallel or not? Or is OPUS meant to stand alone?
A: OPUS is meant to stand alone, and results should be comparable, but time will tell. The purpose of OPUS adding RTK vectors is to facilitate the use of that highly productive GNSS techniques to populate OPUS projects with survey data more efficiently, yet still access the National Geodetic Survey’s unique ADJUST and publishing capabilities. This feature is meant to allow submission of RTK data to NGS, and also, more generically, enable surveyors to ensure that their data are aligned with the National Spatial Reference System.
Q: What tools, resources, and best practice guides are available from NGS for a user seeking to set NSRS coordinates on their RTN base station that is not part of the NCN? (Nic Kinsman on behalf of her community at large)
A: See compilations at 1 March 2011 v. 2.0 Guidelines for Real Time Networks and Class Description RTN Administration and register for the pending 2021 webinar: opus-projects-rtk-rtn. As recommended in the v2.0 Guidelines, you could post-process 10 days of static GPS data logged at each of the RTN base stations in OPUS-S. Then average results to obtain coordinates in the NSRS. A more accurate method would be to upload at least 5 days of GPS data collected at each RTN base station in OPUS-Projects. Then, you can post-process the simultaneous data files logged at each RTN station and user-specified CORS. Afterwards, you can run an adjustment of the survey network to derive final coordinates in the NSRS. The National Geodetic Survey is also exploring ideas to develop a more-automated method for ensuring RTNs are aligned with the NSRS. This could include automatically processing daily data files logged at each base station in OPUS, and then providing a time series of solutions.
Q: If we coordinate with NGS and use the current version in Beta, will an adjusted RTN receive a certificate stating it is in alignment with the NSRS?
A: The logistics of certifying various networks is daunting; to date we’ve concentrated on tools and guidelines to help you align a network, but not to prove or promote it. OPUS can harvest observation data and publish the resulting coordinates, noting they are ‘TIED TO THE NSRS’ when sufficient quality is met. Certification might imply much more, that NGS agrees that you’ve used OPUS-projects correctly, have imported the resulting coordinates into RTN configuration properly, and that your RTN functions properly. If there is a simpler, fair and dependable way NGS can participate in recognizing well coordinated RTNs, we’re open to discuss it.
Q: We do a monthly OPUS project of our RTN stations, could we share the RTN stations with OPUS so that the results are published? Right, OPUS share. We would do this every month.
A: YES, that seems possible, though possibly more valuable via OPUS projects. Further, we may be able to stand up a simplified, automated process to support the appropriate monitoring of and reporting for such permanent networks.
Q: I would like to know the difference in VRS and OPUS and when it is best to use one over the other when setting temporary benchmarks on a job site.
A: A VRS is a type of network corrector method that a local or regional Real-Time Network (RTN) can provide. VRS can provide wonderfully accurate and productive surveying, where they exist, and when they are set up correctly. NOAA’s OPUS works worldwide, and is maintained to stay aligned to modern international reference frames, as well as the official US datums, through the use of more time-intensive static- and rapid-static survey techniques. You’ll have to make a professional choice, depending on your project goals and accuracy requirements. Based on some research conducted at NGS, we have found that a 5-minute VRS solution (in an RTN with an interstation spacing less than 70 km that is aligned with the NSRS) will have a horizontal accuracy less than 2.5 cm and a vertical (ellipsoid height) accuracy less than 5 cm at 95% confidence. These accuracies rival what can be achieved with a 2-h occupation post-processed in OPUS-S. Any occupation that is longer than 2 hours in duration and post-processed in OPUS-S will be more accurate than a VRS solution.
Q: Will the Vnetworks (in this case from DOT) eventually takeover from the RTK opus correction surveys? Thank you.
A: See answer above; and YES, if the RTN base station coordinates are correctly aligned with the National Spatial Reference System, then they will provide results to the stated accuracies above. Depending on your project needs and goals, you can choose which works best for you. However, if you wish to send your RTN data to NGS for publication, then you should upload your data to OPUS-Projects, run its adjustments, and submit your results. OPUS-Projects is currently the gate for sending RTN survey data to NGS.
Q: Should we wait until the Ephemeris is listed as "Precise" before we share data? This sometimes takes 2-3 weeks.
A: DON’T WAIT, for three reasons. One, the impact of precise orbits is minimal for most US solutions. Two, shared solutions are eventually reprocessed after tool or frame upgrades, and so will then use the precise orbits. Three, your memory of fieldwork only fades with time, so it is best to upload while your memory is fresh! That being said, our CORS team does wait for the precise orbits before running most network monitoring activities, as it provides the best results.
Q: When I share solutions and am submitting two separate 4hr. plus observations, should I submit my photos with both submittals? I only took photos with one of the observations.
A: YES, for now, each solution is treated as independent and each form requires two photos. It doesn’t check that your photos are unique, so if conditions are identical for the observations, YES you can re-use the photos. Note, we recommend taking lots of photos, and this provides you the opportunity to upload different views (e.g., north vs. south) if you have spares.
Q: Why is "not share" the default? Would it not make sense to include ALL data that is being used / processed by NGS to be included for all their processing?
A: GOOD QUESTION. For now, we are driven by prioritization and privacy; prioritization as we aren’t equipped to efficiently handle over a million shared solutions per year, and privacy, as we deem it most prudent to FORGET about user’s data once their task is complete. Future versions of OPUS may learn to at least temporarily share, buffering your solution for a brief period of time, giving you an opportunity to consider sharing once you see the solution yourself, and after we show you how it complements existing shared solutions.
Q: For OPUS Share- we have a 17 hour observation, but we can split into two 4 plus hour observations. Is there actually any benefit in submitting as two shorter observations vs 1 longer one?
A: NO AND YES. All things considered, it is better to leave an observation intact. However, you may wish to split an observation for our GPSBM project, to get double credit, thereby counting the bench mark as “DONE”.
Q: When observing an NGS station with PID as part of OPUS Share, can we get the published State Plane Coordinate and ellipsoid height with the Share results for quicker comparison?
A: EXCELLENT SUGGESTION. Today, for sharing, the values are available on separate reports, and the horizontal difference appears as a total NEAREST NGS PUBLISHED CONTROL POINT distance. OPUS-projects shows scatter plots for both horizontal and height, it seems smart to show these during sharing review too.
Q: Is there a way to reobserve a shared solution for multiple occupations?
A: YES - we encourage multiple submissions to OPUS Sharing. Your first solution of a mark will use the NGS datasheet’s PID or generate a new one. Use that PID with subsequent observation uploads and click Options > Yes, Share > [Upload to Static] > [mark has a PID]. Note, NGS doesn’t use these individual solutions to create a composite datasheet yet, but the next database should.
Q: Are there any plans to provide a points multiple OPUSshare coordinates/solutions in a tabular format. (instead of multiple webpages)?
A: YES. Today, shared solutions are available in two JSON formats, which can be converted into tables. See the OPUSmap’s OpusSolutionsForMap.js for all solutions, or View Shared Solutions for a JSON filtered by date, county, designation, etc. Later, as mentioned above, future versions of the database and datasheet will be able to make better composite use of these shared solutions.
Q: Will there be a way to update descriptions of OPUS-Shared marks. e.g. the mark has been destroyed
A: YES, one day, in the new database. For now, please send recovery notes by email to ngs.opus@noaa.gov and we will manually update damaged marks, e.g., for Datasheet BBBB68.
Q: Can you talk a bit about bluebooking?
A: The term ‘bluebooking’ refers to the act of creating and sharing specially formatted survey project observation, description, vector, and adjustment files in accordance with FGCS data format specifications, originally bound in a ‘blue’ binder. NGS has for 40 years provided software and guidelines for user generation and checking of these files, allowing them to submit their data to densify their portion of the national GPS and leveling geodetic control network. Very soon, OPUS projects will further simplify this task for GPS, and in a few years, leveling. See Survey Project Proposal for links to policy, guidelines, etc.
Q: Any plans for a mobile device app that makes it possible to search and view datasheets in the field
A: WE ARE MOBILE NOW! See the form at Submit Survey Mark Recovery Data. which also helps ‘Find Marks near me’. Many NGS advisors also enjoy the 3rd party BenchMap - App.
Note, marks shared via OPUS are not yet visible via most channels, but will be after NGS upgrades the database for the next reference frames. To prepare for recovery of marks shared via OPUS, see https://geodesy.noaa.gov/surveys/forms/obslog-OPUS.pdf
Q: Where is the mobile app for mark recovery?
A: See answer above.
Q: Why don't you just add a recovery option to your existing app?
A: See answers above; it isn’t clear which ‘existing app’ you mean.
Q: I don't see the "Mark REcovery" app in the Apple App Store?
A: See answers above.
Q: Was that an app for the phone or just the website?
A: WEBSITE, a mobile-friendly webpage that can (with your permission) use your cell phone’s GPS and camera, just like an app.
Q: On the Online Mark Recovery Form, for the pictures do we need to have the names in the format of PID-DESIGNATION-TYPE-DATE.jpg?
A: NO WORRIES, the form renames the photos for you.
Q: Is there a plan to upgrade description file creation? I'd like to see everything done in a collector app on my phone or on a web interface
A: YES, our goal is to make all in-the-field uses mobile friendly. We plan further improvements in how you describe the marks you are observing, and how OPUS identifies them.
Q: Mark Recovery Webpage - Marks Near Me - Can there be an option added to increase the search radius?
A: Technically possible; thanks for the idea. The mark recovery team will discuss.
Q: Could a stakeout feature using your phone be added to the map recovery form?
A: NO, probably, absent any geodetic use case. There are existing 3rd party navigation apps that might suffice, all would be limited by phone positioning accuracy.
Q: Can the mobile recovery website pre download existing mark data? We often don't have adequate cell service and Bench map doesn't do it.
A: NO, unfortunately. Preloading would require development of an actual mobile app.
Q: When would NGS like to have a user update the mark recovery? every visit? if it is damaged? Etc.?
A: INFREQUENTLY is best, though ALWAYS if there is any noteworthy change, e.g, you have better photos, or can say that a long-unrecovered mark still exists, or is suitable for GPS use.
Q: Are old USC&GS monuments that are no longer in your "Benchmark Locator" still better than a new made monument?
A: YES, from a geodetic network perspective, we prefer observations focused on existing monuments, but you should use those monuments that are convenient and appropriate for you.
February 11, 2021. Presenter: Philippe Hensel
Q: What are the criteria for CORS automatic selection? What are the criteria for adjustment?
A: CORSs are brought into OPUS Projects from the processing in OPUS Static: Data have to be available; CORS data have to be of good quality, and the CORSs have to be within a certain distance from the occupation location. As a result, often too many CORSs are brought into OPUS Projects. Once the CORSs are brought into OPUS Projects, the user should evaluate which CORSs should remain to control the entire project.
The criteria for using CORSs in the sequence of OPUS Project adjustments is to reduce the set of CORS to the very best 4 or 5 CORSs. You need to have the hub within 100 km of your user marks; the CORSs must exhibit low errors and be consistent with their published coordinates, etc. The manual provides an extensive presentation of criteria for selecting CORS. In the meantime, please see the ADJUST guidelines.
Q: Does OPUS Projects process baselines between observed stations, or is everything a hub from CORS?
A: OPUS can process any baseline between two stations (the hub can be chosen by the user to be any mark, User Mark or CORS). However, NGS recommends the use of a CORS as a central hub because it brings a full 24 hours of data to the project, used to compute baselines between the hub and the other CORSs in the project. Typically, GPS observations on user marks are much shorter than 24 hrs, so baselines between that given user mark and any other mark (user mark or CORS) will only be as long as the observation on that user mark.
Q: How would I incorporate HTDP values for PACS/SACS surveys in Alaska?
A: HTDP is run on every project. It’s done automatically for you! Session P2P values reference time of the survey, before HTDP is applied. Note that in the Solution Statistics table, P2P’s are shown WITHOUT HTDP applied. HTDP is applied in the network adjustment phase.
Q: Is there a preferred ratio of known to new marks? If you want to bluebook 5 new marks do you need to tie 5 known marks or 10?
A: Currently there is no “preferred” ratio. However, we are still recommending users follow the principles outlined in NGS 58/59 to achieve good ellipsoid heights and orthometric heights published to centimeter-level accuracy. So we still recommend you have a minimum of 2 known (published orthometric heights to Height Mod specs or leveling) within an appropriate distance from the new marks. Note that you would not have to tie to local control and you can still successfully process, using CORS-only. However, that is not recommended for publication.
Q: Is it useful to use Opus Projects on "GPS on Benchmark" observations?
A: The GPS on Benchmark program has a minimum requirement set by OPUS Share. However, if a user desired to use OPUS Projects to submit the survey to NGS for inclusion in the national database (the “IDB”), that would be great. There’s a lot more work involved, even if OPUS Projects now makes bluebooking so much easier. It’s still a lot more work than simply sharing one static 4+ hour GPS observation. For example, if you want to publish to the IDB, a proper campaign style survey is required and the ADJUST guidelines must be followed.
Q: How about RTK vectors - using the new GVX file format ?
A: As soon as the current Beta OPUS Projects will go to production, we will load new capabilities in OPUS for RTK on Beta.
Q: Where can we download the manual?
A: The manual is still under internal review, and is not yet publicly available. We will likely email attendees of this webinar when it is available, and/or you can sign up for NGS notification emails at https://geodesy.noaa.gov/INFO/subscribe.shtml.
Q: Can we use this for SACS and PACS?
A: Yes. The FAA AC 150/5300-16B https://www.faa.gov/airports/resources/advisory_circulars/index.cfm/go/document.current/documentNumber/150_5300-16, Section 7.8.1.1 lists OPUS Projects as the required vector processing software. NGS will assign an NGS Project Tracking ID following the review of an approved AC-16 Plan. This tracking ID will unlock all features of OPUS Projects and NGS will retrieve the project once it has been submitted. At this time, all AC-16 deliverables are also required to be submitted to the FAA Airport Data Information Portal https://adip.faa.gov/agis/public/;jsessionid=3A150D25A321EB64A56AD8134CDD7A88#/public under the FAA Project ID.
Q: How many GNSS receivers are needed to be used simultaneously in order to establish a network project. I would think most companies only have two to use at the same time.
A: The answer depends on what you want to do. If you want to adjust your real-time network, you don’t need your own receiver at all, and can just download data from the RTN. Otherwise, the minimum number of receivers is one! However, to take advantage of common-mode errors and to take the most advantage of the least squares adjustment in OPUS Projects, the more receivers, the better.
Q: When and how does someone get registered for OP101?
A: Please see the training calendar at https://geodesy.noaa.gov/corbin/calendar.shtml. The next class will be March 23-25, 2021, from 12:00pm - 4:00pm ET each day.
Q: What is the distance required to be when selecting a CORS that will help with the troposphere correction?
A: In the manual, we’ve proposed a distance between 375 and 800 km for troposphere decorrelation.
Q: Please repeat the Dummy ID# and info when appropriate.
A: The “dummy ID” that unlocks the advanced features of OPUS Projects is “0000.” It is identified in the online form under “Tracking ID” when creating your (Beta) OPUS Projects.
Q: Can we fully submit marks for publication and have them published through the BETA version?
A: Yes!
Q: I have an upcoming project where I was going to create an opus project, do you have to take the training to use opus projects now and when the upgrade takes place?
A: No, the training only needs to be taken once.
Q: If I create a project prior to upgrade then I can get in on current training, will the upgrade affect a current project in the non beta state?
A: Once Beta OPUS Projects goes to production, the new Manager’s Page will be able to assign a tracking ID (official NGS tracking ID or the dummy id “0000”) to the project, if a tracking ID has not already been assigned to that project. Projects created in the current production version of OPUS Projects would necessarily NOT have a project ID assigned yet, so once the transition occurs, this functionality would now become available.
Q: If we already have been trained for OPUS Projects will we be required to take OP101 and OP102?
A: If you have already taken OPUS Projects Manager’s Training, no further training is required. We will have training modules available for OPUS Projects 102, but they will not be mandatory. If you would like to take OPUS Projects Training for the first time or as a refresher, please see the Training Calendar at: https://geodesy.noaa.gov/corbin/calendar.shtml
Q: Can you upload just differential leveling data to OPUS for bluebooking or do you have to include GPS data also? Will new marks be assigned PIDS and when will it show up in the Data explorer on NGS website?
A: OPUS and OPUS Projects will only support GPS observations at this current time. In the near future, it will also accept real-time vectors. In the future, with NSRS modernization, OPUS will eventually be able to ingest leveling and total station data. Stay tuned!
When the description file is approved and loaded into the NGS Integrated Database (IDB), the new PIDs will be generated. The marks are uploaded manually into the NGS Data Explorer on a monthly basis. For immediate information, refer to NGS Datasheets: these are made available as soon as the GPS project is loaded into the database.
Q: Is OPUS bringing non-Constrained adjustment to UNITY applying GPS-FACTOR?
A: When running the horizontal free adjustment (i.e., a minimally constrained adjustment of the vectors) in OPUS-Projects, its least squares adjustment utility named “ADJUST” will automatically scale up the standard deviations of the vector components until the variance of unit weight for the adjustment equals exactly 1.000. This scaling is necessary, as standard deviations from GNSS baseline processing are notoriously optimistic. The technique is known as variance component estimation, and it is commonly employed in practice to deal with overly optimistic error estimation from baseline processing.
Q: Will you be able to input your own control stations and values to augment the selected CORS stations. [Later in the webinar….] Well, I guess the answer is no. I was thinking that if I had a passive geodetic control point for a public works project and occupied it for some sessions could I augment the selected CORS with this control.
A: There is no provision to “augment” the established CORS for a project, unless you mean adding a temporary CORS to your project. Temporary CORS will still appear as “User Marks,” not CORS. This mark can be constrained along with CORSs in your adjustment. Please reach out to the Bluebook Team or the NGS Infocenter if you want to pursue this question further.
Q: What is a recommended sample rate for the RINEX, 30 seconds?
A: OPUS-Static will decimate your Rinex file to 30 seconds, so that is all you need. NGS typically observes at 15-second intervals, but anything shorter is not necessary. Shorter intervals will create larger files that might take somewhat longer to process.
Q: can you start with the dummy ID and later switch it?
A: Absolutely!
Q: would GPS-only be recommended even when GLONASS is available on all session receivers?
A: Yes, as OPUS-S will only process GPS data - for now. NGS is currently developing the next generation of PAGES software to support multi-GNSS processing
Q: Do all sessions have to be at least 2 hours long?
A: Yes, we are limited by the current capabilities of OPUS-Static. Soon, however, you will be able to upload real-time vectors.
Q: Any improvements for remote locations with few, if any, CORS in the area where all are "Distant"?
A: There are no specific improvements that I know of. Unfortunately, we are limited to the available stations in the NOAA CORS Network and the IGS Network. In some parts of the world, their spacing is sparse. One way to mitigate this problem is to establish some temporary CORS in your project area so as to add more “24-h” baselines to your project for densifying control.