J'ajoute aussi qu'Osmose propose (n plus d'ajouter des tags faux) de remplacer des "shelter=yes" pour des arrêts de bus alors qu'on a un "shelter=yes" (vérifié et bien visible sur le terrain et sur les photos) La raison à cela: l'absence d'information sur ce sujet dans les données OpenData, ce qui ne signifie PAS qu'il n'y a pas d'abris bus (dans certains cas les données de la STAR sont fausses, pour cet arrêt : il y a bel et bien un abri bus).
La STAR n'est pas forcément à jour dans sa base de ce que la mairie locale a pu aménager à la demande des usagers locaux. On a des erreurs à ce niveau dans les communes rurales de la métropole, pour des arrêts près de carrefours en zone rurale, très exposés aux intempéries: à l'origine c'était juste un bateau avec un poteau indicateur, mais depuis l'abris a été aménagé et la STAR n'a pas enregistré dans sa base cet aménagement. Mais la plupart du temps dans ces cas l'OpenData de la STAR ne mentionne rien ou alors mentionne un "abri=faux" juste par défaut (parce que son export de données n'a prévu à cet endroit qu'une valeur booléenne et pas une valeur "null" non renseignée). Pourtant l'abri bus est bien là (et même depuis plusieurs décennies !) Bref, ne tenez pas compte du tout de ce que propose Osmose concernant le réseau bus STAR dans Rennes Métropole, c'est du quasi-100% faux (hormis peut être quelques très rares points difficiles à voir) et à revoir intégralement (pas la peine de perdre du temps à signaler du faux positif sur des milliers de noeuds) ! Dans l'état actuel, cette proposition "d'intégration" est beaucoup plus une nuisance qui devrait être retirée. Cette analyse est à refaire de façon plus précise. Concernant le changement de référence "ref:fr_star=*" en "ref:FR_STAR=*" c'est à corriger, de même que le changement de réseau "network=fr_star" en "network=Star" (totalement faux) à corriger plutôt en "network=FR:STAR". Mais dans les deux cas ce n'est pas de "l'intégration" mais plutôt une suggestion de changement (avec un niveau de gravité faible), pour lequel Osmose pourrait même se passer totalement de le signaler: ce type de changement est facile à faire sans Osmose, qui n'a pas non plus à chercher à imposer un tel choix qui n'a été discuté et documenté nulle part. Le 13 décembre 2016 à 20:35, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Au passage, concernant Rennes, ce que propose "d'intégrer" Osmose c'est > quasiment du 100% faux positif !! > > Bref Osmose est totalement à revoir concernant Rennes (ses règles sont > totalement fausses) !!! > > 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/attachment >> s/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
