intelligent positioning (gis-gps unification) || gps accuracy estimation using map-matching...

8GPS Accuracy Estimation Using

Map-Matching Techniques:Application to Vehicle Positioning

and Odometer Calibration

This chapter describes the further development of the test-bed application in Chap-ters 5 and 6, called Map-Matched GPS (MMGPS) that processes raw GPS outputdata from RINEX files or GPS-derived coordinates. This developed method usesGPS point positioning, which is map matched to locate the vehicle on a road centre-line when GPS is known to be sufficiently accurate. MMGPS software has now been adapted to incorporate positioning based on odometer-derived distances(OMMGPS), when GPS positions are not available. Relative GPS positions are usedto calibrate the odometer. If a GPS position is detected to be inaccurate, it is not usedfor positioning, or for calibrating the odometer correction factor. In OMMGPS, GPSpseudorange observations are combined with DTM height information and odome-ter positions to provide a vehicle position at 1-second epochs. The described experi-ment used GPS and odometer observations taken on a London bus on a pre-definedroute in central London. Therefore, map-matching techniques are used to test GPSpositioning accuracy, and to identify grossly inaccurate GPS positions. In total, over15,000 vehicle positions were computed and tested using OMMGPS.

In general, the position quality provided by GPS alone was extremely poor, dueto multipath effects caused by the urban canyons of central London, so that odome-ter positioning was used much more often to position the vehicle than GPS. Typi-cally, the ratio is 7 : 3 odometer positions to GPS positions. In the case of oneparticular trip, OMMGPS provides a mean error of position of 8.8m compared with53.7m for raw GPS alone.

Intelligent Positioning: GIS-GPS Unication G. Taylor and G. Blewitt© 2006 John Wiley & Sons, Ltd ISBN: 0-470-85003-5

1. Introduction

Global navigation satellite systems (GNSS), such as GPS, have been increasinglyused in real-time tracking of vehicles. Especially when GPS is integrated withincreasingly powerful geographic information system (GIS) technologies, theaccuracy and reliability of low-cost stand-alone GPS receivers can be signifi-cantly improved to meet the technical requirements of various transportationapplications of GPS, such as vehicle navigation, fleet management, route track-ing, vehicle arrival/schedule information systems (bus/train) and on-demandtravel information.With the autonomous European Satellite Navigations SystemGalileo, expected in 2008, an opportunity of a joint system ‘GPS + Galileo’ withmore than 50 satellites will provide many advantages for civil users, in terms ofavailability, reliability and accuracy. However, severe multipath effects will con-tinue to be a problem in dense urban areas.

To date, there have been many attempts to improve the reliability of vehiclepositioning through the fusion of observations obtained by the integration ofvarious positioning and navigation instruments. The vast majority of suchsystems use a GNSS, for absolute positioning, and a variety of other sensors toprovide relative positioning. The usual model is to use GPS to position a vehiclewhenever possible together with some form of inertial navigation system (INS)or dead reckoning (DR) system, such as odometer, gyro and compass, to deter-mine a vehicle’s position relative to an initial position.

Kealy et al. [1999] and Ramjattan and Cross [1995] describe a typical solution,integrating GNSS and DR using a Kalman filtering technique. In this experimenta test route for the system was established in the centre of Perth, Western Aus-tralia. The results of this work found that ‘DGPS/DR solution starts to degradefrom 1m to errors as much as 35m by the end of a 10 minute period’ [Kealy etal., 1999]. Kalman filtering techniques do have an inherent problem, for vehiclenavigation, on road networks, ‘in terms of stability, computational load, immu-nity from noise effects and observability’ [Chiang et al., 2002]. The performanceof the filter is heavily dependent on the models used. The model used is a com-promise between a statistical predictive dynamic model and the measurement(observation) model. If too much weight is given to the dynamic model, an overlysmooth track is the result, i.e. rapid changes of direction are not recognizedquickly enough. If too much weight is given to the measurement model, errorswould be construed as sharp changes in direction. Devising the correct model isvery difficult, and without a very good model a Kalman filter will deliver thewrong result. Other accounts of using a Kalman filter for multi-sensor vehiclenavigation are given by Stephen and Lachapelle [2000], who use GPS and lowcost gyro, by Petrovello et al. [2003], who provide an informative discussion onlevels of integration, and also by Mezentsev et al. [2002]. Hailes [1999] usesKalman filtering with map matching.

