Journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM

Posté par jben le 13 mai 2013 à 18:47. Licence CC By‑SA.

Étiquettes :

126

mai

2013

Sommaire

Voici un synopsis pour les décideurs pressés. J'ai réalisé un moteur de recherche d'itinéraire adapté au vélo. Le but c'est de minimiser non pas la distance, mais l'énergie fournie par le cycliste. J'utilise les données d'OpenStreetMap et SRTM. Le backend est publié sous licence BSD-2, je n'ai pas de frontend, je recherche des volontaires.

Présentation

Je suis un cycliste, et non un sportif. Pour moi la bicyclette est un moyen de déplacement idéal, mais uniquement un moyen de déplacement. Pour aller au boulot, pour aller faire des courses, ou plus généralement pour aller quelque part j'utilise mon vélo quand je peux c'est-à-dire quand la distance est raisonnable (comprise entre 5km et 15km, en dessous ça ne vaut pas le coup, au-dessus c'est trop pour moi), quand j'ai un endroit pour le déposer avec une bonne probabilité de le retrouver (ce qui exclue beaucoup de déplacements dans Paris pour mon plus grand désespoir), et quand je n'ai pas besoin ou que j'ai le moyen de me changer.

Excepté pour mon trajet domicile travail, le choix de l'itinéraire est un problème systématique. Il se trouve que je n'ai pas encore à ce jour trouvé un moyen de calculer un itinéraire qui m'est adapté.

Il est important pour moi que l'itinéraire n’en soit pas absurde, il n'est pas normal de descendre pour remonter si l'on peut facilement l'éviter. Il ne faut toutefois pas tomber dans l'excès inverse et ne pas faire un détour de 10km pour éviter une petite côte. Bref, j'ai voulu construire mon propre moteur de routage, avec un critère adapté au cycliste.

Il vient ensuite le choix du critère, habituellement on choisit la distance, ou le temps avec une vitesse dépendante de la catégorie de route. Aucun de ces deux critères n'est pour moi adapté au vélo, j'ai donc choisi d'utiliser un critère tout à fait naturel, l'énergie dépensée par le cycliste.

Ce critère est un bon compromis, si l'on peut éviter de descendre pour remonter au prix d'un petit détour cela sera énergétiquement valable, a contrario si fait un détour monstrueux on va dépenser plus d'énergie dans le détour que l'obstacle initial.

J'ai commencé à travailler là-dessus il y a deux ans, ça a beaucoup évolué, voici comment ça marche.

Données

Pour commencer, il faut des données, allons-y !

Données cartographiques

Concernant les données cartographiques, OpenStreetMap est le Graal pour ce genre de projet, il contient les routes, les points, des informations de circulation (autorisé ou non au cycliste, sens unique, contre sens cyclable…). Bref, c'est merveilleux, je suis heureux et les oiseaux chantent, sauf que…

Pour calculer mon énergie, j'ai besoin de l'altitude des points.

Données altimétriques

Après des essais avec les données de l'IGN accessibles, j'ai vite jeté l'éponge. Ces données posent deux problèmes principaux :

l'étendue spatiale limitée,
la licence qui est trop restrictive.

J'abandonne les données IGN. Toutefois, cela m'aura permis de comprendre certains trucs sur les systèmes de projection et de me familiariser avec proj.4, couteau suisse pour travailler avec des données cartographiques. Tout n'est pas perdu.

Il se trouve qu'un jour, j'entends parler des données SRTM au boulot (merci Aurore), ça avait l'air super intéressant. Passé le fait que la documentation est pour ces données ce que le discernement est pour un militant politique, j'étais très heureux.

J'interpole l'altitude des nœuds d'OSM à l'aide des données SRTM, et ça roule. Pour être plus précise, l'interpolation est faite avec une interpolation bilinéaire, des interpolations plus fines (qui ont été testés) n'apportent pas grand-chose par rapport aux problèmes qu'elles soulèvent.

Modèle de cycliste

Bon, c'est bien maintenant que j'ai des données je vais pouvoir optimiser un itinéraire… Euh, wait il manque pas un truc ? Il faut définir la façon dont un cycliste dépense son énergie.

Rien de plus simple, une fois qu'on a défini un modèle de pédaleur.

Hypothèses

Comme dans tous les modèles, nous avons des hypothèses, je vais essayer de les expliciter, j'en oublierai peut-être certaines, j'en suis désolé.

Le cycliste, même sportif, n'est pas relativiste

Cette hypothèse est très forte, et elle me choque beaucoup. Toutefois, je vais faire de la mécanique Newtonniene.

Le bipède fournit une puissance constante

Cette hypothèse peut sembler saugrenue, mais en fait elle est la clef d'une pratique efficace du vélo, c'est-à-dire l'utilisation judicieuse des différents développements pour fournir une puissance constante. Je ne compte plus le nombre de fois où je me suis fait doubler en côte par des vélocipédistes que je prenais une grande joie à enrhumer par la suite.

Si c'est le fait de pédaler en descente qui vous dérange, dites-vous bien que certains cyclistes le font, et quand niveau énergétique ça ne change pas grand-chose, le temps passé en descente est faible en général.

La route est droite est sans arrêts

Comme il n'y a aucun moyen de savoir si un virage entraîne un freinage et donc une perte d'énergie, à moins d'utiliser des heuristiques qui en fonction de l'angle prennent une décision, il n'y aura pas de perte d'énergie. Le modèle fonctionne donc comme si la route était droite. Pour information, j'ai essayé quelques heuristiques sur des trajets que je connaissais, sans résultats conformes à la réalité.

De même, on n’a aucun moyen de savoir quand le cycliste s'arrête, il ne s'arrête donc pas. Nous sommes donc en présence d'un chauffard à bicyclette ne respectant aucun feu tricolore, et ne voyant pas les virages (tout en restant sur la route qui est toujours droite par définition, c'est beau la théorie, hein ?).

Le sportif et son instrument de torture constituent un unique point matériel

L'hypothèse est simple, on considère qu'il n'y a aucune déformation de roues ou pneu et qu'il n'y a pas de mouvement de rotation interne. En pratique, on veut surtout dire qu'il n'y a pas d'énergie stockée sous ces formes.

L'attirail est soumis aux forces suivantes

Les forces considérées sont seulement les forces résultantes dans l'axe longitudinal. Les forces dans l'axe perpendiculaire à la route et dans l'axe latéral sont perpendiculaires au mouvement, donc de travail nul.

Outre la force provenant du mouvement de la bête perchée sur sa monture, les forces présence sont les suivantes :

Le poids (en cas de pente négative, cette résultante aura tendance à accélérer le vélo, en cas de pente positive elle aura tendance à le ralentir), c'est la force qu'on doit considérer.
La résistance au roulement. C'est la force qu'exerce la route sur le vélo, mais aussi la qualité des axes, \textit{etc}. Cette force est toujours néfaste au cycliste.
Les frottements de l'air. Sauf dans le cas où l'on a le vent dans le dos à une vitesse supérieure à laquelle le vélocipède se déplace, elle est néfaste au mouvement.

Modélisation des forces

Donc je vais ici modéliser une à une les forces intervenantes sur l'ensemble du chevalier et de sa monture.

Force exercée par le vélocipédiste

La puissance fournie par la force exercée par l'animal est donc de Pᶜ = Fᶜv donc pour avoir une puissance constante, la force considérée sera Fᶜ = Pᶜ/v.

Le poids

La masse considérée pour le calcul du poids, et la masse totale de la bête, du vélo et des bagages. Seule la résultante par rapport à l'axe longitudinal est considérée.

Donc Fᵖ = -m⋅g⋅sin(θ) où θ est l'angle de la pente. Si θ est positif la force est motrice (en descente).

La résistance au roulement

La résistance au roulement est toujours une force s'opposant au mouvement, elle est modélisée de la façon suivante : Fʳ = -m⋅g⋅Cᵣ où Cᵣ est un coefficient caractéristique de la route et des pneus.

