Glitch/inconsistency detection in navigation data

JF Mezei wrote:

   ...

> So one must really understand the "event" as well as how the data was
> recorded for that event before starting to process such data and
> eliminate points judged to be "bad".

One must always understand data in order to analyze and interpret it 
meaningfully. Believing otherwise is like believing that someone can 
manage a business without understanding its nature.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Ulrich Bangert wrote:
> Hello JF Mezei,
> 
>> Ok. fair enough. But that still leaves the requirement that the user
>> know about the type of data that he has to process, the types of
>> irregularities which must be retained, and those that can be removed
>> because this will be needed to decide on the window size. And one also
>> need to know how the data was collected.
> 
>  Agreed!
> 
>> of stray points. With "auto" track recording, chances are very good that
>> the GPS would record a point at the turnoff, one point at the stop for
>> water, and again a point once the car gets back to main road and turns
>> back into the normal direction.
> 
> I am not sure if i interprete the term "auto track recording" in the right
> way. Perhaps it is even a "standard" term in navigation that i am not aware
> of  (I have seen the question for outlier detection purely from a
> mathematical point of view). But if it is some kind of "event driven" track
> recording you are of course right that the proposed algorithm can not handle
> data acquired in this way because some frontend entity has already made the
> decision what an event is and what not and has missed to acquire the
> "surrounding data" that are necessary for the algorithm.

I read somewhere, that some GPS units use a boundary and time check when 
recording track points in auto mode.

It went something like this:

If the new sampled track point n is outside the "road" defined by track 
points n-1 and n-2 plus a margin to each side of the line n-2 to n-1, or 
the unit has not recorded a track point for "this long", then record 
track point n.

/Mogens

Mogens Beltoft wrote:
> If the new sampled track point n is outside the "road" defined by track
> points n-1 and n-2 plus a margin to each side of the line n-2 to n-1, or
> the unit has not recorded a track point for "this long", then record
> track point n.


Change in speed also causes a track point to be recorded on sime Garmin
units. And I think that change in heading also does. I don't think
Garmin ever documented the algorythm.

Jerry Avins wrote:
> JF Mezei wrote:
> 
>   ...
> 
>> So one must really understand the "event" as well as how the data was
>> recorded for that event before starting to process such data and
>> eliminate points judged to be "bad".
> 
> One must always understand data in order to analyze and interpret it 
> meaningfully. Believing otherwise is like believing that someone can 
> manage a business without understanding its nature.

Tell that to an MBA. :-)

You are quite right. When I asked what kind of nav system this is, there 
was no response. All the discussion has been about hypothetical 
something or others, rather than real world improvement of specific 
problems in the data.

Steve

Steve Underwood wrote:
> Jerry Avins wrote:
> > JF Mezei wrote:
> >
> >   ...
> >
> >> So one must really understand the "event" as well as how the data was
> >> recorded for that event before starting to process such data and
> >> eliminate points judged to be "bad".
> >
> > One must always understand data in order to analyze and interpret it
> > meaningfully. Believing otherwise is like believing that someone can
> > manage a business without understanding its nature.
>
> Tell that to an MBA. :-)
>
> You are quite right. When I asked what kind of nav system this is, there
> was no response. All the discussion has been about hypothetical
> something or others, rather than real world improvement of specific
> problems in the data.
>
> Steve

My apologies for that, Steve. These *are* real-world data from
real-world
systems, but as I don't know exactly where the limits go for corporate
"hush-hush" I'll rather play it safe for now. And, of course, I can
guess
but I don't necessarily know the important details.

No offence to you or any other. I saw a way of doing things and I
wanted
to know what the alternatives, preferably commercially available, are.
As
there seems to be no canned solution available, I'll probably have to
program some Kalman filters myself and play with them until I get a
sense for how these things work and how to incorporate the various
ideas. 
 
Rune