Following the Taxiways
Dave Jesse on April 21, 2017

In this blog I will explain how we compute the ground track for visualisations and why this is undergoing a process of revision.

What the User Sees

When we process flight data we often show the flight on a chart or, most commonly these days, on Google Earth. It is easy to see where the flight went, and the Google Earth controls are intuitive, allowing us the ability to spin the plot around and zoom in and out without too much difficulty and certainly without any training.

Users view these plots and see the approach and departure tracks without taking too much bother over where the aircraft went, but as soon as it lands, the track is immediately compared with the runway and taxiways. An error of 100ft in the track at 5 miles to run is hard to identify, but an error of 100ft in the taxi phase is glaringly obvious.

If the data is used to drive a visualisation of the track, users are very sensitive to aircraft moving unnaturally. By this I mean moving backwards or sideways, especially when the aircraft should have been stationary. This is less of an issue when looking at Google Earth views, because there is no time-based display of the aircraft, but draw a Boeing 747 and move it sideways across the threshold and it really looks absurd.

What the Data Shows

We treat the position data as coming from a precise or imprecise source. That is, if the positional error is significantly greater than the resolution (e.g. for inertial reference navigation systems) we treat it as imprecise. The recorded track is then often so far away from the correct position that it is of little use other than to indicate where the airfield might be. We cannot use this data to locate the aircraft accurately on the airfield so we use various techniques to position the aircraft on the runway, either on the centreline or displaced according to the ILS signals for a landing. From that point on the best we can do is to use groundspeed and heading data and plot a graph using “dead reckoning”. This becomes progressively less accurate the further the aircraft taxis, but it’s the best we can do in these cases.

For aircraft with a precise recorded position, the resolution is still poor and plotting the unaltered track will look absurd. We therefore need to undertake some form of smoothing process to achieve these goals:

  1. Stationary aircraft should not move (the visualisation requirement)
  2. Aircraft following straight taxiways should move in a straight line
  3. Aircraft should start their taxi in at the position at the end of the landing, which may be refined by using the ILS localizer data.

The first item is easily achieved by taking periods of very low groundspeed and treating them as zero groundspeed. The current threshold for this is 1kt, as we don’t normally see an aircraft moving at less than 1kt for any significant period of time.

The second item is not as simple as it would seem. Any form of track smoothing that uses the recorded position data will suffer from jumps in some way or another. The worst case is for a long taxiway that is almost, but not exactly, North-South or East-West. Consider an almost Easterly taxiway. The longitude parameter increases nicely along the taxi, but at some point the latitude will make a 1-bit step change. This is typically 38m or 120ft (some aircraft record at a higher precision, so the step may be half, quarter or an eighth of this).



Image 1



You can blend this step over a long period, but no matter how gentle the correction is, looking along the line of the taxiway you will always get a movement that is related to the recording resolution step and not just the line the aircraft followed. For this reason we use groundspeed and heading as the basis for track computations, even where the recorded position is “precise”.

The third point is covered by initializing the track algorithm with the final point of the approach computation which uses the ILS localizer to provide accurate cross-runway position data.

Two Alternative Solutions

The problem with using integrated groundspeed and heading techniques is that over a long period they will, as all integration processes do, lose accuracy. Two alternative solutions have been used to solve this problem.


The Iterative Solution

The first solution, which has been in use for a couple of years now, was to fiddle the groundspeed during the straight sections of movement so that, when the aircraft had turned a corner, the next section of the track had a minimal cross-track error. Let me explain that again. Imagine we have North and then East taxiways, and that the groundspeed under-reads slightly. When you integrate the groundspeed along the North movement, the aircraft position will not travel quite as far as it should. Then when you turn to travel East, the computed track will be consistently South of the recorded position. If we speed up the initial movement North, the cross-track error on the easterly taxiway can be reduced. A minimization function can find the fiddle factor that will give the lowest cross-track error.

This solution can be expanded to allow us to adjust many straight legs of a taxi path and minimize many cross-track errors at the same time. It solution has the advantage of giving a very good solution when it works but the twin disadvantages of being spectacularly wrong and almost impossible to debug when it fails. I have in particular to apologize to some analysts at Cathay Pacific whose tracks had a habit of ending up in the water beyond the airfield in some cases where the iterative convergence algorithm had just failed to find a solution.

The Half-And-Half Solution

I have said earlier that we cannot use simple smoothing of taxi tracks because of the problem with steps in recorded ground track, especially on North-south or East-West taxiways. This visual problem does not apply to turns where a simple smoothing algorithm usually gives a fairly convincing answer. (Not always, but often enough for the rare and strange exceptions to be acceptable). This solution again splits the taxi movement into straight and curved sections. We then use the simple smoothed track for the curved sections and integrate the heading and groundspeed between the two curved sections to give a final answer.

“But”, I hear you cry “the integrated groundspeed and heading won’t join the dots”. Here is the integration from one red curved section of track shown in blue. You can see the mismatch at the end of the computation.


Image 2


Here is the integration starting from the other curved section and working backwards. Unsurprisingly the final error is the same but in the opposite sense.


Image 3


With a little mathematical trickery we blend the two together to obtain a final answer as below.


Image 4

On this example you may just be able to see a small difference between our blue track and the smoothed latitude and longitude track (the black line), but the error is minute and far less significant than the errors that would arise on a more difficult example.

This solution has the advantages of far lower computation overhead, simplicity to debug and (I hope) is easier to understand.

Here is the more complex track which was used to design the solution and from which some of the variable parameters were determined.



Image 5


The gate is at A on the easterly side of the chart, and here the odd spikes are where the latitude and longitude parameters start working. The longest straights are the runways. You can see where the smoothed latitude and longitude still has waves where the bit level changes arise, but the blue straight computations have corrected for this. The red curves are mostly satisfactory, except for one line near the centre of the diagram, B. A small gap in the blue trace at C is where the groundspeed was very low for some time and then started again. We leave the aircraft stationary at the last point where the groundspeed was above 1kt, then pick it up again where it exceeds 1kt, allowing for a jump as we don’t know exactly where the aircraft was during this period.

I am sure that in time we will find ways to improve this further, but the general improvement in speed and reliability of this algorithm over the earlier iterative solution is significant and it will go into service once we have gained enough confidence in the performance under differing circumstances.