Project Thousand-Papercuts

[dgraf-gh]

Hey everyone! 👋

I wanted to start a little initiative called Project Thousand-Papercuts, which is a spot to gather all those tiny paper cuts and minor annoyances we run into while using Reitti. You know the ones: things that feel a bit too small to file a full bug report for, but still bug you!

Think of this as a low-effort place to vent those small pet peeves. I will be keeping an eye on this thread and doing my best to polish those rough edges over time. Let me know what is on your mind!

[dgraf-gh]

I will start:

the datepicker does not show a locked date correctly

[dgraf-gh]

Will be done in #1333

[Appoxo]

First of all: Awesome project. I am using it together with dawarich (thanks to gpsloggers capability to push to multiple locations) because each project has it's own strengths.

What annoys me here: Transport mode classifications. They are kinda useless compared to dawarich.
While dawarich seems to classify based on speed as well as acceleration, reitti does only speed. So driving in the city regularly switches between car, bike, car, bike because I drive 25-35 in the city and usually includes stop'n'go traffic.

I usually commute by bike so I can't turn the transport mode off either.
Which is sad because I like the pretty graphs.

My suggestion:

Option A: Overlapping speed ranges

• Bike: 15-35km/h
• Car: 30-120km/h

If I drive over the threshold for maybe 2-3 points (configurable), the transport mode switches and stays until the reverse becomes true (move for x points below the range).

Option B:

Implement acceleration calculation into the transport detection classification.

Option C [ but actually being a supplement to either A and/or B)

Depending on how and what reitti can get from the map data, could it also classify transport by the area/road I move on?
Example:
If I drive 50 km/h downhill with my bike on a gravel/asphalt road in a forest, how likely is that it's a bike and not a car despite the speed threshold being max 50 km/h?
And depending on these factors it could override the current transport mode.

Side question:
If we can get smarter transport mode detection, could we maybe also have an option to display a percentage of the likelihood the mode was correctly assumed?
Example:

• bike mode was configured to be 15-25km/h: Speed was between 10-30 km/h, location was 10% city, 60% sidewalk (rural area) and 30% forest = 75% certain it was biking and not a car
• car mode was configured for 50-120 km/h): Speed was between 0 and 50 km/h in the city and on the highway 70-140 km/h. The car was not near train tracks.
  • The likelihood of switching between walking and car every 4min is unlikely so it couldnt be switching between walking and driving.
  • The likelihood of switching between bike and car is high but the majority of driving in the city was >30km/h and constant switching is very unusual.
  • Result: 30% it was riding a bike and 70% driving a car

[dgraf-gh]

Hi @Appoxo,

Since I am quite happy with how the Visit Detection has developed over the last year, I am already focusing my efforts on better transportation mode detection. I am also facing the problem that I am too fast on my bike in the city. Right now, as you saw, we have these hard thresholds which kind of work, but also kind of suck. I have already tried to mitigate some inaccuracy by giving the detection more context or intelligence. For example: it is unlikely that you jump in a car and, in the middle of the ride, switch to a bike. That was the case when you were stuck in a traffic jam, for example.

I really like the idea of having the speed band in your option a. That way, we could have a score for every transport mode on a segment of a trip, maybe with some additional data, such as whether your user is more likely to take the bike or car. When we have that, Reitti could merge the segments in a second pass.

For getting the map data: at that point, Reitti only has the GPS point in hand. We would otherwise have to make a lookup somewhere, and this will slow the whole process down. I will create an issue for the scoring, and then we can see if it improves the detection.

Thank you for the input.