jben a écrit 839 commentaires

C'est ce que je pense faire, en même temps qu'en prenant en compte la notion de pied à terre dans les côte. En gros, le pied-à-terre coûtera plus cher en énergie (il suffit d'utiliser pour cela ce qu'on trouve dans la littérature sur le rendement de la marche à pied (c'est peu efficace comme moyen de transport comparé au vélo), et ce mode pieds-à-terre sera invoqué sur les voies piétonnes et les côtes qu'on ne peut pas passer à vitesse convenable.

Cx étant bien entendu sans unité. Je vais m'autoflageller pour cela.

En fait dans l'interface web que je propose, tu peux changer la valeur de S·Cx, qui est le produit de la surface frontale et du coef de pénétration dans l'air, sans problème. Par contre dans le cas d'un vélo couché, je ne pense pas que ça soit le Cx qui soit radicalement différent, mais plutôt le S, il semble même que le Cx soit un peu plus élevé pour un vélo couché (comprendre la position est moins aérodynamique à surface égale).

En glanant des valeurs sur internet, et gros le S d'un vélo droit est entre .45 et .55 m², dans le cas d'un vélo couché il semble être entre les .25 et .35 m², le Cx étant dans tous les cas aux alentours de .8 m² (ces chiffres sont donnés à la louche, ils varient beaucoup selon la position sur un vélo droit et la conception du vélo couché). Après il y a aussi moyen d'influer sur le Cx, c'est ce qu'on fait avec le profilage, tout ce qui est casque profilé (comme on en voit dans les contre-la-montre), vélo couché carénés ne modifie quasiment pas le S mais font fortement diminuer le Cx (le but étant de réduire les turbulences qui vont entraîner une forte dépression à l'arrière du cycliste).

Après pour déterminer ce S·Cx il y a plusieurs méthodes, prise de photo de face pour déterminer la surface frontale, approximations pour déterminer le Cx. Essai en soufflerie pour déterminer le S·Cx. Ou la methode artisanale qui donne d'assez bon résultats, qui est de chercher à atteindre la vitesse limite dans une descente (sans pédalage bien sur), et d'avoir plusieurs valeurs pour differentes pentes. À partir de cela on peut retrouver le coef de roulement et le S·Cx (mais on ne pourra pas faire la distinction entre ce qui vient du S et du Cx, on s'en fout un peu de toute façon).

En fait tu as assez bien fait le tour du problème sur les feux. Prendre en compte les feux en moyenne avec indépendance donne des résultats complètement farfelus. C'est possible de quantifier une perte moyenne par feu, mais la non-indépendance entre les feux rend cette quantification incorrecte. J'ai fait des essais sur une ville que je connais bien, qui a sur des boulevards un nombre de feu très important avec une distance entre les feux faible. En ajustant la perte d’énergie en se basant sur des feux normaux, dans le cas de ces boulevards, c'est du n'importe quoi, car dans la pratique les feux sont synchronisés (et heureusement vu la distance entre les feux) et c'est un plaisir d'emprunter ces boulevards.

Bref, je suis un peu bloqué de ce coté là.

Après, je ne vise pas forcément un public cherchant à faire du routage en milieu urbain, mais plutot à faire de la planification de randonné. En fait c'est pour ça que moi je j'ai développé, et c'est pour ça que moi je l'utilise. Avant de partir (ou pendant la rando), je planifie mon itinéraire, que généralement je garde tel que, et je le rentre dans mon GPS (sur mon guidon), puis je pars, et je le suis plus ou moins. Généralement c'est plus moins que plus, mais ça me permet d'avoir un idée. Après quand je suis sur le vélo, il y a toujours des moments où j'ai envie de prendre une autre route, d'aller voir la mer, de monter sur un point d'observation pour voir le paysage, ou d'aller voir un site touristique qui est indiqué par des panneaux. Je suis complétement incapable de suivre un itinéraire, mais j'utilise rv pour avoir une idée.

Concernant les VAE, ça ne m'interesse pas, et pour plusieurs raisons. La première c'est que les différentes technologie des VAE sont à prendre en compte (récupération de l'énergie cinétique au freinage, limitation de la vitesse en descente avec ou sans récupération d'énergie, efficacité du stockage, rendement du moteur en mode moteur ou récupération, puissance apporté en fonction de la vitesse) bref, un sac de parametres qui n'a rien à voir avec le cyclisme. L'autre raison, c'est que je conchie une partie des VAE. Disons que j'étais au début très favorable, et j'ai vu nombre de personnes utiliser un VAE alors qu'elles n'utilisaient pas le vélo, et j'ai vu ça comme un progrès. Mais j'ai l'impression que les mentalités sont en train de changer, avec non plus des vélo à assistance mais des vélo à propulsion électrique, bien entendu toujours vendu en tant que VAE.

Plusieurs fois, alors que je suis à ma vitesse de croisière sur le plat (entre 30 km/h et 32 km/h, c'est mon rythme), je me suis fait doublé par des vélos électriques qui avait un différenctel de vitesse par rapport à moi d'environ 10 km/h. À 40 km/h, ce n'est plus de l'assistance, c'est de la propulsion (et d'ailleurs le code de la route requiert que l'assistance se désactive au dela de 25 km/h). Il y avait aussi une côte à la fin de mon trajet à Paris où je mettais la gomme (car j'étais chaud, et comme c'était la fin, j'en profitais pour finir en beauté), et je la montais à 25-30 km/h en danseuse, et régulièrement j'ai vu des VAE avec le cycliste bien assis sur sa selle sans forcer à 30 km/h. Donc je suis favorable au vélos à assistance, pas au vélo à propulsion, et j'ai l'impression que la seconde catégorie est en train de devenir dominante (et contradiction totale avec le code de la route).

Ton hypothèse de départ est fausse. Sans les baguages ma masse roulante n'est pas de 100kg, la masse du bipède n'est pas négligeable, loin de là.

Après j'ai plus que 12kg de baguage. Quand je pars en rando, je bivouac sur le chemin, et j'aime avoir mon petit confort. J'ai donc tente, duvet, réchaud, riz, casseroles, café, cafetière, bouquins pour occuper les soirées (un jour je passerai à la liseuse électronique)… J'ai aussi tout ce qu'il faut pour faire des réparation si nécessaires (chambres à air, pompe, outils divers, pneu de rechange, rayons (depuis peu), maillons de chaîne…). Et enfin, j'ai mon stock d'eau (environ 10L, important quand on bivouac).

Alors oui, il y a moyen d'emporter moins, mais que veux-tu… Je vais ça pour le plaisir, pas pour me retrouver dans un inconfort.

Alors pour le coup, vu la dimension du bazar je ne suis pas sur que faire un recuit simulé avec une décroissance de la température à une vitesse pas trop brutale soit plus rapide qu'un A*. Ton problème étant absolument bourré de minimum locaux (la montage on la contourne par la droite ou par la gauche), que un au final la décroissance de la température que tu devra mettre pour avoir un résultat proche de l'optimal rend inutile le soit que tu as apporté à l'initialisation du SA. Ou alors tu fous un SA avec une decroissance tellement rapide de la température, que ton algo ça va quasiment être un algo glouton. En plus dans tous les cas, tu as un résultat non garanti (et non deterministe). Bref, je ne suis pas favorable.

En plus entre les nœuds de ton maillage, il est pas possible de calculer le chemin le plus court, le chemin étant dépendant des paramètres. Une solution serait de discrétiser l'espace des paramètres, et pour chaque jeu de parametres calculer les chemin les plus court. Non, beaucoup, beaucoup trop gros.

Bref, il y a moyen de faire mieux que ce que j'ai, mais pas avec cette methode je pense. Une manière d'obtenir un résultat plus rapidement, serait d'utiliser une heuristique non-admissible dans l'A*, de telle sorte à avoir une solution plus rapide, mais au coût de perdre la garantie d'optimalité.

Ça ne revient pas au même.

En fait tu consomme plus dans la côte, mais tu accumule de l’énergie potentielle. Et tu n'as pas de résistance de l'air vu ta vitesse. En descente toute ton énergie potentielle part dans la résistance de l'air et tu atteint ta vitesse limite.

Comme l'énergie dissipée dans la résistance de l'air est en (distance×v²), à cause du carré, la moyenne des énergies des deux vitesses est plus élevés que l’énergie de la moyenne des deux vitesses.

Après il est vrai que ça ne change pas grand chose, mais le cœur de l'algo est de jouer avec ce pas grand chose pour proposer des trajets interessants.

Oui bien sur, c'est moi qui suis bête. Je vais le faire.

Bof, c'est très général comme point de vue. Et il y a nombre de contre exemples. Dans ce genre de cas on risque avantager ou pénaliser des carrefours par rapport à l'inverse de l'objectif. Je préfère ne rien faire dans tous les cas.

Je ne veux pas de filtre pas de pied à terre ou assimilé. Cela induirait une non connexité du graphe, et c'est vraiment un problème casse-bonbons.

Par contre oui, il faut tenir compte de toute la masse roulante, et avoir un coef de roulement (même si c'est plutot un frottement statique) qui soit suffisamment élevé pour que ça ne soit pas avantageux.

Oh oui ! Je le rajoute dans ma todolist.

Replaçons nous dans le contexte initial du thread. Nous parlions de pente cassante, à 20%. Bien entendu une pente cassante, même à 20% ne fait pas 10 mètres, c'est pas suffisant.

Précisons de plus que nous parlions d'un comportement de randonnée, avec baguages (ou remorque dans mon cas). Il faut être clair, en rando si je compte la masse roulante, je dépasse les 160 kg dans mon cas. Alors dire que 100 kg dans le cas d'une rando avec baguages est une hypothèse pessimiste me semble un peu dur.

Autrement, à propos du braquet, vous faites ce que vous voulez, mais moi si je veux fournir de la puissance, à une cadence 35 tours/minute je me casse les jambes, je ne semble pas être le seul. Alors soit vous arrivez à fournir ce type de puissance à cette cadence, dans ce cas tant mieux pour vous, mais il semble que vous soyez une denrée rare, soit vous prenez un braquet plus sympathique.

J'avoue qu'avoir une notion de pied-à-terre pourrait être utile. Genre au dessus de telle pente, j'ai pas les braquets qu'il faut, je mets pieds à terre. Et donc tout d'un coup, je deviens énergetiquement moins efficace. Et en utilisant pour ça l'efficacité énergetique de la marche à pieds qui est plus faible que celle du vélo (en gros ça se modélise pareil sauf qu'on enlève la résistance de l'air et on augmente fortement la résistance de roulement).

Ouais enfin avec un braquet 30:28 en 700mm, si tu monte à 20% avec une cadence normale tu es dopé.

En 700mm avec un braquet 30:28 à 80 tours de pédale / minute, ça fait du 11km/h. Du 3.14 m/s, ce qui fait donc du .6 m/s en vitesse verticale. Donc la puissance necessaire est donc m g [.6 m/s]. Avec une masse de 100 kg (on a dit chargé) ça fait du 588 W. À rapprocher des valeurs obtenues au tour de France par Froome.

Moi avec un braquet 30:28, sans chargement je monte 12%, avec remorque 7% maximum.

Après du veux faire du 5km/h avec un braquet 30:28, tu dois avoir une cadence à 35 tours par minutes, moi à cette cadence là, mes jambes me brûlent.

Je ne déteste pas les côtes, et je m'en mange régulièrement. Je déteste les côtes inutiles. En vélo, j'aime découvrir des nouveaux endroits, et le plus possible par sortie. Plus je me mange de côtes, moins je fais de distance.

C'est vrai, mais la dangerosité n'est que très difficilement quantifiable.

Après personnellement, pour avoir fait du vélo dans de diverses circonstances, ce que je trouve le plus dangereux, c'est en ville quand on est pas synchrone avec le trafic. Pour moi le gros avantage du routage selon l'énergie n'est pas en ville où d'autre critère rentrent en compte comme les feux, l'accessibilité en vélo, etc.

C'est typiquement un exemple que j'ai rencontré, et pourquoi je veux intégrer cela. Tu as parfaitement compris mon souhait.

Je suis d'accord, mais c'est pas quantifiable en énergie la simplicité. Après si je prends en compte un ralentissement dans les virages en fonction du rayon de courbure, ça devrait aussi donner des trajets plus simple.

Merci de ce lien sur les tags osm. Ce que je comprends pas, c'est que moi, je n'utilise pas le tag footway. Cf ligne 42-48 de ce fichier. Auriez-vous les way-id correspondants, pour savoir si c'est à cause d'un mauvais tag sur ma version de la base ou autre chose ?

En l'occurence les formules de Cardan nous donnent une solution explicite sans itération. Donc oui c'est rapide.

En fait, moi ce que j'ai fait pour cette partie là, c'est que j'ai écrit mon modèle pour maxima (cf. calc_model.mc), puis à l'aide d'un script maison en perl, maxima m'exprime la solution que je veux, puis le script me convertit ça en code C++ (là il y a des truc moches en regex pour convertir la syntaxe) (cf. gen_calc_model.pl) et le résultat obtenu est calc_model.cc qui lui rentre dans la compilation.

Je fournis dans les sources calc_model.cc, mais ce n'est pas un fichier de sources, c'est du code généré (c'est un peu pareil lorsque le code C d'un parseur est fournit dans les sources alors que c'est du code généré par lex/yacc).

Il y aurait probablement moyen de faire plus simple, mais au niveau chronometrage cette étape est petite en temps devant les temps d'obtention des nœuds de la base de donnée (même quand elle n'est pas froide).

Le problème que je vois (je peux me tromper, je n'ai pas eu le temps de regarder en détails) c'est que c'est limité à l'Europe. Hors j'ai l'ambition de conquérir le monde proposer un service mondial à terme, où du moins un code qui peut facilement être déployé sans considération de localisation.

Par exemple, à titre perso, j'ai une instance backend+frontend qui couvre la Pennsylvannie (où je réside actuellement) et toute la zone autour du lac Ontario (où j'ai été faire de la rando à vélo cet été). J'utilise ce que je développe, c'est normal car je développe avant tout pour moi.

les données sont normalement disponibles gratuitement.

Oui, mais pas sous licence libre. Je ne souhaite pas rendre mon code spécifique à des données non disponible sous licence libre. Après si quelqu'un m'écrit des patch permettant d'utiliser ces données de manière alternative (tout en gardant un support pour une autre source de données librement accessible) alors je les accepterai. Mais je ne ferai pas cela moi-même.

Je serai probablement prêt à enfreindre ces principe de données libres si la mauvaise qualité des données libres avait une influence négative sur le résultat. Mais en l'espèce, même en utilisant des données plus précises, en particulier j'ai eu accès à des données régionales détaillés provenant de l'IGN, ce que ça apporte au moteur de routage est ridicule et ça ne change pas le résultat.

Donc au final je reste avec SRTM3 qui fournit des données de qualité suffisante pour l'instant. Après, c'est pas forcement définitif, en particulier si on me montre que à certains endroits on a une vrai différence, je changerai sûrement mon fusil d'épaule. Aussi dès que les améliorations prévus (prise en compte des virages…) seront faites, il est possible que je revienne dessus. Mais cela ne me semble pas une priorité pour l'instant.

Merci toutefois de cette info, j'ai lu avec plaisir la méthodologie utilisée, et même si je ne l'utilise pas (du moins pour l'instant), c'est toujours satisfaisant de lire des choses intéressantes.

À propos du crowdfunding, oui ça peut marcher, mais il faut trouver des devs quand même (mais des devs qui se font payer cette fois), monter un projet, faire un appel à financement… Tout cela m'exaspère. Après, si des gens me font une proposition payante de dev, et que je peux être confiant en ces personnes, pourquoi pas se lancer là dedans. Mais le plus dur me parait de trouver les devs.

À propos de la doc, en fait ces derniers temps je l'ai pas mal modifié, et avoir une deuxième langue avec la mention outdated est absurde, à ce niveau là, c'est même rien à voir. Après si en effet ça se stabilise, ça peut être faisable de garder deux versions même si une est plus à jour que l'autre.

Le problème c'est que pour l'instant je cherche un ou des contributeurs. Je ne cherche pas (encore) de financement. Les organisation vélocipèdique, bien qu'ayant tout mon respect, ne m'apporteront guère dans ce domaine je pense.

C'est pour ça que j'ai visé dlfp, je sais qu'il y a des dev, et j'utilise des données libres (OSM) et je developpe sous licence libre (BSD-2), donc ça me semblait approprié pour trouver des contributeurs. Après, quand il sera question d'heberger le service, là je pense que linuxfr ne sera pas là où je m'adresserai.

Pour la zone géographique j'utilise l'export de geofabrik. À priori, il est possible de coller plusieurs export ensemble (comprendre rajouter la suisse, la belgique et quelques autres détails, pour couvrir toute la francophonie européenne). Pour passer à l'europe entière, faudra un serveur avec de bons reins. Pour ça il faudrait avoir un frontend et ainsi proposer un vrai service au public.

Quand à l'interface d'orsm, je suis désolé, mais le dev web me donne des boutons. En fait ça fait quasiment un an que j'ai fini cet interface là, et si j'en ai pas parlé c'est qu'il me restait 2-3 bugs à corriger et que ça me donne une furieuse envie de faire plein de choses, sauf de toucher au dev web.