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