Journal rv/hervé : recherche d’itinéraire vélo minimisant l'énergie en utilisant les données d'OSM

72
25
oct.
2014

Sommaire

Introduction

Il y a quelques temps, plus d'un an déjà, j'ai écrit un journal ici-même présentant un projet sur lequel je passais une partie de mon temps libre. Les choses ayant légèrement évolué depuis, je récidive. Bien que la lecture du précédent journal soit utile, elle n'est pas obligatoire pour comprendre celui-ci, sauf pour des points de détails, j'y ferai référence en temps voulu.

Étant adepte du vélocipède en tant que moyen de transport, et comme tous les amateurs de cet activité merveilleuse, je suis régulièrement confronté à un problème de choix d'itinéraire. N'ayant qu'un amour modéré pour les côtes, et une haine, qui n'a d'égal que ma haine du café américain, pour les dépenses inutiles, comme par exemple monter pour redescendre alors qu'un détour minime permet d'éviter cette aberration, un choix de l'itinéraire basé uniquement sur la distance me paraît une absurdité comparable à celle d’apprécier la poutine.

Il y a donc quelques années, mon Dieu que le temps passe vite, je me suis donc mis en tête de créer mon propre moteur de recherche d'itinéraire adapté à mes contraintes. Il est bien connu qu'on n'est servi de manière satisfaisante que par soi-même. En fait j'ai donc commencé à explorer, jouer avec les données, écrire du code, pour enfin obtenir un moteur de routage fonctionnel il y a environ un an et demi. Ce fut l'objet de mon précédent journal, et les choses ont peu évolué au niveau de ce moteur, principalement de la correction de bugs, un peu de réorganisation, et quelques nouvelles fonctionnalités. Rien de bien important. Puis n'ayant pas réussi à recruter de développeur de frontend, j'ai écrit une interface minimaliste et moche, pour montrer les possibilités du moteur.

Je vais donc présenter, ici, de manière détaillée, mon moteur de routage, l'interface minimaliste et moche, et surtout lancer un appel à développeurs pour une interface non minimaliste et potentiellement non moche. Puis je vous présenterai les futures améliorations que je prévois d'apporter au moteur de routage, dans un avenir proche à lointain.

rv, le moteur de routage

Le moteur de routage se nomme rv. La seule raison profonde à ce nommage est mon incapacité à trouver des noms intéressants à mes projets. J'ai donc commencé par nommer mon dossier où je codais routage_velo, mais comme c'était trop long, je l'ai par la suite raccourci en rv. Le code du moteur de routage est disponible sur mon répo git. Si vous n'êtes intéressé que par l'utilisation du moteur de routage ou que par l’interfaçage, je vous conseille de sauter cette partie.

Données

Présentation des données

Pour faire du routage, il me faut des données. Ainsi j'utilise deux types de données. Le premier est constitué de données cartographiques, instrument indispensable à du routage sur une carte. Je ne vous ferai pas l'affront de vous présenter de manière détaillée, en particulier parce que j'en suis incapable, le projet OpenStreetMap, dont l'objectif principal est de fournir une cartographie mondiale sous licence libre ODbL.

Le second type de données est constitué des données altimétriques, puisque pour faire un routage en fonction de l'altitude, il me faut des données cartographiques avec des étiquettes altimétriques sur les points, informations que OpenStreetMap ne fournit pas. Pour ce faire j'utilise les données du projet SRTM de la NASA qui fournit pour l'ensemble du globe entre 60° et -60° de latitude des données altimétriques avec une précision au mètre suivant une grille de 3 secondes d'angle.

Travail sur les données

J'importe les données dans une base de donnée PostgreSQL avec les extensions PostGIS. Pour l'import des données cartographiques, j'utilise l'outil Osmosis, bien connu des utilisateurs d'OSM, et le schéma de base utilisé est pgsnapshot, tel que définit par Osmosis.

Seules les données concernant des routes utilisables par les vélocipèdistes sont recopiées dans des tables personnelles, les tables du schéma pgsnapshot étant laissées intactes. En particulier, cela signifie que le moteur de routage peut cohabiter sur une même base de données utilisant le schéma pgsnapshot.

J'importe également les données SRTM dans la base de données via un programme perso (fournit dans mon répo git). Certaines données sont manquantes (c'est assez rare), pour compléter les points manquants de la grille, j'utilise un algorithme des plus proches voisins une fois que ma grille est complète, je calcule l'altitude des nœuds fournit par OpenStreetMap via une interpolation bilinéaire. Cette étape est entièrement réalisée à l'aide de procédures postgres (plpgsql et plperl).

