lire trace GPS avec python

[PiRK]

Je sais pas trop si je dois poster ça dans le coin du geek ou techniques de cross.

J'ai un petit projet qui me trotte dans la tête qui est de faire un ou plusieurs programmes pour essayer de tirer des informations interessantes d'un paquet de traces GPS (statistiques sur l'altitude de depart d'une transition classique, statistiques sur les plafonds selon le mois de l'année dans un coin donné...).

Mais pour commencer il faut que je passe par des étapes moins intéressantes tel que trouver un nombre significatif de traces GPS (presque résolu) et écrire les fonctions pour lire les traces GPS, et pour ça je dois aussi choisir sur quel format je vais travailler (igc ou kml). Est-ce que quelqu'un sait s'il existe des librairies pour python qui s'occupent des formats GPS ? Sinon, est-ce que vous connaissez d'autres projets en python qui travaillent sur les traces GPS desquels je pourrais m'inspirer ?

Ca me permettrait de gagner du temps et de passer plus vite aux aspects intéressants.

Ou si vous avez des idées d'informations interéssantes qu'on pourrait tirer d'un gros paquet de traces GPS, dites les moi.

[touz]

J'ai pensé un jour a utiliser les trace de la cfd pour "faire des stats" sur l'atmosphère.
Mais la plupart ont des mesures trop distante les unes des autre pour que ça me soit utile.
Néamoins si tu arrives à automatiser un import de trace, depuis une "base de donné" conséquente, peut être que j'y reréfléchirait...
Aucun doute qu'on en discute un de ces jour IRL 

[PiRK]

J'ai pensé un jour a utiliser les trace de la cfd pour "faire des stats" sur l'atmosphère.
Mais la plupart ont des mesures trop distante les unes des autre pour que ça me soit utile.
Néamoins si tu arrives à automatiser un import de trace, depuis une "base de donné" conséquente, peut être que j'y reréfléchirait...
Aucun doute qu'on en discute un de ces jour IRL 

Faut voir ce que t'entend par "automatiser un import de trace, depuis une "base de donné" conséquente". Je pense commencer par une approche "force brute", c'est a dire des programmes qui lisent betement tous les fichiers d'entrée un par un, ca sera probablement tres facile a réaliser.  Mais c'est pas exclu (selon les resultats en performances) que je fasse aussi quelques programmes pour trier les traces a l'avance (par region/massif, par intervalle de mesure si tu veux, par "saison", par distance...).

En attendant, j'ai déja trouvé ca http://github.com/twpayne/igc2kmz/wiki/algorithms . J'y jetterais un coup d'oeil des que j'aurais le temps.

[PiRK]

Bon j'ai presque compris le format igc, mais il me reste une petite question pour l'altitude  

Voici trois lignes en exemple :

Code:

B1212544230606N00159282EA0190202082
B1212554230607N00159277EA0190002082
B1212564230607N00159270EA0189702081

En couleur : B1212544230606N00159282EA0190202082

Le premier caractere est toujours un B sur les exemples que j'ai lu (balise ?). Les six caracteres suivants ressemblent a une heure dans le format hhmmss, c'est probablement UTC/GMT. Ensuite on a la latitude avec deux caracteres pour les degrés, deux caracteres pour les unités des minutes et 3 caracteres pour les chiffres apres la virgule des minutes et un caractere pour preciser l'hemisphere N ou S (dans la premiere ligne de mon exemple ca fait 42° 30,606' N) . Puis vient la longitude qui est similaire a la latitude sauf que les unites sont codées sur 3 chiffres parceque ca peut aller de 0 a 180 dans chaque hemisphere (E ou W) (001° 59,282' E dans mon exemple).

Ensuite vient un caractere A qui veut probablement dire altitude suivi de 10 chiffres. Et la selon la trace que je regarde c'est pas pareil, parfois les 5 premiers sont toujours 0 et l'altitude se lit sur les 5 derniers, parfois les 5 premiers chiffres sont identiques aux 5 derniers (exemple B1024104359254N00628532EA0165101651) et parfois on a deux valeurs differentes mais vaguement proches a 100 ou 200 m pres sur les 5 premiers et les 5 derniers chiffres comme dans mon exemple ci-dessus. Je suis allé voir la trace meme GPS au format KML et j'ai vu que l'altitude retenue etait celle sur les 5 derniers chiffres (ca donne 1.98803, 42.5101, 02082).

J'ai lu une doc (www.fai.org/gliding/system/files?file=tech_spec_gnss_al5.pdf) a propos du format igc mais on n'y comprend rien et j'ai eu l'impression que ca n'avait strictement rien a voir avec le format qu'on trouve sur le site de la CFD.

Est-ce que quelqu'un sait ce que ces deux altitudes differentes sont ? Une altitude barometrique en plus de la GPS ? Si c'est ca, est-ce qu'on peut etre certain de toujours trouver l'altitude GPS en deuxieme ?



[Fichier joint supprimé par l'administrateur]

[PiRK]

Allez je me repond a moi meme en bon autiste que je suis :

Code:

B_RECORD_RE = re.compile(r'B(\d{2})(\d{2})(\d{2})(\d{2})(\d{5})([NS])'
                         r'(\d{3})(\d{5})([EW])([AV])(\d{5})(\d{5}).*\Z')
[...]
class BRecord(Record):
    def parse(cls, line, igc):
        m = B_RECORD_RE.match(line)
        [...]
        result.ele = int(m.group(12))

Donc je crois que d'apres Tom Payne c'est une "elevation". Mais c'est quoi la difference entre une elevation et une altitude ? Et pourquoi est-ce que ca n'evolue pas precisement comme l'altitude (sur mes 3 lignes d'exemple l'alt vaut 2082,2082,2081 alors que l'ele vaut 1902,1900,1897) ?

Question subsidiaire : Tom Payne appelle 'validity' le caractere qui vient juste avant ces deux altitudes et prevoit que ca peut-etre A ou V. Quelqu'un sait de quoi il s'agit ?
 

[piwaille]

Les deux formats (IGC et KML) sont assez simples à comprendre... je vois que tu es déjà plongé dans l'IGC.
peut être que le KML est plus dans l'air du temps dans le sens où c'est un XML. Du coup tu trouvera peut être une bibliotèque python toute faite pour importer un XML dont tu lui défini la syntaxe.

[PiRK]

Les deux formats (IGC et KML) sont assez simples à comprendre... je vois que tu es déjà plongé dans l'IGC.
peut être que le KML est plus dans l'air du temps dans le sens où c'est un XML. Du coup tu trouvera peut être une bibliotèque python toute faite pour importer un XML dont tu lui défini la syntaxe.

Le KML est en effet tres simple a comprendre, mais les fichiers kml qu'on trouve sur le site de la cfd n'incluent pas l'heure avec les points, on n'a que la date du vol. Ca limite un peu ce qu'on peut en tirer comme infos.
Et puis les bibliotheques xml ne sont pas franchement simples a apprendre quand on part de zero. J'y ai jeté un coup d'oeil et j'ai renoncé pour l'instant, je prefere decouper une bonne vieille ligne de texte de longueur fixe en champs avec des expressions regulieres, surtout que je peux m'inspirer du code de Tom.  J'imagine que si je ne connaissais pas deja les expressions regulieres ce serait different.

[PiRK]

Bon, j'ai testé ma premiere ebauche de moulinette et voici les resultats :
- les plafonds des traces passant dans un rayon de 2km autour du Granier : http://pirk.wiki-parapente.fr/cfd/output.txt
- la distribution de ces plafs par tranche de 100 m d'altitude : http://pirk.wiki-parapente.fr/cfd/outputstat.txt

C'est pas un programme tres finaud, tout ce qui passe dans le cylindre est pris en compte. La prochaine etape sera de ne tenir compte de la trace que si apres le Granier elle passe a proximite du Montgelas pour ne s'occuper que des plafs qui sont en rapport avec une transition Chartreuse-Bauges.

Je me demande si les deux traces qui ont des plafs entre 4000 et 4100 sont des anomalies  

[thanjuzo]

Choix IGC ou KML : il vaut mieux prendre IGC qui est "unique". Il existe des tas de façons différentes de représenter une trace en KML, alors que pour IGC la spec publiée par la FAI laisse peu de variantes.

J'avais fait un truc approchant, en exploitant uniquement la liste des vols CFD (pas les contenu des traces) sur plusieurs années pour trouver quel est le jour de l'année qui vole le mieux, juste en Excel. Ca n'a pas amélioré mes perfos de rendement des vacances, mais on trouve quand même des trucs bizarres dans ces stats.

[PiRK]

Nouveau resultats :
J'ai cherché le plaf des traces dans un cylindre de 2 km de rayon avec une base a 800 m et un sommet a 5000 m centré sur le Granier a condition que ces traces passent ensuite dans un cylindre de  3 km de rayon avec une base a 900 et un sommet a 5000m  centré  sur le Montgelas.
Ca donne : http://pirk.wiki-parapente.fr/cfd/granierplafs.txt
Et en image :


Il reste surement des petits trucs a affiner dans le programme, mais la principale tache est de definir correctement les cylindres de depart et d'arrivee de la transition. Par exemple peut etre que 900 m est trop bas comme base dans le cylindre du Montgelas, si ca se trouve un partie des pilotes qui sont arrives a 900 n'ont pas reussi a remonter. Mais si je met la base trop haut je risque de ne pas retenir ceux qui passent sous mon cylindre au ras du caillou.

Si vous avez des idees de transitions que vous avez envie d'analyser, il n'y a qu'a me fournir les cylindres de depart et d'arrivee sous le format suivant : latitude_centre longitude_centre rayon altitude_base altitude_sommet

Code:

start="45.448333333333331 5.9219444444444447 2000 800 5000" 
finish="45.537777777777777 6.0263888888888886 3000 900 5000"

ps : Mes felicitations aux 3 gars qui ont fait la transition en partant entre 1800 et 1900 m

[PiRK]

J'ai retrouvé le vol avec le point a 4087, je crois quec'est une anomalie ou alors le gars assure vraiment bien tous ses plafs : http://parapente.ffvl.fr/cfd/liste/2009/vol/20091849

Par contre certains des plafs a 1900- m ont l'air reguliers : http://parapente.ffvl.fr/cfd/liste/2007/vol/20070977 et http://parapente.ffvl.fr/cfd/liste/2007/vol/20071756

[SP2]

J'ai retrouvé le vol avec le point a 4087, je crois quec'est une anomalie ou alors le gars assure vraiment bien tous ses plafs : http://parapente.ffvl.fr/cfd/liste/2009/vol/20091849

C'est une anomalie , je faisais parti des sept chanceux (Cabri'air) ce jour là et les plafs à cette heure là étaient sur le Granier de 2900m limite barbulles.......

