Ici, les highway=bus_stop sont ceux qui reçoivent public_transport=platform et ce ne sont que ceux qui ont les détails, name, ref, route_ref, zone. Entretemps il est vrai que ceux-là sont devenus
ref:De_Lijn ref:TEC route_ref:De_Lijn route_ref:TEC Le même pour les tags zone. Pour les arrêts du STIB/MIVB à Bruxelles, ref et route_ref sont suffisant. Il est vrai que ref:BE:De_Lijn aurait p-ê été mieux encore. De toute façon les informations de De Lijn et TEC viennent des operateurs eux-mêmes. Donc ces route_ref-là sont 'calculés'. Le STIB/MIVB a choisi de ne pas partager leurs données. Ils ne sont même pas capables de repondre aux courriers. Their loss. Le réseau n'est pas si grand que ça. Jo 2016-10-23 20:09 GMT+02:00 Philippe Verdy <[email protected]>: > Je ne suis pas sûr que ce soit utile, sauf dans le cadre d'un survey de > terrain où on ne voit que les arrêts mais pas exactement les lignes > suivies. De plus tous les numéros ne sont pas forcément affichés (il y a > des lignes rurales qui passent devant et où l'arrêt est possible à la > demande en faisant signe au chauffeur ou en lui demandant une descente, on > ne voit qu'un poteau ou un bateau mais aucun indicateur des lignes > possibles). > > Je pense que pour les lignes de transport publiques il vaut mieux se fier > aux informations données par les exploitants de réseaux ou les > collectivités (mais là encore les données peuvent être parcellaires, > notamment pour les fiches horaires affichées, qui ne mentionnent pas > toujours tous les arrêts "mineurs" ou pas les horaires précis pour chacun > des arrêts précédents et suivants. > > Même quand ces arrêts sont listés sur les fiches horaires, ils ne sont pas > toujours affichés pour toutes les lignes sur le terrain. Bref le > "route_ref" risque d'être incomplet... Surtout pour les variantes d'une > ligne ou les lignes partiellement partagées (deux numéros de lignes pour le > même bus: c'est le bus qui indique le numéro et sa destination, il peut sur > un segment servir à plusieurs réseaux, par exemple un réseau local et un > réseau régional, et aussi assurer un trafic commercial au delà hors des > réseaux publics sous un numéro supplémentaire propre à l'exploitant, ou > passer d'un réseau public à un autre sur son parcours).. C'est peu courant > pour les bus urbains des grandes villes, mais plus courant pour les cars > qui desservent depuis une plus grande ville des zones rurales qui sont hors > de la compétence de la grande ville (ou intercommunalité). > > Si tu fais ça, ce que tu vas taguer ce sont les "platform" (ou "bus_stop" > de l'ancien schéma), mais pas les "stop" ("stop_position") du schéma v2 qui > nécessitent une connaissance des parcours pour les mettre précisément sur > les chemins. > > Malheureusement les anciens objets "bus_stop" sont souvent posés sur un > chemin, donc sans préciser le côté où il y a une plateforme, un banc, un > abris, un bâteau d'arrêt, ou l'accessibilité, ou d'autres éléments comme le > "pole", un panneau d'information... Impossible avec ça de reconstituer un > itinéraire et de savoir si l'arrêt est desservi dans les deux sens ou pas. > > > Le 23 octobre 2016 à 18:55, Jo <[email protected]> a écrit : > >> En Belgique on utilise route_ref pour indiquer quelles lignes desservent >> un arrêt. C'est facile à ajouter pendant le 'survey'. Et ça peut aider pour >> vérification une fois que l'on commence à créer des relations route. >> >> Polyglot >> >> 2016-10-22 17:56 GMT+02:00 Philippe Verdy <[email protected]>: >> >>> Déjà les "bus_stop" (ancienne version) devraient correspondent point par >>> point aux nouveaux objets "public_transport:platform" s'ils ne sont pas sur >>> le chemin mais doivent servir à indiquer les abris, les bancs ou >>> l'accessibilité et la zone d'attente (ou le poteau indicateur) >>> >>> S'ils sont sur le chemin (donc sans indication du côté) ce sont des >>> "public_transport:stop_position" (et il n'y a pas d'attributs pour les >>> bancs, abris et l'accessibilité). >>> >>> Selon que c'est un type ou l'autre tu en déduis le rôle qu'il faut >>> mettre dans la relation route. Idéalement on devrait avoir deux rôles pour >>> chaque arrêt: stop et platform >>> >>> Les "route segments" (proposés) sont une autre problématique liée à la >>> topologie des chemins, et la multiplicité des variantes qui empruntent des >>> sections communes. Mais ils sont surtout nécessaire pour lever les >>> ambiguités de parcours sur les chemins quand ils ne forment pas une ligne >>> continue sans intersection, car dans l'immédiat on est amené à devoir >>> mettre tous les ways membres dans l'ordre, y compris avec des doublons pour >>> les segments communs, et il n'est pas facile de déterminer un ordre des >>> segments quand il y a des intersections, même sur une seule route et après >>> avoir séparé chaque direction et chaque variante de la ligne dans des >>> relations "route" séparées mais regroupées dans un "route_master" >>> >>> Quand on a compris tout ça, on peut faire une appli qui saura distinguer >>> les vrais "stop_position" des "plateform" (c'est facile: le "stop" est sur >>> le chemin, mais pas la "plateform"), ce que "bus_stop" ne sait pas classer >>> correctement. Juste faire ça fera beaucoup avancer les choses. >>> >>> ---- >>> >>> Pour aller au delà avec les "stop_area" par exemple pour regrouper >>> différents arrêts et plateformes de différentes lignes destinées à la >>> correspondance directe ou même pour revenir en arrière sur la même ligne >>> mais par une autre route), c'est un autre travail à faire: celui de >>> vérifier et assurer les correspondances. >>> >>> De même que les objets "station" qui sont des regroupements plus large >>> comprenant plusieurs "stop_area", des batiments, des accès (escaliers, >>> portes, ascenseurs...) où la correspondance est plus complexe (et où on >>> peut avoir des services annexes (comme la vente des billets et abonnements) >>> et peut grouper des réseaux de nature différente et différents opérateurs >>> pour l'intermodalité (exemple: les gares routières et gares ferroviaires) >>> >>> >>> Le 22 octobre 2016 à 12:10, Florian LAINEZ <[email protected]> a écrit : >>> >>>> Si on propose ce que l'on sait déjà de l'arrêt et qu'on propose de >>>>> confirmer/infirmer/ne pas se prononcer, on gagne des possibilités de >>>>> réponse rapide. >>>> >>>> tout à fait, je pense à de l'autocomplétion avec la meilleure >>>> proposition mise en avant le cas échéant. >>>> >>>> Peut-être que si on laisse la personne dessiner le trajet (juste en >>>>> chaînant les arrêts) on a pas mal de matière. >>>>> Ensuite un moteur de calcul de trajet (favorisant les rues larges et >>>>> droites) peut être utilisé côté serveur pour avoir un trajet >>>>> vraisemblable. >>>>> Trajet à valider bien-sûr. >>>> >>>> C'est à peu près ça que j'ai en tête. Avec la possibilité de drag&drop >>>> le chemin pour le replacer (du style de ce que propose OSRM sur osm.org) >>>> sans avoir à gérer des way un par un. >>>> >>>> @philippe tout ceci est passionnant mais ce sont des problématiques >>>> complexes, or mon appli est vraiment focalisée sur la simplicité. D'où le >>>> parti pris de ne gérer que les highway=bus_stop (ou son équivalent >>>> public_transport=platform). >>>> >>>> Mon idée est bien de pouvoir gérer les deux modèles, ancien et nouveau, >>>> de manière transparente pour l'utilisateur. >>>> Charge aux mappeurs expérimentés de compléter le travail avec des >>>> outils plus classiques. >>>> >>>> >>>> Le 21 octobre 2016 à 22:26, Philippe Verdy <[email protected]> a >>>> écrit : >>>> >>>>> Les tags "from=*", "via=*" et "to=*" sont plutôt destinés à un >>>>> utilisateur humain qu'à subir un vrai rapprochement avec un arrêt. >>>>> >>>>> Dans le shéma actuel ("public_transport:version=2" dans les relations >>>>> "route"), ce sont les noeuds membres (posés sur un les ways membres) ayant >>>>> un rôle "stop" qui servent à ça, le premier noeud (from) devrait être de >>>>> rôle "stop_enter_only", le dernier de rôle "stop_exit_only". La direction >>>>> de la ligne devrait s'en déduire.... L'ennui c'est qu'il existe parfois >>>>> des >>>>> stations intermédiaires qui n'autorisent que la descente ou que la montée, >>>>> ayant ces même rôles (c'est rare...). On n'a en fait rien de clair pour >>>>> indiquer réellement quels arrêts (noeuds de rôle "stop") sont les deux >>>>> terminus (l'idéal serait d'ajouter un suffixe ":start" ou ":end" à ces >>>>> rôles) >>>>> >>>>> On peut ajouter aussi les plateformes (noeuds, lines ou polygones) en >>>>> membres de rôle "platform" (avec "platform_enter_only", >>>>> "platform_exit_only" pour le premier et le dernier arrêt, mais cela me >>>>> semble inutile si on a identifié clairement les deux noeuds "stop" de >>>>> départ et d'arrivée: le rôle "platform" suffit à lui seul; ces rôles >>>>> variantes sont plutôt destinés à combler des données manquantes quand il >>>>> manque des noeuds "stop", mais les plateformees sont pas faciles du tout à >>>>> gérer et associer avec le parcours de la ligne sans un noeud "stop" >>>>> correspondant). >>>>> >>>>> Il reste cependant le cas des lignes circulaires dont le départ et >>>>> l'arrivée sont au même point: si ce point n'est pas sur un way en sens >>>>> unique (par exemple une petite voie de service latérale à la chaussée), là >>>>> on a bsoin que ce premier chemin ait un rôle "forward" ou "backward" (je >>>>> ne >>>>> vois pas comment faire autrement) pour indiquer le sens de la ligne. >>>>> L'autre solution serait d'utiliser deux noeuds très proches mais séparés >>>>> pour distinguer le départ et l'arrivée (mais sans mettre alors dans la >>>>> "route" le segment qui les relie ! Ces noeuds étant cependant associés à >>>>> la >>>>> même plateforme. >>>>> >>>>> Les chemins sont ensuite parcours dans le sens indiqués par leur >>>>> jonction, mais il reste la difficulté des lignes dont l'itinéraire repasse >>>>> plusieurs fois par le même noeud (voire même par un même chemin en cas de >>>>> détour, et pas non plus forcément en sens opposé si ce détour fait une >>>>> boucle): là encore les chemins doivent être orientés pour réduire (avec >>>>> backward ou forward) le nombre de possibilités de succession des chemins, >>>>> mais il peut rester des ambiguités. >>>>> >>>>> Pour éliminer totalement ces ambiguïtés, il a été proposé de créer des >>>>> relation "route" avec un tag "segment=yes", où les chemins forment une >>>>> ligne ininterrompue et ne repassant jamais par un même noeud ou chemin, >>>>> puis d'inclure ces segments de routes en tant que membres d'une relation >>>>> "route" normale. Mais ce n'est pas encore mis en oeuvre. >>>>> >>>>> En attendant, on a encore besoin que les relations "route" mentionnent >>>>> la liste des arrêts ("stop") dans l'ordre exact. Et il est impératif >>>>> d'utiliser des noeuds rôle "stop" (tagués "public_transport=stop_position" >>>>> + "bus=yes") sur les chemins. Ces noeuds n'ont aucun tag pour les abris, >>>>> poubelles, accès handicap, etc. qui sont à mettre plutôt sur les objets >>>>> "public_transport=platform". >>>>> >>>>> Le nouveau schéma recommande même de placer dans l'ordre dans la >>>>> relation les noeuds "stop" suivis immédiatement de l'objet "platform" >>>>> auquel il se réfère; la liste des chemins se met plutôt ensuite après >>>>> (avec >>>>> des chemins en doublons parfois, faute de prise en charge pour l'instant >>>>> des "segments" de route). >>>>> >>>>> Noter que les chemins peuvent aller commencer et aller plus loin que >>>>> le premier et le dernier arrêt (généralement on inclue dans une route >>>>> aussi >>>>> les éléments de chemins qui raccorde une route pour un sens à l'autre >>>>> route >>>>> dans l'autre sens dans la même ligne. >>>>> >>>>> Le plus compliqué est de réviser les "bus_stop" qui ont été placés un >>>>> peu n'importe où (sur les chemins ou pas) et tagués de façon hybride comme >>>>> des "stop" ou des "platform", et ensuite repris indifféremment avec le >>>>> même >>>>> rôle "platform" dans les relations "route" ; il faut: >>>>> - enlever les "highway=bus_stop" sur les noeuds, mettre >>>>> "public_transport:version=2" sur les noeuds, >>>>> - doublonner ces noeuds s'il y a des "shelter ou wheelchair", en >>>>> placer un sur le chemin, l'autre à côté pour la station du bon côté, >>>>> - en mettre un avec "public_transport=stop" (celui sur le chemin), >>>>> l'autre avec "public_transport=platform" >>>>> - ne garder les tags "shelter=yes" ou "wheelchair=yes" que sur la >>>>> plateforme, >>>>> - mettre le tag "bus=yes" sur le stop >>>>> - reprendre la relation "route" et placer les deux noeuds (le "stop" >>>>> d'abord suivi de la platforme) >>>>> - vérifier l'ordre de succession des stop/platform dans la liste >>>>> - la route ensuite peut avoir des ""from=*", "via=*" et "from=*" mais >>>>> ils ne sont pas obligés de mentionner le nom exact local de l'arrêt >>>>> (figurant sur place) >>>>> >>>>> La "description=*" de la route peut avoir besoin d'indiquer en plus du >>>>> numéro (commercial) de ligne la direction mais pas nécessairement le nom >>>>> du >>>>> dernier arrêt, elle peut mentionner juste le nom simplifié dans "to", ou >>>>> bien lui ajouter une désambiguisation "Commune (arrêt)", par exemple >>>>> "Trifouillis-lès-Oies (Mairie)", même si l'arrêt sur place s'appelle >>>>> seulement "Mairie": sur une même ligne les noms d'arrêts sont le plus >>>>> souvent simplifiés, de même la direction d'une ligne affichée sur les bus, >>>>> quu peut être juste le nom de la commune suivante, les bus pouvant >>>>> maintenant changer dynamiquement cet affichage au cours de son parcours, >>>>> au >>>>> début ils vont mentionner le nom d'une commune, puis le nom d'un quartier, >>>>> puis le nom de l'arrêt final, ce qui faciliter la vie pour les usagers qui >>>>> peuvent confondre les numéros de lignes) >>>>> >>>>> Quand on a pu enfin construire correctement toutes les routes (une par >>>>> direction et par variante d'itinéraire), on peut les réunir dans une >>>>> relation "route_master" (pas besoin de rôle spécifique, ni même de >>>>> préciser >>>>> la version du schéma de transport). >>>>> >>>>> Puis rassembler toutes les lignes (relations "route_master") dans une >>>>> relation "network". >>>>> >>>>> ---- >>>>> >>>>> Noter aussi que la proposition des "segments de route" devrait aussi >>>>> permettre de prendre en compte des lignes qui partagent en partie certains >>>>> bus sous plusieurs numéros de lignes (parfois pour des réseaux >>>>> différents): >>>>> une "route" en revanche ne doit concerner qu'un seul numéro de ligne sur >>>>> un >>>>> seul réseau: ce cas est courant pour les liaisons longue distance dont une >>>>> partie seulement est prise en charge par une collectivité ou un EPCI dans >>>>> son réseau de transport: on a des cas de partages de lignes >>>>> interrégionaux, >>>>> intercommunaux, inter-EPCI, et des cas même où une liaison n'est pas >>>>> entièrement publique mais fait partie d'une offre d'un transport privé, >>>>> qui >>>>> n'est sous contrat avec la collectivité que dans son secteur et pas sur le >>>>> reste. >>>>> >>>>> Ces partages de liaisons (pour plusieurs lignes diférentes) existent >>>>> aussi bien pour les bus, que le train, exactement comme dans le transport >>>>> aérien (où cela se pratique tous les jours entre affrêteurs d'avions, >>>>> compagnies aériennes et agences de voyage), du fait que pour les >>>>> transports >>>>> publics les territoires (le plus souvent les EPCI aujourd'hui ou des >>>>> syndicats mixtes groupant plusieurs EPCI) ont obtenu des monopoles et une >>>>> compétence exclusive (qui interdisent aux autres collectivités sur leur >>>>> territoire de négocier ou subventionner individuellement des >>>>> transports avec des opérateurs privés). >>>>> >>>>> >>>>> Le 21 octobre 2016 à 18:03, Florian LAINEZ <[email protected]> a >>>>> écrit : >>>>> >>>>>> Merci encore pour vos réponses, j'ai affiné ma présentation en >>>>>> intégrant vos différentes idées https://slides.com/overflorian >>>>>> /busstopcollector/ >>>>>> >>>>>> Tu veux intégrer de l'OCR (reconnaissance optique de caractères) pour >>>>>>> avoir les noms des arrêts ? ;-). >>>>>>> >>>>>> je garde l'idée pour la v10 ! Plus sérieusement tes suggestions >>>>>> concernant la collecte de GPX / photos sont très pertinentes. >>>>>> >>>>>> Pas mis à jour depuis longtemps mais cette application avait la >>>>>>> vocation de mapper les arrêts de transport >>>>>>> http://makinacorpus.github.io/osm-transport-editor/#/ >>>>>> >>>>>> J'avais déjà vu passé ça mais j'avais oublié son existence ! Je vais >>>>>> contacter le développeur pour lui faire part de mon projet, merci >>>>>> >>>>>> Dans ta "présentation tu parles "Edit bus stops details: name, >>>>>>> direction, bus line". Bus_line et direction sont tagués sur le bus_stop >>>>>>> ? >>>>>>> Je ne trouve rien sur le wiki, j'ai raté des choses je pense ! >>>>>> >>>>>> >>>>>> +1 >>>>>> la ligne est portée par la ou les relations ("name" ou "ref") ainsi >>>>>> que la direction ("to") >>>>>> >>>>>> "highway=bus_stop" fait partie de l'ancien modèle, il me semble >>>>>> qu'il vaut mieux utiliser le nouveau "public_transport=stop_position" >>>>>> >>>>>> >>>>>> Si on regarde le Schéma : https://wiki.openstreetmap.org >>>>>> /wiki/FR:Key:public_transport#Sch.C3.A9ma_en_bref - si on reste dans >>>>>> le bus, on va tagger uniquement l'endroit où s’arrête le bus " >>>>>> stop_position" ou l'endroit où attendent les passagers "platform" >>>>>> qui n'est pas forcément à la hauteur de là où s'est arrête le bus. >>>>>> >>>>>> Je détaille bien dans ma présentation le fait que je m'intéresse pour >>>>>> l'instant aux points d'attente des passagers et que le point d'arrêt du >>>>>> bus >>>>>> viendra peut-être plus tard. >>>>>> >>>>>> Concernant les tags à utiliser, je pense qu'il est prématuré d'en >>>>>> parler, je ne suis qu'à débroussailler ce que pourrait être l'appli pour >>>>>> l'instant. Ceci dit je suis tout à fait au fait de la problématique >>>>>> ancien >>>>>> modèle VS nouveau modèle public_transport. >>>>>> >>>>>> D'autres idées / remarques ? >>>>>> >>>>>> Le 21 octobre 2016 à 10:14, lenny.libre <[email protected]> a >>>>>> écrit : >>>>>> >>>>>>> >>>>>>> Le 21/10/2016 à 08:45, Vincent Bergeot a écrit : >>>>>>> >>>>>>> Le 20/10/2016 à 11:26, Florian LAINEZ a écrit : >>>>>>> >>>>>>> >>>>>>> dans le bus je me sers d'un thème quasi identique à celui là : >>>>>>>> https://www.cartes.xyz/t/04e491-Arrets_de_bus__Florian# >>>>>>> >>>>>>> @vincent tu m'as bien compris, c'est exactement ce que j'aimerai >>>>>>> faire avec un interface pour les débutants. Il manque aussi à ton outil >>>>>>> la >>>>>>> gestion des lignes : il est difficile de voir quels arrêts sont sur la >>>>>>> même >>>>>>> ligne, or ça me parait être clef pour la simplicité de contribution. >>>>>>> >>>>>>> yep, je crois comprendre. >>>>>>> Cela devient plus une question de "rendu" que de données si je >>>>>>> comprends bien. Imaginer les couleurs correspondantes aux lignes et les >>>>>>> arrêts associés. >>>>>>> Effectivement, en mettant le rendu transport sur le thème précédent, >>>>>>> c'est déjà un peu plus clair. >>>>>>> >>>>>>> Dans ta "présentation tu parles "Edit bus stops details: name, >>>>>>> direction, bus line". Bus_line et direction sont tagués sur le bus_stop >>>>>>> ? >>>>>>> Je ne trouve rien sur le wiki, j'ai raté des choses je pense ! >>>>>>> >>>>>>> +1 >>>>>>> la ligne est portée par la ou les relations ("name" ou "ref") >>>>>>> ainsi que la direction ("to") >>>>>>> >>>>>>> "highway=bus_stop" fait partie de l'ancien modèle, il me semble >>>>>>> qu'il vaut mieux utiliser le nouveau "public_transport=stop_position" >>>>>>> >>>>>>> >>>>>>> Si on regarde le Schéma : https://wiki.openstreetmap.org >>>>>>> /wiki/FR:Key:public_transport#Sch.C3.A9ma_en_bref - si on reste >>>>>>> dans le bus, on va tagger uniquement l'endroit où s’arrête le bus " >>>>>>> stop_position" ou l'endroit où attendent les passagers "platform" >>>>>>> qui n'est pas forcément à la hauteur de là où s'est arrête le bus. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Et pour les relations, à voir avec la requête overpass qui le fait ! >>>>>>> >>>>>>> PS : je suis conscient que cela ne correspond pas à certaines de tes >>>>>>> attentes (off-line, interface plus simple, android, ...) mais cela me >>>>>>> permet aussi d'avancer sur un thème arrêt de bus pour que ta mère puisse >>>>>>> s'en servir une fois qu'elle aura commencé avec ton idée d'application >>>>>>> :) >>>>>>> >>>>>>> -- >>>>>>> Vincent Bergeot >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-fr mailing list >>>>>>> [email protected] >>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Florian Lainez* >>>>>> @overflorian <http://twitter.com/overflorian> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-fr mailing list >>>>>> [email protected] >>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-fr mailing list >>>>> [email protected] >>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Florian Lainez* >>>> @overflorian <http://twitter.com/overflorian> >>>> >>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >> >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