La difficulté suivante sur les données se situe au niveau de la connexité. En effet, le graphe routier est constitué de plusieurs composantes connexes. Si certaines sont légitimes (comme celles représentant des îles non reliées au continent), certaines ne le sont pas (un parking que l'on a oublié de relier au monde extérieur). Il se trouve que si un utilisateur demande un routage entre deux composante connexe, celui-ci ne peut aboutir, et conduit l'algorithme, si il ne le sait pas, à explorer tout le graphe, ce qui est énorme et inutile. Ainsi les composantes connexes sont calculés et les nœuds sont étiquetés en fonction de leur composante connexe d'appartenance. Ainsi quand un utilisateur demande un routage entre deux points géographique, l'algorithme peut essayer de choisir les nœuds de départ et d'arrivée de telle sorte qu'ils soient sur la même composante connexe (dans l'exemple du parking, on projettera sur la route adjacente) si possible, et échouer avec un message d'erreur immédiatement si ça ne l'est pas (dans le cas d'un routage entre une île isolée et le continent par exemple). Ce calcul est entièrement effectué à l'aide d'une procédure postgres en plpgsql lors de l'import ou de la mise à jour des tables utilisées par le moteur de routage.

Routage

L'idée du routage est de minimiser un critère. Pour ce faire trois critères sont proposés :

  • Distance parcouru par le vélocipède

  • Dénivelé positif cumulé sur le trajet

  • Énergie dépensée par le vélocipédiste.

Si vous avez bien suivi mon raisonnement et mon objectif, vous comprendrez que seul le troisième critère m'intéresse, le premier étant l'équivalent d'un routage bête et méchant, ne prenant pas en compte l'altitude, et le second correspondant à une recherche à tout prix d'évitement des côtes, même si cela implique un détour complètement absurde. Seul l'énergie dépensée par le cycliste prends en compte l'altitude et la distance parcourue, c'est un vrai compromis. Nous le savons tous, la solution se situe toujours dans le compromis, sauf vis-à-vis de la sanction appropriée concernant les amateurs de poutine.

Toutefois j'ai implémenté dans mon routeur de routage les trois critères, principalement car cela permet de comparer le critère que je propose aux critères simplistes communément acceptés, et aussi car cela se faisait à moindre coût dans l'architecture du code. Dans la suite, je ne vais toutefois détailler que le modèle lié à l'énergie, le calcul de la distance ou du dénivelé positif ne nécessitant pas d'explications.

Modèle physique pour le calcul de l'énergie

Pour calculer l'énergie dépensée sur un trajet, j'ai utilisé un modèle physique, et j'ai utilisé les loi de la mécanique (du point). Il y a certaines hypothèses qu'il est nécessaire d'expliquer. Pour une vision en détail du modèle je vous conseille la lecture de mon précédent journal. Les hypothèses principales sont les suivantes.

  • L'animal fournit une puissance constante. Je considère que le cycliste sait se servir de ses vitesses, et les utilise de manière à fournir une puissance constante, que ça soit en côte ou en descente.

  • L'ensemble du cavalier et de sa monture est soumis à la pesanteur. C'est très important, c'est ce qui va faire varier l'énergie totale en fonction du relief.

  • Le cycle, et l'imbécile flanqué dessus, sont soumis à une résistance de l'air. La résistance est proportionnelle au carré de la vitesse relative par rapport à l'air. Vous pouvez trouver des infos sympa sur ce type de résistance ici.

  • Le vélocipède est soumis à une résistance au roulement. Cela provient de la déformation des pneus sur le sol. Cela dépend du type de sol, du type de pneu. Toutes choses égales par ailleurs, cette résistance est considérée comme proportionnelle au poids (je parle bien du poids de l'ensemble et non de la masse).

  • Il n'y a aucune perte d'énergie dans les virages. Cette hypothèse est fausse dans le cas où le cycliste est obligé de freiner à cause du rayon de courbure trop faible du virage par rapport à sa vitesse. Toutefois, c'est une hypothèse très utile pour le calcul.

  • Il n'y a aucun arrêt. Ce qu'il faut comprendre c'est que le cycliste ne s'arrête ni au feu, ni au stop.

Certaines hypothèses peuvent paraître osées, c'est vrai, mais il faut dire qu'elles n'ont que peu d'influence sur le résultat final.

Pour valider les hypothèses de résistance de l'air et résistance au roulement, j'ai fait des essais en descente avec un traceur GPS sur ma bicyclette sans fournir de puissance, et je peux affirmer avec confiance que ces hypothèses sont justifiées.

Le modèle a donc plusieurs paramètres qui sont :

  • La masse roulante (bicyclette, animal, fret), elle influe sur l'inertie de l'ensemble en mouvement, sur le poids, et sur la résistance au roulement.

  • La vitesse sur le plat (qui, connaissant les autres paramètres sert à calculer la puissance constante à considérer)

  • La surface apparente et le coefficient de pénétration dans l'air (S.Cx) qui permet de calculer la résistance de l'air. Ce paramètre dépend principalement de la position du sportif sur son instrument de torture, mais peut aussi dépendre d'éléments extérieurs comme les sacoches ou un carénage tel qu'on voit dans les contre-la-montre.

  • Le coefficient de roulement. Il permet de calculer la résistance au roulement. Ce paramètre dépend principalement du type de pneu utilisé et du gonflage. Il est aussi influencé par le type de sol, mais il est supposé constant sur tout le trajet.

  • Le vent additionnel (vitesse et direction). À la discrétion de l'utilisateur pour prendre en compte un vent permanent et orienté dans le calcul du routage. Son influence est forte sur la valeur de l’énergie, mais faible sur le choix de l'itinéraire.

Algorithme de routage

Pour effectuer le routage dans un graphe, la première chose à quoi nous pensons est l'algorithme de Dijkstra. Toutefois cet algorithme est clairement lent, et je lui ai donc préféré l'algorithme A*, outre le fait d'être plus rapide, et d'être plus facile à orthographier, sous certaines conditions, l'algorithme A* est optimal de la même manière que l'algorithme de Dijkstra l'est.

Pour résumer, l'algorithme A* et l'algorithme de Dijkstra consistent à explorer les voisins des nœuds connus en partant du nœud de départ. La différence c'est que l'algorithme A* va utiliser une heuristique qui estime le critère entre le nœud courant et le nœud d'arrivée pour choisir l'ordre d'exploration, et s'arrêter quand il aura exploré le nœud d'arrivé. Dans le cas général l'algorithme A* ne donne pas le résultat optimal. Toutefois si l'heuristique utilisée est admissible, c'est à dire si elle est une borne inférieur du critère, alors l'algorithme A* est optimal. Attention toutefois à avoir une heuristique informative, par exemple, prendre comme heuristique une fonction qui nous retourne 0, nous donne une heuristique admissible, mais dans ce cas cela revient à utiliser un algorithme de Dijkstra (à tous les niveaux dont au niveau temps).

Dans mon cas, on peut pour chacun des critères avoir une heuristique admissible (et informative). Dans le cas de la distance, la distance à vol d'oiseau à l'arrivée est une minoration de la distance sur le graphe. Dans le cas du dénivelé positif cumulé, la partie positive de la différence d'altitude à l'arrivée est une minoration du critère (mais guère informative dans nombre de cas il faut l'avouer). Dans le cas de l’énergie, l’énergie dépensée sur un trajet en ligne droite à pente constante à l'arrivée sans prendre en compte la résistance de l'air (qui dépend de la vitesse que l'ont ne peut pas minorer, excepté par 0), est une minoration du critère.

Au final, j'ai donc un algorithme, pas trop lent, et exact, pour choisir un itinéraire.

Programme

Le programme de routage est écrit en C++. Il fonctionne bien sous GNU/Linux. Il n'a pas été testé sur d'autres plate-formes.

Pour lancer le routage, il faut écrire dans la base de donnée les paramètres, les points de départ, d'arrivé et les points de passage. Un job id est attribué par la base. Il faut ensuite lancer l'exécutable avec comme argument la chaîne de connexion à la base et le job id. Le programme lit les paramètres, lance l'algorithme de routage, écrit au fur et à mesure dans la base une estimation de l'avancement (ce n'est qu'une estimation, il n'est pas possible de prévoir le nombre de nœuds à parcourir à l'avance) et quand il a terminé écrit dans la base le résultat et termine.

Dans les versions précédentes, il prenait ses arguments sur l'entrée standard et retournait avancement et résultat sur sa sortie standard, ceci a été modifié afin de permettre facilement un interfaçage à l'aide de scripts python.

Interface web

C'est là où les choses se gâtent. J'ai été pendant quelques temps satisfait de mon programme de routage, qui s'utilisait en ligne de commande. Même si guère pratique, ceci était suffisant pour mon usage, il apparaissait de manière assez évidente que ceci n'était pas satisfaisant pour l'usage général des utilisateurs de bicyclette.

Non que j'accuse les vélocipèdistes d'être bêtes, même personnellement si j'affectionne les programmes en ligne de commande, il faut avouer que pour un usage cartographique, la ligne de commande ne semble pas ce qu'il y a de plus approprié.

J'ai donc envisagé de greffer une interface au moteur de routage rv. Le fait que le moteur de routage demande d'avoir de manière accessible une base de données, implique qu'il est difficile de faire une interface sur un poste client pour un usage autonome, à moins d'installer en même temps la base de données et d'importer toutes les données nécessaires au routage. Il semble donc immédiat qu'une interface web est la solution adaptée, même si à titre personnel je ne suis pas satisfait du fait que de plus en plus d'outils se déplacent vers le web, induisant ainsi une dépendance et une difficulté d'usage déconnecté, je dois reconnaître qu'en l'espèce cela semble approprié.

Dans mon précédent journal, j'ai lancé un appel à contribution, et même si j'ai eu des retours enthousiastes vis-à-vis du projet (qui m'ont fait très plaisir par ailleurs), je n'ai pas eu de volontaires pour le développement d'une interface web. La vie est triste.

Précisons que ce n'est pas forcement facile de développer une interface web sur un moteur qu'on n'a pas concu et quand on ne voit pas exactement le but recherché, je me suis donc attelé à développer moi-même une interface web, de démonstration, pour montrer les possibilités du moteur, et l'idée générale. L'interface web que j'ai développée est donc une interface de démonstration, elle n'a pas vocation à rester, elle sert juste à montrer ce que fait le moteur de routage, et permet un usage minimaliste d'icelui.

Comme d'habitude, je ne sais pas nommer mes projet, j'ai donc profité d'une similarité phonétique entre rv et le prénom hervé pour choisir le nom de mon interface, je l'ai donc nomée hervé. Vous avez le droit d'être affligés, je le suis aussi. Le nom étant trouvé, j'ai fait du développement web, cela faisait depuis 2005 que je n'avais pas fait de html et de javascript, je n'aimais pas cela, et cela n'a fait que ancrer mon opinion.

Je n'ai pas dit que le développement web est mal, c'est juste que ce n'est pas ce que j'ai envie de faire, et comme c'est un projet que je fais sur mon temps libre, vous comprendrez très bien que je me concentre sur ce que j'ai envie de faire au détriment de ce qui m’horripile. C'est donc de l'html et du javascript pour l'interface client, avec utilisation de leaflet pour jouer avec les cartes, et c'est du python au niveau du serveur.

L'interface de démonstration est accessible ici: Herve, limité au niveau de la France Métropolitaine. Cette interface est très moche, mais elle permet de montrer les fonctionnalités du moteur de routage. Cette instance est hébergée sur un serveur de test d'OpenStreetMap France, elle est volontairement limitée en ressource. C'est donc lent, et il y a un nombre de routage simultanés faible. De plus si vous avez la malchance d'accéder à l'interface alors que la base de données est froide, lent n'est plus le mot approprié, c'est pire. Cette interface refuse également de calculer des trajets d'une distance supérieure à 100 km à vol d'oiseau.

Je vous invite à tester quelques trajets, et à vous amuser un peu. Pour une petite démonstration, sur la ville de Poitiers, dont le centre-ville est sur une colline, pour aller du bas de la colline au bas de la colline à l'opposé de la ville, voici deux résultats, montrant l'importance de la prise en compte de l'altitude dans le choix de l'itinéraire :

On remarquera que Google Maps par exemple nous donne à peu près le même résultat que l'optimisation de la distance. Pour avoir vécu quelques années à Poitiers, le trajet que je préfère, et de loin, est celui résultant de l'optimisation de l'énergie.

Documentation et code

Tout le code du moteur, les scripts pour récupérer les données, et l'interface web est disponible sur mon répo git.

Le répo git contient aussi la documentation (en français) sur comment se servir du tout. J'ai essayé de la faire aussi détaillée que possible, mais je doute que j'y sois complètement parvenu.

Avenir et appel à contribution

J'ai plusieurs rêves, et plusieurs envies.

Interface web et API web

J'aimerai en faire un service accessible à tout un chacun, via une interface web. Pour cela il me faudrait un ou des volontaires pour développer une vraie interface au moteur de routage, je serais bien entendu là, prêt à adapter le moteur au besoin, et à fournir toutes les explications nécessaires.

Il est aussi envisageable de développer une API pour par exemple une utilisation via une appli de smartphone. Je n'utilise pas de smartphone, ça ne m'intéresse pas, je n'y connais rien, mais si quelqu'un est intéressé, je ne suis pas contre, même si l'interface web me paraît prioritaire.

Il faudra aussi probablement voir du côté d'où héberger l'infrastructure. Jusqu'à maintenant l'infrastructure de test a été fournie par OpenStreetMap France, il est possible qu'ils soient volontaires pour fournir l'infrastructure.

Moteur

J'ai aussi plusieurs projets pour le moteur de routage

  • Abolir la règle puissance constante à vitesse élevée. C'est à dire permettre que l'utilisateur fournisse une information comme à partir de cette vitesse j'arrête de pédaler, et à partir de cette vitesse je freine. (Pour un souci de cohérence la seconde devra être supérieure à la première.)

  • Ajouter une notion d'accélération latérale maximum, ce qui implique de limiter la vitesse de passage dans un virage en fonction de son rayon de courbure. J'avais échoué par le passé à avoir quelque chose qui ne faisait pas n'importe quoi, mais j'ai réussi à tester une méthode d'approche du rayon de courbure qui donnait des résultats cohérents avec mes traces GPS (dès que je veux modifier mon modèle, j’essaie de le valider par un essai réel avec trace GPS)

  • Tenir compte du type de sol, et faire bouger le coefficient de roulement en fonction des tags OSM

Documentation

J'aimerais internationaliser le projet. Même si je n'ai pas de mal à écrire en anglais, j'ai rédigé la documentation en français (car j'ai plus de plaisir à écrire en français). Toutefois c'est une erreur, et je pense traduire la documentation en anglais. Bien entendu si quelqu'un veut la traduire, je profiterai du temps libéré pour faire autre chose, et j'accepterai donc avec plaisir cette contribution.

Une fois que la documentation sera traduite, je pense supprimer la version française, déjà que c'est dur de garder la documentation à jour, si elle est présente dans les deux langues, c'est un coup à échouer.

En bref

  • J'ai développé un moteur de routage basé sur l'énergie pour les vélocipèdistes utilisant les données d'OSM et SRTM, et j'ai encore des projets d'amélioration du moteur de routage.

  • Je propose une interface de démonstration, et je recherche des gens pour développer une vraie interface web. Au niveau licence, je demande juste une licence approuvée par l'OSI (si quelqu'un veut développer sous une licence propriétaire, je n'ai rien à redire, mais il ne recevra pas mon aide).

  • Le code et la documentation sont disponible sur un répo git. Tout est disponible sous licence BSD-2.

  • L'infrastructure jusqu'à maintenant à été fournie par OpenStreetMap France que je remercie vivement. Si vous avez envie de financièrement soutenir ce projet, c'est à OpenStreetMap France qu'il faut donner, c'est par ici.

  • Pour me contacter, vous pouvez répondre à ce journal, m'envoyer un courrier électronique (vous trouvez mon adresse dans les commits du répo git), ou encore venir me voir sur irc, je fréquente le salon #osm-fr sur oftc.

  • # Quelques remarques

    Posté par (page perso) . Évalué à 8.

    Je suis vraiment content d'avoir des nouvelles de ce projet qui m'avait enthousiasmé l'année dernière (déjà ?).

    Soit dit en passant, « dépôt » est la traduction française de repository, alors pourquoi « répo » ?

    En regardant la démonstration d'hervé, je ne pense pas que les paramètres « masse roulantes » et « vitesse sur plat » soient des données intéressantes.
    D'un point de vu utilisateur, je souhaite aller de A à B, et je peux choisir de minimiser la distance, l'énergie ou le temps.
    Quand au processus physique, je pense que la minimisation est ici indépendante de la masse a priori (sauf si l'objet devient trop petit, et que la viscosité s'en mêle). Elle semble donc inutile.
    La vitesse sur plat pourrait être une valeur par défaut, et changeable uniquement dans un onglet avancé.

    Enfin, en cliquant sur le trajet, ça pourrait être sympa d'avoir un profile du parcours (altitude en fonction de la distance).

    Je voudrais bien t'aider, mais je n'y connais rien en développement web, alors bon…

    • [^] # Re: Quelques remarques

      Posté par . Évalué à 5.

      Merci de ton retour.

      pourquoi « répo »

      Tu as raison. C'est la seule réponse que j'ai, et je ne peux qu'accuser que ma personne.

      Quand au processus physique, je pense que la minimisation est ici indépendante de la masse a priori (sauf si l'objet devient trop petit, et que la viscosité s'en mêle). Elle semble donc inutile.

      Oh que si, c'est même elle qui fait beaucoup varier le résultat. Pour simplifier, il y a deux forces majeures, la résistance de l'air (qui va donc pas vouloir faire des trajets trop long) dont la force ne dépend pas de la masse, et le poids, qui en dépend. C'est avec la masse que l'on a le meilleur ajustement du compromis distance/pente.

      Concernant la vitesse sur le plat, l'indiquer c'est ce qui permet d'avoir une estimation temps au final correcte, et elle influe sur le résultat. Quand je mets une vitesse sur le plat plus faible (donc une puissance plus faible), la résistance de l'air va devenir moins importante (force en v²) et son travail sur le trajet plus faible, et donc on va permettre de faire plus de détour pour éviter une côte. Au contraire, quand la puissance est très forte, ce qui devient déterminant c'est la résistance à l'air et on va se rapprocher d'une minimisation de distance.

      Pour moi c'est les deux paramètres les plus importants (et les plus compréhensible pour l'utilisateur). Le choix du critère n'est pas important selon moi, les autres n'étant fourni que pour le fun.

      Après tes remarques, même si elles sont pertinentes, sont des remarques concernant l'interface, comment présenter les paramètres, afficher le profil altimétrique (le backend fournit les données), et je suis d'accord qu'il y a du boulot à faire, mais cela sort de mon domaine de compétences.

      • [^] # Re: Quelques remarques

        Posté par . Évalué à 7.

        Bon j'ai eu le temps de trouver un exemple :

        • [^] # Re: Quelques remarques

          Posté par . Évalué à 5.

          masse 150 km, vitesse 20 km/h

          Une masse de 150 km ? Je suppose que c'est pour un vélo mesurant 2 A ?

          Blague à part, très beau projet.

        • [^] # Re: Quelques remarques

          Posté par . Évalué à 3.

          Il y aurait moyen d'avoir le droit d'ajouter un facteur correctif pour le calcul du temps ? J'ai une vitesse en ligne droite pas loin de 30km/h, mais un trajet ponctué de stops/feux qui font que je parcoure plutôt 20km en 1 heure sur du plat. Du coup si ton projet pouvait faire la règle de 3 pour moi, après avoir fait les calculs avec la première…

          "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

  • # On gagne combien ?

    Posté par (page perso) . Évalué à 3.

    Joli projet.

    Par contre dans la vraie vie ça permet de faire moins d'efforts dans plus de 1% des cas ?
    À vue de nez il ne doit pas être bien courant de pouvoir contourner une colline tout en économisant de l'énergie. Les sites qui me viennent en tête sont soit naturellement plus économiques sans passer sur la bosse (donc le trajet sur le plat est déjà le plus court), soit naturellement plus économique en passant sur la bosse (car le contournement est bien plus long, donc le trajet le plus court est de nouveau le meilleur).

    • [^] # Re: On gagne combien ?

      Posté par . Évalué à 10.

      En fait, c'est pas fait pour les zones que tu connais bien. Dans les zones que tu connais bien tu es souvent à même, toi-même, de choisir le trajet le plus adapté. Mais pour les autres trajets ça peut être vraiment utile.

      Dans la ville où je suis actuellement en Amérique du Nord, cela ne sert pratiquement à rien, quelque soit la direction tu vas te manger des côtes et des descentes, et le trajet direct est donc souvent préférable. Dans certains cas, il trouve quand même quelques astuces, qui permettent d'éviter une côte (sur les 4 que compte le trajet de 3km).

      Par contre je l'ai pas mal utilisé quand je faisais de la rando en Normandie, région que je ne connais pas. Et vu le relief, et les routes, il me trouvait souvent un trajet qui avait l'air farfelu sur une carte, mais qui était très pertinent quand on voyait le relief en vrai. Je l'ai aussi pas mal utilisé en Aquitaine, pour faire des distances moyennes (de l'ordre 50km) et là aussi, les résultats qu'il me donnait étaient intéressants.

      Il y a aussi l'exemple extrême de Poitiers que j'ai donné dans le journal qui permet de bien se rendre compte.

      Donc en fait tu gagnes dans largement plus qu'1% des cas, mais tu gagnes rarement sur des terrains que tu connais par rapport à ce que tu ferai en utilisant ta connaissance, mais ce n'est pas dans ces terrains-là que tu as besoin d'un planificateur d'itinéraire.

      • [^] # Re: On gagne combien ?

        Posté par . Évalué à 2.

        Même sur un trajet que l'on connais bien c'est toujours intéressant de vérifier si les chiffres correspondent au ressenti.
        J'ai essayé sur un trajet ou je fait un bon détour pour éviter une cote sans vraiment savoir si c’était "rentable"
        Et bien maintenant je sais, la réponse est "oui c'est rentable" ;)

    • [^] # Re: On gagne combien ?

      Posté par . Évalué à 2.

      Par contre dans la vraie vie ça permet de faire moins d'efforts dans plus de 1% des cas ?

      Sur les petits trajets, ça me parait peu probable. Par contre, sur les grandes randos, ça doit être significatif, parce que les détours sont beaucoup moins couteux…

      • [^] # Re: On gagne combien ?

        Posté par . Évalué à 2.

        Je fais pas mal de vélo et je suis curieux de voir ce que ça donne. J'ai testé le programme sur des parcours que je connais entre 20 et 150 bornes mais je ne trouve rien de génial. Quelques bosses évitées mais sans plus, le reste est toujuors trop long en détour par rapport à l'effort économisé. Tu es tombé sur des exemples parlants que tu peux indiquer stp ?

        Je précise que je suis en Bretagne et que je fais du vélo pour le plaisir d'en faire donc j'ai plutôt tendance à faire des détours pour rencontrer les difficultés, mais je suis toujours preneur d'infos sympas.

        • [^] # Re: On gagne combien ?

          Posté par . Évalué à 2.

          Non non, je n'ai pas essayé, je répondais juste au post précédent!

          De manière générale, j'imagine (peut-être naivement) que l'algorithme revient à peu près au même que de minimiser le temps. Mais je suis tout à fait d'accord pour dire qu'en vélo, surtout en rando, les bosses ne sont pas forcément le plus désagréable!

  • # Géovélo

    Posté par . Évalué à 2.

    As-tu tenté le comparatif avec Géovélo (présent uniquement dans quelques villes) ? Ils ont adopté une stratégie un peu différente : l'algo essaie de faire passer sur des voies vélo-friendly (piste cyclable, couloirs de bus,…). Je ne le retrouve pas mais il y avait un curseur pour choisir entre rapidité et sécurité.

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

    • [^] # Re: Géovélo

      Posté par . Évalué à 4.

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

      • [^] # Re: Géovélo

        Posté par (page perso) . Évalué à 6.

        Nonobstant la finalité, en réaction à Géovélo, propriétaire, poussé par une société qui n’est pas très ouverte à la collaboration, l’ADAV (association Droit au vélo, Région Nord-Pas de Calais) a créé un outil libre de notation de la cyclabilité.

        Ça se teste ici : http://cyclabilite.droitauvelo.org
        Forge ici : https://redmine.champs-libres.coop/projects/cyclabilite

        Il a été développé par la coopérative Champs libres (http://www.champs-libres.coop) et un modèle économique est recherché entre la coop et l’ADAV pour généraliser l’outil au moins à l’espace francophone européen (mais l’infini et au delà serait également très bien)

        L’étape d’après la notation, c’était le calcul d’itinéraire et rv avait été évoqué comme piste.

        Il existe une liste regroupant des personnes intéressées par le sujet et membres d’associations de promotion du vélo et qui a un peu de vie. On peut la rejoindre via cartovelo-subscribe arobase droitauvelo.org

        Il y a également le canal #cartovelo sur evolu.net mais c’est beaucoup moins vivant

        Champs Libres fait parti de Libre Entreprise, http://www.libre-entreprise.org/

    • [^] # Re: Géovélo

      Posté par . Évalué à 4.

      Il n'y rien de pire que ce genre de trucs censés te faire passer par des itinairaires vélo friendly. Des détours à n'en plus finir, des voies pourries à partager avec des gamins en trottinette (ceux qui décident toujours de faire demi-tour pile au moment où l'on s'apprete à les doubler) et des chiens…

      • [^] # Re: Géovélo

        Posté par . Évalué à 1.

        A l'opposé, les itinéraires typés automobile qui te font passer par des voies rapides (interdites aux cyclistes) ne sont pas du tout pertinent non plus.

      • [^] # Re: Géovélo

        Posté par . Évalué à 1.

        Du coup le problème c'est pas trop l'algo, c'est l'extension limitée et ridicule du domaine cyclable …

      • [^] # Re: Géovélo

        Posté par (page perso) . Évalué à 1.

        Tout à fait d'accord concernant Géovélo (exemple d'URL: http://geovelo.nantesmetropole.fr/).
        Ceci dit, je n'ai pas trop à me plaindre des autres usagers de la voie publique :) Ce qui m'ennuie davantage, c'est les détours proposés pour passer par des axes répertoriés comme cyclables, alors que le chemin direct est souvent plus confortable (route suffisamment large, moins d'effort au final).

        J'admets toutefois être un cycliste expérimenté et attentif, ce qui fait que je suis à l'aise en vélo sur des routes où d'autres hésitent à passer en voiture… Je comprends tout à fait que d'autres puissent être rassurés d'être au maximum sur les axes cyclables.
        À ce titre, le choix du mode de calcul, comme dans hervé, est chouette. L'idéal, un jour peut-être, serait de pouvoir proposer de :
        — minimiser l'effort,
        — minimiser le temps ou
        — minimiser les axes non cyclables.

        • [^] # Re: Géovélo

          Posté par . Évalué à 3.

          • minimiser l'effort,
          • minimiser le temps

          Actuellement c'est équivalent. Puisque le cycliste travaille à puissance constante, temps et énergie sont proportionnels. Par contre dans le futur, avec la notion de pied-à-terre en côte, d'arrêt de pédalage en descente, et freinage dans les virage, ça ne devrait plus l'être. Par contre je ne suis pas sûr que ces deux critères, sauf cas particuliers, soient suffisamment différent pour avoir un lieu de minimum différent.

          • minimiser les axes non cyclables

          C'est hors de question. C'est pas quantifiable en terme d'énergie ou de modèle physique, et l'essence même de mon moteur c'est d'avoir un modèle physique. Après ça peut être utile ce type de minimisation, mais c'est complétement orthogonal à mon projet, et ça ne m'interesse pas. Faisant du dev sur mon temps libre, je dev uniquement sur ce qui m'interesse (c'est assez égoïste, je sais).

  • # Erreur markdown

    Posté par . Évalué à 2.

    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.

  • # Financement participatif ?

    Posté par (page perso) . Évalué à 8.

    Voici un projet qui est super sympa, et je regrette de n'avoir aucune compétence en développement. En tout cas l'interface actuelle permet déjà de prévoir des trajets, même si c'est perfectible, c'est pas si mal.

    Si aucun bénévole charitable ne se propose pour améliorer ça, pourquoi ne pas tenter un crowdfunding pour financer le projet ? Ok, monter un crowdfunding demande du temps, de savoir comment réveiller une communauté etc, c'est pas forcément simple, mais je me dit que ce genre d'application ne peut qu'intéresser les vélocipédistes. Je me dit qu'il y a fort probablement moyen de trouver un écho sur un projet de ce genre.

    Pour la traduction de la doc en anglais : sur un autre projet, quelqu'un a passé le texte à traduire à la communauté duolingo (https://www.duolingo.com/). Un texte technique et pas simple en plus (les "wave lessons" lojban, de l'anglais vers le français), et ils ont fait un superbe boulot… Je ne sais pas trop comment ça fonctionne, mais ça peut être l'endroit où trouver des traducteurs.

    Je te déconseille fortement de supprimer la version française de la doc. Au pire, informe au début qu'elle est n'est plus d'actualité, que la version anglaise est mieux maintenue. Mais ça fait toujours un point de départ pour tous les gens pas doués avec l'anglais (mais qui peuvent avoir d'autres qualités utiles à ton projet). Tant qu'ils sont au courant que les infos à jour sont dans une version anglaise…

    • [^] # Re: Financement participatif ?

      Posté par . Évalué à 3.

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

  • # Associations de vélo

    Posté par . Évalué à 5.

    Hahum, hum, rheuutheutheuuu…

    Bonsoir.

    Voila, j'avais un gros chat dans la gorge. Je sais qu'ici c'est une plateforme du libre, d'échange, et tout et tout. Je trouve le projet vraiment super intéressant, vraiment. Je ne pense pas pouvoir t'aider pour bien des choses, pour l'instant. Et pourtant moi aussi je suis membre de la pédale cycliste. J'utilise beaucoup le vélo pour toutes sortes de déplacements et ton projet semble ta réalisation est vraiment pratique.

    Néanmoins, il serait aussi très bien de relayer l'information au sein des différentes organisations vélocipédique. Comme je suis Belge de Belgique Belgicaine, j'ai trouvé un lien sur un site de vélo belge (le gracq), qui donne un lien vers d'autres associations de vélo dans le monde. Peut-être trouveras-tu ton bonheur sur cette page.

    • [^] # Re: Associations de vélo

      Posté par . Évalué à 3.

      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.

      • [^] # Re: Associations de vélo

        Posté par (page perso) . Évalué à 4.

        Ha mais comme on peut trouver des cyclistes sur linuxfr… on peut trouver des devs parmi les assoc de cyclistes. Y'en a potentiellement moins qu'ici, mais ceux qui y sont seront plus que probablement intéressés.

        Faut pas se fermer des portes, lance ton appel aussi dans les communautés de cyclistes, et puis autour de toi, peut-être que par ce biais quelqu'un va en parler à la personne qui, elle, aura l'envie et les capacités de participer.

  • # Congratulations !

    Posté par (page perso) . Évalué à 2.

    Je réitère mes congratulations exprimées la fois précédente. J'avoue que je bave d'envie de voir ce projet embarquer officiellement sur un serveur d'osm-fr, par exemple. Enfin, peu importe le serveur tant que la région lémanique y est présente ; je ne peux actuellement pas faire de tests dans la région lausannoise.

    Donc bravo pour tout. Pour ce qui est du site web, il est peut être intéressant d'utiliser l'interface web d'osrm : http://map.project-osrm.org/

    • [^] # Re: Congratulations !

      Posté par . Évalué à 2.

      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.

  • # Beau travail.

    Posté par . Évalué à 2.

    Tu viens de me donner le sujet de devoir (je suis prof) que je cherchais…
    En dehors de cela félicitation. J'ai fait quelques tests de cet outil essentiel et pourtant préalablement inexistant:
    C'est parfait en montagne. En plat, de mon point de vue, un vision orienté "type de voie" est plus pertinente. Avec des pondérations et des outils libre on fait des merveille.

    • [^] # Re: Beau travail.

      Posté par . Évalué à 5.

      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.

      • [^] # Re: Beau travail.

        Posté par . Évalué à 1.

        Tout d'abord, chapeau pour l'idée et l'implémentation. J'ai deux petites questions:

        Est-ce qu'utiliser les formules de Cardan est vraiment ce qu'il y a de plus rapide pour trouver une solution approchée? J'imagine que numériquement (par exemple avec la méthode de Newton, je ne sais pas si on a fait beaucoup mieux depuis) x3 - a n'est pas plus simple qu'un autre polynôme de degré trois. De plus avec Cardan on est parfois obligé de passer par les complexes.

        Dans ton programme, tu considères que la puissance est constante (non nulle) même en descente? Est-ce que cela donne des itinéraires différents si tu imposes puissance nulle en descente (ou autre solution intermédiaire, par exemple on ne pédale que jusqu'à une certaine vitesse)?

        • [^] # Re: Beau travail.

          Posté par . Évalué à 3.

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

          • [^] # Re: Beau travail.

            Posté par . Évalué à 2.

            Les formules de Cardan sont formelles, et les fonctions qui sont utilisées pour obtenir une racine approchée de type double sont certainement itératives (au moins std::pow). Ce que je voulais dire, c'est que std::pow(qqch, 1.0/3.0) (plus les cos(atan(qqch))) n'est probablement pas plus rapide que la méthode de Newton pour une polynôme de degré 3 "quelconque". Mais en voyant ton code généré je me dis que cela a l'avantage d'utiliser des fonctions standard sans se casser la tête, et ton dernier paragraphe montre que ça ne vaut pas le coût d'y passer même une heure.

  • # SRTM

    Posté par . Évalué à 4.

    Un beau projet, très intéressant, chapeau !
    Pour les données SRTM, il existe des données raffinées, avec les trous bouchés, toute la méthodologie est détaillée ici, les données sont normalement disponibles gratuitement.

    • [^] # EU-DEM

      Posté par . Évalué à 2.

      Je conseillerais pour ma part le fond EU-DEM qui est un produit hybride du SRTM et d'ASTER.

      • [^] # Re: EU-DEM

        Posté par . Évalué à 4.

        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.

    • [^] # Re: SRTM

      Posté par . Évalué à 6.

      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.

  • # Cassantes

    Posté par . Évalué à 7. Dernière modification le 26/10/14 à 21:28.

    Merci pour ce projet !
    En tant que cycliste je ne trouve pas que les montées soient un problème linéaire. Les montées ne me dérangent pas tellement c'est surtout celles réellement cassantes, au delà d'un certain pourcentage sur un minimum de distance. Je viens de faire un test l'algo ne semble pas en tenir compte, il me propose un parcours avec une montée quasiment impossible à prendre à vélo.
    Comme je fais beaucoup de rando avec bagages c'est un critère essentiel, il ne faut pas avoir à descendre pour pousser le vélo.
    edit : je viens de voir (excellent !) que l'interface affiche le %, celui dont je parle est quand même à 20% !

    • [^] # Re: Cassantes

      Posté par . Évalué à -2.

      Il y a deux possibilités pour ton problème : soit tu ne sais pas pédaler, soit tu n'as pas un vélo adapté. Le problème du modèle c'est qu'il suppose que tu puisses toujours avoir un braquet adapté, ce qui est loin d'être vrai sur tous les vélos.

      "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

      • [^] # Re: Cassantes

        Posté par . Évalué à 3.

        Troisième possibilité, tu n'as aucune idée de ce qu'est une côte à 20% et un vélo chargé ;-) !
        Mais je suis sûr que jben pourrait calculer ça ainsi qu'intégrer la limite d'équilibre, dans l'exemple que j'ai trouvé il indique une vitesse de 1.7km/h, donc là moi, clairement je sais pas pédaler effectivement ou alors j'ai pas un vélo adapté il me faudrait un tricycle plutôt.

        • [^] # Re: Cassantes

          Posté par . Évalué à 1. Dernière modification le 27/10/14 à 15:41.

          dans l'exemple que j'ai trouvé il indique une vitesse de 1.7km/h

          Euh, sauf erreur de ma part, 1.7km/h sur une pente à 20%, ça fait 340m/h. Si tu passes à 1000m/h, ça te fait 5km/h, ce qui est amplement faisable même chargé avec un petit braquet genre 30*28 ou plus.

          Evidemment, je suppose que c'est une petite côte, si tu habites au pied du Zoncolan c'est un peu différent :-).

          • [^] # Re: Cassantes

            Posté par . Évalué à 2.

            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.

            • [^] # Re: Cassantes

              Posté par . Évalué à 2. Dernière modification le 28/10/14 à 12:13.

              Trouves moi une pente de 20% de moyenne continue sur plus de quelques mètres…Si tu prends l'exemple du Zoncolan cité plus haut, il a des passages à 22-23% max, mais sa moyenne n'est "que" de 11.5%. Pareil pour l'Angliru, malgré des passages à presque 24% à la corde de certains virages, il ne fait que 8 à 10.5% de moyenne suivant le versant.

              Sortir 588W sur quelques centaines de mètres n'est pas très difficile, un cycliste chevronné peut développer 1500W sur un sprint. On parle de 2200W pour François Pervis.

              Bref un pourcentage ne veut rien dire si on ne prend pas en compte la durée. Par ton avis péremptoire tu insinuerais que je suis dopé par exemple.

              • [^] # Re: Cassantes

                Posté par . Évalué à 1.

                Entièrement d'accord, les côtes qui ont une pente de 20% sur plus de quelques mètres ont un nom, ce n'est pas quelque chose sur lequel tu tombes au hasard en utilisant rv.

                Quant aux 588W, non seulement c'est tout à fait à la portée d'un amateur, mais en plus on obtient ce chiffre avec des hypothèses très pessimistes : 100kg, 12km/h, etc.

                • [^] # Re: Cassantes

                  Posté par (page perso) . Évalué à 3.

                  588W […] est tout à fait à la portée d'un amateur

                  Mais bien sûr, 3/4 de cheval de puissance à la portée d'un amateur.
                  L'unité « cheval » correspond à ce qu'est capable de fournir un cheval « moyen » du 18 ou 19ème siècle pendant une heure.

                  Pour des efforts d'une heure, les meilleurs athlètes de l'histoire (dopés, alimentés au quart de poil, entraînés, etc) développent maxi 6 watts par kilo de masse corporelle. Soit 450 watts pour un athlète de 75 kg.
                  On est entre 4 et 5 watts / kg pour un très bon non dopé (suivant la discipline), soit 340 watts.

                  La plupart des individus en bonne forme sont à 3 watts / kg, avec un effort jugé épuisant lorsqu'il est à 4 watts / kg. Donc en gros une personne de 75 kg qui développe 300 watts va rapidement devoir ralentir.

                  • [^] # Re: Cassantes

                    Posté par . Évalué à 3.

                    Tu as raté le passage où on t'explique que les pentes à 20% le sont rarement sur plus de quelques mètres…

                    Pour des efforts d'une heure, les meilleurs athlètes de l'histoire (dopés, alimentés au quart de poil, entraînés, etc) développent maxi 6 watts par kilo de masse corporelle. Soit 450 watts pour un athlète de 75 kg.
                    On est entre 4 et 5 watts / kg pour un très bon non dopé (suivant la discipline), soit 340 watts.

                    Non ils développent bien plus, moi aussi, toi aussi sûrement. La où ça se corse, c'est quand on doit les tenir plus de 10-15 minutes.

                    Tiens pour exemple pendant ma pause déjeuner j'ai fais une sortie aujourd'hui qui comprenait entre autre 3 petites côtes avec des passages entre 16 et 23% sur 30 à 50mètres (je laisse de côté un passage calculé à 30% qui est peut-être du à une erreur gps), d'après mes vitesse de passage Strava me donne des valeurs de puissance entre 800 et 1255W sur ces passages.

                    Pourtant même si je fais pas mal de vélo, je ne suis pas franchement en grande forme et en tout cas pas du tout grimpeur, et encore moins dopé à part au chocolat avec les poignées d'amours qui vont avec.

                    strava / 1240W

                    • [^] # Re: Cassantes

                      Posté par (page perso) . Évalué à 5.

                      Tu as raté le passage où on t'explique que les pentes à 20% le sont rarement sur plus de quelques mètres

                      J'ai bien vu ce passage.
                      Je réponds à la prétention que 588 watts est à la portée de beaucoup de gens : l'immense majorité de la population actuelle dans nos contrée est dans l'impossibilité de développer cette puissance pendant ne serait-ce que 10 secondes.

                      On parle d'efforts qui durent plus que quelques secondes :

                      Les montées ne me dérangent pas tellement c'est surtout celles réellement cassantes, au delà d'un certain pourcentage sur un minimum de distance.

                      Pour faire 1000 watts sur une pente à 20% il faut rouler à 21 km/h (poids total roulant de 80kg). Donc si la côte fait 50 mètres de long tu la passes en 9 secondes. Donc on s'en fiche pour cette discussion.
                      Avec un effort comme celui-là, tu es à 13 watts par kilo, c'est totalement intenable même sur seulement une minute.

                      • [^] # Re: Cassantes

                        Posté par (page perso) . Évalué à 3.

                        tout dépend de quelle filière tu mets en jeu… anaérobie, aérobie etc.

                        Quelques minutes impossible… quelques secondes, jouables.

                        Quand on saute, on développe une belle puissance aussi. Sur un laps de temps très court.

                    • [^] # Re: Cassantes

                      Posté par . Évalué à 3.

                      Je connais bien le cyclisme et je peux te dire que plus de 1000 watts c'est impossible sur un vélo: en pesant 75 kg il faudrait faire 2 tours de manivelle par seconde avec la totalité du poids du cycliste à chaque fois, équivalent à soulever son corps de 1m30 chaque seconde.
                      C'est donc impossible avec un vélo et probablement impossible tout court.

                      En vélo on ne peut que difficilement dépasser 500 watts en étant frais et sur une durée inférieure à la minute. Pour ça il faut avoir de vraies bonnes jambes donc l'histoire de presque 600 watts accessible facilement ça décrédibilise totalement les propos.

                      • [^] # Re: Cassantes

                        Posté par . Évalué à -1.

                        Je connais bien le cyclisme et je peux te dire que plus de 1000 watts c'est impossible sur un vélo: en pesant 75 kg il faudrait faire 2 tours de manivelle par seconde avec la totalité du poids du cycliste à chaque fois, équivalent à soulever son corps de 1m30 chaque seconde.

                        Non, tu ne connais pas le cyclisme :
                        1) Ce type de puissance est tout à fait avéré : par exemple http://www.goldencheetah.org/critical-power-plot.png trouvé au hasard sur le net (qui appartient probablement à un cycliste sur piste vu la tête de la courbe).
                        2) En sprint, ou en échappée, ou de façon générale quand tu emmènes un gros braquet tu tire sur le cintre, ce qui te permet d'exercer une force importante. En plus, avec les pédales auto, tu tires aussi la pédale opposée vers le haut.

                        • [^] # Re: Cassantes

                          Posté par . Évalué à 3.

                          Sean Rhea est le fondateur du site goldencheetah. Son site est utilisé par pas mal de monde. La trace que tu montres n'a strictement rien à voir avec de la piste: le trajet fait plus de 3 heures, il faut rester sérieux 5 minutes!

                          Le graphique vient d'une vieille version et il montre le CP = Critical Power: les puissances maximales de son trajet du 6 mai 2008 et les meilleures puissances maximales sélectionnées sur la totalité de ses trajets.

                          Son trajet du 6 mai a un maxi à 800 watts et le maxi enregistré sur son meilleur a un maxi à plus de 1400 watts. Ces valeurs viennent simplement du moment du fait qu'elles sont calculées et non mesurées. Par exemple en bas d'une pente raide avec l'élan dont le calcul ne tient pas compte. Sur les versions récente il doit être dans les 1000 watts car il a maintenant de quoi mesurer correctement.

                          François Pervis, un des meilleurs français avant son accident, faisait 1300 watts sur 10 secondes. Donc je persiste: faire 1000 watts un peu soutenu c'est impossible.
                          Je crois que le record des records est vers 2000 watts par Förstemann: http://fitnessrevolutionrowlett.com/wp-content/uploads/2013/08/Robert-Forstemann.jpg
                          En voyant ses cuisses tu vois qu'il y a comme un soucis. Il est dopé, il a de plus une probable mutation génétique, et ça ne fonctionne que sur cycloergomètre car sur un vrai vélo il est bien en dessous. Au squat il fait 2600 watts selon lui, je n'y connais pas assez en squat donc je ne commente pas.

                          • [^] # Re: Cassantes

                            Posté par . Évalué à -3.

                            Je te cite :

                            C'est donc impossible avec un vélo et probablement impossible tout court.

                            Puis :

                            François Pervis, un des meilleurs français avant son accident, faisait 1300 watts sur 10 secondes

                            Merci d'avoir reconnu que tu as tort.

                          • [^] # Re: Cassantes

                            Posté par . Évalué à 2.

                            Tes données me semblent foireuses.

                            François Pervis développe 2200W. Un ami qui roule très très fort a été mesuré avec des pics à 1800W lorsqu'il faisait un entrainement expérimental.

                            1400W c'est ce qui a par exemple été mesuré sur le capteur de puissance d'Elia Viviani à la fin d'une étape du tour d'Italie de 170km.
                            http://italiancyclingjournal.blogspot.ch/2012/02/viviani-1390-watts-250m-sprint.html

                            1000W, n'importe quel cycliste chevronné les développes au sprint sur dix à 15 secondes. 600W est atteignable par un grand nombre de personnes.

                            • [^] # Re: Cassantes

                              Posté par (page perso) . Évalué à 3.

                              Je ne m'y connais pas franchement en vélo mais je suis curieux de voir un humain développer autant de puissance. Alors forcément 2200 je demande à Google, et je constate que c'est de l'instantané (en plus du fait que c'est du déclaratif non vérifiable), c'est à dire sur UN coup de pédale. En gros il tire comme un malade et ça fait 2200 watts pendant moins d'une seconde.
                              À ce compte là je fais plus de 1000 watts aussi, il suffit que je saute en l'air. Ça fait 1500 watts sur 0,25 seconde.

                              • [^] # Re: Cassantes

                                Posté par (page perso) . Évalué à 2.

                                Google m'indique d'autres liens avec des personnes qui développent aux alentours de 2000 watts durant plusieurs secondes. Des cyclistes.
                                Je suis vraiment (mais vraiment) étonné/épaté.
                                Je suis en particulier étonné par la progression de la puissance. Comment en 15 ans le corps humain des meilleurs a pu augmenter cette capacité de 50 ou 100% ? Les mesures d'avant étaient foireuses ? Le dopage+entraînement+nutrition (ne me faites pas croire que ce sont des athlètes naturels) est hyper-giga-ultra meilleur ?

                                De mon côté je reste avec mes 1500 watts sur 0,25 seconde.

                              • [^] # Re: Cassantes

                                Posté par . Évalué à 3.

                                À ce compte là je fais plus de 1000 watts aussi, il suffit que je saute en l'air. Ça fait 1500 watts sur 0,25 seconde.

                                Je pense que c'est pas l'activité la plus impressionnante. En éternuant ça m'étonnerais pas que certains déploient encore plus d'énergie sur moins de temps encore.

                                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                                • [^] # Re: Cassantes

                                  Posté par (page perso) . Évalué à 2.

                                  Difficile d'évaluer, mais je n'ai pas cette impression à première vue.
                                  La puissance dépend de la « force » du muscle, et de sa vitesse de contraction. La vitesse de contraction est je crois sensiblement la même pour tout le monde. Il y a peut-être un facteur 2 qui traîne, mais pas de quoi faire en sorte que le petit diaphragme rattrape les énormes fessiers+quadriceps+ischos+gastrocnémiens+soléaires.

                                  • [^] # Re: Cassantes

                                    Posté par . Évalué à 3.

                                    On parle là des muscles du tronc qui sont sollicités en permanence et doivent AMHA avoir une certaine force voir une force certaine (sachant qu'ils travaillent de concert contrairement au mouvement de pédalage qui sollicite des muscles plus grands et gros mais en moins grand nombre).

                                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Cassantes

                Posté par . Évalué à 0.

                Trouves moi une pente de 20% de moyenne continue sur plus de quelques mètres

                http://www.felesducolombier.fr/pour-devenir-feles/les-pentes ça existe. Je serai curieux de voir rv tourner dans ce genre de coin où les routes directes ont des pentes prohibitives et où les détours sont franchement pas gratuits.

                • [^] # Re: Cassantes

                  Posté par . Évalué à 2.

                  Tu viens juste de prouver le contraire. le Grand Colombier c'est 7% de moyenne avec des passage à 18% de moyenne sur 400m et un tout petit pic sur quelques mètres à 22%.

                  Et c'est le genre de col qui a été gravi pendant des années par des cyclotouristes avec un 42x23.

                  • [^] # Re: Cassantes

                    Posté par . Évalué à -1.

                    Et c'est le genre de col qui a été gravi pendant des années par des cyclotouristes avec un 42x23.

                    Impossible, jben te dit que même en 30x28 il faut être Froome pour monter une telle pente !

                    • [^] # Re: Cassantes

                      Posté par . Évalué à 2.

                      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.

                      • [^] # Re: Cassantes

                        Posté par . Évalué à 2. Dernière modification le 31/10/14 à 14:54.

                        Faut quand même être dingue pour se trimbaler 60kg de bagages, tu en fais quoi de tout ce merdier. Ta une garde robe entière de créateurs sur cintre dans ta remorque ? T'embarques ta hi-fi sur batterie + collection de vinyles ? Je comprendrais pour des périples de dingues dans des zones hyper hostiles mais bon ce n'est pas vraiment là-bas que tu vas utiliser rv. Il y'a des mecs qui font la route du Great Divide (4500km de tout terrain en altitude) avec maxi 12kg de charge vélo compris.

                        • [^] # Re: Cassantes

                          Posté par . Évalué à 3.

                          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.

                        • [^] # Re: Cassantes

                          Posté par . Évalué à 2.

                          12kg de charge vélo compris ??? En autonomie complète seul j'ai minimum 15kg de bagages (tente, réchaud, nourriture, eau…), 15kg de vélo (garde boue, lumière, portes bagages etc.) J'ai jamais vu moins.

                          Cet été par exemple, j'ai 4 sacoches, un follow-me, ma fille et son vélo.
                          Autre exemple une remorque avec deux enfants ça fait 60kg facile.

                          C'est justement avec un chargement que RV a un intérêt, si je roule tout seul sans bagage à côté de chez moi sur un vélo léger je m'en tape un peu des montées, même à 20% (trop fort je suis).

                • [^] # Re: Cassantes

                  Posté par (page perso) . Évalué à 3.

                  Je serai curieux de voir rv tourner dans ce genre de coin où les routes directes ont des pentes prohibitives et où les détours sont franchement pas gratuits.

                  S'il n'y a pas d'alternative, comment veux-tu que le logiciel fasse des miracles ? Il creuse un tunnel ?

                  • [^] # Re: Cassantes

                    Posté par . Évalué à 4.

                    Oh oui ! Je le rajoute dans ma todolist.

              • [^] # Re: Cassantes

                Posté par (page perso) . Évalué à 1.

                Promène-toi ici:
                http://www.openstreetmap.org/#map=15/43.6938/6.9881

                Tu y trouvera une pente >20% qui monte depuis le Chemin de l'Escure sur >100m ;-)

                • [^] # Re: Cassantes

                  Posté par . Évalué à 2. Dernière modification le 05/11/14 à 10:36.

                  mouais j'ai vérifié mais en fait non. Sur toute la longueur du chemin ça fait du 8.5% mais la partie à 20% ne dure que 100m justement. Il y'a 2-3 autres passages pentus mais plus court et entre chacun la pente baisse un peu.

                  Il ne faut pas se fier aux panneaux indicatifs sur le bord de la route, ça n'indique que le max.

                  Il existe des côtes très très dures avec des pourcentages approchants les 30%, notemment dans certains vignobles en terrasses. Mais elles sont tellement évidentes et nécessairement entourées d'autres routes plus faciles qu'un logiciel pour les éviter est tout à fait inutile. Même les véhicules à moteur les empruntent très peu.

        • [^] # Re: Cassantes

          Posté par . Évalué à 1.

          Pour garer un vélib sur la montagne sainte-geneviève quasi-quotidiennement, je pense que si. M'enfin, merci pour l'option, ça me donne l'occasion de me faire moinser, ce qui est toujours plaisant.

          "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

          • [^] # Re: Cassantes

            Posté par . Évalué à 4.

            Ne te vexes pas, il faut juste revenir au sujet "itinéraire minimisant l'énergie" et non pas de savoir qui est le meilleur grimpeur ou le meilleur vélo.
            La semaine dernière j'étais sur les monts de Lacaune avec un vélo chargé, j'ai du mettre pied à terre une fois en écoutant les conseils de l'épicière qui m'a assuré que son petit neveu prenait ce raccourci, la prochaine fois j'utiliserai un velib à la place de mon surly ;-)

            • [^] # Re: Cassantes

              Posté par . Évalué à 1.

              Après faut aussi savoir s'il y a moyen de louvoyer ou si on est obligé de prendre la côte de face, ce qui change encore une fois tout… Du coup ça me paraît difficile de trouver un critère pertinent de "pente max".

              "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

    • [^] # Re: Cassantes

      Posté par . Évalué à 2.

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

      • [^] # Re: Cassantes

        Posté par . Évalué à 1.

        Du coup il faudrait tenir compte du poids du véhicule (qui peut avoir une remorque, un siège enfant etc…). Je dirai même un filtre pas de pied à terre du tout ou pas de pied à terre sur plus de x mètres.

        • [^] # Re: Cassantes

          Posté par . Évalué à 2.

          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.

          • [^] # Re: Cassantes

            Posté par . Évalué à 1.

            Oui, un fort coefficient d'énergie perdue dans le cas d'un passage à pied. C'est bien mon problème. Par exemple je tracte ma fille (avec un follow-me), du coup chaque passage à pied est très contraignant, le poids de l'attelage et le fait que ma fille ne va pas marcher vite, il faut que je la surveille etc… Peut-être un "coef pénalité" en plus du poids ?

  • # le hic...

    Posté par . Évalué à 3.

    …c'est que plus on évite les côtes, moins on arrive à les passer.

    Et puis finalement, c'est tellement bon les descentes que ça vaut quand même le coup de se fatiguer un poil non ?

    • [^] # Re: le hic...

      Posté par . Évalué à 2.

      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.

  • # Oh un journal sur le cyclimse!

    Posté par (page perso) . Évalué à 10.

    Est-ce tu penses intégré la dangerosité comme critère dans ton algo?

    En effet, les automobilistes sont pour la plupart des psychopathes prêt à risquer une vie humaine et à passer des années en prison pour gagner quelques secondes en doublant à moins d'un mètre les gens qui utilisent des moyens de transport écologiques.

    http://devnewton.bci.im

    • [^] # Re: Oh un journal sur le cyclimse!

      Posté par . Évalué à 2.

      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.

      • [^] # Re: Oh un journal sur le cyclimse!

        Posté par . Évalué à 1.

        La dangerosité pourrait déjà être traitée au niveau des courbes et carrefours. Moins il y a de carrefours moins c'est dangereux généralement. Un carrefour en tourne à gauche est plus dangereux (et plus lent) qu'en tourne à droite.

        • [^] # Re: Oh un journal sur le cyclimse!

          Posté par . Évalué à 2.

          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.

          • [^] # Re: Oh un journal sur le cyclimse!

            Posté par . Évalué à 2.

            Si le trajet n'est pas appris par coeur les carrefours sont encore plus pénalisant, il faut s'arrêter et regarder l'itinéraire.
            C'est un peu comme les montées cassantes, tu vois le truc à redémarrer avec un attelage…

      • [^] # Re: Oh un journal sur le cyclimse!

        Posté par . Évalué à 1.

        Bonjour,

        J'ai fait quelques tests sur des coins que je connais "bien" en Ile-de-France.

        Je pense que l'absence de gestion des feux est un choix qui fait vraiment mal pour l'intérêt de rv en milieu purement urbain, jusqu'à franchement le disqualifier en l'état actuel pour cet usage, à mon avis. Je ne sais pas si quantifier la perte d'énergie a un feu (freinage puis relance), aiderait a améliorer cela. Et puis les données sur les vagues vertes de feux et la vitesse pour les attraper doivent être infernales à trouver. Enfin, en milieu urbain, se passer de données de cyclabilité est un défi…

        Hélas pour rv, je pense (mais sans pouvoir le prouver, c'est une pure intuition) que l'usage des routeurs pour vélos concerne pour l'instant surtout le milieu urbain. En fait, pour que vous rencontriez un public d'utilisateurs, je présenterais rv plutot comme un moteur qui

        • permettrait à un cycliste de concevoir un itinéraire lui permettant d'économiser la batterie de son VAE (prise en compte des feux impératifs pour viser le milieu urbain, ou sinon uniquement en campagne)

        voire :

        • permet à des associations/aménageurs d'avoir un critère de plus pour trouver où proposer/faire des pistes cyclables/véloroutes (en les mettant sur des trajets de moindre effort entre des noeuds d'un réseau)

        Vous pourriez même avoir une partie inverse : l'utilisateur rentrerait son parcours prévu, et vous donnez un taux de vidage de batterie du VAE théorique à la fin. Pas très sexy, mais vu le nombre de nouveaux cyclistes sur-équipés qui aiment bien quantifier le plus possible tout à l'avance, il y aurait peut-être une demande…

        Mais pour les cyclistes avec des vélos qui ne sont pas des VAE, pour l'instant, je pense que rv a une approche un peu étrange : c'est une sorte de planification théoriquement intéressante surtout à "grande" échelle, capable de proposer un gros détour, mais qui fait moins bien que les autres approches pour un routage instantané sur une courte distance pour un cycliste un peu perdu.

        • [^] # Re: Oh un journal sur le cyclimse!

          Posté par . Évalué à 3.

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

          • [^] # Re: Oh un journal sur le cyclimse!

            Posté par . Évalué à 1.

            Oui, en milieu urbain la conséquence première d'aller vite ou pas à vélo, c'est la possibilité ou non de prendre une vague verte… Il y a des vagues vertes qui ont l'air d'être vers 30, un bon cycliste peut espérer l'avoir, un cycliste plus lent va s'arrêter à 1/3 des feux au moins dans les pots d'échappements. Mais la donnée est manquante, on en est encore à s'échanger des bons plans sur les forums quand un cycliste expérimente une vague verte prenable à vélo quelque part !

            Mais comme tu choisis de les ignorer totalement (enfin, je pense, vu certains résultats que j'ai eus qui envoient dans des forêts de feux), ca fait que pour l'instant rv en ville fait passer par des goulots urbains sans hésiter. Donc, rv peut produire des résultats très "mauvais" en milieu urbain, ca peut donner une très mauvaise image.

            Pour le VAE, moi aussi ca me chagrine, y compris les VAE a 25 km/ (*), mais je constate que ca se répand de plus en plus. Et puis, par définition, ce sont des assistés, un moteur de routage orienté batterie VAE peut les intéresser :)

            Ensuite, si tu vises la planification de grande randonnée, je t'informe qu'il existe un moteur, développé par un pionner d'OSM, et qui fait (je suppose a priori) l'exact inverse du tien dans le principe : aucun critere purement energétique ou de relief, mais une approche basée sur le maillage existant des itinéraires cyclables : http://cycle.travel/

            Peut-être quelque chose à faire avec un mix des approches ?

            (*) : Raison 1 : La pub pour un VAE consiste à lister les défauts du vélo, super !
            Raison 2 : Un VAEiste qui a payé 2.000E pour rouler à 25 peut avoir tendance a avoir envie de rouler a 25, pas 23, et tant pis pour le cycliste devant a 23… Un vrai cycliste profite d'un ralentissement ponctuel pour reprendre son souffle et repartir de plus belle, un VAEiste lui il voit juste les secondes qui s'envolent, parce qu'apres de toute facon il sera de nouveau a 25, tellement c'est dur de rouler a 30 sur un VAE pour "compenser" le ralentissement.
            Raison 3 : J'arrête mais j'en ai d'autres :)

            • [^] # Re: Oh un journal sur le cyclimse!

              Posté par . Évalué à 1.

              Oui, c'est très typique comme comportement. Hier un vélo électrique m'a doublé dangereusement au pire endroit de la piste. J'ai pris sa roue tranquille jusqu'à la décente suivante où il m'a donné l'impression de freiner (en fait, il n'accélère pas en décente visiblement). Je sais pas si c'est qu'ils sont pas gentil ou s'il faut s'adapter à l'usage, mais je préférerai les voir sur la route…

              "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

  • # Félicitations

    Posté par . Évalué à 5.

    Je suis très heureux de voir des nouvelles du projet, je me demandais il y a quelques temps ce qu'il devenait. J'ai toujours une instance qui tourne chez moi (pas mise à jour depuis le dernier journal…), que j'utilise de temps en temps.

    J'aime beaucoup les résultats proposés par le routage, qui sont toujours très proches de ce que j'ai pu constater sur les trajets que je connais bien (j'ai même découvert une fois une astuce sur un trajet que je faisais quotidiennement depuis six mois).

    Ajouter une notion d'accélération latérale maximum, ce qui implique de limiter la vitesse de passage dans un virage en fonction de son rayon de courbure. J'avais échoué par le passé à avoir quelque chose qui ne faisait pas n'importe quoi, mais j'ai réussi à tester une méthode d'approche du rayon de courbure qui donnait des résultats cohérents avec mes traces GPS

    Ce serait une excellente idée. Je pense que ça permettrait en plus de corriger mon principal reproche à l'algo, qui gère parfois assez mal les enchaînements de carrefours. Petit exemple :

    Titre de l'image

    C'est certes plus court, mais avec autant de virages à 90 degrés, ça ne va pas plus vite et ça ne fatigue pas moins.

    • [^] # Re: Félicitations

      Posté par . Évalué à 2.

      Attention, on va te répondre que tu ne sais pas tourner ou qu'il faut changer de guidon ;-)
      Dans le même ordre d'idée les carrefours sont à éviter, même tous droits car ils obligent à redémarrer ce qui est parmi les plus consommateur d'énergie.

    • [^] # Re: Félicitations

      Posté par (page perso) . Évalué à 3.

      Tiens, ce trajet me fait penser à une optimisation de trajet qui n'a pas été mentionnée : la simplicité. En effet, certains moteurs de calcul d'itinéraire proposent parfois des trajets très compliqués, vachement optimisés pour minimiser la distance par exemple, mais au prix d'un nombre délirant de changements de direction, ce qui est génial pour se perdre…

      • [^] # Re: Félicitations

        Posté par (page perso) . Évalué à 2.

        Si tu regardes bien en l’occurences sur sa capture difficile de faire plus simple sans prendre un sens interdit ^ (à part faire le tour du truc vert).

        • [^] # Re: Félicitations

          Posté par . Évalué à 1.

          Bah si : continuer sur la rue Voltaire puis tourner à gauche rue Saulnier (sauf s'il y a une côte que j'ai raté).

          • [^] # Re: Félicitations

            Posté par (page perso) . Évalué à 2.

            ah je pensais le trajet de haut en bas.

            • [^] # Re: Félicitations

              Posté par . Évalué à 3.

              Le trajet est bien de bas en haut. Cependant, la rue Saulnier a un contre-sens pour les vélos, il n'y a donc pas de sens unique pour notre cas (ça ne se voit cependant pas avec ce fond de carte. Le fond de carte Cycle Map est beaucoup plus clair pour ces cas là).

      • [^] # Re: Félicitations

        Posté par . Évalué à 2.

        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.

    • [^] # Re: Félicitations

      Posté par . Évalué à 1.

      Tiens, un voisin !

      Du coup, je remarque un bug, les chemins dans le parc sont taggués highway=footway or en France, cela signifie interdit aux vélos : http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France

      La capture OSM se trouve ici : Lien OSM

      • [^] # Re: Félicitations

        Posté par . Évalué à 2.

        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 ?

        • [^] # Re: Félicitations

          Posté par . Évalué à 1. Dernière modification le 28/10/14 à 09:33.

          Les way id sont : 243819641, 243819642, 243819644 et 243819646. Ils datent d'un an.

          Dans le source,
          tags->'highway' NOT SIMILAR TO '(motorway|trunk|construction|steps|pedestrian|track)%'
          ne devrait pas devenir :
          tags->'highway' NOT SIMILAR TO '(motorway|trunk|construction|steps|pedestrian|track|footway)%'
          ?

          • [^] # Re: Félicitations

            Posté par . Évalué à 2.

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

            • [^] # Re: Félicitations

              Posté par . Évalué à 0.

              Il faudrait, plutôt que de l’interdire, le pénaliser comme de la marche à pied. Je pense à la passerelle du bout du pont Bir-Hakeim à Paris, que j’emprunte et qu’aucun routeur (comme GéoVélo à Paris par exemple) ne m’indique.

              Ô joie, en utilisant Hervé ça passait ! J’espère que la modif ne m’empêchera pas cela.

              Sinon, j’en profite pour te féliciter du boulot. Même à Paris, ça m’a donné exactement mon trajet quotidien, que j’optimise pourtant depuis un bon bout de temps. Je pense que pénaliser les virages aidera encore plus, même pour les feux : en général on s’arrête plus à un feu pour lequel on doit tourner qu’un feu où on va tout droit (si on est avantagé par une vague verte par exemple).

              • [^] # Re: Félicitations

                Posté par . Évalué à 2.

                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.

                • [^] # Re: Félicitations

                  Posté par . Évalué à 1.

                  Ce que vous risquez de devoir faire, c'est d'interdire les chemins qui coupent une porte fermée. J'avais testé sur hervé un exemple extrême : passer à travers les jardins à la française du château de Versailles. Le routage l'autorisait : en plus du problème déjà remonté, il avait des passages par des nœuds : barrier=gate,access=no.

    • [^] # Re: Félicitations

      Posté par . Évalué à 3.

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

  • # economies d'energie

    Posté par . Évalué à 3.

    Beau projet, content de voir que cela a bien avancé.

    l'idée est interessant, mais j'ai juste un doute,
    en voiture j'ai constaté que passer par un col plutot que faire le tour de la montagne revenait au meme pour la consommation.
    en effet, je consomme plus en montant, mais je consomme presque rien en descente.

    pour le velo c'est un peu pareil non ?
    en passant par le col, je vais faire 500m de denivelé positif, gros effort, suivi de 500m de denivelé negatif ou je n'aurais pas à pedaler, tout ca pour joindre 2 points en 1 ou 2h.
    si je fais le tour de la montagne, je vais rouler à effort constant pendant 2h30 ou 3h…

    • [^] # Re: economies d'energie

      Posté par (page perso) . Évalué à 3.

      oui mais si tu veux arriver au boulot pas en sueur… c'est la puissance développée qui compte plus que l'énergie développée dans ces cas là.

    • [^] # Re: economies d'energie

      Posté par (page perso) . Évalué à 3.

      Pour avoir fait du vélo-cross, je préfère les vallons : ça monte, ça descend, l'effort n'est pas trop long.
      Quand tu as une longue montée : tes jambes chauffent et les cuisses fatiguent ; arrivé en haut, si tu as une longue descente ensuite : tu vas passer ton temps à freiner et après ne plus avoir de jambes, tu ne vas plus avoir de bras ensuite, crispés qu'ils sont sur les freins et le guidon pour maîtriser les trajectoires. Crampes garanties…

    • [^] # Re: economies d'energie

      Posté par . Évalué à 2.

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

  • # Recherche de plus court chemin

    Posté par (page perso) . Évalué à 2. Dernière modification le 28/10/14 à 08:22.

    Salut!

    Tout d'abord bravo pour ton projet, c'est un sujet très intéressant. Quand est-ce qu'il y aura Bonn dans ta démo? ☺

    Je pense que l'algorithme de recherche de plus court chemin est très éloigné de ce qui est utilisé en réalité. Les algorithmes de type Dijkstra ou A* sont des algorithmes généralistes mais ici notre graphe est assez loin d'être aléatoire, c'est un réseau routier et il y a beaucoup de structures supplémentaires qui ne sont pas forcément faciles à décrire mathématiquement — parceque difficile à identifier — mais dont on peut tirer parti.

    À mon avis il est beacoup plus efficace d'essayer d'imiter ce que fait un être humain pour déterminer son trajet face à une carte:

    1. On détermine une série d'étapes intermédiaires en les choisissant parmi une liste prédéfinie.

    2. On calcule un plus court chemin entre ces étapes.

    3. On résout le problème en partant de plus courts chemins reliant ces étapes intermédiaires en utilisant une méthode de simulated annealing pour améliorer la première approximation.

    Le 1 correspond assez bien à la façon dont on s'oriente: pour un trajet dans une ville on s'oriente grâce aux grandes avenues et places principales par exemple. Pour ton on exemple, on peut choisir des étapes de référence indépendemment de critères de fréquentation, en prenant un maillage relativement large (par exemple une tous les 1km).

    Le 2 est plus rapide entre les étapes intermédiaires parceque on peut abandonner rapidement les recherches infructueuses (si deux étapes sont distantes de 1,5 km et que mon chemin fait plus de 3km je peux l'abandonner — ou le mettre de côté pour l'instant). Comme les étapes sont prédéfinies on peut précalculer certains chemins.

    Le 3 permet d'ajuster l'approximation obtenue en 2, le simulated annealing se prête bien à ce genre d'optimisation.

    On peut imaginer plein de variantes — par exemple différents niveaux d'étapes intermédiaires correspondant aux échelles du voyage (quartier, ville, région,…), et très certainement c'est une bonne idée de partir de plusieurs approximations initiales.

    • [^] # Re: Recherche de plus court chemin

      Posté par . Évalué à 2.

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

  • # Possible changement du coefficient de pénétration dans l'air ?

    Posté par (page perso) . Évalué à 3.

    Il me semble que certains utilisent des vélos couchés, et dans ce cas le Cx est bien plus faible (bien que je n'arrive pas à trouver de valeurs…).

    N'ayant pas regardé l'API, je ne sais pas si les coefficients pris en compte dans l'équation énergétique sont changeables à la volée.

    • [^] # Re: Possible changement du coefficient de pénétration dans l'air ?

      Posté par . Évalué à 6.

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

  • # BRouter

    Posté par . Évalué à 3.

    Bonjour,

    Je trouve ce projet super intéressant, et j'espère qu'il va continuer à se développer. Je n'ai pas encore fait de test, mais pour l'instant comme c'est expliqué plus haut l'interface web est assez limitée (plus d'une heure pour calculer un trajet Lyon-Grenoble !).
    Pour moi ce mode de calcul me parait très pertinent, car j'utilise le vélo pour me déplacer (différent de randonner), et régulièrement sur de longues distances (100-150km, voire 500km en 2 jours cet été). Sur ce genre de trajet, le calcul à énergie minimale est très pertinent.
    De même, le fait de pouvoir ajuster la masse, la vitesse sur plat, le SCx… est une façon très intuitive de définir un profil (je roule en vélo couché, et je "pédale" pas pareil pour faire 30km le matin ou 250km dans la journée).

    Il n'est pas fait mention dans ce post de BRouter (http://h2096617.stratoserver.net/brouter-web/), qui est un projet qui me semble assez ressemblant. Je n'ai pas creusé le mode de calcul de BRouter, mais sans forcément calculer l'énergie il prend en compte le dénivelé dans son calcul d'itinéraire, et donne des résultats très pertinents. Par contre la définition des profils est beaucoup moins intuitive…
    Pour info, sur le trajet Lyon-Grenoble, Hervé (configuré pour un vélo couché) me donne le même résultat (à peu de chose près) que BRouter en profil "VM-forum-liegerad-schnell", soit vélo couché.

    Un des développements que j'attends avec impatience, c'est la prise en compte du type de sol. Il va falloir du temps pour que toutes les petites routes soient taggées correctement (j'y travaille un peu…), mais au niveau de la vitesse et de l'énergie dépensée, ça change tout !

    Sinon, je suis cycliste et pas développeur, donc à part tester le bazar et faire des critiques je peux pas être très utile…

    • [^] # Re: BRouter

      Posté par . Évalué à 2.

      Après quelques tests sur des trajets que je connais bien, je plussois le problème des pentes cassantes. Je suis pas un grand fan des pentes raides, surtout quand je vais à un rendez-vous pour le boulot, et je préfère faire un détour quitte à perdre du temps.
      BRouter à l'air de mieux gérer ça, car sur ce trajet :
      http://osm104.openstreetmap.fr/herve/#1562
      il me fait faire le tour en longeant la Saône au lieu de passer par-dessus croix-rousse. Sans parler du fait qu'hervé me fait prendre un tunnel interdit aux vélos.
      En même temps, au niveau purement énergétique, monter raide, tout droit et lentement est clairement plus économe que monter en faisant des virages, en roulant un peu plus vite et en faisant plus de distance… dilemme pas facile à régler.

    • [^] # Re: BRouter

      Posté par . Évalué à 3.

      plus d'une heure pour calculer un trajet Lyon-Grenoble !

      Le serveur actuel n'est qu'une machine de test. J'ai pour projet de réecrire le backend de stockage, donc il va y avoir pas mal de mouvement à ce niveau.

      Il n'est pas fait mention dans ce post de BRouter

      Je ne connaissais pas BRouter jusqu'à il y a environ une semaine, et c'est postérieur à l'écriture de ce journal. Il y a certain cas où je ne suis pas en accord avec ce qu'il propose, c'est possible que je ne sois pas objectif.

      Sinon, je suis cycliste et pas développeur, donc à part tester le bazar et faire des critiques je peux pas être très utile…

      Maintenant que le dev de l'interface web reprend, je pense proposer des profils dans l'interface final (VD ballade, VD sportif, VC balladade…) tout en laissant une possiblilité de créer ses propres profils en décidant des paramêtres. Mais j'aurai à un moment besoin d'aide pour définir le profil d'un vélocipèdiste horizontal, je ne pratique pas moi-même. Et puis bon, les testeurs et les retours sont toujours utiles.

  • # Financement de l'hébergement

    Posté par (page perso) . Évalué à 1.

    Une approche qui pourrait être intéressante pour financer un hébergement correct, serait de chercher un parrainage par une assez grande métropole, en mettant en avant le coup de pub que ça apporterait à cette métropole auprès de ses cyclistes. Quel élu serait insensible à cet argument ?

    Habitant une grande ville, j'utilise souvent Géovélo pour aller d'un quartier à un autre (je ne les connais pas tous). Ce n'est pas idéal (hervé, en plus rapide, serait mieux), mais avec les rivières/fleuves, creux et collines, un outil pensé pour les vélos n'est pas du luxe.

    • [^] # Re: Financement de l'hébergement

      Posté par . Évalué à 2.

      Une approche qui pourrait être intéressante pour financer un hébergement correct

      C'est la partie qui me fait chier. Je fais ça pour mon plaisir. J'ai assez de dossier et formalités à la con à faire par ailleurs… Mais je sens que je vais devoir m'y coller.

      hervé, en plus rapide, serait mieux

      En fait, il y a plusieurs facteurs. Le premier c'est qu'il tourne sur un serveur de test, qui est volontairement limité, le second c'est qu'il utilise un backend de stockage pas adapté, je suis en train de régler ce dernier point. Pour le premier… bah, cf. ma réponse à la citation précédente.

      • [^] # Re: Financement de l'hébergement

        Posté par . Évalué à 1.

        Tu pourrais commencer par installer un site sur invitation pour tester que ça marche bien + estimer le volume de données, puis proposer ça sur abonnement pour financer le site?

        En tout cas, pour le moment, il n'existe rien pour permettre aux cyclistes de 1) créer un parcours puis 2) d'afficher le parcours coloré pour indiquer le dénivelé. Même Google ne fait pas ça.

        • [^] # Re: Financement de l'hébergement

          Posté par . Évalué à 0.

          Avec BRouter (http://h2096617.stratoserver.net/brouter-web/) on peut assez facilement faire son itinéraire. Il propose un itinéraire entre 2 points en fonction du profil souhaité, puis on peut le modifier facilement en "tirant" des points.
          Il donne le profil de dénivelé, le dénivelé positif, et on peut l'exporter en gpx. Je l'utilise tout le temps pour mes itinéraires.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.