Rider limit increase?

[aaronwelsh]

Hi guys,

I was a 2016 FS participant, then I slept on registration last year and was locked out (I think I probably tried to register around 12/15 or so). I’m already signed up for this year, but on behalf of my fellow procrastinators, I wanted to suggest increasing the FS roster limit from 250.

As cycling infrastructure continues to improve and FS continues to be more popular, shouldn’t people be included? I don’t know the details, but it seems like the cost of adding more people is low.

More participants means more regional cyclists, more forum friends, and more fun…… right?

Topic

[lordofthemark]

@hozn 168725 wrote:

So there are a few reasons for the limit:
(1) Simply supporting issues people have. Inevitably people will request help because their ride is not showing up, their photos are not showing up, they aren’t getting credit for riding with someone else, etc. When you have this many users there is just a % that will need help — and also use cases that find bugs in our software. Moving to exclude manual rides has helped minimize those issues, but this is still a concern.
(2) One limit we’re pushing up against that is motivating the 250 limit is that we can only make 500 weather-related API calls per day. So if we suggest that most people are posting 2 rides per day, 250 participants would saturate that limit. Granted, in reality the number of calls per day is probably less than 2x total participants. We could increase the API limit by buying commercial tokens … but not sure who’s gonna foot the bill there.
(3) There are also API limits for Strava itself, though they’ve increased the limits for the freezingsaddles application, so we could probably double our roster and still be ok from strava.com perspective.

So, for the above, I think (1) is the most pertinent issue. If we had some sort of nominal registration fee than (2) could be a non-issue, though I think once someone starts taking money from participants we have an entirely new type of activity going on and I believe there are liability etc. implications there that I’m sure no one would want to touch.

I am going to do my part, and try to not post multiple rides a day, because I keep stopping and starting Strava. Note though, that the inability to post manual rides makes the “Strava trust” issue a bit more trying.

[SolarBikeCar]

@hozn 168797 wrote:

Yes, the data is location-dependent. A solution here would be to make a grid and “snap” nearby locations to the same lat/lon coordinates so that we could take advantage of caching (which we do already do) and everyone in a (e.g.) 10-mile radius gets the same weather data applied to their rides. This is probably as simple as decreasing the precision/scale of the coordinates, but I’d like someone with more geospatial knowledge to weigh in on that.

That’s what I’d do as well. Round every geo-point to 1 decimal place. Most of the metro area riders would be in the 36 geo blocks between (38.6,-78.4) and 39.2,-76.. Each of the blocks would be roughly 5 square miles. People outside the area would cluster around a few more geo-block areas. If you took last years data you might find you have only 100 or so unique values once you rounded every geocode down to 1 decimal of precision. I’d then give everyone in that geo-block the weather as returned by the API for the center of the block (i.e Lat+.05,Lon+.05). This method would adjust to the minimum number of geo-blocks needed each day and could vary as players travel to far-off places and returned.

.

[LhasaCM]

@hozn 168725 wrote:

(2) One limit we’re pushing up against that is motivating the 250 limit is that we can only make 500 weather-related API calls per day. So if we suggest that most people are posting 2 rides per day, 250 participants would saturate that limit. Granted, in reality the number of calls per day is probably less than 2x total participants. We could increase the API limit by buying commercial tokens … but not sure who’s gonna foot the bill there.

As someone who generally has 4 or 5 rides a day to maintain the integrity of my #kidical reporting and so disproportionately taxes the backend – what kind of a bill are we talking about here? Is it something like the $20/month for the “Drizzle” level of the Stratus plan at Weather Underground?

[hozn]

@LhasaCM 168856 wrote:

As someone who generally has 4 or 5 rides a day to maintain the integrity of my #kidical reporting and so disproportionately taxes the backend – what kind of a bill are we talking about here? Is it something like the $20/month for the “Drizzle” level of the Stratus plan at Weather Underground?

Yeah, it’s something like that at worst. But I wouldn’t worry about it; some folks ride more than a couple times a day, but many don’t ride at all. I think it works out right now to be about right (maybe a little under) with 250 participants. I might also just ask wunderground.com if they’d donate a license / increase API limits for this app, since it’s an free/open application & competition, etc.

[hozn]

@SolarBikeCar 168854 wrote:

That’s what I’d do as well. Round every geo-point to 1 decimal place. Most of the metro area riders would be in the 36 geo blocks between (38.6,-78.4) and 39.2,-76.. Each of the blocks would be roughly 5 square miles. People outside the area would cluster around a few more geo-block areas. If you took last years data you might find you have only 100 or so unique values once you rounded every geocode down to 1 decimal of precision. I’d then give everyone in that geo-block the weather as returned by the API for the center of the block (i.e Lat+.05,Lon+.05). This method would adjust to the minimum number of geo-blocks needed each day and could vary as players travel to far-off places and returned.

.

Great – thanks for that implementation suggestion! I’m glad this approach is indeed quite simple and this sounds like a pretty straightforward way to stretch our wunderground.com api allotment without really losing much granularity.

[Author]

Replies