intake pipeline : bad smoothing, incorrect mode detection...

e-mission / e-mission-docs

Repository for docs and issues. If you need help, please file an issue here. Public conversations are better for open source projects than private email.

BSD 3-Clause "New" or "Revised" License

15 stars 34 forks source link

Hi, I attached the timeline for a recent trip (March 19) :

for the trip from 3:13 to 3:53 pm the smoothing has not deleted a point a few km off the track, and the inferred mode is bicycle with outlier speeds (due to the offtrack point)
also, for this day, I am pretty sure to have started the trip in the morning and I see no trips for the morning in the diary, how can I check that I was not tracked ? There are some stats in the morning in the timeline, but no location, does that mean that the location tracking was off?
on the same day, the trip mode at 7:30pm is all tagged as walking, although I took the tramway for a while
I have similar issues with other trips (e.g. bus detected instead of local train)

More generally, we will now enter a phase with more testers and more tests, how do we organise so that you are not overwhelmed with issues? (we have already 2 early testers who said us that some trip modes were incorrect). It is difficult for us (in practice impossible for the moment) to understand enough the pipeline so that we can work on corrections ourselves, but we can qualify the issues and filter them out for you. Thanks in advance.

@PatGendre I think that the key is that the mode detection will never be perfect. There is no algorithm in existence that will give you 100% accuracy. It is a good question what the actual accuracy is, and I want to run the benchmark to quantify that, but people want to use the platform without waiting for the benchmarking so it keeps getting postponed in favor of issues like #325 and #345.

However, note that the existing mode detection only supports 5 modes. It doesn't support, for example, e-bikes, motorbikes, carpooling, ride-hailing (uber/etc). So most projects that care a lot about the mode have allowed users to confirm the mode and specify the purpose (e.g. https://github.com/e-mission/e-mission-phone/pull/528, https://github.com/e-mission/e-mission-phone/pull/534).

Or there are projects that don't care that much about each individual trip, only the trends (e.g. TripAware https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-2.html) and they didn't want people to cheat by choosing a more sustainable mode, so they didn't allow mode selection.

If the tracking is not working properly (e.g. your second issue above), that is a lot more serious and I am happy to investigate those in greater detail. Please send me your logs if you still have them.

e-mission / e-mission-docs

intake pipeline : bad smoothing, incorrect mode detection... #346