Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Le 03/09/2014 06:29, Art Penteur a écrit : Dans le cas que tu présentes, tu as bien trois points : les lignes que tu traces et qui partent loin sont bien accrochées à un point, quelque part. Donc à chaque angle que tu vois, tu peux bien définir le point du virage, le point avant, le point après. Reste la question du calcul du rayon de courbure. La méthode de base consiste à trouver le centre du cercle passant par les trois points. On le trouve à l'intersection des médiatrices des deux segments avant/après. Puis il suffit de calculer la distance entre ce centre et le point. Sur des points très irrégulièrement espacés, je ne sais pas ce que cette méthode peut donner. Il est aussi possible de calculer la parabole qui passe par les trois points, puis d'appliquer des formules analytique (en dérivée seconde, ...) sur cette parabole. Il est possible que ça donne de meilleurs résultats. Bon courage. Je relève les copies dans une heure. D'ici là, je surveille que vous ne copiez pas sur le voisin, ni sur Internet. D'après moi, il suffit de charger la trace GPX. De la simplifier à 1m Ensuite on calcule l'angle de tous les 3 points consécutifs de la trace On fait la somme des angles positifs consécutifs et des angles négatifs consécutifs et si la somme dépasse un certain seuil (par ex 30°) alors on a un virage. Le total donnerait une bonne approximation du nb de virage total. Art. Le 3 septembre 2014 01:05, Vincent Pottier vpott...@gmail.com a écrit : Le 03/09/2014 00:13, Christian Quest a écrit : Un petit outil pour analyser un GPX, et le compléter par des POI sur les virages... C'est ici: http://forum.openstreetmap.fr/viewtopic.php?f=3t=1443 Hum... Intéressant mais contrairement à ce qui est dit sur le forum, je ne crois pas que ça soit si simple. Je ne suis pas matheux, mais... Compter les virages, ça va. Calculer les rayons de courbure, ça va dépendre de la qualité du tracé. Un exemple : . . . | | x---. Il y a un virage. Mais quelle courbure ? Autre exemple (la route qui croise la voie ferrée) ...-x \ x-... Il y a deux virages repérables, mais quelle courbure ? Il faut au moins trois points pour marquer un virage dont on pourra calculer le rayon de courbure. Avec deux points (angle cassé) il me semble que ça ne suffit pas. Voir aussi le cas de deux virages successifs du même côté : il faut repérer deux minima de rayon de courbure distincts. Je crois aussi que la variation d'azimut entre l'entrée et la sortie du virage est un critère important pour sa force : une épingle à cheveux, c'est un rayon court mais aussi 180° de variation d'azimut. Intéressant à suivre... sur dev, peut-être... -- FrViPofm FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Organisation 10 ans OSM
Bonjour, venant lundi soir, je me posais la question s'il y avait d'autres personnes partant de la région est (est de Paris) pour faire du covoiturage. Perso je partirais de Vitry-le-François soit en voiture soit en train. Et il y a t'il aussi des possibilités de dormir sur Paris si transport trop galère? Bonne journée, Simon ps: je peux donner mon mail et mon 06 sur MP. Pseudo OSM : Simon M ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Le 3 septembre 2014 01:05, Vincent Pottier vpott...@gmail.com a écrit : Le 03/09/2014 00:13, Christian Quest a écrit : Un petit outil pour analyser un GPX, et le compléter par des POI sur les virages... C'est ici: http://forum.openstreetmap.fr/viewtopic.php?f=3t=1443 Hum... Intéressant mais contrairement à ce qui est dit sur le forum, je ne crois pas que ça soit si simple. Je ne suis pas matheux, mais... Compter les virages, ça va. Calculer les rayons de courbure, ça va dépendre de la qualité du tracé. Un exemple : . . . | | x---. Il y a un virage. Mais quelle courbure ? Autre exemple (la route qui croise la voie ferrée) ...-x \ x-... Il y a deux virages repérables, mais quelle courbure ? Il faut au moins trois points pour marquer un virage dont on pourra calculer le rayon de courbure. Avec deux points (angle cassé) il me semble que ça ne suffit pas. Voir aussi le cas de deux virages successifs du même côté : il faut repérer deux minima de rayon de courbure distincts. Je crois aussi que la variation d'azimut entre l'entrée et la sortie du virage est un critère important pour sa force : une épingle à cheveux, c'est un rayon court mais aussi 180° de variation d'azimut. Intéressant à suivre... sur dev, peut-être... Et pourquoi pas un tag : virage=slow virage=gaz virage=gaz-gaz ;-) -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Organisation 10 ans OSM
J'ai de quoi hébergé si besoin. Le 3 septembre 2014 10:06, Simon Miniou simon.min...@gmail.com a écrit : Bonjour, venant lundi soir, je me posais la question s'il y avait d'autres personnes partant de la région est (est de Paris) pour faire du covoiturage. Perso je partirais de Vitry-le-François soit en voiture soit en train. Et il y a t'il aussi des possibilités de dormir sur Paris si transport trop galère? Bonne journée, Simon ps: je peux donner mon mail et mon 06 sur MP. Pseudo OSM : Simon M ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Pot de rentrée local-grenoble le 10 septembre
S'il y a encore des contributeurs de la région grenobloise qui ne sont pas inscrits sur la liste local-grenoble, je fais passer l'info ici : Pour essayer de faire connaissance, les gens disponibles du groupe local iront prendre un verre le mercredi 10 septembre à 18h. Le rendez-vous est pour l'instant fixé au Café le Centenaire, place Notre-Dame. Il vaut mieux tout de même vérifier les derniers messages sur la liste local-grenoble (ou me demander par mail). Tout le monde (contributeurs, sympathisants, curieux...) est le bienvenu ! http://wiki.openstreetmap.org/wiki/Grenoble_groupe_local#Pot_de_rentr.C3.A9e_-_mercredi_10_septembre_2014 -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Le 03/09/2014 06:29, Art Penteur a écrit : Dans le cas que tu présentes, tu as bien trois points : les lignes que tu traces et qui partent loin sont bien accrochées à un point, quelque part. Donc à chaque angle que tu vois, tu peux bien définir le point du virage, le point avant, le point après. Oui, oui, je sais bien. C'est à dessein qu'il n'y avait qu'un point sur le dessin. Reste la question du calcul du rayon de courbure. La méthode de base consiste à trouver le centre du cercle passant par les trois points. On le trouve à l'intersection des médiatrices des deux segments avant/après. Puis il suffit de calculer la distance entre ce centre et le point. Sur des points très irrégulièrement espacés, je ne sais pas ce que cette méthode peut donner. D'où mon premier schéma. Si le premier point, avant le virage, et le dernier, après, sont derrière l'horizon et que les segments traversent les plaines du Nevada sur des kilomètres avant de contourner la cabane drugstore, le calcul de courbure, quelque soit la courbe, cercle, parabole, clothoïde, ne donnera rien de pertinent hormis la variation d'azimut. Il est aussi possible de calculer la parabole qui passe par les trois points, puis d'appliquer des formules analytique (en dérivée seconde, ...) sur cette parabole. Il est possible que ça donne de meilleurs résultats. Bon courage. Je relève les copies dans une heure. D'ici là, je surveille que vous ne copiez pas sur le voisin, ni sur Internet. Dommage : https://fr.wikipedia.org/wiki/Trac%C3%A9_en_plan_%28route%29 -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] arrêt de bus : information, sur handicap cognitif
Bonjour. Je remonte à un sujet que j'ai raté étant en vacances alors, ce n'est que maintenant que j'ai eu le temps de remonter assez loin dans mes mails. L'exemple Grenoblois cité à un moment est de mon œuvre. C'était une ébauche. J'ai dans l'idée un schéma de d’extension du schéma actuel TC. Il n'est pas encore dans sa forme ultime. Voici où j'en suis : * Désambiguïsation du tag plateform Aujourd'hui, plateform peut aussi bien désigner l'abri-bus, un poteau d'arrêt, oui le quai. Avec ma proposition, on séparerait clairement les trois : - tag:public_transport=platform pour un quai - tag:public_transport=pole pour un poteau - tag:amenty=shelter + tag:shelter_type=public_transport pour un abri * Informations données (le tag va à l'objet porteur d'information (abri ou poteau): - time_tables (yes/no) : Les horaires des lignes - waiting_time (theoric/dynamic/no) : Temps d'attente (théorique fait selon la fiche horaire, et dynamique donne le temps réel) - network_map (geographic/schematic/no) : Plan du réseau - line_map (geographic/linear/no) : Plan des lignes pour les plans, géographique correspond à un plan réaliste (on peut s'en servir pour se repérer dans la ville), schématique est un plan simplifié (plan du métro de Paris par ex) et linéaire est plan de ligne themomètre (comme ce que donne overpass api), avec les arrêts. D'autres paramètres peuvent être ajoutés, tels qu'en effet si le nom de l'arrêt est présent, ainsi si la listes des lignes faisant arrêt ici est présente (pour la liste, elles ce sont les relations routes qui s'en chargent) Comme j'ai lu dans la discussion, un préfixe (tel que information) serait pas bête. Aussi, on pourrait ajouter un sufixe, si toutes les lignes ne sont pas traitées de la même façon (exemple : si il y a les horaires de tel réseau, mais pas de tel autre, alors des lignes des deux réseau s'arrêtent ici, on rajoute un :network ) * Les arrêts où le point d'arrêt n'est pas attitré à la ligne. Pour les gare (routières, mais aussi adaptable au ferroviaire), où les bus d'une même ligne ne s'arrêteront pas systématiquement au même quai, je propose une relation public_transport=station avec comme membres : - Les Quais/arrêts/abris/poteaux, avec comme rôle role stop/platform/shelter/pole (suffixés par leur numéro si disponible) - Le(s) Bâtiment(s) (cf carto d'intérieur pr acceuil, caisses, salle d'attente...) - L'endroit où on a l'information de où va s'arrêter notre bus, avec un tag spécial Dans la relation route, le point d'info prendrait la place de l'arrêt. Virgile Kéré - Mail original - Date: Mon, 11 Aug 2014 10:46:01 -0700 (PDT) From: ZIMMY jeanlouis.zimmerm...@laposte.net To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] arrêt de bus : information, sur handicap cognitif Message-ID: 1407779161776-5814271.p...@n5.nabble.com Content-Type: text/plain; charset=UTF-8 J'ai beau chercher je ne trouve pas d'information ni sur le wiki ni dans taginfo permettant de confirmer pour un arrêt de bus la présence de : - carte de quartier ou transport - horaire de passage des bus - présence du nom de l'arrêt - numéro des lignes concernées Mes proposition : display:map=yes/no/bad display:timetable=yes/no/bad display:name=yes/no/bad display:lines=yes/no/bad Qu'en pensez-vous ? Ces informations seront valorisées ici : http://lizpoi.3liz.com/orange/index.php/lizpoi/map/?tree_id=3selected=135 - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (CCPRO,FR84) Mandataire OSM-France sur le Grand-Sud-est ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Le 3 sept. 2014 14:11, Vincent Pottier vpott...@gmail.com a écrit : [...] D'où mon premier schéma. Si le premier point, avant le virage, et le dernier, après, sont derrière l'horizon et que les segments traversent les plaines du Nevada sur des kilomètres avant de contourner la cabane drugstore, le calcul de courbure, quelque soit la courbe, cercle, parabole, clothoïde, ne donnera rien de pertinent hormis la variation d'azimut. De façon très naïve, je pense que si j'avais à coder, sur ce cas je créerais un point fictif sur la ligne droite, à la même distance que celle jusqu'au point suivant, et je m'appuierais sur ce point pour les calculs de rayon. J'imagine que les pros font plutôt une approximation d'un tracé au milieu des points (spline ou autre), et calculent analytiquement le rayon sur cette courbe. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] arrêt de bus : information, sur handicap cognitif
moi qui croyait que platform désignait toute la zone déchange de l'arrêt ou des arrêts de même nom; y co,pris en multimodal... Et donc avait vocation à être une relation avec un polygone englobant contant aussi les oeuds des arrêts de toutes les lignes concernées (y compris bus, métro, tram, ferroviaire, taxi; voire aussi les points de départs des passerelles ou tunnels piétons qui permettent de franchir certains aces et relier les différents arrêts vers l'extérieur de la plateforme) Apès le détail des poteux indicateurs (aux noeuds des arrêts), abris bus, quais, etc... dont déjà dans la plateforme d'échange. En zoomant assez on trouverait aussi d'autres serices autour parmi les POIs (y co,pris les guichets de renseignement ou de vente; les distributeurs de tickets; les panneaux d'affichage. Mais le tout géré comme une plateforme unique. Exception: les zones ferroviaire des gares ou aéroports sont asez grandes pour avoir plusieurs plateformes: on distinguera donc la place devant la gare avec ses arrêts bus de la gare elle(même dans la partie ferroviaire qui peut avoir deux ou trois plateformes parfois (ex. à Paris-Montparnasse/Pasteur entre les gares TGV, la gare banlieue et la station métro situé à lextrimité du tunnel roulant par un tunnel qui n'est pas partie de la plateforme mais fait juste une liaison entre les deux gares passant sous des immeubles hors de la gare. Le 3 septembre 2014 15:02, Virgile Kéré vk...@free.fr a écrit : Bonjour. Je remonte à un sujet que j'ai raté étant en vacances alors, ce n'est que maintenant que j'ai eu le temps de remonter assez loin dans mes mails. L'exemple Grenoblois cité à un moment est de mon œuvre. C'était une ébauche. J'ai dans l'idée un schéma de d’extension du schéma actuel TC. Il n'est pas encore dans sa forme ultime. Voici où j'en suis : * Désambiguïsation du tag plateform Aujourd'hui, plateform peut aussi bien désigner l'abri-bus, un poteau d'arrêt, oui le quai. Avec ma proposition, on séparerait clairement les trois : - tag:public_transport=platform pour un quai - tag:public_transport=pole pour un poteau - tag:amenty=shelter + tag:shelter_type=public_transport pour un abri * Informations données (le tag va à l'objet porteur d'information (abri ou poteau): - time_tables (yes/no) : Les horaires des lignes - waiting_time (theoric/dynamic/no) : Temps d'attente (théorique fait selon la fiche horaire, et dynamique donne le temps réel) - network_map (geographic/schematic/no) : Plan du réseau - line_map (geographic/linear/no) : Plan des lignes pour les plans, géographique correspond à un plan réaliste (on peut s'en servir pour se repérer dans la ville), schématique est un plan simplifié (plan du métro de Paris par ex) et linéaire est plan de ligne themomètre (comme ce que donne overpass api), avec les arrêts. D'autres paramètres peuvent être ajoutés, tels qu'en effet si le nom de l'arrêt est présent, ainsi si la listes des lignes faisant arrêt ici est présente (pour la liste, elles ce sont les relations routes qui s'en chargent) Comme j'ai lu dans la discussion, un préfixe (tel que information) serait pas bête. Aussi, on pourrait ajouter un sufixe, si toutes les lignes ne sont pas traitées de la même façon (exemple : si il y a les horaires de tel réseau, mais pas de tel autre, alors des lignes des deux réseau s'arrêtent ici, on rajoute un :network ) * Les arrêts où le point d'arrêt n'est pas attitré à la ligne. Pour les gare (routières, mais aussi adaptable au ferroviaire), où les bus d'une même ligne ne s'arrêteront pas systématiquement au même quai, je propose une relation public_transport=station avec comme membres : - Les Quais/arrêts/abris/poteaux, avec comme rôle role stop/platform/shelter/pole (suffixés par leur numéro si disponible) - Le(s) Bâtiment(s) (cf carto d'intérieur pr acceuil, caisses, salle d'attente...) - L'endroit où on a l'information de où va s'arrêter notre bus, avec un tag spécial Dans la relation route, le point d'info prendrait la place de l'arrêt. Virgile Kéré - Mail original - Date: Mon, 11 Aug 2014 10:46:01 -0700 (PDT) From: ZIMMY jeanlouis.zimmerm...@laposte.net To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] arrêt de bus : information, sur handicap cognitif Message-ID: 1407779161776-5814271.p...@n5.nabble.com Content-Type: text/plain; charset=UTF-8 J'ai beau chercher je ne trouve pas d'information ni sur le wiki ni dans taginfo permettant de confirmer pour un arrêt de bus la présence de : - carte de quartier ou transport - horaire de passage des bus - présence du nom de l'arrêt - numéro des lignes concernées Mes proposition : display:map=yes/no/bad display:timetable=yes/no/bad display:name=yes/no/bad display:lines=yes/no/bad Qu'en pensez-vous ? Ces informations seront valorisées ici :
Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Le 3 septembre 2014 14:08, Vincent Pottier vpott...@gmail.com a écrit : Le 03/09/2014 06:29, Art Penteur a écrit : Sur des points très irrégulièrement espacés, je ne sais pas ce que cette méthode peut donner. D'où mon premier schéma. Si le premier point, avant le virage, et le dernier, après, sont derrière l'horizon et que les segments traversent les plaines du Nevada sur des kilomètres avant de contourner la cabane drugstore, le calcul de courbure, quelque soit la courbe, cercle, parabole, clothoïde, ne donnera rien de pertinent hormis la variation d'azimut. Les cercles c'est juste pour les rond-points (et encore... pas tous car certains sont ovoïdes). Pour le reste le meilleur tracé c'est la chaînette (pas le clothoïde) qui correspond à un équilibre des forces et simule mieux le comportement au volant pour la prise de virages. https://fr.wikipedia.org/wiki/Chaînette Courbe transcendantale qu'on peut confondre à tord avec une parabole (la parabole n'est valable qu'avec une seule force dont l'orientation est fixe, comme le poid, la chaînette ajoute les forces de tension ou compression longitudinale qui élargissent la bosse de la parabole entre ses deux points de tension fixes aux extrémités). Cette courbe est un cosinus hyperbolique. Si on ajoute une contrainte angulaire aux extrémités (telle que les tangentes afin d'éliminer les angles aux extrémités avec les arcs suivants de chaque coté), on obtient une Bézier, bien plus facile à calculer que la chaînette (c'est la forme de la règle souple métallique qu'on fixe en certains points par des contraintes de placement. Deux types de Bézier: quadratique pour la plus simple ou cubique pour un meilleur résultat. La vraie Bézier physique a un degré infini mais en pratique on s'arrêt au degré 3 qui suffit largement au delà la précision des virages de routes tombe à moins de 10 centimètres dans tous les cas pratique pour des déviations angulaire totale de l'arc inférieure à 45 degrés et une route d'une largeur voisine de 7 à 10 mètres, et une longueur totale de l'arc inférieure à 100 mètres (sinon il suffit ajouter quelques noeuds et tracer des sous-arcs, mais sur une trace GPS, 100 mètres c'est déjà beaucoup et on a en principe deux ou tris points intermédiaires pour une relevé correct; sinon la trace n'est pas utilisable). . ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] arrêt de bus : information, sur handicap
La relation, qui englobe tout, c'est public_transport=stop_area. Public_transport=plateform identifie un lieu où attendent les passagers d'un transport en commun (wiki). Donc, on peut comprendre là l'endroit où tu trouves les infos (abri/poteau), mais aussi l'endroit d'où on monte dans le véhicule (quais)... C'est pourquoi je propose de scinder clairement les deux utilisations. - Mail original - Date: Wed, 3 Sep 2014 15:37:24 +0200 From: Philippe Verdy verd...@wanadoo.fr To: Discussions sur OSM en français talk-fr@openstreetmap.org Subject: Re: [OSM-talk-fr] arrêt de bus : information, sur handicap cognitif Message-ID: CAGa7JC1XLsEzA1x79yeAhT6RY5R=ha4roudncl+tbptarbw...@mail.gmail.com Content-Type: text/plain; charset=utf-8 moi qui croyait que platform désignait toute la zone déchange de l'arrêt ou des arrêts de même nom; y co,pris en multimodal... Et donc avait vocation à être une relation avec un polygone englobant contant aussi les oeuds des arrêts de toutes les lignes concernées (y compris bus, métro, tram, ferroviaire, taxi; voire aussi les points de départs des passerelles ou tunnels piétons qui permettent de franchir certains aces et relier les différents arrêts vers l'extérieur de la plateforme) Apès le détail des poteux indicateurs (aux noeuds des arrêts), abris bus, quais, etc... dont déjà dans la plateforme d'échange. En zoomant assez on trouverait aussi d'autres serices autour parmi les POIs (y co,pris les guichets de renseignement ou de vente; les distributeurs de tickets; les panneaux d'affichage. Mais le tout géré comme une plateforme unique. Exception: les zones ferroviaire des gares ou aéroports sont asez grandes pour avoir plusieurs plateformes: on distinguera donc la place devant la gare avec ses arrêts bus de la gare elle(même dans la partie ferroviaire qui peut avoir deux ou trois plateformes parfois (ex. à Paris-Montparnasse/Pasteur entre les gares TGV, la gare banlieue et la station métro situé à lextrimité du tunnel roulant par un tunnel qui n'est pas partie de la plateforme mais fait juste une liaison entre les deux gares passant sous des immeubles hors de la gare. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] arrêt de bus : information, sur handicap cognitif
2014-09-03 15:02 GMT+02:00 Virgile Kéré vk...@free.fr: * Désambiguïsation du tag plateform Aujourd'hui, plateform peut aussi bien désigner l'abri-bus, un poteau d'arrêt, oui le quai. Avec ma proposition, on séparerait clairement les trois : - tag:public_transport=platform pour un quai - tag:public_transport=pole pour un poteau - tag:amenty=shelter + tag:shelter_type=public_transport pour un abri Je pense que le wiki [1] lève toute ambiguité: The platform can tagged as an node, way or relation. Nodes are used for locations where there is no physical infrastructure (for example a customary bus stop without infrastructure or with a pole), a way for location where a linear area is allocated for people waiting for public transport and an area when a more expansive size is allocated or where different platforms adjoin, such as at in a railway station C'est vrai qu'on ne peut pas déduire qu'un simple noeud est un pole mais il faudrait simplement améliorer la doc actuelle avec un pole=yes par exemple. * Informations données (le tag va à l'objet porteur d'information (abri ou poteau): - time_tables (yes/no) : Les horaires des lignes Regarde cette image: https://pbs.twimg.com/media/BvUsqMEIMAA3VRf.jpg A part strip=yes (à remplacer par road_marking=bus), les autres tags tiennent la route. - waiting_time (theoric/dynamic/no) : Temps d'attente (théorique fait selon la fiche horaire, et dynamique donne le temps réel) Il vaudrait mieux un tag qui indique la présence d'un temps d'attente électronique, le theoric étant déjà précisé par le tag information:time_table (ou time_table) pour les plans, géographique correspond à un plan réaliste (on peut s'en servir pour se repérer dans la ville), schématique est un plan simplifié (plan du métro de Paris par ex) et linéaire est plan de ligne themomètre (comme ce que donne overpass api), avec les arrêts. D'autres paramètres peuvent être ajoutés, tels qu'en effet si le nom de l'arrêt est présent, ainsi si la listes des lignes faisant arrêt ici est présente (pour la liste, elles ce sont les relations routes qui s'en chargent) Faudrait juste vous mettre d'accord. Le mieux est de pousser la discussion sur la liste tagg...@openstreetmap.org pour faire en sorte que le résultat soit mis dans le wiki principal en anglais et utilisé par tout le monde de la même manière. Pour les gare (routières, mais aussi adaptable au ferroviaire), où les bus d'une même ligne ne s'arrêteront pas systématiquement au même quai, je propose une relation public_transport=station avec comme membres : Ca existe déjà mais en polygone simple : http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation Il y a le stop_area pour la relation. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Le saviez-vous ?
J'ai rajouté un petit widget sur le site http://openstreetmap.fr dans la colonne de droite intitulé Le saviez vous ? Son contenu est choisit aléatoirement et indique un chiffre à propos d'OSM: - nombre de nouveaux contributeurs sur la semaine - nombre de cartes personnalisées avec uMap - nombre d'addresses dans BANO - nombre de restaurants, de musées, d'hopitaux, d'écoles... - nombre de lieux pour lesquels l'accessibilité en fauteuil roulant est renseigné etc Je pense ajouter des statistiques sur les serveurs (nombre de tuiles chargés sur nos serveurs par exemple). Si vous avez des idées à proposer, n'hésitez pas. L'idée est de donner un chiffre qui peut étonner, montrer le côté données au delà de la carte trop superficielle... Il faut que l'info soit facilement accessible via une URL. J'utilise par exemple l'API de taginfo ou je charge la page d'accueil d'umap pour extraire le numéro de la dernière carte. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le saviez-vous ?
Le 03/09/2014 18:53, Christian Quest a écrit : J'ai rajouté un petit widget sur le site http://openstreetmap.fr dans la colonne de droite intitulé Le saviez vous ? Son contenu est choisit aléatoirement et indique un chiffre à propos d'OSM: - nombre de nouveaux contributeurs sur la semaine - nombre de cartes personnalisées avec uMap - nombre d'addresses dans BANO - nombre de restaurants, de musées, d'hopitaux, d'écoles... - nombre de lieux pour lesquels l'accessibilité en fauteuil roulant est renseigné marche pô toujours Le saviez-vous ? ** musées ont été cartographiés sur OpenStreetMap en France copier/coller m'a tuer ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le saviez-vous ?
Arghhh... taginfo fr est down... il faut que je branche un cache là dessus Le 3 septembre 2014 20:56, DH dhel...@free.fr a écrit : Le 03/09/2014 18:53, Christian Quest a écrit : J'ai rajouté un petit widget sur le site http://openstreetmap.fr dans la colonne de droite intitulé Le saviez vous ? Son contenu est choisit aléatoirement et indique un chiffre à propos d'OSM: - nombre de nouveaux contributeurs sur la semaine - nombre de cartes personnalisées avec uMap - nombre d'addresses dans BANO - nombre de restaurants, de musées, d'hopitaux, d'écoles... - nombre de lieux pour lesquels l'accessibilité en fauteuil roulant est renseigné marche pô toujours Le saviez-vous ? musées ont été cartographiés sur OpenStreetMap en France copier/coller m'a tuer ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le saviez-vous ?
Le 03/09/2014 18:53, Christian Quest a écrit : J'ai rajouté un petit widget sur le site http://openstreetmap.fr dans la colonne de droite intitulé Le saviez vous ? Son contenu est choisit aléatoirement et indique un chiffre à propos d'OSM: - nombre de nouveaux contributeurs sur la semaine - nombre de cartes personnalisées avec uMap - nombre d'addresses dans BANO - nombre de restaurants, de musées, d'hopitaux, d'écoles... - nombre de lieux pour lesquels l'accessibilité en fauteuil roulant est renseigné etc ... Si vous avez des idées à proposer, n'hésitez pas. L'idée est de donner un chiffre qui peut étonner, montrer le côté données au delà de la carte trop superficielle... nombre d'aérodromes, de bouchers, de bureaux de poste, de pharmacies, de terrains de foot, de tennis (déjà présent), de pistes de cross, de bancs publics, de fontaines, d'œuvres d'art, de monuments classés... Si ça n'est pas trop lourd (il faudra certainement du cache), km d'autoroute, de rivière, de sentier, de piste de ski rouge, verte, bleu..., de ligne de côte, de chemin de fer, de lignes HT... km² de forêts, de prairie... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le saviez-vous ?
Ce sont des chiffres intéressants, mais il faut les précalculer car ça prend beaucoup plus de temps que ce que je récupère en live actuellement. Le 3 septembre 2014 22:05, Vincent Pottier vpott...@gmail.com a écrit : Le 03/09/2014 18:53, Christian Quest a écrit : J'ai rajouté un petit widget sur le site http://openstreetmap.fr dans la colonne de droite intitulé Le saviez vous ? Son contenu est choisit aléatoirement et indique un chiffre à propos d'OSM: - nombre de nouveaux contributeurs sur la semaine - nombre de cartes personnalisées avec uMap - nombre d'addresses dans BANO - nombre de restaurants, de musées, d'hopitaux, d'écoles... - nombre de lieux pour lesquels l'accessibilité en fauteuil roulant est renseigné etc ... Si vous avez des idées à proposer, n'hésitez pas. L'idée est de donner un chiffre qui peut étonner, montrer le côté données au delà de la carte trop superficielle... nombre d'aérodromes, de bouchers, de bureaux de poste, de pharmacies, de terrains de foot, de tennis (déjà présent), de pistes de cross, de bancs publics, de fontaines, d'oeuvres d'art, de monuments classés... Si ça n'est pas trop lourd (il faudra certainement du cache), km d'autoroute, de rivière, de sentier, de piste de ski rouge, verte, bleu..., de ligne de côte, de chemin de fer, de lignes HT... km² de forêts, de prairie... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontre mensuelle OSM-Lyon 09/09/2014 18h30 - Invitation + OdJ
Bonjour à tous Les mappeurs OSM de Lyon se rencontrent régulièrement le 2eme mardi de chaque mois, et chacun peut s'inviter et participer à ces rencontres. La prochaine aura lieu : le MARDI 09 SEPTEMBRE à partir de 18h30 au bistrot CHEZ THIBAULT, 80 rue Montesquieu, 69007 LYON Accès : M° Saxe-Gambetta; C4, C12, C14 Thibaudière; Vélo'V Jaurès/Thibaudière. Le CR de la rencontre précédente se trouve sur la page du Wiki-OSM au lien : http://wiki.openstreetmap.org/wiki/Lyon/Reunion_08_juillet_2014 Si vous souhaitez mettre un sujet particulier à l'ordre du jour, vous pouvez commenter la page préparatoire de la rencontre a venir au lien : http://wiki.openstreetmap.org/wiki/Lyon/Reunion_09_septembre_2014 Venez nombreux ! Amicalement ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le saviez-vous ?
Le 03/09/2014 22:09, Christian Quest a écrit : Ce sont des chiffres intéressants, mais il faut les précalculer car ça prend beaucoup plus de temps que ce que je récupère en live actuellement. Oui, pour les nombre de ..., c'est taginfo qui fait le précalcul, la synthèse. Mais les km de ... ou km² de ..., ils ne sont (n'étaient) pas précalculés pour les état-commune ? De fait, ces synthèses vont être de plus en plus attendues. Les données OSM ne vont pas seulement servir à faire des cartes, aussi jolies soient-elles. Peu à peu OSM va entrer dans le big data. BANO pointe son nez. Les polygones Corine sont redécoupés, explosés : les landuses s'affinent avec une granularité inouïe (bientôt on aura le parcellaire dans OSM). Les tags se diversiffient, c'est à dire que la variété d'objets présents et leur précision sémantique ne cesse de croître. L'histoire de l'outil à compter les virages est symptomatique. On n'imaginait pas que ce type de demande pourrait surgir. J'espère que ça va voir le jour. Ça montrera combien la donnée OSM peut se prêter à des traitements farfelus. Et au passage, ça donnera des critères pour de la précision de tracé de voirie, avec, au passage, un module osmose en plus. Après overpass-turbo, taginfo... il va falloir inventer d’autres api (et moteurs par derrière) pour offrir du digest de données OSM. état-commune c'était un point de départ. J'ai bien quelques idées, un maposmatic de la donnée digérée, mais il se fait tard pour que je développe. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Marrant ! Un géomètre en retraite m'avait parlé de clothoïde, le voisin, qui bosse à la DDE (pardon, on ne dit plus DDE) aussi. Et je retrouve cette même clothoïde sur wikipédia [1]. Heureusement que Philippe est là pour nous dire la véritable vérité vraie sur comment sont tracées les routes. Dans son imagination, je suppose. Parce que là [2] ou là [3], je ne vois pas de chaînette mais des cercles et des clothoïdes. Dis, Philippe. Elle fait comment la chaînette, un virage de 270°, courant dans un échangeur ? La limite d'une chaînette, c'est pas 180° ? [1] https://fr.wikipedia.org/wiki/Trac%C3%A9_en_plan_%28route%29 [2] http://osm.org/go/0A_iMpEU [3] http://osm.org/go/0AuEEiDV-- http://osm.org/go/0DF9YZTE -- FrViPofm Le 03/09/2014 16:03, Philippe Verdy a écrit : Les cercles c'est juste pour les rond-points (et encore... pas tous car certains sont ovoïdes). Pour le reste le meilleur tracé c'est la chaînette (pas le clothoïde) qui correspond à un équilibre des forces et simule mieux le comportement au volant pour la prise de virages. https://fr.wikipedia.org/wiki/Chaînette https://fr.wikipedia.org/wiki/Cha%C3%AEnette Courbe transcendantale qu'on peut confondre à tord avec une parabole (la parabole n'est valable qu'avec une seule force dont l'orientation est fixe, comme le poid, la chaînette ajoute les forces de tension ou compression longitudinale qui élargissent la bosse de la parabole entre ses deux points de tension fixes aux extrémités). Cette courbe est un cosinus hyperbolique. Si on ajoute une contrainte angulaire aux extrémités (telle que les tangentes afin d'éliminer les angles aux extrémités avec les arcs suivants de chaque coté), on obtient une Bézier, bien plus facile à calculer que la chaînette (c'est la forme de la règle souple métallique qu'on fixe en certains points par des contraintes de placement. Deux types de Bézier: quadratique pour la plus simple ou cubique pour un meilleur résultat. La vraie Bézier physique a un degré infini mais en pratique on s'arrêt au degré 3 qui suffit largement au delà la précision des virages de routes tombe à moins de 10 centimètres dans tous les cas pratique pour des déviations angulaire totale de l'arc inférieure à 45 degrés et une route d'une largeur voisine de 7 à 10 mètres, et une longueur totale de l'arc inférieure à 100 mètres (sinon il suffit ajouter quelques noeuds et tracer des sous-arcs, mais sur une trace GPS, 100 mètres c'est déjà beaucoup et on a en principe deux ou tris points intermédiaires pour une relevé correct; sinon la trace n'est pas utilisable). . ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !
On en parlait avec Pierren il y a un moment. OSM integre tres peu de sentier/piste, et ceux qui sont en sous bois ou équivalent sont souvent cartographié depuis l'imagerie ou le cadastre ... deux source vraiment pas fiable pour les sentiers. Pour cet usage, celui de la rando OSM est tres tres loin d'etre suffisant, et ne devrait pas être utilisé tel quel. Et tant qu'on aura pas mobilisé massivement les VTTistes, randonneurs, et autres utilisateur de la campagne, ça devrait peu évoluer tant le travail est immense. Le problème est le meme avec la description physique du terrain, falaise, pierrier etc. on est tres tres tres loin d'IGN Topo... Donc pour le moment en France l'usage d'OSM comme unique outil de préparation de rando est une mauvaise idée généralement. Le 4 septembre 2014 00:05, Pierre Knobel pierr...@gmail.com a écrit : Bonsoir, Je viens signaler que j'ai eu une très mauvaise expérience en montagne aujourd'hui après avoir fait confiance au fond de carte OSM de mon GPS. Je me suis perdu dans une zone de falaises en m'engageant sur la mauvaise vire. J'ai fini par m'en sortir et retrouver le sentier en prenant un gros risque pour escalader un morceau de falaise. Après vérification, le sentier qui était sur OSM avait était purement tracé avec l'imagerie Bing sans trace GPS, si j'en crois le commentaire dans le tag source. Il y a plusieurs problèmes avec l'utilisation de l'imagerie dans ce genre de relief. Pour commencer, on voit plein de sentes sur toutes les vires, toutes ne sont pas accessibles à la randonnée, et souvent on ne les voit que sur une portion et on essaye de les connecter à d'autres portions (et on se trompe). Ensuite on croit deviner des sentiers qui n'en sont pas (bords de falaises, lits de ruisseaux à sec... etc). Et pour finir, l'orthorectification des images est complètement déficiente dans les zones de falaises, vous pouvez essayer de recaler un morceau de sentier visible sur l'imagerie avec une trace GPS, vous verrez que 50 m plus loin ça ne colle déjà plus du tout. Jusqu'à aujourd'hui, j'avais une confiance aveugle dans les données OSM en montagne. De mon expérience, on a soit pas du tout de données dans une zone, soit des données de meilleure qualité que les autres cartes existantes positionnées par des contributeurs qui sont allés sur le terrain avec un GPS. Maintenant je suis vacciné, et j'espère que ma galère n'arrivera pas à quelqu'un d'autre. Ca ne serait pas une bonne pub d'avoir un article de journal sur un gars qui s'est fait récupérer en hélico pour avoir utilisé OSM en fond de carte. Pierre ps : on ne peut pas tout mettre sur le dos de la carte (même si c'est un facteur important dans mon erreur), je suis conscient que j'aurais du faire demi-tour longtemps avant d'être coincé sur ma vire, et ne pas m'engager dans des passages de grimpe que je n'étais pas capable de désécalader en sécurité ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !
Apres il faut voir que dans certains endroit il est tres difficile de tracer les sentiers correctement meme en etant sur le terrain. J avais essaye avec mon GPS de rando au cirque de Saint Meme en Chartreuse la trace faisait n importe quoi. Il faut dire qu a cet endroit la falaise est quasi verticale en forme de fer a cheval et le sentier monte la dedans ainsi qu un petit pas equipe via ferrata. Dans ces conditions meme avec le GPS et les images aeriennes il est tres difficle de realiser un trace correct Julien De : Tetsuo Shima tets...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 4 septembre 2014 0h24 Objet : Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne ! On en parlait avec Pierren il y a un moment. OSM integre tres peu de sentier/piste, et ceux qui sont en sous bois ou équivalent sont souvent cartographié depuis l'imagerie ou le cadastre ... deux source vraiment pas fiable pour les sentiers. Pour cet usage, celui de la rando OSM est tres tres loin d'etre suffisant, et ne devrait pas être utilisé tel quel. Et tant qu'on aura pas mobilisé massivement les VTTistes, randonneurs, et autres utilisateur de la campagne, ça devrait peu évoluer tant le travail est immense. Le problème est le meme avec la description physique du terrain, falaise, pierrier etc. on est tres tres tres loin d'IGN Topo... Donc pour le moment en France l'usage d'OSM comme unique outil de préparation de rando est une mauvaise idée généralement. Le 4 septembre 2014 00:05, Pierre Knobel pierr...@gmail.com a écrit : Bonsoir, Je viens signaler que j'ai eu une très mauvaise expérience en montagne aujourd'hui après avoir fait confiance au fond de carte OSM de mon GPS. Je me suis perdu dans une zone de falaises en m'engageant sur la mauvaise vire. J'ai fini par m'en sortir et retrouver le sentier en prenant un gros risque pour escalader un morceau de falaise. Après vérification, le sentier qui était sur OSM avait était purement tracé avec l'imagerie Bing sans trace GPS, si j'en crois le commentaire dans le tag source. Il y a plusieurs problèmes avec l'utilisation de l'imagerie dans ce genre de relief. Pour commencer, on voit plein de sentes sur toutes les vires, toutes ne sont pas accessibles à la randonnée, et souvent on ne les voit que sur une portion et on essaye de les connecter à d'autres portions (et on se trompe). Ensuite on croit deviner des sentiers qui n'en sont pas (bords de falaises, lits de ruisseaux à sec... etc). Et pour finir, l'orthorectification des images est complètement déficiente dans les zones de falaises, vous pouvez essayer de recaler un morceau de sentier visible sur l'imagerie avec une trace GPS, vous verrez que 50 m plus loin ça ne colle déjà plus du tout. Jusqu'à aujourd'hui, j'avais une confiance aveugle dans les données OSM en montagne. De mon expérience, on a soit pas du tout de données dans une zone, soit des données de meilleure qualité que les autres cartes existantes positionnées par des contributeurs qui sont allés sur le terrain avec un GPS. Maintenant je suis vacciné, et j'espère que ma galère n'arrivera pas à quelqu'un d'autre. Ca ne serait pas une bonne pub d'avoir un article de journal sur un gars qui s'est fait récupérer en hélico pour avoir utilisé OSM en fond de carte. Pierre ps : on ne peut pas tout mettre sur le dos de la carte (même si c'est un facteur important dans mon erreur), je suis conscient que j'aurais du faire demi-tour longtemps avant d'être coincé sur ma vire, et ne pas m'engager dans des passages de grimpe que je n'étais pas capable de désécalader en sécurité ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !
Pour les randonnées de type alpin, type on monte dans la falaise à la verticale, il ne reste plus beaucoup de place pour tracer le sentier en 2d. Peut-êt re faudrait-il réviser la description de l'attribut sac_scale=alpine_hiking pour avertir les téméraires d'être prudents, de s'équiper de cartes spécialisées et de randonner à plusieurs : ) http://wiki.openstreetmap.org/wiki/Key:sac_scale Pierre De : THEVENON Julien julien_theve...@yahoo.fr À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mercredi 3 septembre 2014 18h51 Objet : Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne ! Apres il faut voir que dans certains endroit il est tres difficile de tracer les sentiers correctement meme en etant sur le terrain. J avais essaye avec mon GPS de rando au cirque de Saint Meme en Chartreuse la trace faisait n importe quoi. Il faut dire qu a cet endroit la falaise est quasi verticale en forme de fer a cheval et le sentier monte la dedans ainsi qu un petit pas equipe via ferrata. Dans ces conditions meme avec le GPS et les images aeriennes il est tres difficle de realiser un trace correct Julien De : Tetsuo Shima tets...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Jeudi 4 septembre 2014 0h24 Objet : Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne ! On en parlait avec Pierren il y a un moment. OSM integre tres peu de sentier/piste, et ceux qui sont en sous bois ou équivalent sont souvent cartographié depuis l'imagerie ou le cadastre ... deux source vraiment pas fiable pour les sentiers. Pour cet usage, celui de la rando OSM est tres tres loin d'etre suffisant, et ne devrait pas être utilisé tel quel. Et tant qu'on aura pas mobilisé massivement les VTTistes, randonneurs, et autres utilisateur de la campagne, ça devrait peu évoluer tant le travail est immense. Le problème est le meme avec la description physique du terrain, falaise, pierrier etc. on est tres tres tres loin d'IGN Topo... Donc pour le moment en France l'usage d'OSM comme unique outil de préparation de rando est une mauvaise idée généralement. Le 4 septembre 2014 00:05, Pierre Knobel pierr...@gmail.com a écrit : Bonsoir, Je viens signaler que j'ai eu une très mauvaise expérience en montagne aujourd'hui après avoir fait confiance au fond de carte OSM de mon GPS. Je me suis perdu dans une zone de falaises en m'engageant sur la mauvaise vire. J'ai fini par m'en sortir et retrouver le sentier en prenant un gros risque pour escalader un morceau de falaise. Après vérification, le sentier qui était sur OSM avait était purement tracé avec l'imagerie Bing sans trace GPS, si j'en crois le commentaire dans le tag source. Il y a plusieurs problèmes avec l'utilisation de l'imagerie dans ce genre de relief. Pour commencer, on voit plein de sentes sur toutes les vires, toutes ne sont pas accessibles à la randonnée, et souvent on ne les voit que sur une portion et on essaye de les connecter à d'autres portions (et on se trompe). Ensuite on croit deviner des sentiers qui n'en sont pas (bords de falaises, lits de ruisseaux à sec... etc). Et pour finir, l'orthorectification des images est complètement déficiente dans les zones de falaises, vous pouvez essayer de recaler un morceau de sentier visible sur l'imagerie avec une trace GPS, vous verrez que 50 m plus loin ça ne colle déjà plus du tout. Jusqu'à aujourd'hui, j'avais une confiance aveugle dans les données OSM en montagne. De mon expérience, on a soit pas du tout de données dans une zone, soit des données de meilleure qualité que les autres cartes existantes positionnées par des contributeurs qui sont allés sur le terrain avec un GPS. Maintenant je suis vacciné, et j'espère que ma galère n'arrivera pas à quelqu'un d'autre. Ca ne serait pas une bonne pub d'avoir un article de journal sur un gars qui s'est fait récupérer en hélico pour avoir utilisé OSM en fond de carte. Pierre ps : on ne peut pas tout mettre sur le dos de la carte (même si c'est un facteur important dans mon erreur), je suis conscient que j'aurais du faire demi-tour longtemps avant d'être coincé sur ma vire, et ne pas m'engager dans des passages de grimpe que je n'étais pas capable de désécalader en sécurité ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !
Le 04/09/2014 00:05, Pierre Knobel a écrit : Je viens signaler que j'ai eu une très mauvaise expérience en montagne aujourd'hui après avoir fait confiance au fond de carte OSM de mon GPS. J'ai vécu la même expérience en 2013. Je ne voyais plus aucun chemin de tracé, j'ai donc suivi le tracé sur mon GPS. Sauf que je suis arrivé sur un cul de sac (avec mon vélo le long d'une falaise), impossible de faire demi-tour, j'ai du escalader avec le vélo dans les mains et une belle chute d'au moins 500m. Depuis j'ai rectifié le sentier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un petit challenge pour un codeur-motard (ou l'inverse)
Heureusement que les clothoïdes ne sont pas la réalité la variation linéeaire du rayon de courbure en fonction de la distance parcourue n'a pas de dérivée seconde aux points de raccordement. même s'il y a continuité du rayon de courbure lui-même. Et c'est là le hic de cette courbe qui rend certains virages impraticables et même dangereux. Et cela oublie complètement la compososante du temps et de la variation de vitesse dans cette courbe. Ma clotoïde suppose une vitesse strictement constante; mais alors il y aussi le problème de la distortion en début et fin de vitvirage (et surtout en fin de virage parce qu'à vitesse constante et au point de courbure minimale l'accélération est maximale. Pour éviter ça on peut limiter la force centrifuge par le dévers (changement du plan horizontal) mais tous les virages ne sont pas en dévers non plus car il serait impraticable aussi à vitesse plus lente par exemple pour les cyclistes.qui risquent le dérapage ou la chute.Justement là où l'accélération est maximale et le dévers aussi. Résultat: on a des routes tracés comme ça où tout le monde coupe une partie du virage et sort de sa voie (ou ,ort sur les bordures) même à vitesse réglementaire. Et le problème est encore accru avec les véhicules longs au passage du point de plus faible rayon de courbure. Résultat on élargit un peu une voie et on regarde les traces de roulement sur la chaussée: la courbe suivie n'est pas du tout une clothoïde comme dans la théorie trop simpliste. La clothoïde en pratique ne peut marcher que pour des virages de moins de 30 degrés environ; et en pratique uniquement pour les autoroutes et voies ferrées et uniqueent sur des routestracées sur un plan strictement horizontal; et sans variation non plus de la pente, et tenant compte aussi de la variation de vitesse impoée comme une limite de vitesse temporaire avant virage qui n'est pas atteinte toute de suite. C'est inapplicable aux bretelles d'autoroutes et à la plupart des ponts et tunnels courbes. Enfin quand je vois cette phrase absurde de Wikipédia : conserver les contraintes de continuité des tangentes et de progression monotone des courbures (ce que ne permettent pas directement les seuls arcs de Bézier, dont les subdivisions ne respectent même pas la conservation de la continuité des tangentes suite à une simple transformation linéaire non isométrique de leurs points de contrôle interpolés). C'est du n'importe quoi: les arcs de Béziers jointifs connectés pas des tangentes colinéaires gardent leurs tangentes colinéiares avec toute transformation linéaire du plan (isométrique ou pas), et la monotonie de variation de leur courbure. La clothoïde a d'abord eté développée pour les chemins de fer, pas pour les routes, et pas tracée par des moyen mathémtiques mais avec une règle graduée entre deux rayons de courbures prédéfinis. Relis un peu la contrainte de définition de base de la clothoïde: un seul point fixe, et une seule direction tangeant initiale (l'autre extrémité est laissée libre et on ne sait pas où elle va; on fixe juste le point au bout qui correspond à l'accélération maximale qu'on eut supporter au milieu d'un virage mais on ne sait pas où il sera (donc on ne pourra pas y connecter un second arc pour la fin du virage. Pour les virages à tracer ce n'est pas le cas: on a deux points fixes et deux tangentes imposées. Et là c'est bien la chaînette qui marche ! Dans tous les cas qu'on choisisse une clothoïde, une chainette, ou une ellipse pour tracer l'arc, on pourra toujours le décomposer facimement en arcs de Bézier (qui respecte aussi 3 des contraintes des chainettes et les 2 contraintes demandée à la clothoïde), et c'est ce qu'on fait en pratique pour des arcs de moins de 30 degrés environ (d'autant plus facilement avec des Béziercubiques) qui demandent moins de décomposition à précision égale). Les Béziers sont plus faciles à calculer et décomposer par des méthodes purement linéaires, meˆme si ce n'est pas facile à approximer avec un matériel comme une simple corde tendue entre les foyers avec les ellipses. Tout le monde emploie des Béziers aujourdhui... Même pour tracer des cercle (exemple Java, OpenGL...). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Oubliez l'imagerie aérienne pour les sentiers en montagne !
Le probleme c'est pas tant le sentier qui n'est pas exactement au bon endroit ... ce n'est pas tres tres grave dans qu'il y a bien un sentier praticable et qu'il est connecté correctement au reste. Un sentier correctement tracé, correctement connecté, mais qui est décalé de 50m c'est pas bien grave au milieu de nulle part, on a pas forcément besoin de la précision d'un centre ville. Le vrai gros probleme ce sont les sentiers tracés dans OSM qui n'existent pas du tout sur le terrain, ou bien les connections entre sentiers sur OSM, alors que sur le terrain il n'y a pas de connection et souvent meme pas de possibilité de couper a travers champ. Le pire c'est qu'il est très difficile a posteriori de faire le tri dans OSM entre les chemins correctement tracés, et les chemins fantasmés, et que je doute qu'on puisse produire un outil de contrôle qualité a ce propos, sauf a avoir accès au donnée Topo de l'IGN. Pour le moment je considère qu'OSM n'est pas fiable du tout sur ce point - ni exhaustivité, ni qualité -, qu'il ne faut se baser dessus que si on les a tracé/contrôlé soit meme, et je doute que ça puisse se résoudre a court terme tant le travail est immense. Si on ajoute a ca le fait que tout le monde peut se faire un atlas IGN électronique et meme papier en trois coup de cuillère a pot ... on comprend vite le peu d’intérêt qu'on les quelques utilisateurs a participer. Ca plus ceux qui ne veulent pas voir les touristes débouler sur leur sentier favori :) Le 4 septembre 2014 01:13, Nicolas Frery nico...@zoubi.info a écrit : Le 04/09/2014 00:05, Pierre Knobel a écrit : Je viens signaler que j'ai eu une très mauvaise expérience en montagne aujourd'hui après avoir fait confiance au fond de carte OSM de mon GPS. J'ai vécu la même expérience en 2013. Je ne voyais plus aucun chemin de tracé, j'ai donc suivi le tracé sur mon GPS. Sauf que je suis arrivé sur un cul de sac (avec mon vélo le long d'une falaise), impossible de faire demi-tour, j'ai du escalader avec le vélo dans les mains et une belle chute d'au moins 500m. Depuis j'ai rectifié le sentier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Le saviez-vous ?
Le mercredi 3 septembre 2014 22:05:08 Vincent Pottier a écrit : nombre d'aérodromes, de bouchers, de bureaux de poste, de pharmacies, de terrains de foot, de tennis (déjà présent), de pistes de cross, de bancs publics, de fontaines, d'œuvres d'art, de monuments classés... D'autres que j'aimerai afficher, mais je suis pas sûr que la quantité soit si impressionnante - aires de pique-nique : 6000 - parkings à vélo : 5000 - aire de jeux pour enfants : 1 - aire de repos en bord de route : 1000 - cascades : 384 -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