Une valeur courante est Cᵣ = .01, dans le cas de route en mauvais état ou de pneus larges (comme VTT) on pourra avoir tendance à l'augmenter, dans le cas d'un vélo de course à le diminuer.

Les frottements de l'air

La force de résistance du vent est modélisée comme suit : Fᵃ = ½ ρₐ⋅S⋅Cₓ⋅vₐ²

où :

ρₐ est la masse volumique de l'air, elle change en fonction de la température, mais ce changement est assez faible dans les plages classiques de la pratique du cyclisme,
S est la surface exposée par le cycliste,
Cₓ est le coefficient de pénétration dans l'air (profilage de casque, etc.). En général on travaille directement avec le produit SCₓ.
vₐ est la vitesse de l'air par rapport au cycliste. S'il n'y a pas de vent, alors la vitesse de l'air par rapport au sportif est l'opposée de la vitesse du vélocipédiste par rapport à l'air, sinon il faut tenir compte du vent et de sa direction.

Résumé du modèle

Pour résumer :

l'animal est soumis à des forces
on peut appliquer un principe fondamental de la dynamique
l'énergie dépensée par le cycliste s'extrait simplement

Par contre, l'équation différentielle obtenue est non linéaire, et après l'avoir trituré (à plusieurs) dans tous les sens, elle ne semble pas analytiquement soluble. Et une simulation numérique avec un pas temporel est exclue pour des questions de performance. Une approximation sera faite, j'y reviendrai plus tard.

Implémentation

Faute d'avoir trouvé un nom intéressant, le moteur de routage se nomme rv, comme routage vélo, le nom du premier dossier que j'ai créé. Au final, je me suis habitué à ce nom, et un nom comme Hervé pour une interface me semblerait approprié.

Historique

J'ai commencé à travailler dessus ce projet il y a plus de deux ans, et j'ai abouti à des premiers résultats il y a environ un an. Les grandes phases ont été :

en C++ avec un format de stockage ad-hoc et les données altimétriques de l'IGN,
en C++ avec un format de stockage ad-hoc et les données altimétriques de SRTM,
en C++ avec un stockage sqlite et les données altimétriques de SRTM,
en C++ avec un stockage postgres non synchronisées et les données altimétriques de SRTM,
en C++ avec un stockage postgres synchronisées et les données altimétriques de SRTM.

Il y a un an je suis arrivé au point 3. et à l'aide d'un serveur loué chez OVH, j'ai pu passer à l'échelle de la France. En août 2012 je suis parti 15 jours avec ~ma bite et mon couteau~ mon vélo et ma tente, et j'ai utilisé mon moteur de routage pour me guider en Normandie de camping à camping. J'en ai tiré les améliorations suivantes :

ajout du vent dans le modèle qui auparavant en était dépourvu (il y avait les frottements de l'air, mais je considérai toujours que la vitesse du vent était nulle), car la normandie et le vent, ben…
ajout de la résistance au roulement, je me suis rendu compte qu'il avait tendance à faire de trop gros détour pour éviter de petites côtes, comme si le fait de rouler pas vite (donc frottements de l'air faibles) l'autorisait à faire beaucoup de distance, mon hypothèse initiale qui consistait à considérer la résistance au roulement comme négligeable était violemment fausse, mes muscles en ont témoigné.

Après avoir effectué ces modifications (à la lueur d'un écran de netbook, sous une tente, relié au serveur en ssh au moyen d'une connexion 3G), le routage proposé m'a paru sympathique, en effet j'allai de camping sur la côte à camping sur la côte, et la côte normande n'est pas connue pour son coté plat…

Revenu en terrain civilisé, j'ai fait quelques essais en descente départ arrêté, sans pédaler, avec un traceur GPS, pour voir si la courbe de vitesse prévue correspond à la courbe de vitesse observée, et les résultats sont très bons, meilleur que les essais précédents. La résistance au roulement était un point crucial à prendre en compte.

Puis je me suis rapproché d'OpenStreetMap France, via IRC, et je me suis vu proposé une VM sur une de leurs machines fournies par la Fondation Free, un VM avec une quantité de RAM largement acceptable (et inespérée) pour continuer mes expérimentations.

Depuis je suis passé à postgres. J'ai déporté petit à petit une bonne partie de la complexité vers des procédures sur la base.

Algo de recherche

Alors, il y a rien de bien nouveau, je cherche un itinéraire minimisant une fonction de coût, ici l'énergie fournie par l'animal, j'utilise une version étendue de l'algorithme de Dijkstra, connue sous le nom d'algorithme A*. De plus, le coût de chaque arête dépend du chemin parcouru précédemment (exemple le coût d'une côte est faible si l'on a accumulé de la vitesse grâce à une descente).

J'utilise comme heuristique une heuristique dite admissible, c'est-à-dire une minoration de l'énergie dépensée correspondant à l'énergie dépensée sur une ligne droite de pente constante. Un raisonnement physique permet de dire que c'est une minimisation. Cette heuristique étant admissible, l'algoritme A* trouvera le chemin minimisant le coût.

Connexité

Un des problèmes majeurs qui est apparu, et que je me suis attelé à résoudre ces derniers mois, est la connexité. En effet, il existe des petites composantes connexes (que les gens sur le channel IRC d'OpenStreetMap France nomment ilôts isolés), ces petites composantes connexes peuvent être de trois ordres :

réelles cartographiquement, par exemple une île, et dans ce cas il est légitime qu'une demande d'itinéraire entre l'île et le continent échoue,
une erreur de cartographie d'OSM, par exemple une route non reliée,
une erreur d'étiquetage, une route autorisée au vélo reliée au reste du monde par une route interdite au vélo.

Excepté dans le premier cas, ces composantes connexes sont de taille minuscule, et il faut projeter un des points sur la grosse composante connexe. Le problème c'est qu'il faut connaître ces composantes connexes.

C'est là où ça se corse, il faut précalculer les informations de connexités, et il faut remettre à jour les informations de connexité à la mise à jour de la base. Tout est fait sous forme de procédure postgres, lors de l'import initial (relativement long) et lors des mises à jour de la base.

Code

Actuellement le code est divisé en trois parties :

le moteur de routage en C++
les procédures postgres permettant l'import initial et la mise à jour. L'avantage d'avoir cela sous forme de procédure c'est que toute la mise à jour de la base et le précalcul nécessaire est fait au sein d'une seule transaction garantissant ainsi la cohérence des données,
un binding python pour pouvoir lancer la procédure et récupérer les résultats de manière simple.

La façon d'utiliser le moteur de routage, de réaliser les imports dans la database est disponible au sein du même répertoire. Il y a aussi les infos sur comment la mettre à jour automatiquement quotidiennement via un cron.

C'est par ici que vous trouverez le code, et c'est sous licence BSD-2.

Interface de test

Mais vous pouvez avoir envie de tester le bousin sans importer la database, et je vous comprends ! En effet, l'importer à l'échelle de la France, en ordre de grandeur c'est une semaine de calcul. Après on peut la mettre à jour quotidiennement via un cron, c'est ce que je fais.

Mais je vous propose de tester sur la machine mise gracieusement à ma disposition par OpenStreetMap France. Il suffit pour cela d'utiliser le module rv tel que défini dans rvpy/rv.py. La configuration par défaut d'une instance de la classe Route utilise osm104.openstreetmap.fr sur le port 29302 pour faire le calcul.

En téléchargeant le fichier rvpy/rv.py dans le répo git vous pouvez directement faire des essais, et vous amuser avec. Le fichier rvpy/example contient un exemple d'utilisation.

Attention : Afin de ne pas écrouler la machine, une limitation de 8 calculs de routage en même temps a été imposée sur cette interface de test.

Frontend

C'est bien beau tout ça me diriez vous, mais c'est pas très utilisable par un vélocipédiste standard, et vous auriez raison. Nicolas Dandrimont a réalisé un premier frontend, disponible ici, mais n'a, a mon plus grand regret, pas le temps de développer le frontend des mes rêves.

Je n'ai pas de vrai frontend, et j'aimerai bien trouver quelqu'un qui veuille développer un frontend, pour moi le frontend idéal :

permet de choisir en cliquouillant le point de départ, d'arrivée et les éventuels waypoints.
affiche un ensemble de paramètres minimaliste (masse, vitesse de base sur le plat…)
permet via un menu/mode/onglet avancé de choisir tous les paramètres (pour ceux qui veulent jouer)
affiche l'énergie totale fournie sur le trajet, la vitesse moyenne, le dénivelé positif
trace l'itinéraire une couleur variable indiquant la pente
permet en cliquant sur un point de l'itinéraire d'avoir des infos relatives au point
affiche un profil d'altitude

Toutes ces infos sont fournies par le backend.

Conclusion

Je tiens tout d'abord à remercier Nicolas Dandrimont que j'ai régulièrement embêté depuis deux ans avec mon projet et qui m'a fourni des infos précieuses sur l'utilisation des données OSM. J'ai aussi sollicité ceux qui traînent sur le chan d'OpenStreetMap France qui ont répondu à mes questions même si elles étaient débiles, et m'ont fourni des infos sur la façon de travailler avec des bases de données OSM.

Je remercie tout particulièrement l'association OpenStreetMap France qui m'a fourni l'infrastructure nécessaire au développement de mon projet.

J'ai comme perspectives de faire un autre backend de traitement de trace GPS pour interpréter a posteriori un parcours réalisé par un cycliste en terme de dénivelé total, pente, énergie, puissance maximale. Si quelqu'un est volontaire pour faire un frontend, ça fait des idées pour continuer dans la même veine.

Et enfin, si quelqu'un a envie de faire un frontend, ça serait avec un très grand plaisir.

P.S. : Rédiger son journal dans un éditeur de texte c'est bien, devoir le reformater pour éviter que les retours à la ligne ne soient significatifs contrairement à l'habitude en MarkDown, c'est moins bien. N'hésitez pas à appuyer mon rapport de bug.

P.S. bis : en plus de la licence indiquée, ce contenu est placé sous la licence CC-BY

# BRAVO !!!

Posté par windu.2b le 13 mai 2013 à 19:09. Évalué à 10.

Déjà, félicitations pour le boulot fait. Depuis un moment, je me désespérais de trouver un tel outil : Google Maps en France ne veut plus calculer d'itinéraires pour le vélo, http://www.geovelo.fr/ est pas mal mais ne fonctionne que sur Paris, …

Bref, merci beaucoup ! En échange, je participerais volontiers au développement du front-end :-)

