[OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

Dim 23 Oct 21:41:47 UTC 2016

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 <verdy_p at wanadoo.fr>:

> 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 <winfixit at gmail.com> 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 <verdy_p at wanadoo.fr>:
>>
>>> 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 <winnerflo at free.fr> 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 <verdy_p at wanadoo.fr> 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 <winnerflo at free.fr> 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 <lenny.libre at orange.fr> 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
>>>>>>> Talk-fr at openstreetmap.org
>>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Florian Lainez*
>>>>>> @overflorian <http://twitter.com/overflorian>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Talk-fr mailing list
>>>>>> Talk-fr at openstreetmap.org
>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-fr mailing list
>>>>> Talk-fr at openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Florian Lainez*
>>>> @overflorian <http://twitter.com/overflorian>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161023/0fd6945a/attachment.htm>