+ Le chant du vario +

si ca te va de faire ca va geodjango & bd postgis, je suis partant pour participer ! Ca sera plus simple que les espaces aeriens, dont finalement, tout le monde se fout :)

Est-ce qu'un gentil modo pourrait scinder ce sujet juste apres la premiere reponse de Mathieu et deplacer la suite dans le coin du geek avec un titre qui va bien ?   :trinq:

Bon, j'ai pas ete tres clair dans ma requete et du coup il manque deux ou trois messages qui permettent de comprendre qu'on parlait de faire un outil de recherche  geographique de vols CFD en utilisant les traces GPS :) Il se peut que ca degenere en un truc plus general sur l'utilisation des traces GPS pour diverses statistiques (je pense par exemple a une carte des thermiques en additionnant les Vz a un endroit donné).

Pour commencer j'ai fait une liste par saison des vols déclarés a la CFD avec les infos disponibles sur le site de la FFVL : http://pirk.wiki-parapente.fr/cfd/listes_vols/

Il y a deja de quoi faire de belles statistiques pour les amateurs de graphiques excel.

Non, non, tout le monde ne se fout pas des espaces aériens. J'attends avec impatience ta moulinette pleinement fonctionnelle  ;)

Mais si en plus tu y ajoutes les fonctions suggérées par PiRK, alors là moi je dis  karma+

Ca avance petit a petit :
(http://188.165.48.115/tmp/cfdsearch.png)

Il faut que je fasse des tests pour decimer les traces GPS avant de les charger dans la bdd parceque pour l'instant c'est assez lent si on centre la zone de recherche sur Saint Hil. Et apres il va falloir s'attaquer aux aspects cosmétiques de l'interface.

:jump: :jump:

L'interface, je pourrais aider... dans quelques temps ! On pourrait même intégrer avec le machin à espace aérien, vu que bizarrement, on utilise la même techno :mrgreen:

Bravo !!!!

Ouahou, à vous deux (Pirk et Marc) vous allez nous sortir un outil bien sympa. Désolé mes compétences sont limitées dans ce domaine (la programmation). Juste fait un peu de Basic et C++ ... il y a bien longtemps.

 karma+ et  karma+

c'est gentil, mais à part donner qqs pointeurs à Pirk, j'ai rien fait, donc c'est juste lui qu'il faut féliciter  :grrr:
 :trinq:

Euh et la moulinette à espaces aériens ça vient pas de toi ?

Donc système de recherche géographique de Pirk + moulinette de Marc (et quelques pointeurs) = cet outil bien sympa
D'où un  karma+ à chacun.

Marc, tu es trop modeste  ;)

Oui, Marc, ne soit pas si modeste. Sans toi j'aurais programmé le truc en assembleur ;) Avec ton interface graphique ca aura nettement plus de gueule.

Il reste tout de meme un peu de boulot de mon coté, il faut que je trouve l'intervalle d'echantillonage maximum acceptable pour alléger le plus possible les traces. J'ai testé 9 s, mais ca prend toujours 1 minute pour la recherche centrée sur Saint Hil, et chaque année on va rajouter ~2000 traces a la bdd. Dix secondes pour un parapente qui vole en ligne droite bras haut sans vent  ca fait deja 100m  :?

super vos truc les gars, continuez !  karma+ & karma+

J'ai besoin de vos avis de potentiels utilisateurs. J'ai fait quelques tests pour trouver la methode la plus efficace pour decimer les traces.

J'ai les resultats suivants :
* sur mes ~ 14500 traces GPS, j'ai un total de 43 millions de points
* si je decime en prenant pour critere un minimum de 10 secondes entre 2 points, j'ai 15 M de points
* si je decime en prenant pour critere un minimum de 20 secondes entre 2 points, j'ai  8 M de points
* si je decime en prenant pour critere un minimum de 50 metres entre 2 points, j'ai 18 M de points
* si je decime en prenant pour critere un minimum de 100 m entre 2 points, j'ai 9 M de points
* si je decime en prenant pour critere un minimum de 150 m entre 2 points, j'ai 6 M de points
* si je decime en prenant pour critere un minimum de 200 m entre 2 points, j'ai 4.6 M de points
* si je decime en prenant pour critere un minimum de 300 m entre 2 points, j'ai 3 M de points
* si je decime en prenant pour critere un minimum de 400 m entre 2 points, j'ai 2.3 M de points
* si je decime en prenant pour critere un minimum de 500 m entre 2 points, j'ai 1.8 M de points