Je me permets de rajouter quelques idées :
* pouvoir exporter une recherche, via un permalink ;
* indiquer la part du trajet sur les voies cyclables, pistes cyclables, routes sans aménagement cyclable, …
- [^] # Re: BRAVO !!!
  
  Posté par jben le 13 mai 2013 à 20:06. Évalué à 10.
  félicitations
  
  Merci beaucoup.
  
  En échange, je participerais volontiers au développement du front-end :-)
  
  Avec plaisir, par contre je tiens à préciser que je n'y connais rien au développement web. Tout ce que je peux faire c'est modifier le backend pour avoir d'autres/plus d'infos.
  Je me permets de rajouter quelques idées :
  - pouvoir exporter une recherche, via un permalink ;
  Justement, ça j'en avais discuté avec Nicolas, et j'ai prévu que le backend crache des infos sur les versions des chemins utilisé. Ce qui permettra que lorsqu'un itineraire exporté via un permalink est affiché de mettre éventuellement un message du genre _les chemins constituants cet itinéraires ont été modifié depuis sa création
  - indiquer la part du trajet sur les voies cyclables, pistes cyclables, routes sans aménagement cyclable, …
  C'est possible. Par contre il faut voir que l'optimisation ne se fait du tout par rapport à ce critère. J'ai quelques idées pour aboutir à une optimisation prenant aussi en compte ce critère, ça pourrait éventuellement ce faire. Je ne l'ai pas fait, car pour moi ce n'est pas un critère, il faut dire que je fais du vélo tous les jours dans Paris en traversant des trucs gens la place d'Italie, alors mon sens du tranquille en est séverement alteré.
  
  En tous cas tu as déjà trouvé comment me joindre. Le channel IRC d'osm-fr est une des possiblilités.
- [^] # Re: BRAVO !!!
  
  Posté par Olivier LEMAIRE (site web personnel) le 13 mai 2013 à 20:46. Évalué à 1.
  
  Moi aussi j'utilise geovelo, qui est aussi disponible pour Nantes et Tours.
  
  Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée
- [^] # Re: BRAVO !!!
  
  Posté par Xinfe (site web personnel) le 13 mai 2013 à 21:19. Évalué à 10.
  
  En plus de Bravo sur la technique, j'appose un autre Bravo pour l'écriture. J'ai passé un bon moment à lire et rire devant mon ordi.
- [^] # Re: BRAVO !!!
  
  Posté par Patrick Nicolas le 14 mai 2013 à 09:28. Évalué à 1.
  
  Je me joins à ces félicitations, je vais tester ça dès que possible.
  Je participerais aussi volontiers à un frontend, on signe où pour s'organiser ?
  - [^] # Re: BRAVO !!!
    
    Posté par LeBouquetin (site web personnel, Mastodon) le 14 mai 2013 à 10:17. Évalué à 2.
    
    Je serais également très intéressé par participer.
    - [^] # Re: BRAVO !!!
      
      Posté par jben le 14 mai 2013 à 20:49. Évalué à 2.
      
      Je ne pensais pas rencontrer autant d'ehthousiasme, et à dire vrai, javais rien prévu. Merci beaucoup.
      
      Je vous propose de se réunir sur le chan IRC #rv@oftc, ça évitera de polluer le chan #osm-fr.
# Approximation

Posté par jben le 13 mai 2013 à 20:15. Évalué à 10.

J'ai écrit :

Par contre, l'équation différentielle obtenue est non linéaire, et après l'avoir trituré (à plusieurs) dans tous les sens, elle ne semble pas analytiquement soluble. Et une simulation numérique avec un pas temporel est exclue pour des questions de performance. Une approximation sera faite, j'y reviendrai plus tard.

Sauf que je n'y suis pas revenu.