Fei et al. [2000] describe fuzzy logic techniques as an alternative to Kalmanfiltering for GPS/INS integration. Furthermore, Mayhew and Kachroo [1998]compare solutions using various configurations of GPS, steering position,

150 Intelligent Positioning

odometer, gyroscope, forward accelerometer and map-matching, with sensorfusion methods Kalman filtering, rule-based and fuzzy logic. Chiang et al. [2002]developed a GPS/INS multi-sensor navigation system that utilizes an artificialneural network (ANN) as another alternative to Kalman filtering. Wise-McLainand Murphy [1993] describe GPS and a DR system for tracking.

Over the past four years a group of researchers from the GIS Research Centre,School of Computing, University of Glamorgan, have designed, developed andimplemented a software application package for researching algorithms andtechniques to improve GPS based on map matching for navigation and track-ing. This test-bed application, called Map-Matched GPS (MMGPS) processesraw GPS output data, from RINEX files, or GPS-derived coordinates. It provideslinkage to a GIS for access and analysis of appropriate spatial and related attrib-ute data (primarily road and height information). MMGPS identifies the correctroad, on which a vehicle is travelling, and snaps the vehicle position onto thatroad. Furthermore, MMGPS corrects the derived position using its own com-puted correction parameters, e.g. Correction Dilution of Precision (CDOP) usingthe history of previous position estimates and road geometry [Blewitt and Taylor,2002].Various research experiments utilizing MMGPS have been conducted andresults have been fully described in Taylor et al. [2001a].

The main objectives of the research described in this chapter are to determineboth the accuracy and reliability of position of a public transport bus that canbe provided using a combination of GPS, odometer and map matching tech-niques. To this end, a new algorithm has been developed that integrates odome-ter observations with the existing software, now called OMMGPS. In OMMGPS,height information obtained from digital terrain models (DTM) are used todetermined 3D GPS point positions, when only three GPS satellites are visibleto the receiver. More importantly, height aiding improves the accuracy of GPSpoint positions with poor satellite geometry (high PDOP), and when severe multipath occurs (multiple reflected GPS satellite signals).

The developed method uses absolute GPS positioning, map matched, to locatethe vehicle on a road centre-line, when GPS is known to be sufficiently accurate.When this is not the case, odometer readings are used to locate the vehicle on aroad centre-line. The odometer is calibrated using relative GPS positions, basedon map-matching criteria, such as the residuals of CDOP, for GPS precisiondetermination (see also Section 2). The accuracy of OMMGPS is a function ofthe frequency of accurate GPS points, reliable map matching and correct odome-ter calibration.

Standard Ordnance Survey (OS) digital plan and height map products wereused for road map matching and height aiding. A number of trips along a busroute in central London – Baker Street, Oxford Street, etc. – were made to testthe method. A typical result of map-matched GPS positioning is shown in Figure 8.1.

The innovative feature of this particular implementation is that map match-ing is actually used for GPS accuracy determination rather than to identify thecorrect road the bus is driving on.This is achievable, since pre-defined bus routes

GPS Accuracy Estimation Using Map-Matching 151

are involved, hence the correct road is always known. The trajectory of asequence of GPS point positions is compared with an identified part of the busroute, using the map-matching techniques described in this chapter. If this com-parison meets the map-matching criteria, described below, the points are usedfor odometer calibration and bus positioning. Otherwise, they are discarded.

2. Methodology

