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
