-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: overlapping triplegs #607
ENH: overlapping triplegs #607
Conversation
-Tripleg_geometry from start to end staypoint - tripleg time from start positionfix to start of next staypoint
…e/triplegs-overlap-staypoints
* TST: introduce separate test class for overlap staypoints method * DOC: adjust docstring for overlap staypoints method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for contributing to Trackintel! I think the new method is a great addition to the existing tripleg generation and will probably be very useful for several applications :)
I had a look at the code and the implementation looks good to me in general, but I'm a bit confused about why the additional column tripleg_id_geom
is necessary. It would be best if we can avoid this, since it's confusing for users when there are several tripleg_id columns. I assume the reason can be seen in your drawn table, where the time in the overlap methods only starts after the staypoint ended, but the geometry already includes the pfs in the staypoint? In that case, wouldn't it be more consistent to just make the start at the same time, so that started_at
is also set to the tracked_at
time of the last pfs in the staypoint? I hope that makes sense. To deal with empty geometries, one could use the first or latest positionfix of the staypoint where the geometry is non-empty.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #607 +/- ##
==========================================
+ Coverage 93.40% 93.44% +0.04%
==========================================
Files 33 33
Lines 2061 2076 +15
Branches 364 367 +3
==========================================
+ Hits 1925 1940 +15
Misses 126 126
Partials 10 10 ☔ View full report in Codecov by Sentry. |
Thanks for the feedback! The reason why the So depending on if the temporal or spatial perspective is considered, the tripleg ids would be assigned differently. As a solution the temporal
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes! I see the problem, but I like the new version with the geometry-viewpoint, where the tripleg ID is based on the geometries.
In the end, the method is called overlap
, so it makes sense that the tripleg_id
refers to the overlapping geometries even if the start and end time of the tripleg is not set this way.
From my side it is therefore fine; I just made one more comment where it would be good for future edits if we have a bit more explanation how the code works. @hongyeehh , do you want to have a look as well? If yes, note that the diff is a bit messed up; the only thing that is really new is the method _generate_triplegs_overlap_staypoints
(and the test class). The rest is mainly marked because of minor changes that required different indent.
Thanks for the PR! I like the idea of overlapping tripleg generation and think the current code is quite well structured. We need to add more docstring to explain our definition of triplegs' time and geometry, and more test cases for the new method. But we can do this in a separate PR as this one is already quite heavy. Thanks for contributing to trackintel. I will merge this now! |
This PR introduces a new method
overlap_staypoints
for generating triplegs.Although the default method
between_staypoints
is suitable for most cases, there are instances where the temporalresolution of positionfixes is very coarse with an irregular interval between the positionfixes, resulting in large gaps
between staypoints and triplegs. These are not actual missing data in the record, but rather a consequence of the coarse
temporal resolution. Such occurrences can complicate further analysis.
Our use case involves GPS data of locomotives with positionfixes at irregular intervals, ranging from a few seconds to
several hours when active, and possibly reducing to one positionfix per day when the locomotive is inactive for extended
periods.
Adds
method="overlap_staypoints"
ingenerate_triplegs()
.TestGenerate_triplegs_overlap
.Approach
The logic follows the
"between_staypoints"
method, which already sets the"finished_at"
time of the staypoint tothe
"tracked_at"
timestamp of the following positionfix (which is the first positionfix of the next tripleg, andthereby also defines its
"started_at"
time). The"finished_at"
time of the tripleg is now also extended tothe
"tracked_at"
timestamp of the first positionfix of the next staypoint:To ensure a spatial overlap of the geometries, a new column
"tripleg_id_geom"
had to be introduced for the groupingthe points of the positionfixes into a linestring.
When a staypoint consists of only one positionfix, the previous tripleg will have a spatial overlap with that staypoint.
However, the following tripleg will not spatially overlap with the staypoint. Otherwise, duplicating the positionfix of
the staypoint would be necessary.
Note: I have not explored how selecting the
"overlap_staypoints"
method impacts the later processing andanalyses phases in the trackintel framework.