Espace Aériens Sur Seeyou

[LimaMike]

Chers amis,

 

lors d'un récent concours à Montricher, nous nous somme demandé si les bases de données (à jour !) de tous les moyens de navigations étaient rigoureusement les mêmes. Il serait évidemment très désagréable de suivre une ligne avec un calculateur ou un programme pour PDA/PNA et de se trouver vaché par SeeYou Contest...

 

Merci de me rassurer...

JPH

[jp PETIT]

Tu ne sera pas le seul dans ce cas là puisque tous les pilotes auront la même base de donnée !

de plus, il y a forte chance que le contrôle se fasse, lui aussi, avec cette même base de donnée .

Au dernier concours que j'ai fait, l'organisation fournissait une base de donnée des points mais aussi un fichier espace.

 

salutations

Modifié le 13 mai 2009 par PETIT JP

[Invité richard]

Tu ne sera pas le seul dans ce cas là puisque tous les pilotes auront la même base de donnée !

de plus, il y a forte chance que le contrôle se fasse, lui aussi, avec cette même base de donnée .

Au dernier concours que j'ai fait, l'organisation fournissait une base de donnée des points mais aussi un fichier espace.

 

salutations

 

 

Outre l'aspect technique, quel fichier (qqc soit son format, on s'en fou... ) fait référence sur l'état des

zones actuelles, je veux dire par là celles publiées officiellement sur les 1/500000 et 1/1000000 ?

C'est bien d'avoir des données , encore faut il qu'elles soient justes.

Modifié le 15 mai 2009 par richard

[Stéphane]

