DynaNet User's Guide V3.3

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 234 [warning: Documents this large are best viewed by clicking the View PDF Link!]

1
x
y
z
DynaNet User’s Guide
Version 3.3
Editors:
Roger Fraser, Frank Leahy, Philip Collier
July 2017
DynaNet User’s Guide
Dynamic Network Adjustment Software
July 2017
©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.
(http://creativecommons.org/licenses/by/4.0/legalcode)
For all technical and software related matters, please contact:
Dr. Roger Fraser
Manager, Geodetic Survey
Office of Surveyor-General Victoria
Department of Environment, Land, Water and Planning
Level 17/570 Bourke St, Melbourne, Victoria, 3000
roger.fraser@delwp.vic.gov.au
ii
DynaNet User’s Guide
Version 3.3
Dr. Roger Fraser
Manager, Geodetic Survey
Office of Surveyor–General Victoria
Melbourne
Dr. Frank Leahy
Associate Professor
University of Melbourne
Melbourne
Dr. Phil Collier
Research Director
Cooperative Research Centre for Spatial Information
Melbourne
iii
iv
Acknowledgements
The development of this software and user guide has benefited 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 files 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
(Matthew 10:8)
Remember the words of the Lord Jesus, how He said, “It is more blessed to give than to receive”
(Acts 20:35)
v
vi
Contents
Acknowledgements ...................................... v
Contents............................................ vii
ListofFigures......................................... xiii
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 flow . . . . . . . . . . . . . . . . . . 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 files . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Create DynaNet project file . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Verification and error checking . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Configuring import options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Referenceframe ................................ 24
3.3.2 Datascreening ................................. 25
3.3.3 GNSS variance matrix scaling . . . . . . . . . . . . . . . . . . . . . . . . . 31
vii
3.4 Network measurement simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5 Dataexport....................................... 35
3.5.1 Station and measurement files . . . . . . . . . . . . . . . . . . . . . . . . . 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 Gridleinterpolation.................................. 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 Textlemode ................................. 62
5.6 Exporting interpolated information . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.7 Working with NTv2 geoid grid files . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.7.1 Reporting NTv2 geoid grid file metadata . . . . . . . . . . . . . . . . . . . 64
5.7.2 Importing WINTER DAT geoid grid files . . . . . . . . . . . . . . . . . . . 65
5.7.3 Grid file 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 efficiency . . . . . . . . . . 73
6.4.2 Inevitable influences on the generated block sizes . . . . . . . . . . . . . . . 74
6.4.3 Factors influencing the segmentation rate . . . . . . . . . . . . . . . . . . . 76
viii
6.4.4 Generating coordinate estimates and full variance matrix for a user–defined
setofstations ................................. 77
6.4.5 Datum deficient blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.6 Non–contiguous networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5 Segmentinganetwork ................................. 78
6.5.1 Configuring segmentation behaviour . . . . . . . . . . . . . . . . . . . . . . 79
6.5.1.1 Specifying stations to appear in the first block . . . . . . . . . . . . 79
6.5.1.2 Achieving optimum block sizes . . . . . . . . . . . . . . . . . . . . 80
6.5.1.3 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 differences . . . . . . . . . . . . . . . . . . 86
7.2.5 Orthometric heights (H) and height differences (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
7.3.1.1 Normal distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.3.1.2 Chi–square distribution . . . . . . . . . . . . . . . . . . . . . . . . 96
7.3.1.3 Student’s t distribution . . . . . . . . . . . . . . . . . . . . . . . . 98
7.3.2 Preparation of measurement precisions and variance matrices . . . . . . . . 99
7.3.2.1 Scaling GNSS variance matrices . . . . . . . . . . . . . . . . . . . 100
7.3.3 Expressing estimates of quality and reliability . . . . . . . . . . . . . . . . . 101
7.3.3.1Errorellipses.............................. 101
7.3.3.2 Positional uncertainty . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.3.3.3 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
8.3.2.1 Single–thread mode . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.3.2.2 Multi–thread mode . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.3.2.3 Block–1 only mode . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.3.2.4 Staged adjustment mode . . . . . . . . . . . . . . . . . . . . . . . 115
8.3.2.5 Report results mode . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.3.3 Adjustment configuration options . . . . . . . . . . . . . . . . . . . . . . . 116
ix
8.3.4 Output configuration options . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.3.5 Export configuration 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
9.3.1.1 Rectifying over–optimistic variance matrices of the same type . . . . 129
9.3.2 Testing for the presence of outliers . . . . . . . . . . . . . . . . . . . . . . 131
9.3.2.1 Testing measurements with reliable estimates of precision . . . . . . 131
9.3.2.2 Testing measurements with doubtful estimates of precision . . . . . 135
9.3.3 Hints on addressing measurement failures . . . . . . . . . . . . . . . . . . . 141
Bibliography 143
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 specification 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 file format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
C Output file format specification 195
C.1 Headerblock ...................................... 195
C.2 Importlogle(IMP) .................................. 195
C.3 Measurement to station output file (M2S) . . . . . . . . . . . . . . . . . . . . . . 196
C.4 Segmentation output file (SEG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
C.5 Coordinate output file (XYZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
C.6 Adjustment output file (ADJ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
C.6.1 Adjustment statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
x
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 file (COR) . . . . . . . . . . . . . . . . . . . . . . . 207
C.8 Adjusted positional uncertainty file (APU) . . . . . . . . . . . . . . . . . . . . . . 209
C.9 SINEX output warning file (SNX.ERR) . . . . . . . . . . . . . . . . . . . . . . . . 212
xi
xii
List of Figures
1.1 Coordination of DynaNet program execution . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Flow of information between various DynaNet programs and input and output files . 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 filtered by the --bounding-box option. 26
3.3 Stationrenamingle .................................. 28
3.4 Baselinescalarle.................................... 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 file interpolation . . . . . . . . . . . . . . . . 61
5.5 Interactive geoid grid file interpolation . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.6 geoid progress reporting of geoid interpolation and text file transformation . . . . . 63
5.7 Example NTv2 grid file summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.8 Progress of NTv2 grid file 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
xiii
7.3 Relationships between slope distance, MSL arc distance, ellipsoid arc distance and
ellipsoid chord distance measurements . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.4 Heights and height differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Singlethreadmode................................... 111
8.3 Multi–thread mode on four cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.4 Thread switching on a single core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.5 Block1onlymode ................................... 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 file 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
heightdierences .................................... 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
measurements....................................... 181
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 schemadenition ............................ 188
B.21 DnaStation schemadenition.............................. 189
xiv
B.22 Sample station file encoded in DynaML format . . . . . . . . . . . . . . . . . . . . 189
B.23 DnaMeasurement schemadenition ........................... 190
B.24 Clusterpoint and GPSBaseline schema definition . . . . . . . . . . . . . . . . . . . 191
B.25 Directions and GPSCovariance schema definition . . . . . . . . . . . . . . . . . . . 191
B.26 Sample measurements encoded in DynaML format . . . . . . . . . . . . . . . . . . 192
B.27 Example formatted text file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
B.28 Example comma separated values file . . . . . . . . . . . . . . . . . . . . . . . . . . 194
xv
xvi
List of Tables
3.1 Station coordinate types handled by the supported file formats . . . . . . . . . . . . 18
3.2 Supported measurement types and measurement codes . . . . . . . . . . . . . . . . 19
3.3 GNSS variance matrix scaling options . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 StationMapelds.................................... 36
3.5 Associated Stations List fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Associated Measurements List fields . . . . . . . . . . . . . . . . . . . . . . . . . . 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:
//confluence.qps.nl/pages/viewpage.action?pageId=29855173)....... 50
5.1 NTv2 grid file overview fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 NTv2 grid file sub grid fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Grid file interpolation error codes and descriptions . . . . . . . . . . . . . . . . . . . 67
6.1 Distribution of parameters and measurements of a network segmented into two blocks 71
7.1 Confidence intervals for ±1σto ±4σ. ......................... 96
9.1 Student’s t confidence 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 file interpolation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
A.17 geoid exportoptions .................................. 160
A.18 segment standardoptions ............................... 161
A.19 segment congurationoptions............................. 161
xvii
A.20 adjust standardoptions................................. 162
A.21 adjust adjustment mode options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.22 adjust phased adjustment options . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
A.23 adjust adjustment configuration 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 configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
A.29 plot mappingoptions .................................. 168
A.30 plot PDFvieweroptions ................................ 169
B.1 Header line column locations and field widths . . . . . . . . . . . . . . . . . . . . . 172
B.2 Station information column locations and field widths . . . . . . . . . . . . . . . . . 173
B.3 General measurement information column locations and field widths . . . . . . . . . 174
B.4 Column locations and field widths for horizontal angles . . . . . . . . . . . . . . . . 174
B.5 Column locations and field widths for geodetic azimuths, astronomic azimuths, zenith
distances and vertical angles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
B.6 Column locations and field widths for direction sets. . . . . . . . . . . . . . . . . . . 176
B.7 Column locations and field widths for ellipsoid chords, ellipsoid arcs, Mean Sea Level
arcs, slope distances and height differences. . . . . . . . . . . . . . . . . . . . . . . 176
B.8 Column locations and field widths for a GNSS baseline (single or cluster) header record.177
B.9 Column locations and field widths for a GNSS point cluster header record. . . . . . . 178
B.10 Column locations and field widths for GNSS baseline and point measurements. . . . 178
B.11 Column locations and field widths for a GNSS cluster covariance block. . . . . . . . 179
B.12 Column locations and field widths for orthometric and ellipsoid height measurements. 181
B.13 Column locations and field widths for geodetic latitudes and longitudes, and astronomic
latitudesandlongitudes. ................................ 181
B.14 Geoid information column locations and field widths . . . . . . . . . . . . . . . . . . 182
B.15 DynaNet program options formatting. . . . . . . . . . . . . . . . . . . . . . . . . . 184
B.16 Formatted text file fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
B.17 Comma separated values file fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
xviii
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
mainland Australia.
CSV Comma Separated Values
DNA Dynamic Network Adjustment
DynaML DynaNet Markup Language. XML format defined according to the DynaNet 2.0 XML
schema.
EPSG European Petroleum Survey Group
GDA2020 Geocentric Datum of Australia 2020. Realised by continuous analysis of over 400
Asia Pacific 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 =
1/298.257222101
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
xix
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
xx
List of Symbols
φGeodetic latitude.
λGeodetic longitude.
ΦAstronomic latitude.
ΛAstronomic longitude.
AAstronomic azimuth.
θ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
frame.
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.
ξDeflection of the vertical in the prime meridian (north–south component).
ηDeflection of the vertical in the prime vertical (east–west component).
Combined deflection 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.
xxi
hHeight of point pabove the ellipsoid.
µThe mean.
σStandard deviation of an estimated quantity.
σ2Variance or precision of an estimated quantity.
σ2
0Variance factor or sigma zero.
αProbability or significance level, expressed as a percentage or value from 0 to 1.0.
kCoverage factor corresponding to the level of significance.
χ2
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.
xxii
Chapter 1
Introduction
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 effectively 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
reference frames;
Rigorous application of geoid–ellipsoid separations and deflections of the vertical;
Simultaneous (traditional) and phased adjustment modes;
Automatic segmentation and adjustment of extremely large networks in an efficient 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 [1956] was
the first to develop the concept and principles of phased adjustment. In his work, Tienstra defines
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.
1
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 [1963] studied phased adjustment and demonstrated that Krüger’s [1905]
method of stacking normal equations was mathematically equivalent to Tienstra’s phased adjustment
technique. Schmid and Schmid [1965], 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 [1965] 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 [1970] 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 [1970] 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 [1974]. In this development, Pinch and Peterson formally
prove that where two sections of a network are adjusted independently in a first 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 [1976] notes that in the final 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 [1983] 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
definition, 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
information.
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.
2
package designed to undertake phased adjustments of geodetic networks comprised of conventional
terrestrial measurements. This software package was refined by Collier [1991] to accommodate
three–dimensional adjustments and the integration of GPS baseline measurements. With these
enhancements and other new capabilities and bug fixes, the software became known as MetNet and
was used extensively for the adjustment of the Melbourne survey control network. Further research
by Leahy [1999] led to the development of a fully automated network segmentation procedure which
can handle networks of any size and configuration, 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 refinements 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 [1998] at the University of Melbourne and
was made possible through funding provided by the Australian Research Council (ARC) and industry
support from the Office of Surveyor–General Victoria, AUSLIG Geodesy and WBCM Surveys Pty Ltd.
Following numerous enhancements and refinements 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 specifications of DynaNet and the environments in which it has been compiled and tested
include:
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
software development;
Developed for Windows, Linux and Mac OS X platforms, and runs on 32–bit and 64–bit
operating systems;
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 fixes.
1.2 Conventions used in this document
The following typographical and mathematical conventions have been adopted throughout this
document:
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 fixed–width typewriter font.
Examples of program execution at the command prompt are encapsulated by a grey box. If
different syntax is required for Windows and UNIX/Linux platforms, syntax for both environments
3
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 file contents are denoted by fixed–width typewriter font. File contents are
encapsulated by a grey box with column positions shown in a separate box:
1234567890123456789012345678901234567890123456789012345678901234567890123456789
!#=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
σ2.
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 configuration via program
options and arguments is also explained.
1.3.1 Software architecture and information flow
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 affords several advantages, such as:
Individual programs can be executed to perform a specific 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 specific
user requirement;
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
step.
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.
4
dynanet
import adjust
segment
reftran geoid plot
.dnaproj
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 first to define
the network name, and to convert geodetic station coordinates and measurements from
external file formats into the required binary and text file 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 configure 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 deflections of the vertical into a
project from either an NTv2 formatted geoid model or ASCII text file. This program can
optionally export interpolated geoid information to a DNA geoid text file. geoid also
provides a capability to generate NTv2 formatted files from the legacy AUSGeoid DAT
file 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 specific 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) file. The use of the project file will be discussed in more detail in Chapter 2.
5
The programs import,reftran,geoid,segment,adjust and plot read and write a range of formatted
files in a way which permits the structured flow of information. Figure 1.2 illustrates the flow of
information amongst the various programs and files.
Figure 1.2: Flow of information between various DynaNet programs and input and output files
As shown in Figure 1.2, information exported from one program often serves as input to other
programs. This concept affords the user an ability to examine the output from one program before
executing another program, and to re–run certain programs with different user options and to examine
the variation in results. A brief description of the various file 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 files (.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
6
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 configure the way in which DynaNet
programs process geodetic network information. Each DynaNet program will require certain options
specific 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 specified 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 sufficient 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 five 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 files via the option --reference-frame (or -r in brief). As this
option provides a multiple choice, only predefined 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 configure 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.
7
import
adjust
segment
reftran
geoid
plot
Project creation stage
Pre–processing stage
Parameter estimation stage
Network plotting and
statistics graphing
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
specified reference frame and epoch.
Interpolate geoid–ellipsoid separations and deflections 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
adjustment statistics.
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 different reference
frames, then the sequence import,reftran and adjust will be required.
Terrestrial measurements If terrestrial measurements (e.g. angles, distances and orthometric
height differences) 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 deflections of the vertical which are used by DynaNet to cater for the influence 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 confidence regions and a–priori station corrections
derived from a least squares adjustment, then the sequence will be import,adjust and plot.
8
Secondly, network processing and adjustment may require data concatenation, screening (or filtering),
scaling and multiple transformations between different reference frames before the network is suitable
for processing by adjust. For these tasks, it is recommended that a script file 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 file 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.
145˚11'0.0"
145˚11'0.0"
145˚11'30.0"
145˚11'30.0"
145˚12'0.0"
145˚12'0.0"
−38˚07'0.0" −38˚07'0.0"
−38˚06'30.0" −38˚06'30.0"
−38˚06'0.0" −38˚06'0.0"
0 1
Kilometres
302502400
302513650
302508300
302509800
302513640
261907650
Figure 1.4: Stations and measurements in the skye network
9
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 file to string together several DynaNet program calls. Apart from some
basic differences, calls to DynaNet programs will be identical for both Windows and UNIX/Linux
platforms and can therefore be copied directly to a Windows batch file or a UNIX/Linux shell script
respectively.
For Windows platforms, prepare a file called run_skye.bat as follows:
echo off
rem Script to automate processing of skye geodetic network
For UNIX/Linux platforms, prepare a file called run_skye.sh as follows:
#!/bin/bash
# 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 file 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 files. Setting the
network name and importing files 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 files 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 file 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
as follows:
10
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
file 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 file skye.bst will contain
geoid–ellipsoid separations and deflections of the vertical, and any orthometric heights will be reduced
to ellipsoid heights.
Step 4 — Adjust the network
DynaNet offers the flexibility 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 files, 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 file 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 file.
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 flag within the station file, (2) add a station
position measurement to the measurement file, 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 effect replicates the first 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.
11
12
Chapter 2
Creating, editing and processing
projects
2.1 Introduction
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 file to store default and user specified
options. The user options contained in a project file configure the way in which the respective
DynaNet programs handle the geodetic network information relating to a project. At execution
time, each program can be configured by providing a project file 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 files can be used to
completely automate the processing of geodetic networks, and to capture the options used during
program operation.
This chapter explains the various conventions used by DynaNet for managing projects, how to prepare
input files, 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 file names for all generated output files, and to determine which file to open when
information generated from one program must be read as input by another program. The basic file
naming convention is represented by network_name.ext where network_name is the user–supplied
network name and ext is the file extension. In some cases, DynaNet generates files in the form of
network_name.mode.ext where mode represents either a mode in which a program has been executed
or a user–specified program option.
To permit the input of files with a different file name to that which is expected from the default
naming convention, the file name for certain input files 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 specified when running import, DynaNet adopts the name ’network#’ where
#’ represents the next available integer that yields a unique (or unused) file name in the folder of
13
program execution.
The primary exceptions to the file naming convention are station and measurement files (e.g. *.snx,
*.stn,*.msr,*.xml) provided as input to import, and the raw data files and formatted grid files
(e.g. *.dat,*.csv,*.gsb) provided as input to geoid. No restrictions are imposed upon the
naming of these files other than that the file extension corresponds with the file format. The file
extension restriction is imposed only for certain file types which prevent DynaNet from automatically
interpreting file 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
files, which are treated as either output and/or input files. The following is a list of file types
created by DynaNet in accordance with the file naming convention (assuming the network name is
network_name):
Binary formatted file types
network_name.aml Associated Measurements List. This file contains a list of measurements that
a station appears in.
.asl Associated Stations List. This file contains a count of the measurements
connected to a station and the index of this station in the AML file.
.bms Binary Measurements file. This file contains information about the
measurements in a network. The BMS file is a binary formatted file created
using an efficient file structure to provide maximum efficiency for retrieving
measurement information.
.bst Binary Stations file. This file contains information about the stations in a
network. The BST file is a binary formatted file created using an efficient file
structure to provide maximum efficiency for retrieving station information.
.map Station Map. This file maintains the relationship between the supplied
alphanumeric name and a unique (numerical) station identifier.
.mtx Matrix file. This file stores matrices in a structured file format designed for
efficient data storage.
.dbid Database ID list. This file contains the user–supplied database IDs for
measurements contained in DNA formatted measurement files.
ASCII text file types
network_name.imp import log. This file is a log of the station and measurement import
process.
.seg segment output. This file contains the station and measurement indices
for the respective blocks created from network segmentation.
.adj adjust output. This file 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 file contains
the corrections to the initial station coordinates.
.apu Adjusted Positional Uncertainty produced by adjust. This file contains
the positional uncertainties of the adjusted station coordinates.
14
.dbg Debug output. This file contains detailed program output information
to help assist with isolating network adjustment problems.
.dst Duplicate Stations list. This file contains a list of stations that were
identified as duplicates by import.
.dms Duplicate Measurements list. This file contains a list of measurements
that were identified as duplicates by import.
.log dynanet log. This file provides a time–stamped record of the progress
of the individual programs that have been coordinated by dynanet.
2.2.3 Directories
By default, all DynaNet programs expect input files to exist in the directory in which the programs
are run. DynaNet will also generate output files in this directory. Optionally, an input folder and
an output may be specified to inform the DynaNet programs where to find input files and where to
store output files. This feature will be covered in more detail in subsequent chapters.
2.3 Project setup and processing
2.3.1 Prepare station and measurement files
The first step in creating a project is to prepare the station and measurement files. DynaNet
supports a small range of file types. Appendix B provides a list of supported file types and the format
specification for selected file types. Stations and measurements may be provided in one or more files,
each of which may be encoded in any one of the supported file formats. DynaNet does not impose
any restrictions on how this information should be structured and so the user is left to decide which
file type is chosen and how station and measurement information will be stored.
2.3.2 Create DynaNet project file
In order to process projects in a single step using the main program dynanet, a project file must be
created. Note that a project file does not need to be created if the various DynaNet programs will be
executed manually, or executed via Windows batch files or UNIX/Linux shell scripts. In these cases
however, a project file will be created and updated automatically as each program is executed.
There are two options for creating a DynaNet project file — users may create this file manually or
use import to create this file automatically. The file format for the project file is described in §B.3.
Each time import is executed, a new project file will be created using the network name and the
default or user–specified output folder path. If this file 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
files, will be printed to project file. Users not familiar with the project file format are encouraged
to use import to create the project file, and to use a text editor to modify the project file with the
desired options and arguments.
2.3.3 Automated project processing
Upon creating a project file, projects can be processed in a single step using the main program
dynanet. Using the project file 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.
15
dynanet -p skye.dnaproj --import --geoid --adjust
The first option (-p) and argument (skye.dnaproj) inform dynanet where to find the project file.
Since the folder path was not provided on the command line, DynaNet will assume the project file
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 specified in the project file. 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 files are entered into the project file 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 file path and conversion of orthometric heights to
ellipsoid heights are handled by --ntv2-filepath and --convert-stn-hts (under #geoid). Finally,
configuring adjust to perform a simultaneous adjustment, holding station 302513640 fixed, and
to produce a table of adjusted measurements and statistics in the adjustment output (.adj) file 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 configured to
run a simultaneous adjustment.
As dynanet runs, it will load the options contained in the project file and pass them to the
respective programs. Upon execution, a log file 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 file is shown below.
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345
+---------------------------------------------------------------------------
+ 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: dynanet.mail@gmail.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.
16
Chapter 3
Import and export of geodetic network
information
3.1 Introduction
DynaNet supports a number of file formats for the exchange of geodetic network information. The
primary file 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 specific 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 defined 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 defined according to ICSM’s eGeodesy GML
application schema
SINEX (Solution-INdependent EXchange format) for the exchange of solutions and covariance
information
Appendix B provides the file format specification for the CSV, DNA and DynaML file types. The
specification for GeodesyML can be found at http://geodesyml.org. The specification for the
SINEX file format can be found at
http://www.iers.org/IERS/EN/Organization/AnalysisCoordinator/SinexFormat/
sinex.html
DynaNet also reads and writes a number of binary and ASCII file 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
17
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 file:
import -p uni_sqr.dnaproj
No other options are required, as import will be invoked using the options and arguments contained
in the project file 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 files 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 first available
network name is found.
Whether using a project file or not, additional options and arguments can be supplied to configure
the way in which this information is imported. When using a project file, any additional options and
arguments provided on the command line will overwrite the values contained in the project file.
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 file formats described in
the introduction, Table 3.1 lists the coordinate types handled by the respective file formats.
Table 3.1: Station coordinate types handled by the supported file 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 file
18
formats. §3.2.3 explains the concept of station constraints and how they are interpreted by DynaNet.
Configuring 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 efficient
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 (∆xyz)
H Orthometric height
I Astronomic latitude
J Astronomic longitude
K Astronomic (Laplace) azimuth
L Orthometric height difference
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 file formats.
3.2.3 Network constraints
DynaNet permits networks to be constrained using two different forms — via station constraints and
position measurement constraints. Multiple constraints of both forms may be applied to a network.
19
Station constraints
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 file formats).
Station parameters which the user considers fixed 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 define 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
page 117.
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 fixed 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 significant difference 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 fix 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 defining the geodetic
datum for all stations in a network. However, position measurement constraints are somewhat
different 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 fixed), 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
reflect 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.
20
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 file) is the most rigorous approach
for constraining a network in three dimensions, and for defining 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 influence of the anomalous gravity field
with GNSS measurements within a single adjustment, geoid–ellipsoid separations and deflections of
the vertical are required. For this purpose, geoid facilitates the interpolation of the required geoid
information from a structured geoid grid file (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 file. In this case, all
information about a geodetic network can be imported in a single step. Secondly, import offers
an option to simulate measurements observed in the local reference frame which contain realistic
measures of geoid–ellipsoid separations and deflections 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 file 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 file format.
3.2.5 File name argument conventions
When supplying import with options and arguments relating to input station and measurement files,
DynaNet offers a few conventions to simplify the process of entering file names. Firstly, supplying
a file name does not require the --stn-msr-input-file option (or its shortcut -f). Secondly, any
number of station and measurement files may be supplied, whether of the same or different file
formats. Thirdly, input files can be supplied in any order. The following hypothetical example shows
how a number of files and file 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
files); the progress of file reading; summary of loaded station and measurement information; progress
21
of various processing tasks; and final exit status (i.e. success or failure). Figure 3.1 shows the
information reported to the screen upon program execution.
+ Options:
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
+ Parsing:
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
-------------------------------------------
Total 149
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
-------------------------------------------
Total 1199*
* 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
22
The amount of information will vary depending on the options and arguments supplied to import,
such as folder locations, input files, file contents, reference frame, data screening, GNSS measurement
scaling and export. This information is also logged to a file 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 Verification and error checking
When import is executed, a number of verification and error checking tasks are undertaken upon
loading the information into DynaNet. These tasks are briefly summarised below.
Empty strings
As data is loaded from the input files, import will verify that non–empty strings exist for mandatory
fields and elements. The fields 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 file format specification in Appendix B for
a list of mandatory fields and elements for the respective station coordinate types and measurement
types.
Testing for duplicate stations and measurements
When supplying import with station and measurement information either in one file or in a number
of files, import will identify and remove duplicate station information. Although input file arguments
may be supplied in any order, import processes input files sequentially in the order they have been
entered on the command line. If a station contained in an earlier input file is found in a subsequent
file, the latter station will be regarded as a duplicate station and thereby ignored. All duplicate
stations are printed to a file with a .dst extension. If it is essential that duplicate station information
be maintained across multiple files, then the user must ensure that the file which contains the desired
station information (e.g. station name, coordinates and constraints) is loaded first.
When concatenating networks contained in different files, the same station can sometimes appear
in the station and measurement files twice with different station names. To assist users with the
detection of two differently 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 files 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 affords 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 file(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 file exactly as they appear
23
in the measurements. This test is case sensitive and includes whitespace. Any stations which are not
found in the station file 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 configuring the way in which unused stations are handled.
3.3 Configuring 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 files1,import provides two options to efficiently associate a reference frame to stations
and measurements upon loading the input files.
Default Reference frame
Before any input files are loaded, import by default assumes that the reference frame for all incoming
stations and measurements is GDA94. If an input file does not contain reference frame information,
this default reference frame option will be adopted. However, if an input file contains reference
frame information, this information will be retained. To specify a different default reference frame
to be used for all stations and GNSS measurements contained in the input files, 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
following command:
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 effected by setting the
default reference frame abbreviation in the binary station (.bst) and binary measurement (.bms)
files. 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
file constraints.snx is not altered by this option. Similarly, any GNSS measurements loaded from
a measurement file that have already been assigned a reference frame will not be altered.
1. According to the SINEX 2.02 specification, a SINEX file 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
information.
24
Override input reference frame name
The option --reference-frame sets the default reference frame and thereby only comes into effect 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 different reference frames
Note that option --reference-frame will set the default reference frame for all input files in a
single step. If a project is based upon multiple input files aligned to different 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 file format specification allows (e.g. CSV, DNA and DynaML formats. See B.1), set the
default and measurement–specific reference frame of the stations and measurements within in
the input file;
Where file formats do not make provision for setting the default reference frame, use a two–step
approach:
1. Group files together which are aligned to a common reference frame. Set the default
reference frame upon loading the input files with import.
2. Execute reftran with the desired reference frame and export to the desired file 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 filter 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 flagging and ignoring station and measurement information.
Geographical region
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 defining 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
25
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.
145˚11'44.0"
145˚11'44.0"
145˚11'48.0"
145˚11'48.0"
145˚11'52.0"
145˚11'52.0"
145˚11'56.0"
145˚11'56.0"
145˚12'0.0"
145˚12'0.0"
−38˚06'48.0" −38˚06'48.0"
−38˚06'44.0" −38˚06'44.0"
−38˚06'40.0" −38˚06'40.0"
0 0.1
Kilometres
302502400
302513650
302509800
302513640
Figure 3.2: Stations and measurements in the skye network filtered 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 specific stations and associated measurements, pass to import the option
--include-stns-assoc-msrs followed by a comma delimited string defining 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
26
cluster, add the option --split-gnss-cluster-msrs.
Conversely, to import all stations except a set of specific stations, pass to import the option
--exclude-stns-assoc-msrs followed by a comma delimited string defining 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
--split-gnss-cluster-msrs.
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 file named uni_sqr.seg must exist
in the folder from which import was executed, and this file must contain at least three blocks
(see Chapter 6 for more information on the creation of segmentation files). To use an alternative
segmentation file, pass to import the option --seg-file followed by the name of the segmentation
file. If the segmentation file is located in another directory, the file name must include the full folder
path.
Measurement type
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 defining 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
longitude:
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.
27
Station renaming
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 field 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 file:
import -n skye skye.stn skye.msr --stn-renaming-file skye.renaming
The structure and format of the station renaming file is shown in Figure 3.3. The first 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 field will be defined according to the DNA
STN file format version. For DNA version 3.0 onward, this width is 20. Rows beginning with an
asterisk are treated as comments and are ignored.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
!#=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)
302513640 1364
302509800 980
302508300 830
261907650 765
Figure 3.3: Station renaming file
Station nearness
When concatenating networks contained in different files, the same physical station can sometimes
appear in the station and measurement files with different station names. To assist with identifying
stations with different 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 identified one or more nearby stations, import will create a file 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 file
28
are as follows:
--------------------------------------------------------------------------------
DUPLICATE STATION FILE
Version 3.1.2
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 identified the stations that satisfy the search criteria, it is up to the user to verify
if the stations listed in the .dst file are the same physical station or not. If a single station has
been inadvertently given different names in the station and measurement files, 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 file 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.
Measurement similarity
As in the case for stations, concatenating networks contained in different files can easily result
in duplicate measurements in the measurement files. Duplicate measurements can be difficult 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:
29
+ 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 file 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-->
<DnaMeasurement>
<Type>L</Type>
<Ignore/>
<First>2214</First>
<Second>2213</Second>
<Value>0.0010</Value>
<StdDev>0.0020</StdDev>
</DnaMeasurement>
<!--Type S Slope distance-->
<DnaMeasurement>
<Type>S</Type>
<Ignore/>
<First>2205</First>
<Second>2213</Second>
<Value>13.3010</Value>
<StdDev>0.0050</StdDev>
<InstHeight>0.000</InstHeight>
<TargHeight>0.000</TargHeight>
</DnaMeasurement>
<!--Type S Slope distance-->
<DnaMeasurement>
<Type>S</Type>
<Ignore/>
<First>6002</First>
<Second>1049</Second>
<Value>136.4290</Value>
<StdDev>0.0100</StdDev>
<InstHeight>1.601</InstHeight>
<TargHeight>1.337</TargHeight>
</DnaMeasurement>
As with stations, the second and subsequent appearances of a measurement with similar attributes
will be regarded as a duplicate. Once import has identified the measurements that satisfy the test
for similarity, it is up to the user to verify if the measurements listed in the .dms file are the same
measurement or different measurements. Measurements which are duplicates can either be removed
from the measurement file, or set as an ignored measurement. For example, measurements can be
ignored in DNA files by providing an asterisk (*) for the ignore flag (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 difficult 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
30
measurements the same reference frame and epoch.
Ignoring similar measurements
Upon verifying whether the measurements listed in the .dms file are duplicate measurements, the
user may opt to remove the duplicate measurements or flag them as ignored for further verification.
To automatically ignore all measurements identified 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 flag 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 flagged as ignored, whether in the measurement file or by supplying the
--ignore-similar-msr option, can be automatically removed from all subsequent processing as
follows:
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 flag similar measurements and, together with any other
measurements already marked as ignored, will not be written to the binary measurement file.
Flagging unused stations
Upon loading the station and measurement information from the input files, 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 file. 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
--flag-unused-stations:
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 files
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
31
adjustment. GNSS measurement variance matrices may be scaled using the appropriate scalar fields
within the input files (e.g. Table B.8 on page 177 for DNA file format, or Figure B.23 on page 190
for DynaML file format). In addition, import provides a capacity to scale GNSS variance matrices
via five different 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 files passed to import, or to individual GNSS baselines. Individual
baseline scaling is based upon the contents of a baseline scalar file and does not apply to GNSS point
or baseline clusters. Whether scaling all or individual GNSS variance matrices, scaling can be applied
in two different 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 specific GNSS baseline variance matrices, pass to import the option --v-scale followed by
the name of the baseline scalar file:
import -n skye skye.stn skye.msr --baseline-scalar-file skye.scalars
The structure and format of the baseline scalar file 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.
32
12345678901234567890123456789012345678901234567890123456789012345678901234567890
--------------------------------------------------------------------------------
GNSS BASELINE VARIANCE MATRIX SCALAR FILE
SCALARS
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 file
For all scaling options, §7.3.2.1 describes the procedure implemented by DynaNet for scaling GNSS
variance matrices.
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 files are required — a
station file and a measurement simulation control file. Upon execution, measurements are simulated
for all measurement types and station names listed in the measurement simulation control file.
Measurement values are calculated using the coordinates provided in the station file. 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 file 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 file simnet.stn must conform to the DNA
station file format (c.f. §B.1.3). The input measurement simulation control file simnet-list.msr
must conform to the DNA measurement file 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 file.
The measurement values in the simulated measurements file 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
3.0×p(L/1000.0)/100.0
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
33
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.
123456789012345678901234567890123456789012345678901234567890123456789
!#=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
501
503
E 503 307
G 604 606
H 105
I 106
J 106
K 101 202
L 910 1010
M 604 706
P 105
Q 105
R 106
S 602 302
V 109 207
X 406 501 2
109 501
Y 406 XYZ 3
203
509
Z 503 307
Figure 3.5: Example simulation measurements list
If orthometric heights are supplied in the station file, or if simulated terrestrial measurements are
intended to contain a realistic measure of the influence of the gravity field, geoid–ellipsoid separations
and deflections of the vertical can be added to the measurements through the use of a DNA geoid
file. To this end, add the --geo-file option (c.f. §3.2.4), followed by the geoid file name:
import -n simnet simnet.stn simnet-list.msr --simulate --geo-file simnet.geo
If a DNA geoid file has not been created, geoid may be called to interpolate and export the
geoid–ellipsoid separations and deflections of the vertical to a DNA geoid file. For this purpose,
a binary station file for simnet is required. The steps are as follows:
1. Import the simulation station file to create the binary station file simnet.bst.
2. Interpolate the geoid information (from simnet.bst) and export to a DNA geoid file.
3. Simulate using the station file, simulation control file and the newly created geoid file.
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
34
See Chapter 5 for more help on interpolating geoid information from a geoid grid file.
3.5 Data export
In addition to translating the external file formats into the binary formats required by DynaNet,
import provides a capacity to export geodetic network information into a number of different file
formats. The options for exporting information include:
Export of station and measurement information to CSV, DNA, DynaML, GeodesyML and
SINEX file formats
Export of geodetic network binary files (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 configuration options can be stored for
subsequent import, filtering and processing.
3.5.1 Station and measurement files
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 files 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 files named us_bsl.stn and us_bsl.msr corresponding
to the station and measurement files 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 file.
The option --export-xml-files will produce two XML files named <network_name>stn.xml and
<network_name>msr.xml corresponding to the station and measurement files respectively. To produce
a single DynaML file, 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 files
according to the file naming convention described in §2.2.1 (i.e. uni_sqr), and data is exported to
the same file format as the input files, then the original input files 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 files. 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
35
This command will produce three files named us_bsl.map.txt,us_bsl.asl.txt and us_bsl.aml.txt.
The fields contained in the exported files are described in Tables 3.4, 3.5 and 3.6.
Table 3.4: Station Map fields
Field Description
Station name The station name as given in the input station and measurement files. The column
header contains the number of stations detected in the input files.
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 fields
Field Description
Station name The station name as given in the input station and measurement files. The
column header contains the number of stations detected in the input files.
No. connected msrs The number of measurements connected to this station.
AML index The (zero–based) index of the first 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 fields
Field Description
Station name The station name as given in the input station and measurement files. The column
header contains the number of records in the file.
Msr index The (zero–based) index of this measurement in the binary measurements file.
Msr type The type of measurement (c.f. Table 3.2) and which measurement station this station
refers to (first, 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.
36
Chapter 4
Transformation of coordinates and
measurements
4.1 Introduction
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 different reference frames and epochs. This is
primarily due to the fact that since the launch of the first 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
(GLONASS).
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 different 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 first 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.
37
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.
x
y
z
o
xp
yp
zp
p
p
φ
λ
ν
q
h
Figure 4.1: The ellipsoid–centred cartesian reference frame
A vector xcbetween two points in the cartesian reference frame will have the elements:
xc=
x
y
z
(4.1)
As shown by Figure 4.1, geodetic latitude is the angle between the equatorial (xy) 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 defining
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:
38
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:
ν=a
q1e2sin2φ(4.3)
ais the quantity representing the semi–major axis of the reference ellipsoid and e2is the first
eccentricity obtained from:
e2=a2b2
a2(4.4)
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
given by:
ρ=a1e2
1e2sin2φ3
2
(4.5)
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:
xl=
e
n
up
(4.7)
A vector xlin the local reference frame is related to the cartesian reference frame by:
xc=Rlxl(4.8)
where Rlis the rotation matrix with origin at latitude φand longitude λ:
Rl=
sin λsin φcos λcos φcos λ
cos λsin φsin λcos φsin λ
0 cos φsin φ
(4.9)
39
x
y
z
o
q
e
n
up
p
φ
λ
Figure 4.2: The local reference frame
Equation 4.8 can be written in expanded form as:
x
y
z
=
sin λ(∆e)sin φcos λ(∆n) + cos φcos λ(∆up)
cos λ(∆e)sin φsin λ(∆n) + cos φsin λ(∆up)
cos φ(∆n) + sin φ(∆up)
(4.10)
Since Rlis orthogonal1, a vector xcin the cartesian reference frame is related to the local reference
frame by:
xl=RT
lxc(4.11)
which can be written in expanded form as:
e
n
up
=
sin λ(∆x) + cos λ(∆y)
sin φcos λ(∆x)sin φsin λ(∆y) + cos φ(∆z)
cos φcos λ(∆x) + cos φsin λ(∆y) + sin φ(∆z)
(4.12)
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
distance (s).
1. A matrix is orthogonal if the inverse of that matrix is equal to its transpose, i.e. RT=R1.
40
e
n
up
p1
p2
ϑ
θ
s
ϑ
θ
s
v
a
s
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 defining 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:
xp=
a
v
s
(4.13)
A vector in the local reference frame is transformed to the displaced polar reference frame by:
xp=Rpxl(4.14)
where Rpis an orthogonal rotation matrix at origin p2:
Rp=
cos θsin ϑsin θcos ϑsin θ
sin θsin ϑcos θcos ϑcos θ
0 cos ϑsin ϑ
(4.15)
Polar coordinates of θ,ϑand sare related to vectors in the local reference frame by:
θ= arctan e
n
ϑ= arctan up
e2+ ∆n2(4.16)
s=pe2+ ∆n2+ ∆up2
Equation 4.14 can be written in expanded form as:
a
v
s
=
cos θ(∆e)sin ϑsin θ(∆n) + cos ϑsin θ(∆up)
sin θ(∆e)sin ϑcos θ(∆n) + cos ϑcos θ(∆up)
cos ϑ(∆n) + sin ϑ(∆up)
(4.17)
41
Since Rpis orthogonal, a vector xpin the displaced polar reference frame can be rotated into the
local reference frame by:
xl=RT
pxp(4.18)
which can be written in expanded form as:
e
n
up
=
cos θ(a)sin θ(v)
sin ϑsin θ(a)sin ϑcos θ(v) + cos ϑ(s)
cos ϑsin θ(a) + cos ϑcos θ(v) + sin ϑ(s)
(4.19)
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:
x2
y2
z2
=
x12
y12
z12
+ (1 + δ)
1rzry
rz1rx
ryrx1
x1
y1
z1
(4.20)
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:
R=
cos rzsin rz0
sin rzcos rz0
0 0 1
cos ry0sin ry
0 1 0
sin ry0 cos ry
1 0 0
0 cos rxsin rx
0sin rxcos rx
Conformal transformations between two cartesian reference frames on different 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 first order derivatives of origin shift, rotation and
scale as follows:
x2
y2
z2
=
x12 + ˙x(t2t1)
y12 + ˙y(t2t1)
z12 + ˙z(t2t1)
+1 + δ+˙
δ(t2t1)×(4.21)
1rz+ ˙rz(t2t1)ry˙ry(t2t1)
rz˙rz(t2t1) 1 rx+ ˙rx(t2t1)
ry+ ˙ry(t2t1)rx˙rx(t2t1) 1
x1
y1
z1
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.
42
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:
Vxc=RlVxlRT
l(4.22)
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:
Vxl=R1
lVxcR1
lT(4.23)
Since Rlis orthogonal, Vxlmay be expressed as:
Vxl=RT
lVxcRl(4.24)
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:
Vxp=PVxlPT(4.25)
where Pis the Jacobian transformation matrix formed by linearising equations 4.16:
P=
θ
e
θ
n
θ
up
ϑ
e
ϑ
n
ϑ
up
s
e
s
n
s
up
(4.26)
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:
Vxp=PRT
lVxcRlPT(4.27)
43
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:
Vxc=TVxgTT(4.28)
Tis the Jacobian transformation matrix formed by linearising equations 4.2:
T=
x
φ
x
λ
x
h
y
φ
y
λ
y
h
z
φ
z
λ
z
h
(4.29)
For the reverse solution, propagation of variances into the geographic coordinate system is via:
Vxg=T1VxcT1T(4.30)
4.5 Conversion of projection coordinates
It is often necessary to work with geographic information defined 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 6wide in longitude,
extends from 80latitude to +80latitude, and is numbered consecutively beginning from zone 1
at 180to 174longitude and extending eastwards to zone 60 (+174to +180longitude). 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 different 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 figures on the ellipsoid onto
a flat, two–dimensional surface requires distortion in some form or another. Accordingly, different 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
and Northings.
44
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
6cos3φψt2
+νω5
120 cos5φ4ψ316t2+ψ21+8t2ψ2t2+t4
+νω7
5040 cos7φ61 479t2+ 179t4t6(4.31)
N= 10,000,000 + k0m+νsin φω2
2cos φ
+νsin φω4
24 cos3φ4ψ3+ψt2
+νsin φω6
720 cos5φ8ψ411 24t2+ 28ψ316t2
+ψ2132t2ψ2t2+t4
+νsin φω8
40320 cos7φ1385 3111t2+ 543t4t6(4.32)
Zo =ω
zw
(4.33)
where:
ω=λλ0(4.34)
zw= zone width (in units of λ)(4.35)
ψ=ν
ρ(4.36)
t= tan φ(4.37)
m=a(A0φA2sin 2φ+A4sin 4φA6sin 6φ)(4.38)
A0= 1 e2
43e4
64 5e2
256(4.39)
A2=3
8e2+e4
415e6
128  (4.40)
A4=15
256 e4+3e6
4(4.41)
A6=35e6
3072 (4.42)
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 φ.
45
Conversely, the relationship between geographic coordinates and UTM and TM projection coordinates
is given by [Redfearn, 1948]:
φ=φ0t0
k0ρ0xE0
2+t0
k0ρ0x3E0
24 4ψ02+ 9ψ01t02+ 12t02
t0
k0ρ0x5E0
720 8ψ0411 24t0212ψ0321 71t02
+ 15ψ0215 98t02+ 15t04+ 180ψ05t023t04+ 360t04
+t0
k0ρ0x7E0
403201385 + 3633t02+ 4095t04+ 1575t06(4.43)
λ=λ0+ sec φ0xx3
6sec φ0ψ0+ 2t02
+x5
120sec φ04ψ0316t02+ψ02968t02+ 72ψ0t02+ 24t04
x7
5040sec φ061 + 662t02+ 1320t04+ 720t06(4.44)
where:
E0=EEf(4.45)
N0=NNf(southern hemisphere only) (4.46)
x=E0
k0ν0(4.47)
ψ0=ν0
ρ0(4.48)
λ0=zozw+λ1zw(4.49)
φ0=σ+3η
227η3
32 sin 2σ+21η2
16 55η3
32 sin 4σ
+151η3
96 sin 6σ+1097η4
512 sin 8σ(4.50)
η=f
2f(4.51)
G=a(1 η)1η21 + 9
4η+225
64 ηπ
180 (4.52)
σ=πm
180G(4.53)
m=N0
k0
(4.54)
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.
46
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 files, 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–specified 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–specified system (e.g. cartesian, geographic, local
or polar).
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 files 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
defined 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
tectonic plate.
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
http://www.epsg.org
47
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 [2017]
GDA94 ITRF1996, ITRF1997, ITRF2000,
ITRF2005, ITRF2008
Dawson and Woods [2010]
ITRF1988, ITRF1989, ITRF1990,
ITRF1991, ITRF1992, ITRF1993,
ITRF1994
ITRF2000, ITRF2008 ITRF [2000], ITRF [2008]
ITRF1996, ITRF1997 ITRF2000, ITRF2008, GDA94 ITRF [2000], ITRF [2008],
Dawson and Woods [2010]
ITRF2000 ITRF1988, ITRF1989, ITRF1990,
ITRF1991, ITRF1992, ITRF1993,
ITRF1994, ITRF1996, ITRF1997,
ITRF2005, ITRF2008, GDA94
ITRF [2000], ITRF [2005],
ITRF [2008], Dawson and
Woods [2010]
ITRF2005 ITRF2000, GDA94 ITRF [2005], Dawson and
Woods [2010]
ITRF2008 ITRF1988, ITRF1989, ITRF1990,
ITRF1991, ITRF1992, ITRF1993,
ITRF1994, ITRF1996, ITRF1997,
ITRF2000, ITRF2005, GDA94
ITRF [2008], Dawson and
Woods [2010]
48
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
frames apply.
Table 4.3: Alignment of IGS precise orbit product reference frames with ITRF updates over time
(source: http://acc.igs.org/igs-frames.html)
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–specified
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 file. The following sample shows a GNSS baseline encoded
in DNA format (c.f. Table B.8 in Appendix B.1.4 for DNA measurement files).
G N-2234 N-6200 1.00 1.00 1.00 1.00 ITRF2005 05.05.2005
11675.0160 1.3617930e-04
-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.
49
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
different 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:
//confluence.qps.nl/pages/viewpage.action?pageId=29855173)
WGS84 version Epoch ITRF version and epoch Offset (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 file, 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 file uni_sqr.dnaproj.
Upon executing reftran, the binary station and measurement files skye.bst and skye.bms will be
loaded into memory. For each station and GNSS measurement found in the binary files, reftran
will verify whether the associated reference frame abbreviation is one of the supported reference
50
frames (c.f. Table 4.1). If the user–specified 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 files 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 files or via the call to import (c.f. §3.3.1). Mis–identification 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 different 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.
+ Options:
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 different file formats, including CSV,
DNA, DynaML and GeodesyML file 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:
51
reftran skye -r GDA94 --export-dna
Running this command will produce two files named skye.GDA94.stn and skye.GDA94.msr, which
correspond to the station and measurement files respectively.
Similarly, the option --export-xml-files will produce two XML files named skyestn.GDA94.xml and
skyemsr.GDA94.xml corresponding to the station and measurement files respectively. To produce a
single DynaML file, pass to reftran the option --single-xml-file with --export-xml-files.
52
Chapter 5
Import and export of geoid information
5.1 Introduction
In recognition of the inescapable influence of the anomalous gravity field upon terrestrial geodetic
measurements, and the difference that exists between ellipsoidal and gravity–based height systems,
DynaNet provides an efficient 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 efficient 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 file
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 file modes, how to transform between ellipsoid heights and orthometric heights,
how to convert geoid models in the legacy WINTER file format to binary grid files in National
Transformation version 2.0 (NTv2) grid file format [Junkins and Farley, 1995], and how to display
the metadata contained in an existing NTv2 binary grid file. 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 defined station heights and/or height measurements, users should be aware of the intrinsic
differences between these systems. This section provides a basic overview of height systems and geoid
models, and will define 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 [1993],
Hofmann–Wellenhof and Moritz [2006], Vaniček and Krakiwsky [1986], Bomford [1980], Rapp [1961]
and Featherstone and Kuhn [2006].
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.
53
p
p′′
p
NO
HOh
ν
plumb–line (direction of gravity)
ellipsoid normal
deflection of the vertical (ǫ)
terrain
geoid (W0)
gravity potential (Wp)
ellipsoid
sea surface
mean sea level
ocean
ocean floor
Figure 5.1: The relationships between the natural terrain, ellipsoid, geoid, mean sea level, and sea
surface.
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, flood 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 fluids 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
deflection 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 (deflection
in the prime meridian, ξ) and an east–west component (deflection 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 effects, 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
field and can be readily computed without knowing the nature of the subsurface mass–density or
54
needing to take gravity observations. As a result of approximating the Earth’s gravity field with a
normal gravity field, 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.
p
p′′
p
NNO (ζ)
HNO
h
normal gravity plumb–line
ellipsoid normal
terrain
geoid
mean sea level
quasigeoid(W0)
ellipsoid
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 flow of fluids. The geoid and quasigeoid are coincident
at MSL, but diverge, more or less, over land with respect to elevation. According to Featherstone
and Kuhn [2006], 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 differences.
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 differences that may be found between such models.
Firstly, reflecting 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.
55
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 difference 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
gravimetric quasigeoid.
Therefore, when selecting a geoid model from which to interpolate geoid/quasigeoid–ellipsoid values
and deflections 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
measurements.
5.2.2 Conventions used in DynaNet
Although there is a tangible difference 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 file interpolation
By far, the most simple, convenient, efficient and repeatable means for retrieving geoid information
from a geoid model is to use interpolation from a structured grid file defined by regularly–spaced
grid nodes. Using a regular grid file, 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 deflections 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 briefly 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) fitting offers 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 ξ
and η.
1. AUSGeoid90, AUSGeoid93, AUSGeoid98 and AUSGeoid09
56
N1
N2
N3
N4
Np
φ1
φ2
φ3
φ4
λ1
λ2
λ3
λ4
φinterval
λinterval
φp
λp
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)
=
1
X
i=0
1
X
j=0
αijtiuj(5.2)
where:
a00 =N1(5.3)
a10 =N2N1(5.4)
a01 =N4N1(5.5)
a11 =N1+N3N2N4(5.6)
t=λp
λint
(5.7)
u=φp
φint
(5.8)
λp=λpλ1(5.9)
φp=φpφ1(5.10)
Here, N1,N2,N3and N4are retrieved from the grid file. λint and φint are the grid node
intervals in the east–west and north–south directions respectively. Since the majority of grid files 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 file 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
57
equations 5.3, 5.4, 5.5 and 5.6 are replaced with the corresponding ξand ηvalues for grid nodes 1
to 4.
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 efficient, 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 fitted to the sixteen grid node parameter values and, secondly, the value at the arbitrary
point is evaluated. To fit 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 differentiation from the sixteen parameter values N1...16.
The formula to compute Nat point pusing bicubic interpolation is given by [Press et al., 2002]:
Np=
3
X
i=0
3
X
j=0
αijtiuj(5.11)
Evaluating αinvolves a linear transformation of a vector xrepresenting the four parameter values
and twelve derivatives using a coefficient matrix Cand is given by:
α=C1x
where C1is the inverse of the coefficient matrix:
C1=
1000000000000000
0000000010000000
300300002 0 0 10000
2002000010010000
0000100000000000
0000000000001000
0000300300002 0 0 1
0000200200001001
3 3 0 0 210000000000
000000003 3 0 0 21 0 0
99 9 9 6 3 36 6 6334212
6 6 6 6 42 2 4 3 3 3 32112
2200110000000000
0000000022001100
6 6 6 6 33 3 3 4 4 2 22211
44 4 4 2 2 22 2 2221111
58
The elements of xare calculated as follows:
x1=N1x5=N1
x λint x9=N1
y φint x13 =2N1
x∂y λintφint
x2=N2x6=N2
x λint x10 =N2
y φint x14 =2N2
x∂y λintφint
x3=N3x7=N3
x λint x11 =N3
y φint x15 =2N3
x∂y λintφint
x4=N4x8=N4
x λint x12 =N4
y φint x16 =2N4
x∂y λintφint
The twelve gradient values Ni/∂x,Ni/∂y and 2Ni/∂x∂y (i= 1,...,4) are evaluated as follows:
N1
x =N2N16
2∆λint
N2
x =N9N1
2∆λint
N3
x =N10 N4
2∆λint
N4
x =N3N15
2∆λint
N1
y =N4N6
2∆φint
N2
y =N3N7
2∆φint
N3
y =N12 N2
2∆φint
N4
y =N13 N1
2∆φint
2N1
x∂y =N3N7N15 +N5
4∆λintφint
2N2
x∂y =N10 N8N4+N6
4∆λintφint
2N3
x∂y =N11 N9N13 +N1
4∆λintφint
2N4
x∂y =N12 N2N14 +N16
4∆λintφint
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
following pseudocode:
Np= 0
for i= 0 to 4do
Np=Npt+ai,4u+ai,3u+ai,2u+ai,1equation 5.11
end for
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 file:
geoid -p skye.dnaproj
No other options are required, as geoid will be invoked using the options and arguments contained
in the project file skye.dnaproj.
59
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 file:
geoid skye -g ausgeoid09.gsb
Upon executing geoid, the binary station file skye.bst and the header records from the NTv2 geoid
grid file ausgeoid09.gsb will be loaded into memory. For each station found in the binary station file,
geoid will attempt to interpolate the geoid–ellipsoid separations and the north–south and east–west
deflections of the vertical from the surrounding grid nodes. If the station lies outside the limits of
the geoid grid file, no information will be retrieved for that station. Once the information for all
stations has been interpolated, the binary station file and corresponding DynaNet project file will be
updated.
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 file 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.
60
+ Options:
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 file interpolation
5.5 Arbitrary interpolation and height transformation
In addition to introducing geoid information into an adjustment project, geoid offers two modes for
interpolating geoid information from a geoid grid file — interactive mode and text file mode. With
the latter, it is also possible to transform a file of heights from one height system (or vertical datum)
to another.
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 file option and file 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 deflections 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.
61
+ Options:
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
Deflections:
- Prime meridian = -4.41 seconds
- Prime vertical = -6.48 seconds
Figure 5.5: Interactive geoid grid file 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
option:
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
meridian) respectively.
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 file mode
Text file mode has been designed to provide an efficient means for (1) interpolating geoid information
for a list of coordinates and (2) transforming heights from one system to another using simple ASCII
text file formats. For these purposes, geoid supports Formatted Text files (e.g. *.dat,*.prn,*.txt)
and Comma Separated Values files (*.csv). Appendix B.7 provides the file format specification for
these file types.
To interpolate geoid information and transform a file of heights, type geoid on the command line,
followed by the NTv2 grid file option and file path, then --text-file (or its shortcut -t) with the
input text file path and, if required, options and arguments for interpolation method, coordinate
format and conversion direction. For example, to transform a file of heights in a file 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 file of heights, geoid will report to the screen the items relevant to the
text file transformation, the progress of interpolation and transformation of heights, and any errors or
warnings related to the file transformation. Figure 5.6 shows the information reported to the screen
upon normal program execution.
62
+ Options:
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 file transformation
During this process, geoid will attempt to determine the file type from the file extension and contents
of the input file. Any problems encountered with opening the input file will be reported to the screen.
The name of the output file will be the same as the input file name, but with a “_out” inserted
between the file name and the file extension. During the transformation process, geoid information
will be interpolated using the default or user–specified 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 deflections of the vertical ξand ηfor each point in
the file will be appended to the original record from the input file, which is in turn printed to the
output file. Since geoid is only concerned with heights, the input latitude and longitude are written
directly to the output file without any alteration.
In the case of an error, the input record prefixed by the string ’ERROR (#)’, where ’#’ is a number
indicating the type of error, will be printed to the output file. Typical examples of error include
instances when the coordinates cannot be read from the input file (possibly due to an incorrect
coordinate type or file record format), or if the coordinates lie outside the extents of the geoid grid
file. 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 file, geoid can export this
information to a DNA geoid file. Generating a DNA geoid file 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 file, 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 file mode (c.f.
§5.5.2):
geoid skye -g ausgeoid09.gsb --export-dna-geo-file
geoid -g ausgeoid09.gsb -t pipeline.txt --export-dna-geo-file
63
5.7 Working with NTv2 geoid grid files
5.7.1 Reporting NTv2 geoid grid file metadata
At times, it may be necessary to view a summary of the metadata contained within an NTv2 geoid
grid file. NTv2 grid file metadata is contained within an array of block header records, and provides
specific information relating to, for example, geoid grid file version, geoid and ellipsoid parameters,
grid file extents and grid node interval. To display the header information for a grid file, type geoid
on the command line, followed by the NTv2 grid file option and file 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.
+ Options:
Geoid grid file: ausgeoid09.gsb
Input coordinate format: Degrees minutes seconds
Grid properties for "ausgeoid09.gsb":
+ GS_TYPE = SECONDS
+ VERSION = 1.0.0.0
+ 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 file summary
In relation to Figure 5.7, Tables 5.1 and 5.2 describe the NTv2 grid file header fields and the individual
sub grid header fields.
64
Table 5.1: NTv2 grid file overview fields
Field Description
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 file. A grid file may contain several sub
grids of different 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 file 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 file sub grid fields
Field Description
SUB_NAME The name of this particular sub grid.
PARENT The parent sub grid name. NONE’ if this is the parent grid.
CREATED Grid file creation date
UPDATED Grid file modification 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 files
AUSGeoid09 has been publicly released in the form of ASCII text files using the legacy WINTER
DAT file format. Whilst serving as a simple, human–readable format, the WINTER DAT file format
is not designed to provide an efficient means for instantaneous interpolation. Accordingly, DynaNet
requires the geoid information contained in these files 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 file 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 files and the geoid model parameters. For example,
65
to create a new NTv2 binary grid file named geoid_model.gsb from geoid information stored in a
WINTER DAT file 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 files 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 sufficient number of nodes to construct an orthogonal
grid file. The parameters derived from the raw data will be written to the grid file header records
(c.f. Tables 5.1 and 5.2). Since the WINTER DAT file format contains data for a single grid, the
resultant NTv2 grid file will contain a single sub–grid which will be the parent grid.
To facilitate the capture of other metadata relating to the geoid grid file, geoid provides options
to specify the units for the deflections of the vertical (in radians or seconds), the grid file 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 2.5.0.0, 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 2.5.0.0 --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 deflections 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 file 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 file has been created, a summary of the grid file parameters (c.f. Figure 5.7) will
be displayed.
+ Options:
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 = 2.5.0.0
- SYSTEM_F = GDA94
- SYSTEM_T = AHD71
- ...
- ...
Figure 5.8: Progress of NTv2 grid file creation
66
5.7.3 Grid file interpolation errors
If an error occurs at any time during the geoid interpolation process, a non-zero value is printed to
the output file to indicate the type of error. Table 5.3 lists the errors that may be encountered upon
geoid grid file interpolation.
Table 5.3: Grid file interpolation error codes and descriptions
Code Description
-6 The NTv2 version of the specified grid file is not supported.
-5 The parameters for the specified grid file do not match the number of records.
-4 Could not allocate the required memory.
-3 A grid file has not been opened.
-2 Cannot locate the required sub grid.
1 The specified grid file could not be opened.
2 Cannot read this type of grid file.
3 or 14 Found an unrecoverable error in the specified grid file: <grid–file–name>
It is likely that this file was downloaded or produced incorrectly.
4 Could not read from the specified input file.
5 Could not write to the specified output file.
6 Cannot read this type of input file.
7 Cannot produce this type of output file.
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 specified zone is invalid.
13 or -1 The point <data–record> lies outside the extents of the specified grid file.
15 The interpolation shifts could not be retrieved from the ASCII grid file.
16 The interpolation shifts could not be retrieved from the Binary grid file.
17 The csv record <data–record> does not contain sufficient records.
67
68
Chapter 6
Network segmentation
6.1 Introduction
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,<