Working Session 1: Reports from the EPN Coordination Group (Central Bureau, Analysis Coordinator and Special Projects)
Working Session 2: LAC's reports
Working Session 3: Experiences with new processing strategies
Working Session 4: Site, receiver and antenna issues
EPN LACs should introduce the APCV simultaneously with the introduction of the APCV at the IGS level. At the same time also the switch to the ITRF2005 will be done. When for a specific antenna/radome combination the APCV are not available, the APCV values for the antenna without radome code should be used and this fallback should be indicated with the dome description "NONE" in the "+SITE/GPS_PHASE_CENTER" block of the resulting SINEX file. The "+SITE/ANTENNA" block should correspond to the actual installed radome type. The procedure was described in IGS-Mail no. 5272 and is also applicable to distinguish between individual and type calibrations for receiver antennas.
EPN LACs are asked to do a parallel processing with relative PCV and APCV during a period of 2 weeks preceding the official switch.
At the introduction time, the APCV used within the EPN will be based on the IGS APCV table (table in ANTEX format, e.g., igs05_1325.atx), but complemented with the missing APCV for the EPN stations. EPN LACs will preferable use the APCV from robot calibrations of GEO++ company in Hanover, Germany, if the values are available within the scope of EPN. Legal permissions will be checked with GEO++. The EPN CB will browse through the Geo++ APCV data base each time when Geo++ updates its calibration tables (currently every 6 months) and identifies, if APCV have become available for antenna/radomes installed at EPN stations. In the case EPN stations are affected, the LACs will be requested to introduce the new APCV simultaneously, provided EPN gets the legal permission for it.
The LACs propose that new EPN stations should only be accepted in case their antenna/radome is absolutely calibrated. Not all antenna/radome calibrations included in the IGS APCV table have been absolutely calibrated; some are derived from the previously existing relative values.
CODE will send out two mails with explanations on how to introduce the APCV in the Bernese 5.0. The mails will include the recommendation to first pass through a preparatory step, in which still relative PCV will be used, before introducing the APCV. The preparatory step will allow a straightforward introduction of the APCV afterwards. It is imperative that the LAC verify that after the preparatory step (using the relative PCV), no coordinate changes occur. There is now a converter within Bernese 5.0 available to transform the IGS ANTEX file into Bernese internal formats. CODE will additionally provide the APCV in the Bernese format.
LACs that use a software others than Bernese have to perform the switch to APCV as well. ASI confirmed that the Microcosm software will be suitable.
LACs are asked to start estimating tropospheric gradients simultaneously with the introduction of the APCV. The estimated gradient parameters will have to be pre-eliminated from the TROP SNX file before submission to the combination center because the file format does not support the gradient parameters. The estimation of tropospheric gradients is not mandatory for LACs using a software other than Bernese.
In order to gain experience with GNSS data processing, the LACs can add GLONASS observations to their GPS data analysis, under the condition that they carefully verify if their results are not degraded (with respect to the orbit information used). The Bernese PCF RNX2SNX is already designed for GPS+GLONASS processing.
The LACs recommend that within the EPN obsolete GPS equipment is replaced by combined GPS/GLONASS(/Galileo) equipment and propose to assess this recommendation with a resolution at the EUREF symposium in Riga (June 2006).
There is a general agreement between the LAC that a re-processing is necessary. The LACs are asked to prepare in the near-future for a re-processing. The actual re-processing will take place when the IGS will have done its re-processing, so that we have new improved orbits available.
Postpone the discussion and wait for real-time software.
NRT processing is useful for a quick monitoring of station coordinates. EPN LACs doing NRT processing could submit hourly SINEX files to a central place where these coordinates are checked and alarms are generated when outliers occur. The information could then be made available at a web site. This general idea is supported, but is needs to mature a little bit more.
EPN LACs with contacts to national mapping agencies (NMA) are asked to start processing the NRT GNSS data from the dense national networks in order to contribute to NRT meteorological applications (TOUGH/E-GVAP).This NRT computation makes sense because there is a real synergy of coordinate monitoring and ZTD generations.
The IGS recommends using the FES2004 model for ocean loading instead of the presently used GOT00.2 model. The EPN CB will maintain a file (BLQ format) with the FES2004 ocean loading parameters at its web-site. The LAC are asked to switch to the FES2004 model together with the switch of the APCV/ITRF2005.
The EPN LAC solutions are presently generated using an elevation cut of 10°. Presently, the proposal is to keep these 10°.
IGS will introduce a new version of SINEX (2.0). Consequences for EPN analysis will be observed.
It was proposed to establish a "rapid EPN combination product", which follows a strict time table without waiting for missing LAC contributions. This product aims to provide an EPN coordinate solution with a significant reduced delay. Details will be discussed in the near future.