CC BY
99
УДК 629.783:551.24 Reiner Jäger
Faculty of Geomatics, Hochschule Karlsruhe - Technik und Wirtschaft (HSKA), Germany Member of RTCM Working Group Transformation Messages 2004-20007, Germany Member of FIG WG 5.4 GNSS-Networks, since 2008 Simone Kälber
THE NEW RTCM 3.1 TRANSFORMATION MESSAGES - DECLARATION, GENERATION FROM REFERENCE TRANSFORMATIONS AND IMPLEMENTATION AS A SERVER-CLIENT-CONCEPT FOR GNSS SERVICES
Abstract
As concerns the use of RTCM observation correction data in GNSS positioning services, the coordinates are resulting within the ITRF or in a regional ITRF-realization (e.g. ETRF89) as geocentric (x,y,z) or ellipsoidal (B,L,h) coordinates. The users of GNSS services must however normally present their results in the coordinates of regional or local horizontal and vertical datum systems. Therefore, coordinate transformations are necessary. Currently, the pre-calculated transformation parameters and/or geoid-models have to be transferred in advance to GNSS controllers in particular ways. Such are the transfer of transformation parameter databases with a direct access on the GNSS-controllers, or the mapping of a desired reference transformation and/or geoid into a discrete so-called grid and its transfer to the GNSS-controller by the user.
The aim of the transformation messages of the recent 2007 RTCM 3.1, and so that of the RTCM working group (composed of representatives of GNSS industry, GNSS-services and science) behind, respectively, was to define transformation algorithms and data structures, which allow the GNSS service to transmit respective RTCM transformation messages to the user of the GNSS service. In that way and by the transformation messages’ use in the GNSS -controllers, the above ITRF-based coordinates can automatically be transformed to the desired horizontal datum and height reference system, and the above preparation of a data transfer and further manual operations during the GNSS-measurement become obsolete. Further, the GNSS service providers are able to ensure, that unique and current information for the computation of the different transformations is used.
The software and communication architecture for the use the RTCM transformations messages in a GNSS service can be realized as a server-client concept. The desired reference transformations are implemented within the so-called transformation modules and as part of the RTCM transformation messages server. The networking software of the GNSS service administrates the distribution of the transformation messages. In that way, the NMEA-position of the GNSS-rover is used as as the basic server request and it is passed through the administrating GNSS networking software to the RTCM transformation messages server. Depending on the configuration of the RTCM transformation messages server, different transformation modules are activated and different message design specifications are holding. Accordingly one or several binary RTCM transformation messages are generated and send via the GNSS network software back to the client of the GNSS-controller.
The paper describes the so-called reference transformations by the mathematical models, algorithms and data structures. The various reference transformations (continuous transformation parameter databases, grids, plate transformations, geopotential models, DFHBF, DFLBF, databases of original fitting points, etc.) are divided into three different categories. The concept of gridding using virtual fitting points generated from the reference transformations for a set up of RTCM transformation messages is treated. The difference between static grids and the general and powerful dynamic RTCM grids is discussed. Finally the results of the use of the RTCM server GZTraS with the active configuration for DFHBF/DFLBF databases as reference
transformations of the transformation modules in country-wide tests in the area of Bavaria, Germany, are presented.
1. Introduction
1.1. Situation before and without RTCM 3.1 Transformation Messages
With the global process of the installation of GNSS positioning services, such as SAPOS®/ asms (www.sapos.de; www.ascos.de) in Germany (fig. 1.1), CZEPOS in Czech Republic (czepos.cuzk.cz) and many others in Europe and worldwide, GNSS positioning services have become an interdisciplinary and indispensable application for a high precise geo-referencing.
Figure 1.1: Bavarian part of the German SAPOS®/ascos GNSS-reference-station
network
Figure 1.1 shows, as an example, the Bavarian part of the GNSS-reference-stations network of the German state positioning service SAPOS® and the private service ascos, operating in a private public partnership (PPP), using more or less the same GNSS-reference-stations. The present generation of GNSS-services provide high accurate RTCM correction data, and so enable a 3D online-
positioning on typically a (1-3) cm level of positioning accuracy in the ITRF-related frame, such as ETRF89 in Europe. The precision of positioning is still increasing due to a further improvement in the RTCM correction data modelling in different ways (Virtual Reference Station (VRS) [1], Area Correction Parameters (ACP) [2] and the recent Master-Auxiliary Concepts MAX/i-MAX
[3]). The respective further development is favoured by the competition of the developers of the different GNSS networking software packages. Using the above RTCM correction data, the determined precise positions of the users are resulting in the same frame of the regional ITRF-realization (e.g. ETRF89), which is used for the coordinates of the GNSS-reference stations (fig. 1.1) of the service, namely as the geocentric coordinates (x,y,z)ITRF-reiated, or equivalently, as the geographical coordinates (B,L,h) ITRF-related. In the following we use the abbreviations (x,y,z)GNss and (B,L,h)GNss for the ITRF-related GNSS-position.
The users of GNSS services must however mostly present their results in the target CRS (coordinate reference system) of the classical horizontal datum (B,L)Classical, as well as in the classical height system, where the heights H refer to a physically defined height reference surface. The height reference surface (HRS) for H is related to the gravity-potential of the earth, namely a geoid or a quasi-geoid, which is represented by its height N((x,y,z)GNSS) over the ellipsoid related to GNSS, namely the GrS80 or the wGs84 ellipsoid. Therefore datum transformations leading to (B,L)Classical and surface-transitions from the ellipsoidal GNSS-height h to the height H over the HRS as target CRS are required. The datum transformation and HRS transition methods shall briefly be classified in the following.
On substituting the locally geometrically similar shaped surface of the HRS by the ellipsoid of the classical target system, it is possible to perform the surface transition from hGNSS to H - implicitly - together with the datum transformation (B,L)Classical in one step by the model of a seven parameter similarity transformation generally called 7 PT (tab. 1 (1)). In practice the approximation hclassical = H requires, already in smaller areas, residual interpolation, and so dense physical fitting points, or instead an independent HRS-model N((x,y,z)GNss) to generate by H= hGNSS - N((x,y,z)GNSS) fitting point heights, for the computation of the one-step 7 PT (tab. 1, (1)). Generally, and especially by the approximation hclassical = H, the accuracies for the plane and height component are quite different, and this requires the consideration of an adequate stochastical model in the parameter-estimation
[4]. The problem of a different scale in the plane and height component can easily be solved e.g. by using the equivalent Molodenski similarity transformation ([17]), related to the geographical coordinates (B,L,h), instead of the well-known cartesian ones, and by introducing there two different scale parameters (“8 PT”) [4]. The approximate one-step 7/8 PT model (tab.1, (1)) suits however, more or less, only for small areas without producing too large residuals in the height-component. So a 7 or a 8 PT - no matter if in the cartesian or the Molodenski type - with only one parameter set requires for large areas an additional complex large-residuals-treatment, in order to preserve a precise type of transformation model for the plane and the height component. So the large residuals treatment, which is burdened with
additional errors and hypothesis arising from the applied interpolation methods, becomes an essential component (“third-party”) of the transformation model (tab.1, (1)) for medium and large areas. The alternative way to avoid the above “third party” component is the partitioning of large areas into FEM-meshes with individual sets of 7 or 8 PT and continuity conditions along the mesh borders (so-called CoPaG/DFLBF, see [17], [18]). This leads to small and uncritically interpolatable residuals.
The general and approximation-free way for the GNSS-heighting -considering also, that in many countries the 7 PT datum-transformation becomes obsolete for the horizontal component (B,L) by the introduction of the ITRF-based CRS as standard (source and target) CRS for horizontal positioning - is however to decouple the height transition from the 7 PT, and to use a HRS-model N((x,y,z)GNSS) according to the standard-formula H = hGNSS - N((x,y,z)GNSS) (tab. 1,
(3)).
If in addition to the GNSS-heighting transformation type (tab. 1 (3)), a precise datum transition from (B,L,h)GNSS to the plane component (B,L)Classical is required, there are several ways, to split of the influence of the approximation hclassical = H (tab. 1, (1)) for the resulting plan component (B,L)Classical. These are meant with the datum transition type tab. 1, (2). The first one is to use the FEM partitioning model CoPaG/DFLBF ([17], [18]), as described above, and to omit the height result H, on using instaed a HRS model tab. 1, (3). The second one is use the 7 or 8 PT also for large areas above by considering the approximation hclassical = H in a proper area-size adapted stochastical model for the plane and the height component of the fitting points. Typically is to use e.g. ^h,classical = ±i.0mfor area sizes of 300 km. The third one, is to change the geo-
referencing to a modern precise HRS model N((x,y,z)GNSS) from the ECEF/ITRF-related frame Ngnss to NClassical in the classical datum by a Molodenski like datum transition dN( d) and NClassical = Ngnss + dN(d). This modelling enables also the approximation-free consistent modelling hclassical = H + NClassical in a one-step 7 PT (or 8PT). Here the resulting hclassical may be used to receive H as H = hclassical - NClassical . In practice and literature that third way is rather known, but it is in use [23]. Avoiding and solving, respectively, the problems concerning the HRS surface transition for the height-component by these two additional ways, which existing besides the FEM method CoPaG/DFLBF, they both go ahead with principally large residuals occurring also for the plane component in large areas ([17], [18]).
All in all, and as discussed above, there are three kind of model categories for a transition from the source CRS provided by the GNSS-services to a target CRS, namely
- Three-dimensional datum transitions from (x,y,z)GNss to ((B,L)Ciassicai, H)
- Three-dimensional transitions to (B,L)Classical or locally permitted twodimensional datum-transitions from (x,y,z)GN8s to (B,L)Ciassicai
- HRS models N((x,y,z)GNSS enabling GNSS heighting by H = hGNSS -
N((x,y,z)GNSS).
To enable the full and precise transformation to the target CRS (B,L)Classical and H, all three kind of GNSS-transformation models above require the use of so-called fitting points concerning the computation of the respective model parameters. Fitting-points are physical points, which are known in the source CRS (x,y,z)ITRF-related and in the target CRS. Depending on the kind of model three-, two-or one-dimensional fitting points (B,L)Classical, H), (B,L)Classical and H are explicitly required, or can arbitrary be used simultaneously, respectively. Depending on an additional use of further data-sources (like deflections of the vertical, gravity observations for the computation of HRS models) the required density of the fitting-points is quite different. So within the above three categories the individual model and the resulting precision on the respective transformation from the source CRS (B,L,h)GNSS to the target CRS ((B,L)Classical, H) are characterized and depending on the following factors:
- Density and accuracy of the original database of fitting points
- Parametrization p with respect to different kind of fitting-points (1D, 2D and 3D) to be included
- Power of the approach and parametrization p with respect to provide the use of further data in addition to the fitting points
- Treatment of continuity conditions if required
- Capacity and methods of the interpolation of the residuals r
- Representation of the final model for the datum- and surface-transition database (discrete grid, parametric model, see tab. 1).
There exist various parametric models for the above datum and surface transformations. In the following we call any pre-calculated datum and surface transformation model, as well as any kind of HRS-model N enabling the transition(s) to ((B,L)Classical, H), a reference-transformation, tab. 1. The named examples, like DFHRS [17], [18], DFLBF [17], [18], EIGEN [19], EGM96 [20], EGG 97 [21], BKG Quasigeoid [22], which are included in tab. 1 for the different mathematical models and the final representation of their parameters, as well as concerning their use in the GNSS-rover, are to be understood and used as placeholders for many other approaches for these categories.
The existing approaches and different types of reference transformations tab. 1, (II) with the unique input, tab. 1 (I) and the three different output-components tab. 1 (III) have presently already been used for years as proved transformation concepts in the GNSS-rovers. This is enabled by either the direct access to appropriate parametric representations of reference transformation or by “gridding” them to a so-called field grid (tab. 1, IV; chap.
2.2.1). In order to preserve the use and setting up of the different reference transformations as RTCM transformation messages, the common manner of an access by means of a grid-concept was decided to be used as mathematical model behind the RTCM 3.1 transformation messages (chap. 2).
Table 1: Present situation and capacities of online transformations in GNSS-
networks
I. ITRF- based II. Referen- ce III. Targets and Direct Results IV. Final Mathematical Model of Representation and Examples V. GNSS-rover Data interface
Source CRS Transfor mation Types
„Grid only“ Parametric Griddin g Enabled Parametric Representati on Grid
(B,L)clas sical and H (1) Most DFLBF All DFLBF All
(B,L,h)GNS S (B,L)clas sical (2) Most DFLBF All DFLBF All
- N with H = hGNSS - N (3) BKG Quasi- Geoid; EGG97 EGM96 EIGEN DFHRS All EGM96 DFHRS All
Fig. 1.2: FEM mesh-design and accuracy over Brazil for the computation a DFLBF-parametrization and -database useable as reference transformation of type (I) and/or (II), tab.1 and for the setting up RTCM 3.1 transformation messages
Currently, the above pre-calculated reference transformation types (
Table 1, (1), (2), (3)) have to be transferred by the user to the GNSS-controller, if an online transformation from the ITRF-related source CRS (B,L,h)GNSS to the horizontal (B,L)Classical and/or to the vertical system H as target CRS is required. Hereby the rover-software can either use a direct access to the specific parametric reference transformation (e.g. EGM96, DFHBF, DFLBF), or handle a so-called grid-representation (chap. 2.2.1, 2.2.2) of a reference transformation (
Table 1), in order to perform the transformation from (B,L,h)GNSS to (B,L)Classical, and / or H. The “gridding”, namely the setting up of a so-called rover field grid from any individual reference transformation to a grid-representation, which is interpreted by the GNSS-rover software, is to be done in the so-called “grid-factory”. The “grid-factories” provided as software modules belonging to the GNSS-office packages [6], or as external modules [7], [8], enable the use of any of the above reference transformation types as being mapped to the grid structure of the rover field grid.
1.2. Targets and Capacities of the RTCM 3.1 Transformation Messages
The declaration of the recent set of the seven RTCM 3.1 transformation messages 1021 - 1027 ([5], [11]) comprises different algorithms and data structures, which allow the GNSS service to provide their users with all necessary information for a transition from position (B,L,h)GNSS in the ITRF-based source CRS, provided by the GNSS-service, to the target CRS referring to another horizontal datum (B,L)target and physical height system H. So the above preparation work (chap. 1.1), namely the transferring of transformation-parameter databases to the rover, or the computation of field-grids in advance to the GNSS-measurements, and further manual operations during the GNSS-measurement become obsolete by the RTCM 3.1 transformation messages.
The GNSS service providers are so enabled to ensure, that unique and current information for the computation of the different transformations is used. Principally this does not have to lead to limitations or restrictions in the coming positioning era of applying the RTCM transformation messages on the user side. A first reason for being off limits is already settled in the mathematical models of the RTCM messages, because the algorithms and data-structures (chap. 2.1, chap. 2.2) for setting up the different RTCM transformation messages, which were developed by the RTCM Working Group on transformation messages in the years 2004-2007, can map any original reference transformation (
Table 1). The second reason is settled in the communication architecture between the components GNSS-user, GNSS-networking software and the RTCM-server represented by different so-called transformation modules [12]. Let us assume the moment, that a RTCM transformation module (fig. 3.2, fig. 4.1) on the server side can supply only one complete set of RTCM transformation messages (e.g. 1021 and 1023) based on a specific set of reference transformations and pointing to one target CRS [12]. In that case, however, different transformation modules, thereby different reference transformations and as well different target CRS (fig. 3.2, fig.
4.1), may be connected to different server ports of the TCP server, so there is no limit for the user. A third reason is, that the RTCM 3.1 transformation message structure itself is prepared for supplying different reference transformations and different target CRS, using the internal so-called SIN-numbers (System Identification Numbers) [11]. Equivalently or together with the use of different server-ports (fig. 3.2, fig. 4.1), the use of the SIN-numbers allows to generate and broadcast by one RTCM-transformation module and one data-stream up to 256 messages (SIN = 1 to 256), and so to apply different CRS and the use of different reference transformations in one rover request (fig. 3.2). The kind of messages behind different SIN can be configured in the transformation-module and RTCM-server of the GNSS-service, respectively.
There are many examples and services, where either the external switch to different ports (fig. 3.2; fig. 41.) or the RTCM-internal SIN-counter can be used. In case of using SIN-numbers, the decision, which transformation to use is to be met on the rover side by selecting the transformation type desired by the user in the rover-software. Examples for the use of different server-ports, or different SINnumbers, are e.g. to supply countries like Brazil (fig. 1.2), where at the same time four classical target CRS are existing at one place (SAD96, SAD69, CoregoAlegre 69 and 72) [9]. Other examples are holding for Germany, and all other European countries, where at the same time the different old height systems H [10] and then new European normal heights - meaning different HRS N((x,y,z)GNSS) and RTCM-based HRS-transitions - are existing in parallel.
Thus, both for the GNSS-services, and for the GNSS-service users, the new RTCM 3.1 transformation messages enable a high flexibility with respect to the offer and the use of an increased number of reference transformations as well as an increased number of GNSS-transformation services.
2. Transformation Algorithms
2.1. Message Types and Data Structures
The RTCM 3.1 Transformation Messages ([5], [11]) declaration consists of seven different messages, namely the message types 1021 through 1027. The messages were defined for the above application of a datum-transformation and/or a HRS transition of the ITRF/ECEF-related source CRS, which is provided by a GNSS-positioning service, to another target CRS and a respective projection. As mentioned above, the GNSS-position in the CRS is described as (B,L,h)GNSs . The geographical coordinates (B,L) and heights H of the plane and height target system in regard, above and finally the classical datum systems
(B,L)Classical and the physical HRS-related H, are described in the following by (B,L)T and HT. In that way, we are consistent with the notation of message declarations, and indicate, that there may exist also intermediate target systems, which have to be interlinked in subsequent transformations (chap. 2.2.3.), before arriving at the representation of a final position in the target (T) CRS.
1 5 2 3 6 7 i 1 4 Acp - 8
9 (<po A0 or N0, E0) 10 11 1 Atp , 12
AA ¿A i L AA
13 14 15 Atp , 16
Fig. 2.1: Area of validity and grid design with respect to the origin ((p0 = b0, ?H) = l0) or (n0,e0) and the grid-width (Acp = ab, aa, = AL) for the RTCM grid-based messages couple 1021 (or 1022) and 1023 (or 1024)
According to the three types of reference transformations tab. 1, (1), (2) and (3), and the above datum transformation and surface transition tasks to be solved, the RTCM-transformation message representation is sufficiently represented by the 7 PT of a three-dimensional similarity transformation and an associated “residual grid” (fig. 2.1, fig 2.2). The associated residual grid carries in its 16 nodal-points the three-dimensional plane and height (residuals) values. In this way it can be used both for the representation of a 3D /2D or 1D “surface” related to true residuals, as resulting from the RTCM-gridding (chap. 2.2), as well as for a physical surface’s presentation, namely the 1D HRS N((x,y,z)GNSS) (tab. 1, (3)).
The basic mathematical components of the grid-based representation of the RTCM 3.1 transformation messages are all together:
- RTCM 7 PT parameters p,
- RTCM-grid residuals r, =(5B1,5L1,5H1)T or r, =(5N1,5E1,6H1)T after subtracting so-called mean values (AR AE- AH)
- RTCM-grid based surface representation N, = N() + 8N, stored equivalently to the height residuals as N0 =: AH and 6N, =: 8h,.
All above components are evaluated in the process of RTCM-gridding (chap.
2.2.1) from a number n of virtual fitting points [(B,L,h)GNSS | (B,L)T , HT or N)]i,
which have been generated for the grid-positions Pi (i=1,n) by making use of the above reference transformations (chap. 1.1, tab. 1). In case of setting up an RTCM grid, based on the rover request (fig. 3.2, fig. 4.1) around the rover position (fig.
2.2), the number of grid points is n=16 (fig. 2.1, fig. 2.2). The rover position is controlled - either by the rover-software or by the GNSS-networking software -and reaching a rover-position in the 10% border area of the grid (fig. 2.2), a new NMEA-based request for receiving a new set of RTCM-messages is sent to the RTCM server (fig. 3.2, fig. 4.1) ([5], [11]).
O 1 l 5 > < 2 1 O 3 4 ’ t;i
IP 1 ■ " / / / / / JO / Z * P IP 11 12 ij. i _
IP 1 V ' 1 % P M i6 ^
Fig. 2.2: RTCM residual grid (message 1023 or 1024) definition
Within the seven RTCM-transformation messages, the two message types 1021 and 1022 provide the above basic transformation parameters p, namely the parameters of different types of three-dimensional similarity transformations. The message 1021 supplies the parameters p either for a nonlinear cartesian, or a linearized Cartesian and or an abridged Molodenski-based datum transformation, the message 1022 for a Molodenski-Badekas based datum transformation. The type of the above 7 PT is identified by the so-called computation indicator of the messages. The messages 1023 and 1024 define the residuals for the grid, either related to the ellipsoid and in arc-seconds (message 1023) or to the metric “plane” grid (1024 ), 1024 according to the projection types defined messages 1025 to 1027). The message types 1025, 1026 and 1027 define the parameters for standard projections, and for Lambert conic conformal projections, oblique Mercator projection and others, respectively. At a minimum, the GNSS-service provider has to send out either message 1021 or 1022, followed by either message 1023 or 1024. These messages are carrying the complete transformation information. The additional information contained in the messages 1025, 1026 or 1027 specify only the projection type and its parameters. So these are only needed to enable the GNSS-rover to map the resulting transformed plane positions (B,L)T to the
Northern (N T) and Eastern (E T) coordinates related to the projection type of the target (t) CRS.
2.2. Setting up of RTCM-messages
2.2.1. RTCM-Gridding and Application
The above so-called virtual fitting points [(B,L,h)GNSS | (B,L)T , HT or N)]i are represented by the reference transformations chap 1.2, tab. 1. In case of a gridding, the virtual reference-points are situated on a regular “plane” (B,L)-grid (fig. 2.1, fig. 2.2). In the case of the RTCM-messages, the regular grid is defined in the target system (B,L)Ti , so that - without loss of generality for the gridding-concept -the grid-points transformed to the associated source system (B,L)GNSS,i are shaped slightly irregular. The virtual fitting points in the source (B,L,h)GNss,i are generated in a loop running over the latitude and longitude extension of the grid (fig. 2.1; fig. 2.2).
The height hi associated with the plane grid (B,L)GNss,i has to be chosen approximately according to the topography of the real measurement scenario, in order to receive the correct set of virtual fitting points [(B,L) , H or N)]T,i in the target system. This holds for most of all of the parametric types of reference transformations (tab. 1), e.g. for quasigeoid models N((y,y,z)GNSS) of the HRS. In case of any kind of gridding - also in case of a “grid-factory” based computation or the pre-computation of a static RTCM-grid (chap. 2.2.2) - an approximate height hGNSS,i = Hi + NGNSSi can always be taken from free DTM databases, like ETOPO5 [27] for Hi , and free HRS data, e.g. EGM96 or EIGEN ([19], [20]) for NGNSSi. In case of the dynamic RTCM-grid generation (chap. 2.2.3) the grid heights hGNSSi can easily be derived from the NMEA-request of the rover (chap. 3, fig. 3.2), which is computed as being centred to the RTCM-grid (fig. 2.2) for the time of the request.
The starting point of the gridding procedure is the generation of n virtual fitting-points in the source CRS and the target CRS using any single, a couple, or even a sequence of reference transformations (chap. 2.2.3.1), reading:
(B,L,h)GNSS . => [(B,L)T, HT or N]i i=l,n (1)
Re ferenceTraisfor-mation (s), tab. 1
The different types of reference transformations (tab. 1) and their individual representatives behind (1) are used abstractly, namely as sources to generate the number of n virtual fitting points in the target system (T). The quality measures for the reference transformations applied in (1) are the provided accuracies [(aB,aL), aH oraN ]T i. These are used to set the so-called quality indicator for the plane and height transformation of the RTCM grid-representation. A regional variation (fig.
1.2) leads to varying quality indicators, both for the static and for the dynamic RTCM messages.
The above 7PT parameter vector p = [s | cpx, cpy, cpz |tx,ty,tz] of the grid-representation removes by the scale s, the rotations(cpx,cpy,cpz) and the translations (tx,ty,tz) of the three-dimensional similarity transformation, the datum trend
between the source CRS (S) and the target system (T), which are represented by n sets of virtual fitting points (1). In case of the nonlinear Cartesian 7 PT the functional model for the estimation of the parameters p reads:
xx V x V
yT + ry = s R y + tx a) (2 ,n i=
_zT_ T,i Jz_ i z GNSS,i Jz_
where the right handed rotation matrix R is defined by
R-RzRyRx -
coscpz -sin (pz 0
Sin (pz coscpz 0
COSiPy 0
-Sin (Py 0
cos
9y
0
COS(px — sin (p?
0
sin cpx coscpx
(2b)
As concerns the transition of the ellipsoidal height hGNSS from the source CRS to the height HT in the target CRS, the so-called height indicator is part of the datum parameter-related messages 1021 and 1022.
Gridding for RTCM Height Indicator = 1
A value 1 for the height indicator means, that besides the datum transformation for the plane component (B,L)T , the 7 PT (2a,b) shall also provide the physical heights H T in the target system (T). For the computation of that kind of RTCM grid representation, leading to the plane position (B,L)T and the physical height HT for the rover by a 7 PT, the virtual fitting points (1) HT,i first have to be transformed to the Cartesian coordinates using the standard formulas
x
y
z
T,i
(N(B) + H) • cos(B) • cos(L) (N(B) + H) • cos(B) • sin(L) b2
(— -N(B) + H)-sin(B) a
and N(B) =
a2 /b
1 +
a2-b2
cos2 B
T,i
(2c,d)
The physical heights HTi , which are to be introduced in (2c), and so in (2a), can result directly from a reference-transformation of type tab.1 (1). In case of the availability of a reference transformation of type tab. 1 (3), namely a HRS model N((x,y,z)GNSS) the HTi can alternatively also be computed as HTi = hGNSS i - N . The formula (2a) is then used to estimate the parameters p, e.g. by a least squares estimation together with the associated residual vector r. The datum-parameter set p is stored in the data-fields of the messages 1021 or 1022, respectively. The residual-vector r is transformed to the geographical or the plane coordinates and heights in the target system, and provides the grid-information for the message part 1023 or 1024, respectively.
The use of the RTCM-transformation messages in the GNSS rover is done here in that way, that the parameters p are used in a first step for the datum transformation (2a) of (x,y,z) , which leads to the geocentric position in the target system
GNSS
(x,y,z)T (implying the physical height HT there). The resulting plane and height
2
b
position (B,L)T and HT are received from (x,y,z)T by the inverse computation for (2c,d). In the second step of the RTCM-transformation the grid residuals ri (2a) are used. The residuals provide an additive residual interpolation part, and lead to the final transformed position in the target system. For example in case of using the RTCM-transformation couple 1021 and 1023 related to the geographical coordinates, we get
"B" "b" "8B(SBi)"
L T L T,7PT _SL(SL1)_ interpolated
Bt _= [HT,7PT ] - [8H(8hi)] interpolated (2f)
Gridding for RTCM Height Indicator = 2
A height indicator of a value 2 means, that the height residuals 5h; =: 5N; together with the shift of a mean ah =: n0 value, defined in the data-field of the grid messages 1023 or 1024 represent the HRS N((x,y,z)GNss) (tab. 1 (3)) by
Ni =N(x,y,z)GNS§5i =N0 +8Nj =: =:AH + Shi (3a)
RTCM
1023,1024
The use of the grid representation for the RTCM-message based HRS transition in the GNSS-rover accordingly leads directly to the final result, reading
— h(3S[ss — Nq — SN^gjpQ^g^ — hQNgg — AH — 8H(8hj) interpolated
(3b)
Independently of the possibility to have a direct RTCM-grid-representation of modern ITRF/ECEF-related HRS (tab. 1) by making use of the height-indicator 2, a datum transformation from (B,L,h)GNSS to (B,L)T can be done additionally and independently like in case of the height-indicator 1, by applying the formulas (2a) and (2e).
The above gridding procedures for the height indicator 1 or 2 used for the new RTCM messages are - from the point of view of the mathematical models - the same as applied in the grid-factories of the GNSS-office packages for the present generation of field-grids (chap. 1.1) for the GNSS-rovers.
In addition to the basic error budget for the reference transformation results, namely [(gb,gl),gh or oN }□ , the mapping of these to the grid-representation by the parametric part (1021 or 1022) associated with the grid part (1023 or 1024), implies as characteristics of the gridding itself, two additional error loads, namely the loss of information by the grid-discretisation (discretisation error) and the error of the applied residual interpolation method (interpolation error). The discretisation error decreases with the density of the grid, and so the grid-width (Aq>,AA,) (fig.
2.1). The interpolation error for the different interpolation methods declared in the RTCM-transformation messages specification [11] may vary individually. If the relative error in between the (arbitrary) interpolation methods at the rover or with respect to the true value rT is assumed to be s, it is clear that large residuals in a grid, after removing the trend of the means, imply larger absolute errors ArT=e-rT for the interpolation components (SB(SBi), SL(SLi) )interp0iated and
8H(8hi) interpolated Of the transformed target CRS position (B,L,H)T (2e), (2f) and (3b).
1.2.1. Static RTCM Messages from a Pre-computed RTCM-like Total Area Grid
The mathematical models for the computation of the parameters of the RTCM
3.1 transformation messages ([5], [11]) from one or several desired reference transformations (tab. 1) can also be used to compute according to the models chap.
2.2.1 “RTCM-like” messages 1021 (or 1022) and 1023 (or 1024) with one set of 7 PT parameters p, which cover the whole area of the GNSS-service provider. The parametric message 1021 (or 1022) and the associated grid 1023 or (1024) can then serve as special case of a reference transformation on the RTCM-server side (fig.
3.2, fig 4.1). Based on the NMEA-formatted GNSS position (B,L,h)GNSS arriving as a rover-request at the RTCM-server, the respective transformation module just has to extract the well-defined part of the n=16 grid-points (fig. 2.2) out of the large (n >> 16) RTCM-like total grid , which are situated around the GNSS-rover (fig. 2.3).
Fig. 2.3: Large residuals static grid and extraction to the RTCM 1023 or 1024 grid message. Example for the country of Rheinland-Pfalz, Germany
There are however several disadvantages with respect to the pre-computation of a RTCM-like total area grid. The first disadvantage is due to the fact, that this special case of a reference transformation is per se static (“static grid”), following the idea of the classical rover field grid (chap. 1.1) now ported to the server. Consequently any change concerning the applied reference transformation(s) behind, or the grid-width design, will require its complete re-computation. As the
RTCM-like static grid is separated from the original reference transformation(s) behind, problems may come up concerning such an update, if required after some years.
A static grid is of course a reference transformation (fig. 3.1, fig. 3.2). In the case however, that the GNSS-service and RTCM observation corrections are set up in the timely dynamic ITRF, instead of a fixed ITRF/ECEF-related frame, like ETRF89, the RTCM transformation message is to be set up using two reference transformations (see 2.2.3.1), and not any more solely as a simple extraction from the static grid. In that combined case, the use of the original reference transformations behind the static grid is more appropriate, as it avoids a double discretisation and interpolation error.
Finally, it is to be mentioned, that only one set of parameters p implies large residuals r for the plane component, which are going with the well-known distortions of the so-called “weak-shapes” of classical trigonometric networks ([17], [18]; see fig. 2.3, right upper corner). In case of using the above RTCM-message computation scheme (chap. 2.2.1) with a height indicator of value 1, also the residuals become large in the height residual component due to the approximation hT=: HT over a large area. So the static RTCM-like grid-based representation (“static RTCM grid”) has the disadvantage to imply a higher additional interpolation error budget, compared to the original reference transformation(s) behind. The larger residuals also mean a non-uniqueness and dependency with respect to the residual interpolation method applied in the rover.
2.2.3. Dynamic RTCM Transformation Messages
The general mode of a dynamic computation of the RTCM 3.1 grid-based transformation messages out of a set of several reference transformations (fig. 3.2, fig. 3.2), is complementary to the use of a static RTCM-like country-wide total grid. So all disadvantages already mentioned above, concerning the static RTCM grid, are generally completely avoided by the mode of a dynamic RTCM grid computation at the server.
A dynamic generation of the grid-based RTCM messages means, that the transformation messages (e.g. 1021 and 1023) are computed from combinable and configurable sets of reference transformations (fig. 3.2, fig. 3.2). The dynamic RTCM grid computation follows within a maximum of 500 milliseconds to the NMEA-based rover’s request. The rover position (B,L,h)GNSS is placed in the centre of the grid (fig. 2.2), and the grid design follows directly the RTCM 3.1 message specification. The dynamic generation of the RTCM messages of n=16 points round the rovers position (fig. 2.2) from n=16 local virtual fitting points finally implies the advantage of a higher accuracy of the transformation due to a smaller residual part.
Besides avoiding the above disadvantages, the following sub-chapters show the power with respect to be open for all kind of reference transformations and for their combination in GNSS services, as well for facing future requirements, in case of using the concept of a dynamic generation of the grid-based RTCM 3.1 transformation messages, instead to the rigid concept of static grids.
2.2.3.1. Combined Use of Reference Transformations
All above components of the RTCM- messages are evaluated in the process of RTCM-gridding (chap. 2.2.1) from a number n of virtual fitting points [(B,L,h)GNSS | (B,L)T , HT or N)]i, which have been generated for the grid-positions Pi (i=1,n) by making use of reference transformations (chap. 1.1). So in case of setting up the RTCM messages dynamically, different reference transformations can easily be combined, if required for a GNSS-transformation service.
Let us assume - what will probably happen in future - that the reference frame for a GNSS-service is not any more a regional ITRF-related frame, like ETRF89 in Europe, but the GNSS-orbit consistent global ITRF/ECEF itself. The RTCM-corrections for code and phase-measurements will then provide the ITRF-position as (B,L,h)GNss. And so the coordinates of the reference stations x=(x,y,z)Ref.Stat. (fig
1.1) have to be submitted to the time-dependent position change due to individual plate-movements, a datum-drift and the change of the ITRF datum itself. Let us start with the ITRF-related position x(to)ITRFyyyy of the reference stations
x=(x,y,z)RefStat. of the GNSS-service in an ITRF-related frame, e.g. ETRF89, with yyyy = 1989. Then the datum change from the regional ITRF-related frame to the global ITRF-datum zzzz - e.g. zzzz = 2005 as the present ITRF as new kind of source CRS - is to be modelled by the similarity transformation, reading
x(to )lTRFzzzz — (1 Am) • R(sx, Sy , Sz) • x(t0 )lTRFyyyy t
(4a)
With the small part of a datum drift (Am, r , t) and the individual plate movement RP(j) we arrive from (4a), in a second step, at the ITRF-position related
to the present datum zzzz and to the present plate state epoch tx reading:
x(ti)
7777 x(to)lTRF 7777.
+ (¡Am + R) • x(tQ )itrf 7777 ^ jXtl _to)
(4b) ^
^P(j) )lTRFzzzz _>0"1 — t0)
For the ITRF-related frame ETRF89 the epoch t0 is t0 = 1989.0. The changes of the position x=(x,y,z)Ref.Stat., and so of the resulting GNSS-position at the rover (B,L,h)GNSS, between the ITRF/ECEF as the source CRS of a GNSS-service, and that of a fixed ITRF-related source CRS, are due to the plate dynamics (4b) for the Eurasian plate, e.g. at the location of Karlsruhe 2.7 cm / year (Fig. 2.4). The amount of (4b) can reach up to 10 cm / year at other places and plates on the earth.
The parameters for the subsequent transformations (4a,b) are available from the International Earth Rotation Service (IERS). For more details and literature it is also referred to [24]. The complete transformation from x(to)ITRFyyyy to
x(t1)ITRFz777 can alternatively also be modelled by a 3D similarity transformation using a respective set of physical fitting points in the GNSS-service area [25].
Fig. 2.4: Plate dynamics considerable in present RTCM transformation messages
by a dynamic message set up.
Using the general concept of the RTCM gridding by virtual fitting points, we use a first set of reference transformations (tab. 1), which provide the set of virtual fitting points
[(B,L ,h)lTRF-related | (B,L)t , Ht or N)]i (4c)
As a second set, and as an additional kind of a reference transformation (fig.
3.2) for the dynamic and combinable RTCM messages set up, we can either directly use the formulas (4a,b), or the above mentioned 3D similarity transformation. In that way, we transform the virtual fitting points from the preliminary ITRF-related source CRS to the final ITRF-based source CRS, reading
[(B,L,h)ixRF-related],i => [(B,L,1i)gnssjtrf]í (4d)
From (4c) and (4d) we arrive at the final set of virtual fitting points [(B,L,h)GNSS,ITRF | (B,L)t , Ht or N)]i (4e)
From the set of virtual fitting points (4e) we can now set up the RTCM 3.1 transformation messages, as described in chap. 1.2.
2.2.3.2 Use of Parametric Reference Transformation
Modern georeferencing of GNSS-positions, as well as of geodata products, takes place in the ITRF or in ITRF-related frames. In this example, for the flexible dynamic set up of RTCM 3.1 transformation messages, we regard as preventatives of parametric geodata products and as reference transformations, respectively, the type of geopotential models [19], [20] of the earth gravity field and the type of the parametric DFHRS ([17], [18], [26]). Both can be used for the HRS-representation and as reference transformations type (3), tab. 1. Considering these types of parametric reference transformations concerning the HRS representation, it strikes, that both are to be updated in more or less high update rates according to their improvement and their
physical variations, and both can be used for large regions (global and Europe-wide, respectively). For these reasons, and in the context with chap. 2.2.3.1 it follows, parametric models like these and others (tab. 1) are predestinated be situated in their original parametric representation and the unique databases at the RTCM-server (fig. 3.2, fig. 4.1), and to be used for setting up dynamic RTCM combinable messages in the different transformation modules.
In case of e.g. a parametric geopotential model ([19], [20], [21]), which parametrizes the gravity field W of the earth by the spherical harmonic parameters (Cnm and Snm) reading
w(r,a,A) =
GM
GO n
(1+ I I
n=2m=0
^aGRS8^n
(Cnm cos^ + Snm sin mo- Pnm (cosS)
(5a)
the HRS (tab. 1 (3)) of a quasi-geoid, can easily be received as
W-U
N((x,y,z)GNSS) =---------, (5b)
Yh-N
where U is the parametrization of the reference potential. U depends on the four defining parameters (a,s,co,M) of the geodetic reference system (REF), presently GRS80, and reads:
U = U(a,8,co,M)REF |(B,X,u)) (5c)
The gravity value yh_N is to be computed, iteratively in the case of (5b), also from U (5c). The georeferencing of W is done by the well-known spherical coordinates (r.s.A,), and that for U by the so-called ellipsoidal coordinates (BAu), both are related directly to the GNSS-position (y,x,z)GNss, e.g. for (BAu) as
x
y
z
1 + s2/u2 -cosB-cos^
2 / 2
1 + s u -cosp-sm^ u • sin p
(5d)
As concerns the forward and backward computations related to (5d), it is referred to WTrans-software and the appropriate manual at [13].
2. Communication Architecture for Providing RTCM 3.1 Transformation Messages via GNSS-Network-Software
1.1. General Overview on the Communication Architecture
The communication flow for providing GNSS users with RTCM transformation messages comprises three main components (fig. 3.1, fig. 3.2). The first component consists of the user group carrying out a GNSS-based positioning (B,L,h)GNSS in the ITRF/ECEF-based source CRS and needing the additional service of a datum and surface transformation the target CRS (B,L,H)Target. The GNSS controller-software on the user-side (fig. 3.1, fig. 3.2) must be able to receive the different binary RTCM data-streams by GPRS, GSM or NTRIP-Protocol, to decode them, and to apply then the mathematical models, first for positioning (B,L,h)GNSS in the source CRS, and then these for a forward
r
r
transformation (chap. 2.2.1) to (B,L,h)Target using the parameter and residuals information of the RTCM-transformation messages.
The second component consists of the GNSS-networking-software (e.g. GNREF (©Geo++ GmbH), GNSS Spider (©Leica Geosystems), GPSNet (©Trimble), TopNet (© Topcon), just to mention a few) with its according dial-in-server (fig. 3.2). The GNSS-networking-software is responsible for the generation of the RTCM 3.1 standard messages (fig. 3.1) concerning the code- and phase corrections, which are required for the positioning (B,L,h)GNSS in the ITRF-based source CRS.
The third component is the configurable RTCM transformation server (fig.
3.1), which provides the different RTCM-transformation messages (chap. 2.2.2, chap. 2.2.3). As shown in fig. 3.1, the RTCM transformation messages may be sent by the GNSS transformation services provider in the TCP/IP standard directly to the user group, or through the GNSS-networking software. The second way is also as presented by fig. 3.2.
Fig. 3.1 shows also the two types of GNSS service providers. In case of the type “full service - one hand”, left, the provider covers the complete spectrum of all necessary reference transformations (chap. 2.2.2, chap. 2.2.3), which are required for the full service of the RTCM-messages, which are generated and broadcasted by the RTCM transformation messages server. The individual reference transformation consists of the individual data (transformation parameters and residuals, grid data, spherical harmonic coefficients, identical points, etc.) and the algorithms applied to that respective data (tab. 1). In case of the type “full service - shared”, fig. 3.1 right, a first party provides only one part, and a second party provides the complementary rest, meaning all further parts of the reference transformations needed for a full service on the RTCM server side. As an example for “full service -shared” one can imagine, that the first party e.g. provides the data of a static grid (chap. 2.2.2), and the second party provides all other reference transformations (fig. 2.2.3) including the access to the static grid, implemented on the configurable RTCM transformation server. So the portfolio of GNSS transformation services, and so also the respective configuration of the RTCM transformation messages server are per se an agreement between two or more parties.
We now come back to the third component of the GNSS-service provider, the RTCM transformation messages server. In the fig. 3.2 its use is represented, without loss of generality, for the case, that the RTCM transformation messages are sent through the GNSS-networking software.
Fig. 3.1: Types of GNSS Transformation Services Providers. Full service - one hand: All reference transformations are contributed by one party to the RTCM transformation messages server. Full service - “shared”: One part of the reference transformations is contributed by a first party, all further parts by a second party.
The messages, which are broadcasted to the clients (e.g. for surveying purposes, navigation, machine control, GNSS online monitoring, etc.) are in binary format with check-sum, embedded into a so-called transportation layer ([5], [11]). For a full service, the RTCM transformation message server must be able to set up an arbitrary number of transformation modules according to its configuration. Their distribution can be made either by using different TCP-ports, representing the “transformation modules” [12] or by making use of the SIN [11] within one message stream. Without loss of generality, fig 3.2 and the following explanation of the server client concept relate to the use of different ports for different sets of messages. One transformation module then provides a well-defined set of RTCM transformation messages as an answer, when receiving a NMEA positioninformation as a request (fig. 3.2). As a transformation module is addressed by a preconfigured TCP-Port, the GNSS software is able to send the users NMEA-request to the transformation module, which satisfies the users demands.
The following chapter describes the design and capacities of a configurable RTCM transformations messages server. Such a server has generally to handle a number of different sets of transformation messages, with respect to different height, horizontal and vertical CRS, different resolutions, etc. Each RTCM message set has then generally to be set up by one or a number of separate reference transformations (chap. 1.2, chap. 2.2.3, fig. 3.2), which are implemented in the RTCM transformation server. Depending on the configuration, a transformation module is accessing one ore more of the reference transformations (data and algorithms) to gather the required information for the RTCM transformation messages.
1.2. RTCM Transformation Modules
As the GNSS network software is responsible to provide the total set of RTCM messages to the user, the interface between the GNSS network software and the transformation module which provides the RTCM transformation messages as a subset of the total message set is an important item.
In the logical sense the interface consists in the one direction from GNSS software to transformation module of the NMEA-Position which is provided by the user and passed by the GNSS software to the transformation module. In the other direction the interface comprises the RTCM correction messages (1021 - 1027)
[5], [11] which are provided by the transformation module.
The physical interface between the GNSS-network software and the transformation modules are TCP-sockets [12]. The RTCM transformation modules act as TCP-servers while the GNSS network-software acts as a client. One transformation module has a fixed TCP-Port number.
After the reception of a users NMEA position, the GNSS network software has to establish a TCP-socket connection to the transformation module. The transformation module generates the transformation messages, which are valid for this position and provides them to the GNSS network software. Afterwards the socket-connection is closed.
The GNSS network software is responsible to pass the transformation messages in the interval recommended by the RTCM specification to the user. By means of the NMEA position provided by the user it can be determined if the user is still in the area of validity of the transformation message. For this purpose the transformation messages received from the transformation module have to be decoded and interpreted by the GNSS network software and they have to be buffered for the online-time of a user. If a NMEA user-position is not situated in the central mesh of the RTCM message (fig. 22, [11]), the GNSS-network-software has to request a new transformation message from the transformation module by sending the new NMEA-position of the user to the transformation module and to provide the new RTCM transformation message to the user.
Fig. 3.2: Communication Architecture - GNSS User, GNSS Network Software and RTCM Transformation Messages Server with Configurable TCP-Ports acting as Transformation Modules for the Generation of any RTCM message out of any kind
of Reference Transformations
If the connection to the transformation module fails or no transformation message is provided by the transformation module within a given time range, the GNSS network software should try to establish a new connection to the transformation module in a given interval and to retrieve valid transformation
messages. In these cases the network operator has to be informed in an appropriate manner by the GNSS network software.
Which RTCM message types of the different available message types are provided is configured in the transformation module. The application of different transformation reference transformation (tab. 1) has to be possible. In the GNSS-network-software it must be able to assign different customers to different transformation models.
2. Example for a RTCM-Transformation Server - GZTraS
2.1. Software architecture of GZTraS
The RTCM-Transformation Server GZTraS (fig. 4.1) was realized in 2007/2008 by the authors [13] in the context with [14].
In its current Version 2.0., the GZTraS (GeoZilla Transformation Server) is realized as a Windows® Application (fig. 4.1). Figure 4.1 shows the main window of GZTraS. The list in the top of the window shows the different transformation-modules which are configured for the server. Each transformation module is running on its own TCP-Port and the underlying reference-transformations and the according transformation messages can be defined by configuration. The transformation modules which are currently running are equipped with a green icon. The transformation modules, which are presently not running, are equipped with a yellow icon. Transformation modules, which can due to missing configuration information not yet be started are equipped with a red icon.
Every incoming request as well as occuring problems during generation of the RTCM transforamtion messages is logged to file. The window in the lower area of the GZTraS main window shows the log-entries for the transformation selected in the upper list.
App1ic at i on: GZTraS
Version: Version: 1.0.3
Copyright ©: Reiner Jäger and Simone Kälber
Configuration: Bavaria
[02.02.2008 - IS : OS : SO] [INFO] [GZTraS] Starting up server...
[02.02.2008 - IS : OS : SO] [INFO] [GZTraS] Server finishes binding process...
[02.02.2008 - 15:05:52] [INFO] [GZTraS] Server is waiting for client calls ...
[02.02.2008 - 15:06:34] [INFO] [GZTraS] A client from, localhost-0 is connected
Fig. 4.1 : Main Application Window of GZTraS (GeoZilla Transformation Server) [13]
2.2. Configuring GZTraS
Each transformation-module (e.g. set up for a specific user group or for a specific area) holds its own configuration in GZTraS. The configuration has to be done after adding a new transformation module and before starting the service of the transformation-module.
A configuration contains essentially the following information
- Port-number to use for the transformation module.
- Numbers of the RTCM messages to provide within the transformation-module
- Information about the reference-transformations to use for this configuration
- Static preconfigured position-independent message content
In its current version GZTraS supports as RTCM transformation message types the messages 1021, 1023 and 1025 [11] which are related to geographical coordinates (B,L). As reference transformations (fig. 3.2) DFLBF- and DFHRS ([17], [18]) can be set up.
3. Testing of the RTCM 3.1 Transformation Messages
The application of new the RTCM-transformation messages was tested out in the server-client concept using the server GZTraS in the area of Bavaria (fig. 1.1) in the frame of a diploma thesis at HSKA [14]. The reference transformations DFHBF/DFLBF (tab. 1) were used in the active transformation modules (fig. 3.2, fig. 3.2), which were configured for the broadcasting of the RTCM transformation messages 1021 and 1023 related to the geographical coordinates in the target CRS. The accuracy of the applied original reference transformation was 1 cm for the height (DFHBF) and about 5-7 cm for the plane transformation (DFLBF). The respective reference transformation, represented by DFHBF and DFLBF, are related to the classical German plane datum called “DHDN”, and as for H to the frame of the German “NN-heights” as target CRS.
As concerns the dynamic setting up (chap. 2.2.3) of the grid-based RTCM messages the height indicator 2 was used. To test both, the setting up and interpretation of RTCM-messages for the transformation of the rover position from the source CRS (B,L,h)GNSS to the target CRS (B,L,H)T, these tests were done by using the client GZTraC and an independent client developed in the thesis at the external partner [14]. Further the RTCM-based results were compared to the use of the original access to the reference transformations DFHBF and DFLBF, as well as by comparing both with a number of 42 additional physical fitting points distributed regularly country-wide over Bavaria (fig. 1.1).
The results of the above tests proved by the mutual and independent comparisons the correct setting up of the RTCM-messages and their consistency with the original reference transformations in the given accuracy level of 1 cm and 5 cm respectively. To enable a testing for the interested GNSS community, the RTCM 3.1 transformation messages server and client, GZTraS and GZTraC, the
above Bavarian DFHBF/DFLBF databases, and the DFHBF database for Florida, USA, as reference transformations, have been made available on the Web at [13].
References
1. http://www.trimble.com/vrs.shtml
2. Wübbena G. und A. Bagge: Neuere Entwicklungen zu GNSS-RTK für optimierte Genauigkeit, Zuverlässigkeit und Verfügbarkeit: Referenzstationsnetze und Multistations-RTK-Lösungen. 46. DVW-Seminar "GPS-Praxis und -Trends '97". 29.9.-1.10.97 in Frankfurt/Main.
3. Zebhauser, B. E., Euler, H.-J., Keenan, C.R., Wübbena, G. (2002): A Novel Approach for the Use of Information from Reference Station Networks Conforming to RTCM V2.3 and Future V3.0, ION NTM 2002, January 28-30, 2002, San Diego, CA.
4. S. Kälber and R. Jäger (2005): 3D-Similarity Transformation related to
(B,L,h) - Molodenski-Approach.
http://www.geozilla.de/files/3D_B,L,h_Molodensky_and_XYZ-Alternative.pdf.
5. RTCM Special Committee No. 104 (2006): RTCM Standard 10403.1 for differential GNSS (Global Navigation Satellite Systems) Services - Version 3. Radio Technical Commission for Maritime Services.
6. Trimble Grid Factory Software Description:
http://www.trimble.com/scs900_ts.asp?Nav=Collection-37882
7. Jäger, R. and S. Schneid (2004): DFHBF-Leica.exe. Module for gridding DFHBF-Databases to field grids for Leica Rovers. DFHRS-Team Karlsruhe.
8. Seiler, S.: Use3DIM-Grid-Software-Module. http://www.ib-
seiler.de/pdf/3dim_handbuch.pdf. Ingenieurbüro-Seiler Lauf.
9. Fortes, L.P., Laura, E., Brunini, C., Amaya, W., Sanches, L., Drewes, D. and W. Seemüller (2006): SIRGAS - a geodetic enterprise. Coordinates, Vol. II, Issue 5, May 2006. www.mycoordinate.org. ISSN 0973-2136.
10. Landesvermessungsamt Baden-Württemberg(2008): Einführung des neuen europäischen Normalhöhensystems.
http://www.lv-bw.de/lvshop2/start_ns.asp?openkey=GEODATEN&keyinfo=&os=Win32&mapw=600.
11. RTCM Special Committee No. 104 (2007): Amendment 1 to RTCM Standard 10403.1 for differential GNSS (Global Navigation Satellite Systems) Services - Version 3. Radio Technical Commission for Maritime Services.
12. AdV-Working Group SAPOS and Transformation (2005): Transformationsmodule und technische Einbindung der TransformationsInformation. Technical Paper, April 2005.
13. Jäger,R. and S. Kälber (2008): GeoZilla Transformation Server GZTraS. http: //www. geozilla.de/eng/software/software_gztras .htm
14. Hoyler, K.R. (2007): Anbindung externer RTCM 3.0
Transformationsmodule an GPS-Spider®. Diploma-Thesis at Hochschule Karlsruhe - University of Applied Sciences. Unpublished.
15. Jäger, R. and S. Kälber (2008): GZTraS on GeoZilla-Homepage. URL: http: //www. geozilla.de/eng/software/software_gztras .htm.
16. Jäger, R. and S. Kälber (2008): GeoZilla-WebSite: http://www.geozilla.de.
17. Jäger, R. and S. Kälber (2006): Precise Transformation of Classical Networks to ITRF by CoPaG and Precise Vertical Reference Surface Representation by DFHRS - General Concepts and Realisation of Databases for GIS, GNSS and Navigation Applications. Proceedings to GeoSiberia 2006. Volume 1. S. 3-31. Novosibirsk, Russia. ISBN 5-87693-199-3.
18. Jäger, R., Schneid, S., Kälber, S. and Seiler, S. (2006): Precise Transformation of Classical Networks to ITRF by CoPaG and Precise Vertical Reference Surface Representation by DFHRS - General Concepts and Realisation of Databases for GIS, GNSS and Navigation Applications. 1st International Fair of Geodesy, Cartography, Navigation and Geoinformatics. Prague, Czesk Republic. 16.03.2006 - 18.03.2006. Milan Tallich (Eds.): Conference Proceedings. ISBN 80-85881-25-X. 26 pages
19. EIGEN: http://www.gfz-
potsdam.de/pb1/op/grace/results/grav/g001_eigen-grace01s.html
20. EGM96: http://cddis.nasa.gov/926/egm96/egm96.html
21. EGG97: http://www.ife.uni-hannover.de/forschung/egg97.html
22. BKG Quasigeoid-Deutschland:
http://www.bkg.bund.de/SharedDocs/Download/DE_20-_20InfoMaterial/BKG-Quasigeoid-Prospekt-DE,templateId=raw,property=publicationFile.pdf/BKG-Quasigeoid-Prospekt-DE.pdf
23. Schneid, S. and R. Jäger (2006): Umreferenzierung der Digitalen Finite
Element Höhenbezugsfläche (DFHBF) für Hessen. Technical Report. Hochschule
Karlsruhe - Technik und Wirtschaft (HSKA). Unpublished.
24. Jäger, R. (2008): Deformation Integrity Monitoring for GNSS-Positioning Sevices by the Karlsruhe Approach (MONIKA) - Concpet, Realisation and Present Results. Geomatika (2). Scientific Proceedings of Riga Technical University.
25. Jäger, R., Schmittinger, D. and Kälber, S. (2001): Kurzhandbuch Berner GPS-Software. Fachhochschule Karlsruhe - Hochschule für Technik. Studiengang Vermessungswesen und Geomatik.
26. Jäger, R. (2008): DFHBF-WebSite: http://www.dfhbf.de.
27. ETOPO5: http://www.ngdc.noaa.gov/mgg/global/etopo5.HTML
© Reiner Jäger, Simone Kälber, 2008
