CORS Users Forum

Portland, Oregon

Sept. 9, 2003

NOAA’s National Geodetic Survey (NGS)—in cooperation with the U.S. Department of Transportation and the U.S. Coast Guard--hosted the third annual Continuously Operating Reference Station (CORS) Users Forum on September 9, 2003 in Portland, OR, with the theme “Requirements for CORS-like Networks.” This Forum convened in conjunction with the 42^nd Civil GPS Service Interface Committee meeting.

The Forum featured three short presentations followed by a question and answer session involving the panel of speakers. PowerPoint files for these presentations, as well as those delivered at the previous two forums, can be viewed at http://www.ngs.noaa.gov/CORS/information5/ . This Forum also featured a 1.5-hour interactive session for which the attendees reorganized into five separate discussion groups. Between 80 and 100 people attended the three presentations; the number varied from presentation to presentation. More than 40 people participated in the interactive session.

***************************************************************************

Forum Presentations

Marc Cheves of the Professional Surveyor Magazine prepared the following report on the three presentations.

CORS Program Status

Moderator Gerald Mader of NGS opened the session. Richard Snay, manager of the CORS program, gave an update and informed the audience that more than 700 sites are now providing CORS information, and the system is growing at a rate of seven sites per month. More than 110 organizations participate in the CORS program. 403 of these sites are part of the National CORS network, the data for which is available directly from NOAA’s National Geodetic Survey in Silver Spring, Maryland. Nine years of data is immediately available. After 9/11/2001, it was decided that back-up was needed for the data, and a parallel CORS data site is being established at NOAA’s National Geophysical Data Center in Boulder, Colorado. Snay discussed the Cooperative CORS program and said:

• The data includes GPS base stations whose data are freely disseminated by cooperating organizations

• NGS provides link from its website to that of each cooperating organization

• Site coordinates must be consistent with the National Spatial Reference System

.

Snay discussed the Combo CORS Network which is the overlap between the National CORS network and the Cooperative CORS network. He said:

• The term “Combo CORS” designates a station from which GPS data is distributed both by NOAA and by a cooperating organization.

• Such accessibility to CORS data is highly desirable.

• Scripps Institution of Oceanography (La Jolla, CA) distributes data for 650+ sites in the CORS network.

.

Snay discussed the 19 state agencies that partner in the CORS program, and said these include Spatial Reference Centers in California and Louisiana. Many GPS companies have developed software that provides their customers with automatic access to CORS data for postprocessing activities. Snay related a success story: the Denali earthquake which occurred on November 3, 2002, resulted in horizontal displacements on the order of 10 meters near the epicenter, and as much as 10cm at points located 100km distant from the epicenter. NGS was able to quickly re-adjust positional coordinates for CORS to maintain the National Spatial Reference System in Alaska.

.

Snay gave a primer on OPUS, and said NGS is developing a version of OPUS that will process GPS data that has been observed simultaneously at several sites. He discussed other recent OPUS upgrades and said:

• Users can submit compressed RINEX files

• OPUS can process data that is less than a day old

• Users can select one or more of the three CORS to be used as base stations by OPUS

• Users can select one or more Cooperative CORS to be used as base stations by OPUS

.

Snay also discussed the upcoming change in the way GPS data for CORS are compressed by saying:

• GPS data for CORS are now stored as compressed RINEX files using the “gzip” compression utility.

• NGS is proposing to compress such RINEX files using the “Hatanaka” algorithm followed by the Unix compression utility.

• Once implemented, NGS would support both formats for about six months, then, delete all the “gzip” files.

.

As for the impact of switching to the Hatanaka/Unix format, Snay said:

• The size of Hatanaka/Unix files equals 35% the size of equivalent gzip files (saving storage and enabling faster transmission of data).

• The Hatanaka/Unix format is currently used by several other organizations that store and distribute GPS data (compatibility).

• It will not affect users who obtain data via the UFCORS utility.

• It will affect users who obtain data via anonymous ftp (file transfer protocol)

University NAVSTAR Consortium (UNAVCO)

Will Prescott, President of UNAVCO, gave a report on the Earthscope Facility, which includes a CORS-like network for geophysics called the Plate Boundary Observatory. A cooperative effort among 30 universities, Earthscope will have an expected operational life span of 15 years (five years to build and 10 years to operate). Earthscope components include:

• USArray (US Seismic Array) – An Integrated system of seismic arrays to provide a coherent 3D image of the lithosphere and deeper Earth

• PBO (Plate Boundary Observatory) – Arrays incorporating an additional 175 strainmeters and an additional 875 GPS receivers to measure deformation near the North American and Pacific plate boundary

• InSAR (Interferometric Synthetic Aperture Radar) – Images of tectonically active regions providing spatially continuous strain measurements over wide geographic areas.

• SAFOD (San Andreas Fault Observatory at Depth) – A borehole observatory near the San Andreas Fault to directly measure the physical conditions under which earthquakes occur. The project will drill 4-km deep into the zone of microearthquakes at the nucleation point of the 1966 Parkfield M 6 earthquake.

California Spatial Reference Center (CSRC)

Greg Helmer, Chair of the CSRC Coordinating Committee, informed the audience that their goal will be an approximate 50km CORS station spacing across the entire state (much more dense in southern California and the San Francisco Bay Area), and 7km spacing along certain corridors.

The California Spatial Reference System will provide

• Four-dimensional data

• Geodetic Models

• Height Datums

• Data Distribution

• Education & Outreach

Helmer discussed the difficulties presented by the fact that the land west of the San Andreas fault is moving northwesterly at ±48mm per year. He mentioned several issues related to vertical datums. It’s not just whether to use the National GeodeticVertical Datum of 1929 or the North American Vertical Datum of 1988. Because some California users are ship pilots, and are interested in Mean Lower Low Water and not Mean High Water, it’s also an issue of tidal datums. The CSRC Portal (http://csrc.ucsd.edu) includes a map browser, RINEX data, coordinates, and NGS database access.

*************************************************************************

Reports for the five discussion groups follow:

Group 1: Reference Station Operation

Facilitators: Marti Ikehara and Miranda Chin

Participants:

Jim Killian Polk County Surveyors

Eric Berry Polk County Surveyors

Tina Kempe National Land Survey of Sweden

Dimitry Kolosov Topcon Positioning Systems

Bruce Peetz Trimble Navigation, Inc.

Spencer Reeder Central Washington Univ

James Stowell Leica Geosystems

Lt. Thom Harrington U.S. Coast Guard, NAVCEN

Roy Dokka Louisiana State University

Barry Irwin U.S. Geological Survey

Will Prescott UNAVCO, Inc.

The three most important requests:

1. Standardization

2. Outreach

3. Orthometric Height vs Ellipsoid Height

1. Standardization

Current Federal Geodetic Control Subcommittee guidelines need to be updated to incorporate state-of-art GPS survey technology. Modify existing standards and guidelines, incorporating new concepts into these standards. In particular, standards and guidelines are needed for monument design and data communications.

Standards and guidelines are needed for constructing a CORS: “What I want is to install a CORS that will be acceptable to NGS (and then for sending the data to NGS).”

Guidelines are needed for selecting a site, installing a monument/antenna, minimizing multipath, and increasing site stability.

NGS should compile and publish collections of Federal Land Usage guidelines, Federal and local environmental issues.

2. Outreach

A. Position accuracy

Let people know what accuracy they obtain when using CORS data. For example, if a surveyor needs to achieve 2-cm accuracy in the horizontal, then what needs to be done to achieve this goal. Needs can be different from geographical area to area.

Many people need only two-dimensional positioning.

B. CORS installation

Through the CORS web site: help people who are interested in establishing CORS to incorporate their stations into regional CORS networks. Cooperate with local communities to build regional clusters. GPS vendors can help too.

Educate people who want to install CORS.

C. Station status report

Provide up-to-date station status reports.

Grade the CORS sites according to antenna type, multipath, monumentation, etc.

Multipath information (in addition to site stability) should be made available so users would know the data quality.

D. CORS data grading

Problems on the Rinex header sections: Wrong site names are used. 'External' as antenna type name; users always need to edit.

CORS should provide data quality and quantity information to users.

Implement a procedure to make sure distributed files are usable.

Provide TEQC summary file to users.

IGS grades data by latency, quality, and quantity. CORS should do the same.

Multipath information of a specific site should be published.

E. Reference frame

One of NGS responsibilities is to maintain the National Spatial Reference System (NSRS). But it is local government and individual surveyors who need to comply with NSRS. Therefore it is very important for NGS to provide NSRS educational programs to the local government, CORS site managers, and surveyors.

It is NGS's responsibility to monitor dynamic changes of the reference frame.

3. Orthometric Height vs Ellipsoid Height

How do you transfer orthometric heights from CORS sites to a user’s location?

Calibration of the station.

How good is the current geoid height model? Locally.

Improve the geoid height model.

During the round of self-introductions, each person stated his/her main reason for participating in this discussion group:

Spencer: How to obtain permission from a state/federal government agencies for land/building use for installing CORS?

James: Standards and Guidelines

Jim and Eric: Information/recommendation for CORS installation; such as site selection, monument construction, system installation, etc.

Tina: a brief report of the Swedish GPS network. User fees are required.

Thom: How the U.S. Coast Guard can improve its service to CORS users.

Dimitry: Become familiar with the GPS communities that use CORS.

Bruce: Data quality, coordinate system change, data communication.

Roy: Orthometric height. Ways to help local communities make money by utilizing CORS.

Group 2: Data Access - Communications, Formats and Utilities

Facilitators: Gordon Adams and Dennis Milbert

Participants:

Karl Brown U.S. Geological Survey

Ron Buhmann NOAA’s National Geophysical Data Center

Ruizhi Chen Finland

Joel Cusick National Park Service

Mario Gosalvez PACCRST

Barry Irwin U.S. Geological Survey

Dick Karsky ????

Tim Lunde Boeing

Jim Sinko Stanford Research Institute

Georg Weber Germany

Peter West Trimble Navigation

Participant Input

- More CORS sites.

- More reliable CORS data posting. (Alaska site problem.)

- More 5-second sites.

- Objective is to make user’s job easier.

- Interface with vendor software (e.g. Trimble pathfinder)

- Better relationship between National CORS and Coop CORS. (that is, bring Coop CORS up to the National CORS standard, availability, reliability, position computation)

- Posting of CORS data, 5 seconds or faster.

- Aerial navigation requirement for 5 second data.

- More 1-second sites. (Several requests for this.)

- More stations with meteorological data.

- Make WAAS data available.

- Support wireless Internet data access.

- Real-time or near real-time, within 2 to 3 minutes.

- Allows users to be able to check data (work) before leaving the field.

- Better access to reference coordinates in machine readable format.

- 20-second format data files.

- Better presentation of products.

- Customer service via the web is hard to find.

- Better graphics for data availability.

- Better information on what stations are up and down.

- Better consistency for data downloading

- Different data providers use different file and directory formats.

- This would ease software development.

- 1-second data, needed to support tests of FAA and other systems.

- Transmit real-time code data via RF broadcast, i.e. support USCG funding for this.

- Useful in resource mapping applications.

- Real-time broadcast over the Internet.

- Lowers the equipment cost to the user, no RF equipment needed.

- Would want observables, orbits, meteorological data, correctors, etc.

- IGS has a working group on real-time GPS network using RTCM format.

- Real-time data with tie to a known reference frame.

- Wireless Internet capability.

- More metadata on station “health”.

- Will assist user diagnosing problems with solutions. (e.g. Glen Allen, AK site)

- Users have favorite vs. least favorite site which they use.

- Use the TEQC output as an indication of health.

- Make sure the GSAC format has the ability to indicate health.

- Would like a number or ranking to indicate health.

- Make sure the site contact information is up-to-date and easily available.

- Either from station log or on web page.

- Explain NGS National CORS site selection process and the requirements for becoming a National CORS site.

- Small errors in the data need to be monitored.

- Hatanaka

- UFCORS users will not be affected? (Correct.)

- Need to make a PC version of the translator available.

- Write a Windows utility that will register the Hatanaka file extension and run the un-compaction operation automatically.

- Is there a Mac version of RNX2CRX and CRX2RNX?

- What will be the format of the real-time data: RINEX, BINEX, RTCM, RTCA, receiver specific?

- Use of data from Y-code (encryption) capable receivers.

- Cleaner data.

- Less multipath.

Summary

Improving Existing Products and Services

- Reliability and health of a site.

- Data format standards

New Products and Services

- More 1-seconds sites

- Internet broadcast of data.

- RF broadcast of data from existing CORS.

Group 3: Applications, Outreach, and Technology Transfer

Facilitators: Gerald Mader, Curt Smith, and Tomás Soler

Participants:

DeLane Meier, North Dakota Department of Transportation

Greg Helmer, California Spatial Reference Center

Paul Hartzheim, Wisconsin Department of Transportation

Discussion Topics:

I. Applications:

1. There was a lot of discussion centered around OPUS.

1. NGS is getting out of the traditional brass monument technology.
2. OPUS, today, is not “sanctioned” by NGS and needs to be for surveyors to “buy off” on it.
3. Do people want their data made available in the NGS data base via OPUS?

a. FGDC geodetic control transfer protocol exists and OPUS would follow guidelines.

b. Only allow registered land surveyors to submit for NGS database?

4. CORS enables the users to establish their monuments.
5. L1 only OPUS solutions.
6. Output SINEX from OPUS so users could incorporate OPUS solutions (vectors) in their networks as control and indicate how to weight their points.
7. Multiple station simultaneous OPUS solutions.

2. There was some discussion about real or near real time CORS data.

A. Currently most CORS data is not available in real time.

2. The real potential of GPS is in real time results.
3. NGS “vision” does not include real time at this time.

i. Another agency would provide real time if NGS does not.

ii. Another agency might not provide real time in consistent coordinate system, i.e., not NAD83.

iii. Today individuals provide their real time mode which is generated from “their” base coordinates.

E. Real time capabilities will be driven by advancements in communications.

6. NGS cannot do everything.

3. Data storage and data collection rates were discussed.

A. Data storage and transfer is quite a burden collected at 1 second epoch rate.

B. Data collected at 1 second was decimated to 30 seconds and then interpolated down to 1 second with very similar processing results.

i. Data must be “clean” and free of cycle slips.

ii. Data collected at 5 second epochs may answer some of these issues.

4. Provide a metadata file for each CORS that could be reviewed prior to selecting that CORS for downloading or to use in an OPUS solution.

1. It was mentioned that the UNAVCO program TEQC already provides that type of information.
2. The metadata file could be distributed with the CORS data.

II. Outreach:

1. You can’t just talk about outreach you have to follow up and do it.

a. Training using the right tools for the application.

b. Create a formal program.

c. Approach issues from a regional aspect.

d. Target state society of professional surveyors, land information people.

e. Outreach topics could be CORS in general, OPUS, coordinate systems.

2. Need to reach non-traditional users.

3. There is a lot of input from outside of NGS for the new 2005 adjustment which will be very compatible with CORS.

III. Technology Transfer:

1. The question was asked about the orthometric height component of CORS.

1. Vertical connection is a local issue which can be better understood through education and outreach.
2. Ellipsoid heights, very well defined by CORS.
3. Improved relationship between geoid model and “local” orthometric heights.
4. Ellipsoid + geoid model + correction = orthometric height.
5. An improved geoid model and eventually the correction approaches zero.
6. This would be a “whole program” approach.

Group 4: Cooperative CORS

Facilitators: Julie Prusky and Don Haw

Participants:

Steve Briggs – Trimble Navigation

Dean Wilkerson – Arkansas Department of Transportation

Jill Johnson - Pierce County, WA

Annette De Paz - Newberg, OR

Les Olsen - Pierce County, WA

Hank ???

1) Education via workshops and Web pages

a. Reference frames - Confusion exists between the many different reference frames.

A brief explanation in laymen’s terms would be very helpful on the National and Coop CORS pages maybe in the form of a FAQ

b. Epochs - Confusion between Epochs, datum tags, and adjustment dates.

A brief explanation on CORS Web pages

c. States using old HARN’s vs. CORS - Oregon, one of a few states, uses NAD 83(1991). They do not plan to change until the new nationwide readjustment is complete. How does the CORS and NAD 83(1991) relate? What do the local surveyors need to know?

d. State advisors would be useful in every state.

e. Benefits to community and agencies.

Practical uses of CORS.

How does setting up a CORS benefit my community and what’s in it for me?

2) Let user know of new sites and changes. That way if an agency has $$ for CORS they can best determine where to establish one. The more information, the better. Get them on the map ASAP so communities know what is in the works.

3) Header Record / Standards - receiver, antenna name, directory structure, file names

Let manufactures know of changes before they occur, particularly changes that will effect existing programs.

Group 5: Ionosphere and Troposphere

This group included Seth Gutman, Joe Kunches and Doug Robertson, all with NOAA. Their input is documented along with other responses to a survey of 17 questions. These responses are presented in the next section of this report.

*****************************************************************************

CORS QUESTIONNAIRE

To help NOAA’s National Geodetic Survey (NGS) improve the National and Cooperative CORS program, we invited people to respond to a set of 17 questions. The following responses were received.