[Seb26]

Après, on pourrait aussi sortir les stats de ceux qui ont tenté la transition mais ont échoué au pieds de la savoyarde ou juste derrière...

[PiRK]

Après, on pourrait aussi sortir les stats de ceux qui ont tenté la transition mais ont échoué au pieds de la savoyarde ou juste derrière...

Je peux toujours essayer avec une base et un sommet de cylindre tres proches du sol, mais faudrait que je sache a peu pres vers ou les gens posent dans ce cas la. Au pied du Montgelas meme ou plus au sud sous la Savoyarde ?
Et on va rater tous ceux qui abandonnent en milieu de vallee. Et pour ceux qui posent jsute derriere c'est encore moins evident de trouver automatiquement qui n'a pas reussi a se refaire, en tout cas avec les cylindres. Mais il y a peut etre moyen de voir quelles traces s'interrompent peu apres le passage a proximite du cylindre d'arrivee 

Sinon j'ai jeté un coup d'oeil du coté du Manival (entre Saint Hilaire et le Saint Eynard), ca donne ca :


L'ecart entre les plus bas plafs et les plus hauts est étonnant (plus de 1000 m). J'ai vérifiée quelques-unes des valeurs extremes, et il y a bien un gars qui a réussi en partant de 855 m de Chateau Nardant et d'autres qui font des plafs a plus de 1900 avant de traverser. Ca me rassure sur le fait que mon programme fonctionne correctement.