Alors l'idée est simple. Quand je veux aller d'un nœud OSM (c'est à dire d'un point dans l'espace) à un autre, je fais une approximation.

Au niveau du premier nœud j'ai ma position et vitesse comme condition initiale et il faudrai résoudre l'équation différentielle non linéaire de degré deux pour avoir la vitesse à la position finale ainsi que l'énergie consommée sur ce segment.

Ce que je fais c'est que je considére que sur ce segment la vitesse évolue linéairement en fonction du temps passant de la vitesse initiale à la vitesse finale. L'erreur effectuée fait qu'on a tendance à sur-estimer les frottements de l'air lorsuqu'on est au dessus de la vitesse d'équilibre et les sous-estimer quand on est en dessous.

Des résolutions numériques avec Runge-Kutta à l'ordre 4 de l'équation differentielle nous montre que vu la taille faible des segments l'erreur effectuée est très faible. Et faire des simulations dans le cadre de la recherche d'itinéraires serait impossible avec des ressources raisonnables.
- [^] # Re: Approximation
  
  Posté par smeuuh le 13 mai 2013 à 20:28. Évalué à 6.
  
  Ce que je fais c'est que je considére que sur ce segment la vitesse évolue linéairement en fonction du temps passant de la vitesse initiale à la vitesse finale. L'erreur effectuée fait qu'on a tendance à sur-estimer les frottements de l'air lorsuqu'on est au dessus de la vitesse d'équilibre et les sous-estimer quand on est en dessous.
  
  Ah, c'est malin. Sinon ce que tu peux faire c'est linéariser le v² autour de la vitesse d'entrée. Ensuite, tu déduis la trajectoire, et tu recommences le procédé avec la vitesse moyenne obtenue à partir de la trajectoire, et tu itères jusqu'à convergence. De toute façon c'est de l'enculage de mouches.
  
  (et si ça te choque tant que ça de négliger la relativité, c'est très facile à rajouter dans les équations ;))
  - [^] # Re: Approximation
    
    Posté par jben le 13 mai 2013 à 20:33. Évalué à 5.
    
    linéariser le v2 autour de la vitesse d'entrée […] tu itères jusqu'à convergence
    
    Niveau temps de calcul, mes essais m'on montré qu'il fallait quelques itérations pour atteindre la convergence, et donc beaucoup plus couteux en temps que ce que je propose pour un gain ridicule. J'y avais pensé ;-), mais merci de la suggestion.
    - [^] # Re: Approximation
      
      Posté par smeuuh le 13 mai 2013 à 20:42. Évalué à 1.
      
      Ah, moi qui pensais être original ;)
      En googlant un peu, je suis tombé sur ce très mignon preprint, qui date de la semaine dernière : http://arxiv.org/pdf/1305.1283v1.pdf. Ils ont notamment une review de plusieurs méthodes, y compris une qui obtient une solution closed-form en supposant la trajectoire quasi-horizontale, avec des très bons résultats apparemment (Figure 1). Plus une curiosité qu'autre chose, mais bon …
# Affichage des pentes sur le parcours

Posté par Strash le 13 mai 2013 à 22:14. Évalué à 5.

J'aime beaucoup la démarche, utiliser de la bonne vielle physique pour résoudre un itinéraire, c'est intéressant ! Inclure une préférence pour les pistes cyclables ne devrait pas être trop difficile à ajouter, par exemple en ajoutant un léger biais sur le calcul de l'énergie lors de l'utilisation d'une piste cyclable (ce qui est parfois une réalité, on a moins à être vigilant et on pédale plus efficacement lorsque l'on a pas à s'assurer que l'on ne va pas se faire rentrer dedans à tout instant).

Il serait intéressant d'afficher en rouge les parties en montée et en vert les parties en descente le long de l'itinéraire (avec éventuellement un dégradé de couleur suivant l'angle de la pente).

Mais je suppose que cela est plutôt à faire du coté du Frontend.

Cela permettrait de se faire une bonne idée de la difficulté du chemin trouvé.
- [^] # Re: Affichage des pentes sur le parcours
  
  Posté par jben le 13 mai 2013 à 23:16. Évalué à 5.
  Il serait intéressant d'afficher en rouge les parties en montée et en vert les parties en descente le long de l'itinéraire
  
  C'est ce que je pensais quand j'ai écrit :
  - trace l'itinéraire une couleur variable indiquant la pente
  J'avoue que j'avais dans la tête le même code couleur que toi.
  
  en ajoutant un léger biais sur le calcul de l'énergie lors de l'utilisation d'une piste cyclable (ce qui est parfois une réalité, on a moins à être vigilant et on pédale plus efficacement lorsque l'on a pas à s'assurer que l'on ne va pas se faire rentrer dedans à tout instant)
  
  Ça me gène sur deux points, le premier c'est comment choisir le biais, et le second c'est qu'en règle général je ne suis pas d'accord avec cette affirmation entre parenthèse. En tant que vélocipèdiste, je n'utilise pas ou peu les pistes cyclables. C'est à dire que je route entre 30 et 35 km/h sur le plat, excepté les situation de rando où je préserve mon corps. Je trouve que souvent les pistes ne sont pas adaptés au dela de 15 km/h, avec les morceaux de trotoirs, etc. Après il existe des exceptions, j'ai de très bon souvenir de vrai piste larges en mon état, compétement séparé de la route ou faire du vélo dessus à 35 km/h était un plaisir, mais ça tient plus de l'exception que de la règle.
# Magique !

Posté par camalot le 13 mai 2013 à 23:08. Évalué à 5.

Bravo ! J'ai testé (pour Lyon : Doua - Lanennec), ça évite bien les principales côtes, c'est optimisé et pas si loin de mon trajet habituel ! C'est classe :)

Bon j'ai certainement pas les compétences globales pour t'aider entièrement dans le frontend, mais il se peut que je puisse donner un coup de main !

Ceci dit à lire vos commentaires, je trouve (enfin?) une utilité à ces équations dif et les schémas, je vois que ça parle de Runge et Kutta… Mon prof aurait du nous présenter ça!

Merci ;)
- [^] # Re: Magique !
  
  Posté par jben le 13 mai 2013 à 23:17. Évalué à 4. Dernière modification le 13 mai 2013 à 23:17.
  
  Bon j'ai certainement pas les compétences globales pour t'aider entièrement dans le frontend, mais il se peut que je puisse donner un coup de main !
  
  N'hesite pas à me contacter. Je traine sur le chan IRC d'osm-fr.
# Vol

Posté par 🚲 Tanguy Ortolo (site web personnel) le 14 mai 2013 à 01:09. Évalué à 8.
Pour aller au boulot, pour aller faire des courses, ou plus généralement pour aller quelque part j'utilise mon vélo quand je peux c'est-à-dire quand la distance est raisonnable (comprise entre 5km et 15km, en dessous ça ne vaut pas le coup, au-dessus c'est trop pour moi), quand j'ai un endroit pour le déposer avec une bonne probabilité de le retrouver (ce qui exclue beaucoup de déplacements dans Paris pour mon plus grand désespoir)

Bof, les vols, les vols, on peut s'en prémunir, ou alors c'est que j'ai vraiment le cul bordé de nouilles pour ne m'être jamais fait voler un vélo en quinze ans de pratique urbaine intensive. Les points importants :
- avoir un bon antivol en U ;
- avoir un vélo qui n'a plus que le cadre d'origine, donc on a changé le guidon, la selle… de sorte qu'il a l'air de tout, sauf d'un beau vélo neuf bien assorti ;
- aller de temps en temps se promener dans des chemins mal fichus en forêt après une semaine de pluie, bref dans des bourbiers, et ne jamais, jamais laver sont vélo après (pour qu'il ait l'air mal entretenu, vieux et moche), exception faite des pièces mécaniques (pour que ça roule toujours impeccablement) et des zones de contact avec le cycliste (pour ne pas se salir).
- [^] # Re: Vol
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 14 mai 2013 à 08:36. Évalué à 5.
  
  De surcroît, si l'on en croit la police, ~50% des vols de vélo se produisent à domicile. Laisser son vélo chez soi n'est pas nécessairement gage de sécurité.
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
- [^] # Re: Vol
  
  Posté par lolop (site web personnel) le 14 mai 2013 à 08:49. Évalué à 5.
  
  Q? est-ce que ce truc: http://www.bicycode.org/ est efficace ?
  
  Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
  - [^] # Re: Vol
    
    Posté par dj_ (site web personnel) le 14 mai 2013 à 19:32. Évalué à 3.
    
    En belgique on peut graver le n° national du propriétaire du vélo, si la police trouve un vélo avec un n° ils contactent la personne
    
    pareil en cas de revente, on peut demander a vérifier que c'est bien le proprio
  - [^] # Re: Vol
    
    Posté par windu.2b le 14 mai 2013 à 19:55. Évalué à 2. Dernière modification le 14 mai 2013 à 19:56.
    
    Je te dirai ça quand je me serai fait voler mon vélo…
    
    (il est bien évident que le bicycode n'est pas dissuasif, mais permet de contacter facilement le propriétaire, si le vélo est retrouvé).
- [^] # Re: Vol
  
  Posté par jben le 14 mai 2013 à 20:57. Évalué à 4.
  
  J'ai un bon antivol en U, et ce n'est pas le problème. Par contre mon vélo à l'air bien, est équipé dans tous les sens, mon guidon c'est un tableau de bord (sonette, trompe, compteur, support pour carte plié sur l'avant, support pour GPS, rétroviseur vers le bas vers l'interieur pour ne pas prendre de la largeur).
  
  Il faut attacher les roues, etc. J'ai même connu quelqu'un qui s'est fait voler ses changements de vitesse push-pull (ce que j'ai en plus).
  
  C'est vrai que j'aime être confortable sur mon vélo et que mets le prix, mais en même temps c'est mon principal moyen de transport. Et j'ai un endroit où le mettre au boulot dans Paris, et si je sors le soir je peux même passer le récuperer (si je respecte la limite légale d'alcolemie). En vrai je ne me plains pas trop…
# Excellent !

Posté par cedric le 14 mai 2013 à 04:42. Évalué à 9.
Impressionnant comme boulot, openstreetmap est vraiment une plateforme qui a de plus en plus d'interet. Ca fait deux fois que je pars en vacances et que la meilleure cartographie est fournit par Openstreetmap et marche en plus offline ! J'aurais juste deux questions :
- Est-ce qu'il serait possible d'en faire une version offline en recuperant juste la base de donnees Postgresql par exemple ? En gros, ton serveur Postgresql consomme combien de ram ? Et quel est la puissance processeur minimal necessaire pour resoudre un itineraire ?
- Et tu aurais la meme chose en stock pour la randonnee ? :-)
- [^] # Re: Excellent !
  
  Posté par ʭ ☯ le 14 mai 2013 à 08:42. Évalué à 2.
  
  Et tu aurais la meme chose en stock pour la randonnee ? :-)
  
  En randonnée, il est très très très très rare que le plus court chemin - pas la ligne droite à travers champs et montagnes - ne soit pas celui qui te fatiguera le moins : la plupart de l'effort est dans la station debout, pas dans le fait d'avancer les jambes.
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: Excellent !
    
    Posté par aedrin le 14 mai 2013 à 09:00. Évalué à 3.
    
    Oui, enfin, pas si rare que ça, surtout en montagne !
    En montée raide tu te fatigues beaucoup et en descende raide tu mets trois plombes pour éviter de te casser la margoulette :-p
    
    C'est pas pour rien que quand on peut, on vise un col ou on reste sur le chemin de crêtes qui fait 2km de plus mais qui t'économise les montagnes russes !
    - [^] # Re: Excellent !
      
      Posté par ʭ ☯ le 14 mai 2013 à 09:07. Évalué à 9.
      
      C'est pour ça que je parlais de suivre les chemins : s'il y a un chemin tracé, c'est que c'est le meilleur moyen d'aller d'un point à un autre. L'algo du cyclimse est donc plutôt inutile à pied.
      
      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
      - [^] # Re: Excellent !
        
        Posté par cedric le 14 mai 2013 à 10:57. Évalué à 2.
        
        Il y a rarement un seul chemin pour faire 15km :-) Et la ou je fais de la randonnee, je passe un peu de temps a devoir regarder les cartes pour justement choisir le trace le plus interressant. Un mix de point de vue et d'optimisation de parcour.
        
        [^] # Re: Excellent !
        
        Posté par ʭ ☯ le 14 mai 2013 à 13:52. Évalué à 5.
        
        un mix de point de vue et d'optimisation de parcours.
        
        Tu te balades en optimisant l'effort? 8oO
        
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
        
        [^] # Re: Excellent !
        
        Posté par calandoa le 14 mai 2013 à 19:55. Évalué à 4.
        
        Généralement, en rando tu as un objectif comme un sommet ou autre… si tu veux juste agiter tes jambes, je te conseille plutôt le tapis roulant dans une salle de sport (ou les escalators à contre sens dans le métro si t'es radin).
        
        [^] # Re: Excellent !
        
        Posté par windu.2b le 14 mai 2013 à 19:57. Évalué à 6.
        
        si tu veux juste agiter tes jambes, je te conseille plutôt le tapis roulant dans une salle de sport (ou les escalators à contre sens dans le métro si t'es radin).
        
        Et le plaisir de se promener (à pied ou à vélo) sans véritable but précis, si ce n'est celui de découvrir des paysages, alors ?!?
        
        [^] # Re: Excellent !
        
        Posté par cedric le 15 mai 2013 à 03:11. Évalué à 2.
        
        Je parle de randonnee ici, avec sac a dos, tente or refuge ! Ca donne de tres belle vue, mais il vaut mieux planifier un rien son itineraire quand meme :-)
        
        [^] # Re: Excellent !
        
        Posté par ckyl le 15 mai 2013 à 08:34. Évalué à 4.
        
        Donc tu as des points de passage obligés à une côte donnée… Le routage est trivial en rando. L'échelle des distances est petite, le maillage du réseau est faible, tu n'enmagasines pas d'ennergie, les frotements sont toujours les mêmes et il faut que ca monte méchament pour que ca commence à faire une différence. Tu ne vas pas faire 2km de plus pour éviter une légère côte ca n'a pas de sens.
        
        Bref ca peut éventuellement valoir le coup de faire quelques kilomètres de plus pour épargner quelques centaines de mettre de D+/-. Mais dans la vraie ce genre de config ca n'existe que peu et c'est trivial à détecter en regardant la carte.
        
        Plutôt qu'un soft, pour ce genre d'activité j'ai envie de dire que c'est plus sur d'apprendre à réellement lire les cartes.
- [^] # Re: Excellent !
  
  Posté par Anonyme le 14 mai 2013 à 09:28. Évalué à 3.
  
  ce qui me rend un peu triste c'est que c'est OSM est nécessaire car l'IGN ce sont des bras cassé :(, je justifie bras cassé par le document 7-ign.pdf de la cours des comptes. A ne pas lire si vous êtes sensibles, il est assez cours et très lisible.
  
  A titre informatif l'IGN à un budget de 150 millions d'euros. dont 70 donné par l’état. Bon il arrive pas trop mal a monnayé leurs donné, mais bon. une licence un peu libre pour nos données payé a 50% serait intéressant.
  - [^] # Re: Excellent !
    
    Posté par Nicolas Casanova le 14 mai 2013 à 11:04. Évalué à 5.
    
    ce qui me rend un peu triste c'est que c'est OSM est nécessaire car l'IGN ce sont des bras cassé :(, je justifie bras cassé par le document 7-ign.pdf de la cours des comptes. A ne pas lire si vous êtes sensibles, il est assez cours et très lisible.
    
    Comme j'ai mis un peu de temps à retrouver le document en question, je colle le lien ici, des fois que ça en intéresserait d'autres que moi : http://www.ccomptes.fr/content/download/1139/11093/version/1/file/7-IGN.pdf
    - [^] # Re: Excellent !
      
      Posté par Jean Roc Morreale le 14 mai 2013 à 14:13. Évalué à 7.
      
      La tutelle administrative demande à l'IGN de pourvoir à son financement en vendant ses services/données tout en assurant une mission de service publique (cas du RGE), l'idée étant que l'organisme arrive tout seul à financer ses missions d'intérêt général sans que ça ponctionne le budget des ministères. Logique implacable.
      
      Le résultat est une impossible équation public/privé mise en évidence dès la première page de ce rapport. La même logique est appliquée à d'autres organismes (BRGM, INRAP, etc;) avec des résultats similaires.
      
      Quant à la compétence des chercheurs, topographes, géographes, etc., elle n'est mise nulle part en doute dans ce rapport. Ou par quiconque connaissant leur travail (celui du COGIT, MATIS, etc.).
      - [^] # Re: Excellent !
        
        Posté par Anonyme le 14 mai 2013 à 18:47. Évalué à 0.
        
        je disconvient, apparemment d'après le rapport le personnel administratif en sur-sur-effectif ne sait pas ouvrir une enveloppe, a moins qu'en attendant suffisamment longtemps elle s'ouvre toutes seule.
      - [^] # Re: Excellent !
        
        Posté par calandoa le 14 mai 2013 à 20:07. Évalué à 10.
        
        Et qu'avons nous au final ? Des citoyens qui s'organisent pour payer un organisme qui va cartographier leur pays, mais comme on leur refuse une utilisation avancée des données, ben ils doivent se réorganiser pour le cartographier eux même. Désolé, mais on marche complètement sur la tête… On cumule les désavantages du privé et du public.
        
        Quant aux compétences techniques, le débat n'est pas là. La qualité des cartes IGN est excellente (sans comparaison avec les qq autres pays où j'ai déjà acheté des cartes), malheureusement on ne peut rien en faire à part les acheter sous forme papier ou les consulter sur geoportail. Quand on voit l'évolution de Google Maps ou OSM à coté, c'est un beau gachis.
