Blair,
(apologies if this over-answers your question, but I’m known for being long-winded 
The question you ask sounds like a simple one, but unfortunately can result in very different answers, for reasons that may become obvious below.
Depending on the particular satellite associated with the TLE, you could see it being updated as often as once per day, or as seldom as once per week or longer.
This range of refresh can stem from a lot of reasons, but the “short” list is as follows:
It honestly depends on the vehicle’s relative “importance” in the pecking order of satellites (and the people charged tracking them), how often it makes maneuvers, and how “stable” an orbit it’s in. Obviously, the more it maneuvers the more it will deviate from the projected trajectory calculated (propagated is the technical term) by the SGP math, so it may get it’s TLE refreshed more often to account for all those changes to it’s orbital velocity.
Of course satellites that eventually de-orbit and re-enter the atmosphere will cease to be updated, but may remain in the overall SSN catalog and would likely have the “last” TLE “snapshot” associated with them. Trying to propagate a TLE that’s “expired” a long time ago (or in a galaxy far, far away) will result in data, because the SGP algorithm is kind of a (garbage-in -> garbage-out) kind of math, but it won’t be anywhere close to where the vehicle actual is in the sky.
So you have to watch out for the time/date stamp that’s embedded within the TLE itself… more on that in a sec.
That tells you how often they might get updated. In short, it varies…
You can look through the archives of data that T.S.Kelso has on his Celestrak.com website to get a sense for what satellites get “refreshed” and how often. I’d love for him to store all that in a GitHub repository so you could do periodic checkouts and diff’s against all the changes, get “pull notifications for changes”, and figure out all sorts of useful update metrics, but to each his own. I’m just glad he makes the data available in the first place.
Maybe I’ll eventually find the time to set up a system to mirror the data in git, assuming I have the rights to do so of course. If anyone wants to collaborate on a git-enabled TLE repository system that mirrors T.S.Kelso’s site, let me know
The real question is of course, “how often to I need to look for an update so I’m properly representing where the thing is in the sky?”
So I mentioned the TLE time/date stamp. If you look here: https://celestrak.com/NORAD/documentation/tle-fmt.asp you’ll see that columns 19-32 of the first line of each TLE encodes the “epoch” or “born-on-date” for when the TLE was created. Your code will definitely want to check that “born on date” when it tries to refresh the TLE.
Unfortunately, there’s no “expiration date” so you kind of have to go by general rules of thumb here, but largely driven by the math that the SGP algorithm uses under the hood.
Satellites that are closer to the earth are obviously closer to the atmosphere which acts as a drag on their motion. Drag can vary, and in unusual ways, which makes writing propagator code that accounts for all the variances very, very complex. SGP was written with “approximations” for how the drag gets calculated, so it’s propagated predictions tend to deviate from reality sooner than other satellites. These satellites are often termed “LEO’s” for Low Earth Orbiting. (Trust me, You’ll quickly get used to the acronyms.
At the opposite end of the spectrum are the GEO’s, or Geostationary Earth Orbiting satellites which make up the bulk of the {Primestar, DirectTV, etc…} satellites that make up most of our global telecommunications infrastructure. Their position, so far away that their orbital speed makes them appear to stay synchronized “in positions” over the earth, isn’t affected as much by atmospheric drag, so the SGP math tends to predict their location a little more accurately over a longer period of time.
I’ve been overly simplifying things here, so if any of my fellow orbital mechanics colleagues reading this start having a “well, actually” moment, just roll with me here…
So, in general:
- TLE’s for LEO’s are usually “good” for 3-5 days.
- For GEO’s you can let the TLE get a few days older, 5-7 days on average.
Unfortunately, these are rules of thumb, and don’t account for the fact that a lot of these birds are “maintained”, meaning that for one reason or another they are maneuvering, and as I said at the start, maneuvering satellites need more frequent updates to the TLE’s.
The ISS which you’re primarily concerned with is a vehicle that’s classified as a LEO, and also periodically maneuvers to maintain it’s desired orbital motion, so it’s a double-whammy on the propagated accuracy of any given TLE. For this vehicle in particular, you’re going to want to look for a refresh cycle that’s every 1-3 days or so. That’s not to say that you can’t get decent results if you let things slip longer, but your taking some chances.
I don’t recall how often T.S. is updating the TLE for ISS on his website, but NASA is continuously updating it’s predictions for the ISS’s position, for the very reason that lives are a stake, so it ranks pretty “high” in the satellite pecking order, but generally they only publishes updates for the ISS TLE on a daily basis. A good authoritative and official NASA source for just the ISS can be found here: http://spaceflight.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/orbit/ISS/SVPOST.html
and if you scan through the text data it returns, you’ll actually see multiple published TLE’s throughout the document. Remember those time/date stamps I mentioned ? Look at the diff’s between them to get an idea of the actual “tempo” of when and how frequently they publish.
I haven’t found a link that returns the same data in {JSON}, to make parsing easier, and would love to hear anyone who knows of one.
NASA does have this site: https://data.nasa.gov/developer for anyone wanting to tie to some the web API’s that NASA has exposed.
It’s got tons of cool services to play with… and I’d love to hear if anyone builds anything sexy with Cesium.js and some of the API’s they’ve exposed.
Post it here of course!
Interestingly, and most ironically because of the way you originally asked your first question, there does appear to be a site that exposes the “current” position of (just) the ISS in a RESTFUL way with returned JSON : http://open-notify.org/Open-Notify-API/ISS-Location-Now/
So, now that I’ve dragged you through much, much more info than you probably cared or wanted to know about orbits, TLE’s, satellites and the math(y) ugliness in accurately predicting their motion, the simplest solution for your VR system might just be calling what the open-notify folks have exposed, but then you wouldn’t have understood all that’s happening underneath.
Cheers and Good Luck with your project !
-Frank