Dependencies¶
pip install lonboard requests
Imports¶
from datetime import timedelta
from io import BytesIO
import requests
from arro3.io import read_parquet
from lonboard import Map
from lonboard.experimental import TripsLayer
The bulk ADSB files distributed by adsb.lol are very large (~2GB). To make it easy to use this data in a demo, we've prepared an extract of only the data used in this demo.
Information about how this extract was prepared is documented in kylebarron/adsb-extract.
The Parquet file we're loading has been constructed in the specific format required by the TripsLayer. Airplane trajectories are stored as GeoArrow LineStrings in the geometry column. Timestamps are stored in the timestamp column in an Arrow list array, with the same nesting as the geometry column, so there's one timestamp per point.
# Fetch the Parquet file and parse to an Arrow table
url = "https://github.com/kylebarron/adsb-extract/releases/download/v0.1/2024-10-03_traces.parquet"
r = requests.get(url)
table = read_parquet(BytesIO(r.content)).read_all()
Now we can create a TripsLayer. Since we already have Arrow data, we can pass it directly into the table argument.
layer = TripsLayer(
table=table,
get_timestamps=table["timestamp"],
width_min_pixels=2,
get_color=[30, 30, 200, 200],
trail_length=200,
# Turn off tooltip data selection for better performance
pickable=False,
)
m = Map(
layer,
view_state={
"longitude": -73.8,
"latitude": 40.6,
"zoom": 9.5,
"pitch": 50.6,
"bearing": 8.24,
},
# Increase height of generated map (API subject to change)
_height=800,
)
m
Now we can animate the layer! Click the play button to watch the data animate!
layer.animate(step=timedelta(minutes=1), fps=50)
If you wish, you can stop the animation either with the UI controls above or with stop_animation below:
layer.stop_animation()
Notes¶
- This dataset contains one day of flight data in the UTC time zone. So around 6 AM UTC time the animation will be mostly empty because not many planes are taking off after midnight eastern time.
- If you see some planes moving very fast between Asia and the U.S. west coast, that's due to issues in data handling around the antimeridian. When creating these data extracts in
adsb-extract, I didn't do any special antimeridian handling, and so by default deck.gl thinks data is moving on a euclidean plane. The ideal way to solve this is to split trajectories that cross the antimeridian into two segments, but this is not yet implemented.