Ludovic Launer

Les axes sont maintenant inutiles: Ils ne seront plus dans le fichier 2023 qui va bientot etre disponible... Cordialement, Ludovic

Bonjour Vous avez essaye de demander une version Anglaise au constructeur ? https://spekon.com/en/contact-person.html Vous avez cherche une version Anglaise ? en voici une: https://paraorg.dfv.aero/uploads/uebersetzung-re-5l_ausgabe7-endfassung.pdf Ou une version Francaise meme ? https://www.cannesvoltige.com/wp-content/uploads/2017/01/Manuel_RE-5L_Serie_3-5-FR_rev_7.pdf Cordialement, Ludovic

OK. J'ai contribue un peu, en corrigeant qq bugs et en ajoutant des petites fonctions pour changer le nom des info box par exemple. Mais je pense que le projet n'est plus viable: trop derriere XCSoar. La seule façon de faire avancer la chose serait que XCSoar évolue de façon significative dans son interface.

Exacte, je n'avais pas coche le bon type de zone. Donc j'aurais envie de dire @lool: c'est un problème lie a XCSoar, a voir si il peuvent faire qqchose. Je crois que TopHat est mort, il y a quelques commit de temps en temps, mais ca n'évolue plus du tout depuis un moment. Dommage l'interface était légèrement mieux que celle de XCSoar, qui est franchement pénible et dépassée maintenant.

Bonjour Juste pour preciser: je ne suis pas le concepteur du fichier, j'ai simplement mis en place le github afin d'en avoir une gestion participative, et reactive. Les contributeurs sont visibles sur le github. Sur les axes R71: Ils sont visibles avec SeeYou Navigator. Ils ne semblent pas l'être avec SeeYou, ou XCSoar. Comme le dit "Bob" plus haut la syntaxe est correcte, mais ca ne s'affiche pas. Je vais en discuter avec les contributeurs pour voir si on ne ferait pas un rectangle étroit... Ludovic

Bonjour Quelle version de XCSoar ? Ou as tu récupéré le fichier airspace ? Je ne reproduis pas le probleme avec: XCSoar 7.25 Fichier airspace pris de la source mise a jour regulierement ici: https://planeur-net.github.io/airspace/france.txt https://planeur-net.github.io/airspace/france.txt

Bonjour Nous avons un prufer qui vient au Versoud (LFLG) le Samedi 1 Avril 2023 Si vous avez besoin de renouveler l'ARC d'un planeur immatriculé en D-xxxx, faites mois signe, et je fais passer le message au près du prufer pour vous intégrer a la liste des planeurs a renouveler. Cordialement, Ludovic

Du contenu ? Tu veux dire que le planeur (contenu) est assure casse lors de son transport par l'assureur de la remorque (contenant) pour le montant declare ?? (valeur agrée ou déclarée ?). Je n'avais jamais entendu parle de ce cas... Dans mon cas: pendant le transport en remorque mon planeur est assure casse par l'assurance casse du planeur, et la remorque par l'assurance casse de la remorque (MAIF).

Une force: N

C’est la même chose sur les DG-800 (ou autres) avec un solo. Tu ressorts légèrement le moteur pour faire un flux d’air et refroidir. Comme le dit Vincent ce n’est pas du tout un problème. Mais tu as peut être une autre expérience ? Sur l’ASH26E évoqué plus haut, je crois me souvenir que le Wankel a tenu 200h avant de devoir être changé (32000 euros). Il semblerait qu’il ne soit pas vraiment conçu pour tourner aux régimes auxquels il est utilisé sur les planeurs (+-6400 rpm). Problèmes aussi si il ne tourne pas au moins une fois par mois. On comprend pourquoi la majorité des constructeurs utilisent plutôt des moteurs Solo.

Bah pourquoi ? En même temps on y apprend pas grand chose. Ce qu'il faut retenir: L'angle du fil de laine est 2.5x plus important que l'ange de "dérapage". Example: si il y a un angle de 25 degrés représenté par le fil de laine, l'angle de dérapage réel sur l'axe de lacet est de 10 degrés. OK...bon...très bien...

Pour le passage d'une Becker 4201 a une Becker 6201: pas de cablage ou de connecteur a changer. Simplement verifier et esssayer les reglages du gain micro. Pour passer d'une 4201 a une KRT2, deux solutions: 1) Refaire le cablage du connecteur 2) Acheter un adaptateur 4201 -> KRT2: https://www.glidingshop.eu/connectors-adapters/krt2-becker-4201-adapter

Tu te doutes bien que la version pdf ca va pas m'aider...je voulais la version exploitable sans rechercher trop longtemps...pas grave... J'ai retrouve, c'est la https://www.openaip.net/docs Je note dans ma liste de choses a faire... Cordialement, Ludovic

Donnes moi le fichier des aerodromes en question au format AIP et je verrai pour ajouter ca...

