[Feature Request] Fancier Algorithms to Determine Transit Mode

[RSXEnthusiast]

Is your feature request related to a problem? Please describe.
Coming from Google Timeline, I miss the accuracy of which Google would detect transit modes. I was especially impressed that it could detect motorcycle trips as compared to vehicle trips.

Describe the solution you'd like
None of this would be easy to implement, as location data is super messy, but a few ideas I have for better route detection (in order of likely difficulty/payoff in my uneducated opinion):

• Use publically available bus/train route information to infer when a user is on transit vs in a car.
  • In some countries, you might be able to assume that if a user is travelling quickly, they're probably on a train, but in the US our trains are slower than our highways :D
  • If the entire trip follows a bus route, they're probably not in a car.
  • If the trip starts with a walk or bike, then follows a bus route, probably not in a car.
  • If the trip follows rails instead of a road, they're probably on a train.
• Use publically available bike path data to infer when a user is on a bike vs in a car.
  • If the entire trip follows a bike highway, as per open bike map, AND stays below a certain speed, they're probably on a bike.
  • If the trip includes many segments that are not car accessible, AND stays below a certain speed, the user is probably on a bike.
• Use other data sources such as Gs and audio to detect motorcycling vs car and running vs bike.
  • I assume the accelerometer is how google does it, but maybe it uses audio volume, as it'd be louder on a motorcycle? Really not sure about this one.
  • This is honestly a nice to have thing, and should be super low priority, but it would bring the software more into parity with what Google can do.
  • Machine learning might be of use here, where you could have a section of the app where the user could go over recent trips and correct them to improve detection.

All of these solutions might require some sort of dedicated Reitti app, especially using other phone sensors, which I understand would be a huge undertaking.

Describe alternatives you've considered
The existing functionality is definitely usable and makes the most sense for something simple that just works without a huge complex algorithm or machine learning.

[dgraf-gh]

Hi @RSXEnthusiast,

I like the idea of a better approach to detecting movement types.

None of this would be easy to implement, as location data is super messy, but a few ideas I have for better route detection (in order of likely difficulty/payoff in my uneducated opinion):

True words indeed! I think the main problem here is that we just do not have enough data at the moment. In general, we have a latitude/longitude coordinate and a timestamp. This depends on the logging settings, but let's assume it's every 15 seconds. And that's it. Then, Reitti is designed to display a trip between visits; there is no multi-transport mode trip. It all boils down to the average speed during the entire trip.
That is not 100% correct, because the algorithm splits the trip up into 1-minute chunks and tries to determine the type based on these (mainly used to filter out traffic light stops, for example). It is not perfect, but it's close enough for an overall idea.

In my head, in the far future, there is the existence of a dedicated Reitti app. This could provide additional metadata in a clean way that we could work with. For example, a motorcycle ride probably manifests in some tilting of the phone.

Let's try to address each point:

Use publically available bus/train route information to infer when a user is on transit vs in a car.
Use publically available bike path data to infer when a user is on a bike vs in a car.

These two will probably not happen. I cannot imagine running some form of index for what lies under a GPS point. Reverse-Geocoding is already uncertain about which specific shop it was in a busy city. I doubt that doing this for every point will significantly improve accuracy. At least, it's not worth the cost.

Use other data sources such as Gs and audio to detect motorcycling vs car and running vs bike.

That one I find interesting, and some form of additional data is probably how Google does it. For example, if we take a look at the JSON the timeline in Maps produces:

"persona": {
      "travelModeAffinities": [
        {
          "mode": "WALKING",
          "affinity": 0.674876868724823
        },
        {
          "mode": "CYCLING",
          "affinity": 0.4482758641242981
        },
        {
          "mode": "IN_PASSENGER_VEHICLE",
          "affinity": 0.019704433158040047
        }
      ]
    }

and then for activities we have:

