En revanche les données fournies par l'Open Data de la STAR à Rennes sont excellentes (en terme de géolocalisation et complétude)... sauf qu'Osmose insiste pour changer les tags de numéros de référence et ne produit actuellement presque uniquement 100% de faux positifs sur tous les arrêts (pour ajouter des tags redondants ou faux à des arrêts pourtant déjà intégrés et qu'il trouve bien dans la base).
La géolocalisation peut cependant être un peu améliorée pour placer les plateformes d'arrêt sur le bon côté de la route, mais dans la plupart des cas j'ai vu que la faute ne vient pas de l'OpenData mais d'une précision insuffisante du tracé des rues et routes dans OSM (ce qui a pour effet de mettre les deux arrêts normalement de chaque côté du'une rue tous les deux du même côté). Les tracés vectoriels du cadastre de Rennes et de son opendata sont excellents, la solution est donc de recaler les rues; les ajustements des platformes d'arrêts sont minimes: juste le mettre sur le trottoir plutôt que sur le côté de la chaussée (dans certains cas on peut voir norn seulement la plaforme (avec les zébrures sur la chaussée) mais aussi les abris bus (l'orthophoto fournie par Bing reprend les clichés haute précision réalisés par Rennes Métropole et l'IGN, leur alignement est excellent, on peut donc largement augmenter la précision des anciens tracés OSM initialement dessinés sur des clichés de moins bonne précision et faits souvent un peu à la va-vite au moment où on traçait les limites communales et quelques rues). J'en profite en ce moment pour ajouter les sous-quartiers (là encore sur les données OpenData de Rennes Métropole) : ils sont au niveau 11; jusqu'à présent on n'avait que les 12 quartiers administratifs au niveau 10 et les 6 unités administratives au niveau 9. Et je nettoie des tracés parasites quand j'en trouve. Autant que possible ces tracés de quartiers aux niveaux 9,10,11 sont fusionnés avec ceux des cantons (qui ont été tracés au béut par estimation sur des noms de rues mais sans le calage précis des rues qui est maintenant dans l'OpenData de Rennes Métropole). J'atteint la précision quasi-centimétrique, les rues sont profilées, il n'y a plus de rues qui coupent les bordures de chaussées ou les trottoirs dans ce que je touche, ce qui permet de poser correctement les éléments voisins sur le trottoir comme les poubelles, abris bus, et positions des feux ou encore des arbres et les emplacements de stationnement latéral. Pour certains grands carrefours ou ronds-points je les reprofile de façon moins approximative, j'ajoute les pelouses et zones plantées et certains chemins piétons. Cependant je ne touche pas aux notations d'accessibilité des bordures de trottoirs surbaissés pour les usagers en fauteuil. Et il manque certainement des tas de ralentisseurs près des passages pétons (eux je les ajoute aussi quand ils manquent quand ils sont bien visibles et que je recale eux aussi). Les rues en courbes ont réellement des formes en courbe avec des rayons de courbure corrects et non un seul angle (ça c'est utile pour la navigation des véhicules larges, notamment bus et camions). La moitié des 45 sous-quartiers sont faits: au centre, sud-gare, nord, ouest et sud-ouest. Je continue les autres... Le 21 décembre 2016 à 09:58, Florian LAINEZ <winner...@free.fr> a écrit : > Merci Fred, Noémie pour ces outils. > Je rejoins les critiques : c'est pour l'instant un peu galère voir > trompeur. > Je comprends néanmoins qu'on ne puisse faire mieux pour l'instant ... > > En ce moment j'aborde le problème de qualité avec divers acteurs du > transport et j'ai fait un petit comparatif rapide sur deux quartiers > exemple : https://www.slideshare.net/secret/yhSSpQ6mzE6SH6 > Des suggestions d'amélioration ? > > Y aurait-il moyen de générer des stats plus poussées ? Je cherche par > exemple l'écart moyen de la distance entre les données STIF et OSM, les > valeurs max/min, voir l'écart-type. > Fred peut-être est-ce déjà intégré à OSMOSE ? Je n'ai pas trouvé. > J'aimerai également détailler ça par gestionnaire de réseau, étant donné > qu'il y en a 75 dans les données du STIF. > > Bonne journée > > > Le 20 décembre 2016 à 21:32, Noémie Lehuby <noemie.leh...@openmailbox.org> > a écrit : > >> Bonjour, >> >> Bonne idée Christian ! >> j'ai créé une page de débug qui précise, dans OSM et dans l'opendata, >> pour chaque arrêt avec une ref STIF, les lignes desservies : >> https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=472985886 >> >> il faut lui passer en paramètre l'id OSM du noeud correspondant à l'arrêt. >> >> Ça gère aussi les cas où un arrêt OSM correspond à plusieurs arrêts dans >> l'opendata (dont certains pas forcément du bon côté de la route ...) : >> https://ref-lignes-stif.5apps.com/stop.html?osm_stop_id=928458342 >> >> N'hésitez pas à l'utiliser pour vérifier vos ajouts de références STIF ;) >> >> Noémie >> >> Date: Mon, 19 Dec 2016 18:42:52 +0100 >>> From: Christian Quest <cqu...@openstreetmap.fr> >>> To: Discussions sur OSM en français <talk-fr@openstreetmap.org> >>> Subject: Re: [OSM-talk-fr] Données du STIF sur Osmose >>> Message-ID: >>> <CAAXY6DN0JNdZnk5_QZGKPQBoeQd5k25ERQ5F7Uu-+ecr3q1z=g...@mail.gm >>> ail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> C'est trompeur en effet... >>> >>> J'ai intégré des arrêts sur ma commune et il manque quelques infos de >>> contexte pour savoir qu'on ajoute bien le bon ID quand il y a ambiguité. >>> Il >>> faudrait par exemple le N° des lignes et la direction sinon deux arrêts >>> proches peuvent être intervertis très facilement. >>> >> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > > -- > > *Florian Lainez* > @overflorian <http://twitter.com/overflorian> > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