C'est bien simple: la plupart des pays ne publient pas de fichier officiel. La référence, c'est le texte dans l'AIP. L'Allemagne publie un fichier officiel chaque année, mais c'est une exception. A part ça, il y a quelques doux-dingues comme Régis pour la France ou mézigue pour la Belgique qui se tapent un boulot bénévole et tout à fait non-officiel en transcrivant leurs AIP respectifs. Encore faut-il parfois "interpréter" le texte (en tout cas pour la Belgique, où la situation "de jour, militaires inactifs" est fort différente de la situation standard, raison pour laquelle il y a un fichier "semaine" et un fichier "week-end"). C'est pourquoi ces fichiers comportent toujours une clause de sauvegarde (dont on peut s'interroger sur la protection légale qu'elle offre, d'ailleurs). De toute façon, l'emport d'une carte papier est légalement obligatoire...

 

Pour les concours, le problème est un peu différent: il faut que tous les concurrents disposent des mêmes informations que le programme d'évaluation, question de ne pas être injustement pénalisés pour infraction d'espace aérien. A la limite, on peut créer un fichier incluant des marges de sécurité par rapport à l'espace aérien réel...

[Régis]

La référence, c'est le texte dans l'AIP

Bonne réponse !

 

il y a quelques doux-dingues comme Régis pour la France ou mézigue pour la Belgique qui se tapent un boulot bénévole et tout à fait non-officiel en transcrivant leurs AIP respectifs

et ce n'est rien de le dire !

 

raison pour laquelle il y a un fichier "semaine" et un fichier "week-end"

Pour la France, je m'y refuse. trop de travail et trop de risque. Chacun peut bidouiller le fichier de référence, ce n'est pas compliqué

 

Pour les compétitions :

- Il est impératif que le fichier utilisé soit le même pour les pilotes et pour l'organisation (scoring)

- Il est impératif que ce fichier présente les espaces autorisés et les espaces interdits, sans interprétation possible des pilotes

- les zones alternativement autorisées et interdites doivent figurer clairement avec, en complément, les indications de l'organisation "ouvert" ou "fermé" à chaque briefing journalier (un document écrit est le bienvenu)

 

Bons Vols, have fun and fly safe

[Robert Ehrlich]

A part ça, il y a quelques doux-dingues comme Régis pour la France ou mézigue pour la Belgique qui se tapent un boulot bénévole et tout à fait non-officiel en transcrivant leurs AIP respectifs.

Pour ce qui concerne la France en tout cas, l'AIP est disponible en format PDF. On pourrait peut-être envisager une traduction automatique du PDF en fichier au format adéquat, histoire de soulager Régis.

[Stéphane]

Ben oui, mais pour ça, il faut un autre doux-dingue capable d'écrire un programme de conversion. Pas simple, car il y a un tas de données qui figurent dans l'AIP et sont superflues dans le fichier Open Air, et il y a aussi des données manquantes (les coordonnées des lignes frontières, notamment, où l'AIP se contente de noter "suivant la frontière franco-belge", par exemple).

 

Dans la pratique actuelle, je copie les données pdf rubrique par rubrique, puis je passe ça à la moulinette du "chercher/modifier" du traitement de texte pour approcher le format Open Air, et je termine "à la main".

 

A part le problème des frontières (on m'a fourni un fichier de la frontière belge dans lequel je recherche les sections à insérer dans les définitions de l'AIP), il y a aussi la définition des arcs de cercle où la logique de l'aip n'est pas toujours celle d'Open Air (sens horaire ou antihoraire, par exemple). Sans compter que les définitions (en Belgique) des coordonnées sont clairement basées sur une lecture de carte papier, et non générées électroniquement ou par le calcul. Ce qui fait que l'aip donne un centre et deux points d'arrêt pour l'arc de cercle, mais que les rayons sont différents, ce qui se voit bien dans SeeYou (décrochements aberrants). Ou encore, deux lignes qui devraient logiquement se superposer divergent légèrement...

Modifié le 9 juin 2009 par Stéphane

[SVE]

Oups Erreur !!!! Modifié le 8 juin 2009 par SVE

[SVE]

Dans les modifs possibles, une que nous utilisons en région lyonnaise.En fonction du QFU à St Ex nous avons la possibilité de déclasser des parties de la TMA en classe G en accord avec le controle de St Ex.

Nous découpons donc dans le fichier France de Régis ces déclassements possibles qui deviennent des zones indépendantes de la TMA d'origine ce qui permet de les désactiver dans Seeeyou mobile en fonction du coup de fil à St Ex du matin.Plus d'alerte donc dans ces zones déclassées, mais l'alerte revient si l'on s'approche des limites de ce déclassement (Position ou hauteur).

Pour parfaire le système, nous avons crée une surface au sol identique au zones déclassables (Alt mini 0 et altitude maxi 0) qui indique en "remplissage transparent" l'empreinte au sol de ces zones sans alertes puique elles n'ont aucune altitude.

 

Voir la notice d'utilisation ici

 

C'est un petit peu de boulot tous les ans pour la modif, mais cela empèche les alarmes non réelles ou la désactivation par erreur en vol d'une zone véritable merci à Lolo pour ce boulot.

 

Ce fichier modifié pour tous les déclassements de la TMA de Lyon est dispo sur le site du CVVL aux formats Seeyou et Winpilot.

Utilisables par les clubs concernés par l'accord avec St EX (Corbas,Cessieu,Morestel,Villefranche,Ambérieu et Bourg en Bresse je pense.Et bien sur sous le responsabilité de chacun des utilisateurs.

 

SVE

[Robert Ehrlich]

Ben oui, mais pour ça, il faut un autre doux-dingue capable d'écrire un programme de conversion. Pas simple, car il y a un tas de données qui figurent dans l'AIP et sont superflues dans le fichier Open Air, et il y a aussi des données manquantes (les coordonnées des lignes frontières, notamment, où l'AIP se contente de noter "suivant la frontière franco-belge", par exemple).

Evidemment, je sous-entendais que le doux-dingue en question pourrait être moi-même, mais clairement il faudra attendre la fin de la saison, c'est un projet d'hiver. Les informations superflues pourraient rester en commentaire, ça aiderait surement à localiser les endroits où appliquer un traitement final manuel, qui restera certainement nécessaire

... Sans compter que les définitions (en Belgique) des coordonnées sont clairement basées sur une lecture de carte papier, et non générées électroniquement ou par le calcul. Ce qui fait que l'aip donne un centre et deux points d'arrêt pour l'arc de cercle, mais que les rayons sont différents, ce qui se voit bien dans SeeYou (décrochements aberrants).

Comment fais-tu dans ce cas ? Par le calcul il y a une solution simple pour le cas de l'arc de cercle : on garde les extremités de l'arc telles que dans l'AIP et on prend pour centre le point situé sur la médiatrice du segment joignant ces 2 points qui est le plus proche du centre indiqué dans l'AIP. Oups, en géométrie sphérique, c'est peut-être un peu dur, mais j'espère que les arcs sont suffisamment petits pour qu'on puisse considérer qu'à leur échelle la terre est plate.

[Stéphane]

je sous-entendais que le doux-dingue en question pourrait être moi-même

Eh bien, le moment venu, envoie-moi un courriel, qu'on puisse voir un peu ce qu'il y a moyen de faire.

 

Pour les arcs de cercle, dans le fichier belge actuel, j'ai laissé les choses en l'état, car cette année, avec la refonte complète, j'ai eu assez de boulot comme ça. Ce n'est pas "propre", mais ça pose peu de problèmes pratiques en vol. De plus, il y a un problème légal dès qu'on touche aux coordonnées publiées, et le "centre" de l'arc de cercle est généralement un point bien défini, du genre "point central d'aérodrome", "VOR", etc.

[Denis F]

1 - Le jour où les données serpnt publiées en XML ou équivalent, tout le monde aura la même référence sans risque d'erreurs de transcription, il y aura une version pdf ou papier d'un côté, et il sera facile de bidouiller une version Open Air pour nos calculateurs. Ca viendra sans doute un jour, à force de râler...

 

2 - Avoir les bonnes coordonnées ne garantit pas à 100% qu'il n'y aura pas de divergences d'un logiciel à l'autre pour ce qui est des calculs de distance et d'angles (un exemple flagrant est la distance SeeYou qui diffère de 0,5% selon qu'on a oublié ou non de cocher la case "ellispoide WGS84". Sur des courtes distances la différence n'est pas énorme, mais à 1 m près on peu être dans la zone ou en dehors...

 

3 - pour l'altitude c'est encore pire, car il y a des différences significatives d'un logger à l'autre et que je n'ai jamais vu aucun organisateur tenir compte de la calibration des loggers (ce qui d'ailleurs ne serait que d'un maigre secours vu que l'erreur doit varier pas mal en fonction de la température)

[Robert Ehrlich]

1 - Le jour où les données serpnt publiées en XML ou équivalent, tout le monde aura la même référence sans risque d'erreurs de transcription, il y aura une version pdf ou papier d'un côté, et il sera facile de bidouiller une version Open Air pour nos calculateurs. Ca viendra sans doute un jour, à force de râler...

D'ailleurs d'ici là les calculateurs boufferont sans doute directement les données en XML, c'est juste un peu plus verbeux, mais, comme je l'entends dire depuis 40 ans, avec les capacités mémoire d'aujourd'hui, ça ne pose pas de problème.

[Stéphane]

Et pour ce qui est de la précision des coordonnées, j'ai même découvert une curiosité en SeeYou (pour PC, une version 2): 2 coordonnées identiques donnant un résultat légèrement différent à l'écran! La seule explication que je puisse imaginer, c'est qu'il y a des problèmes d'arrondissement des chiffres que mon PC résout différemment selon les coordonnées précédentes et/ou suivantes dans la chaîne... Le cas ne s'est présenté qu'une fois à ce jour.

[Robert Ehrlich]

Ben oui, mais pour ça, il faut un autre doux-dingue capable d'écrire un programme de conversion. Pas simple, car il y a un tas de données qui figurent dans l'AIP et sont superflues dans le fichier Open Air, et il y a aussi des données manquantes (les coordonnées des lignes frontières, notamment, où l'AIP se contente de noter "suivant la frontière franco-belge", par exemple).

Evidemment, je sous-entendais que le doux-dingue en question pourrait être moi-même, mais clairement il faudra attendre la fin de la saison, c'est un projet d'hiver. Les informations superflues pourraient rester en commentaire, ça aiderait surement à localiser les endroits où appliquer un traitement final manuel, qui restera certainement nécessaire.

Ben voilà, le doux dingue a commencé le boulot, je pense être en mesure de sortir automatiquement bientôt la partie du fichier OpenAir correspondant aux TMA décrites dans la pubication SIA ENR 2.3, pour le reste il faudra un peu plus de temps.

Pour ce qui concerne les lignes frontières mentionnées plus haut, j'ai constaté que dans le fichiers "france.txt" on ne fait pas mieux que chez les Belges ou dans le document ENR 2.3, il n'y a pas de tracé proprement dit dit, simplement un commentaire du style "** France/Germany Border **", je ne ferai ni mieux ni pire, si ce n'est que je garderai le texte du document français qui est en Français, d'autant plus qu'en Anglais j'aurais plutôt dit "Boundary".

Modifié le 19 janvier 2011 par Robert Ehrlich

[Thierry]

Ben oui, mais pour ça, il faut un autre doux-dingue capable d'écrire un programme de conversion. Pas simple, car il y a un tas de données qui figurent dans l'AIP et sont superflues dans le fichier Open Air, et il y a aussi des données manquantes (les coordonnées des lignes frontières, notamment, où l'AIP se contente de noter "suivant la frontière franco-belge", par exemple).

Evidemment, je sous-entendais que le doux-dingue en question pourrait être moi-même, mais clairement il faudra attendre la fin de la saison, c'est un projet d'hiver. Les informations superflues pourraient rester en commentaire, ça aiderait surement à localiser les endroits où appliquer un traitement final manuel, qui restera certainement nécessaire.

Ben voilà, le doux dingue a commencé le boulot, je pense être en mesure de sortir automatiquement bientôt la partie du fichier OpenAir correspondant aux TMA décrites dans la pubication SIA ENR 2.3, pour le reste il faudra un peu plus de temps.

Pour ce qui concerne les lignes frontières mentionnées plus haut, j'ai constaté que dans le fichiers "france.txt" on ne fait pas mieux que chez les Belges ou dans le document ENR 2.3, il n'y a pas de tracé proprement dit dit, simplement un commentaire du style "** France/Germany Border **", je ne ferai ni mieux ni pire, si ce n'est que je garderai le texte du document français qui est en Français, d'autant plus qu'en Anglais j'aurais plutôt dit "Boundary".

 

 

 

C'est pour ça que tu te couches si tard????? :lol: :lol:

[Robert Ehrlich]

C'est pour ça que tu te couches si tard????? :lol: :lol:

Ou que je me lève si tôt ... mais tout ceux qui me connaissent savent bien que c'est ton hypothèse qui est la bonne.

 

On découvre des choses étonnantes en programmant ce genre de choses, la dernière en date :

Dans le document sur lequel je bosse en ce moment, la liste des TMA, accessible par

https://www.sia.aviation-civile.gouv.fr/aip/enligne/fr/..%5CPDF_AIPparSSection%5CAIP%20FRANCE%5CENR%5C2%5C1102_ENR-2.3.pdf en page 5 sur l'avant-dernière ligne du cadre décrivant les limites latérales de la TMA BALE partie 1, on voit écrit (ARP COLMAR), ou plutôt on croit voir, car en réalité c'est (ARP C0LMAR), le "O est en fait un zéro. Une demi-heure pour trouver pourquoi ça ne plaisait pas à mom programme !

[Robert Ehrlich]

Pour ce qui concerne les lignes frontières mentionnées plus haut, j'ai constaté que dans le fichiers "france.txt" on ne fait pas mieux que chez les Belges ou dans le document ENR 2.3, il n'y a pas de tracé proprement dit dit, simplement un commentaire du style "** France/Germany Border **", je ne ferai ni mieux ni pire, si ce n'est que je garderai le texte du document français qui est en Français, d'autant plus qu'en Anglais j'aurais plutôt dit "Boundary".

J'ai médit en regardant trop hativement. effectivement il y a un commentaire tyle "** France/Germany Border **" dans le fichier "france.txt" , mais il est doublé pour encadrer la suite de points effectivement présents qui se trouvent sur cette frontière. Je ne sais guère ou récupérer cette information si ce n'est dans ce même fichier.

 

A part ça mon programme a l'air de marcher et me permet quelques premières constatations, comme le fait que la TMA Ajaccio est différente dans le document SIA et dans france.txt. il y a en particulier des parties 3, 4 et 5 dans le document SIA qui ne sont pas dans france.txt.

 

La suite de cette discussion serait peut-être mieux placée dans le forum "Réglementation - Espaces Aériens", qu'en pense le chef ?

[Philoo]

 

... page 5 sur l'avant-dernière ligne du cadre décrivant les limites latérales de la TMA BALE partie 1, ..., le "O" est en fait un zéro....

 

Ca ne serait pas le fameux trou de Bale ? :lol:

 

-->[]

[Régis]

comme le fait que la TMA Ajaccio est différente dans le document SIA et dans france.txt. il y a en particulier des parties 3, 4 et 5 dans le document SIA qui ne sont pas dans france.txt

 

le fichier "France.txt" a été conçu à la base pour un usage purement vélivole. Certains espaces décrits dans l'AIP France ne figurent donc pas dans le fichier, car non utile à la cause vélivole (Vol en plaine > FL 115) ou région maritime éloignée des côtes. On peut évidemment le compléter pour un usage avion....

 

Pour la description des frontières terrestres, j'utilise google earth, la précision est suffisante.

Modifié le 21 janvier 2011 par Régis

[Robert Ehrlich]

comme le fait que la TMA Ajaccio est différente dans le document SIA et dans france.txt. il y a en particulier des parties 3, 4 et 5 dans le document SIA qui ne sont pas dans france.txt

 

le fichier "France.txt" a été conçu à la base pour un usage purement vélivole. Certains espaces décrits dans l'AIP France ne figurent donc pas dans le fichier, car non utile à la cause vélivole (Vol en plaine > FL 115) ou région maritime éloignée des côtes. On peut évidemment le compléter pour un usage avion....

Inversement dans mon programme je peux ne retenir que les zones dont le plancher est inférieur à une certaine valeur, FL115 par exemple. Ceci dit même dans les parties retenues il y des différences, par exemple dans france.txt :

AC D
AN Ajaccio1 121.05
AH FL075
AL 2500F AMSL
DP 42:00:00 N 008:31:00 E
DP 42:00:00 N 008:55:00 E
DP 41:42:00 N 008:50:00 E
DP 41:42:00 N 008:47:00 E
DP 41:40:00 N 008:47:00 E
DP 41:40:00 N 008:31:00 E

et dans ce que mon programme donne à partir de l'AIP :

AC D
AN AJACCIO1
AH FL195
AL 2500F AMSL
DP 42:20:56 N 008:28:58 E
DP 42:17:02 N 008:31:57 E
DP 42:16:00 N 008:41:30 E
DP 42:07:27 N 008:49:50 E
DP 42:00:00 N 008:49:00 E
DP 42:00:00 N 008:55:00 E
DP 41:46:05 N 008:51:08 E
DP 41:42:00 N 008:50:00 E
DP 41:42:00 N 008:47:00 E
DP 41:40:00 N 008:47:00 E
DP 41:20:00 N 008:34:12 E
DP 41:19:58 N 007:58:21 E
DP 42:01:00 N 007:54:54 E
DP 42:15:41 N 007:49:53 E

Ni les limites verticales, ni les limites latérales ne sont identiques.

D'après le commentaires dans france.txt les données sont du 20 novembre 2001 alors que la page de l'AIP est du 18 novembre 2010, d'ailleurs cette TMA y figure en négatif (carcatères blancs sur fond sombre) sans doute pour indiquer un changement par rapport à l'édition précédente.

 

Ce n'est pas la seule différence, j'en prépare une liste exhaustive, mais c'est moins évident qu'il ne semble, certaines différences sont "cosmétiques", genre variation d'une coordonnée de 1 ou 2 secondes (environ 30 m en longitude, 20 en latitude pour 1 seconde). ou ajout ou suppression d'un point au milieu d'une ligne droite, ce qui ne change rien au tracé, mais d'autres sont bien réelles. Un truc qui ne me facilite pas la tâche est que, si les zones sont systématquement "fermées" dans l'AIP (le dernier point est identique au premier), il n'en est pas de même dans france.txt, dans la plupart des cas le premier point n'est pas repris à la fin mais il y a des des exceptions, notamment pour les zones qui finissent sur un arc de cercle ou une frontière, mais pas seulement.

Pour la description des frontières terrestres, j'utilise google earth, la précision est suffisante.

Peux-tu préciser comment tu fais ça avec google earth, est-ce "à la main", ou y a-t-il une automatisation possible ?

Modifié le 23 janvier 2011 par Robert Ehrlich

[Régis]

TMA AJACCIO :

je n'ai pas fait de mise à jour en octobre/novembre 2010. donc si il y a eu une modification de cette TMA, elle sera prise en compte pour la mise à jour de début d'année. (il ne doit pas y avoir beaucoup de planeurs qui fréquentent cette TMA)

 

Fermeture des zones :

la description des espaces prévoit efffectivement que la dernière coordonnées soit identique à la première afin de bien "fermer" l'espace. Dans le fichier txtx, ce n'est pas nécessaire, le contour se ferme tout seul. ça permet d'économiser des lignes et par conséquent d'alléger le fichier en Koctets.

 

Frontières Google : je fais ça à la main

Modifié le 23 janvier 2011 par Régis

[La Globule]

TMA AJACCIO :

.... (il ne doit pas y avoir beaucoup de planeurs qui fréquentent cette TMA)

 

 

Comment, comment!!!

y'en a pas beaucoup... j'en connais au moins trois (et quatre depuis quelques jours!), certes pas nombreux ,mais c'est des bons , et en tous cas on se marre bien . puis y'a aussi de la belle onde en Corse qui justifierai bien le 195 mini.(Regis tu dois connaitre!)

 

La Globule, instructeur transhumant estival, de Challes à Ghisonnaccia (où vous êtes bienvenus pour des vols découverte).

Modifié le 23 janvier 2011 par La Globule

[Régis]

OK mea culpa !

je complèterai les EAC en Corse dans la prochaine édition

[Philoo]

...

Peux-tu préciser comment tu fais ça avec google earth, est-ce "à la main", ou y a-t-il une automatisation possible ?

 

 

Il existe une moulinette qui projette les fichiers OpenAir sur GoogleMaps (en 2D):

OpenAir2Map

A utiliser avec des petit fichiers, évitez le fichier France complet.