Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

driver_constructor_data for past seasons #37

Closed
christianlohr9 opened this issue Mar 3, 2023 · 6 comments
Closed

driver_constructor_data for past seasons #37

christianlohr9 opened this issue Mar 3, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@christianlohr9
Copy link

Hi,

either I'm blind again or this dataframe only works for current drivers.
Is it possible to create a df for past seasons?

Imo a static df would be ok for this and I'd love to help / provide the df for past seasons.

Best regards,
Christian

@pbulsink
Copy link
Collaborator

pbulsink commented Apr 29, 2023

I think it already is a static df in the package - certainly I'd suggest submitting a pull request to update to 2023 driver/constructors.

Some challenge appears though for past seasons where a driver may have driven for more than one team (think Russell in 2020 when he subbed for Mercedes in Bahrain). The best solution in general might be for load_results() (and other functions) to return both driver and constructor id?

@SCasanova SCasanova added the enhancement New feature or request label May 2, 2023
pbulsink added a commit to pbulsink/f1dataR that referenced this issue May 6, 2023
Reimplementing SCasanova#40 in partial resolution of SCasanova#37
@pbulsink
Copy link
Collaborator

pbulsink commented May 6, 2023

Now when you get the results from load_results() it includes the constructorId of each driver. That's the most reliable way to identify the driver/constructor pairing and doesn't need manual updating each season. We should likely modify the data frame in the package to take the drivers out and have it essentially be just a colour reference for the constructors.

@pbulsink
Copy link
Collaborator

Now when you get the results from load_results() it includes the constructorId of each driver. That's the most reliable way to identify the driver/constructor pairing and doesn't need manual updating each season. We should likely modify the data frame in the package to take the drivers out and have it essentially be just a colour reference for the constructors.

Note: this is still missing for sprint races - I'll have to look into them to see if Ergast passes that data or not for us to include.

pbulsink added a commit to pbulsink/f1dataR that referenced this issue Jun 19, 2023
@pbulsink
Copy link
Collaborator

From now, my likely only suggestion would be a table of constructor_id and their team colours for plotting purposes.

pbulsink added a commit to pbulsink/f1dataR that referenced this issue Jun 20, 2023
@pbulsink
Copy link
Collaborator

Close once #83 merges?

This results in having only constructor_data available - driver data can be collected in part by load_drivers() (i.e. their wikipedia url, full name, etc) and, most crucially, the driver-constructor relationship is maintained for all race and sprint results.

I'd suggest that if you're working on practices/qualis you refer to the driver/constructor relationship from the associated race, and interpolate (if possible) if there are any substitute/junior/test drivers doing the practice session.

@SCasanova
Copy link
Owner

Closed by #83 (available by joining constructors and drivers)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants