Churchill-Ellis Park

[Robert Fischer]

Originally Posted by Jeff P

You think that's my take on horse deaths?

Wow (just wow.)

International racing jurisdictions have trainers and veterinarians in charge of horses too.

Yet somehow their horse fatality rates are orders of magnitude lower than ours here in the US.

My take?

There's a reason for that.

Maybe we should start by asking:

What are they are doing different than us?


-jp
.

You ask some good questions, although I'm not sure the answer won't be apples vs. oranges.

Not answering for TLG, but your previous comment could be taken in the context of a slight vs. the 'BAQ' thing, even if it wasn't meant to take a 'shot' at NYRA or state gaming or whatever

[Jeff P]

Originally Posted by the little guy

Tom, with all due respect, it did serve a purpose, and whether you want to acknowledge this or not, there are a TON of moving parts in running a racetrack. Believe it or not, we don't sit around thinking of ways to make people's lives more difficult. In fact, we spend a lot of time thinking how we can continue to move forward in an increasingly more difficult environment. We try to do this so we can continue to provide racing for the many people that depend on it and enjoy it.

Andy,

Yes.

There IS a reason for renaming/branding a meet.

And there ARE a lot of moving parts.

If a track wants to brand their meet and make it stick out by giving it a catch phrase name:

GO for it!

But keep in mind the data is one of those moving parts too.

Imo, when a track asks Equibase to brand an upcoming meet a certain way:

They should also ask Equibase to not break the data.

And Equibase should strongly (and quietly behind the scenes) suggest to track management that they be allowed to get the data right if that doesn't happen.

Imo, that means:

The rebranded track name can and should be front and center when Entries are drawn, on the front page of the DRF, on Track Programs, on TV, and on Track Video.

But the data itself (data file names, result file names, running lines, workouts, and compiled stats) should bear/be based on a permanent track code where the races are run.

The only valid reason to change an existing track code would be if a track is torn down, the track surface(s) are removed, or moved to a slightly different location, and then rebuilt (such as Belterra which was essentially built on the same site where River Downs used to be.)

Horse Racing is a data driven business.

The first order of business:

Get the data right.


-jp
.

[Jeff P]

Originally Posted by Robert Fischer

You ask some good questions, although I'm not sure the answer won't be apples vs. oranges.

Not answering for TLG, but your previous comment could be taken in the context of a slight vs. the 'BAQ' thing, even if it wasn't meant to take a 'shot' at NYRA or state gaming or whatever

I can assure you:

No slight was meant.

I just want the data to be right.


-jp

.

[o_crunk]

Originally Posted by Jeff P

Andy,

Yes.

There IS a reason for renaming/branding a meet.

And there ARE a lot of moving parts.

If a track wants to brand their meet and make it stick out by giving it a catch phrase name:

GO for it!

But keep in mind the data is one of those moving parts too.

Imo, when a track asks Equibase to brand an upcoming meet a certain way:

They should also ask Equibase to not break the data.

And Equibase should strongly (and quietly behind the scenes) suggest to track management that they be allowed to get the data right if that doesn't happen.

Imo, that means:

The rebranded track name can and should be front and center when Entries are drawn, on the front page of the DRF, on Track Programs, on TV, and on Track Video.

But the data itself (data file names, result file names, running lines, workouts, and compiled stats) should bear/be based on a permanent track code where the races are run.

The only valid reason to change an existing track code would be if a track is torn down, the track surface(s) are removed, or moved to a slightly different location, and then rebuilt (such as Belterra which was essentially built on the same site where River Downs used to be.)

Horse Racing is a data driven business.

The first order of business:

Get the data right.


-jp
.

This is 100% correct of course. And I'd add that Equibase is charging a ton of money for data. You would think they would have an interest in maintaining integrity.

Let's see what happens with CD/Ellis. Equibase has been very inconsistent with stuff like this over the years. Changing track codes but not track names, changing track names but not track codes. There does not seem to be an overarching philosophy or spec that they adhere to. For a company that is the only source of this data, it's quite clownish, IMO.

[The_Turf_Monster]

If you can't write a case statement to alter a variation in track code, the problem isn't the track code imo.

[Jeff P]

StrideSafe Science & Technology Page:
https://www.stridesafeusa.com/science

