Content uploaded by Mohamed Eleiche
Author content
All content in this area was uploaded by Mohamed Eleiche on May 28, 2017
Content may be subject to copyright.
41
GEOMATICS
ISSN 1407-7345 ĂEOMĀTIKA 2009-7345
RTCM3.1. MĒRĪJUMU TRANSFORMĀCIJAS ZIĥOJUMA STANDARTS GNSS
POZICIONĒŠANAS DIENESTIEM
BASICS OF RTCM 3.1 TRANSFORMATION MESSAGES STANDARD FOR GNSS
POSITIONING SERVICES
MSc Mohamed Eleiche, Msc., PhD Candidate at the University of West Hungary
Faculty of Geoinformatics, H-8002 Székesfehérvár, P.O.Box 52, Hungary
Email: mohamed_eleiche@hotmail.com
Key words:
Differential Global Navigation Satellite Systems, mathematical geodesy
1. Introduction
The use of RTK (Real Time Kinematics) in GNSS reference station networks has become the general
tool and quickly spreading solution for high precision positioning using Global Navigation Satellite
Systems (GNSS). The RTK network approach is the evolution of single base RTK positioning
technique, which achieved a RTK cm-solution only in the close range up to 20 km and sub-meter
accuracy else by using GNSS positioning. The GNSS measurement for the rover is not the end target
for the GNSS user. The reason is that coordinates derived by the RTCM observations corrections
provided by the GNSS service in a VRS, ACP or MAX mode of representation are related to the ITRF
(International Terrestrial Reference Frame System) based Coordinate Reference System (CRS) of the
GNSS-service. This CRS is related to a past ITRF-datum and plate stand, such as e.g. ETRF89 in
Europe. In that way it is in a sufficient consistency with the GNSS satellite orbits for the DGNSS-
operation mode of a GNSS-service. The GNSS-service users however need to transform that ITRF-
based RTK-position (X,Y,Z) - the source CRS in the sense of the RTCM-transformation messages –
as the result of the receiver RTK-algorithm using the receivers code and phase measurements together
with the service’s RTCM corrections to another horizontal and vertical CRS, the so called target CRS.
The RTCM transformation messages provide the respective transformation information concerning
the transition from the ITRF-based source CRS to the horizontal and vertical target CRS. These user
requirements motivated the RTCM (Radio Technical Commission for Maritime Services) SC104
(Special Committee 104 Differential Global Navigation Satellite Systems (DGNSS)) to include in the
RTCM correction message, an additional set of transformation messages, enable transform the user
of a GNSS service to the plan position and the physical height the target system. The transformation
itself is represented by a set of transformation parameters (general trend) associated with a grid of
three-dimensional residuals. The essential characteristics of the RTCM transformation messages is,
that any existing reference transformation for the 3D (plan and height transition), 2D (horizontal
datum transition) and 1D (pure height determination) can be mapped to the grid-based RTCM
transformation messages. The “gridding” of any reference transformation is to be done by generating
a grid of CRS-points both in the source and in the target CRS and the split of a seven parameter-
transformation and a residuals field. This can be done in tow different ways, namely the concept of a
global “static grid” and the more flexible concept of a dynamic grid generation [1].
This paper describes the concept of transformation in RTCM 3.1 messages for RTK networks, the
basics of mathematical geodesy used in RTCM 3.1 standards, the generation of RTCM 3.1 trans-
formation messages at server side and the implementation of these transformation messages at the
client (rover) side.
42
1.1 Transformation Problems
The earth-fixed ITRF-based position of a point P provided by GNSS is defined with respect to the
plan position by two angles related the reference ellipsoid, namely the latitude and longitude(
ϕ
,
λ
),
and the ellipsoidal height h. From (
ϕ
,
λ
) the Northern [m] and Eastern [m] are derived according to
the
projection type. As concerns GNSS-services the GRS80 ellipsoid (same major axis a and two
parts of a millimeter the same minor b as the WGS84 ellipsoid) and UTM are presently used as
reference ellipsoid and reference projection. The base of the height reference surface (HRS) is either
the equipotential surface of the earth gravity field, known as the Geoid, and connected to orthometric
heights H-orth, or in modern height systems more and more the quasigeoid QGeoid related to the
Molodenski theory, and leading to the normal height type H-normal. The height of the HRS, namely
the Geoid or QGeoid, respectively over the ellipsoid is described with N. The HRS fits to the global
GRS80 ellipsoid embedded into the ITRF with undulations N of up to about ±100m.
The HRS as well as heights H are nowadays physically defined, namely via the geopotential number
P
C
of the earth surface point P in the earth’s gravity-field together with GRS80 - related normal
gravity field U (1a,b) and (2a,b). In case of the HRS type of a geoid and the related orthometric height
system a model for the real gravity in the area in regard must be known with respect to the average
gravity
P
g
from P along the plumb-line down to the geoid. As
P
g
is not generally available and also
gives information about the interior decomposition of the earth, e.g. with respect to natural resources,
the Qgeoid and the Normal-height system (1a,b) become more and more popular as the general type
of a HRS and a height system, respectively.
Quasi-Geoid
QG
N
and Nor-
mal Height N
H
Geoid G
N
and Orthometric
Height Orth
H
Q
QP
QG
γ
UW
N
−
=
P
P
PP
QGG
H
g
NN ⋅
γ
γ−
−=
(1a,b)
P
P
P
P0
N
C
WW
Hγ
=
γ
−
=
P
P
N
P
P0
ort
g
H
g
WW
Hγ
⋅=
−
=
(2a,b)
Using RTCM observation corrections of the ITRF-based GNSS-service the GNSS receiver computes
the coordinates (X,Y,Z)-ITRF/Source of P. The position (X,Y,Z)-target of a regional classical
trigonometric network is related to the ITRF source system by a seven parameter datum transition
(about 500 classical datum systems exist world-wide). The target reference ellipsoid (about 40
different ones are in use world-wide) is then used for the computation of the horizontal position
(
ϕ
,
λ
)-target and the ellipsoidal height h in the target system.
The RTCM-(X,Y,Z)-target was set up with the physical heights H instead of the ellipsoidal height h-
target, physical heights H again result form the datum transition together with the residuals (height
indicator =1). In the area of GNSS-positioning the physical height H is received from the ellipsoidal
height h-source using a geoid-undulation (N-source), which is in modern geoid- and quasi-geoid
computation also related to the ITRF.
43
Figure (1) Architecture of RTK Network
1.2 Architecture of RTK Network
The concept of permanent GNSS reference stations networks started to expand early in year 1990.
The idea is based on establishment of several GNSS reference stations at points with known
coordinates connected to a central server managing the whole network. The central server receives at
time interval via mean of communications, the GNSS raw readings for each GNSS station and its
correction, and then the server can model the error in the area, and produces the required corrections
for GNSS rovers within the coverage area [1, 9].
The RTK network of permanent GNSS
reference stations is an evolution of the DGPS
concept based on using a baseline between a
fixed GNSS reference station with known
coordinates and a moving rover, where the
correction of the GNSS reading at fixed GNSS
station is applied at rover position to increase
the accuracy of rover positioning. The RTK
network establishes several GNSS reference
stations that transmit their corrections to a
control server that manages the whole system,
and then transmits the corrections to users
within coverage area.
1.3 RTCM Correction Data for GNSS-
Positioning
The correction data for GNSS-Positioning
within RTK networks is a challenging process,
and is depending on the architecture of the
RTK networks especially the communication tier between rover and control server. Mainly, there are
three main methodologies for correcting data in RTK networks for GNSS-Positioning using the
RTCM standard, first the Virtual Reference Station (VRS) technique, which requires duplex
communication between rover and control server. Secondly, the Area-Correction Parameters (ACP)
technique commonly known as FKP can work in simplex mode (broadcasting corrections) or duplex
mode. Finally, the Master Auxiliary Concept (MAX) based on simplex mode.
1.4 Transformation of GNSS measurements into user defined CRS
Let us consider the case where the GNSS measurements (B1, L1, h1) are required to be expressed in
another geographic and vertical CRS (B2, L2, H). This transformation operation is processed on two
successive steps. Step 1 is for the transformation from (B1, L1, h1) to (B2, L2, h2), then Step 2 is for
the transformation from (h1 or h2) to (H).
(B1, L1, h1) are the geodetic latitude, geodetic longitude and ellipsoidal height for GNSS
measurements, (X1, Y1, Z1) are the geocentric Cartesian coordinates for (B1, L1, h1) in the same
datum, (X2, Y2, Z2) are the geocentric Cartesian coordinates for (X1, Y1, Z1) in the target datum,
(B2, L2, h2) are the geodetic latitude, geodetic longitude and ellipsoidal height for (X2, Y2, Z2) in the
target datum.
Step 1 is implemented by the transformation procedure from geographic CRS1 to geocentric CRS1,
then from geocentric CRS1 to geocentric CRS2, and finally from geocentric CRS2 to geographic
CRS2, as shown in figure (2).
44
Figure (3) Relation between geoid
and ellipsoid
2. Transformation Sets for 3D Coordinate in RTCM 3.1
The RTCM 3.1 standard supports four sets of coordinate transformation, and they are Helmert
transformation formula both the linear expression and strict, and Molodenski abridged formula which
calculate directly (B2, L2, h2) from (B1, L1, h1) compacting the three steps of conversion and
transformation in single formula, and finally the Molodenski-Badekas transformation which derives
the 7 transformation parameters at another point than the coordinates origin, and it requires in
addition to the 7 parameters the three coordinates of the point of transformation. Please refer to
OGP, "Surveying and Positioning Guidance Note Number 7, part 2"[2] and "Amendment 1 to RTCM
standard 10403.1" [6] for full details of the mathematical equations.
Figure (2) Coordinate transformation from 3D Cartesian CRS1 to Compound User Defined CRS2
2.1 Vertical Datum Transformation
The heights obtained from GPS are typically heights above
an ellipsoidal model of the Earth. These GPS ellipsoidal
heights are not consistent with spirit leveled heights above
mean sea level, or heights above HRS such as geopotential
surface often known as orthometric height. The conversion
from ellipsoidal to orthometric height requires a geoid
height model. The difference between GPS ellipsoidal
heights, h, and leveled orthometric heights, H, is called
geoid height, N [4, 8].
H = h – N (3)
The GNSS observations delivers the ellipsoid height at the point of interest, which was considered a
revolution in geodesy, where before this value was difficult to quantify. Also, there are several
modern methodologies for computing the geoid undulation up to one centimeter accuracy using
satellite technology, field gravimeters, and advanced mathematical models.
45
Figure (4) Definition of axis of
transformation (Rotations & Translations)
2.2 Mathematical Formula for the transformation sets in RTCM 3.1
3D Cartesian and Geographic Coordinates
The 3D coordinates transformation between two different datums includes three implicit operations as
described in Figure (2). The conversion between Cartesian and geographic coordinates is derived in
the following section.
Geographic to Cartesian
The conversion from Geographic to Geocentric in the same datum (same ellipsoid) given as
function of geodetic latitude B, longitude L, and ellipsoidal height h, is:
+−
+
+
=
BhNf
LBhN
LBhN
Z
Y
X
sin))1((
sincos)(
coscos)(
2
(4)
Cartesian to Geographic
The conversion from Geocentric to Geographic in the same datum (same ellipsoid) given as function
of geodetic coordinates X, Y, Z, is:
−
φλ
+φ+
=
λ
φ
N
coscos
X
X/Ytana
)YX(/)sinNeZtan(a
h
222
(5a)
It should be noted that φ and h needs iterations to be
computed, where
Be
a
N
22
sin1 −
=
(5b)
Datum Transition
The 3D coordinates transformation in this case compute the coordinates in the target CRS, given the
coordinates in the source CRS and the seven transformation parameters between two datums, which
are three translations (dX, dY, dZ), three rotations (Rx, Ry, Rz) and a scale factor M. Subscript T
denotes target and S for source CRS.
3. Transformation Messages at Control Server in RTCM 3.1
The RTCM 3.1 standard supports seven types of transformation messages which are message type
1021, 1022, 1023, 1024, 1025, 1026, and 1027 as shown in Table (1) and Figure (5). Please refer to
"Amendment 1 to RTCM standard 10403.1" [6] for full details of the messages and their data
fields' description.
It is clear that only one set of the four available transformation sets will be used, which means only
the message types 1021 or 1022 will be used not both. The same concept is applied for message types
46
1023 and 1024, where the message type 1023 is for geographic coordinates and message type 1024
for Cartesian coordinates.
The remaining three message types 1025, 1026, and 1027 are for map projections parameters.
Message type 1025 includes the parameters for all map projections types except for map projection
Lambert Conformal Conical with 2 SP, which is defined in message type 1026, and Oblique Mercator
map projection which is defined in message type 1027.
Table (1) List of RTCM 3.1 transformation messages and their description and use
Message
Type
Message Name Description Use
1021
Helmert/Abridged
Molodenski
transformation
7 parameters of transformation for
Helmert/Abridged Molodenski
Transformation from ITRF to user
CRS using Helmert or Abridged
Molodenski
1022
Molodenski-
Badekas
Transformation
10 parameters of Molodenski-
Badekas Transformation
Transformation from ITRF to user
CRS using Molodenski-Badekas
1023 Ellipsoidal
residuals Residuals in geographic coordinates Coordinate values are in degrees
1024 Plane Grid
residuals Residuals in Cartesian coordinates Coordinates values are in meter
1025 Projections (except
LCC2SP & OM) All projection parameters Conversion to all projections
except LCC2SP & OM
1026 LCC2SP Projection Projection parameters for LCC2SP Conversion to LCC2SP projection
1027 OM Projection Projection parameters for OM Conversion to OM projection
Figure (5) Usage of RTCM 3.1 transformation messages and their levels
47
Figure (7) residuals Parameters of
Message Type 1023
Mainly, the decision to transmit message type 1021 or 1022 is based on the type of transformation set
used. Secondly, the units of the coordinates determine, if degrees or meters, the use of message type
1023 or 1024. Finally, the type of used projection determines the type of message type 1025 or 1026
or 1027 as shown in Figure (5).
Message Type 1021
The message type 1021 in RTCM 3.1 standard includes the parameters necessary for the
transformation of the rover position coordinates from ITRF CRS to another coordinate reference
system defined in the same message. The transformation parameters enable the use of Helmert or
abridged Molodenski method at the rover side. As described in "Amendment 1 to RTCM standard
10403.1", it has 27 data fields, and its size is 412 bits without the size of the characters of the source
CRS name and the target CRS name.
The Computation Indicator field (defined as DBF150) describes which transformation to be used.
Computation Indicator field (DBF150) The Height Indicator Field (DBF151)
Value Description
0 Helmert standard 7 parameters (linear
expression)
1 Helmert standard 7 parameters (strict
formula)
2 Abridged Molodenski
3 Molodenski-Bakedas
Message Type 1023
The message type 1023 in RTCM 3.1 standard includes the ellipsoidal residual parameters necessary
for the transformation of the rover position coordinates from ITRF CRS to another coordinate
reference system defined in the 1021 message. As described in "Amendment 1 to RTCM standard
10403.1", it has 35 data fields, and its size is 578 bits.
Value Description
0 Geometric Height (Ellipsoidal height) (h)
1 Orthometric Height (Physical Height
above geoid) (H)
2 Geoid Height (N)
Figure (6) Parameters of Message Type 1021
48
3.1 Generation of Transformation Messages in RTCM 3.1
The transformation messages in RTCM 3.1 can be divided into 3 levels as shown in Table (2) and
Figure (5). The messages generation should follow this order, which means that message for level (1)
should be generated first, then message type of level (2), and finally message type of level (3). The
essential part in the transformation messages in RTCM 3.1 is the level (1) messages, which describe
the main data required for processing the transformation.
The source datum is the ITRF datum, in which the GPS coordinates are delivered. The target datum
is depending on the RTK network service provider specifications. A main requirement for the
transformation operation is the 7 transformation parameters from source CRS to target CRS, in
addition to the height model in the transformation.
Table (2) Level of RTCM 3.1 transformation messages
Message
Level
Supported
Messages Description
Level (1)
1021 or 1022
Includes the definition of source and target datums, grid size, 7
transformation parameters, rover position in source CRS, formula used in
transformation, height model. This message describes all the data needed to
perform the transformation operation.
Level (2)
1023 or 1024
Includes grid size, mean offset, rover position in target CRS, residuals for
16 grid points. This message describes the results of applying the
parameters of level(1) message on the rover position.
Level (3)
1025 or 1026
or 1027
Includes the parameters required to convert the geographical coordinates in
target CRS into the required projection.
3.2 Static and Dynamic Grids
The generation of seven transformation parameters and the residuals are computed from a grid of 16
points with the rover position at their center. There are two different concepts and respective ways to
create the n=16 grid points and the respective RTCM-messages (1021 or 1022 and 1024 or 1024) ,
namely the so called static and the dynamic grid mode [3].
In case of the static mode, the individual reference transformation(s) of a country or a GNSS service
respectively, is (are) applied to generate N virtual fitting points both in the target and the source CRS
for the whole country (N >> n; n=16 for the local RTCM grid). Here the grid width has already to be
adapted to that of the later RTCM grid. The static seven parameters and the N residual vectors are
determined using the N virtual fitting points in a seven parameter transformation for the whole area.
The RTCM message is generated as an n=16 point residual extraction round the rover position using
the country wide static grid together with the static set seven parameters.
In the concept of the dynamic grid the two sets n= 16 virtual fitting points surrounding the rover (fig.
7) are generated dynamically in real-time on the rover’s NMEA-request. So local seven parameters
n = 16 and residual vectors are resulting and are transmitted as message types 1021 (or 1022) and 1023
(or 1024) to the rover [3], [8].
The static grid generates high residuals and leaves larger interpolation errors, which is avoided in the
dynamic grid generation due to essentially smaller residuals.
In future the dynamic generation of virtual fitting points and a respective dynamic RTCM
transformation message generation will become more and more relevant for several reasons. The first
49
one is, that the concept of a static grid is ineffective or even impossible to be handled for some kind
of meaningful parametric reference transformations, e.g. in case of using geopotential models for the
height component of the message. A further, and a main reason for following the concept of a dynamic
grid and RTCM transformation generation, is due to the necessity of combining subsequent reference
transformations with some dynamic components (e.g. plate movements, datum drift), requiring
accordingly the generation of dynamically changing virtual fitting points. This holds for the future
operation mode of GNSS-services and also for future positioning concepts, like state space repre-
sentation (SSR), which are both related to a modeling taking place throughout in the dynamic ITRF
[3].
3.3 Example from Bavarian Database
The GZTraS (GeoZilla RTCM Transformation Server) is product from GeoZilla (www.geozilla.de).
GZTraS is a Windows-based Server for GNSS-Network-Software and provides the functionality of a
transformation module to provide RTCM 3.1 transformation messages, and GZTraC is its client
software [3]. The beta version of the software includes databases for Bavaria (Bayern) in Germany
and Florida in USA. Hereafter a sample of point observed in Bayern area is sent to the server in ITRF
CRS, and the server replied with the RTCM 3.1 message for the transformation of the coordinates in
addition to the transformation parameters.
The observed point coordinates are (49°.0000, 11°.0000, 580 m) in (B, L, h) format, and received by
the server receives in NMEA format. It is transformed to the target CRS using 7 approximate
parameters. Following the above concept of dynamic RTCM grid and message generation the server
then sets up n=16 virtual grid points in the target CRS. The reference transformation of the DFLBF
database for Bavaria [1], [8] is then used at server site to compute the corresponding set of n=16
precise virtual fitting points in the source CRS. The two sets of n=16 points are then used to compute
the accurate seven transformation parameters of a similarity transformation (message 1021). The
horizontal components of the residuals of the seven parameter transformation are stored as a first part
of the RTCM message 1023. The geoid heights N are computed for all n=16 grid-points from the
reference transformation of the DFHRS (Digital Finite Element Height Reference System) database of
Bavaria ([4], [7]). After a subtraction the mean height offset N
0
(N
0
= 46.920 m) the remaining
residuals δN are stored as third component in message 1023, which is based on height indicator 2. So
the RTCM transformation message is ready to be sent to the rover on RTCM 3.1 format.
In the example based on real data for Bavaria, the NMEA position of the rover point is reading:
$GPGGA,082012.12,4900.0000000000,N,01100.0000000000,E,1,6,2.4,580.000,M,,M,2.4,0012*71
From this we get the following RTCM transformation messages:
Message Type 1021 from Bayern (GeoZilla) Message Type 1023 from Bayern (GeoZilla)
Field Name Value Field Name Value
Computation Indicator 1 Latitude of Origin 49.000972
The Height Indicator 2 Longitude of Origin 11.001250
Latitude of Origin 49.000000 Extension in Latitude (N/S) 0.100000
Longitude of Origin 11.000000 Extension in Longitude (E/W) 0.100000
Extension in Latitude (N/S) 0.100000 Mean Latitude Offset 0.000000
Extension in Longitude (E/W)
0.100000 Mean Longitude Offset 0.000000
dX -551.664000 Mean height offset (m) 46.920000
50
Figure (8) data sent from server to rover
dY -29.638000 Residual in Latitude (Point 1) 0.0006000000
dZ -444.905000 Residual in Longitude (Point 1) 0.0003900000
R1 -0.000247
Residual height (Point 1) 0.00000
R2 0.000485
:: ::
R3 -0.000445
Residual in Latitude (Point 16) xxxxx
dS 0.999991
Residual in Longited (Point 16) yyyyy
as 6378137.000000
Residual height (Pont 16) zzzzzzz
bs 6356752.314000
at 6377397.155000
bt 6356078.963000
In this example the physical height H = h – N = 580 – 46.920 = 533.800 m
4. Implementation of Transformation Messages at Client Side in RTCM 3.1
The main aim of the transformation messages in RTCM 3.1 standard is to provide the user with the
coordinates of the observed GNSS measurements in the required CRS, and the parameters required for
projection, and also to provide the physical height of the observed point or its geoid height. All the
operations of coordinate's transformation are done on the server side and the client side is blind about
these operations.
4.1 Handling the Transformation Results
As shown in Figure (8), the rover receives a set of alternative combinations of RTCM 3.1 messages
and each has its own data.
Case (1) 3D Transformation (Plan & Height)
In this case, the rover receives the coordinates in target geographic CRS (B, L)t and the physical
height (H) in case of height indicator = 1, or the geoid height (N) over the ITRF datum in case of
height indicator = 2. The rover can compute the
physical height (H) using: H = h – N, where h is
the ellipsoidal height from GNSS measurement.
The message type 1023 in RTCM 3.1 includes
the transformation parameters in addition to the
residuals of 16 grid points around rover position.
From this message the rover can recompute the
target coordinates based on received 7 parameters,
and calculate the standard deviation of errors
from the residuals.
Case (2) 2D Transformation (Plan Only)
In this case, the rover receives the coordinates in
target geographic CRS (B, L, h)t with the
geometrical height (h) in case of height indicator
= 0. The rover in this case has to know the geoid
height relative to any ellipsoid (the target or
51
source ellipsoids) in order to compute the physical height.
The message type 1023 in RTCM 3.1, includes the transformation parameters, in addition to the
residuals of 16 grid points around rover position, including the residual for geometric height (h)t.
From this message the rover can recompute the target coordinates based on received 7 parameters, and
calculate the standard deviation of errors from the residuals.
Case (3) 1D Transformation (Height Only)
In this case, the rover receives the coordinates in the source geographic CRS (B, L, h)s in the ITRF
CRS. The seven transformation parameters in this case are all zero, there will be no coordinates
transformation. In case the height indicator = 1, the physical height (H) is transmitted, and the
residuals are relative to it. In case the height indicator = 2, the geoid height (N) is transmitted, and the
residuals are relative to it, and the physical height can be computed by the equation: H = (h)s – N
4.2 Handling the Projection Parameters
The RTCM 3.1 standard transmits the projection parameters in the message types 1025, 1026, 1027 as
described in Table (1). The rover can project the geographic coordinates using the parameters
received in the RTCM 3.1 message or any other parameters included at the client side. The essential
input to the map projection conversion is the horizontal geographic coordinates (B, L) in the
geographical CRS used in map projection. Where:
X = f(B, L) & Y = f(B, L) , and the physical height (H) is the same as in geographic CRS.
5. Conclusion
The RTCM 3.1 is a new standard developed to provide the GNSS user with high accuracy in
positioning in addition to the transformation of coordinates in the target CRS with the physical height
of the observed point or its geoidal height.
The transformation messages in RTCM 3.1 standard introduces a new concept that utilizes the
infrastructure of the RTK network to provide the transformation operation in addition to the physical
height which is a main request for all GPS users. The transmission of the coordinates of the observed
points in target CRS, and the seven (or ten) transformation parameters, and the physical (or geoid)
height of the observed point, in addition to the projection conversion parameters (if any) provides the
GNSS user in the coverage area in real time operation valuable data that reduces exponentially the
work time and provides a safe mean to reduce errors and increase work efficiency.
This concept is new, and needs to be well established in operation modes, and to be adopted by RTK
network service providers and GNSS manufacturers.
It should be mentioned that the transformation messages in RTCM 3.1 standard will not solve
classical problems in mathematical geodesy, like the computation of physical height from GPS
ellipsoidal height, rather this standard will allow the communication and data transfer between the
solutions of these problems and the client side.
Acknowledgment
The author would like to thank Prof. Reiner Jäger for his assistance, support and review of the paper.
He always replied to my inquiries in detailed and informative answers. Further I want to thank
Mr./Mrs. XXXXX for the final proof-read of the paper.
52
References
1. 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 realization of databases for GIS, GNSS and navigation applications. Proceedings
to GeoSiberia 2006. Volume I. S. 3-31. Novosibirsk, Russia. ISBN 5-87693-199-3.
2. OGP International Association of Oil & Gas Producers, Surveying & Positioning Guidance: Notes
1,2,3,4,5,7-1,7-2,10,13,14,16 version 1.0
3. Jäger, R. und S. Kälber (2007-2009): GZTraS - RTCM3.0 Transformation-Server and Downloads.
www.geozilla.de.
4. Jäger, R. (2008): DFHRS (Digital FEM Height Reference Surface) – A Rigorous Approach for the
Integrated Adjustment and Fitting of Height Reference Surfaces Proceedings EUREF
Symposium 2006, 14 - 17 June 2006, Riga. EUREF-Mitteilungen. Bundesamt für
Kartographie und Geodäsie (BKG), Heft 16. Frankfurt am Main. Page 91-96.
5. Jäger, R. (2007-2008): Personal communications.
6. RTCM Special Committee No. 104 (2007): Amendment 1 to RTCM standard 10403., Differential
GNSS (Global Navigation Satellite Systems) Services - Version 3, Radio Technical
Commission for Maritime Services, http://www.rtcm.org.
7. The DFHRS research project of the Hochschule Karlsruhe - University of Applied Sciences
(HSKA) website: http://www.dfhbf.de/
8. Jäger, R. und S. Kälber (2008): The New RTCM 3.1 Transformation Messages – Declaration,
Generation from Reference Transformations and Implementation as a Server-client-
Concept for GNSS Services. 3rd International Conference and 3rd Trade Fair of
Geodesy, Cartography, Navigation and Geoinformatics. Prague 27th – 28th February
2008. Research Institute of Geodesy, Topography and Cartography. Volume 44. No.
54.ISBN 978-80-85881-29-5.
Mohamed Eleiche
Basics of RTCM 3.1 Transformation Messages Standard for GNSS Positioning Services
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 in Europe) as geocentric (x,y,z) or
ellipsoidal (
ϕ
,
λ
,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.
The aim of the transformation messages of the recent 2007 RTCM 3.1 was to define transformation algorithms
and data structures by seven RTCM transformation messages, which allow the GNSS service to transmit respec-
tive 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.
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. In that way, the
NMEA-position of the GNSS-rover is used 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.
53
This paper provides the data structures associated with the transformation messages in RTCM 3.1 standard, and
how the client uses the received messages and transforms the ITRF-based position (source system) to the desired
horizontal and vertical reference coordinate system (target system) of the user. The seven parameter
transformation part, and the conception of residual grids are treated as well as the implementation of the
physical height. As concerns the height it is explained, how the RTCM transformation messages represent in two
different ways the physical height by using the so-called height indicator.
Mohamed Eleiche
RTCM3.1. mērījumu transformācijas ziĦojuma standarts GNSS pozicionēšanas
dienestiem.
Attiecībā uz novērojumu RTCM korekcijas datu lietošanu GNSS pozicionēšanas dienestiem, tad ăeocentriskās
(x,y,z) jeb elipsoidālās (φ,λ,h) koordinātas koriăēšanas rezultātā itransformē vai nu ITRF vai arī reăionālā ITRF
sistēmā (piem., ETRF 89 Eiropā). GNSS pakalpojumu izmantotāji rezultātus tomēr parasti lieto reăionālās vai
lokālās koordinātu un augstumu sistēmās. Tādejādi nepieciešamas koordinātu transformācijas. Patreiz, apriori
aprēėinātos transformācijas parametrus un/vai ăeoīda modeĜus īpašā kārtībā pārraida GNSS kontrolieriem
vispirms. Patreizējo 2007 RTCM 3.1. transformāciju mērėis ir definēt transformācijas algoritmus un datu
struktūras ar septiĦiem RTCM ziĦojumiem, kas GNSS dienestiem Ĝauj tos nosūtīt kā attiecīgos RTCM
transformācijas ziĦojumus GNSS pakalpojumu izmantotājam. Šādā ceĜā GNSS kontrolierī lietotie
tramsformācijas ziĦojumi un augstāk minētās uz ITRF sistēmu bāzētās koordinātas automātiski tiek
transformētas uz izvēlētajām horizontālo plaknes koordinātu un vertikālo augstuma koordinātu sistēmu.
Sagatavošanās augstāk minētajai datu transformācijai un sekojošām manuālām operācijām GNSS mērījumu
laikā kĜūst vecmodīga. Programmatūra un sakaru arhitektūra RTCM transformācijas ziĦojumu izmantošanai
GNSS pakalpojumos var tikt realizēta, lietojot servera-klienta koncepciju. Vēlamo sistēmu transformācijas
ieviestas tā saucamo transformācijas moduĜu veidā un kā RTCM servera transformācijas ziĦojums. Tādā veidā
GNSS rovera NMEA ziĦojumā pārraidītā pozicija tiek lietota kā pieprasījums bāzes serverim un tas tiek raidīts
caur administrējošo GNSS tīkla programmatūru uz RTCM transformācijas ziĦojumu serveri. Atkarībā no RTCM
transformācijas ziĦojumu servera konfigurācijas tiek aktivizēti dažādi transformācijas moduĜi un dažādu
specifikāciju uzturētas ziĦojumu konstrukcijas. Atbilstoši tiek ăenerēti viens vai vairāki RTCM transformācijas
ziĦojumi binārā kodā un tiek nosūtīti ar GNSS tīkla programmatūru klientam – GNSS kontrolierim. Rakstā
analizē datu struktūras, saistītas ar RTCM 3.1 standarta transformācijas ziĦojumu, kā arī tas, kā klients lieto
saĦemtos transformācijas ziĦojumus un transformē no ITRF bazes sistēmas (izejas sistēma) uz lietotāja izvēlēto
horizontālo un vertikālo atbalsta koordinātu sistēmu (mērėa sistēma).Pārbaudīta septiĦu parametru
transformācijas daĜa un koncepcija par nesaišu tīkla un fiziskā augstuma ieviešanu. Attiecībā par augstumu ir
paskaidrots, kā, lietojot t.s.augstuma indikātorus, RTCM transformācijas ziĦojumi divos dažādos veidos
reprezentē fizisko augstumu.
М.Элейхе. Стандарт сообщения по трансформации измерений RTCM3.1 для служб
позицинирования ГНСС.
В отношении к использованию службами позицирования ГНСС корректированных данных наблюдений
RTCM, то геоцентрические (x,y,z) или элипсоидальные (φ,λ,h) координаты в результате коррекции
трансформируют в систему ITRF или региональную (напр. ETRF89 в Европе систему. Пользователи
услугами ГНСС результаты обычно используют региональные или локальные системы координат и
высот. Поэтому необходима трансформация координат. В настоящее время вычеслленые авторамы
параметры трансформаций и/или сперва в особом порядке передают модели геоида контролерам
ГНСС.
Цель современных трансформаций 2007 RTCM3.1 определить алгоритмы трансформации и структуры
данных 7 сообщениями RTCM, что позволит службам ГНСС послать как соответствующие сообщения
трансформации RTCM пользователю услуг ГНСС. Таким путем сообщения по трансформации которые
применяют в контролере ГНСС и вышеупомянутые на системе ITRF основанные координаты
автоматически трансформируются на избранные системы координат горизонтальной плоскости и
вертикальных высот. Подготовка трансформации данных и последующих мануальных операций во
время измерений ГНСС стала старомодной. Программатура и архитектура связей при использовании
сообщений RTCM в услугах ГНСС может быть осуществлена в концепции сервер – клиент. Желанные
трансформации систем введены в виде т.н. модулей трансформации и как сообщение о
трансформации сервера RTCM. Таким образом переданная в сообщении NMEA позиция используется как
запрос базовому серверу и запрос передается через администрирующую сеть ГНСС программатуру на
54
сервер сообщения трансформации RTCM. В зависимости от конфигурации сообщений трансформации
RTCM активизируются различные модули трансформации и на различных спецификациях созданные
конструкции сообщений. Соответсвенно генерируют один или несколько сообщений трансформации
RTCM в бинарный код и посылаются программатурой сети ГНСС клиенту –контролеру ГНСС. В
статье анализируются структуры данных связанные с сообщением стандартной трансформации
RTCM3.1 а также то как клиент использует полученные сообщения трансформации и переводит с
базовой системы ITRT (исходнаясистема) на избранную пользователем систему горизонтальных и
вертикальных координат (цеваясистема). Проверены трансформации 7 параметров и концепция о
неувязке сети и физической высоты. В отношении высоты поясняется, что используя т.н. индикаторы
высоты сообщения трансформации RTCM в двух различных видах представляют физическую высоту.
