STIDF - endTime, STI -> Track

Edzer,

Thank you for your considered reply.  I did in fact do something like you
suggested and used my duration as my data.  It then occurred to me that
there were probably knock on consequences to relaxing Track to an STI, and
digging around find that gstat is looking for, or to my reading thus far,
is looking for ST*DF for variogramsST and krigingST, so ST*DF it will be.

Reading the code of Track (https://github.com/edzer/trajectories) has
also led me to reconsider my data preparation process because the
@connections contains pertinent information relating to the validity of a
given trial.  The researcher's challenge was to observe the subject in real
time and reject trails that moved from a central fixation beyond 2 degrees
of visual angle.  And I now just find that this was done without the
benefit of a bounding circle to guide the 2 degree assessment.

So, what I think I might end up doing is borrow (and in my case then
mangle) your elegant connections code to track distance relative to the
central fixation point.  I assume that @connections$distance is the
distance from one sampling point/time and the subsequent.  And then check
whether accepted trials were actually valid as well.
And that will then be my data for the STIDF.

Thank you again,

Chris

On Fri, May 29, 2015 at 6:56 PM, Edzer Pebesma <
edzer.pebesma at uni-muenster.de> wrote:

On 05/28/2015 12:28 PM, Chris English wrote:

Hi,

I am wondering about the role of endTime in STIDF objects.  I am

examining eye tracking data (previously cleaned of blinks) in relation to

presented stimuli that is for some subjects an optical illusion and for

others not.  I want to examine where they were looking and when.

My process is to make a STIDF from the eye tracking data case and a

STSDF of the stimuli that was presented where and for how long,

convert the STIDF to a Track then do some 'over' analysis.

If I build my endTime for the STIDF using the delta() function on N

samples, I think I get something like N-1 endTimes, or every sample

is an endTime so N = N.

If instead I am thinking of endTime(s) as an interval during which

there is a cross hair and some tangential stimulus on the screen and

endTime is when a subject responds in some manner I can't build an

STDIF due to the following test:

eye_5v1_stidf <- STIDF(eye_5v1_sp, eye_5v1_time, eye_5v1_data,

+ eye_5v1_endTime)
Error: nrow(object at time) == length(object at endTime) is not TRUE

nrow(eye_5v1_time)

[1] 4724

length(eye_5v1_endTime)

[1] 63

endTime is meant to give the end time of the time interval an
observation refers to, and so the number of endTime s has to be
identical to the number of time instances (number of observations). I
guess you figure that out.

Indeed, it is not true. But what information do I have in endTime other

than my sensor sampling rate adjusted for blinks?  What I hoped to

achieve was to compare the spacetime aspects of the Track data through

time periods consistent with the time periods in the STSDF.

Perhaps 'over' takes care of this for me and I don't have to attend if

I just accept that endTime in the case of the STIDF is the end of each

sample.

The eye tracking data I am examining is fairly simple: x, y, cumulative

sum of samples in ms, duration between samples; from which

an STI can be constructed.  Not much more data than where the eyes were

when.  It would seem that there would be a lot of simple sensor

data of this sort so I wonder if Track can relax its requirement of

STIDF to allow STI.

Good point - I wonder that too. For now, you could feed it a data.frame
with zero columns, e.g. data.frame(matrix(nrow=n, ncol=0))

--
Edzer Pebesma
Institute for Geoinformatics (ifgi),  University of M?nster,
Heisenbergstra?e 2, 48149 M?nster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info

What I actually ended up doing was using spDistsN1 as commented in your
code for use with sp-1.1-1 for the
distances, and copied wholesale your directions_ll function and padded
it with a trailing 0.0 as directions_ll
returns N-1.

In looking at head(trackObj at connections) I note an absence of
row.names() in @connections that one might find useful for tests between
@connections and the STIDF data using match. Could I suggest this as an
enhancement to Track?

Cheers,

Chris

On Mon, Jun 1, 2015 at 12:33 PM, chris english
<englishchristophera at gmail.com <mailto:englishchristophera at gmail.com>>
wrote:

    Edzer,

    Thank you for your considered reply.  I did in fact do something
    like you suggested and used my duration as my data.  It then
    occurred to me that there were probably knock on consequences to
    relaxing Track to an STI, and
    digging around find that gstat is looking for, or to my reading thus
    far, is looking for ST*DF for variogramsST and krigingST, so ST*DF
    it will be.

    Reading the code of Track (https://github.com/edzer/trajectories)
    has also led me to reconsider my data preparation process because
    the @connections contains pertinent information relating to the
    validity of a given trial.  The researcher's challenge was to
    observe the subject in real time and reject trails that moved from a
    central fixation beyond 2 degrees of visual angle.  And I now just
    find that this was done without the benefit of a bounding circle to
    guide the 2 degree assessment.

    So, what I think I might end up doing is borrow (and in my case then
    mangle) your elegant connections code to track distance relative to
    the central fixation point.  I assume that @connections$distance is
    the distance from one sampling point/time and the subsequent.  And
    then check whether accepted trials were actually valid as well.
    And that will then be my data for the STIDF.

    Thank you again,

    Chris

    On Fri, May 29, 2015 at 6:56 PM, Edzer Pebesma
    <edzer.pebesma at uni-muenster.de
    <mailto:edzer.pebesma at uni-muenster.de>> wrote:



        On 05/28/2015 12:28 PM, Chris English wrote:

        > Hi,
        >
        > I am wondering about the role of endTime in STIDF objects.  I

        am examining eye tracking data (previously cleaned of blinks) in
        relation to

        > presented stimuli that is for some subjects an optical

        illusion and for others not.  I want to examine where they were
        looking and when.

        >
        > My process is to make a STIDF from the eye tracking data case

        and a STSDF of the stimuli that was presented where and for how
        long,

        > convert the STIDF to a Track then do some 'over' analysis.
        >
        > If I build my endTime for the STIDF using the delta() function

        on N samples, I think I get something like N-1 endTimes, or
        every sample

        > is an endTime so N = N.
        >
        > If instead I am thinking of endTime(s) as an interval during

        which there is a cross hair and some tangential stimulus on the
        screen and

        > endTime is when a subject responds in some manner I can't

        build an STDIF due to the following test:

        >

        >> eye_5v1_stidf <- STIDF(eye_5v1_sp, eye_5v1_time, eye_5v1_data,

        > + eye_5v1_endTime)
        > Error: nrow(object at time) == length(object at endTime) is not TRUE

        >> nrow(eye_5v1_time)

        > [1] 4724

        >> length(eye_5v1_endTime)

        > [1] 63

        >>

        endTime is meant to give the end time of the time interval an
        observation refers to, and so the number of endTime s has to be
        identical to the number of time instances (number of
        observations). I
        guess you figure that out.

        >
        > Indeed, it is not true. But what information do I have in

        endTime other than my sensor sampling rate adjusted for blinks? 
        What I hoped to

        > achieve was to compare the spacetime aspects of the Track data

        through time periods consistent with the time periods in the STSDF.

        > Perhaps 'over' takes care of this for me and I don't have to

        attend if I just accept that endTime in the case of the STIDF is
        the end of each

        > sample.
        >
        > The eye tracking data I am examining is fairly simple: x, y,

        cumulative sum of samples in ms, duration between samples; from
        which

        > an STI can be constructed.  Not much more data than where the

        eyes were when.  It would seem that there would be a lot of
        simple sensor

        > data of this sort so I wonder if Track can relax its

        requirement of STIDF to allow STI.

        Good point - I wonder that too. For now, you could feed it a
        data.frame
        with zero columns, e.g. data.frame(matrix(nrow=n, ncol=0))

        --
        Edzer Pebesma
        Institute for Geoinformatics (ifgi),  University of M?nster,
        Heisenbergstra?e 2, 48149 M?nster, Germany; +49 251 83 33081
        <tel:%2B49%20251%2083%2033081>
        Journal of Statistical Software:   http://www.jstatsoft.org/
        Computers & Geosciences:   http://elsevier.com/locate/cageo/
        Spatial Statistics Society http://www.spatialstatistics.info

In looking at head(trackObj at connections) I note an absence of
row.names() in @connections that one might find useful for tests between
@connections and the STIDF data using match. Could I suggest this as an
enhancement to Track?

Sure, but so far I've seen no cases where the points from which these
connections are computed have meaningful row.names. And the match is
essentially by row order, meaning you don't need base::match to match,
right?

wrote:

On 06/02/2015 08:45 AM, chris english wrote:

What I actually ended up doing was using spDistsN1 as commented in your
code for use with sp-1.1-1 for the
distances, and copied wholesale your directions_ll function and padded
it with a trailing 0.0 as directions_ll
returns N-1.

In looking at head(trackObj at connections) I note an absence of
row.names() in @connections that one might find useful for tests between
@connections and the STIDF data using match. Could I suggest this as an
enhancement to Track?

Sure, but so far I've seen no cases where the points from which these
connections are computed have meaningful row.names. And the match is
essentially by row order, meaning you don't need base::match to match,
right?

Cheers,

Chris

On Mon, Jun 1, 2015 at 12:33 PM, chris english
<englishchristophera at gmail.com <mailto:englishchristophera at gmail.com>>
wrote:

    Edzer,

    Thank you for your considered reply.  I did in fact do something
    like you suggested and used my duration as my data.  It then
    occurred to me that there were probably knock on consequences to
    relaxing Track to an STI, and
    digging around find that gstat is looking for, or to my reading thus
    far, is looking for ST*DF for variogramsST and krigingST, so ST*DF
    it will be.

    Reading the code of Track (https://github.com/edzer/trajectories)
    has also led me to reconsider my data preparation process because
    the @connections contains pertinent information relating to the
    validity of a given trial.  The researcher's challenge was to
    observe the subject in real time and reject trails that moved from a
    central fixation beyond 2 degrees of visual angle.  And I now just
    find that this was done without the benefit of a bounding circle to
    guide the 2 degree assessment.

    So, what I think I might end up doing is borrow (and in my case then
    mangle) your elegant connections code to track distance relative to
    the central fixation point.  I assume that @connections$distance is
    the distance from one sampling point/time and the subsequent.  And
    then check whether accepted trials were actually valid as well.
    And that will then be my data for the STIDF.

    Thank you again,

    Chris

    On Fri, May 29, 2015 at 6:56 PM, Edzer Pebesma
    <edzer.pebesma at uni-muenster.de
    <mailto:edzer.pebesma at uni-muenster.de>> wrote:



        On 05/28/2015 12:28 PM, Chris English wrote:

        > Hi,
        >
        > I am wondering about the role of endTime in STIDF objects.  I

        am examining eye tracking data (previously cleaned of blinks) in
        relation to

        > presented stimuli that is for some subjects an optical

        illusion and for others not.  I want to examine where they were
        looking and when.

        >
        > My process is to make a STIDF from the eye tracking data case

        and a STSDF of the stimuli that was presented where and for how
        long,

        > convert the STIDF to a Track then do some 'over' analysis.
        >
        > If I build my endTime for the STIDF using the delta() function

        on N samples, I think I get something like N-1 endTimes, or
        every sample

        > is an endTime so N = N.
        >
        > If instead I am thinking of endTime(s) as an interval during

        which there is a cross hair and some tangential stimulus on the
        screen and

        > endTime is when a subject responds in some manner I can't

        build an STDIF due to the following test:

        >

        >> eye_5v1_stidf <- STIDF(eye_5v1_sp, eye_5v1_time, eye_5v1_data,

        > + eye_5v1_endTime)
        > Error: nrow(object at time) == length(object at endTime) is not TRUE

        >> nrow(eye_5v1_time)

        > [1] 4724

        >> length(eye_5v1_endTime)

        > [1] 63

        >>

        endTime is meant to give the end time of the time interval an
        observation refers to, and so the number of endTime s has to be
        identical to the number of time instances (number of
        observations). I
        guess you figure that out.

        >
        > Indeed, it is not true. But what information do I have in

        endTime other than my sensor sampling rate adjusted for blinks?
        What I hoped to

        > achieve was to compare the spacetime aspects of the Track data

        through time periods consistent with the time periods in the

STSDF.

        > Perhaps 'over' takes care of this for me and I don't have to

        attend if I just accept that endTime in the case of the STIDF is
        the end of each

        > sample.
        >
        > The eye tracking data I am examining is fairly simple: x, y,

        cumulative sum of samples in ms, duration between samples; from
        which

        > an STI can be constructed.  Not much more data than where the

        eyes were when.  It would seem that there would be a lot of
        simple sensor

        > data of this sort so I wonder if Track can relax its

        requirement of STIDF to allow STI.

        Good point - I wonder that too. For now, you could feed it a
        data.frame
        with zero columns, e.g. data.frame(matrix(nrow=n, ncol=0))

        --
        Edzer Pebesma
        Institute for Geoinformatics (ifgi),  University of M?nster,
        Heisenbergstra?e 2, 48149 M?nster, Germany; +49 251 83 33081
        <tel:%2B49%20251%2083%2033081>
        Journal of Statistical Software:   http://www.jstatsoft.org/
        Computers & Geosciences:   http://elsevier.com/locate/cageo/
        Spatial Statistics Society http://www.spatialstatistics.info

--
Edzer Pebesma
Institute for Geoinformatics (ifgi),  University of M?nster,
Heisenbergstra?e 2, 48149 M?nster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info