BRIS .drf Fields #1268-1278

[eqitec]

These fields are not defined in the data file dictionary but I see dates in them. Does anyone know what they are for?

[snoadog]

Looks like the date of a trainer change

[ranchwest]

Yes, date of trainer change, but the last such field is 1277.

[eqitec]

Thanks. You seem well-versed in the .drf.

Could I ask one more question?

Are there undocumented fields showing the % performance of jockeys in the past performances lines, especially the last race before today's race? I know where the winning performance of today's rider is, but I need to compare that against the winning performance of the last rider of the horse's most recent race, to calculate if the rider change from the last race and today's race is an improvement, or a degradation?

[snoadog]

Nope, that one's not in there as far as I know.

[snoadog]

btw here's the link: http://www.brisnet.com/cgi-bin/static.cgi?page=drfsff

[ranchwest]

Thanks. You seem well-versed in the .drf.

Could I ask one more question?

Are there undocumented fields showing the % performance of jockeys in the past performances lines, especially the last race before today's race? I know where the winning performance of today's rider is, but I need to compare that against the winning performance of the last rider of the horse's most recent race, to calculate if the rider change from the last race and today's race is an improvement, or a degradation?

No, the previous jockey data is not readily available. You could see if the jockey has a mount today and get the data from there, though it would be for today, not the date of the ride. Not sure which you'd prefer.

If you get the data for all tracks, you could refer back to the past race date data. Or, if you're really into it, you could create a database to retain the information. Unless you write a program for such data, it would be a lot of work if you're trying to look at more than a few races.

[eqitec]

Re:

"Or, if you're really into it, you could create a database to retain the information".

This is what I have been doing for years, such that my rider database has over 4000 names and my trainer database has over 15000. For every race I've handicapped, I write their then current performance %s to these databases and recycle those back into the current races I'm handicapping.
This helps to some extent when I encounter riders or trainers I am not familiar with, but the timing is the issue. I was hoping to improve upon this with the most current data.

Thanks again.

[ranchwest]

Re:

"Or, if you're really into it, you could create a database to retain the information".

This is what I have been doing for years, such that my rider database has over 4000 names and my trainer database has over 15000. For every race I've handicapped, I write their then current performance %s to these databases and recycle those back into the current races I'm handicapping.
This helps to some extent when I encounter riders or trainers I am not familiar with, but the timing is the issue. I was hoping to improve upon this with the most current data.

Thanks again.

This is the sort of data that might give you an advantage because very few people will have access to that data or attempt to use it. Of course, it isn't the sort of thing that will help every race.

[raybo]

Re:

"Or, if you're really into it, you could create a database to retain the information".

This is what I have been doing for years, such that my rider database has over 4000 names and my trainer database has over 15000. For every race I've handicapped, I write their then current performance %s to these databases and recycle those back into the current races I'm handicapping.
This helps to some extent when I encounter riders or trainers I am not familiar with, but the timing is the issue. I was hoping to improve upon this with the most current data.

Thanks again.

What software or application are you using, for your handicapping and your "databasing"?

[Tom]

Just throwing this out, if the fields are not identified, what confidence is there that whatever is going into them will remain the same data?
You could screw up a database real fast.

[eqitec]

Totally FilemakerPro because it runs natively on Windows and Macs, plus also now has a thin client named FilemakerGo that runs on the iPad, iPhone, and iTouch.

[raybo]

Totally FilemakerPro because it runs natively on Windows and Macs, plus also now has a thin client named FilemakerGo that runs on the iPad, iPhone, and iTouch.

Since you're already using a full blown database for your database and handicapping (daily play), it should be rather simple to store the current jockey stats for each race and horse you access. After looking at the Filemaker Pro website, it appears that those stored records should be accessible for your daily play, recalling the latest updated records from the database and automatically entering them into a jockey stat field that you have added.

If you can't do this, what's the use in having a database, like Filemaker Pro, or any other such application? Databases are intended for storing and updating data and then putting that updated data to work. If Filemaker Pro won't do the job then Excel or some other spreadsheet program, capable of automation, could certainly accomplish it.

[CBedo]

Just throwing this out, if the fields are not identified, what confidence is there that whatever is going into them will remain the same data?
You could screw up a database real fast.Off topic, but this is one (of many) reasons, I'm moving all my dbs to nosql solutions like MongoDB (my fav). They are schema-less and easy to adapt on the fly.

[ranchwest]

Since you're already using a full blown database for your database and handicapping (daily play), it should be rather simple to store the current jockey stats for each race and horse you access. After looking at the Filemaker Pro website, it appears that those stored records should be accessible for your daily play, recalling the latest updated records from the database and automatically entering them into a jockey stat field that you have added.

If you can't do this, what's the use in having a database, like Filemaker Pro, or any other such application? Databases are intended for storing and updating data and then putting that updated data to work. If Filemaker Pro won't do the job then Excel or some other spreadsheet program, capable of automation, could certainly accomplish it.

A lot of people make good use of databases without necessarily making maximum use of those databases. That's part of the beauty of databases. They can be very useful and then become even more useful. I applaud eqitec for being at least as far as he's told us. Heck, for all I know he may be some sort of guru.

[ranchwest]

Just throwing this out, if the fields are not identified, what confidence is there that whatever is going into them will remain the same data?
You could screw up a database real fast.

If I can't figure out when it changes, I probably couldn't use it to begin with.

[CBedo]

If I can't figure out when it changes, I probably couldn't use it to begin with.I'm with ya there, but being schemaless is definitely one of the nice features of some of the NoSQL database/data stores. When you do figure out something changes, or more likely, when you decide you want to add another piece of data, it's super easy to add, and you don't have to worry about repopulating the whole db if you don't need to.

[Tom]

*bump*

I was looking at the file foe Del Mar for tomorrow, in Excel 2010 just to see all the fields and what was in any "reserved" ones and I notice that there is no call out for poly surfaces. Fields 7 and 326-335 all have only D or T in them, even though most races were run over poly.

Seemed to me to be a serious flaw if anyone is using this data for a database.

[DJofSD]

Look at ~ field #1403.

[raybo]

*bump*

I was looking at the file foe Del Mar for tomorrow, in Excel 2010 just to see all the fields and what was in any "reserved" ones and I notice that there is no call out for poly surfaces. Fields 7 and 326-335 all have only D or T in them, even though most races were run over poly.

Seemed to me to be a serious flaw if anyone is using this data for a database.

Field 25 is today's track's All Weather surface flag.

Fields 1403 through 1412 are the AllWeather flags for the past performances.

An "A" in any of these fields denotes an all weather track surface.

[Jeff P]

Tom, agreed.

I too saw it as a case where special handling is/was required.

For JCapper (before the data fields mentioned by Raybo existed and as a fail safe in case they are not accurate) I wrote a function specifically designed to identify surface type. Races are cataloged as being run on natural dirt, turf, or synth.

The function accepts track code and race date as inputs. It then matches the input data against a matrix containing a list of track codes where synthetic surfaces were installed along with start date and end date for races run on the artificial stuff.

PS - Raybo, good to see you posting again.

-jp

.

[Tom]

Silly me. I thought having a field named surface would be where you would put the, uh, surface the race was run over.:rolleyes:

Thanks for the info guys. This reminds of Eastie's tag line! :D

[DJofSD]

To echo one statement made by Jeff, yes, sometimes the data in fields #1403-1412 are in error -- when there should be an "A", it is not there.

[Tom]

Well, they have a new guy at BRIS and he is going to be on Byk's show every Friday.

Time to start calling and asking when their data will have integrity.:rolleyes: