sources for satellite data in Cesium compatible form ...

Hi. I’m not sure if this is a good place to ask this, but here goes.

We’re using Cesium to do computations on geospatial data, for a mobile augmented reality project. I’d love to find some good sources of real-time data for satellites (e.g., the ISS) that I could use to demonstrate and test the project (e.g., I’d like to be able to look up with our web-AR viewer and see where satellites are in the sky).

What I can’t figure out is where to get this data. I’m a computer scientist, not a geo person, so I’m unfamiliar with where I could get these data feeds and how to convert the data into a a cesium entity. All of the example I can find on the web are displaying the data (e.g., showing satellites on a map) but none seem to say how to get it.

If anyone has some pointers, or code snippets, I’d appreciate it!



I’m not aware of any sites that provide real-time position data for any satellite. What is frequently done is to take a description of a satellite’s orbit which can be used to compute the anticipated position of the satellite assuming that the description does not change because of orbit adjustment maneuver. Those descriptions are typically provided in something called a Two Line Element (TLE) which can be obtained from CelesTrak. Each satellite has an associated identifier called NORAD ID, SSC number, or SCC number. The SSC number for the ISS is 25544 and the current TLE on CelesTrak is

1 25544U 98067A   16105.89927881 -.00000356  00000-0  18451-5 0  9994
2 25544  51.6453  13.7032 0001546  81.0820   9.4371 15.54196642995131

The satellite’s predicted orbit is computed using a SGP (Simple General Perturbations) mathematical model propagator. A JavaScript implementation is available and I think it was mentioned recently in this forum.

You might find Ed Mackey’s Satellite A/R app for Android here a useful source of additional ideas and information.

Hope that helps.


Check out shashwatak's github project satellite-js

It's an accurate enough implementation of the SGP math model Scott mentioned for what you need.
Also successfully implemented in jeyoder's ThingsInSpace webgl project:
and a few other places around the web if you poke around. :wink:



Thanks, that makes everything MUCH clearer. I’ll check out that sources.

Out of curiosity, how often do the TLE’s change? I assume they must change occasionally, but is it a daily/weekly/monthly kind of occurrence?

Thanks a lot, I will definitely check out that project on github!

(apologies if this over-answers your question, but I’m known for being long-winded :wink:

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 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 :wink:

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: 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. :wink:

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:

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: 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 :

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. :wink:

Cheers and Good Luck with your project !



I was trying to render the seafloor in Cesium but I had some problems.

I’m not sure what i did wrong

I used this elevation dataset srtm30plus_stripped.tif.gz from

I then built the terrain tiles with

and serving the terrain with

… but seems that underwater gets in trouble.

The terrain looks correct, mountains are rendered correctly but the seafloor is rendered above the terrain level.

I attached some screenshot [1] can you please help me to understand how to proper render terrain belove the sea surface?




Cesium’s “heightmap” data format only supports values down to -1000 meters, by definition, since all values use that as a starting point. See

I think the “quantized-mesh” format doesn’t have that issue, but the “cesium-terrain-builder” tool currently only supports heightmap output. No one has taken a shot at implementing quantized-mesh support for it yet.

(Also, this is probably the wrong thread for that question.)