Comment on [AIP] Reitti v5.3.0: Multi-Segment Trips, Spatial Coverage & FIT File Support

• randomname01@feddit.nl ⁨20⁩ ⁨hours⁩ ago

  Hi, thanks for your replies! I just read both of them and I got some more ideas, feedback and suggestions, so I’m sorry if I ramble a bit.

  One option is understanding the track beneath the path, sort of a “reverse route planner”

  Yeah, when exploring my data imported in Reitti (or Dawarich for that matter lol) I always thought this would be a great option. This would also enable something else that I forgot to mention, namely a way to auto fix dodgy data (I’ll get back to that later).

  With clear identification you could indeed identify trips with far greater confidence; train tracks means a train, highways means car by definition, separated bike paths should mean bicycle or walking, bodies of water will be a boat most of the time, … I imagine identifying exact rules could become tricky in edge cases, but I feel like this would increase the default quality of identification by a lot

  I am searching for a way to add notifications to reitti. One rule then could be, if there is a trip between place A and B, during the workweek between 07:00 and 09:00, re-classify this as train ride. But this would override then the walk to the trainstation. So the rule would need to be:

  • Trip between Place A and Place B
  • during workweek
  • between 07:00 and 09:00
  • trip is classified as driving

  That sounds fantastic to me, but my first reaction is that that sounds like an advanced option that would be great in addition to the one you mentioned first. By the way, another option to add might be if the trip passes through point C, because this could be used to differentiate between a commute by bike and by car, for example - since some people switch between modes of travel for the same commute, but the other variables you mentioned would still be the same.

  By the way, that reminds me that commute tracking could be cool to keep track of? I’m just spitballing. Identifying repeat trips would probably be useful in any case, as it could enable mass editing.

  As for editing, I did think of a few different things. Like I mentioned I think some sort of auto cleanup/smart cleanup system (perhaps with suggestions?) would be nice to have. This could include:

  • Location points jumping away from a road/train track/whatever at un unrealistic speed, especially if the subsequent data points are on that track
  • Same point as above, but with building detection
  • Some sort of auto clustering that could work in the same way; fifty points close to each other, one point 500 metres away and then fifty more points in that same spot probably indicate something fucky with that one rogue point.

  Assuming the logic is possible to implement, you could work with a confidence threshold: everything above that is corected automatically (perhaps with an option to roll back in an edit history queue), everything below that could be added to a user-verifiable list.

  As for your second point: there’s colota-forwarder, which can fan out GPS points from one system to multiple others. Maybe that would work for your use case? I don’t currently see reitti itself implementing something like that, as it would mean keeping up to date with other services’ APIs and reacting whenever they change.

  Ha, as as was writing that part in my previous comment I thought that something like that might exist and I told myself I’d check later. Mentioning Colocota-Forwarder somewhere in the Reitti documentation might be a good idean?

  Also, one final thing I’d love is a mobile app. Not necessarily to track (there are many apps to do that), but as a first-class mobile experience for Reitti. I do understand the challenges on that front though, so I’d understand if this simply won’t happen.

  Anyway, thanks for your work on Reitti and I hope my feedback can help you in some way.

  original

  • danielgraf@discuss.tchncs.de ⁨19⁩ ⁨hours⁩ ago

    Yeah, understanding the data beneath the point would help alot. The problem with that is that we first can not query some system for every point. And second, since the raw data is already jumping around alot, even if we could it is still way off.

    Commute tracking could be a way for the statistics. They need to improve a lot.

    For the logic to detect valid points, we basically do that already for the visit detection. I am quite happy with it right now. Maybe the second year of reitti will be focused on the trips. 😀

    Google did something like the confidence thing in their old timeline (Records.json) format. There for every path they had stored the confidence of the transportation mode.

    And finally the mobile app. I doubt it will come the next year but we never know. I would have some ideas like tracking bumps (smoother rides are propably a car or train, elevation above x meters is propably a plane and so on) and such things to have more confidence in the trip detection. Right now, there is an app for everyone available which can report into reitti. So there is no pressure. But I don’t know, I also did not thought about writing my own reverse geocoder but that also came out of a necessity to have some smaller hostage on a small vps.

    original