[ENH] Is there currently a way to know how many laps a race should have had

[d-henness]

Proposed new feature or change:

I need to know the fraction of the race each driver finished. Previously I had been doing this by looking at the race winner to see how many laps they completed and assumed that they had finished 100% of the race. With Monaco today that will no longer work. Is there a better way to get this information and if not, could this be included in a future version?

Thanks for all your work on this!

[theOehrly]

It's not implemented currently. But I'm fairly certain that the API does provide that information. I agree that it would be nice to have this. No promises though that I get around to adding it soon.

[jeroenvisser101]

This data is provided in LapCount (https://github.com/theOehrly/Fast-F1/blob/master/fastf1/api.py#L74), but it's not implemented yet in Fast-F1 as @theOehrly said, but should be fairly simple if you want to add it.

[rajuptvs]

@theOehrly @jeroenvisser101 Hi, Can I pick this up if no one is working on it yet

[theOehrly]

@theOehrly @jeroenvisser101 Hi, Can I pick this up if no one is working on it yet

Sure, I guess it won't be too difficult to add overall. Feel free to ask if you have questions.

[rajuptvs]

Thanks... I'll work on that..

[theOehrly]

@rajuptvs Hey, just wanting to ask if you have made any progress and if you are still interested in working on this? Is there anything that you need help with maybe?

[Toskosz]

Hey can i work on this ? if so, any advice on where to start ?

[theOehrly]

@Toskosz Sure, you can work on this. @rajuptvs has not responded anymore, so I'll assume they're not actively working on this.

The steps (roughly) should be:

1. validate that the 'lap_count' API response actually returns the intended number of laps and not just the number of laps that have been completed
2. Add a method in api.py that loads this data and returns it, effort required for parsing should be minimal. All API methods have similar structure, take a look at race_control_messages for example, which is fairly simple as well. The method should return all the data that is downloaded, not just the total lap count (for completeness’ sake).
3. Add a call to this method in Session._load_laps_data and set a property to the total number of laps. It should be accessible through the same _get_property_warn_not_loaded method as some of the other values. This way, users are reminded that they need to call .load first.

As a return value for the API method, I'd go with something like

{
  'TotalLaps': 56,
  'LapCount': {
    'Time': [00:00:07.160, ... ],
    'CurrentLap': [1, ...]
  }
}

[Toskosz]

The 'TotalLaps' attribute can change multiple times and not necessarily during a lap, e.g The Belgian GP:

['00:00:06.162', {'CurrentLap': 1, 'TotalLaps': 44}], ['01:32:10.123', {'TotalLaps': 43}], ['02:55:28.488', {'TotalLaps': 39}], ['04:19:26.431', {'CurrentLap': 2}]

So for the API method return i was thinking something like this:

{

	'Time': [00:00:07.160, ... ],
	'TotalLaps': [56, None, 50, ... ],
	'CurrentLap': [1, 2, None, ...]

}

Using None when either 'TotalLaps' or 'CurrentLap' doesnt exist in the data (Similar to race_control_messages when the key is missing). What do you think ?

[theOehrly]

@Toskosz sorry for the somewhat late reply. That is a very interesting finding. I'd say that your proposed approach is very reasonable then.

I'd like to understand how/why 'TotalLaps' changes. Am I right in assuming that the first value always is the scheduled number of laps? The last value then is the actual number of laps completed? Values in between are probably approximated if the session is running into the time limit and represent the number of laps that will likely still be completed? Any information like that should be noted in the documentation for that api function as well.

[Toskosz]

Yes, the first value of 'TotalLaps' is the original number of laps scheduled, but the last is not necessarily the amount of laps completed, as a race may not end (2021 Belgian GP) or end by time limit (2022 Monaco GP). Values in between ​​are rare so it's hard to say, but it does seem like they're approximations of race control based on the time limit left.

I was wondering if the property should just be the most recent 'TotalLaps' value or should it be all values ​​in a dict with each value's time?

Also, how does the testing folder works ? Does 2020_05_FP2 refer to a specific weekend or can I just add a lap_count.raw with random data on it ?

[theOehrly]

@Toskosz if I do understand you correctly, then it does not make sense to use only the most recent value. The most recent value would be the last value, right? And its relevance seems to be not very high, as you say that it only maybe denotes the actual number of laps completed. Furthermore, this issue was about getting the number of originally scheduled laps, which would be the first value, correct? Getting the total number of laps completed can already be done reliably by looking at the number of laps driven by the leader.

I'd say, the API method should return all values, as you previously proposed. Everything that is known and assumed about the data should go into the documentation (guesses need to be clearly differentiated from things that are known for sure). Maybe someone finds a use for all the data. The new property of the session class should only be set to one single value, which is the originally scheduled number of laps. This is what this issue is originally about. And it seems to be the only reliable value with regard to all the other 'TotalLaps' values.

There is an argument to be made that, for convenience reasons, one could add a second property for the actual number of laps completed. But it sounds like it would be best to simply make this return the total number of laps driven by the race winner. So it is not directly related to the new API endpoint.

The 2020_05_FP2 folder inside the testing/reference_data refers to this specific session and weekend, yes. If you need to use a different session (maybe a race) or a different weekend, then you can add a similarly named folder for that. (The 2020_05_FP2 session was picked for some of the other tests because it was a rainy session with little driving and therefore the amount of data is reduced considerably.) The .raw files contain the data as it is returned by the fetch_page function. You can also generate random data yourself. It might make more sense for testing in this case. Then please add a separate folder and name it something descriptive like fake_data.