StrideSAFE was created specifically to address the serious problem of catastrophic injury in racehorses.

It is known and widely published that in 85% of catastrophic injury cases, necropsies had shown the presence of pre-existing pathology. There had been a slow but relentless deterioration of bone health taking place over several weeks or possibly even months which eventually so weakened the bone that eventually it gave way.

The challenge was to detect the early stages of this pathology and so intervene to save the horse’s life.

Traditional levels of care had failed in this regard. Every horse which has suffered a fatal injury has been examined by a veterinarian the day it ran. There are no easily visible external signs and the horse is sound at the trot.

StrideSAFE reasoned that it was necessary to collect data from the horse itself when it was running at high speed during a race. Only then would the forces be so great as to trigger discomfort in the bones and therefore changes in the horses biomechanics.

StrideSAFE sensors can measure and record the forces in all three directions, that is dorso-ventral i.e. up and down, longitudinal i.e. forwards and backwards, and medio-lateral i.e. side to side. The sensors collect data 2,400 times every second!

Each horse has a unique way of moving, at StrideSAFE we liken it to a “fingerprint”. It is when this style changes that we know something is bothering the horse.

The changes which occur take place over as little as 1/100th of a second, easy for a sensor to pick up and measure but impossible for humans to recognize...

StrideSafe Press/Testimonials Page:
https://www.stridesafeusa.com/pressandtestimonials

Dr. Scott Palmer
New York State Equine Medical Director

“This is probably one of the most important contributions to the Thoroughbred horse industry that has ever been made” (Full article)

