## CORS Users Forum

**Portland, Oregon**

**Sept. 9, 2003**

![](media/image1.jpeg){width="6.4in" height="3.5875in"}

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)

![](media/image2.png){width="7.2in" height="4.915277777777778in"}

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.

![](media/image3.jpeg){width="4.107638888888889in"
height="4.883333333333334in"}

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.

A.  NGS is getting out of the traditional brass monument technology.

B.  OPUS, today, is not "sanctioned" by NGS and needs to be for
    surveyors to "buy off" on it.

C.  Do people want their data made available in the NGS data base via
    OPUS?

```{=html}
<!-- -->
```
a.  FGDC geodetic control transfer protocol exists and OPUS would follow
    guidelines.

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

```{=html}
<!-- -->
```
D.  CORS enables the users to establish their monuments.

E.  L1 only OPUS solutions.

F.  Output SINEX from OPUS so users could incorporate OPUS solutions
    (vectors) in their networks as control and indicate how to weight
    their points.

G.  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.

B.  The real potential of GPS is in real time results.

C.  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.

F.  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.

```{=html}
<!-- -->
```
i.  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.

A.  It was mentioned that the UNAVCO program TEQC already provides that
    type of information.

B.  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.

A.  Vertical connection is a local issue which can be better understood
    through education and outreach.

B.  Ellipsoid heights, very well defined by CORS.

C.  Improved relationship between geoid model and "local" orthometric
    heights.

D.  Ellipsoid + geoid model + correction = orthometric height.

E.  An improved geoid model and eventually the correction approaches
    zero.

F.  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