JOSM ne donen pas d'anomalie de ce point de vue là: il tente d'ordonner les ways ensemble en les connectant mais il ne sait pas déterminer la direction et peut les ordonner en sens inverse du parcours s'il commence par le dernier way pris en sens inverse de son tracé (ce qui est souvent le cas des rues bidirectionelles, ou des rues een sens unique mais prises à contre-sens par les bus!).
Faites l'essai avec des "route" qui comportent des autointersections avec elles-mêmes, JOSM ne sait pas quoi faire et peut les interconnecter n'importe comment. C'est moins souvent le cas quand on a séparé les deux sens de la ligne dans des "route" différentes, mais ces cas arrivent encore. Mais JOSM ne change PAS l'ordre relatif des arrêts (stop et platform), il est incapable de le décider. Ceci dit, que les arrêts soient triés avant ou après les ways ou au milieu n'a effetitvement aucune importance. Mais leur ordre relatif est encore essentiel, mais ce n'est pas JOSM qui est le problème ici. Le 25 octobre 2016 à 14:18, Francescu GAROBY <windu...@gmail.com> a écrit : > Je rejoins Florian : techniquement parlant, rien n'oblige à ce que les > éléments qui composent une relation soient dans le bon ordre. D'ailleurs, > JOSM ne les trie pas comme il faut : il met d'abord toutes les ways, puis > tous les nodes. > L'important est que le tracé soit complet (aucun bout de way manquant), > que les "stop_position" soient bien présents (comme ils appartiennent en > même temps à une way déjà présente dans la relation, on peut donc les > trier, du point de départ au terminus, en se basant sur les tags "from" et > "to de ladite relation). Avec tout ça, on peut alors retrouver le > "platform" correspondant (il se trouve dans la même relation "stop_area" > que le "stop_position"). > > Francescu > > Le 25 octobre 2016 à 12:18, Florian LAINEZ <winner...@free.fr> a écrit : > >> J'adore parler aux gens qui ont les arrêts de bus comme TOC ! Ce n'est >> pas aussi exotique que les PEI mais c'est tout aussi sympa ;) >> >> Cool ta webapp Noémie, j'imagine que cela fait suite au premier draft que >> tu avais fait auparavant et qui n'est plus en ligne. >> Par contre je n'arrive pas à ajouter une ligne de bus à un arrêt, même >> connecté avec mon compte OSM. Quand je clique sur "modifier", la liste des >> lignes apparait bien mais simplement sous forme de liste avec des bullet >> points. Est-ce normal ? (je suis bien en ile-de-france, à >> savignys-sous-orge). >> >> Les limitations que tu mentionnes (relation préexistante obligatoire...) >> sont bien compréhensibles, par contre je ne comprends pas pourquoi tu mets >> un fixme et que tu es obligée de retraiter la relation à posteriori. >> Si tu mettais directement un rôle platform à l'arrêt rajouté dans la >> relation de la ligne, ce ne serait pas plus propre ? >> >> Sinon, pour terminer, en effet, Maps Me est très utile. J'étudie en ce >> moment la possibilité de le forker pour en faire un éditeur spécifique. >> Est-ce que vous pensez que ça vaut le coup ? Sinon on pourrait écrire le >> code pour eux pour essayer de l'intégrer direct à l'appli ? Good/bad idea? >> >> L'appli est plutôt destinée à cartographier dans le bus ou à pied en se >>> promenant ? >>> Si c'est dans le bus, c'est une contrainte à ne pas minimiser : c'est >>> assez difficile de bien cartographier en prenant le bus, il y a peu de >>> temps et beaucoup de choses à regarder. >>> >> Je ne sais pas encore, je requiert justement votre aide pour préciser les >> vrais besoins de cette appli. >> Jusqu'à présent je pensais plutôt à un éditeur assez classique qui puisse >> être utilisé partout mais peut-être qu'une appli plus spécifique serait >> plus adaptée ... je pense notamment à détecter automatiquement que >> l'utilisateur est dans le bus dans lequel, puis zoomer automatiquement sur >> le prochain arrêt à mapper en mettant en évidence les infos manquantes. >> Ce ne sont pour l'instant que des idées, merci pour vos retours >> >> Le 24 octobre 2016 à 20:25, Noémie Lehuby <noemie.leh...@openmailbox.org> >> a écrit : >> >>> Bonjour, >>> >>> Pour cartographier les arrêts de bus (qui sont l'un de mes TOCs), je me >>> suis faite une petite webapp. Elle est accessible à cette adresse : >>> https://microcosm.5apps.com/poi.html?poi_type=bus_stop#18/48 >>> .84885/2.37222 All bugs included ! >>> >>> Elle permet de modifier le nom des arrêts existants, et d'y indiquer les >>> lignes de bus qui y passent (en idf uniquement) >>> On ne peut enrichir que des lignes où la relation route existe déjà dans >>> OSM et est pas trop mal renseignée (pour la retrouver dans >>> l'auto-complétion, il faut que network, ref et to soient renseignés) >>> Lorsqu'on ajoute la ligne sur un arrêt dans l'appli, ça ajoute le nœud >>> comme dernier élément de la relation, avec un rôle fixme. >>> Reste encore à repasser dessus chez soi pour remettre de l'ordre dans la >>> relation. >>> >>> Ça ne permet pas de créer les arrêts de bus manquants, j'utilise Maps.me >>> pour cela. >>> Je pense d'ailleurs que Maps.me est un bon candidat pour la maman de >>> Florian :p >>> Je leur ai déjà fait une issue github sur l'amélioration du rendu des >>> arrêts de bus : https://github.com/mapsme/omim/issues/1067 >>> >>> >>> L'appli est plutôt destinée à cartographier dans le bus ou à pied en se >>> promenant ? >>> Si c'est dans le bus, c'est une contrainte à ne pas minimiser : c'est >>> assez difficile de bien cartographier en prenant le bus, il y a peu de >>> temps et beaucoup de choses à regarder. >>> Quelque soit l'outil que j'utilise (OSM Tracker, Maps.me ou MicrocOSM), >>> j'ai rarement le temps de noter toutes les infos d'un arrêt avant que le >>> bus ne reparte. >>> >>> >>> C'est un beau challenge en tout cas, je suis curieuse de voir si on peut >>> tenir les objectifs proposés ;) >>> >>> Noémie >>> @nlehuby >>> >>> >>> Le 2016-10-23 23:42, talk-fr-requ...@openstreetmap.org a écrit : >>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 3 >>>> Date: Sun, 23 Oct 2016 23:41:47 +0200 >>>> From: Jo <winfi...@gmail.com> >>>> To: Philippe Verdy <verd...@wanadoo.fr> >>>> Cc: Discussions sur OSM en français <talk-fr@openstreetmap.org> >>>> Subject: Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus >>>> Message-ID: >>>> <caj6dwmcbwokb4grhfav+nesyc7tqyqy5e5ngvoypi8mti_v...@mail.gm >>>> ail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> >>>> 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 <verd...@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 <winfi...@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 <verd...@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 <winner...@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 <verd...@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 <winner...@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.li...@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@openstreetmap.org >>>>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Florian Lainez* >>>>>>>>>> @overflorian <http://twitter.com/overflorian> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Florian Lainez* >>>>>>>> @overflorian <http://twitter.com/overflorian> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-fr mailing list >>>>>>> Talk-fr@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/attachment >>>> s/20161023/0fd6945a/attachment.html> >>>> >>>> ------------------------------ >>>> >>>> Subject: Pied de page des remises groupées >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>>> >>>> ------------------------------ >>>> >>>> Fin de Lot Talk-fr, Vol 123, Parution 64 >>>> **************************************** >>>> >>> >> >> >> -- >> >> *Florian Lainez* >> @overflorian <http://twitter.com/overflorian> >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > > -- > Francescu > > _______________________________________________ > 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
