I missed the "About" link in the footer but still found my way to the repo [1], where the project is briefly explained including a ton of great example images. Thanks for that!
> This website (technology demo) allows you to aggregate and visualize massive amounts of air traffic data. The data is hosted in a ClickHouse database and queried on the fly. You can tune the visualizations with custom SQL queries and drill-down from 50 billion records to individual data records.
This is certainly missing some kind of legend explaining the colors of the lines, and what data is actually shown.
Is "red" high or low velocity?
And as an example, I do not understand what the "Boeing vs. Airbus" selection is trying to represent, as well as how "Altitude & Velocity" are supposed to be displayed at the same time.
Project certainly requires a bit more care if any discussion should happen around it.
count() AS total,
sum(desc LIKE 'BOEING%') AS boeing,
sum(desc LIKE 'AIRBUS%') AS airbus,
sum(NOT (desc LIKE 'BOEING%' OR desc LIKE 'AIRBUS%')) AS other,
greatest(1000000 DIV {sampling:UInt32} DIV zoom_factor, total) AS max_total,
greatest(1000000 DIV {sampling:UInt32} DIV zoom_factor, boeing) AS max_boeing,
greatest(1000000 DIV {sampling:UInt32} DIV zoom_factor, airbus) AS max_airbus,
greatest(1000000 DIV {sampling:UInt32} DIV zoom_factor, other) AS max_other,
pow(total / max_total, 1/5) AS transparency,
255 * (1 + transparency) / 2 AS alpha,
pow(boeing, 1/5) * 256 DIV (1 + pow(max_boeing, 1/5)) AS red,
pow(airbus, 1/5) * 256 DIV (1 + pow(max_airbus, 1/5)) AS green,
pow(other, 1/5) * 256 DIV (1 + pow(max_other, 1/5)) AS blue
SELECT round(red)::UInt8, round(green)::UInt8, round(blue)::UInt8, round(alpha)::UInt8
The redder the pixel, the more Boeing planes there.
The greener the pixel, the more Airbus planes there.
The bluer the pixel, the more non-Boeing/Airbus planes there.
The less transparent the pixel, the more planes in total.
White means all planes fly there, yellow means Boeing and Airbus dominate, red means Boeing dominates, green means Airbus dominates, cyan means Airbus+others, magenta means Boeing+others, etc.
Around Heathrow at least, there seem to be a few paths where Airbus and Boeing both fly, but seem to be reporting slightly different offsets within that path.
I wonder if that's a systemic difference in how they report their GPS position to ADS-B, or an actual real difference caused by slightly different autopilot systems, or something else?
I see you highlight that, but I believe the visualization is designed to be intuitive once you interact with it a bit—no legend stricty needed if you calibrate against what you already know.
Pick a flight you know (maybe one near yer home) and play with the options -- what patterns emerge? Red draws attention, “Boeing vs. Airbus” compares data, while “Altitude & Velocity” combines them. Explore hands-on; discovery often makes insights click better than instructions.
Awesome work, but please consider providing some contrast options. You can't see the country or continent boundaries unless they are full of tracks (or at least I can't.)
The ”race tracks” are left- and right-hand traffic patterns for arriving aircraft and touch-and-go training, typically used by smaller aircraft. The polylines going from airport to the surroundings are IFR (instrument flight rules) STARs (standard terminal arrival routes) for inbound/outbound planes; each vertex in the line corresponds to a so-called navigation star which usually has a 5-letter name.
COS's airfield is also used by PSFB so you'll see different patterns than a normal airport. You find similar patterns, though, near other military bases like here, near Pensacola and Eglin:
It appears to be where "you" (website visitors) have loaded page tiles. I was able to draw a little picture on the map by zooming in and panning around!
Apparently my 'easy' isn't the same as yours. There's nothing I could find in the code that describes what it is. You'd have to make a pretty big logic leap to figure it out. All you can see in the code (in config.js, not in index.html) is the dataset url (random string) and the description "this website", which tells you very little.
Over in r/ADSB, someone recently posted a 3D visualizer of live ADS-B data: https://objectiveunclear.com/airloom.html. A nice alternative to the standard 2D maps we're used to.
Reminds me of the galaxy view in No Man's Sky. Very cool. It's also the type of visualisation I'd imagine would be perfect seen through the lens of a Vision Pro or similar.
We have a an ADS-B receiver at Summit Station in Greenland which we use to track airplanes that produce RFI we see in our experiment. I've considered sharing data (since nobody else seems to have data there) but the feeding instructions always scare me (run this script that downloads a bunch of random crap as sudo... no thanks).
Please just give me a cURL command I can run... (perhaps some services have that, I haven't looked that hard).
(other sites are corporate or have sold out [adsbexchange], happy to contribute reasonable costs to get a feed, no affiliation, I just like sensor feeds, thank you for the offer and consideration)
I appreciate the information! And yes, the fact that most sites are corporate makes me really distrustful of running random scripts from them.
This is sort of an example of what I'm talking about though, this script seems to install a bunch of random stuff but what I really want is an API to incorporate into our own recording process. As far as I can tell from a brief look, this binary (?) is downloaded from somewhere and run: https://github.com/airplanes-live/feed/blob/main/scripts/air... but I just want to incorporate it in the system we're using already when I finally get to improving it from a 10-minute hack job from when I set it up as a side project that ended up being really useful (https://arxiv.org/abs/2506.17522)
I have to dive in a bit more to give good and specific guidance/context, but fundamentally, your system will require a shim to "speak" $UAT_SOURCE and the output this would expect, assuming the source was an sdr. Want help writing the code for this? Specs to build requirements RNO-G in -> SDR out are welcome.
yes, we have an SDR running some form of dump1090, then we are parsing json output from that and sticking it in a local sqlite database (we cycle databases once per day). Then that sqlite database eventually gets copied down. There are plans to improve our system to read a bit more directly but on low priority. It looks like these tools expect some format called BEAST that maybe can already be generated by dump1090, and then it's just a TCP stream to some endpoint?
Pretty much that. The SDR enthusiast's docker guide the parent comment linked to uses this ultrafeeder container, which has instructions on how to connect directly to dump1090 running on a port. Pairing that[1] plus the rest of the guide instructions should get you a decent ADS-B setup that can feed any of the services you might want - and if you don't want to use the Docker container(s), you should be able to at least use the services and configuration they use as a guide.
sdr-enthusiasts [0] produces some very nice self-contained Docker images as an alternative to the `curl | sudo bash` style of install script that plagues a lot of the ADSB ecosystem.
most likely all you need is their "ultrafeeder" [1,2] image.
You can get containerized feeders for services like fr24 (e.g. liggy1/fr24feed) but that may not meet your requirements since it's really intended to handle everything from the sdr to the API, not siphon off data you are collecting some other way and then feed it.
Yeah I definitely don't want to run an opaque container either. We're already collecting and storing the data... I am happy to throw the data over via a udp socket or http request, but I don't want random software that we don't control running...
If you're not comfortable running my readsb (fork of dump1090) which is the feed client used by live / lol / fi and some other sites, then you can probably just send them data using socat.
Most of them will have port 30004 open for their ingest domain, usually feed.domain.com.
Thus you'd hook up socat to 127.0.0.1:30005 (i assume you run dump1090 or readsb locally as a decoder).
And make socat send that to feed.adsb.lol:30004 and/or feed.airplanes.live:30004
If you're in a remote location, you don't need to worry about mlat-client as MLAT requires at least 4 receivers that receive common aircraft.
Is there a good documentation (or maybe code) reference to the protocols that get used here? Running readsb is fine enough by me, but I'm just interested in how these systems work. I see some mentions of a Beast format. And then there's the mlat-client too
And to be clear, I'm not necessarily against running readsb I just don't want to run random bash scripts that mess with a running system...
It looks like readsb is an evolution of dump1090 with potentially more features? I'll look into it when we consider reworking our software. For now I added a quick socat and I'll find out soon if it worked (no planes currently over Summit...). It would be nice if these websites advertised "Start feeding from your running dump1090 instance with socat tcp:localhost:30005 tcp:foo.bar:30004, here is a systemd service that does that."
edit: it worked! airplanes.live now tracking QTR28V from Seattle to Doha.
But to conserve bandwidth, it might make sense to send through a compressed ssh tunnel to something not in the middle of the Greenland ice sheet.
I had the same concerns awhile back and ending up running a slightly modified version of https://github.com/wiedehopf/mlat-client -- not quite as simple as an http push, but much simpler than a containerized feed client.
It's good to be careful. A popular ADS-B network used to distribute a raspberry pi image that let the maintainers ssh into your machine whenever they wanted.
I know! I think the creator, brilliant as they must be, is not an English native speaker. Or perhaps they simply enjoy the controversy / provocation heh :)
Eh I think the name kinda works from the perspective that it exposes patterns in adsb data. If you just glanced at adsb maps you wouldn't really see many of these patterns unless you stared at it for a very long time.
I love how you can clearly make out the VFR EAA approach going into Oshkosh from Ripon. It’s only one week out of the year, but there’s so much traffic in that week that it still stands out.
Last I looked at it coverage is pretty good for land globally? Sea less so.
The bigger issue is that in first world buying a sdr dongle for giggles is viable while in poor countries less so. A raspberry and dongle is a substantial investment if you’re earning 1/20th of a US salary. Don’t think there is an issue with willingness to share data
How to utilize sat feeds with open data? Across ADS-B track data (like OpenSky Network) South America, Africa and Oceania seem covered in addition to Europe and America, as does East Asia, and India. But China, and some parts of Central Asia and Middle East appear absent?
Little bit of trivia regarding the "strange hole near Mexico City"[1] from the README.
This is a 12-kilometer exclusion zone around the highly active Popocatépetl volcano to prevent incidents stemming from volcanic activity.
[1] https://adsb.exposed/?zoom=9&lat=19.1139&lng=261.3813&query=...