[Use case] Multi-individual spatial interaction about sftrack

[basille]

Thanks for this contribution too Sebastien! This one will not make it into sftraj, as it would be beyond the scope of the package. However, we want to make sure sftraj allows this. From what I understand, in your scenario, you have several individuals in the same sftraj, so you would need basically ways to extract spatio-temporal coordinates and this individual detail at the same time — which will be basic accessors from sftraj.

On a side note, you would want also a third column giving the individual identity in case there are more than two in one single objects… It would also be nice to be able to work over several trajectory objects (like one sftraj object per individual), and be sure that it can also work in 3 dimensions…

[jedalong]

we are working on tools that I think address this issue (or partly thereof) in the package wildlifeDI (which currently uses adehabitat ltraj objects)

[robitalec]

spatsoc provides two functions that could help here: group_times for grouping relocations temporally based off some temporal threshold (since relocations rarely share the exact same timestamp) and edge_dist for calculating the distance between all individuals (can be > 2) within timegroups. No support for azimuth at this time though.

[basille]

@jedalong and @robitalec, are there specific requirements for the tools offered by your respective packages? Would you rely on sftraj for the data part?

[jedalong]

Currently use ltraj, would migrate if it creates efficiencies. A key basic feature is the ability to include multiple individuals in a single sftraj object that can be easily subset (but I think you probably had that).

[basille]

It is indeed planned, but does not hurt to repeat it! In the proposal, we have:

Nesting is an essential part of the data model, as it allows any relevant boundaries of a trajectory, such as the individual level, the year, or a journey (movement from home to work and from work to shopping), and any nested combination of those. The package tidyr provides a function nest, which allows to nest columns inside a data frame, and will be used to easily switch from one level to another (e.g. from an individual representation to an individual-year representation).

So that would be one possibility… which still has to be defined properly (I will probably open a use case just for this).

[robitalec]

@basille, spatsoc works with data.table, so the geometries are expected as two columns (lat, lon) along with a datetime column. We then loop through (with data.table's by argument) the data by timegroup chunk and calculate distance between individuals. sftraj could be used for the data but I would worry about sacrifices in terms of speed, losing out on data.table's efficient grouped calculations.

I agree though, the handling of multiple individuals in one object is key.

[basille]

Thanks for these details @robitalec. Does spatsoc work with data.table for performance reasons only, or were there other reasons as well? Would you have very large datasets that you could share with us so we can test on our end?

[robitalec]

We used data.table because it's my personal preference when working with tabular data, it's really efficient and when paired with functions like fread, it can easily import large CSVs (and other text formats). Our relocation data is normally received and stored as CSVs so it felt like a natural tool to use. Advantages include: easily working with many individuals, simple chunking by season, subpopulation or other groups, efficient. Disadvantages: requires all data prep (datetimes, reprojected coordinates) and data cleaning/checking to be ad hoc (and in the spatsoc context - up to the user). The structure and integrated checks of a track-specific package would help here.

I definitely agree with the comments in #6 about anticipating larger (and not strictly wildlife) datasets and performance being a priority. spatsoc's core functions: group_times and group_pts are inherently point-based and would not benefit from trajectories being stored as a line, but having both storage options with conversion between seems like a good option, albeit more work!

Unfortunately I don't currently have any large datasets I can share. The example data in spatsoc shows our expected data structure, but is only ~14K rows.

[basille]

Our largest dataset here is >1M locations, but I'm sure we can find substantially larger ones. We can also fake them for test purposes…

As for data.table, thanks for this information! So we have:

• Reading performance when importing data files → not covered by sftraj
• Easy manipulation

I see there are efforts to make sf and data.table truly compatible, but I think this goes behind the scope of sftraj. As long as we rely properly on sf, then whatever sf can use should work for sftraj too.

[birderboone]

I'm re-opening some of these use-cases so theyre easier to find as people submit new ones.

[basille]

Closing this issue now that sftrack is developed and on CRAN.