Tu oneteras que la STAR différencie bel et bie ndans ses données les plateformes (géolocalisée précisément) en les séparant des itinéraires (qui ne passent jamais exactement par ces points mais seulement à proximité).
Tu peux critiquer les "stop_position", mais c'et ce qui assure de ne pas avoir à chercher dans la liste des chemins celui pui pourrait correspondre à une des "plateform" indiqués comme desservis par la ligne. On a les deux concepts, mais dans une logique de calculs d'itinéraires, avoir les stop_position (même approximatifs et ne venant pas des open data mais de la pose d'un point raisonnablement proche de la plateform évite d'avoir à se poser des questions. Les "stop_position" n'ont pas vocation à être rendus sur la carte (d'autant plus qu'ils sont mis sur la voie, généralement tracée au milieu dans la plupart des rues, sans tenir compte de la position exacte des "bateaux" ni de la longueur des zones d'arrêt zébrées sur une des voies de la chaussée, donc pas au milieu). Ces stop_position sont aussi approximatifs que le tracé des rues avec un seul chemin "central" quel que soit le nombre de voies ou la largeur de chaussée. Ces deux éléments (chemins highway=* et noeuds "stop_position") sont là dans une logique d'itinéraires et non réellement de rendu (qui devrait tenir compte de la surface), et cela restera là tant qu'on continuera à taguer des rues/routes comme de simples traits et non comme des surfaces en détaillant les voies). Quand on voudra aller plus loin, ont repositionnera aussi correctement les feux (pas au milieu de la chaussée), on mettra la surface réelle des passages piétons, on taguera les trottoirs (non pas comme des chemins parallèles mais comme des surfaces jointives à celle des voies de la chaussée. Cela ne risque pas d'arriver avant longtemps. Donc on reste dans une logique d'itinéraire pour l'instant, en sachant que le rendu reste approximatif (en supposant un "buffer" raisonnable de +/- 3,50 mètres de chaque côté du chemin tracé, ce qui correspond à une largeur "moyenne" estimée d'une rue à deux voies, une largeur qu'on peut ajuster un peu si on trouve des tags précisément le nombre de voies ou la présence de voies supplémentaires pour bus=+4 mètres environ, ou juste pour cyclistes=+2mètres, ou la présence de stationnement latéral=+3mètres environ; les rendus ensuite, selon l'échelle de représentation ou ce qu'ils veulent afficher peuvent ajuster les largeurs de tracé, mais elles sont rarement proportionnelles à la largeur exacte, c'est là encore juste une estimation raisonnable). Pourtant concernant les arrêts de bus et les autres équipements et mobiliers urbains sur les trottoirs (éclairage public, arbres, bancs, poubelles, points d'eau...) on aimerait déjà les voir posés hors du milieu de la chaussée (donc déjà hors des itinéraires tracés dans la base). Mais il n'y a pas de moyen correct pour associer les arrêtes de bus avec l'itinéraire sans avoir à chercher. Les stop_position ont l'avantage de pouvoir être vérifiés automatiquement et très facilement: on en déduit alors quel "plateform" fait effectivement partie ou pas de l'itinéraire, ou si l'itinéraire indiqué par les chemins est complet ou pas. Le 13 décembre 2016 à 20:31, <osm.sanspourr...@spamgourmet.com> a écrit : > Je parlais en général pour le bien de la communauté, pas pour mon réseau > local (Lorient a des données sur le portail data.gouv.fr mais pas le > réseau transport à ma connaissance, Quimperlé n'a pas grand chose en > disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, comme > dit joliment par Christian open mais pas data). > > Entièrement d'accord il faut des données libres et stables, je pense que > pour la STAR (Rennes) c'est le cas. > Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon, > Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère > Noëlle, heu Noémie. > Merci pour l'offre ! > > Je pense que la faible couverture de public_transport=stop_position montre > que c'est une lubie de tagueur fou : pas de réalité sur le terrain (il faut > observer l'arrêt du bus, pour le train suivant la longueur pourtant on ne > peut en mettre qu'un (quoique ce n'est pas précisé dans le wiki > <https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position>) > et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs > disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, sinon > on tague pour le schéma (ce qui me semble pire que taguer pour le rendu). > On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut > opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt de > bus et tu te manges une relation avec des tags qui feront que ton arrêt ne > se sera pas affiché. > > Jean-Yvon > > > > Le 13/12/2016 à 20:03, Noémie Lehuby - noemie.leh...@openmailbox.org a > écrit : > > Bonsoir, > > Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres régions, > mais il faut s'assurer avant que les codes qu'on importera sont stables. > S'ils ne représentent plus rien dans 6 mois, on va le regretter. > C'est pourquoi en île-de-france ça a du sens : le STIF propose un > référentiel sur son portail opendata donc on peut penser qu'on aura une > certaine pérennité de ces codes. > Quel réseau te ferait plaisir pour Noël ? > > C'est amusant ça : la couverture en public_transport = stop_position est > si faible que j'avais jamais remarqué le problème de rendu avec Skechtline > que tu cites Philippe. > > Noémie > > Date: Mon, 12 Dec 2016 21:17:49 +0100 > From: osm.sanspourr...@spamgourmet.com > To: talk-fr@openstreetmap.org > Subject: Re: [OSM-talk-fr] intégration des référentiels STIF > Message-ID: <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net> > <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Logiquement, on se dit que tu vas nous faire la même chose pour l'open > data des lignes hors du STIF : il y a des réseaux de transports en > dehors de l'Île-de-France, si, si ;-). > > Pense qu'une seule personne a profité de l'outil, c'est un peu abuser, > non ? :-D > > Jean-Yvon > > Le 12/12/2016 à 21:01, Noémie Lehuby - noemie.leh...@openmailbox.org a > écrit : > > Bonsoir, > > J'ai poussé une mise à jour de l'outil, avec quelques améliorations > mineures : https://ref-lignes-stif.5apps.com/ > Je pense que je ne vais pas faire beaucoup d'autres évolutions dans > l'outil, vu que Florian a déjà associé plus des 3/4 des lignes ;) > Belle performance ! > > > -------------- section suivante -------------- > Une pièce jointe HTML a été nettoyée... > URL: > <http://lists.openstreetmap.org/pipermail/talk-fr/ > attachments/20161212/e1a79ea5/attachment-0001.html> > <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161212/e1a79ea5/attachment-0001.html> > > ------------------------------ > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