1: Name/Organization

(WP) Will Prescott, University Navstar Consortium, Inc.

(SG) Seth Gutman, NOAA’s Forecast Systems Laboratory

(JK) Joe Kunches, NOAA’s Space Environment Center

(DR) Doug Robertson, NOAA’s National Geodetic Survey

(MD) Michael L Dennis, Shephard-Wesnitzer, Inc., Sedona, AZ

(BF) Brian S. Fisher, President, Southwest Geomatics Inc., Phoenix, AZ

(TH) Thomas Homan, Gila County, AZ

(AB) Adrian Burcham, Salt River Project, AZ

(PA) Pettigrew and Associates, NM

2. If you currently use CORS data or you expect to use CORS data in the future, please describe your applications with a few words or sentences.

(WP) CORS data is often used for geophysical applications, to determine motion of the ground caused by: plate motion, earthquakes, volcanoes, subsidence.

(SG) Monitoring refractivity of neutral atmosphere (primarily the troposphere) for weather forecasting, climate monitoring, and other applications (e.g. satellite/sensor calibration-validation).

(JK) Monitoring refractivity of the dispersive atmosphere (primarily due to TEC in the ionosphere) for space weather forecasting.

(DR) Estimating ionospheric signal delay from retrieved TEC for integer fixing for high accuracy GPS positioning.

