Freezing Saddles scoreboard software updates

[hozn]

I’m starting a new thread to collect future updates on the scoreboard (as opposed to my previous practice of starting a new thread for each update).

I fixed the issue with team/indiv various leaderboards not displaying. In doing so, I noticed that some of our leaderboards are heavily skewed due to invalid data. In particular, the “Time in the Saddle” (i.e. summed “moving time”).

I’ve commented on some of these rides so hopefully the riders can clean them up. I’m tempted to just exclude manual entry rides from any of the leaderboards (other than points). If I had my druthers, I’d exclude them completely, just as Strava does for their challenges, but I realize that would be viewed as unfair. (And, of course, I didn’t write the rules; the intent of the scoreboard app is to conform as best as technically possible to whatever the established rules are.)

Unfortunately, the problems extend to rides that have a GPX track too — I commented on these too — so excluding manual entries won’t take away the need for some oversight of erronious data in the scoreboards. Of course, this oversight requirement problem grows linearly with the number of contestants. If the size of the competition changes dramatically in future years, I’ll need to invest in better tools to help manage the noise. I’m comforted by the fact that we’re at least capped by the number of riders crazy enough to ride in winter conditions. But I realize FS participants are still a small fraction of those actually commuting these days.

Topic

[Steve O]

@hozn 109327 wrote:

wunderground.com

If you find a discrepancy in their data vs ours, let me know.

Here is the specific observation that was being used for the start (07:49) of your ride in “Vienna, VA” (the location of your ride, according to Strava — we take shortcuts and use the city when possible due to limitations in wunderground api usage allowances):
{
….
“fog”: “0”,
“hail”: “0”,
“heatindexi”: “-9999”,
“heatindexm”: “-9999”,
“hum”: “40”,
“icon”: “clear”,
“metar”: “METAR KDCA 201252Z 31008KT 10SM CLR M13/M24 A3042 RMK AO2 SLP302 T11331244”,
“precipi”: “-9999.00”,
“precipm”: “-9999.00”,
“pressurei”: “30.43”,
“pressurem”: “1030.2”,
“rain”: “0”,
“snow”: “0”,
“tempi”: “8.1”,
“tempm”: “-13.3”,
“thunder”: “0”,
“tornado”: “0”,
//

This has to be right. I distinctly remember there was no tornado that morning.

[Steve O]

@consularrider 109338 wrote:

I know that my closest weather station (Westover KVAARLIN28) was reading about 2°F that morning.

And since I live about 300 yards from consular, I presume mine was about the same.

[creadinger]

Yeah, I was thinking there was something wrong with the data matching up rides with temps. As of yesterday, it still said that my coldest ride was in early January – 12 degrees, measured in King George, VA.

I did an AM sleaze ride last Friday when it was super cold and everyone was in single digits or below zero, and it still lists 12 degrees as my coldest ride.

[hozn]

I guess the short answer is that the penalization does not selectively discriminate …. The better answer would be to always use lat/lon rather than town names. I am not sure the api limits will allow for that, but I will look into it.

[Author]

Replies