The general approach was to use GPS to position the vehicle, and also to calibrate the odometer readings, but only if GPS was available and of sufficientaccuracy. At all other times odometer readings were used to position the bus.Odometer positioning was achieved by tracing the distance measured by theodometer along the bus route road centre-line – actually, a 5m offset center-linewas used, left of direction of travel, see Figure 8.1. Map-matching techniques areused to improve the GPS positioning accuracy, and to identify grossly inaccurateGPS positions. The previous 10 GPS/odometer positions are used for map-matching calculations.

3. Map Matching

The existing MMGPS software has been adapted to incorporate positioningbased on odometer-derived distances, when GPS positions are not available.Thisnew version of map-matching software, OMMGPS, works in the following way:


N

MMGPS

London

Uncorrected GPSOsnames.shpRoute2a_offset.shpWater_polyline.shpRoad_polyline.shpRail_polyline.shpNames_text.shpGeneral_polyline.shpFence_polyline.shpBuilding_polyline.shpBoundary_polyline.shp

Miles0.180.090.09 0S

W E

Figure 8.1 Map-matched GPS positioning with OMMGPS

1 A GPS observation is read from the GPS RINEX file, and an odometer countis read from the odometer file.

2 A Raw vehicle position is computed using all satellites visible to the receiver,above a 15 degrees elevation mask, plus height aiding, where height is obtainedfrom a DTM. This height is interpolated (bilinear) at the vehicle’s previousreference (Ref) position, i.e. snapped on the road centre-line [Li et al., 2003].This DTM-derived height of the receiver is used to provide an extra equationin the least squares pseudorange computation of GPS coordinates, i.e. com-putation with a minimum of three satellites is possible. For each epoch (instanttime of observation) GPS points within 100m of the road centre-line are considered.

3 An odometer correction is calibrated using odometer count at the currentepoch and relative GPS distance travelled. Only if the GPS position is usable,otherwise this step is skipped for this epoch.

4 Road geometry based on DGPS corrections (from step 9, previous epoch) isadded to the Raw position to give a corrected (Cor) position.

5 This Cor position is now snapped to the nearest point on the nearest road-centre line to give the current Ref position, and then a DTM height is calcu-lated. That is, a Ref position is available that can be used to generate roadgeometry based on DGPS corrections for use with the next epoch’s computedRaw position. The resultant Ref positions are checked for correctness usingtests against map-matching criteria [Taylor and Blewitt, 1999, 2000; Taylor et al., 2001a]; see below.

6 The odometer position is calculated, using previous Ref position, as well asthe odometer distance.

7 A position error vector is estimated in a formal least squares procedure, inwhich the Correction Dilution of Precision (CDOP) is computed. This esti-mate is a map matched correction that provides an autonomous alternative toDGPS, fully described in Chapter 6 and in Blewitt and Taylor [2002].The resid-uals of this process are used to determine the goodness of fit of the positionerror vector.

8 Position error vector (step 7) is used to adjust the Ref position used for step9. This provides a long-track correction, especially when CDOP is low (rapidchange of road direction).

9 DGPS corrections for each satellite pseudorange are computed using thecurrent Ref position. These are retained for future use.

The main map-matching criteria for snapping a Raw GPS position to a roadcentre-line Ref GPS position are each of the following, which have to be belowa set maximum value:

• Distance error (absolute value of the difference between Raw distance andRef distance, between the current and previous epochs);

• Bearing error (absolute value of the difference between Raw bearing and Refbearing, between the current and previous epochs);


• Residuals of CDOP;• Maximum distance of Raw GPS position from the road centre-line.

The number of satellites visible to the receiver has to be the same for currentand previous epochs.

If a Ref GPS position passes the check, it is used for positioning the bus andcalibrating the odometer correction factor. Otherwise, the position of the bus isderived from the calibrated odometer distance, and the odometer calibrationcorrection factor is not updated.The values used for map matching are obviouslyopen to adjustment and tuning, for different road geometry and environmentalscenarios.

