Recommendation 1

1. Recommendation 1 The IGS shall develop a standard protocol for exchanging information about IGS stations. The associated machine-readable database should be maintained by the IGS CB. Input to the database are stemming from • IGS station managers: reporting on all kinds of local site effects, tracking problems • IGS data centers: statistics covering data availability, data latency, completeness of data files and the consistency of the records in the RINEX header and the site logs • IGS analysis centers: reports on processing problems with specific stations • IGS working groups and pilot projects • Other networks sharing a common station with the IGS By accessing the database, the user will find out, using automated procedures, the most up-to-date information, as well as historical information, concerning the IGS stations. In case critical problems (metrics to be defined) are detected for a station, the IGS CB should send a notification email to the station manager.

2. Recommendation 2 The IGS station managers should • Announce when they make major changes at their stations, such as new antenna, etc... before the change is actually made (mandatory for IGS05 reference frame sites), except when an emergency happens. In all cases, site logs should be submitted to the IGS CB with a minimal delay. • Submit site pictures to the IGS Central Bureau; the pictures need to be updated when a change at the antenna, its monument or surroundings occurs.

3. Recommendation 3 The IGS Central Bureau is encouraged to • Reduce of the latency when updating site log files (important for ultra rapid and rapid products). An automated/web-based site log submission tool would help. • Maintain of a list indicating for each IGS station the type of calibration that is available for the installed antenna/radome pair (useful for antenna working group) • Provide for each IGS station a link to all info available for that station, e.g. other independent analysis, working group and pilot project results, time series, PPP results (useful for all users of the station data). Also a link to more general information like the discontinuity table, the latest cumulative coordinate and velocity solution is appreciated. • Maintain realistic IGS station maps based on data availability and not just site log availability • Maintain a list of 2-AC stations for a other ACs to consider.

4. Recommendation 4 The IGS acceptance process for new stations needs to • Define "critical world areas": stations from those areas (i.e. Africa, Antarctic, Hudson Bay …) that pass the major criteria should become IGS stations without question • Define and set up a procedure to regularize high quality non-IGS stations contributing to several AC solutions • Request site pictures (in all directions) before adding a station to the IGS network.

5. Recommendation 5 The IGS shall define and set up a process with all other networks who share a common station, to communicate with each other when there's a site log update.

6. Recommendation 6 • The IGS should consider trusting gatekeeper’s data directly and monitoring only the stations not already managed by a competent organization • The gatekeepers should be certified to be following the IGS standards (at least) through a simple questionnaire and regular spot checks • All the gatekeeper’s data should be IGS data • The IGS will then only deal with the gatekeepers for problems with those stations • Possible gatekeepers include: BKG, AUSLIG, GFZ, ESA, NRCan, JPL, NGS, IGN, SWEPOS, etc, etc, etc for either their entire networks or the parts that each gatekeeper decides

7. Recommendation 7 • A process to define and certify ITRF-quality stations • Global ref frame quality stations with specific requirements • (new Infrastructure Committee which could also automate the station configuration changes via web tools)