jben a écrit 841 commentaires

  • [^] # Re:C'estlégal

    Posté par  . En réponse au journal lemonde.fr ou l'abonnement au javascript. Évalué à 7.

    En droit le vol est la soustraction frauduleuse de la chose d'autrui. Que tu la rende ou non, ça reste un vol, l'infraction est consitituée.

    Après la subtilité si tu as rendu la voiture, c'est que l'infraction est sans préjudice, mais le vol reste consitué.

  • [^] # Re: notre vie privée n'est pas respectée ?

    Posté par  . En réponse à la dépêche Cozy, un cloud personnel que l'on peut héberger, bidouiller et supprimer. Évalué à 4.

    Non. Te couper les mains pour que tu ne puisses plus envoyer de commentaires sur dlfp serait amplement suffisant.

  • [^] # Re: notre vie privée n'est pas respectée ?

    Posté par  . En réponse à la dépêche Cozy, un cloud personnel que l'on peut héberger, bidouiller et supprimer. Évalué à 3.

    Mais personnellement, je ne vois pas […]

    Merci pour ton avis. Je ne vais pas réagir à ça, il y aurait tellement de choses à en dire, qu'un débat serait utile. Mais vu tes qulités pour stériliser un débat, cela ne me semble guère utile.

    Par contre je réagis à ça (la gaisse est de moi) :

    Disons que si votre disque dans le cloud est crypté, votre vie privée est à peu près respectée.

    Alors pour le premier point, le Dictionnaire de l'Académie française, 9ᵉ édition, exprime :

    • Chiffrement → Voir chiffrage (2).
    • Chiffrage (2) → Action de chiffrer un texte pour en assurer le secret ; résultat de cette action.
    • Chiffrer (3) → Transcrire un texte en langage conventionnel pour en assurer le secret.
    • Déchiffrer (1) → Lire ce qui est écrit en chiffre, selon un code convenu et secret ; traduire en clair.
    • Décrypter → Traduire, mettre en clair un texte chiffré dont on ne possède pas la clef ou le code.
    • Crypter → ∅.

    Si on veut donner un sens à crypter, ça serait chiffrer un message sans connaître la clef.

    Sur le second point, je me permets de réagir, non la vie privée n'est pas respectée par le stockage de données chiffrées, les données chiffrés sont protégées, mais c'est tout. Il existe beaucoup trop de personne qui pensent que chiffrer les données les met à l'abri. C'est le cas seulement si elles ne sont pas disonnibles ailleurs en clair, et si on fait attention à ne pas laisser traîner des données derrière soi.

    Ça me ferait penser à quelqu'un qui dit qu'il est protégé en voiture car il a mis sa ceinture de sécurité, et qui en même temps, peut-être roule sur la neige avec des pneu lisses.

  • [^] # Re: Impressionnant

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. Évalué à 2.

    Si ils ont des diffs définis pour la même zone que l'export, ça roule sans problème.

  • [^] # Re: Impressionnant

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Trop de changements de direction

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Excellent !

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Trop de changements de direction

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Bravo !

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Excellent

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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.

  • [^] # Re: Trop de changements de direction

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Excellent !

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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).

  • [^] # Re: Cycle Streets

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. Évalué à 5. Dernière modification le 14 mai 2013 à 21:00.

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

  • [^] # Re: Excellent !

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Vol

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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…

  • [^] # Re: BRAVO !!!

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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.

  • [^] # Re: Magique !

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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.

  • [^] # Re: Affichage des pentes sur le parcours

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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.

  • [^] # Re: Approximation

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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.

  • # Approximation

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: BRAVO !!!

    Posté par  . En réponse au journal rv, un moteur de recherche d'itinéraire vélo en utilisant les données d'OSM. É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: Mots de passe via HMAC

    Posté par  . En réponse au journal Sécurité des mots de passe. Évalué à 2.

    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.

  • # Mots de passe via HMAC

    Posté par  . En réponse au journal Sécurité des mots de passe. Évalué à 6. Dernière modification le 10 mai 2013 à 14:27.

    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.

  • [^] # Re: Un peu de géometrie voyons !

    Posté par  . En réponse au message Génération de cercles coupés par un nombre croissant de diamètres. Évalué à 7.

    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.