- [^] # Re: Excellent !
  
  Posté par jben le 14 mai 2013 à 20:59. Évalué à 5.
  - Est-ce qu'il serait possible d'en faire une version offline en recuperant juste la base de donnees Postgresql par exemple ? En gros, ton serveur Postgresql consomme combien de ram ? Et quel est la puissance processeur minimal necessaire pour resoudre un itineraire ?
  Oui mais il faut avoir de la RAM (ou un SSD pour avoir des accès rapide).
  
  Au doigt mouillé, je dirais que ça doit pouvoir tourner avec 30 GiB de SSD et 4 GiB de RAM, en cas de HDD je dirai au minimum 16 de RAM.
  - [^] # Re: Excellent !
    
    Posté par Nonolapéro le 14 mai 2013 à 23:31. Évalué à 2.
    
    rv utilise-t-il l'intégralité de la base de données OSM ou seulement une extraction des routes et du découpage administratif ? Je me dis que pour lui les landuses (forêts, champ, etc.) ou les bâtiments ne doivent pas être bien utiles.
    - [^] # Re: Excellent !
      
      Posté par jben le 15 mai 2013 à 00:12. Évalué à 3. Dernière modification le 15 mai 2013 à 00:13.
      Pour être précis dans la base il y a :
      
      les données classiques d'osm (donc avec le tout le reste),
      
      des tables contenant des infos utiles au routage (en particulier une table de nœuds avec l'altitude précalculés et la composante connexe précalculée, et une table d'arrete) donc que sur les données utiles,
      
      Pour le routage, seul le second type de données est utilisé. L'avantage de ce système c'est que osmosis met à jour tout seul comme un grand les données classiques puis lance au sein de la même transaction la procédure qui répercute ces changements sur les tables contenant les données utiles.
      
      Pour rester dans la question initiale, pour faire une utilisation hors-ligne on aurait besoin que des tables contenant les données utiles. Et de manière paralelle on peut garder l'ensemble pour pouvoir les mettre à jour sur une autre machine.
- [^] # Re: Excellent !
  
  Posté par jben le 14 mai 2013 à 21:07. Évalué à 4.
  
  J'ai oublié un point dans mon commentaire précedent :
  
  Et tu aurais la meme chose en stock pour la randonnee ? :-)
  
  Le problème de la rando pietonne, sauf si j'ai mal compris le principe, c'est que le bipède n'accumule pas d'énérgie cinétique en descente. Mais un minimisation du dénivelé totale positif rencontré est possible (et réalisé par le backend en C++, mais non prévue par le binding python).
# Cycle Streets

Posté par MrLapinot (site web personnel) le 14 mai 2013 à 09:24. Évalué à 10.

Un site absolument exceptionnel qui fait la même chose, mais pour le Royaume-Uni :

http://www.cyclestreets.net/

Ça pourrait donner des idées d'interface, voire échanger avec eux. Notamment, les utilisateurs qui contribuent des photos des itinéraires. Ils ont aussi une documentation très détaillée qui décrit les algos utilisés : http://cambridge.cyclestreets.net/journey/help/howitworks/ et http://cambridge.cyclestreets.net/journey/help/routing/ par exemple.
- [^] # Re: Cycle Streets
  
  Posté par jben le 14 mai 2013 à 21:00. Évalué à 5. Dernière modification le 14 mai 2013 à 21:00.
  
  Merci de l'info, je ne connaissais pas. La doc est interessante.
# Trop de changements de direction

Posté par Nicolas Dumoulin (site web personnel) le 14 mai 2013 à 09:35. Évalué à 3.

Je viens de faire un test sur mon itinéraire domicile-travail, et si le départ est excellent, la deuxième moitié cherche trop à prendre des petits chemins alors que la rue n'est pas passante, ce qui produit pas mal de changement de direction et notament sur des carrefours pas évidents. Concrètement :
- départ "Avenue de l'Europe, Beaumont, Clermont-Ferrand" en prenant le point qui est à l'ouest
- arrivé "Irstea, Aubière" (oui, ça fait pas très loin ;-) )

