It would be nice if supporters could request a city update instead of waiting for it to happen automatically, which takes a long time. Of course there would have to be limits to that, and maybe those limits could be based on the supporter level.
Another option would be to have supporter’s active cities to be placed at the top of the update queue.
I came up with a similar idea, on a smaller scale: Single street (way) update
Maybe it’s not possible, but I thought after a small OSM edit, the whole city need not be reprocessed.
I like supporter perk idea!
I understand from James’s post that the city updates are what is giving him the most headaches recently, and he’s had technical issues as well. I do wonder if the latter is hindering the former, and if the city update issue could end up null once they are attended to. However I think this is a nice idea and another incentive to support the site development - especially as a supporter who has been furiously updating the OSM for my nearby area and is waiting for hundreds of streets to be added 
You and me both @kevincharlespels! I have all the streets in my city ( Keller, Texas - CityStrides ), But need an OSM update to update the data on 10 zero-node streets.
For me it’s Sardoal, Santarém - CityStrides and the surrounding concelhos/counties. I found public GIS resources on the municipal websites and have been furiously updating the OSM for these rural areas, which was a lot easier than how I was first doing it by running around with my phone snapping pictures of signs and taking notes!
Weirdly, some portion of the OSM data was imported in some cases - many new street names appear on my CityStrides lifemap, but the nodes for those new streets are not in the street list. I assume this is related to the problems James was having updating from OSM.
Also I love how different this rural area looks from the cities I’ve mostly run in, but I really miss a grid!!
I actually disagree even though I’m a supporter.
Having cities update on a cron job requires less work for James (ie he doesn’t need to build new manual update option)
Regardless of what limits are put on it (ex: city can only be updated once an hour/day/week/whatever), there will always be those that want it even more frequent. So the goal posts have been moved but there will be some that still want to spam update requests to get it more frequent.
At a certain point the more populous cities (that tend to have the most streets as well) may get so many users requesting updates that it monopolizes the update queue (may also stretch the limits of system as well since more streets across more users need to be reprocessed) and the smaller cities with less users or no subscribers may go very long stretches without being updated.
Although subscribers currently have certain perks by paying, this seems over the line IMO and like a pay-to-play type deal. Requiring users to pay for the underlying code to be updated more frequently so that the core feature/purpose of the site (ie street data to mark off) is a bit sketchy. If a user cannot afford to become a subscriber and the system is bogged down by subscriber update requests, the site may become useless for some non-subscribers in certain cities.
@Marty You make some good points. Maybe that’s why a limit on the number of single way updates might make more sense. 
There’s always going to be the anxious types, like me, waiting for a few (OK 10) [0-node] streets to be updated to get 100% (of my city).
I think it’s important to distinguish between things that are cool to have as a one-off, and those that have long-term uses and benefits. The city update code still has some bugs and hasn’t even cycled through twice yet.
It’s not so weird that the displayed map and the nodes don’t always match.
The displayed map on this site is generated by a different site (https://www.mapbox.com/) which is also based on OpenStreetMap. It gets regularly updated, and is merely a visual representation of the underlying OSM data.
The nodes, on the other hand, are what this site imports directly from OSM to determine what the roads are and whether you’ve completed one. Updating this data turns out to be non-trivial, and is the current source of many headaches.
Several times I’ve changed a road in OSM and seen the visible change on the map within a week. Yet the old node existed long after the visual map changed, resulting in a node in the middle of a field. At least until the next time the city was updated. (My home city was last updated on October 10.)
You are assuming that the update queue would be spammed by users requesting the same city over and over. I was suggesting some more simple: if currently updates take 2-3 months (granted, we haven’t had a second cycle of updates yet so the time might be actually less while the kinks of the process get fixed, making this request irrelevant), you can request the city to be placed af the top of the queue. By “limits” I meant that a city can’t be updated in less that some specific amount of time (a month, for example, so it doesn’t matter how many users trigger the update).
I don’t see this as a bad thing or as a pay per play scheme. You just give people that support the site a faster way to see their cities updates, in the same way that supporters get their activities processed faster.
Good point. Seems a few lines of code could easily limit the number of times a city gets updated.
Good points, thanks for reminding that it’s not just how CityStrides handles the OSM data