(MD) Have used CORS for survey-grade geodetic control for the last few years. Typical use is to tie a project to NAD 83 when other HARN control is not conveniently available. I also use CORS to constrain survey control networks. To a lesser extent, I have also used CORS to correct mapping-grade (code phase) data. I expect to increase my use of CORS for survey control and mapping-grade correction in the future.

(BF) Use OPUS all the time (3-10 times a month) to post process the base of RTK surveys

(TH) Densification/Height Mod within Gila County.

(AB) We have a CORS station set up (SRP1, PIDs AJ6820 & AJ6821) and use the data to post process stations for Surveying, as well as broadcasting RTK corrections.

(PA) Here in SE New Mexico we use CORS to control our projects. The area is very friendly for GPS work and we use it extensively. However, in this area there is very little published control. So we have to resort to the CORS for control data for our networks. Sometimes these networks cover 30-40 miles of route at a time.

3. What level of accuracy is needed for your applications? What does this level of accuracy enable you to do?

(WP) Daily position (24 hour average) with precision of 1 mm horizontal, 5 mm vertical desirable. This allows us to determine and examine both secular motion (trends lasting for many years) as well as look at transients with characteristic time periods of weeks to months. We also use higher frequency positions with lower precision to look at sub-daily effects or signals in the seismic bands (less than 20 second periods).

(SG) Accuracy currently provided by dual frequency geodetic receivers and multipath resistant antennas in the average CORS site environment is sufficient to estimate integrated precipitable water for all currently envisioned applications. Possible future estimation of slant path signal delay may require measurement accuracy similar to the requirements specified by JK & DR.

(JK & DR) Minimized (cycle slips due to) multipath. Pseudorange multipath (< 0.1 cycle). P1 not C1 observations.

(MD) For survey control, I want the highest accuracy possible, say 1-2 cm horizontally and 2-5 cm vertically, or better if possible. This level of accuracy allows use of multiple CORS for constraining survey networks, and facilitates use of GPS for deriving orthometric heights (i.e. height modernization).

(BF) centimeter - decimeter level accuracy. The positions are used to check published stations, and also used to tie RTK (autonomous base setups) data to geodetic systems.

(TH) Horizontal = GPS ‘A’ and ‘B’ to set up for RTK work for section and quarter section work

(AB) Centimeter level or less

(PA) We typically look for cm to sub-cm accuracy. This gives us the greatest mobility. By doing this we never push our surveys beyond their intended purpose in the event we have to expand.

4. What type of station distribution is needed for your applications in terms of coverage area and/or station spacing? What does this station distribution enable you to do?

(WP) Broad coverage at 100-200 km spacing is valuable for providing a framework for local studies. In specific areas of interest (deforming zones within 100 km of faults or volcanoes) spacing of 5, 10, or 20 km is often desirable.

(SG & JK & DR) Regular distribution with approximately 100 km station spacing in Alaska, Canada, CONUS, Mexico, Caribbean. Operational atmospheric monitoring over North America.

(MD) I find CORS most useful when it is within 50-80 km or so of my work areas, although I don't think this is a realistic expectation in general. The biggest obstacle I have for reliably using CORS is the distance, because I usually operate in rural areas. Very long occupations are necessary, and even then high quality fixed-integer solutions can be very difficult to obtain. This varies quite a bit --- sometimes the solutions are good, sometimes not, even under apparently very similar conditions (ionopsheric activity?).

(BF) It would be nice to have shorter occupation times (i.e. less than two hours). Having some sort of post-process kinematic option on OPUS might also be nice. I don't know the logistics of being able to do that though.

(TH) Would prefer 150km spacing or better to reduce observation times. This would allow more rapid placement of stations.

(AB) The station spacing should be typically 100 to 200 km spacing to allow for the shortest occupation times of control points for post processing

(PA) We typically set our control points at a 6-mile interval. This gives us optimum coverage for RTK practices.