4. Distance Correction Factor

The previous section assumes that distances obtained from odometer readingsare multiplied by a correction factor C, so that the distance supplied toOMMGPS is actually Cd rather than just d. It is not reasonable to assume C isfixed, as different roads and, indeed, different road conditions on the same roadwill influence C. For this reason, when GPS and odometer signals are both avail-able, C will be calibrated over a time window by comparing distances travelled,based on odometer readings with those estimated from GPS (i.e. relative dis-tances between two GPS points). If GPS goes offline, the value of C obtainedjust before the GPS signal is lost (or regarded as unreliable) is used togetherwith the odometer method to estimate location, i.e. the current odometer posi-tion is calculated based on the previous GPS or odometer position, and thecurrent odometer reading is multiplied by the correction factor C.

5. Estimating C

C can be regarded as a correction factor between odometer-based distance esti-mates as used above, and those obtained from the GPS-based method. At eachsecond t, an odometer distance dt and GPS-based coordinate estimates (Xt,Yt,Zt)are obtained. Here, it is assumed dt is a cumulative variable, so that the distancetravelled between t − 1 and t is dt − dt−1. This is called ∆d. Also, from the GPSmeasurements the cumulative distance travelled can be computed usingOMMGPS. These distances are called Dt. Similar to the odometer distances, ∆Dis defined as Dt − Dt−1. Thus, a model of the relationship between ∆d and ∆D is:

∆Di = C∆di + error

This model can be calibrated by estimating C using least squares techniques, i.e.C is chosen to minimize the expression:

∆ ∆D C di ii

−( )∑ 2


It may be verified that, in this case, the estimate for C is:

However, this assumes that C is a constant correction factor. In reality, C is likelyto change, depending on traffic conditions, such as road shape, weather, and soon. A more realistic model allows C to vary with time, so that at each time t adistinct Ct is obtained. One approach in this situation is to estimate C accordingto the same model, i.e. using a ‘moving window’ least squares estimate. At eachtime t, only the values for ∆Di and ∆di are considered in a time window of kseconds, i.e. only data from times t − k,t − k + 1, . . . , t. At time t + 1, data isdropped for time t − k and added for time t + 1. Also, a weighting scheme is usedin the least squares method, so that the squared errors for data close to t havea higher weighting. This gives an estimation method, which places more empha-sis on minimizing errors close to time t. In this case, the least squares expressionto be minimized is:

where wi is the weight placed on the error at lag i seconds before time t. In thiscase, Ct is:

5.1. Weighting Scheme for wi

Some thought should be given to the weighting scheme for the wis. Obviously, atime-decay effect is expected, so that w0 > w1 > . . . > wk. One possibility is tochoose an exponential fall-off up to wk, so that wk = g k could be chosen, assum-ing g < 1. Note that w0 = 1 can be fixed without loss of generality. In order toobtain the best performance of the tracking algorithm as a whole, it may beexperimented with different values of k and g . Thus, the estimate for Ct may bewritten as:

5.2. Implementing the Correction Factor Algorithm

The estimate of Ct needs to be updated each second, where the odometer readingis reliable and the GPS position is available. Providing the GPS is available for

CD d

dt

it i t i

i ki

t ii k

=− −

=

−=

∑∑g

g

∆ ∆

∆0

2

0

...

...

Cw D d

w dt

i t i t ii k

i t ii k

=− −

=

−=

∑∑

∆ ∆

∆0

2

0

...

...

w D C dii k

t i t t i=

− −∑ −( )0

2

...

∆ ∆

CD d

d

i ii

ii

=∑∑∆ ∆

∆ 2


k seconds, it may be worked with an iteratively updated ‘moving window’ esti-mate. Now, Ct may be written:

where:

If a record of the last k values of ∆dt and ∆Dt is available, sum1 and sum2 maybe updated at each second, as well as the estimate Ct. This can be seen in:

