map.flightsストーリー

第26話(全26話)2026年8月9日〜9月28日

日ではなく、時間

9月15日、2つの受信局を運用する人から、自分の受信局がとらえた機体に高度が表示されないと連絡がありました。1時間で彼から17,000件を超える位置が届いていましたが、高度の入ったものは1件もありませんでした。同じ日の16:52 UTCには修正が公開され、数分後には彼の受信局から高度と速度が流れ始めました。

8月9日8月10日8月11日8月12日8月13日8月14日8月15日8月16日8月17日8月18日8月19日8月20日8月21日8月22日8月23日8月24日8月25日8月26日8月27日8月28日8月29日8月30日8月31日9月1日9月2日9月3日9月4日9月5日9月6日9月7日9月8日9月9日9月10日9月11日9月12日9月13日9月14日9月15日9月16日9月17日9月18日9月19日9月20日9月21日9月22日9月23日9月24日9月25日9月26日9月27日9月28日 9月27日 8月9日9月1日9月28日
map.flightsの1日ごとの作業ペース、2026年8月9日〜9月28日、目盛りなし。最終日は途中までです。

途中で消えた高度

ADS-Bトランスポンダーを積んだ機体は、およそ0.5秒ごとに位置を送信し、高度はまさに同じメッセージに入っています。だから17,000件の位置にひとつも高度がないなら、黙っているのは機体ではありません。どこか途中で消えているのです。

その途中には、運用者の自宅にある箱があります。受信機が電波を解読し、その結果を私たちに送ります。彼の2つの受信局では古いバージョンのデコーダーが動いていて、同じ値を別の名前で呼んでいました。高度はずっとそこにあったのです。古い名前で。16:52 UTCからは両方の方言を理解できるようになり、別の時代のデコーダーを使う受信局も何ひとつ変える必要がありません。

2通のメール、9つの要望

翌日、同じ人から要望のリストが入ったメールが2通届きました。別の機体の登録記号が同じ文字で始まっていても、写真は彼が意図した機体に付くべきだ。ギャラリーは絞り込めるべきだ。ウォッチリストのリンクは機体に飛ぶべきだ。受信局の記録には、どの機体が記録を出したかを書くべきだ。そして1便の「離陸」と「着陸」の通知が同時に届くべきではない。

どれにも現実の世界に理由があります。登録記号は使い回され、同じ文字で始まるものがたくさんあるので、最初の数文字から機体を推測するフォームはときどき間違えます。そして2つの通知が同時に届いたのは、その便がどの受信局にも聞こえない場所から離陸したからでした。離陸を知ったのは着陸と一緒だったのです。同じ1秒に届く2通の通知より、正しい1通のほうがいい。

9月16日20:54 UTCには、すべてが公開されていました。フォームはもう勝手に選ばず、登録記号があいまいなときは両方の候補を示します。ギャラリーは機種、航空会社、場所、登録記号で絞り込めます。受信局の記録には機種名が載ります。離陸の通知が遅れて届きそうなときは、着陸だけを送ります。21:20には、リンクを添えた返信が彼に届いていました。

閉まることのない地図

航空交通に閉店時間はありません。ヨーロッパが夜のとき、アジアでは便が離陸しています。だから誰も地図を開いていない瞬間はありません。

それでもウェブサイトの新しいバージョンは、いまも1日に何度も公開されることがよくあります。別の場所で組み立て、確認し、それから一度に切り替えます。そのとき地図を開いている人は何も気づきません。前のバージョンのファイルが手元に残っているので、開いたままのタブは切り替え後も自分のコードを見つけられるのです。そして新しいバージョンが何かを壊したら、1回の操作で前のバージョンに戻ります。

上のグラフには、ゼロの日がありません。最も高い棒は9月27日、3D空港の建物に実際の高さ、屋根、窓が付いた日です。

あとに残ったもの

プロジェクトは8月9日、1ページのルールから始まりました。そのひとつは、いまも「map.flightsについて」のページに載っています。受信できないものは主張しない。7週間後、人々の自宅から170の受信局がデータを送り、サイトは13の言語を話し、アーカイブには2026年のオープンデータの過去分を取り込んだものも含めて、79億件の機体の位置と1,220万便が収まっていました。ほかの数字は、この回より前の25話にあります。

「これは全部、日ではなく時間の話でした」。Luboš Kovář、9月16日、受信局の運用者への返信で。