The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences. Vol. XXXVII. Part B5. Beijing 2008 
improves the navigation for flight lines where a constant 
height over the topography is required. 
D. Flight Plan management: Different flight plans and flight 
lines can be loaded and activated. The line attributes (such 
as height, required speed over ground or sensor head 
attitude) can be displayed for each line. 
E. Laver control: GIS-like control to display or deactivate 
different data layers. 
F. Online/offline button: Control button to switch between 
online mode (RT georeferencing, display of RT swath 
boundary) and offline mode (data coverage analysis, 
transmission of data extend and data gaps to HELIPOS 
(see section 5). 
7. DISCUSSION OF RESULTS 
The described software modules have been tested on several 
flights in the period of January to April 2008. In this section we 
will discuss some of the results comparing the real-time 
solutions (trajectory and raw point-cloud) and indicators to that 
of post-processing. 
7.1 Trajectory 
Differvnc* in Tra|«ctory determination (RT - Postprocessing) 
01 Poll l Pitch 
8«! 
Yaw 
oaf 
PXcrt mean 0 00". stt) 0 0T 
■> 0X»'}rn 0M‘ 
1755 3 7« 3 795 
Figure 9: Difference in the computed position, attitude and 
velocity between the RT solution using point 
positioning and post-processed solution using CP- 
DGPS. 
Figure 9 shows the difference in trajectory estimation (position, 
attitude and velocity) between the RT solution using point 
positioning (computed by GIINAV) and the post-processed 
results based on differential carrier-phase (computed by 
GrafNav/PosProc) for a flight by helicopter in the region of 
Lausanne (Switzerland). The plot depicts that the difference in 
attitude is low (roll /pitch: RMS < 0.05°, yaw: RMS <0.1°) and 
close to the noise of the used IMU (Litton LN-200), whereas 
the difference in absolute position is more important (RMS 
planimetry > 1.5m, RMS altimetry > 4m). These results are not 
surprising, considering that neither DGPS nor RTK (Real-time 
Kinematics) were used for the RT solution. The correspondence 
in velocities is much better due to the influence of the IMU 
data. 
7.2 Laser point-cloud 
For the in-flight quality assessment of the ALS data mainly the 
accuracy and the completeness of the georeferenced point-cloud 
is of interest. The histograms in Figure 10 depict the 
distribution of the point-cloud coordinate differences (RT point 
positioning GPS/INS versus reference trajectory). As proven by 
forward covariance propagation (Glennie, 2006; Landtwing, 
2005), the errors in position propagate directly into the 
georeferenced point. Accordingly, the east and north 
components are similar (RMS « 1.5 m) to the position errors in 
the trajectory (Figure 9). The RMS of the height component is 
about 2-3 times worse. But again, corresponds well to that of 
point-positioning accuracy in the vertical channel. In this 
particular flight the height over ground was approximately 
250m. Thus, the angular discrepancies had a minor impact on 
the final georeferencing quality (roll/pitch: 0.05° at 250m « 0.2 
m). Hence, up to 1000 meters flying height a 2D point-cloud 
accuracy below 3m can be achieved without differential 
techniques. For the purposes of in-flight monitoring displaying 
the swath and the computation of data coverage, this accuracy 
is largely sufficient. 
Difference in pointcloud coordinates (RT - Postprocessing) 
met®« 
t«»t: m*an 0.9m aid 0.9m Nortti: mean 0.8m atd 1.0m Op: mean -2.0m aid 2.3m 
Figure 10: Histograms of difference in point-cloud coordinates 
computed in real-time and in post-processing (based 
on 3.7 Mio samples) 
As the relative accuracy of the laser point-cloud is not affected 
by the positioning accuracy, the integrity of the results of LI AN 
can be guaranteed even in point-positioning mode. Comparing 
the data extends and data gaps computed using the RT and the 
post-processed point-cloud indicated no substantial differences. 
All data gaps were identified correctly, and the identified 
boundaries (in 2D) corresponded to the accuracy for the single 
laser point (i.e. RMS «1.5 m). 
7.3 System Performances 
The testing in several survey missions was also very 
informative about the achievable system performances in terms 
of manageable data rates and CPU load. To separate the vital 
and extended elements physically from each other, the 
computing was divided on two field laptops: 
• LOG-PC: linked to hardware (GPS/IMU/LiDAR) through 
Ethernet and running the GPS Datalogger, ALS 
Datalogger and IMU Datalogger modules. 
• NAV-PC: Linked to LOG-PC through Ethernet and 
running the LIEOS, GIINAV and HELIPOS modules. 
On the LOG-PC the CPU consumption was very low with peaks 
not passing 10%. Even tough data thinning of the raw ALS data 
can be enabled, we tested LIEOS at the full data rate of the 
employed laser (lO’OOO points/second). Trajectory computation 
by GIINAV was performed at 400 Hz, whereas trajectory 
information (position, attitude and velocity) was transmitted at 
1Hz to HELIPOS. The swath boundaries were also updated at 
1Hz. Running only the georeferencing and naviagtion modules 
occupied the CPU of the NAV-PC with less than 5%. The most