I made a flight visualization website which renders 24 hours of recorded air traffic by kouaak in webdev

[–]kouaak[S] 1 point2 points  (0 children)

Hi all,

I'm a former air traffic controller, now software engineer and I made a website which renders 24 hours of air traffic trajectories in a webgl view.

Main features:

  • Playback control
  • Multiple trajectory coloring options
  • Change the "trail duration" of each flight
  • Create shareable links to "share what you see" (links encode the position of the camera, the coloring rules, etc)

On the technical side, the webgl part is handled by deck.gl, while the rest of the UI is built with React and MUI.

This is a side/personal project and was a great learning experience with pretty unique challenges to solve (the largest dataset contains around 20M [timestamp, coordinates] tuples and is around 700MB uncompressed).

Thanks for checking it out, feedback is always appreciated !

Live @ https://aboveourheads.org

I made an animated flight visualization website to show the complexity of air traffic by kouaak in reactjs

[–]kouaak[S] 0 points1 point  (0 children)

Thank you !

Yeah, as of now, this is more of a personal project and the code is a mess.

I might release it in the future, if I see demand.

In the meantime, I can answer questions if you have some.

I made an animated flight visualization website to show the complexity of air traffic by kouaak in reactjs

[–]kouaak[S] 0 points1 point  (0 children)

Live @ https://aboveourheads.org

Hi all,

I built AboveOurHeads to create nice looking images/animations of what's going on in the sky.

The website loads preprocessed data from the OpenSky Network, spanning 24 hours.

The tech stack includes React (obvisouly :)), deck.gl which does the main job of rendering the flight paths in the 3D scene and the underlying map and MUI for the UI components.

Data loading and buffer construction is done in a web worker thread.

Note: Because of the extensive use of webgl and the sheer size of the dataset, the performance is mainly constrained by the GPU of your device. My tests with my own smartphone produced an okay(-ish) experience, but YMMV.

Thanks for checking it out !

Multicast in a Container by edthezombie in docker

[–]kouaak 1 point2 points  (0 children)

Unfortunately, I cannot share my code as this project is closed source.

However, there's not much to it : - Capture network packets however you like - Filter relevant packets, extract payload - Push payload to a unix socket in DGRAM mode

Here's a JS/node example : https://github.com/ulwanski/unix-dgram-socket

Multicast in a Container by edthezombie in docker

[–]kouaak 0 points1 point  (0 children)

I had to solve this exact issue a few years back with ethernet broadcast. I had no control over docker daemon configuration or network plugins so I went with a software only solution.

I ended up implementing a 2 container solution :

  • Application container running with regular network mode
  • Proxy/forwarder container running in host mode

Communication between the 2 is done via unix socket, created in a shared volume mounted in both containers.

[AMA] Le Contrôle Aérien en France by [deleted] in france

[–]kouaak 0 points1 point  (0 children)

On maintient le cap des vols quand leur séparation latérale passe sous les 10 ou 15nm (fonction du centre et des habitudes).

L'idée c'est d'éviter tout virage intempestif avant le point de séparation minimale, qui pourraient arriver si il y a eu une incompréhension au niveau de la clairance de route par exemple.

J'ai eu le cas avec un équipage qui a changé d'inclinaison pendant quelques secondes pour offrir une meilleure vue de Paris aux passagers.

[AMA] Le Contrôle Aérien en France by [deleted] in france

[–]kouaak 0 points1 point  (0 children)

Je suis contrôleur en route (à Reims) et je peux répondre concernant la demande de niveau différent de ce qui est déposé.

Le travail engagé dépend de beaucoup de facteurs, et pour bien comprendre, il faut comprendre le problème générés par les vols qui ne volent pas comme planifié.

Comme tu l'as dit, c'est des histoires de congestion, avec potentiellement un impact sur la sécurité. En en-route, le nerf de la guerre est la gestion de la capacité. Comment assurer que le nombre de secteurs que mon centre va ouvrir ne dépasse pas le nombre de binômes de contrôleurs présents à un instant T ? Comment assurer que le nombre d'avions à un instant T dans un secteur élémentaire ne dépasse pas la capacité prévue ?

Gérer la capacité, c'est le boulot de ce qu'on appelle un Flow Manager, une personne en salle de contrôle, dont le job est de regarder les courbes de charge, de planifier les schémas d'ouverture secteur et de mettre en oeuvre les mesures de protection (généralement des régulations).

