XML data of active tracks

[togatrigger]

I'm looking an xml/json or an api to query information that I can use to list the active tracks, and the individual races over the next few days or the days that have available past performance data.

I am aware of,
http://www.nyra.com/totedata/totetrack/totetrack.xml
which would give me upcoming races and post times for them.

and, trackmaster has an XML data file,
http://www.trackmaster.com/cgi-bin/xmlFileList.cgi?tmu
which lists all the days with available past performance data (my current option)

I am curious if the other providers have similar resources that I can use to interface with active tracks. I am aware of the HTML lists from bris, drf, and equibase but I'd rather not scrape the data, for obvious reasons.

Thanks,

(for some context: this is in developing a x-platform application to obtain, analyse, and manage pp data; so if anyone else has some information in any of these vectors please include it if possible).

[Dave Schwartz]

First, check out this thread:

http://www.paceadvantage.com/forum/s...ad.php?t=77114

[togatrigger]

Thanks Dave, I'm not sure what point in your post you (think) applies to me. I would like to do this in a way that would promote and provide a front-end for the providers of the data. I guess you're suggesting that even using that (free) XML feed is enough to constitute hammering the server and entail repercussions(?).

[BillW]

As a complement to what you are looking for, Equibase has an XML feed of the daily scratches and changes ...

http://www.equibase.com/premium/eqbL...MLDownload.cfm

Schema available at the bottom of the page here ...

http://www.equibase.com/static/latec...techanges.html

[togatrigger]

Thanks Bill. This is very helpful. I was looking at using the plain text from brisnet or drf. This is a much easier solution.

My intention is for these feeds to be hit only a few times a day for each user. The available races should be hit once a day, maybe twice at the most. That information doesn't get updated often, and knowing when it does would help limit that to a constant factor. As for the scratches, obviously a bit more. I'm not sure what is reasonable? three times between each race? Once? so, 15 to 45 updates a day. A big difference, but I also don't expect a power user to use this application, so those numbers can be cut down quite a bit.

[Dave Schwartz]

Toga,

No, I was suggesting that the majority of people want a desktop app rather than a web app. I assumed - perhaps incorrectly - that you were leading up to accumulating data for the purpose of dissemination.


Dave

[togatrigger]

Ahh... I actually agree with the majority of people in maintaining a desktop app for this kind of thing. I would never trust a record of my bets to an outside database, and (you mention about storing data) the third party (me), has no right in storing the pp data the user bought, so it makes sense a web app is not the right fit. A major provider could do it.

My project is a response to the serious lack of non-windows applications out there; along with steep learning curves and difficult user-interfaces in current packages.

[thorobasePA]

It doesn't really matter if desktop solutions are the preferred end-goal; for prototyping of new ideas, real-world data feeds of races, PPs and results is needed.

So I think we need an API for details like this. I had made an exploratory attempt with thoroData for this, but it needs to be refactored for the future.

@togatrigger, if you are going to be looking into working with these XML feeds, I'd highly recommended taking a look at YQL. It will allow you to easily build webservices, work with it using SQL-like statements and let Yahoo! take care of the hosting and caching.

[togatrigger]

A common API is something I would love to build. This way end-users can use the same interface to purchase from _any_ provider they choose. The advantages to the users are huge. Unfortunately, I don't think it's very attractive to providers until the software package becomes popular, and is stealing business away from them --on the assumption that a single provider was established.

Interesting choice in using yards. I guess that makes more sense.