[R-sig-Geo] STIDF - endTime, STI -> Track

[chris english]

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> 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> 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
>>
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> R-sig-Geo at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>>
>

	[[alternative HTML version deleted]]