Remove bad GPS signals inside building

Question

I have a problem I can not solve, when the GPS data logger is inside a building, the units still reads data "with much noise". Thus, when the unit is kept static, it still reads data and the recorded points jump in a mad way. i.e., if I kept the unit for 2 hours on a desk. I will still record points that are distant from each other by e.g. 150 meter.

This is a problem to me as I want to make a program that calculates the total distance that the unit has moved. So, if I kept the unit fixed on the desk for 3 hours, the unit keeps recording many data points that are distant from each other by e.g. 150 meter. So, my program will read that the unit has moved for 20 KM during this period although it was not moving.

I have tried to filter the obtained data by HDOP, PDOP, VDOP, but it only removed 5% of bad data points. I tried to also filter data by the number of satellites that the gps logger reads, but this also did not identify all bad signals.

I know that there is no solution to prevent this error it is due to the technology itself as GPS is not designed to read inside buildings. My biggest problem is to remove these data points not to be calculated by my program. I know there may be some filters that work.

If you wish, I can attach an excel file having some data which are recorded inside building. My aim is only to make my program know what these points are so that I can remove them from my calculations. Please note that the speed, heading are zeros because I configured the device not to store these parameters, but If you need these data for filtering, I can send you the data.

Answer 1

We use data that's logged in cars, and we're not interested in position data that's collected when the phone is charging on somebody's desk. I think our approach will solve most of your problem.

I deal GPS noise as follows:

• To get rid of 90% of the useless noise, the logger stops logging when there's no movement (no measurement with a speed of more than 10km/h), or no signal for more than 3 minutes. That way we don't cut holes when somebody is waiting for a traffic light or at corners; During post-processing we'll remove the trailing noise if there was indeed no movement for a longer period.

• As soon as there's are 3 consecutive measurements with a speed of over 10 km/h, we assume that it's not just noise, and we store everything that we've buffered back until the first measurement with a speed < 2 km/h. That way, if a car slowly leaves, we still capture it driving away.

At this point we've filtered out 90% of the noise, but we're still left with minor noise when somebody stands still during trips. We deal with that as follows:

• If there's a short period without movement, all of the positions with a low speed are interpolated over a bezier curve between the last movement before standing still, and the first movement after standing still. The position, speed and heading are taken into count. A linear interpolation (or simply removing these measurements) will probably provide usable results with a smaller effort.

There are some extra heuristics to make sure that slow driving in traffic jams is not seen as GPS noise, by measuring both the traveled raw distance, and the distance between the first and the last position in the period.

This was all implemented for an assignment where an accuracy of 99% for distance calculation is required, so a lot more is involved. For example by matching to a map, planning routes to verify the matches, and to fill up gps in the signal in tunnels or when the signal was bad because of reflections, and by checking if the headings, positions and speeds of consecutive measurements match (you can always use any 2 of those to calculate the 3rd one). But this is basically what we do to filter out most of the GPS noise.

If you don't have to calculate stuff in real-time, you've got a great advantage that you can look "into the future", which makes it a lot easier to filter stuff.