Il y a plus d’un an, je publiais un premier article dédié à la géolocalisation d’un vol commercial depuis une photo prise dans l’avion, à partir de différentes recherches et outils de recherche en sources ouvertes. Cependant, d’autres outils existent et sont à mon sens trop peu médiatisés, notamment via des ressources françaises. Je me suis donc dit qu’il serait intéressant d’y consacrer quelques lignes. Et puis, une nouvelle fois, tel un running gag au sein de nos groupes de discussion, une photo également prise depuis un avion nous a été envoyée. Qu’à cela ne tienne, il s’avère que le cas est parfait pour introduire ces outils.
Géolocalisation d’un vol depuis une photo ? On est reparti pour un tour !
Préambule
Si vous arrivez directement sur cet article depuis une source externe, je vous conseille vivement de commencer par lire mon premier article sur le sujet, disponible ici.
Dans ce deuxième opus, nous allons tout d’abord résoudre ce cas au travers de la solution “classique” via les outils d’analyse et de suivi de vol. Puis dans un second temps, et c’est tout l’intérêt de ce post, j’aimerai aborder un outil relativement puissant et nettement moins connu.
Contexte et premiers éléments
De la même façon que lors du premier cas traité sur ce blog, cette histoire démarre avec la photo suivante, reçue le 29/10/2021 à 11h58 nous demandant qui saurait dire où cette personne a prévu de passer son week end.
Le nom du fichier est “PXL_20211029_095541933.jpg”. Cette fois ci, pas de timestamp ! Cependant, on peut à priori valider la date de prise de la photo, qui est bien le 29/10/2021. Il est également possible de vérifier cette information au travers des métadonnées de la photo.
En effet, par défaut, lors de l’upload d’une photo sur les plateformes sociales, les métadonnées sont retirées afin d’assainir les fichiers et gagner de la place. Cependant, via Telegram (car c’est ici que nous avons récupéré l’image), il est possible d’envoyer une image en tant que fichier brut, sans compression et en conservant les métadonnées.
$ exiftool PXL_20211029_095541933.jpg
[...]
Aperture : 1.7
Image Size : 4032x3024
Megapixels : 12.2
Scale Factor To 35 mm Equivalent: 6.2
Shutter Speed : 1/3906
Create Date : 2021:10:29 11:55:41.933+02:00
Date/Time Original : 2021:10:29 11:55:41.933+02:00
Modify Date : 2021:10:29 11:55:41.933+02:00
Thumbnail Image : (Binary data 14521 bytes, use -b option to extract)
Circle Of Confusion : 0.005 mm
Depth Of Field : inf (1.54 m - inf)
Field Of View : 67.4 deg
Focal Length : 4.4 mm (35 mm equivalent: 27.0 mm)
Hyperfocal Distance : 2.28 m
Light Value : 14.2
Grâce à cela, on sait notamment que la photo a été prise à 11h55 le 29/10/2021.
Bien. Deuxième étape, les éléments remarquables de la photo et ce qu’on peut en tirer. Comme un air de déjà vu… Vous ne trouvez pas ?
- Blanc : Premier élément à prendre en compte ici, l’altitude ! En effet, même si cela parait évident, il s’agit probablement de l’information la plus importante. En effet, l’altitude étant relativement basse, cela nous indique que la photo a été prise juste après le décollage, ou bien juste avant l’atterrissage de l’avion ;
- Rouge : Plutôt simple, la “winglet” de l’aile nous donne la compagnie aérienne (Easyjet) ainsi qu’une indication sur le modèle d’appareil ;
- Jaune : Les volets hypersustentateurs sont déployés, ce qui confirme la piste d’atterrissage (lol) ou de décollage ;
- Bleu : Un point d’eau. Ou plutôt trois points d’eau différents. Nous le verrons plus tard, c’est typiquement le genre de point géographique remarquable dont nous avons besoin ;
- Vert : En arrière plan, on aperçoit un site industriel surplombé de deux grosses “cheminées”, ce qui ressemble très fortement à une centrale nucléaire ;
- On pourrait également noter d’autres éléments intéressants, tels qu’une route moyenne, bien qu’ayant 4 voies, un pont, ou encore des reliefs en arrière plan.
Pour la suite, deux méthodes, employant chacune certains éléments de l’image.
Méthode 1 : La classique, résolution par analyse des vols
Si vous avez lu mon premier article sur le sujet, cela va vous sembler familier. En effet, connaissant l’heure approximative du vol, et plus précisément de l’atterrissage grâce à la basse altitude de l’appareil ainsi que la compagnie opérant le vol, l’identifiation peut se faire relativement facilement au moyen de différents outils de suivi et d’analyse de vols.
Je l’avais déjà mentionné auparavant, mais les outils à suivre permettent un accès gratuit aux historiques de vols de manière limitée dans le temps. L’accès à des données plus anciennes est également possible, mais il s’agit généralement de services payants.
Bien. Connaissant la date du vol et ayant une idée d’une plage (l’appareil devant être en vol à 11h55), commençons par regarder les vols opérés par EasyJet le 29/10/2021. L’outil Airportia (lien) permet (parmi d’autres) ce type de recherche. Petite précision, la personne étant française, nous allons nous concentrer sur les vols au départ de villes situées en France. A noter également, les horaires affichés sont au format UTC. Dans notre cas, il est donc nécessaire d’y ajouter 2 heures.
En se basant sur ces critères, deux vols correspondent. Cependant, compte tenu de l’image et de l’altitude, nous pouvons inclure les vols ayant théoriquement atterri quelques minutes avant l’heure de la photo (retards potentiels, etc). Au final, 4 vols peuvent correspondre.
Quatre vols à analyser, c’est relativement peu ! Airportia permet également d’avoir des détails plus précis sur un vol et notamment les heures réelles de départ et d’arrivée ! Ainsi, il est possible de voir les éventuels retards. Compte tenu de l’altitude et de l’heure de la photo, peu de chances qu’il s’agisse du vol U24263 (Paris-Biarritz) étant donné que ce dernier a atteri environ 10 minutes après la prise de la photo, ce qui est tard par rapport à la position de l’appareil sur cette dernière.
Les autres vols peuvent correspondre. Cependant, le vol U24052 (Rennes-Lyon) attire l’attention grâce à un détail particulier. En effet, les infos sur ce dernier révèlent que le vol du jour a été retardé et que par conséquent, l’atterrissage a eu lieu à 11h57, soit 2 minutes après la prise de la photo !
Ce vol semble être un bon candidat. Pour la suite, l’outil en ligne FlightRadar24 (lien), également présenté dans le premier article sur le sujet, a été utilisé. Une fonctionnalité géniale proposée par le site est la possibilité de “rejouer” un vol une fois celui-ci arrivé. Cela permet notamment de connaître le trajet emprunté par l’appareil, minute par minute, et d’avoir des informations précises telles que la vitesse ou l’altitude à un instant donné. Ainsi, en recherchant le vol cible, il est possible de le rejouer.
On se place à l’heure de la prise de la photo, 11h55 (rappelez vous, 9h55 sur l’application car nous sommes en format UTC) et on peut ainsi voir la position et l’orientation de l’appareil, ainsi que son altitude de 1800 pieds. Comme je n’ai pas énormément de notions relatives à ces échelles, Google m’indique que cela correspond à environ 550 mètres.
Bien. Nous savons maintenant où était cet avion à 11h55. Maintenant, il ne reste qu’à observer l’environnement géographique proche de cette position afin de dire s’il s’agit de ce vol ou non. Si ce n’est pas le cas, alors le processus d’analyse pourra être répété aux autres vols identifiés.
En zoomant sur la carte de FlightRadar, on peut voir la position exacte par rapport à une carte type “Google Maps”, représentant également les routes, chemins de fer, points d’eau… Vous avez dit point d’eau ?
L’image montre en effet plusieurs points d’eau proches de la position de l’appareil, sur sa gauche, ce qui correspond à notre recherche. De plus, nous avions identifié un trait particulier par rapport à ces derniers. En effet, l’image originale montre au moins 3 points d’eau ayant une forme plutôt proche de ceux représentés sur la carte.
Ayant la position exacte de l’appareil ainsi que des points d’eau potentiels, on peut maintenant essayer de trouver des images plus précises de la zone afin de voir si cela correspond. L’excellent Google Earth Pro répond parfaitement à ce besoin. On se rend à la position indiquée de l’appareil puis après une légère orientation, on obtient l’image suivante.
Les points d’eau, la route, le pont, et même le site industriel en arrière plan, tout y est ! Cela confirme donc l’aéroport d’arrivée ainsi que le vol supposé. On peut donc affirmer que cette personne est partie de Rennes afin de passer son week-end dans la région de Lyon.
Ok… Mais supposons maintenant que nous arrivons quelques jours plus tard et que nous n’ayons pas envie de payer pour avoir accès aux données de vol plus anciennes, peut-on toujours répondre à cette question à partir des éléments disponibles ?
Méthode 2 : Let me introduce… Overpass Turbo !
On arrive maintenant au sujet principal de cet article ! Comme mentionné en introduction, l’idée est de présenter rapidement un outil particulièrement utile dans l’analyse de données géographiques et notamment quand il s’agit de géolocaliser des éléments.
Pour faire court, Overpass Turbo (lien) est un outil d’extraction et d’exploration des données du réseau OpenStreetMap. Il permet de construire des requêtes, exécutées au travers de l’API Overpass et récupérer les données sur une carte interactive.
Histoire d’apporter une définition rapide (merci Wikipedia), OpenStreetMap (OSM) est un projet collaboratif de cartographie en ligne qui vise à constituer une base de données géographiques libre du monde en utilisant le système GPS et d’autres données libres. En gros, chaque personne peut renseigner des éléments du monde réel sur cette carte, en suivant quelques règles d’identification, ce qui en fait une formidable base de données, comme vous allez le voir. Au passage, OpenFacto a fait il y a maintenant 2 ans un super article sur le sujet que je vous invite à lire également.
Avant de rentrer dans le vif du sujet, quelques éléments nécessaires à la compréhension. Sans rentrer dans les détails, les objets recensés au sein d’OSM et interrogeables au travers de Overpass Turbo peuvent être de trois types différents :
- Un noeud (node) : Ce sont les éléments de base du système OSM. Les nœuds consistent en une latitude et une longitude. En gros, un point sur la carte ;
- un chemin (way) : Un chemin est une interconnexion entre au moins deux nœuds caractérisant une ligne telle qu’une rue, ou similaire ;
- Une relation (relation) : Un objet de type relation est une collection d’objets.
Ainsi, tout élément enregistré auprès d’Open Street Map est catégorisé par au moins une de ces propriétés (plus d’informations ici)
De plus, chaque objet est également associé à différentes propriétés (“features” et “tags”) qui permettent de le définir, mais également de le rechercher. Cette catégorisation fonctionne sous la forme de clés/valeurs. Par exemple, une route portera la clé highway ainsi qu’une valeur permettant de définir son importance. Ainsi, une autoroute sera caractérisée par le couple highway=motorway. A l’inverse, une route beaucoup moins importante, reliant par exemple deux villages sera représentée sous la forme highway=secondary.
Enfin, il est également possible d’ajouter des éléments supplémentaires afin de filtrer les résultats, appelés “tags”. Il existe une quantité astronomique de tags, propres à chaque type d’objet dans OSM. Si on reprend l’exemple des routes, il est par exemple possible d’utiliser les tags lanes ou encore maxspeed.
Le wiki d’OpenStreetMap référence l’ensemble des éléments existants, ainsi que les tags qui peuvent y être associés. C’est une réelle mine d’or, absolument indispensable pour cibler correctement les recherches : Map Features.
Bien ! Nous avons maintenant tous les éléments théoriques de base nous permettant de construire une requête via Overpass Turbo. Mais, à quoi ressemble une requête Overpass ?
Pour illustrer tout ça, rien de tel qu’un exemple simple. Imaginons que j’utilise régulièrement le bus à Rennes et que je cherche une salle de sport. Par contre, fainéant que je suis, j’aimerais que cette salle se situe relativement proche d’un arrêt de bus. Eh bien en langage “Overpass”, ça ressemble à ça :
[out:json][timeout:800];
(
node["public_transport"="station"]({{bbox}});
way["public_transport"="station"]({{bbox}});
relation["public_transport"="station"]({{bbox}});
)->.bus;
(
node(around.bus:100)["leisure"="fitness_centre"]({{bbox}});
way(around.bus:100)["leisure"="fitness_centre"]({{bbox}});
relation(around.bus:100)["leisure"="fitness_centre"]({{bbox}});
)->.fitness;
(.fitness;);
out geom;
Effectivement, ce n’est pas très “user-friendly”. Néanmoins, une fois les notions de base comprises, vous allez voir qu’on s’y retrouve. Quelques explications :
- L’instruction
[out:json][timeout:800];permet de définir le délai maximal de recherche avant expiration de la recherche ; - Le premier bloc consiste à rechercher l’ensemble des noeuds, chemins et relations correspondant à des arrêts de bus. Ces derniers peuvent être référencés avec la clé
public_transportet la valeurstation(Mais pas uniquement! D’autres appelations possibles sont indiquées sur le wiki de OSM). Le résultat de cette recherche est stocké dans une variable que nous nommonsbus; - L’attribut
({{bbox}})correspond à laBounding Boxce qui n’est ni plus ni moins que la zone, representée par la carte visible, dans laquelle nous souhaitons effectuer la recherche. Pour notre exemple, nous allons ainsi se placer sur Rennes de façon à englober toute la ville ; - Le second bloc consiste à rechercher l’ensemble des salles de sport, identifiées avec la clé
leisureet la valeurfitness_centre. Petite subtilité cependant, on peut croiser les résultats de cette recherche avec ceux de la recherche précédente, en appelant à nouveau la variablebus. Ainsi, on va récupérer toutes les salles de sports, croiser ces résultats avec les stations de bus, et ne récupérer que celles à moins de 100m d’une station, grâce à l’instruction(around.bus:100), puis on stocke le résultat dans une variablefitness; - Enfin, on précise que l’on souhaite récupérer cette variable, puis afficher le résultat.
Concrètement, cela nous donne le résultat suivant et 3 salles potentielles :
Maintenant que nous avons vu les bases de Overpass Turbo, on s’attaque à notre challenge ?
Identification des éléments
La première chose à faire est d’identifier les éléments sur lesquels se baser pour la recherche. Inutile de chercher à faire correspondre trop d’éléments car cela complexifie inutilement la requête. De plus, en cas d’absence de résultats, il sera plus difficile de savoir où cela bloque.
Ce n’est peut être pas la bonne méthode (honnêtement, je ne sais pas) mais la méthode avec laquelle j’ai eu le plus de résultats, et surtout celle avec laquelle j’ai réussi à avancer est la suivante :
- Démarrer “large” avec des requêtes plutôt générales, afin notamment de voir si la syntaxe est correcte et si on est en capacité de récupérer des résultats ;
- Puis, progressivement rajouter de la complexité. Rajouter des éléments, rajouter des liens entre objets (distance notamment) voire modifier la zone de recherche (la fameuse
{{bbox}}).
A ce sujet, quelle hypothèse de départ pourrait-on faire ?
D’un point de vue contextuel, on voit un site industriel qui semble être une centrale (nucléaire ? thermique ? autre ?). De plus, on sait qu’on se trouve à proximité d’un aéroport. De ces deux éléments peu communs, nous avons peu de chances de récupérer des centaines de résultats. Ainsi, on peut se permettre une zone de recherche de départ plutôt grande. Via leur site, Easyjet propose une carte de l’ensemble de leurs tracés de vol, très majoritairement en Europe. C’est noté, on prendra donc cette base, l’Europe.
On a donc deux éléments principaux. Cependant, il est toujours probable que l’on trouve un peu trop de résultats pour être analysés manuellement (bien que ce soit toujours possible!). En plus, c’est l’occasion d’avoir une requête un peu plus sexy/complexe, pour la démonstration. Si on reprend la photo originale, on peut rajouter plusieurs éléments annexes :
- Les points d’eau ;
- La route ;
- Ce qui ressemble à un pont ;
- Un village au loin ;
- Des champs…
Les éléments qui semblent sur le papier les plus pratiques et sûrs à traiter sont les points d’eau ainsi que la route. On va donc partir là dessus, pour un total de 4 éléments à entremeler afin de construire notre requête !
Construction de la requête
Comme je le précisais tout à l’heure, j’aime bien dans ce genre de cas partir du général pour aller progressivement vers du spécifique. C’est également comme cela que nous allons construire notre requête.
Je ne l’ai pas précisé plus tôt, mais bien entendu, il n’y a pas qu’une requête possible pour identifier des points géographiques… En effet, on peut utiliser différents éléments comme référence et arriver au même résultat.
Pour ce cas là, j’ai choisi de débuter sur la recherche autour du site industriel en émettant également l’hypothèse qu’il s’agit d’une centrale nucléaire. La recherche commence donc grace au Wiki de OSM (lien) afin de trouver quels objets peuvent correspondre à cette recherche.
Il se trouve qu’une clé power existe, accompagné d’une valeur generator, ce qui rentre complètement dans le champ de notre recherche (lien). Mieux encore, il est possible d’y associer un tag source permettant de filtrer la source d’énergie (lien). Parmi la quinzaine de sources différentes renseignées se trouve une valeur nuclear. Parfait !
En suivant la syntaxe abordée précédemment, on peut donc construire cette première requête. La syntaxe avec l’utilisation d’un tag peut être trouvée ci-dessous.
Note : Il est également possible de factoriser les recherches de noeuds, chemins et relations au sein d’une seule instruction, en utilisant les initiales de chaque terme, ce qui donne nwr.
[out:json][timeout:800];
(
// Source nucléaire d'énergie dans la zone de recherche
nwr["generator:source"="nuclear"]({{bbox}});
)->.nuke;
On stocke le tout dans une variable nuke, on se place correctement sur la carte, et on exécute la requête (Selon la complexité de cette dernière et le nombre d’éléments récupérés, cela peut prendre quelques minutes) :
Félicitations, vous avez réalisé votre première requête Overpass Turbo ! Ca fait beaucoup de résultats hein ?
Deuxième élément important, l’aéroport. Etant donné l’altitude, on sait qu’un aéroport est probablement proche de la position de l’avion au moment de la photo. Rebelotte donc, on retourne fouiller notre wiki-bible à la recherche de paramètres permettant de taguer un aéroport.
Assez rapidement, on tombe sur le couple de clés/valeur aeroway=aerodrome qui indique être un élément général pour ce type d’infrastructure (lien). Afin de lier cette nouvelle recherche à la dernière, et ainsi réduire le nombre de résultats, nous allons chercher à intégrer une notion de distance. Ainsi, nous allons sélectionner l’ensemble des aéroports à moins de X kilomètres d’une centrale nucléaire. Je vous conseille d’effectuer différents tests afin de visualiser les différences de résultats. Peu d’éléments nous permettent ici de calculer la distance précise. Ainsi, on peut se dire que 20 kilomètres est une distance satisfaisante, par rapport à la photo.
Toujours en suivant le même modèle, on peut donc rajouter le bloc suivant à notre requête, en stockant le résultat dans une nouvelle variable airport qu’on va d’ailleurs appeler en résultats :
(
// Aérodrome et aéroports à moins de 20km des centrales
nwr(around.nuke:20000)["aeroway"="aerodrome"];
)->.airport;
Ce qui nous donne le résultat suivant.
Des résultats différents… Plus groupés.. What ? Eh bien oui, en changeant la requête, nous avons également changé l’ensemble des éléments à afficher. Des centrales nucléaires européennes, nous sommes passés à l’ensemble des infrastructure aéroportuaires (aérodromes compris!) proche de centrales. Par conséquent, si on a 4 résultats proche d’une même centrale, alors les quatre seront récupérés.
A partir de là, deux solutions :
- Modifier la requête pour ajouter un 3e élément ;
- Ou affiner la requête présente en travaillant les éléments déjà présents.
En effet, de la même façon que pour la première requête, un tag existe sur cet objet et permet notamment de filtrer sur le type d’infrastructure : sa taille. Il s’agit du tag type (lien). Dans notre cas, il semble s’agir d’un objet international. On peut donc modifier notre requête en conséquence et y ajouter le tag en question.
(
// Aérodrome et aéroports à moins de 20km des centrales
nwr(around.nuke:20000)["aeroway"="aerodrome"]["aerodrome"="international"];
)->.airport;
Beaucoup moins de résultats ! A partir de là, on pourrait commencer à regarder manuellement parmi les 12 aéroports, mais ce serait encore potentiellement fastidieux. Nous allons plutôt voir s’il est possible de réduire encore la liste.
Pour cela, pourquoi ne pas ajouter les deux éléments supplémentaires identifiés ?
Les routes étant des infrastructures plutôt communes, l’objectif pourrait être de se référer aux points d’eau afin de filtrer les résultats. Cependant, on veut que ces points d’eau correspondent à certains critères précis :
- Ils doivent être proche d’un aéroport (forcément) ;
- Ils doivent être très proche d’une route, qu’il reste à qualifier.
Pour réaliser cela, on va pouvoir créer une sorte de première condition à respecter, avant d’effectuer notre vraie recherche. Ainsi, on va chercher tout ce qui peut s’apparenter à un point d’eau à proximité de nos ensembles de résultats. Afin d’être relativement large, on peut utiliser la clé/valeur natural=water (lien). Encore une fois, je vous conseille d’effectuer des tests pour les distances. De notre côté, compte tenu de l’altitude de l’avion sur la photo, on sait qu’il est relativement proche du sol. Sans pour autant pouvoir calculer son altitude précise et ainsi sa distance de l’aéroport, on peut considérer qu’il ne sera pas à 10 kilomètres du point recherché… Visuellement, on peut supposer que 3km est encore relativement large. Quelques essais nous amènent à voir que les résultats diffèrent peu tout en diminuant les distances. Cependant, en dessous de 1km, peu de résultats subsistent. De ce fait, 1500 mètres semble être un bon point de départ.
(
// Points d'eau à moins de 1500m des aéroports précédemment identifiés
nwr(around.airport:1500)["natural"="water"];
)->.waterspots;
Puis, nous pouvons créer une seconde variable permettant de récupérer l’ensemble des routes très proches des points d’eau identifiés. Compte tenu de la photo et afin d’être large, prenons une valeur de 100 mètres. Via le wiki, on peut identifier que les routes sont rangées sous la clé highway. La valeur permet de classer les différentes routes selon leur taille. D’après la photo, on est sur une route à 2 voies, avec terre-plein central. Cela semble être une route importante, sans pour autant être une autoroute. La valeur la plus probable associée à ce type de route est trunk (lien). Ainsi :
(
// routes secondaires à moins de 100m des points d'eau identifiés
nwr(around.waterspots:100)["highway"="trunk"];
)->.road;
Bien. Les deux éléments sont sélectionnés et stockés dans des variables. Cependant, les routes ont été recherchés à partir des points d’eau, et non l’inverse. En effet, il aurait été inutile de chercher en premier lieu les routes situées à 1500 mètres d’un aéroport… Car la recherche aurait probablement retourné des résultats pour tous les aéroports.
Or, nous souhaitons filtrer les aéroports par rapport aux points d’eau “matchant” nos critères. Pour faire cela, rien ne nous empêche de recouper les précédentes recherches entres elles, afin de ne sélectionner que les points d’eau correspondant à la fois à la distance avec un aéroport et à la distance avec une route majeure. On peut donc reprendre nos deux éléments et les recouper l’un par rapport à l’autre, en cherchant par exemple dans notre ensemble de points d’eau, ceux distant de 100m ou moins d’une route importante.
(
// mise en relation des points d'eau et des routes identifiées
// Points d'eau correspondants
node.waterspots(around.road:100);
way.waterspots(around.road:100);
relation.waterspots(around.road:100);
)->.matching_water;
Ce qui nous donne le résultat suivant.
On a donc progressivement construit notre requête de façon à collecter :
- Les aéroports proches de centrales nucléaires en Europe ;
- L’ensemble des points d’eaux proche de ces aéroports, puis nous avons traité ces données afin de restreindre le nombre de résultats (grâce à la route).
Il ne nous reste plus qu’à recouper ces deux ensembles de données afin de voir quels aéroports correspondent ! Pour cela, on va donc rechercher dans notre notre ensemble d’aéroports, ceux proches de points d’eau contenus dans le deuxième ensemble de données.
(
// Recherche dans l'ensemble des aéroports identifiés
// Ceux proches de moins de 1500m des points d'eau trouvés
node.airport(around.matching_water:1500);
way.airport(around.matching_water:1500);
relation.airport(around.matching_water:1500);
)->.matching_airports;
Ca semble pas mal non ?
Requête finale et résultat
En mettant bout à bout l’ensemble des éléments présentés ci-dessus afin de construire une unique requête de recherche, on obtient quelque chose comme ça, avec quelques commentaires :
[out:json][timeout:800];
// gather results
(
// Sources nucléaire d'énergie
nwr["generator:source"="nuclear"]({{bbox}});
)->.nuke;
(
// Aérodrome et aéroports à moins de 20km des centrales
nwr(around.nuke:20000)["aeroway"="aerodrome"]["aerodrome"="international"];
)->.airport;
(
// Ensemble des points d'eau (étangs, bassin...) proche des aéroports
nwr(around.airport:1500)["natural"="water"];
)->.waterspots;
(
// Récupération des routes à moins de 100 mètres de ces points d'eau
nwr(around.waterspots:100)["highway"="trunk"];
)->.road;
(
// Filtre sur les points d'eau par rapport aux routes proches collectées
node.waterspots(around.road:100);
way.waterspots(around.road:100);
relation.waterspots(around.road:100);
)->.matching_water;
(
// Recoupement des aéroports avec les points d'eau correspondant aux critères
node.airport(around.matching_water:1500);
way.airport(around.matching_water:1500);
relation.airport(around.matching_water:1500);
)->.matching_airports;
(.matching_airports;);
out geom;
Toujours centré sur l’Europe, la requête peut être exécutée, et après quelques minutes de recherche (pour ma part) :
Alors, oui, visuellement et à l’échelle de l’Europe, les mêmes zones sont identifiées. Au total, 7 zones potentielles (ce qui est quand même bien mieux que nos premiers résultats!) :
- Paris, France
- Lyon, France
- Milan, Italie
- Sofia, Bulgarie
- Munich, Allemagne
- Prague, République Tchèque
- Saint-Petersbourg, Russie
Pour la suite, plusieurs méthodes afin d’affiner les résultats. On peut par exemple recouper la liste des 7 aéroports avec la liste de ceux desservis par Easyjet (lien), ce qui permet d’éliminer l’aéroport de Saint-Petersbourg. On peut également se baser sur le relief présent sur la photo, nous permettant par exemple d’écarter des aéroports comme Paris, Munich ou encore Prague, ce qui nous laisse une liste de 3 zones à vérifier manuellement :
- Lyon, France
- Milan, Italie
- Sofia, Bulgarie
Pour finir, une nouvelle utilisation de Overpass Turbo peut être faite en ciblant l’une après l’autre les 3 zones identifiées. La zone de recherche étant beaucoup plus petite, la requête est quasi instantanée. L’image ci-dessous illustre ceci avec l’aéroport de Lyon.
De la même manière, on peut modifier la requête pour afficher les différents points d’eau identifiés auparavant. C’est ainsi qu’on peut récupérer différents points d’eau identifiés au nord de l’aéroport.
A ce stade, vous l’avez compris, on va pouvoir réaliser la même vérification que pour la première méthode à l’aide d’outils comme Google Earth, pour ainsi valider la géolocalisation du lieu comme étant l’aéroport de Lyon !
Conclusion
Si on repart sur la question initiale, qui n’était en réalité qu’un prétexte pour parler de Overpass Turbo, alors on peut dire que cette personne a passé son week-end à Lyon ! Nous avons ainsi vu deux méthodes pouvant être utilisées pour aider à investiguer sur ces thématiques, chacune ayant leurs avantages, inconvénients, et applications propres !
En effet, bien qu’il ne soit pas possible uniquement à partir de Overpass Turbo de retrouver par exemple l’aéroport de départ, l’outil n’est bien entendu pas limité au domaine de l’aviation, loin de là. Si le sujet vous intéresse, je vous invite fortement à vous documenter plus en détails sur les données collectées et accessibles via Open Street Map ainsi que sur l’utilisation plus poussée de Overpass Turbo, car l’outil est vraiment puissant et peut être utilisé dans bien des cas.
Je ne l’ai pas dit en introduction, mais il va de soit que je suis loin d’être expert sur l’outil ou plus généralement sur les thèmatiques liées à OpenStreetMap, mais c’était l’occasion d’en parler. En attendant, j’espère que la lecture de ce post vous aura appris des choses, ou vous aura au moins diverti ;-).
Ressources et outils
Différentes ressources ont été données tout au long de l’article. Vous les retrouverez également rassemblées ci-dessous, ainsi qu’un ensemble d’autres liens forts intéressants relatifs au sujet, si vous souhaitez approfondir l’utilisation des outils.
-
Bases de connaissances liées à Overpass Turbo et Open Street Map
-
Autres articles en lien avec Overpass Turbo
-
Outils de suivi de vol