Edit: Klunky hack you can pop in the URL bar to make it go zoom:
You may need something other than .001, depending on what frame rate you're getting.
(Edit edit: There's something to be said for this whole "web" thing sometimes. It's neat that we can hack on code like this....)
I used the subset of the decaying data from spacetrack.
Can you imagine the perils of trying to keep a 300m-long starship in orbit, without hitting all the bits of rubbish? Sulu would have been doing slaloms for half of every episode. (Although they could probably spring-clean a planet of orbital debris within a few hours, too, just vacuum it all up with a tractor beam).
As Spock so eloquently put it in ST4: "Judging by the pollution content of the atmosphere, I believe we have arrived at the latter half of the 20th Century."
If modern-day humans are able to predict its orbit, the Enterprise... any of them... can handle it. As befits a science fiction ship.
EDIT: But now Chromium at least is doing fine.
Doesn't this denote a defect on the browser's part?
We ran out of time so it doesn't actually cascade but it shows the rather high likelihood of collisions if you fast-forward with the slider on the bottom left of the screen. Pull requests would be very welcome, the data from space-track.org generally is great fun to play around with (as is three.js and satellite.js).
That said I'd still prefer to be on-location as there was such a wide range of people with different backgrounds who were all super inspiring and a joy to work with! There actually weren't enough programmers so I got to hook up a lidar to an Intel Edison for another team which ended up winning the Intel price - the team leader even gave me one of those Edisons and invited me to visit Google NYC.
Yupp, I'm a lucky bastard :) and I didn't even mention that Lord British gave a talk too  (he bowed when I thanked his honour for being an inspiration since my childhood).
If you are only slightly interested do participate in the next Space Apps Challenge!
And yes, we were using satellite.js  which provided us with the propagation functionality together with a static set of TLEs from space-track  - I'll add an github issue for adding support for dynamic aggregation of that data right away actually :)
Are these orbits to optimize directness during the day, at the expense of the night? If so I guess that would explain why they tend to favor the southern hemisphere over the dark side of the Earth and the northern hemisphere over the light side (because that's where population is concentrated).
The most obvious way is an circular equatorial orbit at 35,786km. As I'm sure you know, but others may not, the orbital period at that distance means that the satellite completes one full orbit in 24 hours, thus it completes a circle in the same time that the earth does, so it's always over the same spot.
There is also the concept of a Molniya orbit (https://en.wikipedia.org/wiki/Molniya_orbit), where you have a small cloud of satellites (at least 3) with extremely elliptical orbits that together can provide coverage for non-equatorial areas.
If you come up with the satellite's name or designation you found, it's probably relatively easy to determine why it is at the inclination it has. Do you remember what it was you found?
For arbitrary examples, see Palapa 1, Insat 1A, Raduga 6.
Edit: And furthermore, wouldn't the spread be somewhat random with respect to the longitude of the ascending nodes? This seems to be anything but random: http://imgur.com/FQpTkLR
Regarding the non-random spread.... all the orbits start at the same place (0 deg inclination - because that's where people want them). And it's the same sun and moon affecting all of them them in the same way, so you wouldn't expect it to be random. It is interesting that they all appear in that band, I don't have a good explanation for that : )
Two features that I wish this had:
1. A way to focus on a specific point on the Earth's surface.
2. Being able to switch perspectives and look up into space from said point.
Thanks for sharing
Essentially, how do they avoid this: https://youtu.be/O-d8BJ2iljc?t=33s.
So simple, yet very powerful tool to grok intuitively quite a few things: geostationary orbits - and to see at a glance why latency is going to be a problem; the issue of coverage for satellite phones etc.
Edit: Looks like the NASA one still exists (http://science.nasa.gov/realtime/jtrack/3d/JTrack3D.html/) but it's a pain to get it to run because of Java security, and seems to be broken. Won't run in Chrome, broken display in IE and Firefox.
They also used it to surveil/recon the United States as it can loiter in US airspace for a while.
Might try and integrate this visualization with a new tool I'm developing called D2D , based on a new solver called Atom , to model high-thrust debris-to-debris transfers for multi-target active debris removal mission design.
But if you've got that many stations/satellites that you want to keep, you're on your own :).
A few ideas:
* Those spots are the furthest possible distance from the equator (in angular terms), so they should be the most expensive places to put something in orbit (either you launch from a northerly/southerly latitude or spend a lot of fuel on maneuvering into that orbit either way that's expensive)
* Maybe Earth's magnetic field interferes with electronics (less protection from the sun's radiation)
* No one really lives there so there's fewer reasons to spend a lot of money putting something in orbit
* Some kind of international agreement/rules
Maybe someone more knowledgeable could weigh in!
That said my knowledge comes from playing KSP with the scansat mod.
Here's a histogram of the orbit inclinations where you can see this:
Here's the raw orbits data that the site uses:
One possible explanation is the combination of the iridium 33 collision debris field, which is in orbits with inclinations around 86 degrees, and Fengyun 1C debris, which is around 99 degrees (so, 81 degrees but going the opposite direction). The limit of the distributions of those two clusters might account for the clear 'edge' of the circle around the pole.
98° inclination is the same as 82° in retrograde (against the earth's rotation).
No network traffic is generated after the initial load so my guess is that this JSON file is generated on the server from some other data source and is read on load and then continues to calculate positions from that initial load. The data on the server changes every 10 - 15 minutes it seems...must be a script updating it.
Some of the API names from space-track match what's in TLE.json, so it's probably just fetched and post-processed every couple minutes.
Maybe some kind of solar sail salvage drone could do it.
Steam punk, space stations cobbled together from bits of old rockets and satellites.
Well due to (IIRC) the Outer Space Treaty, spacecraft launched is still owned by their original company and I dont think the original company, or anyone else for that matter wants to pay to cleanup their trash, therefore no market.
Didn't get interviewed for most likely that reason.
At the very least you could salvage a blog post out of this. :)
Because of this we went with surface based lasers; they could be recharged using the local grid and clean a specific section of the sky. We looked at placing lasers at locations with high altitude and cross referenced them with the local $ per kilowatt hour. Never really got to the stage of deciding where to place one since we were still stuck with figuring out the market for it. I guess someones active satellite needs to get Sandra Bullocked by some old debris before we start going "hey. there's a market for cleanup!".
The ISS is currently looking into a laser system to clean up debris if i remember correctly. I guess if they ever figure out the person who uses it would get to call him/herself "ISS Door Gunner"
Fake the scale (at least for the orbit size) and it's doable.