sum1t = g sum1t−1 + ∆dt∆Dt − g k+1∆dt−k∆Dt−k

sum2t = g sum2t−1 + ∆dt2 − g k+1∆d2

t−k

Since the algorithm requires only the values of ∆D and ∆d at times t and t − kbut not those in between, a ‘first in first out’ (FIFO) of size k + 1 is a usefulmethod of handling the information. Unlike the more usual ‘last in first out’(LIFO) stack, popping a value from the stack returns the oldest item on the stackrather than the newest. Thus, at each second, the current values of ∆dt and ∆Dt

are computed and pushed onto a FIFO stack. For the first k seconds GPS datais online, no values are popped from the stack. However, after k seconds, valuesof ∆d and ∆D are also popped from the stack. Since the oldest values are poppedfrom the stack, and the stack has had items pushed on to it for k seconds, itimplies that ∆dt−k and ∆Dt−k will be popped.

6. Calibration if GPS Data Is Recently Online

In the previous section, the method for estimating Ct is used when GPS data isavailable. If the GPS data is offline, the calibration of Ct cannot take place. Theprevious section assumed that GPS data is online for a sufficient period of time,so that at least k observations are pushed onto the stack, as well as the suppliedGPS positions ‘settled’ and are reliable. Thus, there is a ‘run-in’ period of lseconds, where the methods in the previous section cannot be applied. Clearly,l cannot be less than k, but a much larger value may be required. This is to bedetermined by experiment.

How Ct should be estimated in this l-second time interval, and how the posi-tion should be estimated? One possibility is to work initially with a global esti-mate of C to provide the odometer-based estimate. As time during the burn-inperiod passes, the estimate should ‘drift’. This can be done by combining Ct andC using a weighted average, with the weighting gradually favouring Ct ratherthan C. The trial method here uses the formula:

C′t = r jC + (1 − r j)Ct

sum D d

sum d

ti

t i t ii k

ti

t ii k

1

20

2

0

=

=

− −=

−=

∑∑

g

g

∆ ∆

∆...

...

Csumsum

tt

t

= 12


where j is the time into the run-in period, and C′t is the ‘combined’ estimate ofthe correction factor, assuming 0 < r < 1.

Finally, sum1 and sum2 need to be ‘rebuilt’ in the first k seconds of this period.That is, for times up to k seconds, the current ∆Dt and ∆dt need to be includedinto the running mean computation, but ∆Dt−k and ∆dt−k are not being dropped.Here, it may be written as:

The estimate of the global C is updated on an ongoing basis when GPS andodometer data are available. It can be noted that:

where gsum1t and gsum2t may be updated each second, since:

It may be sensible to scale gsum1t and gsum2t to avoid rounding errors, forexample, we could use a running mean computation such as:

At any time both sums are reduced by a factor n, where n is the number of timesthe updating algorithm is called. This has no effect on the estimate of C as thenumerator and denominator are scaled by the same factor, but it stops them frombecoming very large, leading to overflow errors.

7. Putting It All Together

The above algorithms are used on an event-driven basis. Each time a new set ofobservations is provided, one of three conditions applies:

• GPS and odometer data both available, not during run-in period.• GPS and odometer data both available, during run-in period.• Odometer data only available.

The set of actions to be taken in each case are outlined in the algorithms listedin the Appendix.

gsumn

ngsum

nD d

gsumn

ngsum

nd

t t t t

t t t

11

11

21

21

1

12

= − +

= − +

−

−

∆ ∆

∆

gsum gsum D d

gsum gsum dt t t t

t t t

1 1

2 21

12

= += +

−

−

∆ ∆∆

Cgsumgsum

t

t

= 12

sum sum d D

sum sum dt t t t

t t t

1 1

2 21

12

= += +

−

−

gg

∆ ∆∆


8. Alterations to the Correction Factor Algorithm