On voit que filtrer avec un critere de distance marche mieux qu'avec un critere de temps, parcequ'on se debarasse de toute l'info sur les enroulages de thermiques qui ne sert a rien dans notre cas.
Pour moi, moins j'ai de points et mieux ce sera (plus rapide, moins de ressources, moins de chances de planter si plusieurs utilisateurs se connectent en meme temps). Personnellement je pense que la precision de 500 m serait suffisante, si j'ai besoin de trouver les traces qui  passent par un sommet donné je dessinerais un gros carre de 1 ou 2 km de coté. Mais en meme temps, au-dela des 200 m on n'a plus tellement de gain en efficacité, donc c'est probablement ce que je choisirais.

Si vous deviez utiliser ce programme pour trouver une trace GPS, combien de precision vous faudrait-il ? (voila une echelle pour vous faire une idée : http://www.paraglidingforum.com/xcplanner/?location=Fiesch&flightType=cfd2&turnpoints=[[45.23537,5.76211],[45.23673,5.76044]])



 

 :coucou:

une idée (qui vaut ce qu'elle vaut hein ;) )
et si tu commençait par séparer les traces par région ? (après, quand tu cherches un point, tu sais retrouver de quelle région il s'agit)
tu stockes les traces (CFD) dans diverses bases : alpesN, alpesS, pyrénées ...

tu va me dire : le blème c'est que les traces des alpesN sont sur-majoritaires ... ben tu peux continuer à diviser jusqu'au niveau : chartreuse, belledonne etc ...
et les traces qui vont d'un massif à l'autre elles peuvent bien être doublées (triplées) vu que tu aura divisé ton temps de recherches.

non ?

Avant de chercher à optimiser, il faut savoir ce qui coûte chers. Le nombre de points coûte :
 - en stockage: ça, je n'y crois pas trop, le stockage coûte plus grand chose
 - en calcul: certes. Mais avant de toucher aux données, il est parfois possible de "mieux" calculer.

Une fois que t'as retiré de l'info, c'est perdu pour toujours. Je serais toi, je calculerai différemment plutôt que de dégrader les données. Tu peux aussi faire du précalcul, comme à partir d'une trace, prendre une trace dont la topologie est équivalente ('simplify' je crois dans geos) mais avec le minimum de point nécessaires. Pour les polygone, je vois bien. Avec des traces, il faudrait tester pour voir si ça convient (tu l'as peut être déjà fait).

Et quand tu dis "on n'a plus tellement de gain en efficacité", tu as mesuré comment ? C'est quoi que tu appelles "efficacité" ?

La séparation par région n'aide pas, la BD fait déjà un tri par boîte englobante, et les traces qui traversent plusieurs région sont rares.

Perdu pour toujours, bof... on peut facilement faire deux bdd separees, une avec tous les points pour nos applications du futur et une allégée qui ne servira que pour la recherche. Comme tu dis l'espace disque n'est pas cher, d'autant plus que la base de donnees prend significativement moins de place que la somme des fichiers IGC d'origine.

Pour le precalcul, je n'ai pas encore testé, il faut que je vois ca. Mais l'idée que je m'en fais c'est que ca va pas etre forcement adapté a une trace GPS d'un vol en parapente, qui est quelque chose de tres specifique. Ce que j'essaye de faire en mettant une distance mini entre points c'est de virer tous les thermiques qui concentrent les points sans rien apporter a la recherche. J'ai peur qu'une fonction de simplification standard soit plus adaptee pour reduire le nombre de points sur de grandes lignes droite que pour des petites spirales. Mais comme dit, il faut que je teste.

Je parle juste du taux de reduction du nombre de points par unité de distance perdue en precision. Genre quand on passe d'une precision de 50 m a 100 m on divise par 2, quand on passe de 400 a 500 le gain marginal est nettement plus faible.

eumpf .. me permet de réfléchir à "voix haute" hein ;)

2 bases de données peut être pas ... mais 2 tables :
une table des points et une table des chemins (qui relie les points) ...
du coup dans ta table des chemin tu peux avoir (pour 1 même vol) et le chemin complet et le "symplify" (un DL2 5 ? ) qui "représente" le vol

réflexion suivante : quand tu calcules le simplify (si tu te fais une fonction perso), vu que tu as le temps, tu peux déjà tenter de t'appuyer sur des points déjà existants ... un peu comme le fait actuellement la déclaration CFD : la trace passe à moins de x km de tel point remarquable (remarqué) ... on la fait passer par ...
après faut nourrir la base des points remarquables :grat:

Plutôt que 2 tables, 1 champs supplémentaire serait plus judicieux/facile (Pirk utilise GeoDjango) 1 vol serait alors représenté par sa trace complète et une version simplifiée (+ d'autres info bien sûr).

Oui, ca serait un gros boulot.

Je ne sais pas exactement comment fonctionne une base de donnees et qu'est ce qui influence la performance des recherches, mais quand j'ai fait mes test "traces completes" vs. "decimation a 10s" vs. "decimation a 20s"  j'ai eu l'impression que la recherche des traces etait quasiment instantannee dans tous les cas mais que ca ralentissait au moment d'y acceder en fonction de la quantité de données trouvée meme en n'accedant qu'a des champs leger tel que le nom du pilote, la distance... donc avant meme d'essayer d'acceder a la trace. Donc je me demande si rajouter un champ tout en gardant la grosse trace complete va vraiment arranger les choses. Mais je rajoute ca sur ma liste de tests a faire quand j'aurais le temps.

EDIT: Peut-etre que la recherche initiale se fait uniquement sur les boites englobantes et que la recherche precise se fait par la suite au moment d'acceder aux donnees  :grat: Tu comprends comment ca marche precisement, Marc ?
Si l'idees de faire deux champs fonctionne, on peut meme imaginer faire une recherche initiale sur le champs avec une precision de 500 m voir 1 km puis une seconde recherche avec la trace complete sur le premier sous-ensemble.

EDIT2: Non, en fait mon idee est conne. On va perdre des traces a la premiere recherche et on va pas les retrouver a la deuxieme.  :clown:

Plusieurs choses... Faut voir quelle opération prend du temps *exactement*. La BD fait effectivement un filtre avec les boîtes englobantes (cherche "index spatial", regarde ce que fait la bibliothèque "rtree", par exemple. Il y a beaucoup de chose à lire là dessus) pour les opérations qui peuvent en bénéficier (recherche d'intersection & cie).
Par contre, tu utilises une couche d'abstraction qui potentiellement te cache des opérations coûteuses ! La recherche peut être super rapide, et dès que tu regardes les valeurs retournées, ça prend du temps: peut être que tu fais des conversions sans t'en rendre compte ? (pense que tu agis à plusieurs niveaux: BD/postgis, puis GeoDjango, puis GEOS, puis peut être JSON & cie ? Une même opération peut se faire à chaque niveau, mais à des coûts très différents ! Autant que possible, il faut faire les opérations coûteuses au niveau BD car elle est sensée être fait pour ça. Plus tu montes dans les abstractions, plus ça va te coûter bonbon. Si tu boucles sur les points d'une trace dans ton code python par exemple, ça va être lent à mourir.

Effectivement, rajouter un champs dans la table ne va pas arranger ton problème car je pensais l'utiliser pour les recherches, qui sont déjà instantanées d'après ce que tu dis. Si tu peux me dire où dans ton code se passe l'opération qui prend trop de temps à ton goût, je peux essayer d'y jeter un oeil...

Ce qui est instantane c'est quand je fait :

Et ce qui prend du temps c'est d'acceder a un element ou tous les elements de v :

A noter que dans le cas des commandes qui accedent a toutes les donnees (len(v), print(v) ou la boucle for), seule la premiere prend du temps. Les suivantes sont instantanees.

Je fais l'equivalent de la boucle for dans mon template de page web, je perd peut etre de la performance avec la couche django.contrib.template.

Je connais pas PostGis, mais je suppose que
Ca te fait un prepared statement lors de l'instanciation de v, mais à ce moment là la requete n'est pas éxécutée.


Quand tu accèdes pour la première fois à ta ressource (ton instance v) la requête postgresql est exécutée. Ce qui est bizarre c'est que print(v[156].distance) mette ensuite 15sec. Cela voudrait dire qu'une requete spécifique est réalisée pour accéder à cet élément. Marc va me corriger sur le python, mais je pense qu'à chaque accès à une donnée de ta liste v, tu crées une nouvelle instance d'un objet postgis ou que sais-je (ton v[156] ou tous les tmp dans la boucle) et qu'à chaque fois une requete est exécutée (on a les mêmes problèmes avec des couches d'abstractions de bdd en php comme doctrine ou propel)

Tu pourrais sniffer ce qu'il se passe entre ta base postgresql et ton programme avec un bon vieux , ou débugger chaque requete sql depuis python et ainsi voir exactement quelles requetes sont exécutées et à quel moment. Y'a pas moyen de construire ton v comme une liste imbriquée de données ou alors une liste avec des dictionnaires imbriqués et non pas une liste d'objets postgis, comme ça a l'air d'être le cas (puisque distance est un membre de l'instance v[156] dans l'exemple) ? Ca te ferait une bonne grosse liste en mémoire (quoique 2476 éléments y'a pire...) mais une seule requête initiale (ça fait un bail que j'ai fait ni python ni sql hein, pas tapper :D )

Ce que je voulais dire c'est que chacune de ces commandes met le temps spécifié si je l'execute directement apres l'instanciation de v. Mais une fois que j'ai executé une commande qui accede a toutes les données, les suivantes prennent chacune moins d'une seconde (y compris l'acces a un champ distance d'un element v[156]).
Donc je suppose que si je lance n'importe quelle commande qui doit acceder a au moins un champ de chaque element, ca force la requete a etre completement executee et on doit se retrouver avec une simple liste d'objets python en memoire.


Pour en revenir a l'histoire de la simplification de la trace, on m'a dit sur un autre forum que l'algo utilisé par "simplify" est Douglas-Peuker (https://secure.wikimedia.org/wikipedia/fr/wiki/Algorithme_de_Douglas-Peuker). Ca a l'air bien efficace pour ecremer la trace en gardant la forme generale, j'ai hate d'avoir le temps de le tester (en ce moment je passe moins d'une heure devant un pc par jour, trop de vrai boulot  :( ).  Mais on va forcement perdre des donnees dans l'affaire.

Simplify <=> DP, c'est marqué dans la doc ;)

Sinon, tu peux rapeller sur quelle type de machine tu fais tes tests ? Je crois que tu parlais d'un EeePC à un moment... Les BD restent des applications relativement gourmandes en ressources. Si ton code est facilement distribuable, je peux tester sur la machine que j'utilise pour mes tests.

Oui, c'est un EeePC avec 1 Go de ram, c'est pas tres performant comme bete. Et je fait mes test sous windows, ce qui n'arrange pas les choses. Je vais essayer de mettre ce que j'ai deja fait en ligne quand j'aurais le temps. Il ne doit pas y avoir grand chose a adapter, juste un ou deux noms de fichiers codés en dur dans ma fonction de chargement des traces GPS.

J'ai pas reussi a trouver dans quelle unité la tolerance doit etre exprimé. Metres ? Degres ? Minutes d'arc ?

tu me dis !

en général, quand rien n'est spécifié pour les unité, c'est que c'est "agnostique", la distance étant calculée classiquement à partir des coordonnées que tu donnes. Si tu donnes des coord GPS (lat/lon), tu travailles avec des mesures d'angle... Je t'avoue que je me suis pas casser la tête quand j'ai eu à faire un échantillonnage basé sur la distance: j'ai regardé quelle était la distance mesurée de 2 points que je savais à 50m l'un de l'autre et ai utilisé cette valeur... C'est un peu approximatif (en principe, la terre n'étant pas ronde, la correspondance angle/distance projetée n'est pas constante avec la position).
Si tu veux un truc un peu plus exact, tu dois pouvoir jouer avec la classe Distance offerte par GeoDjango... Mais là, ça me semble un peu overkill. Ma bidouille devrait déjà donner des résultats acceptables ;)

Tu veux dire qu'on considere des coordonnees spheriques  comme des coordonnées lineaires ?  :affraid:
C'est vrai que pour ce que jeux en faire, a l'echelle de la France on peut faire une bidouille dans ton genre, mais faut voir si ca va encore marcher convenablement pour les traces GPS de la reunion  :grat:

Je suis pas sûr qu'on se soit compris... Mais si tu prends 2 points dont les coords sont données par (lon1, lat1) et (lon2, lat2), la distance euclidienne (sqrt( (lon2-lon1)²+(lat2-lat1)²)) te donnes bien une distance... Elle est juste pas en mètre, et tu as le droit de t'en servir :D. Ça va coincer dès que tu va avoir besoin de raisonner "distance classique" (en mètre, projetée sur un plan).

Mon approximation, c'est qu'une distance X calculée comme ça aura une valeur projetée constante Y. Plus la distance considérée est petite, moins ça va nous gêner. Les 2 trucs qui sont approximer:
 - la terre est ronde, pas plate
 - la terre n'est pas une sphère parfaite

Pour des distance de 50m, je doute que ça vienne perturber nos calculs. Très souvent les calculs qu'on croisent font l'approximation que la terre est une sphère, ça ne choque personne (à juste titre). Ce genre d'approximation est par contre gênante si tu cherches à calculer la vitesse de neutrinos. Les parapente, je pense que ça va aller :)

Utiliser des coordonnées sphérique "comme ci" c'était des coordonnées linéaire, ça marche pour plein de chose... tant que tu n'a pas besoin de la distance projetée au sol. Si tu regardes par exemple la bibliothèque "shapely" (souvent utilisée avec des coords sphériques), c'est ce qui se passe.

Donner comme tu le suggères, le même poids relatif aux minutes de latitude et aux minutes de longitude dans un calcul de distance est suffisamment OK pour une 1ère approximation, tant qu'on ne monte pas dans des latitudes importantes.

Plus près des pôles, on peut franchir des milliers de minutes de longitude en un seul pas.

C'est pourquoi la formule "correcte" utilise plutôt : (lon2-lon1)/cos(lat moyenne)

Effectivement, je n'y avais pas pensé :)

Le soucis c'est qu'un degre de longitude a une longueur variable et generalement differente d'un degre de latitude, donc ca va introduire de l'anisotropie dans la simplification, je vais avoir moins de precision dans la direction Nord-Sud que dans la direction Est-Ouest. Et c'est pas negligeable, en France ca fait un rapport de 1/1.42.
http://www.paraglidingforum.com/xcplanner/?location=Fiesch&flightType=cfd2&turnpoints=[[45.0,5.5],[46.0,5.5]]
http://www.paraglidingforum.com/xcplanner/?location=Fiesch&flightType=cfd2&turnpoints=[[45.25,6.0],[45.25,5.0]]

Au minimum il faudrait multiplier toutes les longitudes par le sinus cosinus de la latitude.

EDIT : grillé par Hub

Dans ce cas, le mieux (je pense) est de projeter tes données avant de faire le calcul, mais ça risque de te coûter assez chers et il va falloir choisir la projection judicieusement en fonction des données traitées.

Et cette imprécision, ça va donner quoi au final tu penses ? J'ai du mal à voir l'impact que ça peut avoir sur la simplification des données.

Si je convertissais 1 m en x degrés en me basant uniquement sur les degrés de latitude, avec une tolerance de 100 m j'aurais effectivement une tolerance de 100 m dans la direction N-S mais une tolerance de seulement 70 m dans la direction E-W parcequ'un point situé  x degrés de longitude d'une ligne N-S seraient considéré comme étant 100 m alors qu'il n'est  qu'a 70 m (et dans une direction intermediaire, ca serait une valeur intermediaire entre 70 et 100). Ca serait pas critique, mais par rapport a la simplification rigoureuse on perdrait en efficacité si on se base sur la direction N-S pour la conversion m<->degrés et on perdrait en précision si on se base sur la direction E-W.

C'est quand même pas la mort de diviser par un cos(lat1+lat2/2) précalculé, pour avoir une distance plus "correcte" ?

[je veux dire cos(latmin+latmax/2) bien sûr, pas la peine de recaculer le bazar pour tous les points]

Oui, c'est une solution simple qui va bien marcher (sauf pour la Reunion et la Polynesie). Mais rien que pour le plaisir de faire un peu d'algorithmique, je reprogrammerais bien un Douglas-Peucker avec la distance rigoureuse en coordonnees geographiques (http://fr.wikipedia.org/wiki/Distance_du_grand_cercle). On verra si j'ai le temps. Pour ce qui est de la performance qui sera probablement degradee, c'est pas tres grave vu qu'on parle d'un bout de code qui ne sera appliqué qu'une seule fois au moment de charger les traces dans la base de donnees. Au lieu de 2 heures ca va prendre 6h, juste le temps d'aller faire un cross et de revenir en stop  :ppte: .

Si vous voulez du millimètre, c'est ceci qu'il vous faut :
http://geodesie.ign.fr/contenu/fichiers/Calcul_distance_volOiseau.pdf (http://geodesie.ign.fr/contenu/fichiers/Calcul_distance_volOiseau.pdf)

 :init:

Bah pourquoi ça marcherait pas pour léziles? 
Ca marche pour toute distance entre 2 points quelconques pas "trop" éloignés l'un de l'autre, en divisant le delta-longitude par le cosinus de la latitude moyenne de ces 2 points.
Mébon, je n'ai ptêt pas comprite la distance que tu veux calculer, c'est bien possible que ça marche pas trop bien pour la distance entre la métropole et léziles.

J'avais dans l'idee de faire la bidouille en prenant une latitude moyenne pour toute la France, donc j'aurais ete oblige d'en definir une autre pour leziles.

Ah OK, vu.  Je pensais (je n'ai pas lu toute la discussion) prendre une latitude moyenne pour un vol, ce qui (en l'état actuel de nos performances) ne s'étale pas sur plus de 2-3 degrés de latitude...

Et avec une simplifcation de Douglas-Peucker:
* tolerance 10 m : 15.0 M de points (~34.4 % du nombre initial)
* tolerance 25 m : 9.5 M de points (~21.8 %)
* tolerance 50 m : 4.4 M de points (~10.1 %)
* tolerance 75 m : 2.4 M de points (~5.5 %)
* tolerance 100 m : 1.6 M de points (~3.7 %)
* tolerance 150 m : 1 M de points (~2.3 %)
* tolerance 200 m : 0.7 M de points (~1.7 %)
* tolerance 500 m : 0.3 M de points (~ 0.67 %)

(http://pirk.wiki-parapente.fr/tmp/dp_eff.png)

C'est mucho bueno ! A 10 m de tolerance on divise deja le nombre de points par 3 ! Je vais essayer de charger les traces avec une tolerance de 75 m pour voir de combien ca ameliore la vitesse de la recherche.

Pour le calcul de la distance j'ai corrigé la longitude avec la latitude moyenne du vol comme tu le suggerais, Hub. La distance du grand cercle c'est plus complique que ce que je croyais, il ne suffit pas de connaitre la formule entre deux points, il faut aussi trouver la distance du grand cercle entre un point et un autre grand cercle et ca fait mal a la tete.

J'ai une carte pour la recherche maintenant. Voila a quoi ca ressemble pour l'instant :
(http://img535.imageshack.us/img535/7346/recherchecyclemap.png) (http://imageshack.us/photo/my-images/535/recherchecyclemap.png/)
(http://img59.imageshack.us/img59/6555/resultatszn.png) (http://imageshack.us/photo/my-images/59/resultatszn.png/)
Uploaded with ImageShack.us (http://imageshack.us)

Il faut encore que je corrige ma liste de vols, j'ai un paquet de vols qui ne sont pas assignés aux bonnes traces GPS. Je vais peut-être aussi ajouter d'autres options de recherche (intervalle de dates, distance mini, nom du pilote, tri par date...).  Pour le côté bling-bling on peut éventuellement aussi envisager d'afficher quelques-uns des premiers vols de la liste sur la carte, même si ca sera pas très intéressant (pas de données d'altitude pour le moment) et que le but est plutôt de fournir les liens vers le site de la FFVL.

Si tu convertis les traces en GPX et que tu les mets sur ton site web dans un coin, Openlayer peut les afficher gratuitement sur ta carte :) Bravo !

Au cas où, voici un lien vers une page que j’ai trouvée assez complète :

http://www.movable-type.co.uk/scripts/latlong.html (http://www.movable-type.co.uk/scripts/latlong.html)

Désolé pour ceusses qui ne pratiquent pas la langue anglaise.

Sportivement (ou pas)

J'ai été fouillé un peu mon code pour voir quelle approximation je fais, et si je risque le problème cité plus haut (suivant la latitude, l'approximation passe d'insignifiante à pas pas du tout insignifiante :mrgreen:), et j'ai vu que je ne faisais pas ce dont je me rappelais :)
Mon "pas" X d'interpolation est un angle, dont je me sers pour trouver "le point situé à une distance X d'un point P" le long d'un trajet. Je ne me soucis pas de la localisation précise, c'est sensé être géré par les couches inférieures (GEOS en l’occurrence). En principe, il pousse même jusqu'à utiliser un modèle non sphérique de la Terre, mais j'avoue être passé un peu vite là dessus, je lui fais confiance... Et puis de toute façon, en principe, aucun calcul n'a besoin de projection...

Bref, finalement, j'ai peut être pas fait tant de la me*** que ça  :mrgreen:  :trinq:

Ta base de recherche est-elle accessible?
Il existe en effet une recherche qui m'intéresserait bien mais qui n'est pas possible sur le site de la cfd: identifier les traces passant à proximité d'un point (dans la cfd il n'est question que de site de décollage ou de département de décollage).

Je n'ai jamais mis le truc en ligne. Le programme fait quelques dizaines de lignes de code et traine sur un vieux netbook. Pour le mettre sur le net il faudrait un bout de serveur bien configuré et quelques compétences additionnelles (je crois que ce qui coinçait pour moi c'était l'installation du plugin apache pour faire tourner du python).

Ah ok, sinon, il faudrait peut être voir avec la fédé ou plutôt ceux qui gèrent les quelques applis autour de la cfd pour voir s'il n'y aurait pas moyen d'intégrer ta moulinette sur le site cfd...

Il faut que je remette le nez dans le projet. Peut-être que si j'arrive à retrouver tous les morceaux (du chargement de traces GPS dans la base de données à l'affichage d'une carte pour dessiner les zones de recherche) et à documenter tout ça proprement, on pourrait peut-être convaincre le webmaster du site de la FFVL de le faire tourner et de mettre en place une mise à jour régulière des traces GPS pour rajouter les nouveaux vols au fur et à mesure.

On en parle début de semaine PiRK. Sinon, on se fait ça sur mon serveur :)

Cool  :pouce: