jben a écrit 861 commentaires

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.

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.

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

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

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.

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.

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…

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

Merci de l'info, je ne connaissais pas. La doc est interessante.

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

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…

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.

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.

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.

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.

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.

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.

C'est parfaitement vrai.

Toutefois les avantages de cette methode dépasse cette inconvéniant, c'est à dire méthode de construction du digest éprouvé, flexibilité (sur toutes mes machines) et absence de synchronisation.

Alors je fais avec ce désavantage.

Perso pour générer mes mots de passes j'utilise HMAC tel que décrit dans la RFC2104.

import hashlib
import hmac

class mdp:
    def __init__(self, key, msg):
        self.h = hmac.new(key,msg,hashlib.sha256)

    alphanumspecial = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789<>?,./;\'\\:"|[]{}`-=~!@#$%^&*()_+'
    alphanum = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'
    alpha = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
    num = '0123456789'

    def get(self,length=15,alphabet=alphanum):

        n = int(self.h.hexdigest(),16)

        password = ''

        while(len(password)<length and n>0):
            password += alphabet[n%len(alphabet)]
            n=n//len(alphabet)

        return(password)

J'ai ma clef secrete, que je ne communique à personne, et pour chaque site j'utilise une chaine pour l'identifier, par exemple linuxfr ou servicepublic. Je calcule condensat HMAC (SHA256), puis je décompose ce condensat dans un alphabet et je tronque. Par defaut j'utilise l'alphabet alphanumérique (donc base62), et je tronque à 15 caractères.

Cela se résume en :

from mdp import mdp
mdp('ma_clef','le_service').get()

Si la clef est suffisament forte, cela fait une entropie de 89 bits.

Après dans la vrai vie j'ai une toute petite gui que je lance avec un raccourci clavier, je rentre ma clef et le nom du site, puis je valide et ça me met le mot de passe dans le champ de texte. (Ce code fait appel à celui cité içi, mais il est trop moche pour que je publie ici), et j'ai une version de secours qui s'utilise en ligne de commande sur mon mobile au cas où.

De cette manière, je n'ai aucun soucis de synchronisation d'une quelquonque base de donnée.

Les formules théoriques seules ne me contentent pas, pour moi sans validation empirique quelque chose de logiquement valide est au mieux quelque chose qui n’est pas logiquement impossible et donc éventuellement dénotable dans une performance physique.

