Tous juste pour l’heure longitude et lattitude, mais tu t’en doutait
Le A c’est effectivement la validité et pas l’altitude. l’autre option c’est V.
Si tu as A : Tu avais un nombre de satellitte suffisant pour déterminer l’altitude “GPS” 02082 en bleu dans ton exemple
Si tu as V : Tu n’as pas assez de satellitte pour faire le calcul 3D. l’altitude utilisé est l’altitude barométrique en athmosphère standard (toujours callé avec 1013.25HPa pour 0m) 01902 en bleu dans ton exemple.
Il serait assez surprenant que tu rencontre un V dans tes donnés…
Tu peux aussi prendre gpsbabel, brancher mon super bout de python :mrgreen: qui t’offrira toute la puissance de gpsbabel et de python (genre tu charges pas que de l’igc, tu peux utiliser les filtres de gpsbabel, etc). En plus, ça évite de reprogrammer la roue une 100ème fois…
ce qui serait top c’est de tracer sur la même courbe, en fonction de l’altitude de départ, ceux qui sont arrivés (ce que tu as déjà fait) et d’ajouter ceux qui ont tenté ! Comme ça, on pourrait en déduire une proba de raccrocher en fonction de l’altitude de départ …
Bon après, tout ça ne veut pas dire gd chose si on ne le fait jour par jour (associé aux conditions du jour) : celui qui tente ça un 10/01 en partant de 2000 n’a pas la même proba d’arriver que celui qui le tente le 20/06 …
Si tu te limites à des polynômes convexes ça peut se faire avec un peu de trigo.
A1 ------ A0
/
/________
A2 Ai
Si tu as un polynôme convexe avec les sommets Ai qui se suivent (dans le sens du schéma ci-dessus), alors le point P sera dans le polynôme si pour tout i mod( course(Ai;Ai+1) - course(P;Ai+1) ; 2Pi) € [ Pi ; 2Pi] avec la course définie ici: http://williams.best.vwh.net/avform.htm#Crs
Il y a surement plus simple ou bien des fonction qui existe déjà mais c’est ce qui m’est venu en premier…
J’aime bien la methode de la droite horizontale qui intersecte un nombre pair de cotés si le point est a l’exterieur et un nombre impair de cotés si le point est dans le poly.
Mais d’ici que j’ai besoin des polynomes j’aurai peut etre eu le temps d’apprendre a utiliser des librairies toutes faites dont parle Man’s.
c’est exactement le genre de doc que je cherchais.
Voici par exemple extrait des 20645 des vols CFD de fin 2000 à mai 2010, le pourcentage de vols et les milliers de km par tranche de 7j de l’année au départ de l’Isère :
Etonnant. C’est décalé d’un mois par rapport a ce que j’aurais. J’aurais pas cru que la saison commencait aussi tot (debut mars) et “s’arretait” aussi tot (mi mai).
[quote]de fin 2000 à mai 2010,
[/quote]
Tu envisages de completer le reste de l’année 2010 ? C’est un peu dommage de s’arreter en milieu d’année au lieu d’aller de date a date, ca doit jouer un peu sur l’importance du pic de mars avril par rapport a mai-juin-juillet (plus de 10% si on considere qu’il y a plus de vols declares en 2010 qu’en 2001).
La je suis sur le bateau, j’ai du mal a m’organiser proprement, mais je promet de mettre le code sur une forge au plus tard fin octobre. D’ailleurs d’ici la ca ne va pas avancer des masses.
plaf.py, le programme que j’ai fait pour tester vite fait les deux autres fichiers. Ca lit tous les fichiers igc dans un dossier et trouve les plafs d’une transition avec un cylindre de depart et d’arrivée
Si vous voulez telecharger les traces, je prefererais qu’une seule personne s’en occupe puis mette le fichier sur un hebergement plus robuste (megaupload devrait faire l’affaire). Sinon, si vous etes plusieurs a telecharger 300 Mo sur ce serveur je pense que ca va coincer. L’archive est ici : http://pirk.wiki-parapente.fr/cfd/igc.tar.bz2, les utilisateurs de linux savent comment decompresser ca, pour windows je pense que 7zip fonctionne.
Peut être que ça roue sera plus belle et plus ronde :canape:
[/quote]
Plus belle et plus ronde que le code utilisé par les gens qui font des vrais trucs (genre openstreetmap, geodjango et plein d’autres projets) ? Bon courage! :canape:
Plus belle et plus ronde que le code utilisé par les gens qui font des vrais trucs (genre openstreetmap, geodjango et plein d’autres projets) ? Bon courage! :canape:
[/quote]
Plus belle et plus ronde, je sais pas. Mais plus simple peut-etre.
Depuis que j’ai commencé a m’interesser aux interfaces graphiques je suis en train de me rendre compte du fossé entre la maniere de programmer des informaticiens (ceux qui font des vrais trucs ) et celle de la plupart des physiciens de labo et de terrain qui n’ont jamais entendu parler des objets, des classes, de fonctions qui prennent d’autres fonctions en parametre ou meme de parsers. J’ai un sentiment mitigé a propos de tout ca, parcequ’au fur et a mesure que je decouvre ces trucs je me rend compte que ma programmation devient plus efficace (forcement) mais qu’en meme temps mon code devient illisible pour mes collegues qui n’ont ni la motivation ni le temps d’apprendre ces trucs. Il va falloir que je fasse le deuil de la lisibilité de mon code pour mes semblables si je veux jouer dans la cour des grands :? .
Plus simple mais sans doute moins éprouvée (bugs, choses auxquelles tu n’as pas pensées, etc), moins évolutive. Sans compter l’effort de maintenance… Tu refais tout => tu dois tout maintenir, ce qui n’est pas le cas si tu reposes sur des libs (que ça soit gdal pour le traitement de données géographique ou des libs de widgets pour les interface graphiques).
Tu parles de physiciens, je connais bien le soucis aussi. J’ai bossé au CERN et j’ai du reprendre du code d’""“informaticiens”""" qui sont en fait des physiciens reconvertis: perl, expression régulières dans tous les sens, réinvention de la roue, pas de doc, aucune structure. Résultat ? Quand tu veux améliorer, tu te retrouves à réécrire from scratch, et seul, car personne n’a envie de passer 2 semaines rien que pour comprendre ce que t’as fait
Euh, c’était pas plutôt du 10 mars au 30 avril en 2010?
Sinon, pour revenir à l’outil et la roue, je voulais juste proposer un truc simple qui devrait fonctionner, mais s’il y a plein de fonctions toutes faites qui le font déjà tant mieux. Et avec un peu de chance, les calculs seront même fait en wgs84, sans approximation sphérique…
Je finirai 2010 en 2011. Voici la france entière de 2001 (complète) à 2009 (complète), en milliers de km et nombre de vols (en absolu plutot qu’en %) :
Toujours ce trou patriotique à la 26ième tranche de 7j … Avez-vous remarqué que le défilé a toujours lieu sous la pluie ? On voit aussi la petite mais significative recrudescence des fêtes de fin d’année, la picole aidant.
Je vous laisserais volontiers l’Excel complet, mais je ne sais pas si la fédé apprécie qu’on lui pique ces données (pas vraiment publiques je pense, elles appartiennent aux auteurs des vols ?)
Si j’ai bien compris tu as fait des stats avec des infos publiquement accessibles sur le site de la fédé, je ne crois pas qu’il puisse y avoir un quelconque soucis avec la distribution des resultats. Le seul point un peu sensible a mon avis c’est si on disperse le nom des pilotes publiquement un peu partout sur le web.
Concernant les traces GPS, je n’ai pas trouvé sur le site de la fédé quelles sont les regles concernant leur diffusion. Mais je sais que sur le site de la WXC on trouve dans les regles la mention :
[quote=http://wxc.fai.org/FCKedfiles/File/CIVL/CIVL_WXC_rules2009.pdf] All flight data collected by the FAI/CIVL WXC Server will be placed in the public domain
and will be freely available. FAI/CIVL will limit the data published about each flight in accordance with
personal data protection laws and regulations. The FAI/CIVL will archive all WXC flight data for future
reference.
[/quote]
Et les vols déclarés a la CFD avec une trace valide sont automatiquement transférés a la WXC depuis peu.
Cela dit je n’ai pas l’intention de les laisser a disposition sur un serveur public longtemps.