After the algorithms, described in the previous sections, were implemented,experiments took place in which the algorithms were applied to test data. Onthe basis of this a number of adjustments were made. In particular, it was foundthat on occasions the GPS signal was only available for very short periods oftime. This occurred either due to a lack of positions provided by the GPS, orbecause the GPS position provided was rejected as unreliable.As a result of this,there were situations when a GPS location was available for 2 or 3 seconds, thenunavailable for a similar length of time, and so on. This led to a problem withalgorithm 6 in the Appendix A. Essentially, each time the GPS signal was avail-able the stack was reset, as were sum1, sum2 and j, effectively ‘forgetting’ thevalue of Ct prior to GPS signal cut-out. An associated difficulty was that, if therun-in period was longer than 2 or 3 seconds, Ct was never being properlyupdated during these periods of intermittent GPS availability.

This led to a problem, since either the run-in period had to be very short, asdid the size of the stack, or very out-of-date values of Ct were used. Neitheroption was acceptable. In the first instance, Ct was under-smoothed, leading toerratic odometer based estimates (i.e. a lack of precision) – in the second case,Ct does not vary wildly but is biased, since much of the time values closer to theglobal C would be supplied – this led to a lack of accuracy.

To overcome this problem, it was noted that GPS cut-outs were never verylong, so that calibration of Ct prior to the cut-out would still provide useful infor-mation. To this end, algorithm 6 was modified so that the resetting of the stackdid not occur when a GPS location became available. The modified algorithm islisted in the Appendix. Experimentation indicated better performance. For thetraining data, a run in a period of 10 seconds was found, as well as a stack sizeof 10 – together with g = 0.8 the best performance was achieved, in terms ofoffset error to beacons (for detailed discussion of the methodology see Section11). It was also found at a later stage that a policy of always returning the odometer-based location estimate (even when GPS was available) improved the accuracy of predictions – this is also reflected in the modified version of algorithm 6.

9. Height Aiding

In OMMGPS height aiding is used throughout to add an extra equation in theleast squares approximation computation of GPS position. Height informationobtained, using bilinear interpolation, from a digital terrain model (DTM) isused to achieve 3D GPS point positions, when only three GPS satellites arevisible to the receiver.

More importantly, height aiding improves the accuracy of GPS point positionswith poor satellite geometry (high PDOD), and when severe signal multipathingoccurs (multiple reflected GPS satellite signals). The number of GPS positions


computed is nearly always increased by using additional height information, dis-played in Table 8.1. Trip 3.4 is the exception.

10. Implementation

OMMGPS consists of a Dynamic Link Library (DLL), written in C++, togetherwith a GUI for use in ESRI’s GIS products ArcView or ArcGIS. The GUI wasoriginally written in ArcView’s Avenue and has recently been translated toVisual Basic for use in ArcGIS [Steup and Taylor, 2003]. The GIS is used to visualize the results graphically, using background OS mapping.

11. Data Processing and Results

A number of separate trips along a bus route in central London (Baker Street,Oxford Street, etc.) were made to test the method. During each of these trips,GPS observations using low cost GPS L1 receivers and odometer observationsusing existing mechanical odometers were taken at each second, on the bus. Intotal, over 15,000 vehicle positions were computed using OMMGPS. Also, oneach trip, the bus recorded the time when it detected a beacon at the beacon’sknown location, actually to a normal intersect with a five metre offset centre-line, see Figure 8.2.

The positions of the bus at these times were used as the ‘true’ position of thebus. There are altogether 13 beacons on the bus route, which are used for deter-mining OMMGPS accuracy. Using this data the exact equivalent OMMGPSpositions used to calculate distances were obtained by interpolation, applyingthe OMMGPS positions at the nearest second before and after the beacon detec-tion time. This is simple linear interpolation.

A bus position was available at each second, either computed by GPS orodometer observations. For the whole route, odometer positions are used muchmore than GPS positions: 70% odometer positions, 30% GPS positions. For thecalculation of OMMGPS, position at beacon detection time for the 13 beaconsused; four positions were calculated using only GPS, and nine positions were cal-culated using only odometer. The results obtained for trip 4 are presented inTable 8.2. This bus trip is the one on which the algorithm was developed and