[piwaille]

je profite du remontage partiel de ma station pour passer ici et intervenir

piRK
ton 1er graph mont(re qu'il y a les gus qui optimisent leurs transition et partent vers 2400 et ceux qui assurent tous leurs pleins ... qi est en "général" vers 2900 ...

Pour ma part je suis déjà parti à 2200 du granier. En revanche je ne sais pas à quelle altitude je racrcohe. Si ça t'intéresse vraiment, quand j'aurais fini de remonter ma station, je recherche

Pour ceux qui posent ... y en a quelques uns qui vachent juste au pied ... sinon je pense que la majorité font marche arrière et retraversent l'autoroute.

[Seb26]

J'imaginais un truc comme:

Parmis ceux qui passe au granier puis dans le cylindre de 8km centré sur N45°32'40.3 / E6°03'12.8, quels sont ceux qui passent la ligne N45°35'?

Avec ça on tient aussi compte de ceux qui raccroche les bauges non pas sur la savoyarde mais en direction de montlamb.
Après, on pourait affiner en diférentiant ceux qui passe la les faces est et ceux qui tapes sur le savoyarde, en fonction de l'heure de la journée et de la saison (et des plafs). Il faudrait pour cela remplacer la ligne de passage par un cylindre de chaque cotés, là ou la majorité passe...

Et surtout, une fois que tu auras tout plein d'info sur la majorité des transitions alpines, il ne faudra pas que t'oublie de donner/vendre l'ensemble de tes résultats à reversale, flymaster et consor...
Bientôt, en arrivant au Granier, on aura droit à une jolie voie féminine qui nous dira, en fonction des cas :
 - "Ne transitez pas encore, montez encore un peu"
 - "Foncez tout droit sur la savoyarde"
 - "Tournez à droite. Visez les faces Est des Bauges"

[PiRK]

Bon il va falloir que je reflechisse a comment faire un programme un peu plus futé, les deux cylindres c'était pour tester sur des transitions connues si les resultats avaient du sens.  Je me demande encore comment je peux faire pour tester si un point est dans un polygone un peu plus complique qu'un rectangle avec des bords alignés aux meridiens/paralleles. Il faudra que je résolve ca si je veux delimiter proprement des massifs.

En attendant mes derniers résultats sont arrives pour la transition Dent de Lanfon - Roc des Boeufs et Grand Manti - Saint Genix. C'est moins evident pour ce dernier de definir un cylindre de depart, il n'y a pas vraiment de sommet mais juste une longue falaise. Ca donne :
http://pirk.wiki-parapente.fr/cfd/chartreuseWE.txt
http://pirk.wiki-parapente.fr/cfd/lanfon-rdb.txt

Je ferais les images demain.

J'ai aussi essayé d'analyser la transition Bauges-Belledonne mais je n'ai trouve qu'une trentaine de vols donc la courbe ne ressemble pas a grand chose. J'ai probablement choisi un mauvais cylindre de départ. Et apres avoir jeté un coup d'oeil aux traces il semble que beaucoup ne se refont pas vraiment au Saint Genix et posent dans la vallée avant Lumbin.
http://www.wiki-parapente.fr/wiki/Fichier:Bauges-belledonne.png

[piwaille]

Avec ça on tient aussi compte de ceux qui raccroche les bauges non pas sur la savoyarde mais en direction de montlamb.

à la limite centrer l'arrivée un poil plus à l'intérieur (voire le Colombier) et agrandir le rayon de détection ?

[Man's]

Je me demande encore comment je peux faire pour tester si un point est dans un polygone un peu plus complique qu'un rectangle avec des bords alignés aux meridiens/paralleles. Il faudra que je résolve ca si je veux delimiter proprement des massifs.

Y a des librairies sig qui font ça très bien, mais j'ai oublié le nom, faudrait demander à Marc ou retrouver le fil où on en parle (le fil du validateur de zones de vol).

[marc]

chouette projet ! je rentre juste d'une pause, donc pas suivit grand chose... Mais y'a de quoi améliorer la chose et moins se compliquer la vie

[PiRK]

chouette projet ! je rentre juste d'une pause, donc pas suivit grand chose... Mais y'a de quoi améliorer la chose et moins se compliquer la vie

A un moment donné il faudra que j'apprenne a utiliser une forge ou git pour rendre la chose collaborative.

Je ferais les images demain.

http://www.wiki-parapente.fr/wiki/Fichier:Lanfon-rdb.png
http://www.wiki-parapente.fr/wiki/Fichier:GresivaudanWE.png

[touz]

Bon j'ai presque compris le format igc, mais il me reste une petite question pour l'altitude  
Voici trois lignes en exemple :

Code:

B1212544230606N00159282EA0190202082
B1212554230607N00159277EA0190002082
B1212564230607N00159270EA0189702081

En couleur : B1212544230606N00159282EA0190202082

Ce que je comprend :

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...

Edit:
Ma source : http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html#link_4.1

[marc]

Tu peux aussi prendre gpsbabel, brancher mon super bout de python 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...

gpsbabel avec branchement python: http://github.com/dkm/gpsbabel-python-filter
exemples de code python qui mange les données crachées par gpsbabel: http://github.com/dkm/gpsbabel-python-filters (y'en a un qui se branche à la moulinette de tom payne, je dois en avoir un qui produit des objets gdal/geos). Voir le bas de cette page http://wiki.kataplop.net/wiki/doku.php?id=geek:integrated_paragliding_portal pour un peu de doc trouvée sur GDAL/GEOS + Python.

[BenHoit]

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 ....

[Seb26]

Je me demande encore comment je peux faire pour tester si un point est dans un polygone un peu plus complique qu'un rectangle avec des bords alignés aux meridiens/paralleles. Il faudra que je résolve ca si je veux delimiter proprement des massifs.

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...

[PiRK]

Oui c'est une solution interessante. Sinon je viens de voir qu'il y a un lien interessant donné dans le fil de la moulinette a espace aerien de Marc (http://www.parapentiste.info/forum/le-coin-du-geek/une-moulinette-a-espace-aerien-t14401.0.html;msg208641#msg208641) : http://local.wasp.uwa.edu.au/~pbourke/geometry/insidepoly/

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.

Edit:
Ma source : http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html#link_4.1

c'est exactement le genre de doc que je cherchais.

[thanjuzo]

J'avais fait un truc approchant, en exploitant uniquement la liste des vols CFD (pas les contenu des traces) sur plusieurs années pour trouver quel est le jour de l'année qui vole le mieux, juste en Excel.

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 :


Il y a creux aux environs du 14 juillet. Est-ce bien bizarre ?

[PiRK]

J'avais fait un truc approchant, en exploitant uniquement la liste des vols CFD (pas les contenu des traces) sur plusieurs années pour trouver quel est le jour de l'année qui vole le mieux, juste en Excel.

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 :


Il y a creux aux environs du 14 juillet. Est-ce bien bizarre ?

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).

de fin 2000 à mai 2010,

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).

[marc]

tester si dans un poly à la main, c'est réinventer la roue.... M'enfin, je vais arrêter de vendre ma sauce

[touz]

Pirk : On veux du code 
Fais comme notre maitre marc un petit compte sur github ça prend 2min

tester si dans un poly à la main, c'est réinventer la roue...

Peut être que ça roue sera plus belle et plus ronde 

[PiRK]

Pirk : On veux du code 
Fais comme notre maitre marc un petit compte sur github ça prend 2min

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.

En attendant tout est la : http://pirk.wiki-parapente.fr/cfd/
Le code lui meme c'est :

• igcparse.py, le parser copié (et simplifié) de http://github.com/twpayne/igc2kmz/blob/master/igc2kmz/igc.py
• coord.py, une classe et deux methodes pour gerer les coordonnés, inspiré de http://github.com/twpayne/igc2kmz/blob/master/igc2kmz/coord.py
• 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

Voila comment utiliser le programme : http://pirk.wiki-parapente.fr/cfd/transitions1.sh

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.

[marc]

tester si dans un poly à la main, c'est réinventer la roue...

Peut être que ça roue sera plus belle et plus ronde 

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! 

[cawotte]

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).

