Interpolate mileage

[t3chguy]

LubeLogger is great and your rapid development is awesome.

After reading https://docs.lubelogger.com/Dashboard#notes-on-distance-traveled

I'd personally like to see the ability for it to interpolate mileage.

Lets say I have the following odometer readings:

• 10000 on Feb 14th
• 20000 on Mar 14th
• 30000 on Apr 14th

It'd show zero for all months, but obviously, I've not done zero miles. The workaround would be to add max(prev_month) into a month for it to not drop those miles into the ether.
A better solution would be to spread the miles between odometer readings evenly over the days in between as a form of interpolation to ensure the graphs are coherent and not only showing a subset of the data.

[hargata]

that's actually a pretty good idea. so would the distance traveled per month just be max(prev month) - max(current month)? The only difficulty I can see with that is if you're viewing data for a specific year then the data for January could potentially be zero since it won't have access to the data from December the previous year.

[t3chguy]

Yeah I guess another way of interpolating it would be max(prev month) - max(current month) though personally I think weighting it based on days between odometer readings would likely be more accurate (though more hellish to query/resolve I'm sure)

The only difficulty I can see with that is if you're viewing data for a specific year then the data for January could potentially be zero since it won't have access to the data from December the previous year.

Fetching 13 months (year plus extra month prior) to build the dataset doesn't sound like it'd be too bad?

[hargata]

I've put some code down for this to try it out but man, trying to interpolate data that just isn't there is pretty expensive to run especially when it comes to having to allocate which portion of it belongs to which month. e.g: a record of 100 miles in Feb 15th and then a record of 200 miles in March 15th, not impossible to weigh how much of the 100 miles belongs in Feb and which ones belong in March, just very expensive.

I was thinking of just adding a Best Practice section in the documentation so that users who needs the most accuracy out of the distance traveled metric should create an entry on the 1st and last day of each month.

[t3chguy]

I was thinking of just adding a Best Practice section in the documentation so that users who needs the most accuracy out of the distance traveled metric should create an entry on the 1st and last day of each month.

Maybe its something I'll cron using the API :)

[hargata]

@t3chguy yeah that would probably be the best way to get as good of an accuracy as possible, I also have something planned for LubeLogger down the road that will utilize the geolocation API so odometer records can be logged automatically, tho that is pretty far down the road since PWA support on iOS is pretty shaky. For now I'll close this ticket as not planned.

[t3chguy]

@hargata I still some solution to ensure no miles are left out of the graph is important, even if its not interpolated/amortized, e.g. your proposed solution of miles=max(month)-max(prev_month) - as with the current system the area under the graph is not guaranteed to be the total mileage done, the specific months are less important

[hargata]

@t3chguy it's absolutely a valid concern, and I did try out some code that implements miles = max(current month) - max(previous month), for January it takes max(current month) - max(previous year), and you can see the code here in this commit, it's not due to a lack of trying: b2a0885

My biggest concern with that approach is that it's going to raise more questions than it answers especially if users only log their odometer readings partway through the month e.g.: January 8th, February 15th, etc. Since the chart on the dashboard only displays data aggregates per month and not in a monthly cycle format(e.g.: Jan 15th - Feb 14th), we're definitely going to be getting some questions down the road about how the mileage is allocated and why it just adds up in the current month and then we'll be back to attempting to weigh those mileage across the dates between odometer records again.

It's oddly reminiscent of the discussion regarding how average fuel mileage should be calculated in the app when factoring in missed fuel ups, it's pretty similar in terms of how we're trying to guesstimate how much distance the user has covered between fuel ups when there is a missed fuel up in between.

We've basically come to the conclusion that there is no satisfactory solution to fill in all the blanks between the available data since users are always going to want more answers, and so releasing a Best Practice statement and hoping that the users will follow it to the best of their ability is perhaps the most optimal way to go.