All Weather Racing - Course Misclassifications (Solved)

0 votes

I have just looked into the all weather courses using the following query, and it seems that many of the courses classified as all weather are actually turf races. Am I missing something because this seems like a serious error with the data?

"""SELECT DISTINCT race_type, course, going
    FROM historic_races_beta 
   WHERE race_type = 'All Weather Flat' AND meeting_date > '2018-01-01' 
   ORDER BY course ASC
"""

race_typecoursegoing

All Weather Flat

BeverlyGood

All Weather Flat

BeverlyGood To Firm 

All Weather Flat

Chelmsford_CityStandard

All Weather Flat

ClonmelYielding

All Weather Flat

DundalkStandard

All Weather Flat

HaydockGood To Firm

All Weather Flat

KemptonStandard 

All Weather Flat

LaytonStandard

All Weather Flat

LeopardstownGood

All Weather Flat

LingfieldGood To Firm

All Weather Flat

LingfieldGood To Soft

All Weather Flat

LingfieldStandard

All Weather Flat

NewcastleStandard

All Weather Flat

NewmarketGood To Firm

All Weather Flat

NottinghamHeavy

All Weather Flat

RedcarGood To Firm

All Weather Flat

RiponGood

All Weather Flat

SouthwellSoft

All Weather Flat

SouthwellStandard

All Weather Flat

WoverhamptonStandard

All Weather Flat

YarmouthFirm

All Weather Flat

YarmouthGood To Soft

asked Oct 28, 2020 in Smartform by ChrisWaltonHello Novice (200 points)
edited Oct 28, 2020 by ChrisWaltonHello

1 Answer

0 votes
 
Best answer
Some of the licensed feeds have carried a misclassified race type in the past for some courses - however, it's important to note the race_type distinction is race by race rather than by course,   So to see the extent of any misclassification in race_type you can query for example:

SELECT race_type, count(race_type)
    FROM historic_races_beta
WHERE meeting_date > '2018-01-01' and course="Beverley"
  group by race_type

Which shows 4 out of 374 races labelled as all weather at Beverley.   However, the going description as per your query makes it clear these are turf races.

In general, it's most accurate to use the going "Standard" description to define which courses run all weather courses rather than the race_type field eg.

SELECT DISTINCT course    FROM historic_races_beta
   WHERE going = 'Standard' AND meeting_date > '2018-01-01'
   ORDER BY course ASC

(This covers the all weather courses as you'd expect, and also throws up Laytown which is of course one meeting a year run on a beach in Ireland, but otherwise all courses are correct).

Note also that there will be a final clean up on the beta database before it is promoted live at the end of the year where race by race misclassifications in race_type will also be corrected, so race_type will also be another way you can query all weather races accurately.
answered Oct 28, 2020 by colin Frankel (19,280 points)
selected Oct 28, 2020 by ChrisWaltonHello
Thanks for the response.

Do you also happen to know whether it would affect the updater if I edited the values for some columns in the database ?
Hi - yes you can edit the content of columns in the database (rather than column names, using relevant update statements) provided that:
a) The schema does not change
b) The loaded_at timestamp does not change - this is what is used by the updater to determine which updates to fetch.
However, best practice is generally to build derived tables that rely on the original Smartform tables and edit these.  Not least because you may need to re-install the original historic data, and if so any changes or additions you make will be lost.
...