jben a écrit 861 commentaires

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.

En plat en effet ce n'est pas très utile. Mais sur des longues distances on est rarement confronté qu'à du plat. Je compte intégrer le type de voie, mais toujours dans le cadre du modèle physique, en utilisant un Cr différent en fonction du revêtement. C'est quelque chose qui a un vrai sens par rapport au modèle.

Autrement si tu veux utiliser ce modèle (je pense que c'est le modèle physique dont tu parles, mais tu pourrais aussi bien être un prof d'algo et vouloir leur faire faire un A* avec un critère non standard) dans ton sujet, bien que je devrais tout d'abord savoir à quel niveau tu enseignes, j'attire ton attention sur le fait que l'équation différentielle obtenue n'est pas analytiquement intégrable (du moins, les gens autour de moi et moi ont échoués à l'intégrer, si jamais tu as une solution fait moi signe). À cause du terme de résistance à l'air elle est de cette forme

m dv/dt = - m g Cr - m g θ - ½ ρ S Cx v² + P/v

en ne considérant aucun vent additionnel et en faisant un developpement limité à l'ordre 1 pour avoir θ.

L'autre solution (et c'est ce que je fais), je fonctionne sous forme de bilan d'energie entre deux points (de nœuds en nœuds sur le graphe OSM).

ΔEc + ΔEp + Tr + Ta + Tf = 0

En notant dans l'ordre la différence d'energie cinétique, d'énergie potentielle de pesenteur, le travail de la resistance au roulement, de la résistance de l'air, de la force apporté par le cycliste. Seul ΔEp et Tr sont connus (ne dépendant que du terrain).

On obtient donc

½ m (v₂²-v₁²) + ΔEp + Tr +  ½ ρ S Cx [∫ v³ dt, t=t₁…t₂] + P(t₂-t₁)

Le but étant de trouver t₂ et v₂, et là… Une intégration numérique de la première équation est exclue (trop longue). En fait ce qui marche bien avec une erreur minime, c'est que je considère que l'accéleration est constante sur chaque segment. On a donc

v = v₁ + (v₂-v₁) × (t - t₁) / (t₂ - t₁)

En injectant cela dans l'équation précédente, on la simplifie en un polynôme de dégrée 3 en v₂ dont une seule des racine est intéressante, il ne reste que à utiliser Cardan.

Donc en gros, ça me parait pas forcement très adapté pour des lycéens (ou alors avec des hypothèses comme puissance du cycliste nulle (en descente) ou on néglige (et ce n'est pas réellement négligeable) les frottements de l'air). Par contre pour du supérieur, ça peut-être sympa.

En tout cas si toi (ou un de tes étudiants) a une idée lumineuse pour simplifier le tout, je suis preneur. Après je me contente de la solution actuelle, ça marche et l'erreur est acceptable.

Dans le second item de En bref, au niveau du lien [OSI], il y a un parsage markdown qui foire. Si un modo pouvait corriger cela, ça serait cool.

À propos de Géovélo, c'est pas mal, mais c'est pas exactement le même but. À dire vrai, rv n'est pas très adapté à un usage urbain (il ne fait pas la différence entre les types routes), mais plus à un usage longue distance/randonnée. Sur une courte distance il y a rarement beaucoup de chemins pour aller d'un point A à un point B, sur une longue distance plus, et il y a mieux matière à optimiser.

Petite taquinerie : rv me fait passer à contre-sens sur un voie que j'ai récemment taguée en sens unique.

Mea culpa, ça fait longtemps que la mise à jour des tables n'a pas été faite. C'était dans un cron, mais je l'avais désactivé pour faire autre chose. Vu la charge actuelle du serveur (avec les dflpiens) c'est pas le bon moment pour le faire.