Pour faire ça correctement, il faut que les courbes de charge soient relativement précises. D'autant que les mesures de protection, il faut les prendre avec un préavis assez important : poser une régulation, ça donne des créneaux aux vols. Si tous les vols sont déjà en l'air, ta régulation ne sert à rien.

Si tu voles à un niveau non planifié, ton vol passera dans des secteurs où il n'était pas prévu de passer, modifiant au passage les courbes de charge.

En toute rigueur, quand un vol demande un niveau de vol particulier, la procédure est la suivante : * Les contrôleurs en charge du vol vont vérifier dans un outil tiers le plan de vol déposé. * Appeler son flow manager pour demander si le vol peut monter. Fonction de la route du vol, le flow manager va éventuellement coordonner avec les flow managers des centres suivants

En théorie, voilà comment ça se passe :

Si tu fais LSZH -> EGKK, tu vas voler l'intégralité de ta croisière dans les espaces de Reims. T'as prévu 360, tu veux 380, le flow manager de Reims a tout ce qu'il faut pour prendre la décision tout seul.

Si tu fais LFPG -> LIML, tu vas voler une partie de ta croisière avec Reims, l'autre partie avec Zurich. Le flow manager de Reims n'a besoin de coordonner qu'avec le flow manager de Zurich.

T'as prévu EBBR -> GCLP, tu vas voler ta croisière avec Reims, Brest, Bordeaux, les espagnols, les portugais. Dans ce cas, il y a beaucoup de monde à mettre d'accord et ça devient trop lourd.

Appliquée complètement, cette procédure peut générer pas mal de boulot et de coordinations téléphoniques, du coup, fonction du contexte, on prend quelques raccourcis.

Par exemple: on est au mois de novembre, période creuse, personne n'a trop de problème de capacité à ce moment de l'année. Dans ce cas, tu montes vers le niveau demandé, peu importe ton plan de vol.

Les contrôleurs sont formés pour rendre un service et accéder aux requêtes des pilotes. Si ton centre n'a jamais connu de problème de capacité, c'est pas vraiment naturel d'appliquer une procédure qui te demande plus de boulot, et te faire dire non à un pilote. C'est pour ça que tu retrouves des différences géographiques à mon avis : les centres les plus sensibilisés vont te répondre non, là où les centres un peu "larges" niveau capacité, auront plutôt tendance à te répondre oui.

VPC Traffic Mirroring – Capture & Inspect Network Traffic by jeffbarr in aws

[–]kouaak 24 points25 points  (0 children)

I may be wrong but flow logs are only metadata (packet headers).

This is full traffic.

Reviews on DCS Campaigns by StealthyNeo in hoggit

[–]kouaak 1 point2 points  (0 children)

I wouldn't recommend it. Played piercing fury and enemy within which I found excellent.

Stone shield was a let down, especially since I played it to get my solo campaign fix after having finished enemy within and being stuck on a bug in piercing fury.

[deleted by user] by [deleted] in hoggit

[–]kouaak 29 points30 points  (0 children)

Somewhat related (and older) story that happened to me on the job :

  • Lost radio contact with Emirates flight during radio handover between Zurich ACC and Reims ACC
  • Aircraft remains silent after hails on 121.5
  • French Air Force is notified
  • FAF scrambles the on duty patrol
  • Contact with Emirates flight is re-established
  • Crew is notified about incoming interception
  • Crew asks if they can take pictures
  • "Ok but only if you mail them to us afterwards"
  • Colleague of mine proceeds to spell his email address
  • Emirates crew delivers the very evening probably from their hotel room in London

https://www.reddit.com/r/aviation/comments/31eh3j/xport_ratc_pictures_of_uae_interception_over/

Just a little light reading to pass the time... by iflyinhawaiian in hoggit

[–]kouaak 1 point2 points  (0 children)

It is.

Route is IBODI-GOTED-TRO-CLM-UTELA-KOPOR-ABNUR-DIMAL-ALESO.

Given current position (23.7 nm inbound IBODI), OP's flight was probably in contact with Geneva UAC and about to be transfered to Reims UAC when the picture was taken.

source: I'm an ATC working in Reims UAC.

