by Carine Bruyninx, Royal Observatory of Belgium


Session 1: LAC Reports
Session 2: EPN Special Projects Reports
Session 3: Processing Strategies

Summary of Discussions/Action Items


Presently the datum of the weekly EPN solution is determined by fixing station coordinates. Should we replace this datum definition by a minimal constraint solution ?


The disadvantage of the fixed station approach is that the network solution can be degraded when problems appear in one of the fixing stations. The meaning of "minimal constraint solution" in this context is to setup no-network rotation and translation conditions for selected stations in the least squares parameter estimation. A minimal constraint solution would also require a set of reference sites, but it would be less sensitive to problems with these reference sites. For that reason, the minimal constraint approach is preferred above the fixed-station approach. In this case, each LAC will have to use 4-5 stable stations (with reliable ITRF2000 coordinates that are weekly updated using the ITRF2000 velocities) for the datum definition in order to guarantee the datum definition at the few mm level. A comparison between the two approaches for weekly EPN solutions showed, that the alignment of the full network will not change, but the coordinates of the reference stations may change.

Recommendation 1:

To fix the datum of the EPN solutions, as well as the individual LAC solutions, the minimal constraint approach is better than the fixed-station approach. Using the present version of Bernese, it is not be possible to apply this minimal constraint approach. This topic will be re-discussed when the next Bernese version will be released.


Should the LACs additionally submit daily SINEX files in order to perform a daily combination of SINEX files ?


The access to the daily SNX files from the LAC would be interesting to improve the outlier detection. In addition, by also keeping the troposphere parameters in the daily SNX files, a fully consistent EPN coordinate and troposphere solution can be generated. The goal is to study short-term effects in time series.
From a geophysical point of view not much is to gain by submitting additional daily files, since most geophysical effects have periods below one day.
Presently, however, it will not be possible to exploit the daily SINEX files to their full potential because of the poor datum definition (see topic 1) of the subnetwork solutions.

Recommendation 2:

In order to evaluate the use of daily SINEX submission by the LACs, H. Habrich will invite the LACs to participate to a test campaign (~8 weeks).
The final decision on the daily SINEX submission is delayed until the results of the test campaign are available and the datum definition of the subnetworks has improved.


Who is using the weekly ETRS89 solutions? Should we recommend a pre-transformation from ITRFxx to ITRF2000 before the transformation to ETRS89 to prevent the rotation in the ETRS89 which becomes visible since the usage of ITRF2000 ?

Recommendation 3:

Discuss these topics it at the next meeting of the EUREF Technical Working Group.


How can the EPN improve the height component to better support ECGN, TIGA and ESEAS ?


The height component can be improved by :

  • Modeling the effect of atmospheric pressure loading (effects up to 2 cm on daily basis). The input necessary to perform this modeling will be provided by the IERS Special Bureau for the atmosphere
  • Using absolute receiver and satellite antenna PCVs (requires Bernese V5.0 and see topic 5)
  • Estimate the troposphere gradient components and use an elevation cut off angle of 3 degrees (requires Bernese V5.0 to output the tropospheric gradients into the SINEX format)
  • Add the data of the GLONASS satellites to the processing (see topic 6)
Recommendation 4:

Contact the IERS Special Bureau for the Atmosphere and inform them about EUREFs interest for the modeling of the atmospheric loading.
Other methods to improve the height improvement can only be implemented when using the Bernese V5.0.


Should the EPN apply absolute receiver and satellite antenna PCV ?


The implementation of absolute receiver and satellite antenna PCV corrections requires the Bernese V5.0. It is expected that in the future, most software packages will be able to add absolute receiver and satellite antenna PCV corrections in the processing.
In Germany, there is presently pressure to use absolute phase centre variations. It is clear that the EPN should apply them because they improve the results. However, this should be done simultaneously (same GPS week) with the IGS. Presently the IGS has not fixed a schedule for the implementation of the absolute PCVs. The main factor is that presently GPS cannot give the scale and there is a one to one relationship between scale and the use of absolute PCVs. AIUB and TU Munich will soon start to solve for antenna phase centre variations (unique in the world). Results of these tests will be shown at the IGS Workshop 2004 in Berne next year so that within the IGS the discussions will be pushed. The change within the IGS is expected somewhere in the next year. Important is that all PCVs are used (both offsets and variations) for both receivers and satellites. An alternative is only to use the absolute offsets without the variation at both sides (rec. & sat).
Remarks about possible consistency problems between solutions with absolute PCVs and those with relative PCVs :

  • What about the users of EPN solutions (generated using the absolute PCVs) who are themselves still using the relative corrections ?
  • What about the combination of future EPN solutions with for example data from uncalibrated L1 antenna ?
  • Orbits that are based on absolute patterns could have a scale change. It is unclear if people using relative patterns can use these orbits.
