![]() ![]() ![]() Re: Glitch/inconsistency detection in navigation d...
| Martin Eisenber... | 06-26-2006 |
![]() ![]() ![]() Re: Glitch/inconsistency detection in navigation d...
| Martin Eisenber... | 06-26-2006 |
![]() Re: Glitch/inconsistency detection in navigation d...
| =?ISO-8859-1?Q?... | 06-26-2006 |
![]() ![]() Re: Glitch/inconsistency detection in navigation d...
| Steve Underwood | 06-27-2006 |
![]() ![]() Re: Glitch/inconsistency detection in navigation d...
| Steve Underwood | 06-28-2006 |
![]() Re: Glitch/inconsistency detection in navigation d...
| Steve Underwood | 06-27-2006 |
If you were Registered and logged in, you could reply and use other advanced thread options
Hi folks.
Assume you are given som 20,000 - 100,000 points of raw (x,y,z)
navigation data as previously logged on some platform, and are asked
to clean up the data.
My first, naive idea is to use some Kalman filter. So far so good.
However, the data might contain glitches (jumps) or other
inconsistencies
that need to be sorted out before feeding them to the Kalman filter.
How would you go about detecting glitches and maybe even do a
first-pass correction of such data? A manual check of 100,000 data
points doesn't seem as a very tempting prospect...
Rune
viestissä:1151317297.168309.116350@m73g2000cwd.googlegroups.com...
I don't know about the systems to exclude irregularities, I doubt if there
are any without some presumptions, e.g. maximum distance between two
consecutive points etc. I will stay tuned to here about such methods.
However, if you after getting rid of the exceptions (errors in data) want to
reduce the number of points in your navigation data, you could apply my
freeware GeoConv. With GeoConv you can reduce the number of points in your
navigation data still maintaining the shape of the track as close to the
original track as possible.
GeoConv: http://www.kolumbus.fi/eino.uikkanen/geoconvgb/index.htm
Eino Uikkanen
http://www.kolumbus.fi/eino.uikkanen/gb/index.htm
Eino Uikkanen wrote:
> viestiss=E4:1151317297.168309.116350@m73g2000cwd.googlegroups.com...
> > Hi folks.
> > Assume you are given som 20,000 - 100,000 points of raw (x,y,z)
> > navigation data as previously logged on some platform, and are asked
> > to clean up the data.
> > My first, naive idea is to use some Kalman filter. So far so good.
> > However, the data might contain glitches (jumps) or other
> > inconsistencies
> > that need to be sorted out before feeding them to the Kalman filter.
> > How would you go about detecting glitches and maybe even do a
> > first-pass correction of such data? A manual check of 100,000 data
> > points doesn't seem as a very tempting prospect...
> > Rune
> > Assume you are given som 20,000 - 100,000 points of raw (x,y,z)
> > navigation data as previously logged on some platform, and are asked
> > to clean up the data.
> > My first, naive idea is to use some Kalman filter. So far so good.
> > However, the data might contain glitches (jumps) or other
> > inconsistencies
> > that need to be sorted out before feeding them to the Kalman filter.
> > How would you go about detecting glitches and maybe even do a
> > first-pass correction of such data? A manual check of 100,000 data
> > points doesn't seem as a very tempting prospect...
> > Rune
> I don't know about the systems to exclude irregularities, I doubt if there
> are any without some presumptions, e.g. maximum distance between two
> consecutive points etc. I will stay tuned to here about such methods.
> However, if you after getting rid of the exceptions (errors in data) want=
to
> are any without some presumptions, e.g. maximum distance between two
> consecutive points etc. I will stay tuned to here about such methods.
> However, if you after getting rid of the exceptions (errors in data) want=
> reduce the number of points in your navigation data, you could apply my
> freeware GeoConv. With GeoConv you can reduce the number of points in your
> navigation data still maintaining the shape of the track as close to the
> original track as possible.
> GeoConv: http://www.kolumbus.fi/eino.uikkanen/geoconvgb/index.htm
> Eino Uikkanen
> http://www.kolumbus.fi/eino.uikkanen/gb/index.htm
> freeware GeoConv. With GeoConv you can reduce the number of points in your
> navigation data still maintaining the shape of the track as close to the
> original track as possible.
> GeoConv: http://www.kolumbus.fi/eino.uikkanen/geoconvgb/index.htm
> Eino Uikkanen
> http://www.kolumbus.fi/eino.uikkanen/gb/index.htm
Thanks. I'll have a look at it.
Rune
Eliminating "stray" waypoints requires knowledge of the situation.
If you are travelling by foot and taking trackpoints every minute, then
a point that is more than 250 metres off the general direction of travel
is an exception. ( running at 15km/h for one minute) If it is an olympic
runner, hen you need to increase that value.
If travelling on a bicycle, you need to know the condition. If on a main
road, a trackpoint doesn't need to be that far off before it is an
exception. But if travelling up a switchback on a mountain pass road in
the alps, then a lot of your points will be "off course" but still very
valid to map your track.
If travelling by car on the same road, your trackpoints may not be taken
at sufficiently close intervals to log some of the switchbacks and log
just a mostly straight road up the mountain with minor ddviations
between each point.
If you have 3 points, A B and C, B can be considred an exception if the
discance between B and the axis A-C is greater than some amount. (the
aviation formulary has those equations to calculate distance between a
point and an axis).
Now, if you have 4 points, A B C and D with B and C being odd, the above
logic won't work because B will be within the limits of the A-C axis.
JF Mezei wrote:
> Eliminating "stray" waypoints requires knowledge of the situation.
> If you are travelling by foot and taking trackpoints every minute, then
> a point that is more than 250 metres off the general direction of travel
> is an exception. ( running at 15km/h for one minute) If it is an olympic
> runner, hen you need to increase that value.
> If travelling on a bicycle, you need to know the condition. If on a main
> road, a trackpoint doesn't need to be that far off before it is an
> exception. But if travelling up a switchback on a mountain pass road in
> the alps, then a lot of your points will be "off course" but still very
> valid to map your track.
> If travelling by car on the same road, your trackpoints may not be taken
> at sufficiently close intervals to log some of the switchbacks and log
> just a mostly straight road up the mountain with minor ddviations
> between each point.
> If you have 3 points, A B and C, B can be considred an exception if the
> discance between B and the axis A-C is greater than some amount. (the
> aviation formulary has those equations to calculate distance between a
> point and an axis).
> Now, if you have 4 points, A B C and D with B and C being odd, the above
> logic won't work because B will be within the limits of the A-C axis.
> If you are travelling by foot and taking trackpoints every minute, then
> a point that is more than 250 metres off the general direction of travel
> is an exception. ( running at 15km/h for one minute) If it is an olympic
> runner, hen you need to increase that value.
> If travelling on a bicycle, you need to know the condition. If on a main
> road, a trackpoint doesn't need to be that far off before it is an
> exception. But if travelling up a switchback on a mountain pass road in
> the alps, then a lot of your points will be "off course" but still very
> valid to map your track.
> If travelling by car on the same road, your trackpoints may not be taken
> at sufficiently close intervals to log some of the switchbacks and log
> just a mostly straight road up the mountain with minor ddviations
> between each point.
> If you have 3 points, A B and C, B can be considred an exception if the
> discance between B and the axis A-C is greater than some amount. (the
> aviation formulary has those equations to calculate distance between a
> point and an axis).
> Now, if you have 4 points, A B C and D with B and C being odd, the above
> logic won't work because B will be within the limits of the A-C axis.
I think this approach might be useful. Do you have any references
(books, articles) to how these things are done in aviation?
Rune
- Garmin Data Fields
- Garmin GPS
- 2012-05-15
- PND Market Data
- Satellite Navigation
- 2012-01-17









> Assume you are given som 20,000 - 100,000 points of raw (x,y,z)
> navigation data as previously logged on some platform, and are asked
> to clean up the data.
> My first, naive idea is to use some Kalman filter. So far so good.
> However, the data might contain glitches (jumps) or other
> inconsistencies
> that need to be sorted out before feeding them to the Kalman filter.
> How would you go about detecting glitches and maybe even do a
> first-pass correction of such data? A manual check of 100,000 data
> points doesn't seem as a very tempting prospect...
> Rune