5. How frequently should CORS data be sampled for your applications? (Indicate all applicable choices)

(WP) Every 30 seconds & every 1 second

(SG & JK & DR) Every 30 seconds

(MD) Every 30 seconds & every 15 seconds & every 10 seconds

(BF) Every 15 seconds & every 1 second

(TH) Every 30 & every 15 seconds

(AB) Every 30 seconds

(PA) Every 15 seconds

If you need CORS data sampled at a rate faster than every 30 seconds, then how long should NGS store these data online for easy retrieval assuming that corresponding data--that has been decimated to a 30-second sampling rate--will be stored online for several years.

(WP) one year

(MD) one year

(BF) one year

(TH) six months

(PA) two months

6. Would you be willing to use interpolated CORS data, if these data are sampled at a slower rate than what is needed for your applications?

(WP) No

(SG & JK & DR) No

(MD) No

(BF) No

(TH) Maybe

(AB) Yes

(PA) Yes

If yes, what would be the slowest rate (for the pre-interpolated data) that you would be willing to accept? If no, then briefly explain your rationale.

(MD) My only reason for saying "No" is my lack of knowledge (and thus comfort) regarding the accuracy of interpolated data.

(BF) I don't totally understand what errors could result from interpolated data, so, showing my ignorance, I would not want to use it.

(TH) I would need better understanding of how interpolated data would shift accuracy-wise.

(AB) 30 seconds

7. How soon after the observation of CORS data do you need these data for your applications? (Indicate all applicable choices)

(WP) Within days. Usually, data available after the close of the UTC data is satisfactory. If available, data within hours can be useful during events (earthquakes, eruptions).

(SG & JK & DR) Within minutes

(MD) Within hours & within days

(BF) Within hours

(TH) Within hours & within days

(AB) Within days

(PA) Within hours

8. Briefly describe your special requirements for the quality of CORS data.

(WP) Clean cycle slip free and multi-path free data are preferred.

(SG) Quality currently provided by CORS dual frequency geodetic receivers and multipath resistant antennas in the average CORS site environment is sufficient to estimate integrated precipitable water for all currently envisioned applications. Possible future estimation of slant path signal delay may require data quality similar to the requirements specified by JK & DR.

(JK & DR) Minimized (cycle slips due to) multipath. Pseudorange multipath (< 0.1 cycle). P1 not C1 observations.

(MD) Very high quality full wavelength, dual frequency observables in RINEX for solving GPS vectors at centimeter-level accuracy. I've noticed some CORS have data with far more cycle slips and poorer tracking than others, for example FERN.

(BF) I use the data to post process RTK autonomous base locations. High accuracy

(centimeter) results are required.

(TH) None

(AB) CORS data needs to be of the best quality to assure that everything that I set off of it has the best accuracy and precision that I can give it.

(PA) It needs to be a level of accuracy good enough for us to incorporate RTK on the derived control points.

9. Briefly describe your special requirements for the environmental setting of a CORS site.

(WP) We require very stable monuments to detect small signals over long periods of time. Braced, deeply anchored monuments (Wyatt-design) are preferred. Antennas mounted on towers are of much less value. Sites with stable antennas (i.e. no or minimal changes of antenna or antenna height) are most valuable.

(SG) Nothing special.

(JK & DR) Stable site, minimum of multipath

(MD) Low multipath, unobstructed sky, very stable antenna mounting.

(TH) None

10. Briefly describe your special requirements for the functional capabilities of an individual CORS site (in terms of hardware, firmware, auxiliary equipment, communications, etc.).

(WP) A good antenna with a ground plane that suppresses multi-path is preferred.

(SG & JK & DR) To minimize data loss and insure data continuity, we think that if data is going to be streamed, it should be streamed to and stored on an on-site collector (e.g. a PC or the receiver) rather than interfacing the receiver directly with a communications device.

(MD) No special requirements.

(BF) RINEX data is all I need. Mostly I just use OPUS.

(TH) None

(AB) We use our CORS site also as a permanent base station for RTK surveying.

(PA) The equipment needs to be standardized and provide data in a usable format.

11. Briefly describe your special requirements for the functional capabilities of the CORS data center located at NGS headquarters in Silver Spring, Maryland.

(WP) None

(SG & JK & DR) GPS (space and tropospheric) meteorology is, with high probability, going to be implemented operationally within the National Weather Service in the next 2-5 years. If CORS data is going to be used as part of a national network, provisions need to be made to insure 24/7 uninterrupted data flow with high reliability.