Et donc le soucis est avant d'arriver au stadium (en vert), après avoir traversé l'avenue Jean Noëllet (secondary, en orange). Je préfère continuer sur la rue du docteur Mercier car il n'y a personne et que c'est plus facile pour tourner à droite (plateau traversant sur l'intersection avec la rue Pasteur présent dans la base) qu'en sortant du chemin un peu plus haut.

Pareil après le traversée du stadium, le zig-zag dans les parking n'est pas génial. En pratique, soit je reste sur l'avenue Blaise Pascal, soit je rentre sur le parking dès le début, mais je préfère le tout droit.

Voilà, j'espère que tu auras pu suivre les détails et que ça t'intéressera.
En tout cas beau boulot et surtout belles explications.

Pour le frontend, est-ce que tu (ou ceux qui le feront) ne pourrait pas reprendre le code de opensnowmap ou bien d'osrm comme base ?
- [^] # Re: Trop de changements de direction
  
  Posté par Julien L. le 14 mai 2013 à 11:20. Évalué à 1.
  
  C'est certainement dû à ce choix:
  
  La route est droite est sans arrêts
  
  Comme il n'y a aucun moyen de savoir si un virage entraîne un freinage et donc une perte d'énergie, à moins d'utiliser des heuristiques qui en fonction de l'angle >prennent une décision, il n'y aura pas de perte d'énergie. Le modèle fonctionne donc comme si la route était droite. Pour information, j'ai essayé quelques >heuristiques sur des trajets que je connaissais, sans résultats conformes à la réalité.
  
  Mais il est vrai qu'en ville les virages (ou peut être plutôt virage à une intersections) sont souvent synonymes de perte de vitesse et donc d'un besoin d'énergie supplémentaire pour "relancer la machine".
  Peut être y aurait-il moyen avec le modèle de pondérer l'effort en fonction des changements de direction nécessaires (à faire varier en fonction de la courbe, serrée ou pas.
  
  Je suis sûr que jben y a pensé (avec tout le temps passé sur ce projet), peut être qu'en pratique ce n'est pas faisable, ou le modèle moins adapté a la ville?
  - [^] # Re: Trop de changements de direction
    
    Posté par jben le 14 mai 2013 à 21:20. Évalué à 3.
    
    Ça serait faisable. Mais des essai m'ont montré sur des routes que je connais, qu'il y aurait trop de faux-positifs, qu'il détecterai une perte d'energie là où il y en a pas. Le problème, c'est qu'à des endroits le mapping des virages est grossier, et c'est ce qui pose problème.
    
    J'ai donc décider de le pas considerer de perte d'energie dans les virages au lieu d'en considerer trop. C'est un choix que j'ai fait (et qui me semblait le meilleur).
  - [^] # Re: Trop de changements de direction
    
    Posté par Joris Dedieu (site web personnel) le 15 mai 2013 à 09:55. Évalué à 2.
    
    Peut être y aurait-il moyen avec le modèle de pondérer l'effort en fonction des changements de direction nécessaires
    
    Cela ne peut pas se régler plus simplement en permettant à l'utilisateur de pondérer chaque route / carrefour / trajet en fonction de sa cyclofrienditude. Ça évite de complexifier l'algo outre mesure tout en tenant compte à la marge de l’expérience des utilisateurs. En plus ça rajoute un aspect participatif.
    - [^] # Re: Trop de changements de direction
      
      Posté par jben le 15 mai 2013 à 10:16. Évalué à 2.
      Il y a deux problèmes à ta proposition :
      
      Comment choisir la pondération ? Actuellement je travaille avec un modèle physique et justifié, et je ne sais pas comment justifier une telle pondération, excepté dans la résistance au roulement, comme je l'ai déjà indiqué. Mais je ne sais pas si c'est justifié. Une autre approche serait d'introduire une valeur de plaisir qui serait une combinaison de l'energie et du type de route, le problème c'est que je n'ai rien pour justifier une telle variable. Je continue à réflechir dessus dans mes rares temps libres.
      
      Pour le participatif j'y crois pas trop à court et à moyen terme. Il faudrait avoir des infos sur l'intégralité de la carte pour que ce soit interessant. Je pense qu'il vaut mieux utiliser les tags osm dédiés et inviter les gens à participer à osm.
- [^] # Re: Trop de changements de direction
  
  Posté par reno le 14 mai 2013 à 12:06. Évalué à 5.
  
  Oui, il manque une minimisation du nombre de traversée de route ce qui permettrait de diminuer le risque..
  - [^] # Re: Trop de changements de direction
    
    Posté par jben le 14 mai 2013 à 21:17. Évalué à 3.
    
    Très difficile à faire dans mon modèle actuel. À quelle énergie ça correspond de traverser une route ? Par contre je pense mettre un coef de roulement different en fonction des routes (enfin proposer en parametres des coefs de roulements différents).
    - [^] # Re: Trop de changements de direction
      
      Posté par JoeBar le 16 mai 2013 à 22:18. Évalué à 5.
      
      J'ai l'impression que dans les données tu peux avoir les feux rouges… malgré tout, que tu les grilles ou pas, tu es obligé de ralentir à chaque feu rouge. Et comme statistiquement on ne peut pas les avoir tous verts, j'imagine qu'on peut simuler un redémarrage complet à par exemple la moitié des feux rouges, ce qui tendrait à minimiser le nombre de feux. Et on peut mettre un redémarrage pour les stops et les cedez-le passage, d'ailleurs. Qu'en penses-tu ?
      
      Ah, j'ajoute que je suis absolument séduit par ton idée ; je travaille moi-même dans le domaine du SIG et bien que ça fasse longtemps que je cherche un site qui fait ça, je ne me suis jamais lancé dans le codage moi-même. En général pour mon routage (car bien sûr je suis aussi un cycliste exclusif, utilitaire comme toi) j'utilise souvent le site http://bikeroutetoaster.com/Course.aspx Un grand bravo, et je suis impatient de voir ça avancer ! Je proposerais presque d'aider aussi, mais en ce moment je ne pense pas pouvoir prendre ce temps, donc je ne fais pas de promesse en l'air.
- [^] # Re: Trop de changements de direction
  
  Posté par jben le 14 mai 2013 à 21:11. Évalué à 4.
  
  Merci de ton retour.
  
  Pourrais tu me donner les coordonnées (ou des coordonnées équivalente car il serait légitime que tu ne veuilles pas donner les coordonnées de ton domicile et de ton travail) ?
  
  Je regarderai pour voir si par hasard, ce dont je doute, l'algo ne fait pas une erreur par rapport au critère. Et si une amélioration me vient en voyant le problème.
  
  Pour le frontend, est-ce que tu (ou ceux qui le feront) ne pourrait pas reprendre le code de opensnowmap ou bien d'osrm comme base ?
  
  Comme je n'ai pas les compétances, je ne vais rien leur imposer…
  - [^] # Re: Trop de changements de direction
    
    Posté par Nicolas Dumoulin (site web personnel) le 17 mai 2013 à 13:38. Évalué à 2.
    
    J'indique dans mon message comment utiliser les même points que moi. Mais voici des coordonnées qui devraient convenir (un poil modifiées sur le domicile ;-) ) :
    3.0963,45.7525 -> 3.1111,45.7626
# Données altimétriques

Posté par snotling0 le 14 mai 2013 à 10:10. Évalué à 2.

Je me pose la question de savoir si les données SRTM sont fiables / précises à cette échelle, surtout en milieu urbain.
Est-ce qu'il serait pertinent de faire ses propres mesures d'altimétrie pour la voirie qui est recensée dans OSM ?
Je n'ai aucune idée de faisabilité technique par contre.
En utilisant les points de repère de l'IGN et en mesurant simplement la pente, est-ce ça se calculerait ? Ou bien j'ai loupé quelque chose :-)
- [^] # Re: Données altimétriques
  
  Posté par Jean Roc Morreale le 14 mai 2013 à 14:27. Évalué à 3.
  
  Pour les données SRTMv4, l'erreur verticale est inférieure à 16m (elle varie selon les endroits). La résolution (la taille d'un pixel) est de 90m. C'est pourquoi jben a dû recourir à une interpolation.
  - [^] # Re: Données altimétriques
    
    Posté par snotling0 le 15 mai 2013 à 10:37. Évalué à 1.
    
    Donc si je comprends bien l'élévation d'un carré de 90m x 90m est moyenné en 1 seule valeur, avec une précision globale de 16m.
    J'ai du mal à me rendre compte mais ça ne me semble pas super précis pour le cas de ton projet ?
    
    D'où mon questionnement, est-il possible de concevoir un dispositif "à-pas-cher" pour mesurer l'élévation sur le terrain, étant entendu qu'on ne s'intéresse alors "que" à la voirie présente dans OSM ?
    - [^] # Re: Données altimétriques
      
      Posté par Patrick Nicolas le 15 mai 2013 à 13:38. Évalué à 1.
      
      Les mesures d'altitude données par un GPS sont peu fiables. Un altimètre (qui mesure la pression en réalité) donnera une bonne mesure de la variation d'altitude.
      Il faut donc connaître l'altitude du point de départ, et construire le profil le long d'un chemin.
      - [^] # Re: Données altimétriques
        
        Posté par 2PetitsVerres le 16 mai 2013 à 09:06. Évalué à 2.
        
        Les mesures d'altitude données par un GPS sont peu fiables
        
        Ça dépend de l'altitude. Quand le récepteur est à plusieurs centaines/milliers de km d'altitude, ça va. Enfin pas trop haut non plus. Mais en vélo c'est pas facile à atteindre.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Excellent

Posté par MarbolanGos (site web personnel) le 14 mai 2013 à 16:29. Évalué à 5.

Je cherchais récemment un moteur de routage pour le vélo et on peut dire que là c'est du bon ! Juste l'affichage (prévu) du graphique montées/descentes pourrait être pratique.

Sur mon trajet journalier le logiciel donne le bon tracé sauf sur la fin. En fait, il conseille de passer par une rue à très fort trafic alors qu'il existe un passage "conseillé" en vélo (cycleway=designated). Il est vrai que cela ajoute une côte mais pour éviter de se faire écraser c'est plus sûr.

Pour le test aller de Boulevard de Lavéran, Marseille vers Avenue Escadrille Normandie Niémen, Marseille (faculté St Jérôme). Le passage conseillé c'est de prendre par la rue Albert Marquet.

Si il y a un suivi de rapport de bug pour cette application via un github ou autre j'ai pas vu dans la news…
- [^] # Re: Excellent
  
  Posté par jben le 14 mai 2013 à 21:14. Évalué à 3.
  
  Sur mon trajet journalier le logiciel donne le bon tracé sauf sur la fin. En fait, il conseille de passer par une rue à très fort trafic alors qu'il existe un passage "conseillé" en vélo (cycleway=designated). Il est vrai que cela ajoute une côte mais pour éviter de se faire écraser c'est plus sûr.
  
  J'ai des idées pour prendre un compte les pistes cyclables, le plus légitime serait de modifier le coef de roulement en fonction du type de route. Il faut que je teste pour voir si ça donne le résultat attendu.
  
  Si il y a un suivi de rapport de bug pour cette application via un github ou autre j'ai pas vu dans la news…
  
  Non, je ne pensais pas avoir autant de succès… Pour l'instant, les bugs ça sera par mail, mais les remarques que tu viens de faire, je les ai noté ;-). Merci.