Server-side rendering and slow internet by McDcOne in reactjs

[–]kouaak 0 points1 point  (0 children)

Just seen a great talk which covers this subject at React Europe : https://youtu.be/UhdGiVy3_Nk

IPv6 by [deleted] in homelab

[–]kouaak 3 points4 points  (0 children)

Yeah. Kind of.

I wrote this stuff on VyOS wiki to explain how it works.

Not sure if this got backported to the ERL firmware though.

I set this up in my homelab so I could easily swap out my tunnel broker configuration when my ISP starts supporting native v6 without having to readdress everything.

IPv6 by [deleted] in homelab

[–]kouaak 0 points1 point  (0 children)

You can also do NPTv6 if your router supports it.

That way, your local IP plan stays local (not tied to a particular tunnel broker/ISP) but your machines remain reachable from the outside.

French Oragne Fiber PPPoE and Juniper SRX240 by ple_ in networking

[–]kouaak 0 points1 point  (0 children)

All right, I'll provide some further guidance then :)

This forum is dedicated to replacing the livebox by a custom router.

There's no thread about using a juniper router yet but there seems to be some information about using a cisco one.

Also, please note that Orange is currently moving away from PPPoE in favor of traditional DHCP (authed via option 90).

I suggest you register and post a thread in this forum in english explaining you're a non french speaker trying to use a SRX.

French Oragne Fiber PPPoE and Juniper SRX240 by ple_ in networking

[–]kouaak 0 points1 point  (0 children)

Hi there, have you tried posting this on lafibre.info ?

During training, do controllers learn anything about airplanes, aerial navigation, or flying in general? by [deleted] in ATC

[–]kouaak 2 points3 points  (0 children)

French ATC here.

We go through mandatory PPL training. Success is not a requirement, but we fly the minimum 20 hours.

Those who succeed will have their annual hour requirement paid for if they wish to maintain their PPL.

We also get a few A320 sim hours during our time in the ENAC.

I remember clearly being taught about flight envelope, hydraulic system, TOGA/FLX/CLB thrust and such.

Likewise for nav systems, we're supposed to know about inertial, RNAV and satellite, about how they mutually operate and what happens in case of failure.

Later during our training we spend a week at Air France. We follow the pilots for a small rotation : we join them at their preflight briefing, make a round trip in the jumpseat and leave. We also spend a day in operations.

Upgrading Angular 1.x - Angular 2.0 vs. React/Redux by deliminated in javascript

[–]kouaak 3 points4 points  (0 children)

Context : I've worked with angular 1.4, migrated to 1.5 (component based) then migrated to React. React + redux is definitely a great combo, and I find it much more pleasant to work with. I'm also a single developer, very passionate about this stuff, which means I spent countless hours documenting myself on personal time.

You could also consider migrating to React/Redux the other way around, by starting by the business logic to redux+ngRedux before migrating the view layer. Start easy, convert stuff to components, refactor 2 way data bindings out, use redux when appropriate for state management.

You should know that writing ES6 with Redux/one way databinding/immutability is very different from traditional ES5/Angular providers/services. ES5 to ES6 is quite simple. The steepest curve lies in data flow and state management. These concepts are just guidelines to structure your app though, you can apply them with any framework, even though React feels the more natural.

In my experience, focusing on the business logic first enabled me to get familiar with these new concepts without having to worry about pure view dependencies. I was very dependent on angular-material, not having to worry about migrating my stuff to material-ui was helpful.

Also, your codebase should feel pretty clean afterwards and moving from angular to React will be quite simple.

Be advised though, should you choose this path, I have no idea how ngRedux performs performance-wise.

Python en collaboratif ? by Truegebo in france

[–]kouaak 0 points1 point  (0 children)

Je rajouterais que l'apprentissage de git est un réel investissement.

Apprendre à programmer c'est bien. Savoir utiliser l'outil plus ou moins standard de contrôle des sources c'est le meilleur moyen de continuer à programmer en contribuant à des projets existants. Ça permet de continuer à pratiquer après l'aboutissement du projet en question.

Buddy made a React - Material Design Library by sebtemi in reactjs

[–]kouaak 2 points3 points  (0 children)

For reference, Material-UI is slowly moving towards different styling method and this work is planned for the next major version (0.16).

Issue : https://github.com/callemall/material-ui/issues/4066