STIDF - endTime, STI -> Track
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