bin alors c'est pas une légende la saison du 10 mars au 12 juin    

[PiRK]

tester si dans un poly à la main, c'est réinventer la roue...

Peut être que ça roue sera plus belle et plus ronde  

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!  

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    .

[marc]

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

[Seb26]

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).

bin alors c'est pas une légende la saison du 10 mars au 12 juin    

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...

[thanjuzo]

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).

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 ?)

[PiRK]

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 :

             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.

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.

[marc]

http://dl.free.fr/rwj8jyNt2
http://bordel.kataplop.net/igc.tar.bz2

Ça devrait suffire. Par contre, je sais pas comment tu as récupéré toutes les traces... Si besoin, je peux supprimer rapidement tout ça

[PiRK]

-

[marc]

Si tu as besoin, j'ai trouvé un moyen d'avoir des données de résolution relativement précise (de l'ordre de la centaine de mètres) en local. Je regarde pour trouver plus précis à télécharger mais je vais déjà bosser avec ça...

[PiRK]

Si tu as besoin, j'ai trouvé un moyen d'avoir des données de résolution relativement précise (de l'ordre de la centaine de mètres) en local. Je regarde pour trouver plus précis à télécharger mais je vais déjà bosser avec ça...

J'ai pas compris. Tu parles de quelles données ?

[marc]

Vrai que j'ai pas été très explicite, limite il manque des mots dans mon message . J'ai récup des données sur les reliefs, ça permet de calculer la hauteur de vol. Moi je vais m'en servir pour vérifier le respects des zones aériennes, mais toi ça peut te servir pour voir en gros à combien au dessus du reliefs les pilotes partent...
Pour l'instant, j'ai pris la solution simple avec SRTM. Y'a mieux, mais plus difficile à télécharger, donc je pars sur du gros grain d'abord. Voilà, j'espère avoir été plus clair cette fois