THE BOOK--Playing The Percentages In Baseball

Nice work over, Gameday is great and getting better all the time!

Are there any plans to provide trajectory data on the batted balls?

Any plans to mark not only the location where the ball is fielded, but the spot where it landed?

The stadium outlines do not seem to be drawn to scale (e.g. the foul lines are not 90 degrees from each other, the outfield walls don’t seem to match in terms of distance, direction...) Any plans to provide more accurate stadium diagrams/outlines?

Any chance you could include the ball path after the hit, i.e. trace the ball through hit, throws, etc.?  It would be great to see how the realy on a double to the gap nailed the runner at the plate…

Could the same technology that gives us the pitch speed and angle of break be programmed to give us the speed of the hit ball as it leaves the bat and the horizontal and vertical angles of the hit ball off the bat?  Hit ball speed and initial direction are the most important pieces of information that we don’t have.

I find that the pitch speed and break printed information doesn’t stay on the screen long enough to fully process it.  Could it stay up in the right top corner until the next pitch?
Could you explain exactly how the break amount and break angle are calculated?

1.  When will EG be rolled out to additional parks?
2.  With the release point data, the y-value (the depth component) is held constant.  Clearly some pitchers will release the ball closer to home plate than others.  I know this information is particularly relevant when displaying the release point in 2-d.  Which gets to the bigger question of are we making too much out of the data being captured?  Is this data being captured solely to display/plot elements in EG, or is it accurate enough to be used for other analyses?

Joe/Peter: “The mlb.com hit location data omits the hit location of errors. [Can you] include hit location of errors in EG?  Certainly wouldn’t require any new changes in technology, just a change in policy.”

Australian Football League will be monitoring their players electronically:
http://australianit.news.com.au/articles/0,7204,21517049^15306,00.html

What are some of the considerations in implementing this in MLB?

And, if the NHL beats you to the punch (I imagine putting a GPS in their sweaters so they can track ice time, as well as the cardio-monitoring of the Aussie league, would be a foregone conclusion), will that make it easier to implement in MLB?

The lazy man’s question:

Are there any plans to have the pitch information data (speed, break, etc.) accessible in some way to users lacking XML parsing skills?

I suppose it would be good to put an explicit request in this thread for a response to Beamer’s look at the apparent discrepancies in measurements between EG parks.

http://www.hardballtimes.com/main/printarticle/under-the-skin-of-enhanced-gameday/

Along the same lines as #4 and #8: does MLB have specs on the error bounds (absolute accuracy and repeatability) of the location/speed information in gameday, and are they willing to release that information?

Great job to you. I want to ask is it possible to translate the ball position and type of ball batted on Gameday to measurable data (like Stats Inc. did)? Then maybe we sabermetrics fans can know more and study more about fielding.

I have a less technical question: are there plans to make a mini-Gameday for those users who don’t need so much information?  Sometimes I just want to get a quick feel for the game, but loading gameday takes a while, and once it comes up there’s an information overload.  Other times, I want to keep an eye on the game but continue to work on my computer; last year there was a compact version with only the “need-to-know” info.  I’d love to have something like that again.

(Also, Gameday is kind of a resource hog, but that’s a story for another day.)

Slightly off topic but I understand Questec and Enhanced game day used the same technology, so does this mean every park where enhanced game day is running, like Toronto, is also using Questec to evaluate the umpires (for some reason I can not get a current list of Questec parks when I google this, it runs from 10-23 to almost all).  So I guess this leads to a game day question, which is in which parks is it available, and what is the criteria for when it is used?  For example, I have only seen enhanced game day at Fenway on Dice-K’s first start in Fenway against Seattle, but why not all games?.

2 things:

1) Thoughts on accuracy of the EG system and what the plan is to ensure consistency

2) More specifically what the ax, az, ay components mean in the XML

3) Will it remain a free resource?

I’m also curious about the accuracy of the data and whether the data is even meant to be used for analysis.  I had a couple technical questions too.

Do the pfx components mean anything relative to a batter, can you tell if a ball breaks in or away from a hitter?

What does break angle measure?

When calculating break length, is a line perpendicular to the ground used or a line perpendicular to the trajectory of the pitch...or something else I didn’t mention?

Thanks a bunch for taking the time to do this

Hi all, this is Cory Schwartz, Director of Stats for MLB.com. If it’s OK with everyone I’ll just take the questions from the top and answer them one at a time… I have about 30 minutes so I’ll cover as much ground as I can.

Question #1:

To your overall question, tracking the ball after it’s hit—batted ball trajecory, fielding location, throws, etc.—is something we hope to accomplish with a “version 2” of the technology, but we don’t have any immediate timeline on it. Our immediate focus is outfitting all 30 ballparks with the existing technology.

As far as the stadium graphics, we are aware of some inconsistencies in those and our design crew is working on cleaning those up.

Question #2… I hope my reply to question #1 covered this?

Question #3…

The display of the data in Gameday is based on how quickly new events are updated. We can tweak this somewhat operationally but it also depends on the pace of the game.

Break is defined as the measurement of the greatest distance between the trajectory of the pitch at any point between the release point and the front of home plate, and the straight line path from the release point and the front of home plate. By this definition, a Barry Zito curveball will have a much greater Break value than a Brad Penny fastball.

The angle of break is the difference between the pitch in perfect perpendicular to the ground, and the actual trajectory of the pitch. A pitch that drops straight down from the release point to the ground would have a 0 degree of break, and the more it breaks in to or away from the batter, the higher the angle of break. I hope that makes sense?

Q#4

We are working to roll out the system in all 30 ballparks by the end of this season.

Re. the “y” coordinate, the cameras pick up the pitch 55 feet from home plate, so that’s as closely as we can track the release point given the existing technology. If the average pitcher is 6’ tall and strides 80% of his height, that gets us pretty close the exact release point. That said, the major emphasis of the technology right now is tracking the speed, trajectory and location at home plate.

Q#5

The x,y coords include all balls hit into play, regardless of outcome, including errors.

Q#6

We’ll certainly consider any technology—existing or new—that helps us better track the various moving pieces on the field… the ball, baserunners, even umpires. But given that Sportvision has been using this technology for MLB games since 2001, we think we’re on the right track!

Q#7

We’re still discussing internally how to best provide the data for wider use. But getting it into the hands of researchers who want to work with it is definitely a goal of this project.

Q#8… first of two parts…

Regarding the tracking of release points, there are several factors that could come into play here. While we use the same standard camera locations in all ballparks, we don’t have access to the same exact locations in each park. Mounds may be different heights or sloped slightly differently. And, most importantly, the cameras are oriented more directly to home plate, and calibrated more accurately in the vicinity of home plate as a result.

By our measurements the accuracy of the release points should be within 2” or less, and the longer we track the ball the more accurate the measurements, to within 1” near home plate.

Keep in mind that a baseball is about 3” across, so accuracy of 1-2” is more than reasonable.

Second part…

We think there’s some great work done here and the Sportvision engineering team is looking at it closely to see if there’s anything we can learn from it. But we do question some of the conclusions also… for example, the “release and plate speed” graphs suggest that there are biases between one ballpark and the next. However, we read these graphs to mean that Millwood’s release velocity (as we measured it) was very consistent across all ballparks, but the rate of deceleration varied… humidity and other atmospheric conditions could account for this, rather than system error.

Q#9

As mentioned above, the system has been thoroughly tested and consistently measured to track the ball within 1” as it approaches home plate.

Q#10

As mentioned above, we hope that a “version 2.0” of this technology would make more accurate and detailed fielding data available in the future.

Q#11

Yes, Gameday was a major resource hog at the start of the season… but I’m happy to let you know we rolled up new code yesterday that should drastically reduce the resources it uses. In fact, in testing it performed faster with the 3D pitch data than last year’s version performed without it!

Apologies if this was asked already: what about eventually adding pitch type (i.e., curveball, changeup, etc.)?

Q#12

We’re not operating the Questec system so I can’t answer questions about it. But, we are operating pitch-f/x on a ballpark basis, so if we have it for one game in Seattle, we’ll have it for all of them, which we do. It’s not up and running in Boston yet, but it will be later this season.

BTW, we ARE operating the system for all Texas Rangers home games, and I hear C.J. Wilson throws a gyroball, too…

Q#13

* Re. accuracy I hope I’ve addressed that above to some extent?

* The a* variables are rates of acceleration.

* This is still a topic for internal discussion. As mentioned above we do want to share the data with researchers as widely as possible, but at the same time, we have to do so in a way that is economically feasible for MLBAM and for Sportvision.

Q#14… I hope I’ve answered these to some extent with the above replies?

Cory, thanks very much for your time.  We all appreciate how open MLB.com is to sharing their data, as well as how forthcoming you are in the details.

Thanks for everyone’s questions and your interest in the data and Gameday. I hope I’ve answered all of the questions at least to some extent, and I’m sure Tango will let me know if there’s something I’ve missed!

This system is still in the ramp-up phase, and while we’re very happy with the results so far, we will continue to look at any way we can make it better as we continue to roll it out. Ultimately we feel we’re building what will become the industry standard for determining every thing there is to know about the pitch, and someday, even more…

Thanks again!

Yes, the info is very useful, thanks to Cory and Tango for putting it together.

BTW, I can confirm that x,y info is indeed present for balls where an error is committed.  I just checked my data and found a reasonable x,y distribution for balls that were mishandled.

Cory

Thanks for coming along and answering all the questions. Much appreciated that you folks are so open on this ...

John

While I appreciate John/34’s sentiment, I’ll deflect any kind remarks away from me.  I am only a conduit. This blog represents you guys, and it’s your efforts that deserves applauds, and that attracted MLB.com here in the first place.

Cory, and whoever else at MLB.com that sanctions these talks, deserves 100% of the credit for being involved here. 

Here’s hoping that MLB.com can be our Linus Torvalds.

John #34 - is your data sourced from ESPN Gamecast instead of mlb.com Gameday? Errors are indeed missing from inning_hit.xml files associated with Gameday; however taking another look at the Gamecast application, errors are included in the display there(among the “hits"). But I don’t know how to access that underlying data.

Gameday and Gamecast are very similar (though I’m not aware of an enhanced Gamecast!). I assume their data derives from the same source.  I don’t doubt that mlb.com records the x,y location of errors in their database; I just don’t see that they are available through Gameday or the files visible on the web.

Hi folks, re. Q’s #5 and 37, sorry I misunderstood… you’re right that errors are indeed missing from the inning_hit.xml files, although they are included in the individual inning files.

This acutally isn’t surprising, as the inning_hit.xml file was built to support the “spray chart” feature on Gameday, which specificially filters by hits and outs, while errors are of course neither. I’ll discuss this with our development team and see if we can find a logical solution.

Thanks for the feedback!

Folks, it’s been a while since this topic came up, but we’ve added errors to the inning_hit files:

http://gd2.mlb.com/components/game/mlb/year_2007/month_06/day_20/gid_2007_06_20_pitmlb_seamlb_1/inning/inning_hit.xml

Look for type="E"

Thanks for mentioning it.

Thank you for addressing it, and addressing it so quickly! I see that in the Gameday front end, error locations are visible when filtering for “hits” but appear with a differently colored dot than actual hits.  As a bonus for those who work with minor league data, I see that errors also appear in inning_hit.xml for those games as well (at least the AAA game I checked).

Hey Cory,

I have a good idea about how to provide gameday data that is economically feasible. You guys can provide the “raw” xml files for free, and do intensive analysis stats/graphs that are paid-only. I mean it wouldn’t hurt to put xml files since only minority of baseball fans really interest in quantifying gameday data.

Andy,

The raw XML files are (currently) available for free, like here:
http://gd2.mlb.com/components/game/mlb/year_2007/month_07/day_01/gid_2007_07_01_anamlb_balmlb_1/pbp/pitchers/

Most of the top analysis is already being provided for free.

I understand. But this is not what I trying to say. I was referring to post #30 where Cory commented"we have to do so in a way that is economically feasible for MLBAM and for Sportvision”.

I was trying to say if MLBAM/Sportvision want to make a profit out of EG, maybe they can do extensive analysis on every pitcher/batter and sell it to clubs or baseball fans who are interested.

I mean no one understand EG better than Sportvision, right? Therefore, readers should be more willing to pay to read the articles that are written by Sportvision.

As for raw XML files, I think it’s ok to put it online for free, since only very small part of the baseball fans are interested in playing with XML files.

Hat tip: Dan Fox

http://webusers.npl.uiuc.edu/~a-nathan/pob/pitchtracker.html

I was working with the pitch data this weekend and I uncovered a data issue that may or may not have been discussed.

When there’s a pitching change in the middle of an at-bat, all the pitches appear to be credited to the reliever rather than whichever pitcher threw them.

For example, on July 14, Yovani Gallardo relieved Ben Sheets in the middle of an at-bat to Todd Helton.  Although Sheets threw at least 7 of the pitches in the at-bat, the entire at-bat is recorded with Gallardo pitching.

Obviously, this doesn’t happen that frequently during the season, but there’s probably at least a handful of at-bats where this would be an issue.

The correct way to solve it IMO would be to move the pitcher id to the pitch element from the at-bat element.  Until that occurs, I’m trying to figure out how to deal with this.  Would it be more damaging to the data to create two separate at-bat entries or have the pitches go to the wrong pitcher? And does anyone know of an easy way to identify when a pitching change occurs in the middle of at-bat?

The mid at bat pitching change is documented by an “action” in the inning file (which also has pitch by pitch information).  You apparently are using the version of pitch information contained in the “pbp” pitcher or batter files. [The example you cited was from a “non-advanced” gameday file; I am curious whether it would be handled any differently in the advanced version.]

A partial solution is to switch to using the inning files; unfortunately (at least the last time I worked with them), the inning files also sometimes had bugs. The only nearly foolproof approach would be to cross-reference the different files, and log any discrepancies for manual review.

Since the mlb files also allow the atbat “event” field to be null (as for instance when the 3rd out is made with a pickoff or caught stealing so that the batter does not complete his at bat), I think the natural solution here is “split” the at bat into 2, with the first terminating in a null event, and the second showing the new pitcher, inherited count, and result.  However, there are complexities I don’t remember off the top of my head, such as the first pitcher still getting awarded the strikeout or walk depending on the count he bequeathed. Those scenarios are rarer still. The solution to these cases might be an optional attribute in the xml, noting the responsible pitcher in addition to the actual pitcher.

Dan,
I’ve listed all the occurrences at my blog in response to your comment there:
http://fastballs.wordpress.com/2007/08/23/how-to-build-a-pitch-database/#comment-88

Joe,
The problem is not in the files Dan is using.  It’s just the nature of the recordkeeping.  MLB’s XML files track pitcher and batter id’s on a per at bat basis.  Figuring out how to deal with that on a per pitch basis when an at bat is split between pitchers and/or batters requires a non-trivial adjustment to the parser code.  In addition, it would make the parser considerably less efficient, and I’m already looking for ways to make the parser faster.

Another interesting article by Joe Sheehan:
http://baseballanalysts.com/archives/2007/09/sinkers2.php

Even though the GB% for a sinker varies depending on its location, (and the percents are influenced by the small amount of balls in play), in every region sinkers are 20-30% better at getting ground balls than normal fastballs, as illustrated by the chart on the right. In fact, it looks like if you shifted the sinker chart down one set of boxes, it would line up pretty well with the normal chart. A sinker that ends belt high gets the same GB% as a regular fastball does when it ends at the knees.

Thanks Mike and Joe.

I guess the best answer now is what you’ve suggested and manually making the updates.  At least it’s only a few cases.

Mike, I’m working on putting together a follow-up to your blog post talking about how to automatically update the database daily.  It should be ready in a few days.  Thanks for all help.