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

[Jo]

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/87a81a1e/attachment.htm>