Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Je ressors le sujet de la naphtaline, parce que j'observe que les localisations sont disponibles sous une nouvelle forme sur le site de l'info routière : http://diffusion-numerique.info-routiere.gouv.fr/description-des-donnees-a15.html Un fichier csv (46285 lignes) millésimé 2012, mis en ligne début avril 2013 http://diffusion-numerique.info-routiere.gouv.fr/IMG/csv/bornage_2012-01-01.csv Un document explicatif http://diffusion-numerique.info-routiere.gouv.fr/IMG/pdf/Referencement_PR_et_bretelles_-120611.pdf Et hors du contexte purement OSM, les données évènementielles semblent être de plus en plus accessibles. Et le format des données est décrit dans ce document : http://diffusion-numerique.info-routiere.gouv.fr/IMG/pdf/Tipi-SD-M2-6-Datex2-120612.pdf Le 9 octobre 2012 16:09, Pierre Béland infosbelas-...@yahoo.fr a écrit : Fabien, j'ai testé ce calque small components.C'est en effet très efficace pour repérer les problèmes de routage. Le calque permet de repérer rapidement les zones à problème. J'ai rapidement repéré deux chemins connectés à un polygone leisure=park plutôt qu'au chemin le croisant. Dans un cas, le polygone se superposait aux chemins, et les masquaient. Pour un contributeur moins expérimenté ou un distrait, il est vite fait de sélectionner le polygone plutôt que le chemin. À ma connaissance, il n'existe pas dans JOSM une feuille de style Routing MapCSS ou une règle de validation qui signale de tels problèmes. Ce serait des ajout intéressants pour repérer à la source ces problèmes Pierre -- *De :* Ab_fab gamma@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org *Envoyé le :* Mardi 9 octobre 2012 5h00 *Objet :* Re: [OSM-talk-fr] Contrôle qualité des axes routiers Quelques nouvelles en provenance d'OSRM, pour le contrôle qualité des itinéraires : http://lists.openstreetmap.org/pipermail/dev/2012-October/025716.html Ce que je comprends, c'est que cela met en évidence des voies desquelles on peut entrer, mais d'où on ne peut pas sortir, à cause de mauvaises connexions avec le reste du réseau routier. Les infos peuvent être consultées sur un calque small components du site osrm http://map.project-osrm.org/, ou bien sur osm inspectorhttp://tools.geofabrik.de/osmi/?view=routing(qui proposait déjà l'analyse des fins de ways très proches mais non connectées à d'autres éléments de voirie) Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 01/10/2012 18:24, Ab_fab a écrit : Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr mailto:cquest@openstreetmap.**fr cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/**wiki/Proposed_features/** Junction#Complex_junction_**relationhttp://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Quelques nouvelles en provenance d'OSRM, pour le contrôle qualité des itinéraires : http://lists.openstreetmap.org/pipermail/dev/2012-October/025716.html Ce que je comprends, c'est que cela met en évidence des voies desquelles on peut entrer, mais d'où on ne peut pas sortir, à cause de mauvaises connexions avec le reste du réseau routier. Les infos peuvent être consultées sur un calque small components du site osrm http://map.project-osrm.org/, ou bien sur osm inspectorhttp://tools.geofabrik.de/osmi/?view=routing(qui proposait déjà l'analyse des fins de ways très proches mais non connectées à d'autres éléments de voirie) Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 01/10/2012 18:24, Ab_fab a écrit : Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr mailto:cquest@openstreetmap.**fr cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/**wiki/Proposed_features/** Junction#Complex_junction_**relationhttp://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
C'est un peu plus clair en regardant le billet du journal suivant : http://www.openstreetmap.org/user/DennisL/diary/17853 Le 9 octobre 2012 11:00, Ab_fab gamma@gmail.com a écrit : Quelques nouvelles en provenance d'OSRM, pour le contrôle qualité des itinéraires : http://lists.openstreetmap.org/pipermail/dev/2012-October/025716.html Ce que je comprends, c'est que cela met en évidence des voies desquelles on peut entrer, mais d'où on ne peut pas sortir, à cause de mauvaises connexions avec le reste du réseau routier. Les infos peuvent être consultées sur un calque small components du site osrm http://map.project-osrm.org/, ou bien sur osm inspectorhttp://tools.geofabrik.de/osmi/?view=routing(qui proposait déjà l'analyse des fins de ways très proches mais non connectées à d'autres éléments de voirie) Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 01/10/2012 18:24, Ab_fab a écrit : Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr mailto:cquest@openstreetmap.**fr cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/**wiki/Proposed_features/** Junction#Complex_junction_**relationhttp://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Fabien, j'ai testé ce calque small components.C'est en effet très efficace pour repérer les problèmes de routage. Le calque permet de repérer rapidement les zones à problème. J'ai rapidement repéré deux chemins connectés à un polygone leisure=park plutôt qu'au chemin le croisant. Dans un cas, le polygone se superposait aux chemins, et les masquaient. Pour un contributeur moins expérimenté ou un distrait, il est vite fait de sélectionner le polygone plutôt que le chemin. À ma connaissance, il n'existe pas dans JOSM une feuille de style Routing MapCSS ou une règle de validation qui signale de tels problèmes. Ce serait des ajout intéressants pour repérer à la source ces problèmes Pierre De : Ab_fab gamma@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mardi 9 octobre 2012 5h00 Objet : Re: [OSM-talk-fr] Contrôle qualité des axes routiers Quelques nouvelles en provenance d'OSRM, pour le contrôle qualité des itinéraires : http://lists.openstreetmap.org/pipermail/dev/2012-October/025716.html Ce que je comprends, c'est que cela met en évidence des voies desquelles on peut entrer, mais d'où on ne peut pas sortir, à cause de mauvaises connexions avec le reste du réseau routier. Les infos peuvent être consultées sur un calque small components du site osrm, ou bien sur osm inspector (qui proposait déjà l'analyse des fins de ways très proches mais non connectées à d'autres éléments de voirie) Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 01/10/2012 18:24, Ab_fab a écrit : Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers: OSRM
J'ai l'impression qu'OSRM ne gère pas bien les chemins fermés avec un area=yes Exemple: http://tools.geofabrik.de/osmi/?view=routinglon=2.45612lat=48.79363zoom=18overlays=islands La place du Maréchal Joffre est en highway=residential+area=yes Cet area=yes est à retirer, mais ne devrait pas gêner le routage, hors les deux rues en sens unique qui arrivent et partent de la place sont marquées comme non connectées... Le 9 octobre 2012 11:00, Ab_fab gamma@gmail.com a écrit : Quelques nouvelles en provenance d'OSRM, pour le contrôle qualité des itinéraires : http://lists.openstreetmap.org/pipermail/dev/2012-October/025716.html Ce que je comprends, c'est que cela met en évidence des voies desquelles on peut entrer, mais d'où on ne peut pas sortir, à cause de mauvaises connexions avec le reste du réseau routier. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 4 octobre 2012 23:59, Marc Sibert m...@sibert.fr a écrit : Le 04/10/2012 11:22, Marc SIBERT a écrit : - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Pas de sélection possible encore. Dodo. A+ -- Marc Sibertmailto:m...@sibert.fr m...@sibert.fr Une petite mise à jour. http://freeroute.fr/tmc/?zoom=12lat=48.86256lon=2.32539layers=B0T Ça devient intéressant : les nœuds TMC sont présents et détaillés. On peut cliquer dessus pour avoir une infobulle détaillée avec un lien JOSM pour y ajouter le nœud. Par contre je n'arrive pas à propager les tags sur le nœud créé dans JOSM, si quelqu'un a une idée ; j'ai déjà RTFM plusieurs fois mais sans succès (doc de JOSM Remotecontrol). tout doux :-) : cliquer sur les sections pour voir les informations qu'elles portent. N'hésitez pas à me faire part de vos commentaires. Si il y a un graphiste dans la salle, je suis preneur de conseils / remarques. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Ce sera intéressant, mais une fois que l'on se sera mis d'accord sur le format des informations à entrer dans la base, c'est à dire définir ce qui est réellement nécessaire et ce qui peut être reconstruit de manière logicielle par exemple : TMC:Point-LCD = 14141 TMC:Type-Code = 1 TMC:SubType-Code = 3 TMC:Type-Name = Intersection TMC:Type-Name:Loc = 0 TMC:SubType-Name = Diffuseur TMC:SubType-Name:Loc = 0 TMC:Segment-LCD = 10301 TMC:PREVNODE = 14140 TMC:NEXTNODE = 47122 TMC:Point-LCD = 14141 Identifiant du point. Pour moi, c'est intéressant TMC:Type-Code = 1 TMC:SubType-Code = 3 TMC:Type-Name = Intersection TMC:Type-Name:Loc = 0 TMC:SubType-Name = Diffuseur TMC:SubType-Name:Loc = 0 5 lignes, pour dire que le point correspond à une intersection, qui est un diffuseur. hmm hmm - TMC:type = 1.3 doit permettre à un logiciel de le déduire TMC:Segment-LCD = 10301 C'est une info importante, mais pas au niveau du point. Plutôt sur la relation représentant l'ensemble du segment. TMC:PREVNODE = 14140 TMC:NEXTNODE = 47122 Là encore, c'est une info qui a du sens, car les tables Alert-C représentent un chaînage. Mais dès lors que l'on a une relation ordonnée représentant le segment, à quoi servent ces informations sur le noeud ? Voila pourquoi les infos que j'ai indiquées sur les deux noeuds osm correspondant à ce point Alert-C sont beaucoup plus dépouillées : Sens Nantes - Rennes http://www.openstreetmap.org/browse/node/1948203861/ Sens Rennes - Nantes http://www.openstreetmap.org/browse/node/1948203859 Si l'on décide de mettre le code correspondant au type de lieu (l'équivalent de TMC:type = 1.3), cela me va Idem pour la révision de la table. Quelque chose qui indiquerait qu'il s'agit de la table en rev 9.1 serait utile, je pense. A part ça, quand on regarde dans les fichiers en .DA2 de l'archive zip de la table des localisants, il y a des informations complémentaires, en particulier le nom en clair des sorties, des aires de repos, ainsi que les coordonnées et les catégories. On peut ouvrir ces fichiers avec un tableur, les colonnes sont délimitées par le nombre de caractères (pas de caractère séparateur) Le 8 octobre 2012 14:10, Marc SIBERT m...@sibert.fr a écrit : Le 4 octobre 2012 23:59, Marc Sibert m...@sibert.fr a écrit : Le 04/10/2012 11:22, Marc SIBERT a écrit : - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Pas de sélection possible encore. Dodo. A+ -- Marc Sibertmailto:m...@sibert.fr m...@sibert.fr Une petite mise à jour. http://freeroute.fr/tmc/?zoom=12lat=48.86256lon=2.32539layers=B0T Ça devient intéressant : les nœuds TMC sont présents et détaillés. On peut cliquer dessus pour avoir une infobulle détaillée avec un lien JOSM pour y ajouter le nœud. Par contre je n'arrive pas à propager les tags sur le nœud créé dans JOSM, si quelqu'un a une idée ; j'ai déjà RTFM plusieurs fois mais sans succès (doc de JOSM Remotecontrol). tout doux :-) : cliquer sur les sections pour voir les informations qu'elles portent. N'hésitez pas à me faire part de vos commentaires. Si il y a un graphiste dans la salle, je suis preneur de conseils / remarques. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 5 octobre 2012 09:37, Eric Sibert courr...@eric.sibert.fr a écrit : - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Si les segments qu'on voit sortent de la base gouvernementale, je trouve que ce n'est pas de très bonne qualité. J'ai pris l'ex N75 passant par le Col de la Croix-Haute : http://freeroute.fr/tmc/?zoom=**11lat=44.5691lon=5.79424**layers=B0Thttp://freeroute.fr/tmc/?zoom=11lat=44.5691lon=5.79424layers=B0T Le segment dans la Drôme est resté en N75 au lieu de passer en départementale. La D93/993 en provenance de l'Ouest ne vient pas se connecter à l'ex N75. Si on part un peu à l'Est jusqu'à la N85, on voit qu'il y a un doublon nationale/départementale au Sud de l'embranchement de l'autoroute. Ils n'ont pas un bugtracker au ministère? ;-) Sinon, ça me montre aussi qu'il y a sans doute des problèmes de référence de route dans OSM. Je vais étudier ça plus en détail :-) Eric Bonjour, Je rebondis sur la notion de retour au producteur. Visiblement déjà et plus tard encore je pense aussi que l'on va trouver de grosses erreurs dans le réseau : Périph sud-parisien : http://freeroute.fr/tmc/?zoom=15lat=48.82245lon=2.30577layers=B0T Dans ma Savoie natale : http://freeroute.fr/tmc/?zoom=13lat=45.53714lon=6.60719layers=B0T Ce serait bien que le producteur les corrige avant qu'on se lance là dedans Un contact, une idée (un lien sur le site original ?) A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 08/10/2012 14:43, Ab_fab a écrit : Ce sera intéressant, mais une fois que l'on se sera mis d'accord sur le format des informations à entrer dans la base, c'est à dire définir ce qui est réellement nécessaire et ce qui peut être reconstruit de manière logicielle par exemple : TMC:Point-LCD = 14141 TMC:Type-Code = 1 TMC:SubType-Code = 3 TMC:Type-Name = Intersection TMC:Type-Name:Loc = 0 TMC:SubType-Name = Diffuseur TMC:SubType-Name:Loc = 0 TMC:Segment-LCD = 10301 TMC:PREVNODE = 14140 TMC:NEXTNODE = 47122 TMC:Point-LCD = 14141 Identifiant du point. Pour moi, c'est intéressant TMC:Type-Code = 1 TMC:SubType-Code = 3 TMC:Type-Name = Intersection TMC:Type-Name:Loc = 0 TMC:SubType-Name = Diffuseur TMC:SubType-Name:Loc = 0 5 lignes, pour dire que le point correspond à une intersection, qui est un diffuseur. hmm hmm - TMC:type = 1.3 A mon avis ce n'est pas la peine de mettre le type du tout. On peut les retrouver sur OSM. De plus les données de Alter-C ne sont pas toujours juste. Les données dans OSM doivent servir à faire le lien avec Alter-C, pas à le remplacer. doit permettre à un logiciel de le déduire TMC:Segment-LCD = 10301 C'est une info importante, mais pas au niveau du point. Plutôt sur la relation représentant l'ensemble du segment. TMC:PREVNODE = 14140 TMC:NEXTNODE = 47122 Là encore, c'est une info qui a du sens, car les tables Alert-C représentent un chaînage. Mais dès lors que l'on a une relation ordonnée représentant le segment, à quoi servent ces informations sur le noeud ? Voila pourquoi les infos que j'ai indiquées sur les deux noeuds osm correspondant à ce point Alert-C sont beaucoup plus dépouillées : Sens Nantes - Rennes http://www.openstreetmap.org/browse/node/1948203861 / Sens Rennes - Nantes http://www.openstreetmap.org/browse/node/1948203859 Si l'on décide de mettre le code correspondant au type de lieu (l'équivalent de TMC:type = 1.3), cela me va Idem pour la révision de la table. Quelque chose qui indiquerait qu'il s'agit de la table en rev 9.1 serait utile, je pense. Oui, il est important de mettre la révision. A part ça, quand on regarde dans les fichiers en .DA2 de l'archive zip de la table des localisants, il y a des informations complémentaires, en particulier le nom en clair des sorties, des aires de repos, ainsi que les coordonnées et les catégories. On peut ouvrir ces fichiers avec un tableur, les colonnes sont délimitées par le nombre de caractères (pas de caractère séparateur) Le 8 octobre 2012 14:10, Marc SIBERT m...@sibert.fr mailto:m...@sibert.fr a écrit : Le 4 octobre 2012 23:59, Marc Sibert m...@sibert.fr mailto:m...@sibert.fr a écrit : Le 04/10/2012 11:22, Marc SIBERT a écrit : - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Pas de sélection possible encore. Dodo. A+ -- Marc Sibert mailto:m...@sibert.fr Une petite mise à jour. http://freeroute.fr/tmc/?zoom=12lat=48.86256lon=2.32539layers=B0T Ça devient intéressant : les nœuds TMC sont présents et détaillés. On peut cliquer dessus pour avoir une infobulle détaillée avec un lien JOSM pour y ajouter le nœud. Par contre je n'arrive pas à propager les tags sur le nœud créé dans JOSM, si quelqu'un a une idée ; j'ai déjà RTFM plusieurs fois mais sans succès (doc de JOSM Remotecontrol). tout doux :-) : cliquer sur les sections pour voir les informations qu'elles portent. N'hésitez pas à me faire part de vos commentaires. Si il y a un graphiste dans la salle, je suis preneur de conseils / remarques. A+ -- Marc Sibert m...@sibert.fr mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 08/10/2012 15:40, Ab_fab a écrit : Pour le cas de la savoie, c'est le chaînage entre les points qui déconne Ils ne sont pas classés dans le bon ordre. Il n'y a pas qu'en Savoie qu'il y a des points dans le désordre. Et aussi de nombreuses ruptures surtout aux changements de départements sur départementales. Ou les segments d'une petite route qui s'arrêtent au carrefour avant la grande route. En plaçant les points TMC convenablement sur l'existant OSM, et en faisant des relations ordonnées des ways constituant un segment, on pourrait (qui sait) à terme générer ce chaînage ... mais sans ce type d'erreur Globalement, les points sont pas mal. Typiquement, moins de 20 m d'erreur. Néanmoins, quelques bugs aussi. À Briançon, un point n'est pas sur le bon rond-point. Le Col de la Madeleine en Savoie est dédoublé. Le point en venant du Sud est bon (33167), celui en venant du Nord est faux (33166). Les deux segments ne sont pas jointifs. Comme par hasard, ce sont deux départementales qui n'ont pas les mêmes références. Col du Glandon, le point est à 500 m du carrefour visé. Tout ça pour dire qu'il va falloir bien réfléchir avant d'intégrer dans OSM avec une étape point qui me paraît assez facile et une étape segment pour laquelle je suis dubitatif. Il faut refaire toute la segmentation ;-) Combien de points? Combien de poly-segments? Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 08/10/2012 14:10, Marc SIBERT a écrit : Par contre je n'arrive pas à propager les tags sur le nœud créé dans JOSM, si quelqu'un a une idée ; j'ai déjà RTFM plusieurs fois mais sans succès (doc de JOSM Remotecontrol). Tu peux regarder les interactions entre ces deux fichiers, je pense que ça couvre le point dont tu parles : https://github.com/vdct/PlaceMaker/blob/master/index.html (ligne 172 notamment) et https://github.com/vdct/PlaceMaker/blob/master/php/importJOSM.php Le 08/10/2012 15:28, Marc SIBERT a écrit : Je rebondis sur la notion de retour au producteur. Visiblement déjà et plus tard encore je pense aussi que l'on va trouver de grosses erreurs dans le réseau : Périph sud-parisien : http://freeroute.fr/tmc/?zoom=15lat=48.82245lon=2.30577layers=B0T Dans ma Savoie natale : http://freeroute.fr/tmc/?zoom=13lat=45.53714lon=6.60719layers=B0T Ce serait bien que le producteur les corrige avant qu'on se lance là dedans Je serais plutôt pour qu'on avance à notre rythme, sans dépendre du rythme du producteur. Le jour où nous sommes prêts pour lancer une intégration, on prend la dernière mouture des localisants, et on note, pour pouvoir les remonter, les erreurs sur cette version. Une interface à la OpenStreetBugs sera(it) pertinente à ce stade. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Hello, D'après mon gmail on en est à 33 questions/réponses sur ce sujet, ça montre qu'il existe au moins une bonne réactivité humaine sur le sujet, non ? Existe-t-il en une telle configuration un outil plus facile à suivre et qui permette de mieux s'organiser que le mail ? Si je regarde le fil des discussions, j'ai l'impression qu'il y a déjà 2 rendus openlayers pour Alert-C ! Loin de moi l'idée de me plaindre de pareille réactivité, c'est juste qu'il me semble que ça serait mieux que, le jour où une personne voudra en faire un troisième, qu'elle sache au moins qu'il y en a déjà deux :-) Le 4 octobre 2012 23:59, Marc Sibert m...@sibert.fr a écrit : Le 04/10/2012 11:22, Marc SIBERT a écrit : - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Pas de sélection possible encore. Dodo. A+ -- Marc Sibertmailto:m...@sibert.fr m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
- établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Si les segments qu'on voit sortent de la base gouvernementale, je trouve que ce n'est pas de très bonne qualité. J'ai pris l'ex N75 passant par le Col de la Croix-Haute : http://freeroute.fr/tmc/?zoom=11lat=44.5691lon=5.79424layers=B0T Le segment dans la Drôme est resté en N75 au lieu de passer en départementale. La D93/993 en provenance de l'Ouest ne vient pas se connecter à l'ex N75. Si on part un peu à l'Est jusqu'à la N85, on voit qu'il y a un doublon nationale/départementale au Sud de l'embranchement de l'autoroute. Ils n'ont pas un bugtracker au ministère? ;-) Sinon, ça me montre aussi qu'il y a sans doute des problèmes de référence de route dans OSM. Je vais étudier ça plus en détail :-) Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Bonjour Ista, Merci pour tes messages. On peut commencer par continuer la discussion sur dev-fr (que j'ai mis en copie), histoire de ne pas envahir la messagerie de ceux que le sujet n'intéresse pas. Pour la synthèse, le wiki est/sera un bon endroit. Je ne crois pas qu'il y ait deux rendus, juste Marc qui a fait évoluer son rendu OpenLayer pour montrer plus d'informations. -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Bonjour, Je tente une synthèse. Il s'agit de réfléchir aux relations possibles entre les données OSM et les informations numériques routières mises à disposition par le gouvernement, avec notamment le travail Datex. Attention qu'il y a un doute concernant la couverture Corse Datex. L'idée d'origine est d'améliorer la qualité du mapping routier OSM français. Cependant, il n'est pas clair que les infos Datex soient de meilleure qualité que celles d'OSM. Ce qui semble sûr, c'est qu'elles sont complémentaires. Nous nous engagerions vers une sorte de collaboration numérique (on parle aussi de croisement), dépassant les notions d'intégration ou importation, pour enrichir les outils construits autour d'OSM, mais pas forcément OSM soi même. Dans OSM, le seul paramètre qui semble acté d'ajouter est l'identifiant Datex, qui semble être définit par les localisants alert-c. Dans cette collaboration, le travail réalisé par les allemands pourra nous inspirer. Voici les idées de projets suggérés : - amélioration qualité des données routières OSM (sur la longueur des tronçons, sur l’exhaustivité des données, par ex), en agissant sur Osmose. - meilleur support des logiciels de navigation routière à partir d'OSM - favoriser l'émergence d'un http://opendata.openstreetmap.fr - meilleur support des notions de carrefour et de noeud routier dans OSM - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Chacune de ces idées a fait l'objet de développements et discussions très riches. S'y reporter. Voici les personnes qui se sont déclarées partantes pour un travail effectif ou un suivi avec intérêt : - Ab_fab gamma@gmail.com - Marc SIBERT m...@sibert.fr - Lionel Gueganton lionel.guegan...@free.fr - Vincent de Chateau-Thierry v...@laposte.net - Frédéric Rodrigo fred.rodr...@gmail.com - votre Modeste Serviteur. Voilà, si je me suis trompé quelque part, pas taper. Le 3 octobre 2012 10:32, Ab_fab gamma@gmail.com a écrit : Un rendu OpenLayers, ce serait super. Peut-on dissocier par la couleur du marqueur les points intermédiaires (1) des points terminaux (2) des routes ? Et également placer les coordonnées du point dans l'infobulle, pour pouvoir la copier / coller dans osrm ? J'ai fait quelques essais entre Nantes et Rennes (N 137). La position initiale du côté de Rennes n'est pas terrible. J'ai tenté un recalage manuel au milieu des voies de circulation pour les points de départ et d'arrivée, mais cela ne change pas grand chose dans l'absolu (distance et durée) pour l'intégralité du parcours. (1) Ceux qui ont une description TMC:PREVNODE **et** une description TMC:NEXTNODE (2) Ceux qui ont une description TMC:PREVNODE **ou** une description TMC:NEXTNODE, mais pas les deux (3) essais sur Rennes-Nantes / Nantes-Rennes Rennes Initial 48.08159,-1.67524 Recalé 48.081103,-1.675042 Nantes Initial 47.26219,-1.58362 Recalé 47.262405,-1.583625 Initial Lien OSRM Dist. Durée Nantes - Rennes http://osrm.at/1rS 96.4 68 Rennes - Nantes http://osrm.at/1rT 96.3 68 Recalé Nantes - Rennes http://osrm.at/1rQ 96.5 68 Rennes - Nantes http://osrm.at/1rR 96.2 68 Le 2 octobre 2012 19:57, Marc Sibert m...@sibert.fr a écrit : Le 02/10/2012 17:48, Frédéric Rodrigo a écrit : Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.**developpement-durable.gouv.fr/** cartelie/voir.do?carte=**ALERTC8et9service=SGhttp://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~**fred/TMC_LCL2OSM-9.1-20121002-** 1.osm.bz2http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Plus sérieusement, je suis sidéré par l'incohérence de ce réseau ! Le manque de jointures entre les way, les nodes en doublons (je suis bien
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 4 octobre 2012 10:48, Ista Pouss ista...@gmail.com a écrit : Bonjour, Je tente une synthèse. ... - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc C'est un brouillon, qui permet la simple visu. A suivre : mise en valeur des route et des nœuds distinctement. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 04/10/2012 10:48, Ista Pouss a écrit : - amélioration qualité des données routières OSM (sur la longueur des tronçons, sur l’exhaustivité des données, par ex), en agissant sur Osmose. - meilleur support des notions de carrefour et de noeud routier dans OSM - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. C'est en cours de finalisation dans Osmose. J'ai ajouté un analyseur qui recherche des éléments décrit dans les points dans OSM et qui signale les manques (par fois je me dit que l'on pourrait aussi signaler des manques dans Alert-C...) Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 4 octobre 2012 11:22, Marc SIBERT m...@sibert.fr a écrit : Le 4 octobre 2012 10:48, Ista Pouss ista...@gmail.com a écrit : Bonjour, Je tente une synthèse. ... - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc C'est un brouillon, qui permet la simple visu. A suivre : mise en valeur des route et des nœuds distinctement. Bonjour, Tu peux utiliser ceci afin de passer la couche Mapquest en noir et blanc http://openlayers.org/dev/examples/osm-grayscale.html A+ Bruno ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Je continue mes cogitations et mes recherches : _ OSRM permet de télécharger une trace GPX de l'itinéraire qu'il a calculé (ainsi qu'un permalink) _ JOSM permet de télécharger les données OSM le long d'une trace GPX Pour le moment, la trace générée par OSRM ne donne rien dans JOSM. Je viens de lire qu'un timestamp doit figurer pour chacun des points pour le chargement dans JOSM, ce qui n'est pas le cas. Il existe un script python pour faire l'ajout automatiquement. Mis à part le côté pratique à titre personnel, est-ce que vous pensez que conserver et mutualiser les traces qui suivent bien les tronçons alert-c a du sens, que l'on vise un import de références Alert-C dans OSM ou pas ? La réponse Ca peut toujours servir est acceptable ;-) Le 3 octobre 2012 10:32, Ab_fab gamma@gmail.com a écrit : Un rendu OpenLayers, ce serait super. Peut-on dissocier par la couleur du marqueur les points intermédiaires (1) des points terminaux (2) des routes ? Et également placer les coordonnées du point dans l'infobulle, pour pouvoir la copier / coller dans osrm ? J'ai fait quelques essais entre Nantes et Rennes (N 137). La position initiale du côté de Rennes n'est pas terrible. J'ai tenté un recalage manuel au milieu des voies de circulation pour les points de départ et d'arrivée, mais cela ne change pas grand chose dans l'absolu (distance et durée) pour l'intégralité du parcours. (1) Ceux qui ont une description TMC:PREVNODE **et** une description TMC:NEXTNODE (2) Ceux qui ont une description TMC:PREVNODE **ou** une description TMC:NEXTNODE, mais pas les deux (3) essais sur Rennes-Nantes / Nantes-Rennes Rennes Initial 48.08159,-1.67524 Recalé 48.081103,-1.675042 Nantes Initial 47.26219,-1.58362 Recalé 47.262405,-1.583625 Initial Lien OSRM Dist. Durée Nantes - Rennes http://osrm.at/1rS 96.4 68 Rennes - Nantes http://osrm.at/1rT 96.3 68 Recalé Nantes - Rennes http://osrm.at/1rQ 96.5 68 Rennes - Nantes http://osrm.at/1rR 96.2 68 Le 2 octobre 2012 19:57, Marc Sibert m...@sibert.fr a écrit : Le 02/10/2012 17:48, Frédéric Rodrigo a écrit : Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.**developpement-durable.gouv.fr/** cartelie/voir.do?carte=**ALERTC8et9service=SGhttp://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~**fred/TMC_LCL2OSM-9.1-20121002-** 1.osm.bz2http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Plus sérieusement, je suis sidéré par l'incohérence de ce réseau ! Le manque de jointures entre les way, les nodes en doublons (je suis bien conscient qu'il s'agit de données originales, pas d'un effet de la transformation en osm). Je me demande comment cela est réellement exploitable dans son utilisation originale ! Ça veut dire aussi que ce ne sera pas facilement directement exploitable, même pour le la simple comparaison car OSM sera, encore cette fois, globalement de bien meilleure qualité (ça fait plaisir). Si c'est ok, je regarde un rendu OpenLayers brut pour commencer puis avec info bulles. Je vous dis quoi. A+ -- Marc Sibert mailto:m...@sibert.fr __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 04/10/2012 11:22, Marc SIBERT a écrit : - établir un rendu OpenLayers d'Alert-C, pour mieux le suivre. Travail en cours : http://freeroute.fr/tmc Une mise à jour ce soir : des couleurs suivant le type de route (A, N ou D), des numéros sur les points. Pas de sélection possible encore. Dodo. A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Un rendu OpenLayers, ce serait super. Peut-on dissocier par la couleur du marqueur les points intermédiaires (1) des points terminaux (2) des routes ? Et également placer les coordonnées du point dans l'infobulle, pour pouvoir la copier / coller dans osrm ? J'ai fait quelques essais entre Nantes et Rennes (N 137). La position initiale du côté de Rennes n'est pas terrible. J'ai tenté un recalage manuel au milieu des voies de circulation pour les points de départ et d'arrivée, mais cela ne change pas grand chose dans l'absolu (distance et durée) pour l'intégralité du parcours. (1) Ceux qui ont une description TMC:PREVNODE **et** une description TMC:NEXTNODE (2) Ceux qui ont une description TMC:PREVNODE **ou** une description TMC:NEXTNODE, mais pas les deux (3) essais sur Rennes-Nantes / Nantes-Rennes Rennes Initial 48.08159,-1.67524 Recalé 48.081103,-1.675042 Nantes Initial 47.26219,-1.58362 Recalé 47.262405,-1.583625 Initial Lien OSRM Dist. Durée Nantes - Rennes http://osrm.at/1rS 96.4 68 Rennes - Nantes http://osrm.at/1rT 96.3 68 Recalé Nantes - Rennes http://osrm.at/1rQ 96.5 68 Rennes - Nantes http://osrm.at/1rR 96.2 68 Le 2 octobre 2012 19:57, Marc Sibert m...@sibert.fr a écrit : Le 02/10/2012 17:48, Frédéric Rodrigo a écrit : Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.**developpement-durable.gouv.fr/** cartelie/voir.do?carte=**ALERTC8et9service=SGhttp://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~**fred/TMC_LCL2OSM-9.1-20121002-**1.osm.bz2http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Plus sérieusement, je suis sidéré par l'incohérence de ce réseau ! Le manque de jointures entre les way, les nodes en doublons (je suis bien conscient qu'il s'agit de données originales, pas d'un effet de la transformation en osm). Je me demande comment cela est réellement exploitable dans son utilisation originale ! Ça veut dire aussi que ce ne sera pas facilement directement exploitable, même pour le la simple comparaison car OSM sera, encore cette fois, globalement de bien meilleure qualité (ça fait plaisir). Si c'est ok, je regarde un rendu OpenLayers brut pour commencer puis avec info bulles. Je vous dis quoi. A+ -- Marc Sibert mailto:m...@sibert.fr __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit : Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Oui Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) Si les itinéraires sont calculés de / vers des points provenant des tables de localisants alert-c (ce qui correspond donc aux segments), ce sera une bonne base. Je suis d'accord avec toi, l'intégration dans la base OSM n'est pas **nécessaire** pour dans le but unique de contrôle qualité. Mais suivre le même référentiel pour la localisation des points et le chaînage des segments, cela sera certainement utile à ceux qui trouveront utile d'intégrer les références dans la base. Ne serait-ce que parce que si intégration il y a, on pourra regrouper plus facilement les ways correspondant à un segment en suivant la trace générée par le moteur de routage. Idem pour la nomenclature. Ce n'est pas facile de comprendre les codes utilisés dans le système des tables de localisants, mais ça me paraît tout de même bien carré. Les matrices origine / destination, ça correspond à ce que l'on trouve dans les atlas routiers, pour le calcul des distances entre villes ? C'est pas mal, mais quand il y a une anomalie sur un long parcours comme Paris Brest, ce n'est pas évident de la localiser avec précision. A l'échelle d'un segment unitaire Alert-C, c'est beaucoup plus simple de remarquer une évolution du kilométrage et ensuite de retrouver à quel endroit il y a un pb. Pour résumer, on peut utiliser les tables pour _ extraire la localisation des points correspondant aux jonctions entre les segments et leur référence _ déterminer les segments unitaires reliant deux points et correspondant à un axe routier réel. On se retrouve avec une batterie de points de départ et de points d'arrivée, sur lesquels on peut faire travailler un moteur de routage comme osrm (sans oublier de le faire travailler dans les deux sens). vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 1 octobre 2012 23:11, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 01/10/2012 18:24, Ab_fab a écrit : Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr mailto:cquest@openstreetmap.**fr cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/**wiki/Proposed_features/** Junction#Complex_junction_**relationhttp://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) Bonjour, Sur le second point, j'aime bien l'idée que TMC aide à mettre en place les matrices sur les parcours les plus importants. Les deux idées peuvent cheminées en parallèle avec une certaine adhérence lors de certaines étapes. mes 0,02 € A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
J'ai peut être raté quelque chose, mais l'export OSM est-il disponible quelque part ? Avant de cherche à voir si tous les segments sont bien routable dans OSM, je me dit qu'il faudrait déjà vérifier que les points et segments existent. Ce premier test peut peut-être être intégré à Osmose. Mais que le bas de la page indique qu'un nouveau schéma (plus simple ?) est au stade de la proposition http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme A regarder en même temps que la page de discussion associée Plus simple je ne sais pas, en plus d'être écrit dans une langue que je connais pas, le schéma font un peu peur ! Mais les allemands on l'avantage d'avoir de l'expérience la dessus. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Le 2 octobre 2012 15:37, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : J'ai peut être raté quelque chose, mais l'export OSM est-il disponible quelque part ? Avant de cherche à voir si tous les segments sont bien routable dans OSM, je me dit qu'il faudrait déjà vérifier que les points et segments existent. Ce premier test peut peut-être être intégré à Osmose. Mais que le bas de la page indique qu'un nouveau schéma (plus simple ?) est au stade de la proposition http://wiki.openstreetmap.org/**wiki/DE:Proposed_features/New_** TMC_schemehttp://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme A regarder en même temps que la page de discussion associée Plus simple je ne sais pas, en plus d'être écrit dans une langue que je connais pas, le schéma font un peu peur ! Mais les allemands on l'avantage d'avoir de l'expérience la dessus. Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Apparemment, le ministère du Développement Durable considère que la Corse n'est pas française... Le 2 octobre 2012 16:05, Ab_fab gamma@gmail.com a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Le 2 octobre 2012 15:37, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : J'ai peut être raté quelque chose, mais l'export OSM est-il disponible quelque part ? Avant de cherche à voir si tous les segments sont bien routable dans OSM, je me dit qu'il faudrait déjà vérifier que les points et segments existent. Ce premier test peut peut-être être intégré à Osmose. Mais que le bas de la page indique qu'un nouveau schéma (plus simple ?) est au stade de la proposition http://wiki.openstreetmap.org/**wiki/DE:Proposed_features/New_** TMC_schemehttp://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme A regarder en même temps que la page de discussion associée Plus simple je ne sais pas, en plus d'être écrit dans une langue que je connais pas, le schéma font un peu peur ! Mais les allemands on l'avantage d'avoir de l'expérience la dessus. Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Oui, le fichier a meilleure allure que ce qui avait été obtenu avec la révision 8.0, où on trouvait pas mal d'aberrations. Merci Frédéric. Le 2 octobre 2012 17:48, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.**developpement-durable.gouv.fr/** cartelie/voir.do?carte=**ALERTC8et9service=SGhttp://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~**fred/TMC_LCL2OSM-9.1-20121002-**1.osm.bz2http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Cool, ce fichier OSM je peus l'importer directement, non ? :-) (désolé pour le bruit) -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 02/10/2012 17:48, Frédéric Rodrigo a écrit : Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Plus sérieusement, je suis sidéré par l'incohérence de ce réseau ! Le manque de jointures entre les way, les nodes en doublons (je suis bien conscient qu'il s'agit de données originales, pas d'un effet de la transformation en osm). Je me demande comment cela est réellement exploitable dans son utilisation originale ! Ça veut dire aussi que ce ne sera pas facilement directement exploitable, même pour le la simple comparaison car OSM sera, encore cette fois, globalement de bien meilleure qualité (ça fait plaisir). Si c'est ok, je regarde un rendu OpenLayers brut pour commencer puis avec info bulles. Je vous dis quoi. A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
il y a des noeuds, des segments et des routes. Les points très proches mais non connectés que j'ai vu font partie de routes distinctes. Idem pour des points en double. Sont-ils à des intersections ? Ils font probablement partie de deux routes distinctes. Quand on regarde les schémas des intersections dans la proposition de tagging, ça a l'air d'être en phase Je ne connais pas assez le schéma pour me permettre d'en dire déjà du mal ;-) Le 2 octobre 2012 19:57, Marc Sibert m...@sibert.fr a écrit : Le 02/10/2012 17:48, Frédéric Rodrigo a écrit : Le 02/10/2012 16:05, Ab_fab a écrit : Il n'y a rien pour le moment en France dans la base osm lié aux localisants alert-C. Quelques essais de conversion effectués sur la révision 8.0 de la table, mais qui n'ont pas été intégrés ensuite. Pour info Il y a une visualisation ici des données de la nouvelle révision 9.2 http://cartelie.application.**developpement-durable.gouv.fr/** cartelie/voir.do?carte=**ALERTC8et9service=SGhttp://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=ALERTC8et9service=SG (on peut voir les différences avec la version 8.0 J'ai l'impression qu'il y a beaucoup de points intermédiaires que l'on ne voyait pas dans la conversion de la table v8.0 en fichier .osm que didier2020 avait utilisée dans une slippy map perso. Ma question portait sur la disponibilité d'un .osm issue de la conversion. Finalement je l'ai fait moi même. Le logiciel à du être amélioré car ça c'est assez bien passé malgré quelques erreurs sur des voie urbaines (TMC:Segment-LCD=999). Voila donc le fichier : http://osm7.openstreetmap.fr/~**fred/TMC_LCL2OSM-9.1-20121002-**1.osm.bz2http://osm7.openstreetmap.fr/~fred/TMC_LCL2OSM-9.1-20121002-1.osm.bz2 Dans un premier temps je propose d'intégrer à Osmose la vérification des points et de leur typologie (fichier SUBTYPES.DAT) : Diffuseur, Rond-point, Carrefour à feux, Pont... Frédéric. __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr Plus sérieusement, je suis sidéré par l'incohérence de ce réseau ! Le manque de jointures entre les way, les nodes en doublons (je suis bien conscient qu'il s'agit de données originales, pas d'un effet de la transformation en osm). Je me demande comment cela est réellement exploitable dans son utilisation originale ! Ça veut dire aussi que ce ne sera pas facilement directement exploitable, même pour le la simple comparaison car OSM sera, encore cette fois, globalement de bien meilleure qualité (ça fait plaisir). Si c'est ok, je regarde un rendu OpenLayers brut pour commencer puis avec info bulles. Je vous dis quoi. A+ -- Marc Sibert mailto:m...@sibert.fr __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 1 octobre 2012 09:21, Ab_fab gamma@gmail.com a écrit : Bonjour, Lors de la soirée parisienne de vendredi, on a évoqué le contrôle qualité des axes routiers, la (probable) nécessité de construire des relations pour gérer tout ça. Depuis, je me suis souvenu d'un de mes TOC non réalisé, à savoir l'intégration des tables de localisants DATEX, liées au système d'info trafic TMC. Hormis le fait de pouvoir à terme servir pour les applications de navigation routière, le maillage du réseau routier en tronçons et points de raccordement devrait pouvoir servir à la vérification des continuités pour le réseau principal, à la manière des outils qui ont été faits pour le suivi de l'avancement des cours d'eau. Les tables de localisants sont disponibles en version 9.2, et le service qui les élabore a donné son accord explicite pour leur usage dans le cadre d'OSM il y a quelques mois. L'archive contenant les tables pour la révision 8.0 inclut une carte qui donne une idée du réseau routier pris en compte (répertoire /Carte) http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v8-0-FR_cle21334c.zip Ce n'est pas pléthorique, mais déjà un premier jalon intéressant, selon moi. Didier2020 avait fait une visualisation en ligne des points et des segments, mais cela me renvoie une erreur 404 Est-ce que le sujet intéresse du monde ? J'initie la discussion sur talk-fr, mais si cela tourne au technique, on pourra basculer sur dev-fr. -- ab_fab Il n'y a pas de pas perdus Salut, Ca me semble une bonne idée. Peut être même que Didier2020 peut mettre son code sur un serveur osm_fr ... Ou nous le passer qu'on l'y mette. Un jour il viendra sur http://opendata.openstreetmap.fr ;-) -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 1 octobre 2012 09:21, Ab_fab gamma@gmail.com a écrit : Bonjour, Lors de la soirée parisienne de vendredi, on a évoqué le contrôle qualité des axes routiers, la (probable) nécessité de construire des relations pour gérer tout ça. Depuis, je me suis souvenu d'un de mes TOC non réalisé, à savoir l'intégration des tables de localisants DATEX, liées au système d'info trafic TMC. Hormis le fait de pouvoir à terme servir pour les applications de navigation routière, le maillage du réseau routier en tronçons et points de raccordement devrait pouvoir servir à la vérification des continuités pour le réseau principal, à la manière des outils qui ont été faits pour le suivi de l'avancement des cours d'eau. Les tables de localisants sont disponibles en version 9.2, et le service qui les élabore a donné son accord explicite pour leur usage dans le cadre d'OSM il y a quelques mois. L'archive contenant les tables pour la révision 8.0 inclut une carte qui donne une idée du réseau routier pris en compte (répertoire /Carte) http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v8-0-FR_cle21334c.zip Ce n'est pas pléthorique, mais déjà un premier jalon intéressant, selon moi. Didier2020 avait fait une visualisation en ligne des points et des segments, mais cela me renvoie une erreur 404 Est-ce que le sujet intéresse du monde ? J'initie la discussion sur talk-fr, mais si cela tourne au technique, on pourra basculer sur dev-fr. -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, J'ai regardé aussi, il y bien longtemps, ces données avec la même idée, en plus de celle ce faire comme les allemands et d'intégrer tous les identifiants dans le réseau OSM français. Je suivrais avec intérêt un Groupe de Travail sur ce sujet. Quelques pistes (mes 0.02 €) : - OSMR Datex : valider les longueurs des tronçons dans OSM en lançant OSMR entre les nœuds du réseau Datex ; - Un outil de rendu en ligne du réseau Datex basé sur OpenLayers. - Une / des page(s) wiki pour le travail de ce groupe. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
attentioLe 1 octobre 2012 09:21, Ab_fab gamma@gmail.com a écrit : Est-ce que le sujet intéresse du monde ? Moi ça m'intéresse, comme contributeur java, si cette techno vous est utile, et comme j'y comprends rien à OSM+TOC+DATEX+TMC+Table de localisant, pour des petites contributions où qu'on me dise ce que je dois faire. Ce qui m'intéresse est tout ce qui aide à la qualité dans les informations. Et attention que mon expérience dans le développement de logiciels libres est nulle. Bref, ça m'intéresse, mais il faut me dire ce que je dois faire. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 1 octobre 2012 10:11, Marc SIBERT m...@sibert.fr a écrit : Le 1 octobre 2012 09:21, Ab_fab gamma@gmail.com a écrit : Bonjour, Lors de la soirée parisienne de vendredi, on a évoqué le contrôle qualité des axes routiers, la (probable) nécessité de construire des relations pour gérer tout ça. Depuis, je me suis souvenu d'un de mes TOC non réalisé, à savoir l'intégration des tables de localisants DATEX, liées au système d'info trafic TMC. Hormis le fait de pouvoir à terme servir pour les applications de navigation routière, le maillage du réseau routier en tronçons et points de raccordement devrait pouvoir servir à la vérification des continuités pour le réseau principal, à la manière des outils qui ont été faits pour le suivi de l'avancement des cours d'eau. Les tables de localisants sont disponibles en version 9.2, et le service qui les élabore a donné son accord explicite pour leur usage dans le cadre d'OSM il y a quelques mois. L'archive contenant les tables pour la révision 8.0 inclut une carte qui donne une idée du réseau routier pris en compte (répertoire /Carte) http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v8-0-FR_cle21334c.zip Ce n'est pas pléthorique, mais déjà un premier jalon intéressant, selon moi. Didier2020 avait fait une visualisation en ligne des points et des segments, mais cela me renvoie une erreur 404 Est-ce que le sujet intéresse du monde ? J'initie la discussion sur talk-fr, mais si cela tourne au technique, on pourra basculer sur dev-fr. -- ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, J'ai regardé aussi, il y bien longtemps, ces données avec la même idée, en plus de celle ce faire comme les allemands et d'intégrer tous les identifiants dans le réseau OSM français. Je suivrais avec intérêt un Groupe de Travail sur ce sujet. Quelques pistes (mes 0.02 €) : - OSMR Datex : valider les longueurs des tronçons dans OSM en lançant OSMR entre les nœuds du réseau Datex ; - Un outil de rendu en ligne du réseau Datex basé sur OpenLayers. - Une / des page(s) wiki pour le travail de ce groupe. Il y a bien une page DATEX sur http://wiki.openstreetmap.org/wiki/FR:Datex faite par Didier2020 en 2011. Un bon début ;-) Cyrille. A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
La base de départ, ce sont les fichiers mis à disposition sur http://diffusion-numerique.info-routiere.gouv.fr/tables-alert-c-a4.html Marcus Wolschon a créé un script java qui est un plugin de son programme traveling salesman http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#Convert_TMC_LoctionCodeList_to_OpenStreetMap Cela mouline les fichiers contenus dans l'archive, pour faire un fichier .osm que l'on peut consulter dans JOSM Après pas mal de tatonnements, j'ai réussi à le faire tourner sur la version 8.0 de la table des localisants, et obtenir un fichier .osm avec tous les segments et les points. didier2020 a réussi également. Désormais la table est en révision 9.2 http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v9-2_cle7bc9d2.zip Là où ça se complique, c'est que les allemands ont élaboré un premier schéma de tags http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema Mais que le bas de la page indique qu'un nouveau schéma (plus simple ?) est au stade de la proposition http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme A regarder en même temps que la page de discussion associée Le 1 octobre 2012 10:13, Ista Pouss ista...@gmail.com a écrit : attentioLe 1 octobre 2012 09:21, Ab_fab gamma@gmail.com a écrit : Est-ce que le sujet intéresse du monde ? Moi ça m'intéresse, comme contributeur java, si cette techno vous est utile, et comme j'y comprends rien à OSM+TOC+DATEX+TMC+Table de localisant, pour des petites contributions où qu'on me dise ce que je dois faire. Ce qui m'intéresse est tout ce qui aide à la qualité dans les informations. Et attention que mon expérience dans le développement de logiciels libres est nulle. Bref, ça m'intéresse, mais il faut me dire ce que je dois faire. Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Ca me semble une très bonne idée de croiser les données OSM avec datex et d'inclure des données datex dans OSM pour assurer un contrôle de qualité et de cohérence par les calculs d'itinéraires. Beaucoup de données externes, même non importables dans OSM peuvent servir au contrôle de qualité et à évaluer l'exhaustivité des données OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 1 octobre 2012 10:35, Ab_fab gamma@gmail.com a écrit : La base de départ, ce sont les fichiers mis à disposition sur http://diffusion-numerique.info-routiere.gouv.fr/tables-alert-c-a4.html Marcus Wolschon a créé un script java qui est un plugin de son programme traveling salesman http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#Convert_TMC_LoctionCodeList_to_OpenStreetMap Cela mouline les fichiers contenus dans l'archive, pour faire un fichier .osm que l'on peut consulter dans JOSM Après pas mal de tatonnements, j'ai réussi à le faire tourner sur la version 8.0 de la table des localisants, et obtenir un fichier .osm avec tous les segments et les points. didier2020 a réussi également. Désormais la table est en révision 9.2 http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v9-2_cle7bc9d2.zip Là où ça se complique, c'est que les allemands ont élaboré un premier schéma de tags http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema Mais que le bas de la page indique qu'un nouveau schéma (plus simple ?) est au stade de la proposition http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme A regarder en même temps que la page de discussion associée Cela y est j'ai tout compris ! Sauf... - Y a-t-il une chose précise, simple, programmable, exprimable en un paragraphe en français, qui soit utile et qui me (nous ? ) permettrait d'avancer en rendant service ? J'ai vu la remarque de Christian Quest : Ca me semble une très bonne idée de croiser les données OSM avec datex et d'inclure des données datex dans OSM pour assurer un contrôle de qualité et de cohérence par les calculs d'itinéraires. ...qui est encourageante, mais qui me parait déjà être une montagne ? - Y a-t-il 1) un groupe de travail ? 2) un projet ? 3) juste un groupe ? 4) Plusieurs groupes et projets ? 5) Rien. Si c'est 5), je suis perdu, je peux rien faire :-) Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
6 : pas encore Là, c'est juste une intuition personnelle. Je cherche à voir si cela parle également à d'autres personnes, au moins dans le principe et voir s'il y a un intérêt à se pencher sur la question. On parle beaucoup d'intégration vs. import, et dans ce cas c'est encore plus fort. Les données brutes ne donnent qu'une trame très grossière, qu'il faudra adapter à la base OSM et sa richesse : par exemple, les intersections entre axes routiers sont de simples points dans les tables de localisants, alors que ce sont des arrangements complexes en réalité (par exemple un échangeur autouroutier). Cela nécessite beaucoup de discussions préalable, et en particulier sur le schéma des descriptions à employer. Le fait d'avoir deux schémas possibles est une première difficulté qui fait qu'il est nécessaire d'arbitrer entre les deux. Les allemands sont avancés sur la question, ils travaillent dessus depuis des années, et vont loin dans les détails (cf. page de discussion sur le nouveau schéma). En obtenant quelques infos de leur part, cela peut permettre d'éviter des pièges. Pour aller plus loin, il faut comprendre le schéma, et ensuite progresser petit à petit jusqu'à trouver un moyen relativement ergonomique pour créer une / des relations de tronçons routier dans OSM, correspondant à un segment TMC. On parlait d'outils spécialisés pour des types précis d'édition, peut-être que là on peut l'envisager : Si l'on commence par placer les noeuds aux intersections stratégiques, peut être qu'ensuite on peut utiliser des outils de routage pour proposer un itinéraire efficace entre deux points, qui risque fort d'être le bon. Il n'y a alors plus qu'à vérifier le tracé proposé et l'ajuster en cas d'erreur. L'étape finale étant la construction de la relation Désolé de ne pas pouvoir te fournir du tout prêt. Le code de Marcus est déjà un bon début pour comprendre comment passer des tables à un fichier osm Noter que le schéma TMC propose aussi des codes pour des zones (surfaces). Là c'est un peu plus simple car la majeure partie suit les limites administratives (par exemple cantonales). Le 1 octobre 2012 13:19, Ista Pouss ista...@gmail.com a écrit : Le 1 octobre 2012 10:35, Ab_fab gamma@gmail.com a écrit : La base de départ, ce sont les fichiers mis à disposition sur http://diffusion-numerique.info-routiere.gouv.fr/tables-alert-c-a4.html Marcus Wolschon a créé un script java qui est un plugin de son programme traveling salesman http://sourceforge.net/apps/mediawiki/travelingsales/index.php?title=Plugin/TrafficMessageChannel#Convert_TMC_LoctionCodeList_to_OpenStreetMap Cela mouline les fichiers contenus dans l'archive, pour faire un fichier .osm que l'on peut consulter dans JOSM Après pas mal de tatonnements, j'ai réussi à le faire tourner sur la version 8.0 de la table des localisants, et obtenir un fichier .osm avec tous les segments et les points. didier2020 a réussi également. Désormais la table est en révision 9.2 http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v9-2_cle7bc9d2.zip Là où ça se complique, c'est que les allemands ont élaboré un premier schéma de tags http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema Mais que le bas de la page indique qu'un nouveau schéma (plus simple ?) est au stade de la proposition http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme A regarder en même temps que la page de discussion associée Cela y est j'ai tout compris ! Sauf... - Y a-t-il une chose précise, simple, programmable, exprimable en un paragraphe en français, qui soit utile et qui me (nous ? ) permettrait d'avancer en rendant service ? J'ai vu la remarque de Christian Quest : Ca me semble une très bonne idée de croiser les données OSM avec datex et d'inclure des données datex dans OSM pour assurer un contrôle de qualité et de cohérence par les calculs d'itinéraires. ...qui est encourageante, mais qui me parait déjà être une montagne ? - Y a-t-il 1) un groupe de travail ? 2) un projet ? 3) juste un groupe ? 4) Plusieurs groupes et projets ? 5) Rien. Si c'est 5), je suis perdu, je peux rien faire :-) Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le lundi 01 octobre 2012 à 10:02 +0200, Cyrille Giquello a écrit : Le 1 octobre 2012 09:21, Ab_fab gamma@gmail.com a écrit : Bonjour, Lors de la soirée parisienne de vendredi, on a évoqué le contrôle qualité des axes routiers, la (probable) nécessité de construire des relations pour gérer tout ça. Depuis, je me suis souvenu d'un de mes TOC non réalisé, à savoir l'intégration des tables de localisants DATEX, liées au système d'info trafic TMC. Hormis le fait de pouvoir à terme servir pour les applications de navigation routière, le maillage du réseau routier en tronçons et points de raccordement devrait pouvoir servir à la vérification des continuités pour le réseau principal, à la manière des outils qui ont été faits pour le suivi de l'avancement des cours d'eau. Les tables de localisants sont disponibles en version 9.2, et le service qui les élabore a donné son accord explicite pour leur usage dans le cadre d'OSM il y a quelques mois. L'archive contenant les tables pour la révision 8.0 inclut une carte qui donne une idée du réseau routier pris en compte (répertoire /Carte) http://diffusion-numerique.info-routiere.gouv.fr/IMG/zip/Alert-C-v8-0-FR_cle21334c.zip Ce n'est pas pléthorique, mais déjà un premier jalon intéressant, selon moi. Didier2020 avait fait une visualisation en ligne des points et des segments, mais cela me renvoie une erreur 404 Est-ce que le sujet intéresse du monde ? J'initie la discussion sur talk-fr, mais si cela tourne au technique, on pourra basculer sur dev-fr. -- ab_fab Il n'y a pas de pas perdus Salut, Ca me semble une bonne idée. Peut être même que Didier2020 peut mettre son code sur un serveur osm_fr c'était un tableau excel avec macro (1 vrai cochonerie ) mais c'était que pour le rendu. ... Ou nous le passer qu'on l'y mette. Un jour il viendra sur http://opendata.openstreetmap.fr ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Bonjour, Je suis partant pour participer avec vous à un travail sur les données DATEX. J'avais commencé il y a qques temps à écrire des parseurs (en python / Django)des fichiers .dat et .da2 contenus dans les zip fournis par le site gouvernemental pour essayer de regénérer la carte donnée en .pdf dans le zip à partir des infos contenues dans la partie /Data (si j'ai bien compris, cela est possible). J'avais un peu du mal à trouver la correspondance entre les docs et ce que j'avais dans les fichiers donc j'avais laissé tomber, mais vu qu'il y a des personnes semble-t-il plus expérimentées en DATEX que moi, je suis partant pour me remettre la tête la dedans et essayer de mieux comprendre tout ça. Pour essayer de saisir la problématique : vous voulez importer dans OSM les références des points contenus dans points.dat dans OSM ? (ou alors rien à voir ? :/ ) . A bientôt Lionel. On Oct 1, 2012, at 12:08 PM, Christian Quest wrote: Ca me semble une très bonne idée de croiser les données OSM avec datex et d'inclure des données datex dans OSM pour assurer un contrôle de qualité et de cohérence par les calculs d'itinéraires. Beaucoup de données externes, même non importables dans OSM peuvent servir au contrôle de qualité et à évaluer l'exhaustivité des données OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
vu qu'il y a des personnes semble-t-il plus expérimentées en DATEX que moi Peut être pas dans les lecteurs de la liste française, mais dans le monde OSM, sans doute. Pour essayer de saisir la problématique : vous voulez importer dans OSM les références des points contenus dans points.dat dans OSM ? (ou alors rien à voir ? :/ ) Tu trouveras peut être que je joue sur les mots, mais on va éviter d'importer, c'est à dire d'extraire les coordonnées des points pour les balancer tels quels dans la base. Normalement, la position géographique doit être bonne à quelques dizaines voire centaines de mètres. Mais quand on sait quels segments sont associés, ce n'est pas trop compliqué de savoir de quelle intersection il s'agit en réalité (de la base OSM). Depuis quelques mois, il y a des outils intéressants pour ce genre d'opération d'intégration, comme ceux qui servent à rentrer les écoles et les bureaux de poste. L'étape suivante, c'est d'intégrer les segments routiers qui relient ces points. C'est là que l'on peut créer une relation. Un de ses premiers mérites sera d'exister en tant que tronçon TMC en tant que tel. Mais un autre intérêt, et peut être encore plus important sera que l'on pourra faire des contrôles périodiques sur l'intégrité du tronçon, de part la présence de la relation, comme vérifier qu'il n'y a pas de voies manquantes. Le 1 octobre 2012 17:35, Lionel Gueganton lionel.guegan...@free.fr a écrit : Bonjour, Je suis partant pour participer avec vous à un travail sur les données DATEX. J'avais commencé il y a qques temps à écrire des parseurs (en python / Django)des fichiers .dat et .da2 contenus dans les zip fournis par le site gouvernemental pour essayer de regénérer la carte donnée en .pdf dans le zip à partir des infos contenues dans la partie /Data (si j'ai bien compris, cela est possible). J'avais un peu du mal à trouver la correspondance entre les docs et ce que j'avais dans les fichiers donc j'avais laissé tomber, mais vu qu'il y a des personnes semble-t-il plus expérimentées en DATEX que moi, je suis partant pour me remettre la tête la dedans et essayer de mieux comprendre tout ça. Pour essayer de saisir la problématique : vous voulez importer dans OSM les références des points contenus dans points.dat dans OSM ? (ou alors rien à voir ? :/ ) . A bientôt Lionel. On Oct 1, 2012, at 12:08 PM, Christian Quest wrote: Ca me semble une très bonne idée de croiser les données OSM avec datex et d'inclure des données datex dans OSM pour assurer un contrôle de qualité et de cohérence par les calculs d'itinéraires. Beaucoup de données externes, même non importables dans OSM peuvent servir au contrôle de qualité et à évaluer l'exhaustivité des données OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Petite précision: + datex est un format d'échange : http://diffusion-numerique.info-routiere.gouv.fr/publication/cnir/test-france en regardant l'interieur des fichiers xml, chaque événement n'utilise pas forcement le référentiel - le référentiel (pour la localisation) c'est alert-c mais alert-c ne couvre qu'une partie des routes: http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=markerpostservice=SETRA Le lundi 01 octobre 2012 à 17:48 +0200, Ab_fab a écrit : vu qu'il y a des personnes semble-t-il plus expérimentées en DATEX que moi Peut être pas dans les lecteurs de la liste française, mais dans le monde OSM, sans doute. Pour essayer de saisir la problématique : vous voulez importer dans OSM les références des points contenus dans points.dat dans OSM ? (ou alors rien à voir ? :/ ) Tu trouveras peut être que je joue sur les mots, mais on va éviter d'importer, c'est à dire d'extraire les coordonnées des points pour les balancer tels quels dans la base. Normalement, la position géographique doit être bonne à quelques dizaines voire centaines de mètres. Mais quand on sait quels segments sont associés, ce n'est pas trop compliqué de savoir de quelle intersection il s'agit en réalité (de la base OSM). Depuis quelques mois, il y a des outils intéressants pour ce genre d'opération d'intégration, comme ceux qui servent à rentrer les écoles et les bureaux de poste. L'étape suivante, c'est d'intégrer les segments routiers qui relient ces points. C'est là que l'on peut créer une relation. Un de ses premiers mérites sera d'exister en tant que tronçon TMC en tant que tel. Mais un autre intérêt, et peut être encore plus important sera que l'on pourra faire des contrôles périodiques sur l'intégrité du tronçon, de part la présence de la relation, comme vérifier qu'il n'y a pas de voies manquantes. Le 1 octobre 2012 17:35, Lionel Gueganton lionel.guegan...@free.fr a écrit : Bonjour, Je suis partant pour participer avec vous à un travail sur les données DATEX. J'avais commencé il y a qques temps à écrire des parseurs (en python / Django)des fichiers .dat et .da2 contenus dans les zip fournis par le site gouvernemental pour essayer de regénérer la carte donnée en .pdf dans le zip à partir des infos contenues dans la partie /Data (si j'ai bien compris, cela est possible). J'avais un peu du mal à trouver la correspondance entre les docs et ce que j'avais dans les fichiers donc j'avais laissé tomber, mais vu qu'il y a des personnes semble-t-il plus expérimentées en DATEX que moi, je suis partant pour me remettre la tête la dedans et essayer de mieux comprendre tout ça. Pour essayer de saisir la problématique : vous voulez importer dans OSM les références des points contenus dans points.dat dans OSM ? (ou alors rien à voir ? :/ ) . A bientôt Lionel. On Oct 1, 2012, at 12:08 PM, Christian Quest wrote: Ca me semble une très bonne idée de croiser les données OSM avec datex et d'inclure des données datex dans OSM pour assurer un contrôle de qualité et de cohérence par les calculs d'itinéraires. Beaucoup de données externes, même non importables dans OSM peuvent servir au contrôle de qualité et à évaluer l'exhaustivité des données OSM. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab Il n'y a pas de pas perdus ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Contrôle qualité des axes routiers
Le 01/10/2012 18:24, Ab_fab a écrit : Ça peut être une bonne occasion de voir le détail de ce schéma. Et s'il est interessant les références des noeuds pourraient y être indiquées, c'est sûr. Le 1 oct. 2012 18:19, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Il faudrait aussi regarder la proposition des jonctions routières complexes qui a été présentée au SOTM à Tokyo. L'idée est d'avoir une relation pour décrire un noeud routier, ce qui permet aux algos de routage (et de rendu) de mieux fonctionner. C'est sur ces noeuds routiers qu'il faudrait peut être mettre les infos DATEX. A lire ici: http://wiki.openstreetmap.org/wiki/Proposed_features/Junction#Complex_junction_relation Pour revenir à ta question initial Ab_fab*, je suis aussi partant pour contribuer sur le sujet. En revancheje coince sur la motivation contrôle qualité que tu associes : pour moi il y a d'un coté le référentiel TMC qu'on peut vouloir intégrer à OSM si on estime que ça apporte de la valeur à la base, et de l'autre le besoin de faire du contrôle-qualité sur le graphe OSM. Pour ce second point pris seul, je préfère dépenser du temps à constituer des matrices origine-destination et à lancer des batteries d'itinéraires via OSRM, pour ensuite détecter les changements dans les durées et/ou les kilométrages, et par suite analyser les causes du changement, voire détecter des cassures dans le graphe. Je pense qu'on aura des résultats plus rapides et des diagnostics plus simples à partager que ceux basés sur le TMC. Sans compter que le rythme d'intégration d'un tel référentiel risque d'être modeste, et engage derrière une maintenance à chaque nouvelle version des tables de localisants. Donc partant, si on pense que ça servira à autre chose que du contrôle-qualité :-) vincent * pas facile de gober en une soirée les 100 messages du jour sur talk-fr :-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