Table 8.1 Number of GPS positions computed

Trip no. GPS only GPS + Height Aiding

3.4 3834 38344 3468 36356 3320 39919.2 3713 4014

tuned, and it shows the excellent potential of the method.The results of the otherthree trips processed, i.e. trip 3.4, 9.2 and 6, are shown in Table 8.3.

There is a substantial improvement in the accuracy of bus position usingOMMGPS instead of only raw GPS. In the case of trip 4, OMMGPS provides amean error of 8.8 metres compared with 53.7 metres for raw GPS withoutodometer.


Beacon

noitisoP suB

tesffo fo noitcesretnI

lamron dna etuorsub

nocaeb morf

15º 15º

Beacon

noitisoP suB

tesffo fo noitcesretnI

lamron dna etuorsub

nocaeb morf

15º 15º

Figure 8.2 Beacon detection

Table 8.3 Average errors for all trips

95% cut offTrip no GPS only OMMGPS OMMGPS

3.4 27.9m 11.3m 6.6m4 53.7m 8.8m 5.2m6 >100m 28.3m 14.1m9.2 40.7m 22.8m 14.4m

Table 8.2 OMMGPS statistics for all beacons – for 95%– trip 4

Error for 100% Error for 95%

Mean 8.8m 5.2mStandard Deviation 6.6m 3.6mRange 18.7m 11.2mMinimum 0.9m 0.9mMaximum 19.6m 12.2m

12. Conclusion

A new algorithm that integrates odometer observations with the existingMMGPS map-matching software was developed and successfully implemented.This new algorithm, called OMMGPS, utilizes map-matching criteria, not todetermine which road a vehicle is on, but to determine GPS position precision,in order to calibrate an odometer with the help of GPS. In OMMGPS, GPSpseudorange observations are combined with odometer positions and DTMheight information to provide a vehicle position at 1-second epochs. Generally,odometer positioning is used much more often to position the vehicle than GPS.Typically, the ratio is 7 : 3 odometer positions to GPS positions.This predominantuse of odometer positioning is due either to GPS not being available or GPSpositions being considered to be too inaccurate to use. This lack of GPS posi-tions is due to satellite masking by buildings or the result of severe GPS signalmultipath in the urban canyons of central London.

Four bus trips along the same bus route were used to test OMMGPS. Theresults obtained from these four trips are most encouraging. In total, over 15,000vehicle positions were computed using OMMGPS. The positions provided byOMMGPS at the time of beacon detection can be considered to be a randomsample of the accuracy provided by OMMGPS, compared to the accuracy pro-vided by GPS alone, that is, if a GPS position was available at all, on or near thebeacon detection time.The average error of OMMGPS positions, over all vehiclepositions, using the random sample of beacon detection times, is 17.8 metresoverall, and 10.1 metres for a 95% cut-off. This compares with an average errorfor GPS alone of at least 55.6 metres overall.

Moreover, the effectiveness of OMMGPS is entirely dependent on the fre-quency and accuracy of GPS-derived positions. The GPS data provided fortesting compared very poorly with similar raw L1 pseudorange GPS data col-lected independently along the same bus routes, albeit using a much more expen-sive receiver and antenna for the independent test observations. Similarly,receiver coordinates collected using another low cost L1 GPS receiver also pro-vided improved positions, although this was most probably due to smoothingprovided by this particular receiver’s own navigation filter.

In conclusion, the technique developed in OMMGPS works well, and can befurther improved with more superior low cost GPS receiver technology or amore careful attention to its operational application. Due to the fact that themethod is based on known routes, it is not only appropriate for bus positioningbut also for use on the railways.


intelligent positioning (gis-gps unification) || gps accuracy estimation using map-matching...

Documents