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
<[email protected]> 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 :
Message: 3
Date: Sun, 23 Oct 2016 23:41:47 +0200
From: Jo <[email protected]>
To: Philippe Verdy <[email protected]>
Cc: Discussions sur OSM en français <[email protected]>
Subject: Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de
bus
Message-ID:
<caj6dwmcbwokb4grhfav+nesyc7tqyqy5e5ngvoypi8mti_v...@mail.gmail.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 <[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 [3])
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
[4]
/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/#/ [5]
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 [6]
/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# [7]
@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 [6]
/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 [8]
