Clarification regarding new Trace segmentation code output #74
Replies: 2 comments 3 replies
-
Hi,
These are a few examples that lead to incorrect output, hence I would not recommend using old code for benchmarking for accuracy. |
Beta Was this translation helpful? Give feedback.
-
Hi @anujsinha3, Thanks for the clarifications. Could you elaborate more on the precision loss statement above for type conversions? We will get back to you on the first two points you mentioned regarding the old code. Meantime, as we discussed could you give us the code using the logic used in the original algorithm. This would actually help us better understand if the logic change you proposed in the algorithm i.e. first checking spatial constraint then duration constraint as compared to the previous logic of first checking duration constraint then spatial constraint is causing any major differences. |
Beta Was this translation helpful? Give feedback.
-
Hello,
I had a small clarification regarding the new trace segmentation output. I ran the below attached file (100 users having orig_unc < 100m) for workflow 2, after commenting out update_stay_duration and wanted to ask few clarifications regarding the output:
Stay
and take the count of unique Stays, I get the value as 7101. When I group by (stay_lat, stay_long), the count shoots up to 10027. So I believe the difference in the counts are the no stay points or transient points - just adding on to my clarification on how to identify these points as I asked in point 1.I may be going somewhere wrong in analyzing these numbers, could you take a look at this clarification please?
100_GPS_users.csv
@anujsinha3 @carlosgjs @qzchen-uw @gracejia513
Beta Was this translation helpful? Give feedback.
All reactions