Ah ? C'est dommage. En l'occurence, tu poses une question théorique, tu as une réponse théorique. Si tu avais posé une question pratique (par exemple en précisant la taille de ton disque, la distance de l'observateur, etc.) tu aurais pu avoir une réponse pratique. Vu ta question, la seule réponse qu'on puisse t'apporter, c'est en dessus de ce seuil, la théorie dit qu'il y a recouvrement, en dessous il n'y a pas recouvrement.

Aussi pour moi la géométrie ne se fait pas sans figure à l’appui

C'est un des problèmes de l'enseignement. Certain enseignants en construit un dogme de la figure. Les figures sont une aide au raisonnement, mais qu'une aide. Les figures peuvent très bien être mentales, et ça ne pose aucun problème, à charge de chaque interlocuteur d'avoir ses représentations mentales. Et en plus ce qui est génial avec les figures mentales c'est qu'on peut les faire bouger dans tous les sens. De plus je n'avais pas envie de dessiner une figure sur clavier, et chacun a toutes les infos pour la construire.

sinon j’appelle ça de l’algèbre et pas de la géométrie

Ça c'est un autre problème, beaucoup de gens n'ont pas de représentations de l'algebre, alors qu'il est simple et utile de s'en construire. En particulier pour l'algèbre linéaire où des représentations géometriques dans des cas simplifiés (souvent en dimention 2, 3 ou 4 après ça devient difficile) sont souvent appropriés.

je cherche toujours un logiciel qui permet de faire cela assez rapidement

Ça serait pas mal d'expliquer ce que tu cherches.

J'ai pris le temps de reflechir à ton problème, je t'ai apporté des réponses, et tu me dis que je ne réponds pas ce que tu veux, tu me dis que j'aurais du passer du temps à faire une figure, tu exposes non à propos ton aversion d'une discipline scientifique, et pour conclure finalement que tu veux autre chose, mais on ne sait pas toujours quoi. Merci.

Justement, si l'epaisseur n'est pas petite devant le rayon, pour que les traits se touchent il faut appliquer la formule avec l'arctangeante.

Après ça dépend où l'on veut que les trait se touchent. Là j'ai raisonné en voualnt que les trait se touchent completement. Mais si on veut juste qu'ils se croisent sur l'axe, alors on a un sin.

On obtient : α = π / ( 2 arcsin(ᵉ⁄ᵣ) )

Donc pour conclure, nous avons 2 formules exactes :

• n = π / ( 2 arctan(ᵉ⁄ᵣ) ), si l'on veut qu'il se chevauchent jusqu'au bout du trait, (donc ne pas obtenir de "sauts" entre les traits même en dehors du cercle)
• n = π / ( 2 arcsin(ᵉ⁄ᵣ) ), si l'on veut qu'il se chevauchent uniquement sur le disque, même si on a des sauts en dehors, on s'en fout.

Une formule approchée :

• n = (π r) / (2 e)

Et on remarque en effet que si e est petit devant r, alors arcsin(ᵉ⁄ᵣ) ∼ ᵉ⁄ᵣ et arctan(ᵉ⁄ᵣ) ∼ ᵉ⁄ᵣ, et donc les deux formules exactes deviennent équivalentes à la formule approchée.

Autrement dit, quand e est petit devant r, on est en train de sodomiser des drosophiles en plein vol.

Si on nome e la demi-epaisseur (c'est à dire la longueur entre le centre du trait et le bord du trait), r le rayon, et α l'angle entre deux diametres, en se plaçant dans le cas limite où il n'y a aucun espace, on a :

tan(ᵅ⁄₂) = ᵉ⁄ᵣ.

On a donc : α = 2 arctan(ᵉ⁄ᵣ). Sachant que les diametres parcourent un demi angle total, donc π, on a donc le nombre minimal de diametre comme suit :

n = π / (2 arctan(ᵉ⁄ᵣ) ).

C'était pas dur quand même.

je suis sûr à 99% qu'il y a plus de X personnes par m², tu peux affirmer être sûr à 33% qu'il y a plus 400*X personnes par 400m²

Ton raisonnement est spécieux.

Le probleme c'est que si tu dis je suis sûr il y a plus de X personnes dans 1 m² avec une confiance de 99%, alors il y a plus de 400X personnes dans 400m² avec une confiance d'au moins 33%. Tu t'es placé dans le pire des cas. Tu pars du principe que pour avoir 400X personnes dans 400m², il faut avoir X personnes dans chacun des m² composant les 400m².

La subtilité c'est quand tu parles d'une variation de .2 sur ta moyenne, tu ne précise pas de quelle source de variabilité tu parles. En effet tu as deux sources de variabilités. La première c'est la variabilité de ton estimation, elle doit être assez faible si tu estimes sur une surface suffisament grande ; cette variabilité apparaitra dans le resultat final en étant multiplié par la surface totale. La seconde c'est la variabilité intrinsèque au processus, le fait que des zones soit denses ou non, cette variabilité influe sur la première, car plus elle est faible plus il va être facile d'estimer la moyenne, mais elle n'influe par directement dans l'estimation de la population totale.

Mais de plus tout ça, ça necessite une population de m² identiquement distribués (et ça c'est pas gagné), l'indépendance au vu des foules me semble être une hypothèse farfelue, faire des calcul avec ça ne sera pas simple.

Bref je ne suis pas en accord avec le raisonnement simpliste et biaisé de l'auteur du journal, mais je ne peux admettre l'utilisation de raisonnement fallacieux pour le contrer.

Regarde cette photo : ça te paraît exagéré 2 personnes au m2 ?

Au premier plan à coté de la sorte de citroen jumper du PCF (j'ai aucune idée du modèle du vehicule et de sa marque, mais ça semble correspondre). J'estime (au doigt mouillé après rotation de la photo et zoom) qu'il y a 12 personnes dans la surface équivalente situé à la gauche du vehicule (à la gauche par rapport au sens du vehicule). Si on prends les dimentions moyennes du citroen jumper, c'est du 5.4m × 2.7m.

Bref, au doigt mouillé ça fait moins d'une personne par metre carré.

En cherchant des infos sur les densités de foules, je suis tombé sur cette thèse sur l'écoulement de foule (en vrai la modélisation des mouvements de foules).

Même si ça n'apporte rien par rapport au valeur, il s'agit d'une lecture interessente (et il y a des beaux dessins).

Ceci était un commentaire bookmark.