# Bravo !

Posté par Lames le 14 mai 2013 à 18:12. Évalué à 4.

Félicitations et Merci !

Juste une petite note pour indiquer que les instructions d'installation sont dans le fichier rv/doc/create_database.md

J'ai repéré une petite coquille dans la section "Ajouts pour rv"

~~psql -d rv -f rv/sql/00-schema.sql~~
devient
psql -d rv -f rv/sql/0.0/00-schema.sql

~~cat rv/sql/10-fonctions-*.sql | psql -d rv~~
devient
cat rv/sql/0.0/10-fonctions-*.sql | psql -d rv
- [^] # Re: Bravo !
  
  Posté par jben le 14 mai 2013 à 21:15. Évalué à 6.
  
  Oh ! Dois-je comprendre que quelqu'un tente un import et une construction de la base, génial !
  
  C'est vrai que j'ai crée des sous dossier pour les versions des shemas. Merci.
  
  Si tu as d'autres retours sur cette doc, je prends avec plaisir, elle a été écrite au fil de l'eau.
  - [^] # Re: Bravo !
    
    Posté par Lames le 15 mai 2013 à 10:28. Évalué à 2.
    
    autre petit détail (coquille)
    
    ~~osmosis --read-pbf file=data/framce.osm.pbf --write-pgsql-dump directory=data/import~~
    osmosis --read-pbf file=data/france.osm.pbf --write-pgsql-dump directory=data/import
    
    Pour aider le projet, une fois que mon installation est ok, je vais la procédurer de manière bien propre.
    
    Je te transmettrais le doc.
  - [^] # Re: Bravo !
    
    Posté par Florent Fourcot le 15 mai 2013 à 14:16. Évalué à 3.
    Autre typo :
```
rv/utils/populate_height_table_parallel \
      data/list_needed_srtm 12 \
       rv/height/rv_populate_height_table dbname=rv data/srtm/
```
    Ça devrait appeller rv/height/populate_height_table.
    
    À la création de la base, il manque aussi un psql -d rv -f rv/sql/0.0/00-schema-rv_heigt.sql (qui provoque une erreur lors du remplissage de la base de donnée).
    
    Le processeur est en train de tourner, on verra bien ce qui en sortira…
# Impressionnant

Posté par Florent Fourcot le 15 mai 2013 à 12:03. Évalué à 2.

Très bon boulot, je pensais à ce genre de services depuis longtemps. Je vais tenter une installation locale à l'occasion, car ton serveur est quand même un peu limité à ne couvrir que la France :-) J'en ai parlé à quelques personnes et c'est le genre de services qui soulèvent de l'enthousiasme.

A priori, rien n'empêche de prendre une autre carte régionale d'OSM à l'import, si je lis bien la documentation dans create_database.md ?
- [^] # Re: Impressionnant
  
  Posté par jben le 15 mai 2013 à 13:21. Évalué à 2.
  
  Merci beaucoup.
  
  A priori, rien n'empêche de prendre une autre carte régionale d'OSM à l'import, si je lis bien la documentation dans create_database.md ?
  
  Non rien ne l'empèche. Par contre ce sont les mise à jour qui seront délicates. En effet pour mettre à jour il faut une source de diffs pour la même région. Et on ne peut pas utiliser extraire d'un diff de planet un diff régional sans passer par la database de planet. Pour la France j'utilise les extractions et les diffs sur les extractions d'OpenStreetMap France.
  - [^] # Re: Impressionnant
    
    Posté par Florent Fourcot le 15 mai 2013 à 14:23. Évalué à 2.
    
    À vue de nez, il faudrait juste que j'adapte ton script de mise à jour pour aller chercher le diff ici : http://download.geofabrik.de/europe/germany/sachsen-updates/ ? (ils n'ont pas de diff toutes les minutes, mais pour une mise à jour journalière ça me semble pas très important).
    - [^] # Re: Impressionnant
      
      Posté par jben le 15 mai 2013 à 14:41. Évalué à 2.
      
      Si ils ont des diffs définis pour la même zone que l'export, ça roule sans problème.
# La mécanique classique est relativiste

Posté par wolowizard le 15 mai 2013 à 15:04. Évalué à 7.

Salut,

Je suis désolé mais en tant que physicien, je vais faire mon chieur:

Le cycliste, même sportif, n'est pas relativiste

Ce qu'on appelle la mécanique classique aka la mécanique newtonienne est relativiste. Elle se base sur la relativité Galiléenne.
La position et la vitesse dépendent d'un référentiel donné, seul le paramètre temps est absolu…

Oui l'équation différentielle n'est pas analytiquement soluble ( notamment à cause du terme en v**2 des forces de frottements fluide)…
Tu supposes toujours un vent de face, c'est bien ça ou tu projettes le vent sur la direction de ta trajectoire?

L'énergie dépensée ne s'extrait pas simplement où alors tu négliges le régime transitoire où l'accélération est non nulle et tu travailles sur le régime permanent…
# Google Maps Navigation pour les itinéraires vélos disponible en France

Posté par thonyo le 27 mai 2013 à 14:51. Évalué à 1.

D'ailleurs Google Maps Navigation fonctionne dorénavant en France avec les itinéraires pour vélos :
Billet du 27/05/2013 sur Google Blog Europe : http://googlepolicyeurope.blogspot.fr/2013/05/bringing-biking-directions-to-more-of.html

Testé et validé pour mes parcours à Lyon ;)
# Y aurait-il un site pour discuter de tout ça?

Posté par gounthar le 19 juin 2013 à 10:45. Évalué à 1. Dernière modification le 02 janvier 2020 à 14:19.
Je viens d'essayer d'installer ce produit sur une Ubuntu, et j'ai des problèmes de base.

J'ai un peu honte.
```
     ./rvpy/rv-launch 
# Hello !
points
# enter points "lon lat" one per line and terminate by "go\n"
3.06488800 50.63735200
2.39710600 51.05117000
go
# cmdline : ['/usr/local/bin/rv_route', '--mass', '70.000000', '--speedref', '20.000000', '--criterion', 'energy', '--scx', '0.450000', '--cr', '0.010000', '--winddir', '0.000000', '--windspeed', '0.000000', '--rho', '1.204000', '--', '3.06488800', '50.63735200 ', '2.39710600', '51.05117000 ']
terminate called after throwing an instance of 'pqxx::broken_connection'
  what():  FATAL:  role "user" does not exist

# init
# searching
# exit: -6
```
Je vois bien qu'il y a un souci avec postgresql, mais j'aimerais changer les infos dans rv, pas dans postgresql.

Merci.
- [^] # Re: Y aurait-il un site pour discuter de tout ça?
  
  Posté par jben le 19 juin 2013 à 14:12. Évalué à 2.
  
  Alors à ta question dans le sujet, non il n'y a pas de site. Par contre il y a un channel irc, #rv@oftc. Je suis aussi joignable sur irc sous le pseudo jben sur entre autres les réseaux oftc et freenode. Je suis également joignable par mail, cf. les sources.
  
  Autrement à la vue de la question que tu poses, je me demande si tu as importé les données necessaires au routage dans la base de donnée.
  - [^] # Re: Y aurait-il un site pour discuter de tout ça?
    
    Posté par gounthar le 20 juin 2013 à 11:52. Évalué à 0.
    
    Non, effectivement, et j'ai avancé depuis.
    
    Par contre, combien de gigas de disque faut-il?
    À l'importation, j'ai rempli les 29G qu'il me restait.
    Merci.

Suivre le flux des commentaires

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