Et donc ? c'est moins dangereux ? Je ne pense pas. Et je ne vais pas prendre en compte les dates des compétitions dans l'analyse C'est pas faux. Je vais voir comment prendre cela en compte. Peut etre ajouter 30m avec 200km/h de vitesse relative.

Je vais déjà ajouter les indications. Je verrai ensuite comment retrouver une altitude de décollage "exacte" dans le cas des traces GPS. Cela suppose que le delta entre altitude GPS et altitude pression est constant, ce qui n'est pas vrai non plus...

Oui, on trouve des articles qui indiquent une précision de l'ordre de 120m en altitude. Je pense que je vais ajouter un indicateur de confiance en fonction des sources utilisées: Press + Press: 3/3 Press + Gnss: 2/3 Gnss + Gnss: 1/3

Exacte, je ne tiens pas compte aujourd'hui de la source altimétrique. En cherchant rapidement, la précision GPS en altitude semble etre de de 23m. Ce qui rend la comparaison presque inutilisable. Mais ceci dit je pourrais envisager une amélioration qui consisterait a ne comparer que des sources identiques (baro/baro ou gps/gps), ou peut être indiquer un "degrés de confiance" qui serait haut dans le cas de baro/baro, moyen dans le cas de gps/gps, et bas dans le cas de baro/gps. Ou tout simplement indiquer la source altimétrique pour le vol. Je vais voir ce que je peux faire si j'ai le temps...merci pour le conseil ! Cordialement, Ludovic

On peut maintenant sélectionner l'année: https://nearmiss.glidingcloud.net/ La génération des évènements se fait maintenant automatiquement tous les jours a 23:00, et en mettant a jour sur les 15 derniers jours (délais pour soumettre un vol a la Netcoupe) Je vais maintenant regarder comment améliorer le filtrage et diminuer les "faux positifs". J'ajouterai peut être ensuite le terrain suppose de départ... Ludovic

Merci Je viens de regarder rapidement c'est plutôt 2 fois le même vol. Il faut que je trouve un moyen de filtrer ca...

Je viens de faire une mise a jour avec les fonctionnalités suivantes: - Animation sur les traces afin de visualiser le sens de progression - "Time slider" pour filtrer par date https://nearmiss.glidingcloud.net/

Eh oui c'est un problème connu (et même documente dans l'aide) Certain vols sont soumis 2 fois par le même pilote, ou un pilote différent (biplace, 2 enregistreurs pour le même vol, ...). Ils ont été supprimés, mais il peut en rester quelques uns (trace unique, ou deux traces presque toujours identiques). Il y a même des vols déclarés 2 fois par le même pilote. Il y a déjà pas mal de couple de traces supprimes: J'ai considéré que si un couple de traces générait plus de 20 événements c'est qu'il était déclaré en double.

@jpmacveighMerci pour l'info. Par contre je ne peux pas utiliser l'approche appel vers une API REST pour plusieurs raisons: Problématique: Il faudrait pouvoir vérifier que l'évènement n'est pas au "décollage" a proximité de l'aérodrome (ou du fix GPS de décollage) Pour information: - Les données brutes font 218 407 689 lignes pour 21Go - Apres détection des évènements il reste 470 lignes: même si c'est "one shot" et via du soft, je ne vais pas faire 470 appels, même si l'API permet de faire la requête en 1 appel ca ne répond pas forcement a la problématique. - Je ne pense pas que cela soit une bonne idée de faire du processing cote client (navigateur) 1)J'ai le fix GPS du décollage, je peux le réinjecter dans la base pour tenir compte du delta entre une position et l'alti de décollage. Par contre ca marche moyennement (=ne marche plus) si on décolle d'un terrain haut et que l'on va vers des endroits plus bas. Sinon je ne vois finalement pas trop comment filtrer ces effets de bord... Mais du coups implémenter 1) pourrait en effet permettre de diminuer un peu cet effet, et je pourrais aussi ajouter l'information sur le terrain supposé de décollage (après avoir écrit un petit morceau de code pour avoir les aérodrome dans une base.) Bref: A voir ... je vais déjà faire un "time slider" pour sélectionner une plage de date dans l'appli web. Apres si l'information de near-miss est intéressante, je peux voir comment générer ces évènements automatiquement jour par jour pour une utilisation similaire a la heatmap et tracemap.

Pour le moment je considère les points a une altitude >500m Une future amélioration consiste a considérer l'altitude de décollage et de ne considérer que les points >500m au dessus de l'altitude de décollage. Idéalement il faudrait considérer 500m au dessus du sol.

@Centurion Dans ce que tu donnes, mis a part le titre, il n'y a pas de changement dans les contours par rapport a la dernière version disponible. L'idée est que ce fichier est maintenu par la communauté, tu peux donc faire une modification, et une pull request pour intégrer la modification dans le fichier.