DynaNet User's Guide V3.3
User Manual: Pdf
Open the PDF directly: View PDF .
Page Count: 234 [warning: Documents this large are best viewed by clicking the View PDF Link!]
DynaNet User’s Guide
Roger Fraser, Frank Leahy, Philip Collier
DynaNet User’s Guide
Dynamic Network Adjustment Software
©Commonwealth of Australia (Geoscience Australia) 2017.
With the exception of the Commonwealth Coat of Arms and where otherwise noted, this product is provided
under a Creative Commons Attribution 4.0 International Licence.
For all technical and software related matters, please contact:
Dr. Roger Fraser
Manager, Geodetic Survey
Oﬃce of Surveyor-General Victoria
Department of Environment, Land, Water and Planning
Level 17/570 Bourke St, Melbourne, Victoria, 3000
DynaNet User’s Guide
Dr. Roger Fraser
Manager, Geodetic Survey
Oﬃce of Surveyor–General Victoria
Dr. Frank Leahy
University of Melbourne
Dr. Phil Collier
Cooperative Research Centre for Spatial Information
The development of this software and user guide has beneﬁted from the assistance provided by
several individuals and organisations. In particular, the authors gratefully acknowledge the following
people for their advice, support, feedback, supply of sample data ﬁles and contribution at various
levels: Gary Johnston, John Dawson, Nick Brown, Craig Harrison and Ted Zhou from Geoscience
Australia (Commonwealth); Ben Menadue and Dale Roberts from the National Computational
Infrastructure (Commonwealth); John Tulloch (retired), David Boyle, Alex Woods, Dave Collett, Bob
Ross (retired) and Peter Growse (retired) from the Department of Environment, Land, Water and
Planning (Victoria); Matt Higgins, Steve Tarbit, Mike Cowie, Darren Burns and Peter Todd (retired)
from the Department of Natural Resources and Mines (Queensland); Simon McElroy, Joel Haasdyk
and Nic Gowans from the Department of Finance, Services and Innovation (New South Wales); Linda
Morgan (retired), Irek Baran and Kent Wheeler from Landgate (Western Australia); Graeme Blick,
Nic Donnelly and Chris Crook from Land Information New Zealand (New Zealand); Scott Strong from
the Department of Primary Industries, Parks, Water and Environment (Tasmania); Stephen Latham
and Peter Stolz from the Department of Planning, Transport and Infrastructure (South Australia);
Gavin Evans from the Department of Environment and Sustainable Development (ACT); Rob Sarib
and Amy Peterson from the Department of Lands and Planning (Northern Territory); Simon Fuller
of ThinkSpatial (Victoria); Peter Teunissen of Curtin University; Chris Rizos of the University of New
South Wales; and Rod Deakin (retired) and Don Grant of Royal Melbourne Institute of Technology.
Freely ye have received, freely give
Remember the words of the Lord Jesus, how He said, “It is more blessed to give than to receive”
Acknowledgements ...................................... v
ListofTables ......................................... xvii
ListofAbbreviations ..................................... xix
ListofSymbols ........................................ xxi
1 Introduction 1
1.1 Brief history of phased adjustment and DynaNet . . . . . . . . . . . . . . . . . . . 1
1.1.1 Preamble to Version 3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions used in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Programoverview.................................... 4
1.3.1 Software architecture and information ﬂow . . . . . . . . . . . . . . . . . . 4
1.3.2 Program execution and command line options . . . . . . . . . . . . . . . . 6
1.3.3 Program execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Two–minute quick start tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Creating, editing and processing projects 13
2.1 Introduction....................................... 13
2.2 Conventions used in DynaNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Filenaming................................... 13
2.2.2 Filetypes.................................... 14
2.2.3 Directories ................................... 15
2.3 Project setup and processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Prepare station and measurement ﬁles . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Create DynaNet project ﬁle . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Automated project processing . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Import and export of geodetic network information 17
3.1 Introduction....................................... 17
3.2 Importing station and measurement information . . . . . . . . . . . . . . . . . . . . 17
3.2.1 Station coordinate information . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Supported measurement types . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 Networkconstraints .............................. 19
3.2.4 Geoidinformation ............................... 21
3.2.5 File name argument conventions . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.6 Progress reporting and import log . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.7 Veriﬁcation and error checking . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Conﬁguring import options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Referenceframe ................................ 24
3.3.2 Datascreening ................................. 25
3.3.3 GNSS variance matrix scaling . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Network measurement simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Dataexport....................................... 35
3.5.1 Station and measurement ﬁles . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2 Association lists and station map . . . . . . . . . . . . . . . . . . . . . . . 35
4 Transformation of coordinates and measurements 37
4.1 Introduction....................................... 37
4.2 Reference frame fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Cartesian reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Geographic reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 Local reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 Polar reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Transformation between cartesian reference frames . . . . . . . . . . . . . . . . . . 42
4.4 Propagation of variances between reference frames . . . . . . . . . . . . . . . . . . 43
4.4.1 Local reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.2 Polar reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.3 Geographic reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Conversion of projection coordinates . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.6 Transformation of coordinates and measurements . . . . . . . . . . . . . . . . . . . 47
4.6.1 Supported reference frames and geodetic datums . . . . . . . . . . . . . . . 47
4.6.2 Relationship between ITRF, IGS and WGS84 reference frames . . . . . . . . 49
4.6.3 Transforming station coordinates and measurements . . . . . . . . . . . . . 50
4.7 Dataexport....................................... 51
5 Import and export of geoid information 53
5.1 Introduction....................................... 53
5.2 Fundamentalconcepts ................................. 53
5.2.1 Geoidmodels.................................. 55
5.2.2 Conventions used in DynaNet . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Gridﬁleinterpolation.................................. 56
5.3.1 Bilinear interpolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2 Bicubicinterpolation.............................. 58
5.4 Import of geoid information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.5 Arbitrary interpolation and height transformation . . . . . . . . . . . . . . . . . . . 61
5.5.1 Interactivemode ................................ 61
5.5.2 Textﬁlemode ................................. 62
5.6 Exporting interpolated information . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.7 Working with NTv2 geoid grid ﬁles . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.7.1 Reporting NTv2 geoid grid ﬁle metadata . . . . . . . . . . . . . . . . . . . 64
5.7.2 Importing WINTER DAT geoid grid ﬁles . . . . . . . . . . . . . . . . . . . 65
5.7.3 Grid ﬁle interpolation errors . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 Network segmentation 69
6.1 Introduction....................................... 69
6.2 The concept of network segmentation . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3 Segmentationalgorithm................................. 71
6.4 Accommodating variations in network design, size, user preferences and computer
performance ...................................... 72
6.4.1 Optimum block size and maximum adjustment eﬃciency . . . . . . . . . . 73
6.4.2 Inevitable inﬂuences on the generated block sizes . . . . . . . . . . . . . . . 74
6.4.3 Factors inﬂuencing the segmentation rate . . . . . . . . . . . . . . . . . . . 76
6.4.4 Generating coordinate estimates and full variance matrix for a user–deﬁned
setofstations ................................. 77
6.4.5 Datum deﬁcient blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.6 Non–contiguous networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5 Segmentinganetwork ................................. 78
6.5.1 Conﬁguring segmentation behaviour . . . . . . . . . . . . . . . . . . . . . . 79
18.104.22.168 Specifying stations to appear in the ﬁrst block . . . . . . . . . . . . 79
22.214.171.124 Achieving optimum block sizes . . . . . . . . . . . . . . . . . . . . 80
126.96.36.199 Isolated networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7 Mathematical models for dynamic network adjustment 83
7.1 Introduction....................................... 83
7.2 Observationequations ................................. 83
7.2.1 Slopedistances(S)............................... 84
7.2.2 Ellipsoid arc (E) and ellipsoid chord (C) distances . . . . . . . . . . . . . . 84
7.2.3 Mean sea level (MSL) arc distances (M) . . . . . . . . . . . . . . . . . . . 85
7.2.4 Ellipsoid heights (R) and height diﬀerences . . . . . . . . . . . . . . . . . . 86
7.2.5 Orthometric heights (H) and height diﬀerences (L) . . . . . . . . . . . . . . 87
7.2.6 Cartesian coordinates and GNSS point clusters (Y) . . . . . . . . . . . . . . 88
7.2.7 GNSS baselines (G) and GNSS baseline clusters (X) . . . . . . . . . . . . . 88
7.2.8 2D position via geodetic latitude (P) and longitude (Q) . . . . . . . . . . . 89
7.2.9 Geodetic azimuths and horizontal bearings (B) . . . . . . . . . . . . . . . . 90
7.2.10 Horizontal angles (A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2.11 Horizontal direction sets (D) . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2.12 Zenith distances (V) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.2.13 Verticalangles(Z)............................... 93
7.2.14 Astronomic latitude (I) and longitude (J) . . . . . . . . . . . . . . . . . . . 94
7.2.15 Astronomic (or Laplace) azimuth (K) . . . . . . . . . . . . . . . . . . . . . 95
7.3 Stochastic modelling and reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3.1 Probability distributions used in DynaNetfor testing . . . . . . . . . . . . . 95
188.8.131.52 Normal distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 95
184.108.40.206 Chi–square distribution . . . . . . . . . . . . . . . . . . . . . . . . 96
220.127.116.11 Student’s t distribution . . . . . . . . . . . . . . . . . . . . . . . . 98
7.3.2 Preparation of measurement precisions and variance matrices . . . . . . . . 99
18.104.22.168 Scaling GNSS variance matrices . . . . . . . . . . . . . . . . . . . 100
7.3.3 Expressing estimates of quality and reliability . . . . . . . . . . . . . . . . . 101
22.214.171.124 Positional uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . 103
126.96.36.199 Measurement reliability and network reliability . . . . . . . . . . . . 103
8 Estimation of station parameters 105
8.1 Introduction....................................... 105
8.2 Overview of least squares estimation . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.3 Adjustinganetwork................................... 108
8.3.1 Simultaneousmode .............................. 108
8.3.2 Phased adjustment mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
188.8.131.52 Single–thread mode . . . . . . . . . . . . . . . . . . . . . . . . . . 113
184.108.40.206 Multi–thread mode . . . . . . . . . . . . . . . . . . . . . . . . . . 114
220.127.116.11 Block–1 only mode . . . . . . . . . . . . . . . . . . . . . . . . . . 115
18.104.22.168 Staged adjustment mode . . . . . . . . . . . . . . . . . . . . . . . 115
22.214.171.124 Report results mode . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.3.3 Adjustment conﬁguration options . . . . . . . . . . . . . . . . . . . . . . . 116
8.3.4 Output conﬁguration options . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.3.5 Export conﬁguration options . . . . . . . . . . . . . . . . . . . . . . . . . . 121
9 Estimating uncertainty and testing least squares adjustments 125
9.1 Introduction....................................... 125
9.2 Algorithms for estimating uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.1 Precision of the estimated parameters . . . . . . . . . . . . . . . . . . . . . 125
9.2.2 Precision of the adjusted measurements . . . . . . . . . . . . . . . . . . . . 126
9.3 Testing least squares adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3.1 Testing the least squares adjustment as a whole . . . . . . . . . . . . . . . 127
126.96.36.199 Rectifying over–optimistic variance matrices of the same type . . . . 129
9.3.2 Testing for the presence of outliers . . . . . . . . . . . . . . . . . . . . . . 131
188.8.131.52 Testing measurements with reliable estimates of precision . . . . . . 131
184.108.40.206 Testing measurements with doubtful estimates of precision . . . . . 135
9.3.3 Hints on addressing measurement failures . . . . . . . . . . . . . . . . . . . 141
Index of subjects 147
A Command line reference 151
A.1 dynanet ......................................... 151
A.2 import.......................................... 152
A.3 reftran.......................................... 156
A.4 geoid........................................... 157
A.5 segment......................................... 160
A.6 adjust .......................................... 162
A.7 plot ........................................... 166
B File format speciﬁcation 171
B.1 Dynamic Network Adjustment (DNA) format . . . . . . . . . . . . . . . . . . . . . 171
B.1.1 Changes from Version 1 to Version 3 . . . . . . . . . . . . . . . . . . . . . 171
B.1.2 Headerline................................... 171
B.1.3 Stationinformation............................... 172
B.1.4 Measurement information . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
B.1.5 Geoidinformation ............................... 182
B.2 Comma Separated Values (CSV) format . . . . . . . . . . . . . . . . . . . . . . . . 183
B.3 Dynamic Network Adjustment Project (DNAPROJ) format . . . . . . . . . . . . . . 184
B.4 DynaNet Markup Language (DynaML) format . . . . . . . . . . . . . . . . . . . . . 188
B.4.1 Stationinformation............................... 188
B.4.2 Measurement information . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.5 GeodesyMLformat ................................... 193
B.6 SINEXformat...................................... 193
B.7 Geoid input text ﬁle format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
C Output ﬁle format speciﬁcation 195
C.1 Headerblock ...................................... 195
C.2 Importlogﬁle(IMP) .................................. 195
C.3 Measurement to station output ﬁle (M2S) . . . . . . . . . . . . . . . . . . . . . . 196
C.4 Segmentation output ﬁle (SEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
C.5 Coordinate output ﬁle (XYZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
C.6 Adjustment output ﬁle (ADJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
C.6.1 Adjustment statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
C.6.2 Measurement to station connections . . . . . . . . . . . . . . . . . . . . . 203
C.6.3 Adjusted measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
C.6.4 Estimated station coordinates . . . . . . . . . . . . . . . . . . . . . . . . . 206
C.6.5 Output of results on each iteration . . . . . . . . . . . . . . . . . . . . . . 206
C.7 Station coordinate corrections ﬁle (COR) . . . . . . . . . . . . . . . . . . . . . . . 207
C.8 Adjusted positional uncertainty ﬁle (APU) . . . . . . . . . . . . . . . . . . . . . . 209
C.9 SINEX output warning ﬁle (SNX.ERR) . . . . . . . . . . . . . . . . . . . . . . . . 212
List of Figures
1.1 Coordination of DynaNet program execution . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Flow of information between various DynaNet programs and input and output ﬁles . 6
1.3 DynaNet program execution sequence . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Stations and measurements in the skye network.................... 9
3.1 import progress reporting of data import, conversion and processing . . . . . . . . . 22
3.2 Stations and measurements in the skye network ﬁltered by the --bounding-box option. 26
3.3 Stationrenamingﬁle .................................. 28
3.4 Baselinescalarﬁle.................................... 33
3.5 Example simulation measurements list . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1 The ellipsoid–centred cartesian reference frame . . . . . . . . . . . . . . . . . . . . 38
4.2 The local reference frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Orthogonal reference frames displaced by geodetic azimuth, vertical angle and distance 41
4.4 reftran progress reporting of station and measurement transformations . . . . . . . 51
5.1 The relationships between the natural terrain, ellipsoid, geoid, mean sea level, and
seasurface. ....................................... 54
5.2 The relationship between the geoid and quasigeoid, and between ellipsoid height (h)
and normal orthometric height (HNO)......................... 55
5.3 Bilinear interpolation concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4 geoid progress reporting of geoid grid ﬁle interpolation . . . . . . . . . . . . . . . . 61
5.5 Interactive geoid grid ﬁle interpolation . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.6 geoid progress reporting of geoid interpolation and text ﬁle transformation . . . . . 63
5.7 Example NTv2 grid ﬁle summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.8 Progress of NTv2 grid ﬁle creation . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1 Network segmentation concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 A trivial GNSS network segmented into two blocks . . . . . . . . . . . . . . . . . . 70
6.3 Network segmentation concept involving four blocks . . . . . . . . . . . . . . . . . . 72
6.4 Segmentation of a geodetic network having stations with large numbers of measurements. 74
6.5 GNSS, direction set and distance measurements in the Victorian geodetic network
associated with MORANG PM 48. . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.6 Segmentation of a spirit levelling network having stations with a low measurement
count. .......................................... 76
6.7 segment progressreporting............................... 79
6.8 Segmentation summary for uni_sqr with a block threshold of 45 . . . . . . . . . . . 80
6.9 Segmentation summary for uni_sqr with a block threshold of 45 and minimum inner
stationcountof35 ................................... 81
7.1 Slope, ellipsoid arc and ellipsoid chord distances . . . . . . . . . . . . . . . . . . . . 84
7.2 Mean sea level arc distances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3 Relationships between slope distance, MSL arc distance, ellipsoid arc distance and
ellipsoid chord distance measurements . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.4 Heights and height diﬀerences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.5 Bearings and horizontal angles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.6 Cluster of horizontal directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.7 Zenithdistances..................................... 93
7.8 Verticalangles...................................... 94
7.9 TheNormaldistribution................................. 96
7.10 Chi–square (χ2) distributions for 4, 6, 10 and 20 degrees of freedom . . . . . . . . . 97
7.11 Student’s t distributions for 2, 5, 10 and 50 degrees of freedom . . . . . . . . . . . . 98
7.12 The error ellipse and its dependence on coverage factor k............... 102
8.1 adjust progressreporting ................................ 109
8.2 Single–threadmode................................... 111
8.3 Multi–thread mode on four cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4 Thread switching on a single core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.5 Block–1onlymode ................................... 113
8.6 Progress reporting using single–thread adjustment mode . . . . . . . . . . . . . . . 114
8.7 Progress reporting using multi–thread adjustment mode . . . . . . . . . . . . . . . . 114
8.8 Progress reporting using Block–1 only adjustment mode . . . . . . . . . . . . . . . 115
9.1 Adjustment summary from a sample GNSS network . . . . . . . . . . . . . . . . . . 136
9.2 Adjusted measurements table from a sample GNSS network — without a–priori
variancematrixscaling ................................. 137
9.3 Adjusted measurements table from a sample GNSS network — with a–priori variance
matrixscaling ...................................... 138
9.4 (a) Level run adjustment with all original measurements, and (b) Repeat level run
adjustment with the suspect measurement removed . . . . . . . . . . . . . . . . . . 140
B.1 Exampleheaderlines .................................. 172
B.2 Example station ﬁle with coordinates in UTM,LLH and XYZ formats . . . . . . . . . . 173
B.3 Example angle measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
B.4 Example geodetic azimuths, astronomic azimuths, zenith distances and vertical angles 175
B.5 Exampledirectionsets.................................. 176
B.6 Example ellipsoid chords, ellipsoid arcs, Mean Sea Level arcs, slope distances and
heightdiﬀerences .................................... 177
B.7 Example GNSS baseline measurement . . . . . . . . . . . . . . . . . . . . . . . . . 179
B.8 Example GNSS baseline clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
B.9 Example GNSS point clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
B.10 Example orthometric height and ellipsoid height measurements. . . . . . . . . . . . . 181
B.11 Example geodetic latitude and longitude, and astronomic latitude and longitude
B.12 Example geoid information records . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
B.13 Example general options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
B.14 Example import options. ................................ 185
B.15 Example reftran options. ................................ 185
B.16 Example geoid options.................................. 185
B.17 Example segment options. ............................... 186
B.18 Example adjust options. ................................ 186
B.19 Example output options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
B.20 DnaXMLFormat schemadeﬁnition ............................ 188
B.21 DnaStation schemadeﬁnition.............................. 189
B.22 Sample station ﬁle encoded in DynaML format . . . . . . . . . . . . . . . . . . . . 189
B.23 DnaMeasurement schemadeﬁnition ........................... 190
B.24 Clusterpoint and GPSBaseline schema deﬁnition . . . . . . . . . . . . . . . . . . . 191
B.25 Directions and GPSCovariance schema deﬁnition . . . . . . . . . . . . . . . . . . . 191
B.26 Sample measurements encoded in DynaML format . . . . . . . . . . . . . . . . . . 192
B.27 Example formatted text ﬁle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
B.28 Example comma separated values ﬁle . . . . . . . . . . . . . . . . . . . . . . . . . . 194
List of Tables
3.1 Station coordinate types handled by the supported ﬁle formats . . . . . . . . . . . . 18
3.2 Supported measurement types and measurement codes . . . . . . . . . . . . . . . . 19
3.3 GNSS variance matrix scaling options . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 StationMapﬁelds.................................... 36
3.5 Associated Stations List ﬁelds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Associated Measurements List ﬁelds . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1 EPSG codes and reference frames . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Supported transformation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Alignment of IGS precise orbit product reference frames with ITRF updates over time
(source: http://acc.igs.org/igs-frames.html) ................. 49
4.4 Alignment of WGS84 realisations with ITRF updates over time (source: https:
5.1 NTv2 grid ﬁle overview ﬁelds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 NTv2 grid ﬁle sub grid ﬁelds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Grid ﬁle interpolation error codes and descriptions . . . . . . . . . . . . . . . . . . . 67
6.1 Distribution of parameters and measurements of a network segmented into two blocks 71
7.1 Conﬁdence intervals for ±1σto ±4σ. ......................... 96
9.1 Student’s t conﬁdence intervals for α= 95%,r= 2 . . . 1000 ............. 135
A.1 dynanet standardoptions................................ 151
A.2 dynanet genericoptions ................................ 152
A.3 import standardoptions ................................ 153
A.4 import referenceframeoptions............................. 153
A.5 import datascreeningoptions ............................. 154
A.6 import GNSS variance matrix scaling options . . . . . . . . . . . . . . . . . . . . . 155
A.7 import network simulation options . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
A.8 import exportoptions.................................. 156
A.9 reftran standardoptions ................................ 156
A.10 reftran transformationoptions ............................. 157
A.11 reftran exportoptions ................................. 157
A.12 geoid standardoptions ................................. 158
A.13 geoid interpolationoptions............................... 158
A.14 geoid NTv2creationoptions .............................. 159
A.15 geoid interactive interpolation options . . . . . . . . . . . . . . . . . . . . . . . . . 159
A.16 geoid ﬁle interpolation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.17 geoid exportoptions .................................. 160
A.18 segment standardoptions ............................... 161
A.19 segment conﬁgurationoptions............................. 161
A.20 adjust standardoptions................................. 162
A.21 adjust adjustment mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.22 adjust phased adjustment options . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.23 adjust adjustment conﬁguration options . . . . . . . . . . . . . . . . . . . . . . . . 163
A.24 adjust staged adjustment options . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.25 adjust adjustment output options . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
A.26 adjust exportoptions.................................. 166
A.27 plot standardoptions .................................. 167
A.28 plot data conﬁguration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
A.29 plot mappingoptions .................................. 168
A.30 plot PDFvieweroptions ................................ 169
B.1 Header line column locations and ﬁeld widths . . . . . . . . . . . . . . . . . . . . . 172
B.2 Station information column locations and ﬁeld widths . . . . . . . . . . . . . . . . . 173
B.3 General measurement information column locations and ﬁeld widths . . . . . . . . . 174
B.4 Column locations and ﬁeld widths for horizontal angles . . . . . . . . . . . . . . . . 174
B.5 Column locations and ﬁeld widths for geodetic azimuths, astronomic azimuths, zenith
distances and vertical angles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
B.6 Column locations and ﬁeld widths for direction sets. . . . . . . . . . . . . . . . . . . 176
B.7 Column locations and ﬁeld widths for ellipsoid chords, ellipsoid arcs, Mean Sea Level
arcs, slope distances and height diﬀerences. . . . . . . . . . . . . . . . . . . . . . . 176
B.8 Column locations and ﬁeld widths for a GNSS baseline (single or cluster) header record.177
B.9 Column locations and ﬁeld widths for a GNSS point cluster header record. . . . . . . 178
B.10 Column locations and ﬁeld widths for GNSS baseline and point measurements. . . . 178
B.11 Column locations and ﬁeld widths for a GNSS cluster covariance block. . . . . . . . 179
B.12 Column locations and ﬁeld widths for orthometric and ellipsoid height measurements. 181
B.13 Column locations and ﬁeld widths for geodetic latitudes and longitudes, and astronomic
latitudesandlongitudes. ................................ 181
B.14 Geoid information column locations and ﬁeld widths . . . . . . . . . . . . . . . . . . 182
B.15 DynaNet program options formatting. . . . . . . . . . . . . . . . . . . . . . . . . . 184
B.16 Formatted text ﬁle ﬁelds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
B.17 Comma separated values ﬁle ﬁelds . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
C.1 Measurement to station connections table . . . . . . . . . . . . . . . . . . . . . . . 198
C.2 Segmentation summary table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
C.3 Individual block data table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
C.4 Adjusted station coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
C.5 Adjustment statistics summary table . . . . . . . . . . . . . . . . . . . . . . . . . . 203
C.6 Adjusted measurements and associated statistics table . . . . . . . . . . . . . . . . 204
C.7 Computed measurements (a–priori) on each iteration . . . . . . . . . . . . . . . . . 206
C.8 Coordinate corrections table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
C.9 Adjusted positional uncertainty table . . . . . . . . . . . . . . . . . . . . . . . . . . 209
C.10 Positional uncertainty covariance block . . . . . . . . . . . . . . . . . . . . . . . . . 210
List of Abbreviations
AGD66 Australian Geodetic Datum 1966
AGD84 Australian Geodetic Datum 1984
AHD Australian Height Datum. Commonly used in reference to Australian Height Datum
1971 (AHD71) and Australian Height Datum (Tasmania) 1983 (AHD–TAS83).
AHD–TAS83 The Australian Height Datum (Tasmania) 1983 is the normal–orthometric height
datum for mainland Tasmania.
AHD71 The Australian Height Datum 1971 is the normal–orthometric height datum for
CSV Comma Separated Values
DNA Dynamic Network Adjustment
DynaML DynaNet Markup Language. XML format deﬁned according to the DynaNet 2.0 XML
EPSG European Petroleum Survey Group
GDA2020 Geocentric Datum of Australia 2020. Realised by continuous analysis of over 400
Asia Paciﬁc Reference Frame sites, referenced to the GRS80 ellipsoid and determined
with respect to ITRF2014 at epoch 2020.0.
GDA94 Geocentric Datum of Australia 1994. Realised by the derived coordinates of the
Australian Fiducial Network (AFN) geodetic stations, referenced to the GRS80 ellipsoid
and determined with respect to ITRF92 at epoch 1994.0.
GLONASS GLObal NAvigation Satellite System
GMA Geodetic Model of Australia. Implemented via the adjustments termed GMA73,
GMA80, GMA82 and GMA84.
GNSS Global Navigation Satellite System
GPS Global Positioning System
GRS80 Geodetic Reference System 1980 reference ellipsoid, where a = 6378137.0 m, f =
ICSM Intergovernmental Committee on Surveying and Mapping
IGS International GNSS Service
ITRF International Terrestrial Reference Frame — a realisation of the International Terrestrial
Reference System (ITRS) produced by the International Earth Rotation and Reference
Systems Service (IERS).
MGA94 Map Grid of Australia 1994. Universal Transverse Mercator projection of the Geocentric
Datum of Australia 1994.
MSL Mean sea level
PDF Probability Density Function
RHEL RedHat Enterprise Linux
SINEX Solution INdependent EXchange format.
TM Transverse Mercator
UTM Universal Transverse Mercator
WGS84 World Geodetic System of 1994
XML eXtensible Markup Language
List of Symbols
θ12 Geodetic azimuth between points 1and 2.
α123 Horizontal angle at point 1, between points 2and 3.
s12 Slope or direct distance between points 1and 2.
c12 Ellipsoid chord distance between points 1and 2.
e12 Ellipsoid arc distance between points 1and 2.
m12 Mean sea level arc distance between points 1and 2.
ζ12 Zenith distance from point 1 to 2.
ϑ12 Vertical angle from point 1 to 2.
νRadius of curvature in the prime vertical.
ρRadius of curvature in the prime meridian.
aSemi–major axis of the reference ellipsoid.
bSemi–minor axis of the reference ellipsoid.
e2First eccentricity of the reference ellipsoid.
x, y, z X, Y and Z coordinates in the cartesian reference frame.
φ, λ, h Geodetic latitude, geodetic longitude and ellipsoid height in the geographic reference
e, n, up East, north and up coordinates in the local reference frame.
θ, ϑ, s Geodetic azimuth, vertical angle and direct distance in the polar reference frame.
E, N, Zo Easting, Northing and zone of a Universal Transverse Mercator (UTM) projection.
k0UTM central scale factor.
λ0Longitude of the central meridian of a UTM zone.
zwUTM zone width.
ξDeﬂection of the vertical in the prime meridian (north–south component).
ηDeﬂection of the vertical in the prime vertical (east–west component).
Combined deﬂection of the vertical calculated from north–south and east–west components.
Nor ζGeoid–ellipsoid separation or height anomaly.
HHeight of point pabove an orthometric height surface.
hHeight of point pabove the ellipsoid.
σStandard deviation of an estimated quantity.
σ2Variance or precision of an estimated quantity.
0Variance factor or sigma zero.
αProbability or signiﬁcance level, expressed as a percentage or value from 0 to 1.0.
kCoverage factor corresponding to the level of signiﬁcance.
rChi–square statistic with rdegrees of freedom.
wSum of the squares of the weighted corrections minimised in the solution of the least
squares normal equations.
τPelzer’s measurement reliability criterion.
TPelzer’s global network reliability criterion.
DynaNet is a rigorous, high performance least squares adjustment application. It has been designed
to estimate 3D station coordinates and uncertainties for both small and extremely large geodetic
networks, and can be used for the adjustment of a large array of Global Navigation Satellite System
(GNSS) and conventional terrestrial survey measurement types. On account of the phased adjustment
approach used by DynaNet, the maximum network size which can be adjusted is eﬀectively unlimited,
other than by the limitations imposed by a computer’s processor, physical memory and operating
system memory model. Example projects where DynaNet can and has been used include the
adjustment of small survey control networks, engineering surveys, deformation monitoring surveys,
national and state geodetic networks and digital cadastral database upgrade initiatives.
DynaNet provides the following capabilities:
•Import of data in geographic, cartesian and/or projection (UTM) coordinates contained in
DNA, CSV, DynaML and SINEX data formats;
•Input of a diverse range of measurement types;
•Transformation of station coordinates and measurements between several static and dynamic
•Rigorous application of geoid–ellipsoid separations and deﬂections of the vertical;
•Simultaneous (traditional) and phased adjustment modes;
•Automatic segmentation and adjustment of extremely large networks in an eﬃcient manner;
•Rigorous estimation of positional uncertainty for all points in a network;
•Detailed statistical analysis of adjusted measurements and station corrections;
•Production of high quality network plots;
•Automated processing and analysis with minimal user interaction.
1.1 Brief history of phased adjustment and DynaNet
Since Gauss published his treatment of the method of least squares in 1809, Tienstra  was
the ﬁrst to develop the concept and principles of phased adjustment. In his work, Tienstra deﬁnes
the principle property of phased adjustment as — “Least squares problems may be divided into
an arbitrary number of phases, provided that in each following phase(s), cofactors resulting from
preceding phases are used.” Using the method of condition equations and Ricci calculus, Tienstra
demonstrated that rigorous parameter estimates for all stations could be derived in a step–wise
fashion by treating the parameters estimated in one phase as quasi–measurements in the next phase.
Since the time of his publication, Tienstra’s concept of phased adjustment has been studied by
several authors, and has been extended and implemented in various forms. Initially, Professor
Dr. Ir. Willem Baarda of the Computing Centre of the Delft Technological University (where Tienstra
was Professor until his death in 1951) led the implementation of Tienstra’s phased adjustment
algorithm for the 1959 adjustment of the United European levelling network [Alberda, 1963]. A
few years later, Lambeck  studied phased adjustment and demonstrated that Krüger’s 
method of stacking normal equations was mathematically equivalent to Tienstra’s phased adjustment
technique. Schmid and Schmid , in their discussion of the generalised approach to least squares,
include an algorithm which solves least squares problems “sequentially” in steps. Their algorithm is
essentially the same as Tienstra’s phased adjustment algorithm, although it is designed to provide for
the addition and removal of measurements after all parameters in the network have been estimated,
rather than to provide a mechanism for handling the adjustment of a large network in stages.
Kouba [1970, 1972] studied the phased adjustment method and demonstrated that the sequential
least squares technique developed by Schmid and Schmid  was mathematically equivalent to
that of Tienstra’s. In his work, Kouba made an important contribution to the study of phased
adjustment by demonstrating that all junction parameter estimates and variances must be carried
between phases if rigorous results are to be achieved. Ying Chung–Chi  summarised Tienstra’s
work using matrix algebra and extended the concept to adjustment by observation equations. Ying
Chung–Chi also demonstrated mathematical equivalence between Tienstra’s method and Krüger’s
method. Although Ying Chung–Chi  does not formally prove that Tienstra’s phased adjustment
method will give the same estimates as a simultaneous adjustment, he demonstrates that it does so
numerically for a simple level network.
The next major application of Tienstra’s concept of phased adjustment was the Canadian Section
Method, developed by Pinch and Peterson . In this development, Pinch and Peterson formally
prove that where two sections of a network are adjusted independently in a ﬁrst stage adjustment,
and the estimates of the parameters common to the two sections (with their variance matrices)
are integrated in a second stage adjustment, the second stage estimates will be identical to those
produced from a simultaneous adjustment. Whilst their method produces rigorous estimates for the
junction station parameters and variance matrices, Gagnon  notes that in the ﬁnal phase of the
process, rigorous variance matrix estimates are not produced for the inner1stations of each block.
The Canadian Section Method has been used widely in Australia for adjustments of the national
network subsequent to the Australian Geodetic Datum 19662(AGD66). These are referred to as
various versions of the Geodetic Model of Australia (GMA) and include the adjustments termed
GMA73, GMA80, GMA82 and GMA84, the latter of which led to the development of the Australian
Geodetic Datum 1984 (AGD84) [Allman, 1983, Allman and Steed, 1984]. The establishment of the
North American Datum 1983 (NAD83) and the European Datum of 1987 (ED87) also made use of
the Canadian Section Method, although they varied from Tienstra’s approach in that they employed
Helmert Blocking for the solution of the normal equations.
Around the time of the development of the early GMA adjustments, Leahy  revisited the
application of Tienstra’s phased adjustment method to the adjustment of large geodetic networks.
This led to further research [Leahy et al., 1986] and the development of VicNet — a two–dimensional
1. Repeated mention of inner and junction stations will be made throughout this user guide. By way of preliminary
deﬁnition, inner stations are the stations which are connected only by measurements in a single section, whereas
junction stations are those which are connected by measurements from two or more sections. See §6.2 for more
2. Whilst the establishment of AGD66 was conducted in phases using the process of segmenting the network into
smaller sections, the approach undertaken for the adjustment and integration of the respective sections didn’t
employ Tienstra’s rigorous phased adjustment technique. This was largely driven by the challenges and complexities
associated with undertaking a large scale adjustment on 1960’s computational infrastructure.
package designed to undertake phased adjustments of geodetic networks comprised of conventional
terrestrial measurements. This software package was reﬁned by Collier  to accommodate
three–dimensional adjustments and the integration of GPS baseline measurements. With these
enhancements and other new capabilities and bug ﬁxes, the software became known as MetNet and
was used extensively for the adjustment of the Melbourne survey control network. Further research
by Leahy  led to the development of a fully automated network segmentation procedure which
can handle networks of any size and conﬁguration, and a rigorous approach for the extension and
integration of networks.
Continued research on the automatic segmentation and phased adjustment of large geodetic networks
gave rise to further reﬁnements in the algorithm and the development of a new 32–bit Windows
package (developed in Visual Basic 6) known as Dynamic Network Adjustment (DNA). The initial
development of DNA was undertaken by Leahy and Collier  at the University of Melbourne and
was made possible through funding provided by the Australian Research Council (ARC) and industry
support from the Oﬃce of Surveyor–General Victoria, AUSLIG Geodesy and WBCM Surveys Pty Ltd.
Following numerous enhancements and reﬁnements in subsequent years, DNA was repackaged and
released as DynaNet version 1.0. In turn, version 2.0 was developed to cater for new measurement
types, and to provide several user enhancements.
1.1.1 Preamble to Version 3.3
DynaNet Version 3.0 is a completely revised version developed by the authors of this user guide. It
has been re–written in C
++ to provide cross–platform support (e.g. Windows, Linux, Mac OS X),
and to take advantage of multi–core processors so as to achieve optimum adjustment performance.
The main speciﬁcations of DynaNet and the environments in which it has been compiled and tested
•Developed using C
++11 and the C
++ Standard Library, Boost [Schäling, 2014], CodeSynthesis
XSD [Kolpackov, 2017] and Apache’s Xerces C
++ XML parser [Apache, 2017];
•The modular architecture design and comprehensive API allows for implementation via custom
•Developed for Windows, Linux and Mac OS X platforms, and runs on 32–bit and 64–bit
•Compiled using Microsoft C
++ 2010 and 2017, Intel C
++ 2014 and 2017, and gcc 4.8.2;
•Tested on Windows XP, Windows 7, Windows 2003 Server. RedHat Enterprise Linux (RHEL)
7, Fedora 23 and OpenSUSE 10.
DynaNet Version 3.3 contains new features and user options, numerous code enhancements, and
various bug ﬁxes.
1.2 Conventions used in this document
The following typographical and mathematical conventions have been adopted throughout this
•DynaNet program names are indicated by bold sans serif font. For example, the program
import is the main program for importing data into DynaNet.
•Program execution on the command line usage is denoted by ﬁxed–width typewriter font.
Examples of program execution at the command prompt are encapsulated by a grey box. If
diﬀerent syntax is required for Windows and UNIX/Linux platforms, syntax for both environments
will be provided. Program options may be either inline with the text or placed within a grey
box. For example, basic command line usage of import is given by:
> import -n network_name network.stn network.msr
and the program option for specifying the input directory is --input-folder.
•File names and ﬁle contents are denoted by ﬁxed–width typewriter font. File contents are
encapsulated by a grey box with column positions shown in a separate box:
!#=DNA 3.00 STN 28.08.2013 GDA94 43
•Math symbols are given in serif font. Variables are denoted by upper or lower case letters in
italics, as in bor B. Matrices are denoted by upper case letters in bold font, as in A, and vectors
are denoted by lower case letters in bold font, as in m. The identity matrix is denoted by I,
and the context in which it is used determines its dimensions. The term variance matrix is used
to refer to the covariance matrix or variance–covariance matrix and is denoted by V. Indexing
of matrix and vector elements is denoted by Cij or cij. Superscripts Tand −1denote the
transpose and inverse respectively. For a random variable x, the notation E(x)∼Nµ, σ2
means that xfollows a Normal distribution with a mean or expected value of µand variance
1.3 Program overview
This section provides an overview of the DynaNet software architecture and a summary of the various
DynaNet programs. The general philosophy of program execution and conﬁguration via program
options and arguments is also explained.
1.3.1 Software architecture and information ﬂow
DynaNet consists of several programs, the functionality of which is distributed across a number of
executables and Dynamic Link Libraries (DLL) using a modular, service–oriented architecture. The
modular architecture of DynaNet aﬀords several advantages, such as:
•Individual programs can be executed to perform a speciﬁc function relating to the processing
and adjustment of geodetic networks;
•One or more programs can be chained together in a customised sequence to satisfy a speciﬁc
•A sequence of program calls can be invoked via scripts at will, at scheduled times or as part
of a larger automated datum maintenance environment;
•Routine and conventional processing of geodetic control surveys can be handled in a single
To assist with conventional end–to–end processing, the main program dynanet serves as a wrapper
application which can be used to coordinate the execution of one or more DynaNet programs in a
single step. The coordination of the various programs is illustrated in Figure 1.1.
reftran geoid plot
Figure 1.1: Coordination of DynaNet program execution
A brief description of the various DynaNet programs is given below:
import To create and process projects in DynaNet, this program must be run ﬁrst to deﬁne
the network name, and to convert geodetic station coordinates and measurements from
external ﬁle formats into the required binary and text ﬁle formats (see §2.2.2). Note that
import only needs to be run once in order to import geodetic station coordinates and
measurements into DynaNet. Accordingly, import does not need to be run for repeated
calls to other programs unless there is a change to the stations or measurements, or if
some form of manipulation to the import process is required. Chapter 3 provides detailed
information on how to use and conﬁgure import.
reftran This program performs reference frame transformations to align all imported stations
and measurements to a common reference frame and epoch. See Chapter 4 for more
information on using reftran.
geoid This program introduces geoid–ellipsoid separations and deﬂections of the vertical into a
project from either an NTv2 formatted geoid model or ASCII text ﬁle. This program can
optionally export interpolated geoid information to a DNA geoid text ﬁle. geoid also
provides a capability to generate NTv2 formatted ﬁles from the legacy AUSGeoid DAT
ﬁle format. See Chapter 5 for more information on using geoid.
segment This program segments a network into a series of inter–connected blocks for use by adjust
in phased adjustment mode. See Chapter 6 for more information on using segment.
adjust This is the main parameter estimation program in DynaNet. adjust can be executed in
simultaneous or phased adjustment mode. When attempting to adjust large networks
using phased adjustment, adjust may be executed in single–thread or multi–thread mode.
For the former, users may opt to use staged mode if physical memory limits prevent
normal program execution. A reverse, Block–1 only adjustment may also be undertaken
if the desired outcome is a full variance matrix for a speciﬁc cluster of stations. See
Chapter 8 for more information on using adjust.
plot This program generates PDF images of a network from the imported information and
graphs relating to network segmentation and adjustment statistics. More information on
plot and its use will be given in a subsequent version of this guide.
As is hinted by Figure 1.1, the coordination of DynaNet programs is handled via a .dnaproj (DynaNet
project) ﬁle. The use of the project ﬁle will be discussed in more detail in Chapter 2.
The programs import,reftran,geoid,segment,adjust and plot read and write a range of formatted
ﬁles in a way which permits the structured ﬂow of information. Figure 1.2 illustrates the ﬂow of
information amongst the various programs and ﬁles.
Figure 1.2: Flow of information between various DynaNet programs and input and output ﬁles
As shown in Figure 1.2, information exported from one program often serves as input to other
programs. This concept aﬀords the user an ability to examine the output from one program before
executing another program, and to re–run certain programs with diﬀerent user options and to examine
the variation in results. A brief description of the various ﬁle types is discussed in Chapter 2.
1.3.2 Program execution and command line options
DynaNet programs can only be executed from the system command prompt (or shell or terminal
emulator), via Windows batch ﬁles (.bat and .cmd) and UNIX/Linux shell scripts (.sh), or from
system calls made within custom–developed programs. Hence, DynaNet Version 3.3 does not provide
a windows–based graphical user interface (GUI).
The convention for executing DynaNet programs is to enter a program name, followed by one or
more options that modify its behaviour and, if required, an argument upon which the program will
act. The convention is as follows:
> program --option argument
The complete command line reference for all DynaNet programs is provided in Chapter A. To display
the command line reference for a DynaNet program, type in the program name at the command
prompt, followed by --help and press Enter:
> dynanet --help
Alternatively, if no program options are provided upon program execution, the program’s version
information and command line reference will be displayed on the screen.
There are over 140 program options which can be used to conﬁgure the way in which DynaNet
programs process geodetic network information. Each DynaNet program will require certain options
speciﬁc to its operation and depending on which option has been provided, additional arguments may
be required. Several options, such as --quiet,--version and --help are common to all programs.
If an option requires an argument, the command line reference will use the term arg.
All options are case–sensitive and must be preceded by two hyphens. Spaces must not be entered
between the hyphen and the option text, however spaces are required between options. Options can
be provided in any order whatsoever. Some options may be speciﬁed using an abbreviated form.
For example, to display the version of a DynaNet program, the abbreviated form -v may be used.
In addition, all DynaNet programs permit the use of partial option text, provided that the partial
option text contains a suﬃcient number of characters to uniquely distinguish the required option
from all other options. For example, the program import will export newly imported stations and
measurements in DNA format if the option --export-dna-files is provided. This function can
also be executed by providing --export-d. However, import will return an error if just --export is
provided since there are ﬁve export options that commence with the text export.
When a program option requires an argument, input may require alpha–numeric entry and/or the
selection of a multiple–choice option. If an argument must include spaces, such as a station name,
enclose the argument with double quotes, such as:
> program --option "arguments with spaces"
For multiple choice options, DynaNet will adopt the default value (denoted in the command line
reference) unless the user overrides it by supplying an alternative argument value. For example,
import provides an ability to specify the default reference frame for all stations and measurements
contained in the user–supplied input ﬁles via the option --reference-frame (or -r in brief). As this
option provides a multiple choice, only predeﬁned reference frames are allowed. If this option is not
provided, import will adopt the Geocentric Datum of Australia 1994 (GDA94) as the default value.
Several options adopt this convention.
Following chapters will explain in detail the function of each program and how to conﬁgure program
behaviour using the program options.
1.3.3 Program execution sequence
Figure 1.3 shows the program execution sequence employed by dynanet when performing end–to–end
processing. For the most part, this sequence will be adequate for conventional geodetic network
processing and adjustment.
Project creation stage
Parameter estimation stage
Network plotting and
Specify network name, reference frame and epoch, import data
into DynaNet format, apply data screening, specify GNSS scaling,
and export data into other formats.
Transform station coordinates and measurements onto the
speciﬁed reference frame and epoch.
Interpolate geoid–ellipsoid separations and deﬂections of the
vertical from geoid model.
Segment the network into a series of blocks.
Estimate station coordinates and uncertainties, calculate network
statistics, adjusted measurements and statistics, output corrections
and export adjustment results.
Plot network map, graph segmentation results and graph
Figure 1.3: DynaNet program execution sequence
There are two circumstances, however, where this sequence may not be appropriate or will need to
be varied. Firstly, depending on the desired outcome, only some stages will be necessary. For this
purpose, dynanet provides the user with an ability to choose which DynaNet programs to execute.
The following examples explain some basic scenarios in which the user will require the execution of
only a subset of the DynaNet programs:
Ellipsoid–only adjustment To estimate coordinates on the ellipsoid from a small geodetic control
survey of GNSS measurements which are aligned to a common reference frame, only import
and adjust are required.
Multiple reference frames If the GNSS measurements in this survey are aligned to diﬀerent reference
frames, then the sequence import,reftran and adjust will be required.
Terrestrial measurements If terrestrial measurements (e.g. angles, distances and orthometric
height diﬀerences) form part of this survey, then the sequence will change to import,reftran,
geoid and adjust. Here, geoid is added to the sequence to obtain geoid–ellipsoid separations
and deﬂections of the vertical which are used by DynaNet to cater for the inﬂuence of gravity
on the terrestrial measurements.
Generate basic network plot If only a plot of all stations and measurements in a network is
required, then only import and plot are required.
Generate plot of error ellipses, uncertainties and corrections If the network plot should also
include estimated error ellipses, circular conﬁdence regions and a–priori station corrections
derived from a least squares adjustment, then the sequence will be import,adjust and plot.
Secondly, network processing and adjustment may require data concatenation, screening (or ﬁltering),
scaling and multiple transformations between diﬀerent reference frames before the network is suitable
for processing by adjust. For these tasks, it is recommended that a script ﬁle be used to string
together the needed program calls to achieve the required program execution sequence.
In either case, knowing which programs to execute will require a knowledge of the data and an
elementary knowledge of geodetic measurement, reference frames and adjustment theory.
1.4 Two–minute quick start tutorial
This section provides a quick start tutorial to processing geodetic network information in DynaNet.
The example used in this tutorial is a network comprised of six stations and nine GNSS baseline
measurements. The the project is named skye, and the stations and measurements are contained
in 2009-10-20-skye.stn and 2009-10-20-skye.msr respectively. Figure 1.4 shows the stations and
measurements in the skye network. The station ﬁle contains a mixture of ellipsoid heights and
orthometric heights on the Australian Height Datum (AHD). The GNSS baseline measurements and
variance matrices have been derived from conventional GNSS processing software and have been
estimated according to the Geocentric Datum of Australia 1994 (GDA94). No scaling has been
applied to the variance matrices.
Figure 1.4: Stations and measurements in the skye network
Step 1 — Prepare the script
For this and many other examples provided in this user guide, it is assumed that users will want
to make use of a script ﬁle to string together several DynaNet program calls. Apart from some
basic diﬀerences, calls to DynaNet programs will be identical for both Windows and UNIX/Linux
platforms and can therefore be copied directly to a Windows batch ﬁle or a UNIX/Linux shell script
For Windows platforms, prepare a ﬁle called run_skye.bat as follows:
rem Script to automate processing of skye geodetic network
For UNIX/Linux platforms, prepare a ﬁle called run_skye.sh as follows:
# Script to automate processing of skye geodetic network
To execute this script using the UNIX/Linux shell, the execute permission for run_skye.sh will need
to be granted to the current user (or group or all users). The ﬁle execute permission can be set by:
$ chmod +x ./run_skye.sh
Alternatively, this script can be executed from the command line using bash:
$ bash ./run_skye.sh
Step 2 — Import the data
The next step to be undertaken is to create a project named skye. In this step, a call to import
is required to name the project and to introduce the station and measurement ﬁles. Setting the
network name and importing ﬁles into DynaNet is achieved by:
import -n skye 2009-10-20-skye.stn 2009-10-20-skye.msr
Upon running this command, the project skye is created and several ﬁles will be written to disk:
skye.bst,skye.bms,skye.map,skye.asl,skye.aml and skye.imp. See Chapter 2 for an explanation
of these ﬁle types.
Step 3 — Introduce geoid–ellipsoid separations
Since DynaNet requires all station heights to be reduced to the ellipsoid prior to adjustment, the next
step is to convert the orthometric station heights to ellipsoid heights. For this purpose, interpolation
of geoid–ellipsoid separations from a geoid model is needed. To this end, the script would be expanded
import -n skye 2009-10-20-skye.stn 2009-10-20-skye.msr
geoid skye -g ./ausgeoid09.gsb --convert-stn-hts
Here, geoid–ellipsoid separations will be interpolated from ausgeoid09.gsb, which is a geoid grid
ﬁle structured according to the National Transformation version 2.0 (NTv2) format. The option
--convert-stn-hts informs geoid that all orthometric station heights should be converted to ellipsoid
heights. After this command is executed, all stations in the binary station ﬁle skye.bst will contain
geoid–ellipsoid separations and deﬂections of the vertical, and any orthometric heights will be reduced
to ellipsoid heights.
Step 4 — Adjust the network
DynaNet oﬀers the ﬂexibility to undertake constrained and minimally constrained (or free) least
squares adjustments in a number of ways. Adjustments may also be performed in a single pass via
simultaneous mode or sequentially in phases using phased adjustment mode. For this tutorial, the
skye network will be adjusted using no constraints and, given the relatively small size of this control
survey, via simultaneous mode. Assuming that station constraints have not been introduced into
either station or measurement ﬁles, the script would be expanded as follows:
import -n 2009-10-20-skye.stn 2009-10-20-skye.msr
geoid skye -g ./ausgeoid09.gsb --convert-stn-hts
adjust skye --output-adj-msr
From this call to adjust, the resulting adjustment output ﬁle will be called skye.simult.adj. The
option --output-adj-msr was added so as to print a table of adjusted measurements and statistics
to the .adj ﬁle.
If it is decided that a station should be constrained, users can choose one of three options to apply
station constraints — (1) set the station constraint ﬂag within the station ﬁle, (2) add a station
position measurement to the measurement ﬁle, including the measurement precision by which to
constrain the station, or (3) specify the station and how it is to be constrained via the call to adjust.
The third option, which in eﬀect replicates the ﬁrst option, can be achieved by the following change
to the call to adjust (using station 302513640 as an example):
adjust skye --output-adj-msr --constraints 302513640,CCC
This section has provided a simple tutorial on using DynaNet to perform a straightforward network
adjustment of GNSS observations. Detailed help on program usage for numerous other processing
tasks will be provided throughout the remainder of this user guide.
Creating, editing and processing
DynaNet uses the concept of a project to manage the input, processing and output of geodetic
network information. For each project, DynaNet uses a project ﬁle to store default and user speciﬁed
options. The user options contained in a project ﬁle conﬁgure the way in which the respective
DynaNet programs handle the geodetic network information relating to a project. At execution
time, each program can be conﬁgured by providing a project ﬁle path as a program argument, or by
specifying the respective options as program arguments. Since DynaNet Version 3.3 can be executed
from the system command prompt or from custom–developed programs, project ﬁles can be used to
completely automate the processing of geodetic networks, and to capture the options used during
This chapter explains the various conventions used by DynaNet for managing projects, how to prepare
input ﬁles, and provides an overview of the basic program operation. More information about the
various options for each program will be explained in subsequent chapters.
2.2 Conventions used in DynaNet
2.2.1 File naming
Central to the management of projects is the network name. DynaNet uses the network name
to form the ﬁle names for all generated output ﬁles, and to determine which ﬁle to open when
information generated from one program must be read as input by another program. The basic ﬁle
naming convention is represented by network_name.ext where network_name is the user–supplied
network name and ext is the ﬁle extension. In some cases, DynaNet generates ﬁles in the form of
network_name.mode.ext where mode represents either a mode in which a program has been executed
or a user–speciﬁed program option.
To permit the input of ﬁles with a diﬀerent ﬁle name to that which is expected from the default
naming convention, the ﬁle name for certain input ﬁles may be overridden by providing the relevant
command line argument. This feature will be covered in more detail in subsequent chapters describing
the input and output options of the various programs.
The network name is a mandatory argument required by all DynaNet programs except import. If
a network name is not speciﬁed when running import, DynaNet adopts the name ’network#’ where
’#’ represents the next available integer that yields a unique (or unused) ﬁle name in the folder of
The primary exceptions to the ﬁle naming convention are station and measurement ﬁles (e.g. *.snx,
*.stn,*.msr,*.xml) provided as input to import, and the raw data ﬁles and formatted grid ﬁles
(e.g. *.dat,*.csv,*.gsb) provided as input to geoid. No restrictions are imposed upon the
naming of these ﬁles other than that the ﬁle extension corresponds with the ﬁle format. The ﬁle
extension restriction is imposed only for certain ﬁle types which prevent DynaNet from automatically
interpreting ﬁle content.
2.2.2 File types
As shown in Figure 1.2 on page 6, DynaNet creates and/or updates a number of binary and text
ﬁles, which are treated as either output and/or input ﬁles. The following is a list of ﬁle types
created by DynaNet in accordance with the ﬁle naming convention (assuming the network name is
Binary formatted ﬁle types
network_name.aml Associated Measurements List. This ﬁle contains a list of measurements that
a station appears in.
.asl Associated Stations List. This ﬁle contains a count of the measurements
connected to a station and the index of this station in the AML ﬁle.
.bms Binary Measurements ﬁle. This ﬁle contains information about the
measurements in a network. The BMS ﬁle is a binary formatted ﬁle created
using an eﬃcient ﬁle structure to provide maximum eﬃciency for retrieving
.bst Binary Stations ﬁle. This ﬁle contains information about the stations in a
network. The BST ﬁle is a binary formatted ﬁle created using an eﬃcient ﬁle
structure to provide maximum eﬃciency for retrieving station information.
.map Station Map. This ﬁle maintains the relationship between the supplied
alphanumeric name and a unique (numerical) station identiﬁer.
.mtx Matrix ﬁle. This ﬁle stores matrices in a structured ﬁle format designed for
eﬃcient data storage.
.dbid Database ID list. This ﬁle contains the user–supplied database IDs for
measurements contained in DNA formatted measurement ﬁles.
ASCII text ﬁle types
network_name.imp import log. This ﬁle is a log of the station and measurement import
.seg segment output. This ﬁle contains the station and measurement indices
for the respective blocks created from network segmentation.
.adj adjust output. This ﬁle contains the adjusted station coordinates and
measurements and associated statistics.
.xyz Adjusted Station Coordinates produced by adjust.
.cor Station Coordinate Corrections produced by adjust. This ﬁle contains
the corrections to the initial station coordinates.
.apu Adjusted Positional Uncertainty produced by adjust. This ﬁle contains
the positional uncertainties of the adjusted station coordinates.
.dbg Debug output. This ﬁle contains detailed program output information
to help assist with isolating network adjustment problems.
.dst Duplicate Stations list. This ﬁle contains a list of stations that were
identiﬁed as duplicates by import.
.dms Duplicate Measurements list. This ﬁle contains a list of measurements
that were identiﬁed as duplicates by import.
.log dynanet log. This ﬁle provides a time–stamped record of the progress
of the individual programs that have been coordinated by dynanet.
By default, all DynaNet programs expect input ﬁles to exist in the directory in which the programs
are run. DynaNet will also generate output ﬁles in this directory. Optionally, an input folder and
an output may be speciﬁed to inform the DynaNet programs where to ﬁnd input ﬁles and where to
store output ﬁles. This feature will be covered in more detail in subsequent chapters.
2.3 Project setup and processing
2.3.1 Prepare station and measurement ﬁles
The ﬁrst step in creating a project is to prepare the station and measurement ﬁles. DynaNet
supports a small range of ﬁle types. Appendix B provides a list of supported ﬁle types and the format
speciﬁcation for selected ﬁle types. Stations and measurements may be provided in one or more ﬁles,
each of which may be encoded in any one of the supported ﬁle formats. DynaNet does not impose
any restrictions on how this information should be structured and so the user is left to decide which
ﬁle type is chosen and how station and measurement information will be stored.
2.3.2 Create DynaNet project ﬁle
In order to process projects in a single step using the main program dynanet, a project ﬁle must be
created. Note that a project ﬁle does not need to be created if the various DynaNet programs will be
executed manually, or executed via Windows batch ﬁles or UNIX/Linux shell scripts. In these cases
however, a project ﬁle will be created and updated automatically as each program is executed.
There are two options for creating a DynaNet project ﬁle — users may create this ﬁle manually or
use import to create this ﬁle automatically. The ﬁle format for the project ﬁle is described in §B.3.
Each time import is executed, a new project ﬁle will be created using the network name and the
default or user–speciﬁed output folder path. If this ﬁle exists, it will be re–created using the options
and arguments supplied. Options which have not been provided will assume default values. All other
options and arguments supplied to import, such as network name and station and measurement
ﬁles, will be printed to project ﬁle. Users not familiar with the project ﬁle format are encouraged
to use import to create the project ﬁle, and to use a text editor to modify the project ﬁle with the
desired options and arguments.
2.3.3 Automated project processing
Upon creating a project ﬁle, projects can be processed in a single step using the main program
dynanet. Using the project ﬁle shown in §B.3 for the skye project (see §1.4), the following command
illustrates how end–to–end processing can be performed in a single step using dynanet.
dynanet -p skye.dnaproj --import --geoid --adjust
The ﬁrst option (-p) and argument (skye.dnaproj) inform dynanet where to ﬁnd the project ﬁle.
Since the folder path was not provided on the command line, DynaNet will assume the project ﬁle
is located in the folder from which dynanet is executed. As shown by the general section in Figure
B.13, §B.3, this folder is C:\Data\proj.
The second, third and fourth options tell dynanet to execute import,geoid and adjust respectively
using the options speciﬁed in the project ﬁle. The order of these options is not important since
dynanet will adopt the program execution sequence shown in Figure 1.3. With respect to import,
the mandatory network name and input ﬁles are entered into the project ﬁle using --network-name
(under #general) and --stn-msr-input-file (under #import) respectively. All other options use
default arguments. For geoid, the NTv2 geoid grid ﬁle path and conversion of orthometric heights to
ellipsoid heights are handled by --ntv2-filepath and --convert-stn-hts (under #geoid). Finally,
conﬁguring adjust to perform a simultaneous adjustment, holding station 302513640 ﬁxed, and
to produce a table of adjusted measurements and statistics in the adjustment output (.adj) ﬁle is
managed by --adjustment-mode and --constraints (under #adjust), and --output-adj-msr (under
#output). Note that the options and arguments under #reftran and #segment are ignored since the
dynanet argument to execute reftran (–reftran) was not provided, and adjust was conﬁgured to
run a simultaneous adjustment.
As dynanet runs, it will load the options contained in the project ﬁle and pass them to the
respective programs. Upon execution, a log ﬁle named dynanet.log will be created and will contain
a time–stamped record of the progress of the individual programs that have been executed. A sample
of the log ﬁle is shown below.
+ Title: dynanet
+ Description: Geodetic network adjustment software
+ Version: 3.2.6, Release (64-bit)
+ Build: Sep 22 2016, 16:23:21 (MSVC++ 10.0)
+ Copyright: (C) 2016 F.J.Leahy, P.A.Collier, R.W.Fraser.
This software is released under a restricted license.
+ Contact: email@example.com
+ +61 407 062 507
+ Executable Start date and time End date and time Exit status
+ import 11-04-2014 6:04:06 PM 11-04-2014 6:04:07 PM Ended successfully.
+ geoid 11-04-2014 6:04:07 PM 11-04-2014 6:04:08 PM Ended successfully.
+ adjust 11-04-2014 6:04:08 PM 11-04-2014 6:04:09 PM Ended successfully.
+ DynaNet finished successfully.
Import and export of geodetic network
DynaNet supports a number of ﬁle formats for the exchange of geodetic network information. The
primary ﬁle formats supported by DynaNet, Version 3.3 for the import and export of stations,
measurements and adjustment solutions include:
CSV (Comma/Character Separated Values format) for the exchange of stations, measurements
and geoid information without concern for aligning data in speciﬁc positions
DNA (Dynamic Network Adjustment format) for the exchange of stations, measurements and
geoid information in a simple, human–readable format. Versions 1 and 3 are supported.
DynaML (DynaNet Markup Language format) for the exchange of stations and measurements in
XML format deﬁned according to the DynaNet 2.0 XML schema
GeodesyML (Geodesy Markup Language format) for the exchange of station, measurement, solution
and covariance information in XML format deﬁned according to ICSM’s eGeodesy GML
SINEX (Solution-INdependent EXchange format) for the exchange of solutions and covariance
Appendix B provides the ﬁle format speciﬁcation for the CSV, DNA and DynaML ﬁle types. The
speciﬁcation for GeodesyML can be found at http://geodesyml.org. The speciﬁcation for the
SINEX ﬁle format can be found at
DynaNet also reads and writes a number of binary and ASCII ﬁle formats for the exchange of geodetic
network adjustment information. These will be described throughout this section as the need arises.
3.2 Importing station and measurement information
The primary program for importing and converting geodetic network stations and measurements into
the format required by DynaNet is import. To import station and measurement information into
DynaNet, type import at the command prompt, followed by one or more options and arguments. The
complete command line reference for import is given in §A.2. If no program options are provided
upon program execution, the command line reference for import will be displayed.
If a DynaNet Project File (c.f. Chapter 2) is to be used, provide --project-file (or its shortcut -p)
followed by the full path for the project ﬁle:
import -p uni_sqr.dnaproj
No other options are required, as import will be invoked using the options and arguments contained
in the project ﬁle uni_sqr.dnaproj.
Alternatively, if all options and arguments are to be entered via the command line, type import, then
--network-name (or its shortcut -n) followed by the network name and the names of the ﬁles that
contain the station and measurement information:
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml
If the --network-name option and argument are omitted, import will use the default “network1”
name. If there is evidence in the current directory that “network1” has already been created, then
“network2” will be used. The integer appended to “network” increases until the ﬁrst available
network name is found.
Whether using a project ﬁle or not, additional options and arguments can be supplied to conﬁgure
the way in which this information is imported. When using a project ﬁle, any additional options and
arguments provided on the command line will overwrite the values contained in the project ﬁle.
3.2.1 Station coordinate information
import accepts station coordinate information in three commonly accepted coordinate systems,
namely, Geographic coordinates, Universal Transverse Mercator (UTM) projection coordinates, and
Earth–centred cartesian coordinates. Geographic coordinates are expressed as latitude,longitude and
height, where height may be ellipsoidal height or orthometric height. UTM projection coordinates are
expressed as Easting,Northing,zone and height. Earth–centred cartesian coordinates are expressed
as X,Yand Z. These coordinate systems and the methods by which DynaNet handles transformations
between them are explained in Chapter 4. With reference to the supported ﬁle formats described in
the introduction, Table 3.1 lists the coordinate types handled by the respective ﬁle formats.
Table 3.1: Station coordinate types handled by the supported ﬁle formats
Format CSV DNA DynaML GeodesyML SINEX
Geographic (d.mmss) • • • • •
Geographic (d.dddd) •
UTM Projection • • • •
Cartesian • • • • •
Appendix B explains the formatting of station coordinate information for each of the supported ﬁle
formats. §3.2.3 explains the concept of station constraints and how they are interpreted by DynaNet.
Conﬁguring the default reference frame for stations is described in §3.3.1.
3.2.2 Supported measurement types
DynaNet supports a wide range of GNSS and terrestrial measurement types. To facilitate the eﬃcient
management of these types, DynaNet uses the concept of a measurement code. The measurement
types and corresponding codes supported by DynaNet are listed in Table 3.2.
Table 3.2: Supported measurement types and measurement codes
Code Measurement type
A Horizontal angles (uncorrelated)
B Geodetic azimuth (or bearing)
C Ellipsoid chord distance
D Direction set
E Ellipsoid arc distance
G Single GNSS baseline (∆x∆y∆z)
H Orthometric height
I Astronomic latitude
J Astronomic longitude
K Astronomic (Laplace) azimuth
L Orthometric height diﬀerence
M Mean sea level (MSL) arc distance
P Geodetic latitude
Q Geodetic longitude
R Ellipsoid height
S Slope (direct) distance
V Zenith distance
X GNSS baseline cluster (full correlations)
Y GNSS point cluster (full correlations)
Z Vertical angle
A brief description of these measurement types, including the observation equations implemented
within DynaNet for relating them to the unknown parameters are described in §7.2. Appendix B
explains the formatting of measurement information for each of the supported ﬁle formats.
3.2.3 Network constraints
DynaNet permits networks to be constrained using two diﬀerent forms — via station constraints and
position measurement constraints. Multiple constraints of both forms may be applied to a network.
Station constraints can be imposed on a network as either free (‘F’) or constrained (‘C’), and either
constraint may be applied to one, two or three station cardinals (hereafter referred to as parameters).
Station constraints may be provided in CSV, DNA, DynaML and GeodesyML formats (see Appendix
B for help on formatting for the respective ﬁle formats).
Station parameters which the user considers ﬁxed can be constrained, so that they will not be
subject to variation by least squares adjustment. Station parameters held free are those in which
the user expects variation according to network geometry, measurements and their uncertainties, and
other station parameter constraints. Stations held constrained in three dimensions deﬁne the datum
(position, rotation and scale) for other stations held free in the network. Care should be exercised
when applying multiple station constraints, as constraining multiple stations with poor coordinate
estimates can lead to network distortions and/or cause several measurements to fail (c.f. §9.3.2).
By default, free stations are assigned an uncertainty of 10.0 m, and constrained an uncertainty of
0.001 mm. To alter these values, refer to the paragraph on default constraint values in § 8.3.3 on
When all unknown parameters in a network are held free, the solution of the parameters is undertaken
as a free network adjustment. Accordingly, the estimation of parameters derives solely from the
measurements. When the minimum number of parameters required to estimate all dimensions of
the network are constrained, the solution is undertaken as a minimally constrained adjustment. In
this case, poor coordinate estimates for the ﬁxed station will not distort the network nor cause
measurement failures. The exception to this of course is if position measurements are supplied
for the constrained station and there is a signiﬁcant diﬀerence between the constrained station
coordinates and the position measurements. In the absence of these inconsistencies, both free
network adjustments and minimally constrained adjustments may be used to test the least squares
adjustment and the reliability of the measurements and their uncertainties (see §9.3).
DynaNet supports the application of any combination of free and constrained parameter constraints
to any number of stations in a network. The advantage of combining Free and Constrained parameter
constraints is illustrated as follows. At times, there may be a single parameter (e.g. a station height)
which cannot be estimated from the available measurements. At other times, a particular plane or
axis may contain no measurements and as such, a one–dimensional or two–dimensional adjustment
is necessary. In either case, station constraints may be applied to ﬁx parameters for which estimation
is not required without compromising the least squares adjustment.
Position measurement constraints
Like constrained stations, position measurement constraints provide a means for deﬁning the geodetic
datum for all stations in a network. However, position measurement constraints are somewhat
diﬀerent in that they permit the least squares adjustment to vary the parameter estimates in
accordance with network geometry, measurements and their uncertainties, and any other station
parameters held constrained. Providing a position measurement with an extremely small value of
uncertainty is identical to holding a station constrained (or ﬁxed), whereas providing a position
measurement with an extremely large value of uncertainty is identical holding a station free.
The measurement types which act as positional constraints include GNSS point cluster (Y), geodetic
latitude (P), geodetic longitude (Q), astronomic latitude (I) astronomic longitude (J), orthometric
height (H) and ellipsoid height (R). Hence, to constrain a network horizontally, provide P and Q
measurements for the station to be constrained together with appropriate standard deviations to
reﬂect the amount by which the station should be constrained. Similarly, H or R measurements with
appropriate standard deviations may be supplied to constrain a network in the vertical direction.
A GNSS point cluster with full variance matrix (e.g. obtained from a GNSS Continuously Operating
Reference Station (CORS) network, made available via a SINEX ﬁle) is the most rigorous approach
for constraining a network in three dimensions, and for deﬁning a datum for the stations of a network.
As with station constraints, care should be exercised when supplying position measurements as poor
measurement estimates or over–optimistic values of uncertainty can lead to network distortions
and/or cause several measurements to fail.
3.2.4 Geoid information
In order to rigorously combine measurements subject to the inﬂuence of the anomalous gravity ﬁeld
with GNSS measurements within a single adjustment, geoid–ellipsoid separations and deﬂections of
the vertical are required. For this purpose, geoid facilitates the interpolation of the required geoid
information from a structured geoid grid ﬁle (see Chapter 5).
import also provides a capability for importing geoid information into DynaNet for two primary
purposes. Firstly, there may be instances where more accurate and higher resolution geoid information
has been observed over an area but is not yet available within a geoid grid ﬁle. In this case, all
information about a geodetic network can be imported in a single step. Secondly, import oﬀers
an option to simulate measurements observed in the local reference frame which contain realistic
measures of geoid–ellipsoid separations and deﬂections of the vertical (see §3.4).
To introduce geoid information into DynaNet, add --geo-file to the list of options for import,
followed by the geoid ﬁle name:
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --geo-file uni_sqr.geo
See §B.1.5 for help on formatting geoid information using the DNA geoid ﬁle format.
3.2.5 File name argument conventions
When supplying import with options and arguments relating to input station and measurement ﬁles,
DynaNet oﬀers a few conventions to simplify the process of entering ﬁle names. Firstly, supplying
a ﬁle name does not require the --stn-msr-input-file option (or its shortcut -f). Secondly, any
number of station and measurement ﬁles may be supplied, whether of the same or diﬀerent ﬁle
formats. Thirdly, input ﬁles can be supplied in any order. The following hypothetical example shows
how a number of ﬁles and ﬁle formats may be used:
import -n my_net constraints.snx gps_bsl.xml level.msr level.stn
This example creates a new network called “my_net”, which is comprised of station constraints
in constraints.snx, GNSS baselines and associated stations in gps_bsl.xml, and spirit levelling
measurements in level.msr and stations in level.stn.
3.2.6 Progress reporting and import log
Once import has been executed with the relevant options and arguments, import will report to
the screen a number of items relevant to the project (e.g. name, location of input and output
ﬁles); the progress of ﬁle reading; summary of loaded station and measurement information; progress
of various processing tasks; and ﬁnal exit status (i.e. success or failure). Figure 3.1 shows the
information reported to the screen upon program execution.
Network name: uni_sqr
Input folder: .
Output folder: .
Associated station file: ./uni_sqr.asl
Associated measurement file: ./uni_sqr.aml
Binary station output file: ./uni_sqr.bst
Binary measurement output file: ./uni_sqr.bms
Default reference frame GDA94
uni_sqrstn.xml... Done. Loaded 149 stations in 0.035s
uni_sqrmsr.xml... Done. Loaded 1199 measurements in 0.04s
+ Reducing stations... Done.
+ File parsing summary:
Read 149 stations:
(CCC) 3D constrained: 1
(FFF) 3D free: 145
(CCF) 2D constrained, 1D free: 1
(FFC) 2D free, 1D constrained: 1
(CFF) custom 2D constraints: 1
Read 1199 measurements:
(A) Horizontal angle: 251
(B) Geodetic azimuth: 1
(C) Chord dist: 0
(D) Directions: 0
(E) Ellipsoid arc: 0
(G) GPS baseline: 114
(H) Orthometric height: 1
(I) Astronomic latitude: 0
(J) Astronomic longitude: 0
(K) Astronomic azimuth: 1
(L) Level difference: 89
(M) Mean sea level arc: 1
(P) Geodetic latitude: 0
(Q) Geodetic longitude: 0
(R) Ellipsoidal height: 0
(S) Slope distance: 428
(V) Zenith angle: 300
(X) GPS baseline cluster: 0
(Y) GPS point cluster: 12
(Z) Vertical angle: 1
* Includes 17 ignored measurements
+ Testing for duplicate stations... Done.
+ Sorting stations... Done.
+ Serialising station map... Done.
+ Mapping measurements to stations... Done.
+ Creating association lists... Done.
+ Serialising association lists... Done.
+ Serialising binary station file uni_sqr.bst... Done.
+ Serialising binary measurement file uni_sqr.bms... Done.
+ Total file handling process took 0.697s.
+ Binary station and measurement files are now ready for processing.
Figure 3.1: import progress reporting of data import, conversion and processing
The amount of information will vary depending on the options and arguments supplied to import,
such as folder locations, input ﬁles, ﬁle contents, reference frame, data screening, GNSS measurement
scaling and export. This information is also logged to a ﬁle named uni_sqr.imp. Any errors
encountered during the various tasks will result in premature program termination and a description
of the error.
3.2.7 Veriﬁcation and error checking
When import is executed, a number of veriﬁcation and error checking tasks are undertaken upon
loading the information into DynaNet. These tasks are brieﬂy summarised below.
As data is loaded from the input ﬁles, import will verify that non–empty strings exist for mandatory
ﬁelds and elements. The ﬁelds and elements which are mandatory will depend upon which station
coordinate type and measurement is being supplied. For instance, zone is not required when supplying
station coordinates in geographic format. Instrument and target heights are only required for slope
distances, vertical angles and zenith angles. Refer to the ﬁle format speciﬁcation in Appendix B for
a list of mandatory ﬁelds and elements for the respective station coordinate types and measurement
Testing for duplicate stations and measurements
When supplying import with station and measurement information either in one ﬁle or in a number
of ﬁles, import will identify and remove duplicate station information. Although input ﬁle arguments
may be supplied in any order, import processes input ﬁles sequentially in the order they have been
entered on the command line. If a station contained in an earlier input ﬁle is found in a subsequent
ﬁle, the latter station will be regarded as a duplicate station and thereby ignored. All duplicate
stations are printed to a ﬁle with a .dst extension. If it is essential that duplicate station information
be maintained across multiple ﬁles, then the user must ensure that the ﬁle which contains the desired
station information (e.g. station name, coordinates and constraints) is loaded ﬁrst.
When concatenating networks contained in diﬀerent ﬁles, the same station can sometimes appear
in the station and measurement ﬁles twice with diﬀerent station names. To assist users with the
detection of two diﬀerently named stations which are intended to represent the same station, import
provides the --search-nearby-stn option. See §3.3.2 for more information on using this option.
As for measurements, it is quite normal for several repeated measurements to be observed over the
same set of stations. Sometimes, measurement ﬁles can contain two independent measurements
with equal values. For this reason, import does not attempt to remove measurements which appear
to be identical and so the responsibility for checking for duplicate measurements falls to the user.
import aﬀords the ability to test for duplicates via the --search-similar-msr option. See §3.3.2
for more information on using this option to search for duplicate measurements.
Station and measurement connectivity
Two tests are performed to ensure that the supplied station and measurement information is valid
in the context of network connectivity. Firstly, a test is performed to verify that the station ﬁle(s)
contain information about all stations connected to the measurements. For this test to pass, the
station names referenced in each measurement must exist in the station ﬁle exactly as they appear
in the measurements. This test is case sensitive and includes whitespace. Any stations which are not
found in the station ﬁle will cause import to terminate prematurely with an error message. Secondly,
any stations which are not connected to any measurements will be noted as unused and marked for
exclusion from segmentation and adjustment processes. See the section on Flagging unused stations
on page 31 for conﬁguring the way in which unused stations are handled.
3.3 Conﬁguring import options
3.3.1 Reference frame
DynaNet provides a capability to transform station coordinates and GNSS measurements between
several static and dynamic reference frames via reftran (see Chapter 4). The purpose of this
functionality is to align stations and GNSS measurements on multiple reference frames to a common
reference frame prior to least squares adjustment. To this end, reftran expects all stations and
measurements to be tagged with a recognised reference frame abbreviation. The reference frames
and abbreviations supported by DynaNet are listed in Table 4.1 of Chapter 4. If the reference frame
is dynamic, reftran will also require an epoch.
Since reference frame information is not always present in CSV, DNA, DynaML, GeodesyML and
SINEX input ﬁles1,import provides two options to eﬃciently associate a reference frame to stations
and measurements upon loading the input ﬁles.
Default Reference frame
Before any input ﬁles are loaded, import by default assumes that the reference frame for all incoming
stations and measurements is GDA94. If an input ﬁle does not contain reference frame information,
this default reference frame option will be adopted. However, if an input ﬁle contains reference
frame information, this information will be retained. To specify a diﬀerent default reference frame
to be used for all stations and GNSS measurements contained in the input ﬁles, add the option
--reference-frame (or its shortcut -r) followed by the reference frame abbreviation to the list of
import options. For example, to assign the International Terrestrial Reference Frame 2008, run the
import -n igs_net constraints.snx gps_bsl.xml level.stn level.msr -r ITRF2008
In this example, import will set ITRF2008 as the default reference frame for the GNSS Point
cluster measurement loaded from constraints.snx, all GNSS baseline measurements loaded from
gps_bsl.xml, and for all stations from gps_bsl.xml and level.stn. This is eﬀected by setting the
default reference frame abbreviation in the binary station (.bst) and binary measurement (.bms)
ﬁles. Any GNSS measurement which does not have a reference frame abbreviation assigned to it will
adopt this default abbreviation. The default epoch assigned to the GNSS baselines in gps_bsl.xml
will be the reference epoch of the user–supplied frame. The reference epoch contained in the SINEX
ﬁle constraints.snx is not altered by this option. Similarly, any GNSS measurements loaded from
a measurement ﬁle that have already been assigned a reference frame will not be altered.
1. According to the SINEX 2.02 speciﬁcation, a SINEX ﬁle must contain a reference epoch for the solution, however
there is no provision for storing the reference frame. Both DynaML and GeodesyML contain elements for managing
reference frame and epoch, although this information is not mandatory. CSV and DNA Version 3 provides the
ability for reference frame and epoch to be stored, but again this information is optional. See Appendix B for more
Override input reference frame name
The option --reference-frame sets the default reference frame and thereby only comes into eﬀect if
a GNSS measurement has not already been assigned a reference frame (see, for example, Table B.8
in Appendix B). To override the assigned measurement reference frame with the default reference
frame, provide the option --override-input-ref-frame.
Handling multiple diﬀerent reference frames
Note that option --reference-frame will set the default reference frame for all input ﬁles in a
single step. If a project is based upon multiple input ﬁles aligned to diﬀerent reference frames,
a blanket application of a single reference frame to all stations and measurements may lead to
non–rigorous results. To ensure the correct reference frame is associated with the imported stations
and measurements, a number of processing steps may be required. For instance, some or all of the
following may be required:
•Where ﬁle format speciﬁcation allows (e.g. CSV, DNA and DynaML formats. See B.1), set the
default and measurement–speciﬁc reference frame of the stations and measurements within in
the input ﬁle;
•Where ﬁle formats do not make provision for setting the default reference frame, use a two–step
1. Group ﬁles together which are aligned to a common reference frame. Set the default
reference frame upon loading the input ﬁles with import.
2. Execute reftran with the desired reference frame and export to the desired ﬁle format
(see Chapter 4).
3. Repeat steps 1. and 2. until the appropriate reference frame and epoch have been assigned
to all stations and measurements.
Further details on performing reference frame transformations will be provided in Chapter 4.
3.3.2 Data screening
When undertaking network maintenance tasks, it is often necessary to screen or ﬁlter input data
using some specialised criteria to produce a thinned or optimal subset of the network. At other
times, it may be necessary to search input data for inconsistent, incorrect or duplicate information.
The data screening helps provided by import include extracting stations and measurements based on
geographical region, network connectivity, network segmentation, and measurement type. Helps for
searching for inconsistent, incorrect or duplicate information include station nearness, measurement
similarity and ﬂagging and ignoring station and measurement information.
To import stations and measurements within a rectangular geographical region, pass the option
--bounding-box to import followed by a comma delimited string in the form of latitude and longitude
pairs deﬁning the upper left and lower right corners of the bounding box. For example, considering
the skye network shown in Figure 1.4 on page 9, the command:
import -n skye skye.stn skye.msr --bounding-box -38.0630,145.1130,-38.07,145.12
will import stations 302513640,302513650,302509800 and 302502400, and all connected GNSS
baselines wholly within the bounding box. The stations and measurements that are imported using
this command are shown in Figure 3.2.
Figure 3.2: Stations and measurements in the skye network ﬁltered by the --bounding-box option.
Note that only the stations and measurements which lie wholly within the limits of the bounding
box will be imported. To include measurements which transcend the bounding box, add the option
--get-msrs-transcending-box. By default, GNSS baseline clusters and GNSS point clusters which
transcend a bounding box will not be split and as a consequence, will be ignored from the import
process. If option --bounding-box is intended to be used to obtain a subset of a GNSS baseline or
point cluster, add the option --split-gnss-cluster-msrs.
Including or excluding stations and measurements
To import only a set of speciﬁc stations and associated measurements, pass to import the option
--include-stns-assoc-msrs followed by a comma delimited string deﬁning the stations to be
imported. This option will also import any stations connected to the associated measurements.
For example, the command:
import -n skye skye.stn skye.msr --include-stns-assoc-msrs 302502400
will import station 302502400, all measurements associated with 302502400, and stations 302513650
and 302509800 which happen to be connected to the associated measurements. Any measurements
between stations 302513650 and 302509800 will not be imported. For these measurements to be
included, add 302513650 or 302509800 to the argument string. As with the bounding box function,
if --include-stns-assoc-msrs is intended to be used to obtain a subset of a GNSS point or baseline
cluster, add the option --split-gnss-cluster-msrs.
Conversely, to import all stations except a set of speciﬁc stations, pass to import the option
--exclude-stns-assoc-msrs followed by a comma delimited string deﬁning the stations to be
excluded from the import process. This option will also exclude all measurements associated with
that station, but not other stations. For example, the command:
import -n skye skye.stn skye.msr --exclude-stns-assoc-msrs 302513650
will import all stations except station 302513650 and all measurements associated with it. If the
intention is to exclude one or more stations from a GNSS point or baseline cluster, add the option
Segmented network block
DynaNet provides a capability to segment a network into a series of connected blocks via segment
(see Chapter 6). The purpose of this functionality is support phased adjustment. Once a network
has been segmented, stations and measurements within a segmented block can be imported using
the option --import-block-stn-msr and the desired block number as an argument:
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --import-block-stn-msr 3
Using this command sequence, only the stations and measurements in block 3 will be imported. For
this command sequence to work as intended, a segmentation ﬁle named uni_sqr.seg must exist
in the folder from which import was executed, and this ﬁle must contain at least three blocks
(see Chapter 6 for more information on the creation of segmentation ﬁles). To use an alternative
segmentation ﬁle, pass to import the option --seg-file followed by the name of the segmentation
ﬁle. If the segmentation ﬁle is located in another directory, the ﬁle name must include the full folder
For networks of mixed measurement types, options --import-msr-types and --exclude-msr-types
can be used to include or exclude certain measurements from the import process. Both options take
for their argument a non–delimited string deﬁning the measurement types to be included or excluded.
For example, the following command will only import GNSS measurements:
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --import-msr GXY
Conversely, the following command will import all measurements except astronomic latitude and
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --exclude-msr IJ
An additional option under the category of measurement type is --prefer-single-x-as-g. This
option will convert all GNSS baseline cluster (X) measurements containing a single baseline into
GNSS baseline (G) measurements.
At times it will be necessary to rename multiple stations throughout a network, such as to correct
stations which have been wrongly named in the ﬁeld or during data processing, or to change from
a well-known alias to another preferred name (or alias). To rename one or more stations upon
importing stations and measurements, pass the option --stn-renaming-file to import followed by
the name of the station renaming ﬁle:
import -n skye skye.stn skye.msr --stn-renaming-file skye.renaming
The structure and format of the station renaming ﬁle is shown in Figure 3.3. The ﬁrst column is the
preferred name to which all occurrences of the names listed in columns 1, 2, . . . , n will be changed.
The number of characters reserved for each station name ﬁeld will be deﬁned according to the DNA
STN ﬁle format version. For DNA version 3.0 onward, this width is 20. Rows beginning with an
asterisk are treated as comments and are ignored.
!#=DNA 3.01 REN
* Station renaming file
* List the preferred name first, and then all other aliases a mark may have
* NEWNAME (20 chrs) ALIAS (20 chars) ALIAS (20 chars) ALIAS (20 chars) ALIAS (20 chars)
Figure 3.3: Station renaming ﬁle
When concatenating networks contained in diﬀerent ﬁles, the same physical station can sometimes
appear in the station and measurement ﬁles with diﬀerent station names. To assist with identifying
stations with diﬀerent names, pass the option --search-nearby-stn to import and, if required, pass
the option --nearby-stn-buffer followed by a distance in metres by which to search for nearby
stations. For example, to search for stations in uni_sqrstn.xml within 1.5 metres of each other, run
the following command:
import -n uni_sqr uni_sqrstn.xml --search-nearby-stn --nearby-stn-buffer 1.5
This command will produce the following output:
+ Testing for duplicate and nearby stations... Done.
- Error: 1 station was found to be separated by less than 1.5m.
See ./unisqr.dst for details.
If the names in each pair refer to the same station, then update the
station and measurement files with the correct station name and re-run import.
Alternatively, if the names in each pair are unique, either call import
without the --search-nearby-stn option, or decrease the radial search
distance using --nearby-stn-buffer.
Having identiﬁed one or more nearby stations, import will create a ﬁle called uni_sqr.dst in which
will be printed a list of stations that are separated by less than 1.5 metres. The contents of this ﬁle
are as follows:
DUPLICATE STATION FILE
Build May 26 2014, 22:27:14 (MSVC++ 10.0)
File created Monday, 26 May 2014, 10:30:35 PM
File name C:\Data\unisqr.dst
Command line arguments import -n unisqr uni_sqrstn.xml --search-nearby-stn --nearby-stn-buf 1.5
Network name unisqr
Stations file C:\Data\unisqr.bst
Measurements file C:\Data\unisqr.bms
Associated station file C:\Data\unisqr.asl
Associated measurement file C:\Data\unisqr.aml
Duplicate stations output file C:\Data\unisqr.dst
Similar measurement output file C:\Data\unisqr.dms
Input files uni_sqrstn.xml
Default reference frame GDA94
Search for nearby stations tolerance = 1.5m
Nearby station search results:
1 station was found to be separated by less than 1.5m:
First station Nearby station Separation (m)
2120 NEWP 0.531
Once import has identiﬁed the stations that satisfy the search criteria, it is up to the user to verify
if the stations listed in the .dst ﬁle are the same physical station or not. If a single station has
been inadvertently given diﬀerent names in the station and measurement ﬁles, redundant station
information can be harmonised by:
1. Amalgamate the station information record(s) to form a single station with the preferred station
name, coordinates and constraints.
2. Search and replace in the measurement ﬁle all instances of the redundant station name with
the preferred station name
It is anticipated that a future version of DynaNet will provide an automated approach for harmonising
redundant station information.
As in the case for stations, concatenating networks contained in diﬀerent ﬁles can easily result
in duplicate measurements in the measurement ﬁles. Duplicate measurements can be diﬃcult to
detect as it is normal and legitimate for redundant measurements to exist. To assist with identifying
duplicate measurements, pass the option --search-similar-msr to import:
import -n uni_sqr uni_sqrmsr.xml --search-similar-msr
This sequence of commands will produce the following output:
+ Searching for similar measurements...
- Error: 3 measurements were found to be very similar (if not identical)
to other measurements. See ./uni_sqr.dms for details.
If the listed measurements are true duplicates, either remove each duplicate
from the measurement file and re-run import, or re-run import with the
--ignore-similar-msr option. Alternatively, if each measurement
is unique, then call import without the --search-similar-msr option.
As shown in the above output, import will create a ﬁle called unisqr.dms in which will be printed
a list of measurements that appear to be similar or identical to other measurements. The format of
the similar measurements is DynaML as follows:
- 3 measurements were found to be very similar (if not identical)
to other measurements.
<!--Type L Level difference-->
<!--Type S Slope distance-->
<!--Type S Slope distance-->
As with stations, the second and subsequent appearances of a measurement with similar attributes
will be regarded as a duplicate. Once import has identiﬁed the measurements that satisfy the test
for similarity, it is up to the user to verify if the measurements listed in the .dms ﬁle are the same
measurement or diﬀerent measurements. Measurements which are duplicates can either be removed
from the measurement ﬁle, or set as an ignored measurement. For example, measurements can be
ignored in DNA ﬁles by providing an asterisk (*) for the ignore ﬂag (see Table B.3, §B.1.4).
For very large networks which have been derived from hundreds of GNSS survey projects, it is possible
for a single GNSS data set to be inadvertently processed twice, resulting in unique but similar GNSS
baselines and GNSS baseline clusters. At times, these similar measurements can be diﬃcult to
detect due to slight variations in the generated GNSS vector and variance matrix components. To
search for single GNSS baselines which may be similar to a GNSS baseline cluster, pass the option
--search-similar-gnss-msr to import. This option will cause import to identify every single GNSS
baseline where both terminal stations are contained within a GNSS baseline cluster and where both
measurements the same reference frame and epoch.
Ignoring similar measurements
Upon verifying whether the measurements listed in the .dms ﬁle are duplicate measurements, the
user may opt to remove the duplicate measurements or ﬂag them as ignored for further veriﬁcation.
To automatically ignore all measurements identiﬁed as similar. add --ignore-similar-msr to the
list of options for import:
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --ignore-similar-msr
Executing this command will automatically ﬂag any measurements deemed to be similar as other
measurements in the network as ignored and thereby exclude them from all subsequent processing.
Removing ignored measurements
Measurements which are ﬂagged as ignored, whether in the measurement ﬁle or by supplying the
--ignore-similar-msr option, can be automatically removed from all subsequent processing as
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --remove-ignored-msr
This option can be combined with option --ignore-similar-msr in a single command:
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --ignore-similst-msr --remove-ignored-msr
Executing this command will automatically ﬂag similar measurements and, together with any other
measurements already marked as ignored, will not be written to the binary measurement ﬁle.
Flagging unused stations
Upon loading the station and measurement information from the input ﬁles, any stations not
connected to any measurements will be noted as unused and thereby marked for exclusion from
segmentation and adjustment processes. However, import will retain these stations within the
binary station ﬁle. Accordingly, functions such as data export (see §3.5) will include these stations.
To prevent unused stations from being used in any further processing, pass to import the option
import -n uni_sqr uni_sqrstn.xml uni_sqrmsr.xml --flag-unused-stations
3.3.3 GNSS variance matrix scaling
For the most part, GNSS measurement and variance matrix information will be sourced from ﬁles
generated by a GNSS processing package. Depending on the processing strategy, it is possible
that the variance matrices accompanying the GNSS measurements will need some form of scaling
such that a more realistic estimate of the GNSS measurement precision is incorporated within an
adjustment. GNSS measurement variance matrices may be scaled using the appropriate scalar ﬁelds
within the input ﬁles (e.g. Table B.8 on page 177 for DNA ﬁle format, or Figure B.23 on page 190
for DynaML ﬁle format). In addition, import provides a capacity to scale GNSS variance matrices
via ﬁve diﬀerent scaling options. Table 3.3 lists the lists the various GNSS variance matrix scaling
options (c.f. Table A.6 on page 155 in the Command line reference).
Table 3.3: GNSS variance matrix scaling options
Option All msrs Clusters Matrix North–south East–west Up
--v-scale • • •
--p-scale • • •
--l-scale • • •
--h-scale • • •
--baseline-scalar-file • • • •
As shown in Table 3.3, GNSS variance matrix scaling can be applied to all GNSS measurements
contained in all measurement ﬁles passed to import, or to individual GNSS baselines. Individual
baseline scaling is based upon the contents of a baseline scalar ﬁle and does not apply to GNSS point
or baseline clusters. Whether scaling all or individual GNSS variance matrices, scaling can be applied
in two diﬀerent ways — via a single matrix multiplier (or variance factor) or via individual scalars
corresponding to the three dimensions of the local reference frame. One or more scaling options in
any combination can be passed to import.
To scale all GNSS variance matrices by a single multiplier, pass to import the option --v-scale
followed by a scalar value. For example, to scale all variance matrices in the skye project by a factor
of 10.0, run the following command:
import -n skye skye.stn skye.msr --v-scale 10
To scale all GNSS variance matrices by partial scalars in the north–south, east–west or vertical
directions, pass to import the options --p-scale,--l-scale or --h-scale respectively, followed by
the relevant scalar value. For example, to scale all variance matrices in the skye project by a factor
of 2.0 in the horizontal direction and 5.0 in the vertical direction, run the following command:
import -n skye skye.stn skye.msr --p-scale 2 --l-scale 2 --h-scale 5
To scale speciﬁc GNSS baseline variance matrices, pass to import the option --v-scale followed by
the name of the baseline scalar ﬁle:
import -n skye skye.stn skye.msr --baseline-scalar-file skye.scalars
The structure and format of the baseline scalar ﬁle is shown in Figure 3.4. 20 characters are reserved
for the two station names, and 10 characters are reserved for v-scale,p-scale,l-scale and h-scale.
GNSS BASELINE VARIANCE MATRIX SCALAR FILE
Station 1 Station 2 v-scale p-scale l-scale h-scale
409601230 409601240 100.0 1 1 1
409601230 409601250 10 2 2 5
409601230 409601260 1 3 3 10
Figure 3.4: Baseline scalar ﬁle
For all scaling options, §220.127.116.11 describes the procedure implemented by DynaNet for scaling GNSS
3.4 Network measurement simulation
import provides a capability to simulate a network of GNSS and terrestrial measurements through
the --simulate-msr-file option. In order to simulate measurements, two ﬁles are required — a
station ﬁle and a measurement simulation control ﬁle. Upon execution, measurements are simulated
for all measurement types and station names listed in the measurement simulation control ﬁle.
Measurement values are calculated using the coordinates provided in the station ﬁle. The following
command demonstrates the use of import to simulate measurements:
import -n simnet simnet.stn simnet-list.msr --simulate
Running this command will create a DNA measurements ﬁle named simnet.simulated.msr which
will contain measurements generated from the station coordinates in simnet.stn and the types and
station names in simnet-list.msr. The input station ﬁle simnet.stn must conform to the DNA
station ﬁle format (c.f. §B.1.3). The input measurement simulation control ﬁle simnet-list.msr
must conform to the DNA measurement ﬁle format (c.f. §B.1.4) in principle, the exceptions being
that only measurement types, station names and cluster counts need to be present. Figure 3.5 shows
a sample simulation control ﬁle.
The measurement values in the simulated measurements ﬁle are calculated exactly from the station
coordinates. All other information is generated as follows:
•Standard deviations for measurement types C, E, L, M and S will be calculated from
where Lis the calculated distance in metres;
•Standard deviations for measurement types H and R will be set to 0.024 metres.
•Variance matrices for G, X and Y measurement types will be set to:
4.022000e-05 −1.369000e-05 3.975000e-05
−1.369000e-05 1.487000e-05 −2.035000e-05
3.975000e-05 −2.035000e-05 6.803000e-05
•Station and target heights for measurements which require these heights (e.g. S, V, Z) will be
set to 1.650 and 1.651 metres respectively.
•Standard deviations for measurement types A, B, D, K, V and Z will be set to 0.01 seconds.
•Standard deviations for measurement types I, J, P and Q will be set to 0.021 seconds.
!#=DNA 3.00 MSR 16.06.2014 GDA94 01.01.1994 20
* Measurement simulation control file
A 503 304 307
B 909 1010
C 501 309
D 602 302 2
E 503 307
G 604 606
K 101 202
L 910 1010
M 604 706
S 602 302
V 109 207
X 406 501 2
Y 406 XYZ 3
Z 503 307
Figure 3.5: Example simulation measurements list
If orthometric heights are supplied in the station ﬁle, or if simulated terrestrial measurements are
intended to contain a realistic measure of the inﬂuence of the gravity ﬁeld, geoid–ellipsoid separations
and deﬂections of the vertical can be added to the measurements through the use of a DNA geoid
ﬁle. To this end, add the --geo-file option (c.f. §3.2.4), followed by the geoid ﬁle name:
import -n simnet simnet.stn simnet-list.msr --simulate --geo-file simnet.geo
If a DNA geoid ﬁle has not been created, geoid may be called to interpolate and export the
geoid–ellipsoid separations and deﬂections of the vertical to a DNA geoid ﬁle. For this purpose,
a binary station ﬁle for simnet is required. The steps are as follows:
1. Import the simulation station ﬁle to create the binary station ﬁle simnet.bst.
2. Interpolate the geoid information (from simnet.bst) and export to a DNA geoid ﬁle.
3. Simulate using the station ﬁle, simulation control ﬁle and the newly created geoid ﬁle.
The command line sequence for these steps is as follows:
import -n simnet simnet.stn
geoid simnet --ntv2-file ausgeoid09.gsb --export-dna-geo
import -n simnet simnet.stn simnet-list.msr --simulate --geo-file simnet.geo
See Chapter 5 for more help on interpolating geoid information from a geoid grid ﬁle.
3.5 Data export
In addition to translating the external ﬁle formats into the binary formats required by DynaNet,
import provides a capacity to export geodetic network information into a number of diﬀerent ﬁle
formats. The options for exporting information include:
•Export of station and measurement information to CSV, DNA, DynaML, GeodesyML and
SINEX ﬁle formats
•Export of geodetic network binary ﬁles (MAP, AML, ASL) to equivalent plain text variants
Export options can be passed to import together with any other option. Hence, the residual station
and measurement information generated through the various conﬁguration options can be stored for
subsequent import, ﬁltering and processing.
3.5.1 Station and measurement ﬁles
To export station and measurement information into CSV or DNA format, pass to import the
option --export-dna-files or --export-csv-files respectively. Similarly, to export station and
measurement information into DynaML format, pass the option --export-xml-files. For example,
the following command will export DNA station and measurement ﬁles comprised of only GNSS
measurements found within the uni_sqr project, with the default reference frame set to ITRF2005
and all GNSS variance matrices scaled by 100.0:
import -n us_bsl uni_sqrstn.xml uni_sqrmsr.xml --v-sc 100 --ref itrf2005 --import-m GXY --export-dna --flag
Running this command will produce two ﬁles named us_bsl.stn and us_bsl.msr corresponding
to the station and measurement ﬁles respectively. Since --flag-unused-stations was passed to
import, stations which become disconnected from removed measurements (as a result of importing
only GNSS measurements) will not be written to the station ﬁle.
The option --export-xml-files will produce two XML ﬁles named <network_name>stn.xml and
<network_name>msr.xml corresponding to the station and measurement ﬁles respectively. To produce
a single DynaML ﬁle, pass to import the option --single-xml-file with --export-xml-files.
Note that if the network name supplied in the above command matched the name of the input ﬁles
according to the ﬁle naming convention described in §2.2.1 (i.e. uni_sqr), and data is exported to
the same ﬁle format as the input ﬁles, then the original input ﬁles will be overwritten.
3.5.2 Association lists and station map
As discussed in §2.2.2, DynaNet reads and writes a number of binary ﬁles. The Station Map
(MAP), Associated Stations List (ASL) and Associated Measurements List (AML) may be exported
to plain text to assist with detailed analysis of the network’s geometry, measurement connectivity
and measurement frequency. To export the ASL, AML and MAP to their plain text counterparts,
run the following command:
import -n us_bsl us_bsl.stn us_bsl.msr --export-map --export-asl --export-aml
This command will produce three ﬁles named us_bsl.map.txt,us_bsl.asl.txt and us_bsl.aml.txt.
The ﬁelds contained in the exported ﬁles are described in Tables 3.4, 3.5 and 3.6.
Table 3.4: Station Map ﬁelds
Station name The station name as given in the input station and measurement ﬁles. The column
header contains the number of stations detected in the input ﬁles.
Station index The (zero–based) index of the station name in an alpha–numeric sorted list of all station
names. DynaNet uses this index when referring to stations during all internal processing.
Table 3.5: Associated Stations List ﬁelds
Station name The station name as given in the input station and measurement ﬁles. The
column header contains the number of stations detected in the input ﬁles.
No. connected msrs The number of measurements connected to this station.
AML index The (zero–based) index of the ﬁrst record of this station’s appearance in the
Associated Measurements List.
Unused? If an asterisk is present, this station is not connected to any measurements.
Table 3.6: Associated Measurements List ﬁelds
Station name The station name as given in the input station and measurement ﬁles. The column
header contains the number of records in the ﬁle.
Msr index The (zero–based) index of this measurement in the binary measurements ﬁle.
Msr type The type of measurement (c.f. Table 3.2) and which measurement station this station
refers to (ﬁrst, second or third)
Cluster If this measurement is part of a cluster, this number represents the index of the cluster
in a list of all detected clusters.
Ignored msr? If an asterisk is present, this measurement has been marked as ignored.
Transformation of coordinates and
Recognising that GNSS surveying is the most highly utilised measurement technique for geodetic
network establishment and maintenance, DynaNet has been designed around the use of pre–processed
GNSS measurements for the estimation of network station parameters. DynaNet has also been
designed to integrate measurements taken in the local reference frame with GNSS measurements in
an earth–centred, cartesian reference frame.
But since the reference frame of GNSS measurements is directly related to the reference frame of the
satellite orbit information used during GNSS processing, it is inevitable that GNSS measurements
taken over several successive years will be based upon diﬀerent reference frames and epochs. This is
primarily due to the fact that since the launch of the ﬁrst GNSS satellites, several reference frames
(and versions) have been adopted for broadcast and precise ephemeris. The reference frames that
may be relevant in this context can include:
•The PZ-90 coordinate system. Used for the Russian GLObal NAvigation Satellite System
•The International Terrestrial Reference Frame (ITRF). Adopted by the International GNSS
Service (IGS) for their precise orbit products.
•The World Geodetic System of 1994 (WGS84). Used for the Global Positioning System (GPS).
Since its establishment, WGS84 has been aligned (and re–aligned) to several versions of ITRF.
In all cases, these frames can undergo several iterations (or revisions), such as ITRF1988, ITRF1992,
ITRF2008, etc. WGS84 is regularly updated and aligned to ITRF. It follows that each frame
realisation will have a diﬀerent reference epoch. Accordingly, there is a fundamental need to handle
transformations of GNSS measurements between these reference frames if the combination and
adjustment of multiple GNSS measurements in a single solution is to be free from reference frame
bias. To this end, reftran has been developed to transform stations and GNSS measurements between
a selection of commonly used reference frames.
The ﬁrst part of this chapter (§4.2 – §4.5) presents the theory of reference frames and coordinate
systems, conversions between coordinate systems, transformation of coordinates and measurements
between static and dynamic reference frames, and propagation of variances. The remainder of the
chapter describes the use of reftran and its options.
4.2 Reference frame fundamentals
4.2.1 Cartesian reference frame
The cartesian reference frame is a three–dimensional system, the origin oof which is coincident
with the centre of the reference ellipsoid. The referencing of point pis by means of orthogonal
displacements parallel to the x,yand zaxes. Figure 4.1 illustrates point pin relation to the axes
of the cartesian reference frame, and the relationship between cartesian coordinates and geodetic
latitude φ, geodetic longitude λand ellipsoid height h.
Figure 4.1: The ellipsoid–centred cartesian reference frame
A vector xcbetween two points in the cartesian reference frame will have the elements:
As shown by Figure 4.1, geodetic latitude is the angle between the equatorial (x–y) plane and the
normal to the ellipsoid through p, and geodetic longitude is the angle between the zero meridian and
the meridian through p. Ellipsoid height is the distance of pabove p0, which is a point projected onto
the reference ellipsoid along the ellipsoid normal. As Figure 4.1 indicates, the coordinates deﬁning
the location of pare dependent upon the size, shape and location of the reference ellipsoid.
4.2.2 Geographic reference frame
With respect to Figure 4.1, geographic reference frame (or geodetic) coordinates φ,λand hare
related to the corresponding cartesian coordinates by the following expressions:
x= (ν+h) cos φcos λ
y= (ν+h) cos φsin λ(4.2)
z=ν(1 −e2) + hsin φ
where νis the radius of curvature in the prime vertical, given by:
ais the quantity representing the semi–major axis of the reference ellipsoid and e2is the ﬁrst
eccentricity obtained from:
and bis the semi–minor axis of the ellipsoid (coincident with the zaxis).
As will be required for later developments, the radius of curvature in the prime meridian ρat φis
and the distance oq which provides for the zcoordinate of the point q— being at the intersection
of the normal at pwith the polar axis of the ellipsoid — is given by:
oq =e2νsin φ(4.6)
4.2.3 Local reference frame
The local reference frame is a three–dimensional orthogonal system that has its origin on or above
any point on the ellipsoid, and is oriented with respect to the local geodetic meridian. Figure 4.2
illustrates the axes of the local reference frame in relation to the cartesian reference frame. The
vector displacement up is coincident with the ellipsoid normal. The orientation of the local reference
frame varies with respect to latitude φand longitude λ.
Vectors in the cartesian reference frame can be represented in the local reference frame as xl:
A vector xlin the local reference frame is related to the cartesian reference frame by:
where Rlis the rotation matrix with origin at latitude φand longitude λ:
−sin λ−sin φcos λcos φcos λ
cos λ−sin φsin λcos φsin λ
0 cos φsin φ
Figure 4.2: The local reference frame
Equation 4.8 can be written in expanded form as:
−sin λ(∆e)−sin φcos λ(∆n) + cos φcos λ(∆up)
cos λ(∆e)−sin φsin λ(∆n) + cos φsin λ(∆up)
cos φ(∆n) + sin φ(∆up)
Since Rlis orthogonal1, a vector xcin the cartesian reference frame is related to the local reference
which can be written in expanded form as:
−sin λ(∆x) + cos λ(∆y)
−sin φcos λ(∆x)−sin φsin λ(∆y) + cos φ(∆z)
cos φcos λ(∆x) + cos φsin λ(∆y) + sin φ(∆z)
4.2.4 Polar reference frame
At times it is necessary to transform vectors in a local reference frame into a displaced orthogonal
polar reference frame. Figure 4.3 illustrates the displacement of a local reference frame at point
p2in relation to the polar frame at point p1by geodetic azimuth (θ), vertical angle (ϑ) and direct
1. A matrix is orthogonal if the inverse of that matrix is equal to its transpose, i.e. RT=R−1.
Figure 4.3: Orthogonal reference frames displaced by geodetic azimuth, vertical angle and distance
With respect to Figure 4.3, a,vand sare unit vectors deﬁning the displaced polar reference frame.
Vectors vand sare in the vertical plane, whereas ais in the horizontal plane. A vector xpin the
polar reference frame has the elements:
A vector in the local reference frame is transformed to the displaced polar reference frame by:
where Rpis an orthogonal rotation matrix at origin p2:
−cos θ−sin ϑsin θcos ϑsin θ
−sin θ−sin ϑcos θcos ϑcos θ
0 cos ϑsin ϑ
Polar coordinates of θ,ϑand sare related to vectors in the local reference frame by:
θ= arctan ∆e
ϑ= arctan ∆up
s=p∆e2+ ∆n2+ ∆up2
Equation 4.14 can be written in expanded form as:
−cos θ(∆e)−sin ϑsin θ(∆n) + cos ϑsin θ(∆up)
−sin θ(∆e)−sin ϑcos θ(∆n) + cos ϑcos θ(∆up)
cos ϑ(∆n) + sin ϑ(∆up)
Since Rpis orthogonal, a vector xpin the displaced polar reference frame can be rotated into the
local reference frame by:
which can be written in expanded form as:
−cos θ(a)−sin θ(v)
−sin ϑsin θ(a)−sin ϑcos θ(v) + cos ϑ(s)
cos ϑsin θ(a) + cos ϑcos θ(v) + sin ϑ(s)
4.3 Transformation between cartesian reference frames
Several methods are available for transforming coordinates and vectors from one cartesian reference
frame to another. DynaNet supports (conformal 3D) 7–parameter and 14–parameter similarity
transformations using the Bursa–Wolf model.
Conformal transformations between two cartesian reference frames on the same epoch are managed
by a 7–parameter similarity relationship. The relationship involves a three–dimensional shift, rotation
and scale of the cartesian coordinate axes and is given by:
+ (1 + δ)
where ∆x12,∆y12 and ∆z12 are the origin shifts, rx,ryand rzare the coordinate axis rotations (in
radians) and δis the scale factor between the two systems. Where rotation of axes exceeds 10” of
arc, the rotation matrix in equation 4.20 is replaced with the following:
cos rzsin rz0
−sin rzcos rz0
0 0 1
cos ry0−sin ry
0 1 0
sin ry0 cos ry
1 0 0
0 cos rxsin rx
0−sin rxcos rx
Conformal transformations between two cartesian reference frames on diﬀerent epochs are managed
by a 14–parameter similarity relationship. The relationship is identical to that given in equation 4.20,
with the exception of introducing terms for the ﬁrst order derivatives of origin shift, rotation and
scale as follows:
∆x12 + ˙x(t2−t1)
∆y12 + ˙y(t2−t1)
∆z12 + ˙z(t2−t1)
+1 + δ+˙
−rz−˙rz(t2−t1) 1 rx+ ˙rx(t2−t1)
ry+ ˙ry(t2−t1)−rx−˙rx(t2−t1) 1
Here, [˙x˙y˙z],[˙rx˙ry˙rz]and ˙
δare the rates of change in origin shift, axis rotation and
scale respectively, t1is the reference epoch of the reference frame for x1,y1and z1, and t2is the
epoch of the reference frame for x2,y2and z2.
4.4 Propagation of variances between reference frames
4.4.1 Local reference frame
Variances in the local reference frame can be expressed in the cartesian reference frame by the law
of propagation of variances:
where Vxlis a variance matrix in the local reference frame, Vxcis a variance matrix in the cartesian
reference frame, and Rlis the rotation matrix given in equation 4.9. Conversely, propagation of
variances from the cartesian system into the local reference frame is obtained by:
Since Rlis orthogonal, Vxlmay be expressed as:
4.4.2 Polar reference frame
The precision of polar coordinates can be derived from precisions in either cartesian reference frame
or the local reference frame. For precisions in the cartesian system, propagation of variances is
evaluated by a two step process, by (1) propagation into the local system as described above, and
then (2) propagation into the polar form.
To transform a variance matrix Vxlin the local reference frame into the polar form Vxp, propagation
of variances is evaluated as:
where Pis the Jacobian transformation matrix formed by linearising equations 4.16:
To transform a variance matrix directly from the cartesian system to the polar reference frame,
propagation is computed by combining equations 4.24 and 4.25:
4.4.3 Geographic reference frame
To transform a variance matrix Vxgfor geographic coordinates into the cartesian system, propagation
of variances takes the familiar form:
Tis the Jacobian transformation matrix formed by linearising equations 4.2:
For the reverse solution, propagation of variances into the geographic coordinate system is via:
4.5 Conversion of projection coordinates
It is often necessary to work with geographic information deﬁned in terms of projection2coordinates.
DynaNet supports Universal Transverse Mercator (UTM) and Transverse Mercator (TM) projections3.
UTM and TM projection coordinates are expressed in terms of Easting E, Northing Nand Zone
Zo. For UTM projections, the earth is divided into 60 zones. Each zone is 6◦wide in longitude,
extends from −80◦latitude to +80◦latitude, and is numbered consecutively beginning from zone 1
at −180◦to −174◦longitude and extending eastwards to zone 60 (+174◦to +180◦longitude). The
origin of each zone is the point of intersection between the equator and the meridian central to the
zone, and the central scale factor of the projected zones is 0.9996. To alleviate negative coordinate
values in the southern hemisphere, the origin is assigned a false Northing of 10,000,000m and a false
Easting of 500,000m. Since two points located in diﬀerent zones can have equal values for Easting
and Northing, projection coordinates are unique only when accompanied by the zone number.
2. As the reference ellipsoid is by nature a three–dimensional curved surface, projecting ﬁgures on the ellipsoid onto
a ﬂat, two–dimensional surface requires distortion in some form or another. Accordingly, diﬀerent map projections
have been designed to preserve one or more of the following geometric properties: shape (conformal), direction
(azimuthal),distance (gnomic) and area (equal area). To this end, several map projections are available —
Transverse Mercator (conformal), Lambert Conic (conformal), Polar Stereographic (azimuthal, conformal) and
Albers Conic (equal area) [Snyder, 1997].
3. A UTM projection is a TM projection with standardised values for zone width, origin, scale factor and false Easting
The relationship between UTM and TM projection coordinates E,Nand Zo and geographic
coordinates φ,λand his given by [Redfearn, 1948]:
E= 500,000 + k0nνω cos φ+νω3
5040 cos7φ61 −479t2+ 179t4−t6(4.31)
N= 10,000,000 + k0m+νsin φω2
720 cos5φ8ψ411 −24t2+ 28ψ31−6t2
40320 cos7φ1385 −3111t2+ 543t4−t6(4.32)
zw= zone width (in units of λ)(4.35)
t= tan φ(4.37)
m=a(A0φ−A2sin 2φ+A4sin 4φ−A6sin 6φ)(4.38)
A0= 1 −e2
k0is the central scale factor, λ0is the longitude of the central meridian, zwis the projection zone
width, and ρis the radii of curvature in the meridian at φ.
Conversely, the relationship between geographic coordinates and UTM and TM projection coordinates
is given by [Redfearn, 1948]:
24 −4ψ02+ 9ψ01−t02+ 12t02
720 8ψ0411 −24t02−12ψ0321 −71t02
+ 15ψ0215 −98t02+ 15t04+ 180ψ05t02−3t04+ 360t04
403201385 + 3633t02+ 4095t04+ 1575t06(4.43)
λ=λ0+ sec φ0x−x3
6sec φ0ψ0+ 2t02
120sec φ0−4ψ031−6t02+ψ029−68t02+ 72ψ0t02+ 24t04
5040sec φ061 + 662t02+ 1320t04+ 720t06(4.44)
N0=N−Nf(southern hemisphere only) (4.46)
32 sin 2σ+21η2
32 sin 4σ
96 sin 6σ+1097η4
512 sin 8σ(4.50)
G=a(1 −η)1−η21 + 9
Efand Nfare the false Easting and Northing values, λ1is the longitude of the central meridian of
zone 1. ν0and ρ0are the radii of curvature evaluated at the foot–point latitude φ0(via equations
4.3 and 4.5), which is the latitude for which the meridian distance mequals N0/k0.
4.6 Transformation of coordinates and measurements
The least squares adjustment model implemented within DynaNet is based upon the cartesian
reference frame. After loading station information from the input ﬁles, import converts all station
coordinates in geographic and projection systems to their cartesian counterparts. Upon preparing for
least squares adjustment, adjust forms observation equations in terms of the cartesian reference frame
using the principles outlined in §4.2 and if required, performs propagation of variances of a–priori
GNSS measurement variance matrices (c.f. §4.4). When reporting the adjustment results, adjust
converts the estimated station coordinates to the user–speciﬁed coordinate systems (e.g. geographic
and/or projection). If required, adjust undertakes propagation of variances of estimated station and
GNSS measurement variance matrices to the user–speciﬁed system (e.g. cartesian, geographic, local
The primary purpose of reftran is to align all station coordinates and GNSS measurements to
a common reference frame and epoch prior to least squares adjustment. reftran performs this
task using the reference frame information supplied to import (either in the input ﬁles or via the
--reference-frame option. c.f. §3.3.1), and the reference frame passed to reftran.
4.6.1 Supported reference frames and geodetic datums
DynaNet supports several commonly used reference frames. To simplify the process of uniquely
identifying each frame, DynaNet adopts the naming convention, abbreviations and system of codes
deﬁned in the EPSG Geodetic Parameter Dataset4(version 7.9.0). Table 4.1 lists the EPSG codes
and reference frames supported by DynaNet.
Table 4.2 shows the various reference frame transformation combinations supported by DynaNet and
the respective references from which the transformation parameters have been sourced.
In addition to supporting transformations between a variety of reference frames, DynaNet also
supports the projection of coordinates between epochs on a single frame using a plate motion model.
In Version 3.3.0, only the Australian plate motion model is supported. Hence, DynaNet cannot be
used to project coordinates between epochs on a frame if the coordinates lie outside the Australian
4. The EPSG Geodetic Parameter Dataset, or EPSG dataset, is maintained by the Geodesy Subcommittee of the
Surveying and Positioning Committee of the International Association of Oil and Gas Producers (OGP). See
Table 4.1: EPSG codes and reference frames
Code Reference frame name Abbreviated name
4939 Geocentric Datum of Australia 1994 (geographic) GDA94
4347 Geocentric Datum of Australia 1994 (cartesian) GDA94
7843 Geocentric Datum of Australia 2020 (geographic) GDA2020
7842 Geocentric Datum of Australia 2020 (cartesian) GDA2020
7789 International Terrestrial Reference Frame, 2014 ITRF2014
5332 International Terrestrial Reference Frame, 2008 ITRF2008
4896 International Terrestrial Reference Frame, 2005 ITRF2005
4919 International Terrestrial Reference Frame, 2000 ITRF2000
4918 International Terrestrial Reference Frame, 1997 ITRF1997
4917 International Terrestrial Reference Frame, 1996 ITRF1996
4916 International Terrestrial Reference Frame, 1994 ITRF1994
4915 International Terrestrial Reference Frame, 1993 ITRF1993
4914 International Terrestrial Reference Frame, 1992 ITRF1992
4913 International Terrestrial Reference Frame, 1991 ITRF1991
4912 International Terrestrial Reference Frame, 1990 ITRF1990
4911 International Terrestrial Reference Frame, 1989 ITRF1989
4910 International Terrestrial Reference Frame, 1988 ITRF1988
4978 World Geodetic System, 1984 WGS84
Table 4.2: Supported transformation parameters
From reference frame To reference frame Transformation Parameters
GDA2020 ITRF2014, GDA94 ICSM 
GDA94 ITRF1996, ITRF1997, ITRF2000,
Dawson and Woods 
ITRF1988, ITRF1989, ITRF1990,
ITRF1991, ITRF1992, ITRF1993,
ITRF2000, ITRF2008 ITRF , ITRF 
ITRF1996, ITRF1997 ITRF2000, ITRF2008, GDA94 ITRF , ITRF ,
Dawson and Woods 
ITRF2000 ITRF1988, ITRF1989, ITRF1990,
ITRF1991, ITRF1992, ITRF1993,
ITRF1994, ITRF1996, ITRF1997,
ITRF2005, ITRF2008, GDA94
ITRF , ITRF ,
ITRF , Dawson and
ITRF2005 ITRF2000, GDA94 ITRF , Dawson and
ITRF2008 ITRF1988, ITRF1989, ITRF1990,
ITRF1991, ITRF1992, ITRF1993,
ITRF1994, ITRF1996, ITRF1997,
ITRF2000, ITRF2005, GDA94
ITRF , Dawson and
4.6.2 Relationship between ITRF, IGS and WGS84 reference frames
When post–processing GNSS data to produce high–precision GNSS baselines or point clusters, a
common prerequisite is the availability of precise GNSS satellite orbit information. IGS and its
participating analysis centres (see http://www.igs.org/) are amongst the most reliable and well
respected producers of precise GNSS orbits. Over the course of its history, IGS has aligned the
reference frame for its satellite orbit products to a variety of ITRF reference frames. Table 4.3 lists
the respective ITRF frames to which the orbit products are aligned and the periods in which those
Table 4.3: Alignment of IGS precise orbit product reference frames with ITRF updates over time
ITRF versions IGS frame Start date End date GPS weeks
ITRF 1992 ITRF92 02.01.1994 31.12.1994 0730 – 0781
ITRF 1993 ITRF93 01.01.1995 29.06.1996 0782 – 0859
ITRF 1994 ITRF94 30.06.1996 28.02.1998 0860 – 0946
ITRF 1994 retained ITRF96 01.03.1998 31.07.1999 0947 – 1020
ITRF 1994 retained ITRF97 01.08.1999 03.06.2000 1021 – 1064
ITRF 1997 IGS97 04.06.2000 01.12.2001 1065 – 1142
ITRF 2000 IGS00 02.12.2001 10.01.2004 1143 – 1252
ITRF 2000 retained IGb00 11.01.2004 04.11.2006 1253 – 1399
ITRF 2005 IGS05 05.11.2006 16.04.2011 1400 – 1631
ITRF 2008 IGS08 17.04.2011 06.10.2012 1632 – 1708
ITRF 2008 retained IGb08 07.10.2012 28.01.2017 1709 – 1933
ITRF 2014 IGS14 29.01.2017 . . . 1934 –
Upon processing GNSS data, the reference frame in which the baselines or points will be produced will
be the reference frame of the satellite orbit coordinates used in the GNSS processing. This is of course
the case if the processed GNSS baselines or points have not been transformed to a user–speciﬁed
frame by the GNSS processing package. If the GNSS processing software is able to transform the
GNSS data to the desired reference frame of the adjustment, no further steps are required. However,
to ensure the correct reference frame is selected upon importing GNSS measurements into DynaNet,
Table 4.3 should be used to identify the ITRF frame corresponding to the frame of the orbit products.
For example, if a GNSS campaign was undertaken on 5 May 2005 and precise satellite orbits from IGS
were used to produce a set of GNSS baselines and station coordinate estimates, the corresponding
IGS frame of those satellite orbits would be IGb00. As the IGb00 frame was aligned to ITRF 2000,
the reference frame and epoch of the GNSS baseline measurements should be set to ITRF 2000 and
05.05.2005 within the measurement input ﬁle. The following sample shows a GNSS baseline encoded
in DNA format (c.f. Table B.8 in Appendix B.1.4 for DNA measurement ﬁles).
G N-2234 N-6200 1.00 1.00 1.00 1.00 ITRF2005 05.05.2005
-20144.2370 5.0458000e-09 7.1068070e-05
-26611.5240 8.5190970e-05-2.7839720e-05 7.6459650e-05
Of course, the user is free to select an alternative frame to which the input data should be transformed
prior to adjustment.
In cases where broadcast ephemeris has been adopted (rather than precise satellite orbits), the
processed data will be in the frame of the GNSS constellation transmitting the broadcast signals. In
the case of GPS, the reference frame of the broadcast ephemerides is WGS84. Despite its name,
WGS84 is a dynamic frame which is continuously realised from routine analysis of the control centre
stations over time. In order to maintain compatibility with international reference frames, WGS84
has been aligned to various versions of ITRF throughout its 30+ year history. Table 4.4 tabulates the
diﬀerent versions of WGS84, the ITRF version and epoch to which each WGS84 version has been
aligned, and the date at which the alignment was adopted.
Table 4.4: Alignment of WGS84 realisations with ITRF updates over time (source: https:
WGS84 version Epoch ITRF version and epoch Oﬀset (m) Adopted GPS weeks
WGS84 1984.0 First realisation (DOPPLER) 1987 0001 – 0729
WGS84 (G730) 1994.0 ITRF 1991 0.7 29.06.1994 0730 – 0872
WGS84 (G873) 1997.0 ITRF 1994 0.2 29.01.1997 0873 – 1149
WGS84 (G1150) 2001.0 ITRF 2000 0.06 20.01.2002 1150 – 1673
WGS84 (G1674) 2005.0 ITRF 2008 0.01 08.02.2012 1164 – 1761
WGS84 (G1762) 2005.0 ITRF 2008 retained 0.01 16.10.2013 1762 –
To avoid misrepresentation of the appropriate frame to which stations and measurements are aligned,
DynaNet prevents the user from using WGS84. Hence, where WGS84 coordinates and/or GPS
baselines are to be introduced into an adjustment, the user should substitute the corresponding
ITRF version from Table 4.4 for the input GNSS measurements based on the date of that data.
Although not provided here, the same will need to be applied for the other GNSS constellations (e.g.
Beidou, Galileo, GLONASS, etc.).
4.6.3 Transforming station coordinates and measurements
To transform station coordinates and measurements, type reftran on the command line followed by
the network name, and then --reference-frame (or its shortcut -r) followed by the desired reference
frame to which all imported stations and GNSS measurements should be aligned:
reftran skye -r GDA94
If a DynaNet Project File (c.f. Chapter 2) is to be used, type dynanet on the command line, then
--project-file (or its shortcut -p) followed by the full path for the project ﬁle, and then the option
to invoke reftran:
dynanet -p skye.dnaproj --reftran
No other options are required, as reftran will be invoked using the options and arguments contained
in the project ﬁle uni_sqr.dnaproj.
Upon executing reftran, the binary station and measurement ﬁles skye.bst and skye.bms will be
loaded into memory. For each station and GNSS measurement found in the binary ﬁles, reftran
will verify whether the associated reference frame abbreviation is one of the supported reference
frames (c.f. Table 4.1). If the user–speciﬁed reference frame is not supported, reftran will terminate
prematurely with an error message. If the frame is in the list of supported frames, the appropriate
reference frame parameters will be selected. As it is possible for the input stations and measurements
to be aligned to multiple reference frames, reftran performs this test for every station and measurement.
Then, depending on whether one or more dynamic frames are involved, either equation 4.20 or 4.21
will be applied. Once all stations and measurements have been transformed, the binary station and
measurement ﬁles are updated.
At this point it should be noted that in order to achieve a rigorous transformation between reference
frames, the correct reference frame of the input stations and measurements must be set within the
input ﬁles or via the call to import (c.f. §3.3.1). Mis–identiﬁcation of the input reference frame will
lead to incorrect results.
Using the command above, reftran will undertake a transformation using the default reference frame
epoch. To transform station coordinates and measurements to a diﬀerent epoch, add --epoch (or
its shortcut -e) followed by the desired epoch in the form of dd.mm.yyyy:
reftran skye -r itrf2005 -e 05.05.2005
If a transformation using an epoch corresponding with today’s date is required, simply type today:
reftran skye -r itrf2005 -e today
When complete, reftran will report the number of stations and measurements transformed or, in the
case of failure, an error message corresponding to the type of failure. Using the skye project, Figure
4.4 shows the information reported to the screen upon normal program execution.
Network name: skye
Input folder: .
Output folder: .
Binary station file: ./skye.bst
Binary measurement file: ./skye.bms
Target reference frame: ITRF2005
+ Transforming stations and measurements... done.
+ Transformed 6 stations.
+ Transformed 27 measurements.
Figure 4.4: reftran progress reporting of station and measurement transformations
4.7 Data export
Upon transforming stations and measurements to an alternative reference frame, reftran provides
a capacity to export the transformed data into a number of diﬀerent ﬁle formats, including CSV,
DNA, DynaML and GeodesyML ﬁle formats.
To export transformed station and measurement information into CSV or DNA format, pass to
reftran the option --export-dna-files or --export-csv-files respectively. Similarly, to export
station and measurement information into DynaML format, pass the option --export-xml-files.
For example, the following command will export the stations and measurements in the skye project
to DNA format in GDA94:
reftran skye -r GDA94 --export-dna
Running this command will produce two ﬁles named skye.GDA94.stn and skye.GDA94.msr, which
correspond to the station and measurement ﬁles respectively.
Similarly, the option --export-xml-files will produce two XML ﬁles named skyestn.GDA94.xml and
skyemsr.GDA94.xml corresponding to the station and measurement ﬁles respectively. To produce a
single DynaML ﬁle, pass to reftran the option --single-xml-file with --export-xml-files.
Import and export of geoid information
In recognition of the inescapable inﬂuence of the anomalous gravity ﬁeld upon terrestrial geodetic
measurements, and the diﬀerence that exists between ellipsoidal and gravity–based height systems,
DynaNet provides an eﬃcient means for incorporating geoid information within an adjustment project.
Introducing this information into a project permits the rigorous combination of GNSS measurements
and terrestrial measurements within a single adjustment, the eﬃcient transformation of heights from
one height system to another, and the rigorous estimation of parameters in cartesian, geodetic and
local reference frames.
The task of introducing geoid information into a DynaNet project can be performed using a geoid ﬁle
as described in §3.2.4, or via automatic interpolation from a geoid model using geoid. The purpose of
this chapter is to explain the latter. This chapter also explains how to interpolate geoid information in
interactive and text ﬁle modes, how to transform between ellipsoid heights and orthometric heights,
how to convert geoid models in the legacy WINTER ﬁle format to binary grid ﬁles in National
Transformation version 2.0 (NTv2) grid ﬁle format [Junkins and Farley, 1995], and how to display
the metadata contained in an existing NTv2 binary grid ﬁle. The application of geoid information to
the observation equations for terrestrial geodetic measurements is dealt with in Chapter 7.
5.2 Fundamental concepts
Height determination demands a reasonable level of care due to the number of systems to which a
height can be related. To minimise the error that may be introduced into an adjustment through
incorrectly deﬁned station heights and/or height measurements, users should be aware of the intrinsic
diﬀerences between these systems. This section provides a basic overview of height systems and geoid
models, and will deﬁne the terms used throughout this document. For further information of height
systems and geoid modelling, the reader is encouraged to refer to Heiskanen and Moritz ,
Hofmann–Wellenhof and Moritz , Vaniček and Krakiwsky , Bomford , Rapp 
and Featherstone and Kuhn .
Consider the surfaces labelled natural terrain, ellipsoid, geoid, mean sea level and sea surface shown
in Figure 5.1. The terrain is the well understood ground surface upon which features of interest
and survey control marks are located. The ellipsoid is the mathematical surface chosen to best
represent the geometric size and shape of the Earth — either as a whole, or in a particular region. It
serves as the fundamental basis upon which positioning and navigation, map projections and geodetic
calculations can be based. It is also the surface to which GNSS measurements on the terrain are
related (c.f. Figure 4.1). As shown in Figure 5.1, ellipsoid height hrepresents the height of point p
above the ellipsoid, measured along the normal to the ellipsoid at point p0.
plumb–line (direction of gravity)
deﬂection of the vertical (ǫ)
gravity potential (Wp)
mean sea level
Figure 5.1: The relationships between the natural terrain, ellipsoid, geoid, mean sea level, and sea
Mean sea level (MSL) is an observed tidal datum and is used as the conventional reference surface
to which heights on the terrain (e.g. contours, heights of mountains, ﬂood plains, etc.) and other
tidal datums are related. The geoid is the surface of constant gravity potential (or equipotential)
chosen to best approximate MSL. It is often shown in the literature as W0in order to distinguish it
as the reference equipotential surface to which other gravity potentials (such as the potential Wpat
point p) are related. Being a gravity potential surface (as opposed to a geometrical surface like the
ellipsoid), the geoid is consistently perpendicular to the direction of gravity (i.e. the plumb–line). In
this sense, it represents the “spirit–level” surface at which ﬂuids stabilise.
As suggested by the curved plumb–line, the direction of gravity varies along the path of the plumb–line
on account of variations in land (or subsurface) mass–density and other gravity anomalies. The
deﬂection of the vertical is the angle between the direction of the plumb–line and the normal to
the ellipsoid and is generally expressed in two dimensions, as a north–south component (deﬂection
in the prime meridian, ξ) and an east–west component (deﬂection in the prime vertical, η). The sea
surface varies from the geoid due to the dynamic topography of the ocean caused by variations in
temperature, regional currents, gravitational eﬀects, and salinity, for example. For similar reasons,
MSL also varies from the geoid.
As shown in Figure 5.1, true orthometric height HOis the length of the curved plumb–line between
point pand the geoid. The geoid–ellipsoid separation NOis the length of the normal to the ellipsoid,
from p00 to the geoid. In practice, it is not a simple matter to compute the true orthometric height
since the integral mean of gravity between pand the geoid is a rather complex and practically
challenging phenomenon to quantify. For this reason, several approximations of HOhave been
proposed, such as Helmert orthometric (HH), normal (HN) and normal orthometric (HN O). It is
not necessary to explain all approximations for HO, although brief comments will be made on the
normal orthometric height system due to its frequent use in establishing national vertical datums.
Consider Figure 5.2. Normal orthometric height HN O is the length of the curved normal gravity
plumb–line between point pand the quasigeoid. It is based on a theoretical (ellipsoidal) normal gravity
ﬁeld and can be readily computed without knowing the nature of the subsurface mass–density or
needing to take gravity observations. As a result of approximating the Earth’s gravity ﬁeld with a
normal gravity ﬁeld, propagation of normal orthometric heights through spirit levelling requires a
relatively simple correction (known as the normal orthometric correction) to account for the change
in gravity according to the change in latitude along the levelling run.
normal gravity plumb–line
mean sea level
Figure 5.2: The relationship between the geoid and quasigeoid, and between ellipsoid height (h) and
normal orthometric height (HNO)
The height of the quasigeoid above the ellipsoid is labelled NNO and is often cited in the literature
as the height anomaly ζ. The quasigeoid is given its name since it is not an equipotential surface
and thereby does not properly describe the ﬂow of ﬂuids. The geoid and quasigeoid are coincident
at MSL, but diverge, more or less, over land with respect to elevation. According to Featherstone
and Kuhn , this divergence may reach up to 3.4 metres in the Himalayas and 0.15 metres in
Australia. The point to note is that the quasigeoid, being an approximation, does not represent true
gravity and hence, does not provide for estimating true orthometric heights and height diﬀerences.
5.2.1 Geoid models
There are numerous geoid and quasigeoid models (so called) in use throughout the world. A
comprehensive review of all such models is beyond the scope of this document. However, it is
worthwhile noting the subtle diﬀerences that may be found between such models.
Firstly, reﬂecting on the concepts discussed in the previous section, a gravimetric geoid model provides
NOvalues, whereas a gravimetric quasigeoid model generally provides approximations of it, such as
NNO or NH. Secondly, the adopted reference ellipsoid for each model is not unique. Although
international practice shows a global trend towards the use of the Geodetic Reference System 1980
(GRS80), some older models may be based upon the World Geodetic System 1984 (WGS84). Thirdly,
a geoid or quasigeoid model can be derived from a global equipotential model alone, such as EGM96
or EGM2008, or a combination of gravimetric data sourced from a global model, regional gravity
observations and other gravity modelling.
Another point to note is that there are models which also include a geometric component to
account for known distortions in a particular vertical datum. In the Australian context, AHD
was established using a normal–orthometric height system. Due to various reasons, AHD contains
numerous distortions of various magnitudes and does not coincide uniformly with the quasigeoid.
Of the four national geoid models published since 1990 for use over the Australian continent1, only
AUSGeoid09 includes a geometric component that models the diﬀerence between the gravimetric
quasigeoid and the zero surface of the AHD [Featherstone et al., 2011]. Hence, AUSGeoid09 provides
for converting between the GRS80 ellipsoid heights and AHD heights, not heights relative to the
Therefore, when selecting a geoid model from which to interpolate geoid/quasigeoid–ellipsoid values
and deﬂections of the vertical, it is imperative that the model supplied to geoid is compatible with
the adjustment project reference frame (and ellipsoid), and the supplied station heights and height
5.2.2 Conventions used in DynaNet
Although there is a tangible diﬀerence between the geoid and the quasigeoid (and other approximations
of the geoid), the term geoid will be used throughout this document to refer to gravimetric geoid
and quasigeoid models generally. Similarly, the term geoid–ellipsoid separation (N) will be used to
refer to both the separation between the geoid and the ellipsoid (NO) and the separation between
the quasigeoid (and other geoid approximations) and the ellipsoid (NN, ζ). Likewise, orthometric
height (H) will be used to refer to true orthometric (HO), Helmert (HH), normal (HN) and normal
orthometric (HNO) height. The practical implication is that whenever these terms are cited, the
user is responsible for interpreting them according to the context of the adjustment project.
5.3 Grid ﬁle interpolation
By far, the most simple, convenient, eﬃcient and repeatable means for retrieving geoid information
from a geoid model is to use interpolation from a structured grid ﬁle deﬁned by regularly–spaced
grid nodes. Using a regular grid ﬁle, geoid information can be interpolated at will for arbitrarily
located points via one of several interpolation methods. The information that can be incorporated
within a DynaNet adjustment includes values for geoid–ellipsoid separation N, the north–south and
east–west deﬂections of the vertical ξand η, and the respective uncertainties σN,σξand ση. When
attempting to interpolate this information from a gridded geoid model, geoid provides an ability to
derive the unknown parameter values using bilinear interpolation and bicubic interpolation. These
methods are brieﬂy described in the following sections.
5.3.1 Bilinear interpolation
The method of bilinear interpolation uses a quadratic form to calculate the desired parameter values
for an arbitrary point from a two–dimensional array of grid nodes. Bilinear interpolation is well suited
to the task of interpolating from grids having a relatively high resolution with respect to variability
in the grid node parameter values, or where higher order curve (or polynomial) ﬁtting oﬀers minimal
improvement in accuracy. In this method, only the four surrounding grid nodes are required. Figure
5.3 illustrates the concept of interpolating an unknown geoid–ellipsoid separation Nat point pfrom
the surrounding grid nodes using bilinear interpolation. The same concept applies to interpolating ξ
1. AUSGeoid90, AUSGeoid93, AUSGeoid98 and AUSGeoid09
Figure 5.3: Bilinear interpolation concept
The formula to compute Nat point pusing bilinear interpolation is given by [Press et al., 2002]:
Np=α00 +α10t+α01u+α11tu (5.1)
Here, N1,N2,N3and N4are retrieved from the grid ﬁle. ∆λint and ∆φint are the grid node
intervals in the east–west and north–south directions respectively. Since the majority of grid ﬁles are
orthogonal with regularly spaced grid nodes, ∆λint and ∆φint will be constant for throughout each
grid. The exception to this convention is when a geoid grid ﬁle contains one or more sub–grids which
have a higher resolution than the parent grid. However, in these instances, the values for ∆λint
and ∆φint will most likely be constant for each sub–grid. To interpolate ξpand ηp, the Nterms in
equations 5.3, 5.4, 5.5 and 5.6 are replaced with the corresponding ξand ηvalues for grid nodes 1
5.3.2 Bicubic interpolation
Bicubic interpolation uses a third degree polynomial, in two dimensions, to approximate a continuous
(or smooth) surface from which to calculate the unknown quantities. For this purpose, bicubic
interpolation requires the parameter values at sixteen grid nodes surrounding the arbitrary point. It
is computationally less eﬃcient, but may be necessary where the grid node spacing is large or there
is high variability in the grid node parameter values.
Conceptually, the method of bicubic interpolation involves two steps. Firstly, a two–dimensional
polynomial is ﬁtted to the sixteen grid node parameter values and, secondly, the value at the arbitrary
point is evaluated. To ﬁt the third order polynomial to the surrounding parameter values, sixteen
values must be evaluated for the four grid nodes — four parameter values, four east–west gradients,
four north–south gradients, and four cross–product gradients. All gradients (i.e. partial derivatives)
are computed using numerical diﬀerentiation from the sixteen parameter values N1...16.
The formula to compute Nat point pusing bicubic interpolation is given by [Press et al., 2002]:
Evaluating αinvolves a linear transformation of a vector xrepresenting the four parameter values
and twelve derivatives using a coeﬃcient matrix Cand is given by:
where C−1is the inverse of the coeﬃcient matrix:
−30030000−2 0 0 −10000
0000−30030000−2 0 0 −1
−3 3 0 0 −2−10000000000
00000000−3 3 0 0 −2−1 0 0
9−9 9 −9 6 3 −3−6 6 −6−334212
−6 6 −6 6 −4−2 2 4 −3 3 3 −3−2−1−1−2
−6 6 −6 6 −3−3 3 3 −4 4 2 −2−2−2−1−1
4−4 4 −4 2 2 −2−2 2 −2−221111
The elements of xare calculated as follows:
∂x ∆λint x9=∂N1
∂y ∆φint x13 =∂2N1
∂x ∆λint x10 =∂N2
∂y ∆φint x14 =∂2N2
∂x ∆λint x11 =∂N3
∂y ∆φint x15 =∂2N3
∂x ∆λint x12 =∂N4
∂y ∆φint x16 =∂2N4
The twelve gradient values ∂Ni/∂x,∂Ni/∂y and ∂2Ni/∂x∂y (i= 1,...,4) are evaluated as follows:
∂x =N10 −N4
∂y =N12 −N2
∂y =N13 −N1
∂x∂y =N3−N7−N15 +N5
∂x∂y =N10 −N8−N4+N6
∂x∂y =N11 −N9−N13 +N1
∂x∂y =N12 −N2−N14 +N16
Values for t,u,∆λpand ∆φpare evaluated from equations 5.7, 5.8, 5.9 and 5.10, and ∆λint and
∆φint are the grid node intervals. Finally, Nis evaluated at point pfrom equation 5.11 using the
for i= 0 to 4do
5.4 Import of geoid information
To introduce geoid information into a project, type geoid at the command prompt, followed by one
or more options and arguments. The complete command line reference for geoid is given in §A.4.
If no program options are provided upon program execution, the command line reference for geoid
will be displayed.
If a DynaNet Project File (c.f. Chapter 2) is to be used, provide --project-file (or its shortcut -p)
followed by the full path for the project ﬁle:
geoid -p skye.dnaproj
No other options are required, as geoid will be invoked using the options and arguments contained
in the project ﬁle skye.dnaproj.
To import geoid information using command line options and arguments, type geoid followed by the
network name2, and then --ntv2-file (or its shortcut -g) followed by the full path for the NTv2
binary geoid ﬁle:
geoid skye -g ausgeoid09.gsb
Upon executing geoid, the binary station ﬁle skye.bst and the header records from the NTv2 geoid
grid ﬁle ausgeoid09.gsb will be loaded into memory. For each station found in the binary station ﬁle,
geoid will attempt to interpolate the geoid–ellipsoid separations and the north–south and east–west
deﬂections of the vertical from the surrounding grid nodes. If the station lies outside the limits of
the geoid grid ﬁle, no information will be retrieved for that station. Once the information for all
stations has been interpolated, the binary station ﬁle and corresponding DynaNet project ﬁle will be
By default, bicubic interpolation (c.f. §5.3.2) is used to interpolate values from the surrounding grid
nodes. To interpolate geoid information using bilinear interpolation (c.f. §5.3.1), add to the geoid
command the option --interpolation-method (or its shortcut -m) followed by a zero (0):
geoid skye -g ausgeoid09.gsb -m 0
Since the least squares adjustment model implemented within DynaNet is based upon the cartesian
reference frame, all orthometric heights contained in the station ﬁle must be transformed to ellipsoid
heights. This can be achieved by adding the option --convert-stn-hts:
geoid skye -g ausgeoid09.gsb --convert-stn-hts
When the option --convert-stn-heights is provided, geoid will determine whether or not to
transform a station’s height by examining the coordinate type (c.f. §B.1.3, §B.4.1). If the coordinate
type is LLH or UTM,geoid will treat the supplied height as an orthometric height and transform it to
an ellipsoidal height using the interpolated Nvalue. If the coordinate type is LLh,geoid will treat
the station height as ellipsoidal, leaving it as–is. The application of interpolated geoid information
to terrestrial geodetic measurements prior to running an adjustment will be explained in Chapter 7.
When complete, geoid will report the number of stations for which geoid information was interpolated
or, in the case of failure, an error message corresponding to the type of failure. Using the geoid
project, Figure 5.4 shows the information reported to the screen upon normal program execution.
2. Note that the option --network-name is the default option to geoid and as such, the network name may be
passed to geoid without the option text.
Network name: skye
Input folder: .
Output folder: .
Binary station file: ./skye.bst
Convert orthometric heights: Yes
Geoid grid file: ausgeoid09.gsb
Interpolation method: Bi-cubic
Input coordinate format: Degrees minutes seconds
+ Binary station file interpolation mode.
+ Opening grid file... done.
+ Interpolating geoid components and reducing
heights to the ellipsoid... done.
+ Interpolated data for 6 points.
+ Geoid file interpolation took 0.007s
Figure 5.4: geoid progress reporting of geoid grid ﬁle interpolation
5.5 Arbitrary interpolation and height transformation
In addition to introducing geoid information into an adjustment project, geoid oﬀers two modes for
interpolating geoid information from a geoid grid ﬁle — interactive mode and text ﬁle mode. With
the latter, it is also possible to transform a ﬁle of heights from one height system (or vertical datum)
5.5.1 Interactive mode
Interpolating geoid information in interactive mode involves using the command line to specify
arbitrary interpolation points one at a time. For instance, to retrieve information for an arbitrary
location of -33°24’ 36” latitude and 149°39’ 06” longitude (provided in degrees, minutes and
seconds), type geoid, the NTv2 grid ﬁle option and ﬁle path, then --interactive (or its shortcut
-e) to indicate that coordinates will be entered via the command line, followed by options and
arguments for latitude and longitude:
geoid -g ausgeoid09.gsb -e --latitude -33.2436 --longitude 149.3906
When complete, geoid will report the Nvalue and the north–south and east–west deﬂections of the
vertical ξand ηinterpolated for the supplied coordinates. In the case of failure, an error message
corresponding to the type of failure will be displayed. Figure 5.5 shows the information reported to
the screen upon normal program execution.
Geoid grid file: ausgeoid09.gsb
Interpolation method: Bi-cubic
Input coordinate format: Degrees minutes seconds
+ Opening grid file... done.
+ Interpolation results for -33.2436, 149.3906 (ddd.mmssss):
N value = 25.4 metres
- Prime meridian = -4.41 seconds
- Prime vertical = -6.48 seconds
Figure 5.5: Interactive geoid grid ﬁle interpolation
By default, interactive input requires coordinates to be supplied in degrees, minutes and seconds
format. To interpolate geoid information using decimal degrees, simply add the --decimal-degrees
geoid -g ausgeoid09.gsb -e --latitude -33.4100 --longitude 149.6517 --decimal-degrees
Note that latitudes and longitudes, whether in decimal degrees or degrees, minutes and seconds, must
be supplied in HP notation (i.e. dd.dddddddd or dd.mmssssss). Spaces between degrees, minutes
and seconds will cause geoid to treat values following the spaces as independent option arguments.
Since geoid does not check or correct latitude values for sign, positive and negative latitude values
will be treated as being in the northern and southern hemispheres respectively. Similarly, positive and
negative longitude values will be treated as being east or west of the zero meridian (i.e. Greenwich
To interpolate geoid information using bilinear interpolation (c.f. §5.3.1), add --interpolation-method
(or its shortcut -m) followed by a zero (0).
5.5.2 Text ﬁle mode
Text ﬁle mode has been designed to provide an eﬃcient means for (1) interpolating geoid information
for a list of coordinates and (2) transforming heights from one system to another using simple ASCII
text ﬁle formats. For these purposes, geoid supports Formatted Text ﬁles (e.g. *.dat,*.prn,*.txt)
and Comma Separated Values ﬁles (*.csv). Appendix B.7 provides the ﬁle format speciﬁcation for
these ﬁle types.
To interpolate geoid information and transform a ﬁle of heights, type geoid on the command line,
followed by the NTv2 grid ﬁle option and ﬁle path, then --text-file (or its shortcut -t) with the
input text ﬁle path and, if required, options and arguments for interpolation method, coordinate
format and conversion direction. For example, to transform a ﬁle of heights in a ﬁle named
pipeline.txt from orthometric to ellipsoidal, where the desired interpolation method is bilinear
and the input coordinates are in decimal degrees, type:
geoid -g ausgeoid09.gsb -t pipeline.txt -m 0 --decimal -r 0
Upon transforming a text ﬁle of heights, geoid will report to the screen the items relevant to the
text ﬁle transformation, the progress of interpolation and transformation of heights, and any errors or
warnings related to the ﬁle transformation. Figure 5.6 shows the information reported to the screen
upon normal program execution.
Input folder: .
Output folder: .
ASCII file: pipeline.txt
Output file: pipeline_out.txt
Geoid grid file: ausgeoid09.gsb
Interpolation method: Bi-linear
Input coordinate format: Decimal degrees
+ ASCII file interpolation mode.
+ Opening grid file... done.
+ Interpolating geoid components... done.
+ Interpolated data for 17 points.
+ Warning: data for 1 point could not be interpolated.
See pipeline_out.txt for more information.
+ Geoid file interpolation took 0.012s
Figure 5.6: geoid progress reporting of geoid interpolation and text ﬁle transformation
During this process, geoid will attempt to determine the ﬁle type from the ﬁle extension and contents
of the input ﬁle. Any problems encountered with opening the input ﬁle will be reported to the screen.
The name of the output ﬁle will be the same as the input ﬁle name, but with a “_out” inserted
between the ﬁle name and the ﬁle extension. During the transformation process, geoid information
will be interpolated using the default or user–speciﬁed interpolation method, and the height supplied
on each line will be transformed according to the transformation direction. The original height,
transformed height, interpolated Nvalue and deﬂections of the vertical ξand ηfor each point in
the ﬁle will be appended to the original record from the input ﬁle, which is in turn printed to the
output ﬁle. Since geoid is only concerned with heights, the input latitude and longitude are written
directly to the output ﬁle without any alteration.
In the case of an error, the input record preﬁxed by the string ’ERROR (#)’, where ’#’ is a number
indicating the type of error, will be printed to the output ﬁle. Typical examples of error include
instances when the coordinates cannot be read from the input ﬁle (possibly due to an incorrect
coordinate type or ﬁle record format), or if the coordinates lie outside the extents of the geoid grid
ﬁle. Table 5.3 in §5.7.3 lists the possible range of error codes and their meanings.
5.6 Exporting interpolated information
During the process of interpolating geoid information from a geoid grid ﬁle, geoid can export this
information to a DNA geoid ﬁle. Generating a DNA geoid ﬁle is only necessary when it is desirable to
introduce geoid information into a DynaNet project via import (c.f. §3.2.4). To export interpolated
geoid information to a DNA geoid ﬁle, simply add the --export-dna-geo-file option when executing
geoid. The following examples show how to export geoid information during the process of (1)
introducing geoid information into a project (c.f. §5.4) and (2) interpolating in text ﬁle mode (c.f.
geoid skye -g ausgeoid09.gsb --export-dna-geo-file
geoid -g ausgeoid09.gsb -t pipeline.txt --export-dna-geo-file
5.7 Working with NTv2 geoid grid ﬁles
5.7.1 Reporting NTv2 geoid grid ﬁle metadata
At times, it may be necessary to view a summary of the metadata contained within an NTv2 geoid
grid ﬁle. NTv2 grid ﬁle metadata is contained within an array of block header records, and provides
speciﬁc information relating to, for example, geoid grid ﬁle version, geoid and ellipsoid parameters,
grid ﬁle extents and grid node interval. To display the header information for a grid ﬁle, type geoid
on the command line, followed by the NTv2 grid ﬁle option and ﬁle path, then --summary (or its
shortcut -u) :
geoid -g ausgeoid09.gsb -u
Running this command will produce a summary similar to that which is shown in Figure 5.7.
Geoid grid file: ausgeoid09.gsb
Input coordinate format: Degrees minutes seconds
Grid properties for "ausgeoid09.gsb":
+ GS_TYPE = SECONDS
+ VERSION = 18.104.22.168
+ SYSTEM_F = GDA94
+ SYSTEM_T = AHD_1971
+ MAJOR_F = 6378137.000
+ MAJOR_T = 6378137.000
+ MINOR_F = 6356752.314
+ MINOR_T = 6356752.314
+ NUM_OREC = 11
+ NUM_SREC = 11
+ NUM_FILE = 1
+ SUBGRID 0:
SUB_NAME = AUSGEOID
PARENT = NONE
CREATED = 01012010
UPDATED = 01012010
S_LAT = -165540.000
N_LAT = -28800.000
E_LONG = -575940.000
W_LONG = -388800.000
LAT_INC = 60.000
LONG_INC = 60.000
GS_COUNT = 7113600
Figure 5.7: Example NTv2 grid ﬁle summary
In relation to Figure 5.7, Tables 5.1 and 5.2 describe the NTv2 grid ﬁle header ﬁelds and the individual
sub grid header ﬁelds.
Table 5.1: NTv2 grid ﬁle overview ﬁelds
NUM_OREC Number of header records in the overview block.
NUM_SREC Number of header records in each sub grid block.
NUM_FILE Number of sub grids contained in the geoid grid ﬁle. A grid ﬁle may contain several sub
grids of diﬀerent densities. The limits of these sub grids will all be contained within the
parent grid. If there is only one sub grid, then it is the parent grid.
GS_TYPE The units of the grid nodes.
VERSION The geoid grid ﬁle version.
SYSTEM_F The “from” reference ellipsoid (or geodetic datum with well known ellipsoid)
SYSTEM_T The “to” height system or vertical datum.
MAJOR_F The ellipsoid semi–major axis of the “from” system.
MAJOR_T The ellipsoid semi–major axis of the “to” system.
MINOR_F The ellipsoid semi–minor axis of the “from” system.
MINOR_T The ellipsoid semi–minor axis of the “to” system.
Table 5.2: NTv2 grid ﬁle sub grid ﬁelds
SUB_NAME The name of this particular sub grid.
PARENT The parent sub grid name. ’NONE’ if this is the parent grid.
CREATED Grid ﬁle creation date
UPDATED Grid ﬁle modiﬁcation date
S_LAT Lower latitude extent
N_LAT Upper latitude extent
E_LONG Lower longitude extent
W_LONG Upper longitude extent
LAT_INC Latitude interval
LONG_INC Longitude interval
GS_COUNT Grid node count
5.7.2 Importing WINTER DAT geoid grid ﬁles
AUSGeoid09 has been publicly released in the form of ASCII text ﬁles using the legacy WINTER
DAT ﬁle format. Whilst serving as a simple, human–readable format, the WINTER DAT ﬁle format
is not designed to provide an eﬃcient means for instantaneous interpolation. Accordingly, DynaNet
requires the geoid information contained in these ﬁles to be converted into a structured binary format.
DynaNet uses the NTv2 format for structuring, storing and interpolating geoid model information.
To convert geoid information in the WINTER DAT ﬁle format to the NTv2 binary format, type
geoid at the command prompt, then --create-ntv2 (or its shortcut -c), followed by the options
and arguments relating to the input and output ﬁles and the geoid model parameters. For example,
to create a new NTv2 binary grid ﬁle named geoid_model.gsb from geoid information stored in a
WINTER DAT ﬁle named geoid_model.dat using the default options, run the following command:
geoid -c -g ./geoid_model.gsb -d geoid_model.dat
When converting geoid ﬁles to the NTv2 binary format, geoid will determine from the raw data the
upper and lower grid extents and the north–south and east–west grid node intervals. Checks are
also performed to ensure the data contains a suﬃcient number of nodes to construct an orthogonal
grid ﬁle. The parameters derived from the raw data will be written to the grid ﬁle header records
(c.f. Tables 5.1 and 5.2). Since the WINTER DAT ﬁle format contains data for a single grid, the
resultant NTv2 grid ﬁle will contain a single sub–grid which will be the parent grid.
To facilitate the capture of other metadata relating to the geoid grid ﬁle, geoid provides options
to specify the units for the deﬂections of the vertical (in radians or seconds), the grid ﬁle version,
the name of the ellipsoid system, the name of the height system or vertical datum, the semi–major
and semi–minor ellipsoid parameters of the two systems, the name of the sub–grid, and the dates of
creation and update. For example, to specify a version of 22.214.171.124, the name MYGEOID, ellipsoid and
height system names GDA94 and AHD71, a creation date of 18 March 2015 and an update date of 5
May 2015, run the following command:
geoid -c -g ./geoid_model.gsb -d geoid_model.dat --VERSION 126.96.36.199 --SUB_NAME MYGEOID --SYSTEM_F GDA94
--SYSTEM_T AHD71 --CREATED 18032015 --UPDATED 05052015
The option --grid-shift-type followed by either seconds or radians can be used to specify the
units in which the grid extents and the deﬂections of the vertical will be stored. The options
--semi-major-from,--semi-major-to,--semi-minor-from and --semi-minor-to are not used during
grid ﬁle interpolation and can be provided for metadata purposes only.
Figure 5.8 shows the information reported to the screen upon normal program execution. Once the
NTv2 binary grid ﬁle has been created, a summary of the grid ﬁle parameters (c.f. Figure 5.7) will
Input folder: .
Output folder: .
Geoid grid file: geoid_model.gsb
WINTER DAT file: geoid_model.dat
+ Creating NTv2 file from WINTER DAT file format:
+ Reading contents of WINTER DAT file... done.
+ WINTER DAT file structure appears OK.
+ Creating NTv2 gsb file... done.
+ Grid properties for geoid_model.gsb:
- GS_TYPE = SECONDS
- VERSION = 188.8.131.52
- SYSTEM_F = GDA94
- SYSTEM_T = AHD71
Figure 5.8: Progress of NTv2 grid ﬁle creation
5.7.3 Grid ﬁle interpolation errors
If an error occurs at any time during the geoid interpolation process, a non-zero value is printed to
the output ﬁle to indicate the type of error. Table 5.3 lists the errors that may be encountered upon
geoid grid ﬁle interpolation.
Table 5.3: Grid ﬁle interpolation error codes and descriptions
-6 The NTv2 version of the speciﬁed grid ﬁle is not supported.
-5 The parameters for the speciﬁed grid ﬁle do not match the number of records.
-4 Could not allocate the required memory.
-3 A grid ﬁle has not been opened.
-2 Cannot locate the required sub grid.
1 The speciﬁed grid ﬁle could not be opened.
2 Cannot read this type of grid ﬁle.
3 or 14 Found an unrecoverable error in the speciﬁed grid ﬁle: <grid–file–name>
It is likely that this ﬁle was downloaded or produced incorrectly.
4 Could not read from the speciﬁed input ﬁle.
5 Could not write to the speciﬁed output ﬁle.
6 Cannot read this type of input ﬁle.
7 Cannot produce this type of output ﬁle.
8 No data was contained within the last input record.
9 The record <data–record> is too short to contain valid data.
10 The record <data–record> does not contain valid numeric input.
11 The required data could not be extracted from the record <data–record>.
12 The speciﬁed zone is invalid.
13 or -1 The point <data–record> lies outside the extents of the speciﬁed grid ﬁle.
15 The interpolation shifts could not be retrieved from the ASCII grid ﬁle.
16 The interpolation shifts could not be retrieved from the Binary grid ﬁle.
17 The csv record <data–record> does not contain suﬃcient records.
For relatively small survey control networks, the task of estimating unknown station coordinates and
their uncertainties can be readily achieved in a matter of seconds using a modern computer. In
these circumstances, network segmentation can be omitted,<