Recommendation 5:

Absolute receiver and satellite antenna PCVs will improve the EPN solutions. However, their implementation should be coordinated with the IGS and will therefore at least be postponed until the next IGS workshop in Berne, March 2004.


Should we introduce GLONASS observations in the EPN subnetwork solutions ?


About 11 EPN stations have GPS/GLONASS receivers and as such, GLONASS data are now part of the EPN. By integrating GLONASS data into the EPN, we will gain a lot of experience and be well prepared for Galileo.
Since it will be necessary to form GLONASS baselines, it is possible that the EPN subnetwork distribution will have to be reviewed. In addition, the GLONASS orbital information is not yet a part of the IGS official orbit product. We should wait for this before generating routinely any GLONASS product. It is not clear when IGS will introduce the combined GPS/GLONASS orbit product. ESA is already planning to do something similar as CODE (common processing of GPS/GLONASS). This will certainly stimulate the generation of the IGS GPS/GLONASS orbit product. An alternative for the IGS orbits could be the CODE GLONASS orbits.

Recommendation 6:

H. Habrich will invite the LACs to participate to some test computations adding GLONASS data to their subnetwork solution.

7.1 Should we allow solving for tropospheric gradients ?


With the present version of Bernese ADDNEQ does not allow saving the tropospheric gradient into TRO SINEX format. The next version of Bernese will allow this. It is expected that the gradient estimation will improve the horizontal position of the stations with a factor 2 (proven by test solutions from CODE). This factor 2 is for the daily solutions, for the weekly solutions, this averages somewhat out.
In order to estimate troposphere gradients, your subnetwork has to have a minimal size.

Recommendation 7.1:

It is to soon now to know what to do. Better is to wait and gather experience with the new Bernese software version.

7.2 Are there any alternatives to the weighting scheme that is presently used to create the EPN Combined Solution ?


Presently a mixed (static and dynamic) weighting is used. It includes empirically derived weighting factors, which dislike from scientific point of view. Within the IGS, the weighting is dynamically and derived from the weekly combination where the weight is based on how good the individual solution agrees with the combined solution.

Recommendation 7.2:

H. Habrich will look into how the IGS is doing the waiting and investigate whether it can be used for the EPN combination.

7.3 Should we introduce satellite dependent weights, e.g. the accuracy codes as given in the IGS orbits ?


There is not too much experience with this yet. EUVN97 tests did not show a specific improvement. It is worthwhile to do tests, but it is unclear if the quality of the satellite accuracy codes is good enough and if the software is ready to handle them correctly.

Recommendation 7.3:

Presently, the use of satellite dependent weights needs further testing and should be rediscussed in the future.

7.4 Should we reprocess the EPN ?


BEK will do it anyway, because there is an internal interest beside their contribution to EPN. SGO supports it but will wait for new Bernese 5.0. Both in TU Dresden and TU Munich a reprocessing of the IGS network will be started in the beginning of next year using absolute PCVs in order to compute new orbits. It is better to wait for these new orbits.

Recommendation 7.4:

Although a complete reprocessing of the EPN would improve the overall consistency of the time series, it is recommended to wait for a final decision on the absolute PCVs and the new Bernese V5.0, which will include new processing options that will improve the overall quality of the computations.

7.5 Should we use the radome-dependent receiver antenna calibration values that IGS issues into the EPN processing ?


Instead using only the name of the antenna to define its calibration values, the IGS has now issued calibration values that take also into account the radome used. Users of the Bernese 4.2 can however not apply these corrections since the field defining the antenna type in the Bernese has only 16 characters. Microcosm and Gipsy users could maybe apply these corrections. However, it needs to be clear what they are doing.

Recommendation 7.5:

The EPN LACs that use software other than Bernese should test the radome-dependent calibration values and inform the Analysis Coordinator about this so that he can test for inconsistencies between the different solutions.


The University of Civil Engineering, Faculty of Geodesy, Bucharest, Romania (FGB) is interested to become a Local Analysis Center of the EPN.


It was discussed, whether the number of LACs should be limited. From scientific point of view only few, but large sub-networks have to be preferred, because the correlations between the stations are more correctly introduced into the least squares adjustment. But to spread the analysis on many nations makes the EPN to a multi-lateral project. Some questions concerning the analysis software installation and the access to Bulgarian GPS permanent stations have to be answered, before FGB could become operational.

Recommendation 8:

The proposal for a new LAC in Bucharest at FGB was generally accepted. The plenum of the Workshop became convinced to favor the distribution of the EPN analysis to many European nations against the scientific aspect of a common solution. FGB will contact the EPN-CB if it is prepared to start with the analysis. After that, a sub-network will be designed.