[R-sig-Geo] STIDF - endTime, STI -> Track
chris english
englishchristophera at gmail.com
Tue Jun 2 09:43:56 CEST 2015
>> 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?
History being a good guide, if you say I don't need match I know its
right. I came to R from
SQL and view (viewed) base::match as something analogous to a where
clause in select, a comfort to myself in my query that I was asking for
what I
thought I was asking for, by name. I'll try and wrap my thinking around row
order relative to my needs and possible tests. I think I was considering
ID's because
as I understand ST objects they are immutable once created so slap in
everything
you might need before you build it...
I'll concentrate on row order.
Thanks again,
Chris
On Tue, Jun 2, 2015 at 3:02 AM, Edzer Pebesma <edzer.pebesma at uni-muenster.de
> 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
> >
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > R-sig-Geo at r-project.org <mailto:R-sig-Geo at r-project.org>
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
> >
> >
>
> --
> 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
>
>
[[alternative HTML version deleted]]
More information about the R-sig-Geo
mailing list