{
      "activityRecord": {
        "probableActivities": [
          {
            "type": "UNKNOWN",
            "confidence": 0.4000000059604645
          },
          {
            "type": "IN_VEHICLE",
            "confidence": 0.10000000149011612
          },
          {
            "type": "ON_BICYCLE",
            "confidence": 0.10000000149011612
          },
          {
            "type": "ON_FOOT",
            "confidence": 0.10000000149011612
          },
          {
            "type": "WALKING",
            "confidence": 0.10000000149011612
          },
          {
            "type": "RUNNING",
            "confidence": 0.10000000149011612
          },
          {
            "type": "STILL",
            "confidence": 0.10000000149011612
          },
          {
            "type": "IN_ROAD_VEHICLE",
            "confidence": 0.10000000149011612
          },
          {
            "type": "IN_RAIL_VEHICLE",
            "confidence": 0.10000000149011612
          },
          {
            "type": "IN_ROAD_VEHICLE",
            "confidence": 0.10000000149011612
          },
          {
            "type": "ON_FOOT",
            "confidence": 0.07000000029802322
          },
          {
            "type": "WALKING",
            "confidence": 0.07000000029802322
          },
          {
            "type": "UNKNOWN",
            "confidence": 0.019999999552965164
          },
          {
            "type": "STILL",
            "confidence": 0.009999999776482582
          }
        ],
        "timestamp": "2025-12-12T16:00:00.000+01:00"
      }

So, they first know what you prefer, and then it seems they calculate a score for every activity. But this is most likely done on the device. This would speak for a dedicated Reitti app where this data can be calculated.

What we could probably create first would be support for multiple transportation modes per trip. This alone would already significantly improve accuracy. What do you think?

[RSXEnthusiast]

That all makes a lot of sense, and I enjoyed reading the write-up! Yes, a lot of the suggested features would benefit from or require a dedicated app, which is a huge maintenance overhead.

Multiple transportation modes per trip would definitely improve accuracy, though I'd imagine that'd be a difficult task in itself using the current speed configuration, as I'm unsure how it'd figure out if you've switched to a bicycle, or just hit a 10mph speed limit in your car. Or how it'd know if you started walking, or just slowed down on your bike.

I do find it interesting that Reitti would find it impossible to decide if a large part of a trip followed a rail line or bus route, but I won't say any more on the matter unless I can come up with a PR which, lets be honest, is unlikely :p. I will say that checking to see if a majority of the points are closer to an active railroad than a car road seems the most plausible.

Again, thanks for the consideration and I've enjoyed reading your thoughts on this.

[dgraf-gh]

Multiple transportation modes per trip would definitely improve accuracy, though I'd imagine that'd be a difficult task in itself using the current speed configuration, as I'm unsure how it'd figure out if you've switched to a bicycle, or just hit a 10mph speed limit in your car. Or how it'd know if you started walking, or just slowed down on your bike.

Slowing down on your bike is not allowed 🚴 💪
What I can imagine would work:

• at the moment we splitup the trip into chunks and determine the average speed of overy chunk
• the transportation mode which speed matches the most chunks wins

this could be changed to:

• we splitup the trip into chunks like before
• every chunk again gets its transportation mode assigned (lets say we have 30 chunks) (walking to a parking lot, driving in a car and finally walking from a parking lot somehwere to a Visit)
• if there are a certain number of chunks with the same transportation mode they belong together. It is fine if they are interrupted by lower-speed chunks. But only if they are again followed up by higher-speed chunks (for example a traffic light stop)
• if a consecutive number of other-speed chunks follows they will form a new part of a trip with a different transportation mode

I do find it interesting that Reitti would find it impossible to decide if a large part of a trip followed a rail line or bus route, but I won't say any more on the matter unless I can come up with a PR which, lets be honest, is unlikely :p. I will say that checking to see if a majority of the points are closer to an active railroad than a car road seems the most plausible.

The main problems here will be the amount of requests we have to make and the accuracy of the results we will get.

Let's say we have a 45 min trip to a nearby city for example by train. There are 4 points per minute stored in reitti we need to check. This already makes 180 points we would need to check aka 180 request. That is a lot, multiply this with for a conservative 2 trips per day and a year worth of data and this quickly becomes unsustainable. Also the burden we would put on external systems if someone choose not to use photon will be to much.

Then the second problem, the accuracy. To determine if a point is on a train line we would need to ask photon (if it even has this data) or nominatim. But we are only working with the accuracy of the GPS data, where 10m difference is already considered good, but these 10meters make a lot of difference if we try to determine what lies below (in the sense of a map) that point.

Overall, I think the costs (our own resources and for external services) will be to high for the accuracy this brings in the end.
For me, the only feasible way would be to go down the rabbit hole in having a dedicated app for that.

Again, thanks for the consideration and I've enjoyed reading your thoughts on this.

Thank you for bringing this up. Really enjoying thinking about this kind of stuff.