(JK) Provisions should be made to provide at least 30-sec data in 5 min sessions with < 5 min latency. Data should be in Rinex-2 or equivalent format.

(MD) No special requirements.

(BF) Keep OPUS up and running.

(TH) 24-7 data access w/ potential for off-site mirror

(AB) The data center needs to perform quality control monitoring of all of the CORS sites. It also needs to archive and maintain the data from those CORS sites.

12. Briefly describe your special requirements for CORS metadata (equipment type, on-site contact, geological setting, etc.) and/or for auxiliary information (orbits, weather, geoid model, crustal motion models, etc.).

(WP) Complete equipment metadata and history are invaluable. Sites with stable antennas (i.e. no changes of antenna or antenna height) are most valuable.

(DR) More information about the quality of the observations themselves, to include number and location of cycle slips, RMS noise, data dropouts, and possibly use or reject recommendatations.

(MD) Besides RINEX data files, I need precise ephemeris files, "unambiguous" ARP definitions and antenna model descriptions/graphics, superceded coordinates (with dates and epochs), datum transformation parameters.

(BF) No specific requirements at this time.

(TH) None – existing metadata is sufficient for my needs

(AB) Knowing which receivers and antennae are at each site helps with the post-processing of the data. Each type of software that I have used to process the data needs to know what kind of data it is processing. I have not had a need to utilize the onsite contacts. Usually the website has all of the information that I need.

(PA) We use this data to adjust/correct our returned coordinates to fit our needs.

13. Briefly describe your special requirements for CORS data accessibility (in terms of data formats, the directory structure for online storage, file naming conventions, data retrieval utilities, data compression utilities, etc.).

(WP) Consider supporting BINEX files

http://www.unavco.ucar.edu/data_support/software/binex/binex.html

(SG & JK & DR) no special requirements.

(MD) Very satisfied with the data accessibility.

(BF) FTP of RINEX data. File structures / naming is good. I have high speed internet access, so the zip files are not a necessity.

(TH) None – Formats work ok with existing software.

(AB) So far, the data accessibility has been fine. I especially like the “User Friendly CORS” retrieval option.

(PA) It just needs to be in a usable format.

14. Briefly describe your special requirements for CORS-related services (help desk, training, documentation, etc.).

(WP) None

(SG & JK & DR) a help desk

(MD) More details on antenna characteristics which are easy to access and clear.

(BF) I would like training on using the PAGES software. We've told Dave Minkel (AZ NGS rep) about this before also.

(TH) None

(AB) The CORS set up requirements documentation were very helpful and easy to follow when we set up our CORS station

(PA) Having this data is great for answering questions without having to consult anyone.

15. Briefly describe any suggestions for improving the CORS program.

(SG & JK) Provisions to support operational GPS use within NOAA’s National Weather Service. Support to include data collection, network monitoring, quality control, and hourly predicted orbits.

(MD) Suggestions:

a. Improve antenna descriptions and cross-referencing in logfile (e.g., give link to actual NGS antenna web page, not just the overall antenna calibration site). Especially important to ensure that ARP definition is crystal-clear. For examples that seem unclear, see logfiles for COSA, FERN, and FRED, and compare to datasheet info (e.g., What does it mean when COSA says changed ARP to BPA? Why is there a non-zero ARP (or BPA) in some of these logfiles? How does BPA differ from ARP? I can't recall what BPA means --- is it "Bottom of Pre-Amplifier"?). The whole antenna ARP thing seems more confusing and ambiguous than it should be. Is there any way to make it clearer?

b. Add ARP information to datasheets, including URL to actual antenna.

c. Give superceded coordinates (with date of change and epoch of reference frame) in both the coordinate sheet and the datasheet. Presently, it's not clear when the superceded coords in the datasheet were determined, and no superceded coords are given in the coordinate sheet.

d. Improve QA/QC with respect to raw observables, to ensure data collected is of high quality (e.g., FERN cycle slips/poor tracking --- at times it's as if the antenna is set up under trees, although I know it's not).

e. Add more CORS as funding allows.

(BF) More stations. Post-processed kinematic as an OPUS option (shorter observation times).

(TH) Possibly adding the provision to enter the site Lat/Lon at the start of the UFCORS page. This would then put the closest 5 CORS sites first in the site picklist followed by the rest.

(PA) The turn-around time on the data would be great if it were down to hours instead of days.

16. Has CORS provided you with the ability to accomplish tasks that were previously unattainable or impractical? Are you aware of any non‑standard or creative uses for CORS data? How may we find out more about these uses?

(SG & JK & DR) GPS-Met is an example. If sufficiently accurate observations are collected and made available in near real time, CORS data permits rapid expansion of network at low cost to NOAA. In addition to its application in space and tropospheric weather forecasting, assimilation of CORS data into atmospheric models make it possible to produce real-time signal delay correctors for HA-NDGPS. It may also be possible to use these models to improve NEXRAD precipitation estimates, improve strong convection and lightning forecasts, correct imaging radar data for change detection, and create more accurate digital elevation models.

(MD) CORS is increasingly making it easier to rigorously tie my surveys to the NAD 83 datum. Without CORS, it would often simply be economically unfeasible to tie many of my surveys to geodetic control, especially since many stations are of lower positional quality, far from project sites, often difficult to access, and disappearing due to development and vandalism. CORS

is wonderful.

(BF) It has made tying all jobs geodetically a practical option. OPUS is probably the coolest thing I have ever seen, and I love it! I am a pretty basic user, but I have started to catalog my jobs (land boundary, topo, etc.) tied to SPC/NAD83.

(TH) Yes – It has allowed us to more effectively utilize surveyor resources. A crew can go out to RTK and we can process the base station after the job is complete to come up with a good horizontal position. Otherwise we would have to static in the point before hand.

(AB) CORS stations become a free receiver in the mix of doing static networks. They provide known, quality coordinate information.

(PA) Yes, it has enabled us to use state plane coordinates for all of our route surveys. No, I have not looked into non-standard uses of these data.

17. NGS now stores GPS data from the National CORS network as RINEX files that have been compressed using the “gzip” utility. In the near future, NGS is planning to also store GPS data as RINEX files that have been compressed using the “Hatanaka algorithm” followed by the “UNIX-compress” utility. Once all existing GPS data from the CORS network are available in the “Hatanaka/UNIX” format, NGS would support both formats for about six months. After this transition period, NGS would delete its GPS RINEX files that are in the “gzip” format. This transition would greatly reduce the disk space needed by NGS to store CORS data. Also, the “Hatanaka/UNIX” format is used by several other organizations that distribute GPS data. Please provide concerns about this possible transition.

(SG & JK) no concerns.

(MD) My only concern is the availability of a utility to un-compress the file ---hopefully one would be available for free (or for a nominal fee). Other than that, it does not matter to me how the data are compressed.

(BF) As long as I have access to the 'un-zip' utility (free download) I as an end user don't care what format you archive the data. As I stated before, I have a high speed internet connection, so when given the option, I download the 'big' file just because I can / it saves a step on my part in that I don't have to un-zip it after download.

(TH) I currently submit to you in gzip format. The Trimble Reference Station software does not have a provisison to support this format internally. Will you be working with the software vendors to provide a no-cost upgrade to support the new storage format. Alternatively, will I continue to supply data in gzip format and NGS will repackage as necessary? Will you be ‘suggesting’ to the GPS software vendors that they add support for the ‘d’ file on the RINEX import so users don’t have to run a separate piece of software prior to importing RINEX?

(AB) As long as the decompression utility is available, I do not have any problems.

(PA) Is this supported by most systems? We do not support self-extracting zip files because of virus concerns. Therefore, I am concerned about how the new system will work.

NGS’ Response to Input

The CORS Team thanks the people who participated in this year’s Forum or otherwise provided suggestions for improving the CORS program. We notice two dominant themes underlying many of the suggestions: standardization and education.

Regarding standardization: NGS is now working with several GPS vendors and with the organizations that operate individual CORS to develop better standards for (1) naming CORS data files, (2) formatting CORS data, (3) organizing CORS data for multiple stations and multiple days into electronic directories, (4) compressing CORS data files, (5) identifying GPS antennas, and (6) addressing other matters. Adherence to standards is especially important for the viability of the Cooperative CORS network where GPS users access data directly from organizations other than NGS. Clearly, all data distribution sites in the Cooperative CORS network should have a similar look and feel.

Regarding education: NGS is planning to create an electronic CORS Handbook that would be readily available via the World Wide Web. NGS has insufficient staff to teach the thousands of people that are regularly using CORS data. Hence, our strategy will be to teach the teachers. We hope that the CORS Handbook will provide pertinent information for teachers in academia and private industry, as well as to individual GPS users. This handbook will be a “living” document that is updated regularly as technology evolves.

Let us take this opportunity to thank the many partners who contribute to the success of the CORS program. Currently, more than 110 organizations operate one or more stations in the National and Cooperative CORS network. For a list of these organizations, please see the CORS Newsletter at http://www.ngs.noaa.gov/CORS/ .

The CORS Team