Imo, this new technology is very much worth checking out and probably deserves its own thread. (But I also think it's relevant here.)


-jp
.

[o_crunk]

Originally Posted by The_Turf_Monster

If you can't write a case statement to alter a variation in track code, the problem isn't the track code imo.

The problem isn’t the case statement. The problem is paying thousands of dollars a month for quality data so I don’t have to slip it in for a bunch of clients who want to fix something that never should’ve changed in the first place. If you’re working with the data at that level, dealing it with it is whatever. It’s the principle of paying for it and expecting it to be supplied in a sensible manner. It would be different if it was free or if I was scrapping it or any number of other scenarios. The scenario where I pay for it, they change it because some marketing genius says so based on some nonsensical reason. I don’t know, that’s pretty amateur to me. Hell, Serling explained it himself…it’s because they know their customers so well and it’s very complicated to run a race track. 😂

[Robert Fischer]

You're better than this, and this is exactly the kind of thing that discredits you

just kidding, racing industry is as bad as the stewards they employ.
It's a coin flip on decisions and you wouldn't consult with them to help solve a problem or cap a trip.

[The_Turf_Monster]

Originally Posted by o_crunk

The problem isn’t the case statement. The problem is paying thousands of dollars a month for quality data so I don’t have to slip it in for a bunch of clients who want to fix something that never should’ve changed in the first place. If you’re working with the data at that level, dealing it with it is whatever. It’s the principle of paying for it and expecting it to be supplied in a sensible manner. It would be different if it was free or if I was scrapping it or any number of other scenarios. The scenario where I pay for it, they change it because some marketing genius says so based on some nonsensical reason. I don’t know, that’s pretty amateur to me. Hell, Serling explained it himself…it’s because they know their customers so well and it’s very complicated to run a race track. 😂

It's not a DQ issue imo. The venue is changing, the meet isn't....hence the new identifier to signify a new venue for a continuing meet.

You could always submit a change request to your vendor to alter your requirements. You have requirements, right?

[o_crunk]

Originally Posted by The_Turf_Monster

It's not a DQ issue imo. The venue is changing, the meet isn't....hence the new identifier to signify a new venue for a continuing meet.

You could always submit a change request to your vendor to alter your requirements. You have requirements, right?

There are a thousand things within the Equibase RDS system that I would do differently. For me those changes are irrelevant. The vendor is going to do what they are going to do with or without my input. My input would have no impact on Equibase's decision to do something.

My requirements are also irrelevant.

If you were Equibase, how would you handle the track_id column for this meet shift change? Based on how these things have been handled in the past, you could come up with any number of valid answers according to Equibase. That's the whole problem IMO. There is no consistency to their own data integrity. So we make it for them on our own based on our clients needs. Which is completely fine.

Again, we are paying for these inconsistent data integrity choices. This isn't a steward in a box making a marginal call. Pretty much every single person who dealt with the BAQ thing or BHP/HOL/OTP thing agrees that these are inconsistent changes.

[The_Turf_Monster]

Originally Posted by o_crunk

There are a thousand things within the Equibase RDS system that I would do differently. For me those changes are irrelevant. The vendor is going to do what they are going to do with or without my input. My input would have no impact on Equibase's decision to do something.

My requirements are also irrelevant.

It sounds like you don't have requirements and consume Equibase's data as-is. For this, a best practice would be the implementation of a balance and controls process to identify any non-conforming track codes and to alter them in whatever transformation process you may have or may need to implement. It's a non-issue and par for the course imo, hardly something to fault Equibase for.

[o_crunk]

Originally Posted by The_Turf_Monster

It sounds like you don't have requirements and consume Equibase's data as-is. For this, a best practice would be the implementation of a balance and controls process to identify any non-conforming track codes and to alter them in whatever transformation process you may have or may need to implement. It's a non-issue and par for the course imo, hardly something to fault Equibase for.

You would never alter the source of the data for storing it as-is. For whatever the need is, and the need may change, you store it as it was transmitted from the "source of truth", in this case Equibase and transform it as needed. In this case, some clients wanted BAQ, some wanted AQU. Some wanted BAQ display but AQU historical stats. You get it. Meanwhile, the races actually took place at AQU.

It is non-issue for me. Still doesn't make it right. Right is better than wrong. BAQ was wrong on almost every data level from the single source of truth.

[headhawg]

Originally Posted by The_Turf_Monster

It sounds like you don't have requirements and consume Equibase's data as-is. For this, a best practice would be the implementation of a balance and controls process to identify any non-conforming track codes and to alter them in whatever transformation process you may have or may need to implement. It's a non-issue and par for the course imo, hardly something to fault Equibase for.

You're missing the point. Track codes should be based on the actual track, not the meet. That's why they are called "track codes" and not "meet codes". It's not a matter of whether the programmer can transform the codes; it's the matter of why should we? And your laissez-faire attitude toward this is the reason that companies get away with stupid ideas and shoddy customer service. But that's -- as you wrote -- par for the course.

[MJC922]

Originally Posted by The_Turf_Monster

It sounds like you don't have requirements and consume Equibase's data as-is. For this, a best practice would be the implementation of a balance and controls process to identify any non-conforming track codes and to alter them in whatever transformation process you may have or may need to implement. It's a non-issue and par for the course imo, hardly something to fault Equibase for.

To be honest it actually is quite a headache to deal with. I would need to download charts overnight using a new track code, so that's one application that needs attention (the downloader). Then we have a data processing application that will take what's in those downloaded charts and place that data into the DB, it's here that if I were doing speed figures (luckily I'm not) I'd have to do the select case because the course is unchanged, although I should at least do it anyway for trainer / jock stats and I don't because more headache than it's worth IMO.

Then another application, I need to download the entries all day long as they become available and those files will have the new code in the filename.

Lastly with downloaded entries files I need to generate the actual product itself which is a new file and have that filename contain the new code instead before uploading it.

It's a massive and unnecessary headache for anyone generating product. All of us can do it, it's a major annoyance though and there really should be no need for it to spill over into the data processing realm like it does.

[thespaah]

Originally Posted by v j stauffer

IMO they couldn't find anything wrong with the track because there isn't anything wrong with the track.

If there was barns like Asmussen, Cox, McPeek a guy like Ian Wilkes or Randy Morse would have hightailed it long ago.

Race horses are going to break down if they run over cotton balls. It's something we've all had to reconcile even though we hate it.

This is a MORONIC overreaction to nothing.

What happens when they return and on the first day back a horse breaks down. Through no fault except of the inevitable numbers?

Close CD forever.

UNBELIEVEABLE!!

Speculation here.
CDI is a publicly traded company. As such, subject to the whims of traders. Modern stock trading is such that negative reports, accurate or just rumor, can cause a company can lose a significant percentage of its market capitalization in a matter of minutes.
That said, I think CDI has reacted to the protests and negativity on social media by trying to play CYA.
Again, pure speculation.