|
JCapper Message Board
General Discussion
--
New JCapper Platinum 2025 Program Update Incoming
|
|
| By |
New JCapper Platinum 2025 Program Update Incoming |
jeff
8/12/2025
12:20:37 PM | I have a MAJOR program update literally hours away from release.
I had actually planned on publishing it yesterday, but discovered something while doing final Edge Case Testing. (Look that phrase up if you don't know what it means.)
This is what I discovered:
Yesterday for Ellis Park, all of the Temperatures in the JSon returned by the Current Conditions API Calls were either -443.10°F or -443.0°F.
There was also a single API Call for PID that came back as -459.7°F. It turns out -459.67 is absolute zero which means 'No Data. (Temperature in the TrackWeather Module is rounded to the nearest one decimal point.)
From there:- I put the new program update on hold.
- I spent some time doing Edge Case Testing (seriously look that phrase up) which involved exporting more than a year of TrackWeather Data from my SDK ChartRaces Table to .csv file.
- I examined 33,248 races from 08-01-2024 through 08-10-2025 and determined the following:
a. The highest Temperature in the data (for tracks where I decided to get weather data) was 102.1°F at FNO (Fresno) on 10-24-2024. Fyi,, many days were actually hotter than that where a decision was made to cancel. (FNO 10-24-2024 was the hottest day in the past year where a track actually ran.)
b. The lowest Temperature in the data (for tracks where I decided to get weather data) that actually ran was 17.1°F at Charles Town on 01-15-2025. Fyi,, many days were actually colder than that where a decision was made to cancel. (CT 01-15-2025 was the coldest day in the past year where a track actually ran.)
c. There was Exactly 1 Race where a bad temperature made it into the Resolved Races Data:
The entry in my SDK ChartRaces Table for Oaklawn 04-13-2025 R6 shows Temperature as: -77.5°F
- And that's what I really needed to determine:
The incidence rate of bad temperatures recorded in the data.
Which since August 1, 2024 turned out to be:
1 in exactly 33,248 races.
From there:- I sent examples of the bad Temperatures in the JSon to Visual Crossing. I asked them to look into it and get back to me.
This morning they sent me an email that reads (in part) as follows:
--quote:
Thank you for reporting this error, and I apologize for the inconvenience.
We’ve identified an issue with the incoming MADIS data stream that caused the problem.
A temporary fix has been applied, and we plan to deploy a permanent solution within the next one to two days.
In the meantime, we’ll continue working with the data provider to ensure the root cause is fully resolved.
Thank you for your patience and understanding.
--end quote.
- I added new code that performs Edge Case Handling inside of the TrackWeather Module.
It does a better job of validating the weather data contained in the JSon returned by the Visual Crossing API Calls.
Even though only one bad temperature made it into the Resolved Races data since 08-01-2024:
Existing code in the current TrackWeather API does allow bad Temperatures (both high and low) to show up on the TrackWeather Html Report generated in BOT Mode.
The new code that I added yesterday is designed to prevent that from happening:
My objective here is that you only see valid data on the report.
- I'm going to stress test the new Edge Case Handling code over the next day or so.
Once I'm satisfied that it's fully working as designed:
You'll see the New Program Version go up!
-jp
.
~Edited by: jeff on: 8/12/2025 at: 12:20:37 PM~
| Acorn54
8/13/2025
12:48:47 AM | thanks for being such a conscientious person, it is an honor to know you. people who purchase your software can trust you to put forward a top of the line product. that is rare these days.
guy
p.s. edge case testing seems like testing for outliers in making udms and verifying the data.
|
|