Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ordre)

[Florian LAINEZ]

Je ne souhaite par contre pas faire apparaitre les segments de route en
> tant qu'objets individuels. Il me semble plus intuitif de permettre de
> modifier le chemin en drag un point du segment qui recalculerait un
> itinéraire en conséquence. Par la suite c'est l'appli qui gérerait
> elle-même les segments à ajouter/supprimer de la relation. Pour vous donner
> une idée de ce comportement, il suffit de déplacer un point de départ ou
> d'arrivée lors d'un calcul d'itinéraire avec OSRM sur osm.org


Autre possibilité : dire par où ne doit pas passer la ligne (à la manière
d'OSMAND).

Peut-être qu'un outil web serait plus adapté qu'un outil mobile pour tracer
les chemins ? Je réfléchis à un outil web complémentaire en ce moment.

Le 27 octobre 2016 à 23:54, Philippe Verdy  a écrit :

>
>
> Le 27 octobre 2016 à 23:37,  a écrit :
>
>> Le 27/10/2016 à 02:27, Florian LAINEZ - winner...@free.fr a écrit :
>>
>> Je ne souhaite par contre pas faire apparaitre les segments de route en
>> tant qu'objets individuels. Il me semble plus intuitif de permettre de
>> modifier le chemin en drag un point du segment qui recalculerait un
>> itinéraire en conséquence. Par la suite c'est l'appli qui gérerait
>> elle-même les segments à ajouter/supprimer de la relation.
>> Pour vous donner une idée de ce comportement, il suffit de déplacer un
>> point de départ ou d'arrivée lors d'un calcul d'itinéraire avec OSRM sur
>> osm.org
>>
>> Autre possibilité : dire par où ne doit pas passer la ligne (à la manière
>> d'OSMAND).
>> Je pense qu'ordonner les arrêts est assez facile pour le non cartographe
>> : c'est en général écrit à l'arrêt.
>>
>> Le 27/10/2016 à 04:48, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> Les trajets des bus sont aussi dans l'opendata de la STAR (sous forme de
>> shape atteaché à un des attributs des lignes, un shape par direction)
>>
>> Bien-sûr les données libres ne sont pas à négliger.
>>
>> Actuellement elles sont partiellement signalées sur le wiki.
>>
>
> Juste parce que je j'ai mis à jour cette page pour intégrer le nouveau
> site Open Data de la STAR (qui remplace ceux, partiels, de Rennes Métropole
> et de Keolis). La STAR a communiqué récemment sur cette mise à dispo en
> open-data et sur l'utilisation des fonds de carte OSM dans ses affichages
> publics.
>
> En mentionnant les licences utilisées (ODbL pour presque tout, sauf les
> pictogrammes de numéros de lignes et les plans PDF sous licence CC-BY-ND,
>  et les pictogrammes de services de Keolis; les quelques données vendant du
> GEOFLA n'ont pas d'intérêt pour nous et ce qui est en CC-NY-ND n'est pas
> nécessaire pour nous).
>
> Certes il manque encore les lignes complémentaires (2NN) et scolaires
> (TsNNN) mais ça va venir, dit le site. Mais ces lignes sont codifiées, même
> si on ne les a pas dans le détail avec les arrêts et shapes.
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ordre)

[Philippe Verdy]

Le 27 octobre 2016 à 23:37,  a écrit :

> Le 27/10/2016 à 02:27, Florian LAINEZ - winner...@free.fr a écrit :
>
> Je ne souhaite par contre pas faire apparaitre les segments de route en
> tant qu'objets individuels. Il me semble plus intuitif de permettre de
> modifier le chemin en drag un point du segment qui recalculerait un
> itinéraire en conséquence. Par la suite c'est l'appli qui gérerait
> elle-même les segments à ajouter/supprimer de la relation.
> Pour vous donner une idée de ce comportement, il suffit de déplacer un
> point de départ ou d'arrivée lors d'un calcul d'itinéraire avec OSRM sur
> osm.org
>
> Autre possibilité : dire par où ne doit pas passer la ligne (à la manière
> d'OSMAND).
> Je pense qu'ordonner les arrêts est assez facile pour le non cartographe :
> c'est en général écrit à l'arrêt.
>
> Le 27/10/2016 à 04:48, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Les trajets des bus sont aussi dans l'opendata de la STAR (sous forme de
> shape atteaché à un des attributs des lignes, un shape par direction)
>
> Bien-sûr les données libres ne sont pas à négliger.
>
> Actuellement elles sont partiellement signalées sur le wiki.
>

Juste parce que je j'ai mis à jour cette page pour intégrer le nouveau site
Open Data de la STAR (qui remplace ceux, partiels, de Rennes Métropole et
de Keolis). La STAR a communiqué récemment sur cette mise à dispo en
open-data et sur l'utilisation des fonds de carte OSM dans ses affichages
publics.

En mentionnant les licences utilisées (ODbL pour presque tout, sauf les
pictogrammes de numéros de lignes et les plans PDF sous licence CC-BY-ND,
 et les pictogrammes de services de Keolis; les quelques données vendant du
GEOFLA n'ont pas d'intérêt pour nous et ce qui est en CC-NY-ND n'est pas
nécessaire pour nous).

Certes il manque encore les lignes complémentaires (2NN) et scolaires
(TsNNN) mais ça va venir, dit le site. Mais ces lignes sont codifiées, même
si on ne les a pas dans le détail avec les arrêts et shapes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ordre)

[osm . sanspourriel]

Le 27/10/2016 à 02:27, Florian LAINEZ - winner...@free.fr a écrit :

Je ne souhaite par contre pas faire apparaitre les segments de route 
en tant qu'objets individuels. Il me semble plus intuitif de permettre 
de modifier le chemin en drag un point du segment qui 
recalculerait un itinéraire en conséquence. Par la suite c'est l'appli 
qui gérerait elle-même les segments à ajouter/supprimer de la relation.
Pour vous donner une idée de ce comportement, il suffit de déplacer un 
point de départ ou d'arrivée lors d'un calcul d'itinéraire avec OSRM 
sur osm.org 
Autre possibilité : dire par où ne doit pas passer la ligne (à la 
manière d'OSMAND).
Je pense qu'ordonner les arrêts est assez facile pour le non cartographe 
: c'est en général écrit à l'arrêt.


Le 27/10/2016 à 04:48, Philippe Verdy - verd...@wanadoo.fr a écrit :
Les trajets des bus sont aussi dans l'opendata de la STAR (sous forme 
de shape atteaché à un des attributs des lignes, un shape par direction)


Bien-sûr les données libres ne sont pas à négliger.

Actuellement elles sont partiellement signalées sur le wiki.

Ça peut être une piste non seulement pour Omose canal OD mais aussi pour 
l'appli.


Deux problèmes :

- les formats à chaque fois différents (bon entre shp et geojson on doit 
couvrir pas mal de possibilités) mais les correspondances attributs sont 
différentes.


- les convergences et divergences. Le nom donné par le réseau a été 
proposé comme nom alternatif (en cas de divergence). localisation, nom 
doivent permettre de mettre une référence (ref: par 
exemple ref:fr_star et non juste ref:network comme proposait Marc à 
cause des arrêts et lignes partagées et donc les sources multiples - il 
parlait de name mais c'est sensiblement pareil) afin de faciliter le 
suivi (dont les arrêts partagés).


Peut-être peut-on pré-remplir la liste des arrêts et l'ordre.

Par exemple si on reprend la ligne C1 de la Star on voit que c'est 
l'itinéraire qui n'est pas à jour.


Mais j'en reviens à un de mes TOC : mettre le modèle dans la base. Car 
les règles que l'on met c'est bien mais typiquement les règles de Jérôme 
pourraient être portées par le réseau Star, au moins le lien vers les 
données.


un ref:fr_star doit permettre de remonter au réseau et sur le réseau on 
doit avoir l'adresse web, l'adresse des données libres (le cas échéant) 
et idéalement les règles de transformation. Peut-être qu'un lien sur un 
wiki c'est plus simple car moins formalisé.


Un petit XML/JSON pour expliquer la correspondance, des paramètres comme 
la distance pour considérer qu'un arrêt OD et un arrrêt OSM peuvent les 
mêmes, ça doit régler déjà pas mal de cas.


Ou est-ce encore trop le b... en OD ?

Si on arrive à le faire, plusieurs applis peuvent en profiter.
Y a-t-il des pratiquants pour savoir si chaque réseau est trop 
spécifique pour espérer y arriver ?


Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Ceci dit, "bus=yes" n'est pas recommandé sur "public_transport=platform"
(alors que la plateforme est justement le lieu d'échange intermodal), mais
bizarrement défini sur public_transport=stop_position (sur le trajet
spécifique d'un mode de transport).

De fait on a des:
  {"bus=yes", "tram=yes", "train=yes"}
sur les objets platform
  {en v2: "public_transport=platform";
  en v1 sur divers trucs: "highway=bus_stop", "railway=halt/station/...",
"subway=station"...
  }
Mais tout ça vient des confusions des objets "v1" et de leur migration en
v2: pour la compatibilité selon les applis et le temps que les mises à jour
s'y retrouvent, on peut donc trouver des nouveaux tags ajoutés aux anciens
objets avant de les enlever plus tard quand aura été fait le tri entre stop
et platform pour la v2 stricte.

Cependant je pense
  * qu'on doit encore garder highway=bus_stop et railway=halt, mais
uniquement sur les "platform" (hors du chemin) et même les y ajouter s'ils
manquent (car les applis pour utiliser la v2 ne sont pas encore prêtes);
  * mais plus du tout sur les "stop"/"stop_position" (sur les chemins) où
il faut les enlever

Au besoin créer un autre noeud platform à côté s'il manque
  --[ éventuellement avec un FIXME si la position est difficile à estimer,
bien que les plateformes sont en général assez longues, et qu'on voit le
marquage au sol des zones d'arrêt qui permettent de savoir où les passagers
peuvent attendre et estimer où est le panneau indicateur ; ce FIXME sera
pour savoir s'il y a un banc ou un abri ou si l'arrêt est adapté pour
l'accessibilité, sans marche vers la chaussée ou à niveau des entrées de
bus, sans pente et assez large dans la zone d'attente ]--
et ajouter cette nouvelle plateforme aux relations avec le bon rôle,
remplacer le rôle de l'ancien objet sur le chemin en "stop").


2016-10-27 2:37 GMT+02:00 Florian LAINEZ :

>
> Le 26 octobre 2016 à 23:19, Philippe Verdy  a écrit :
>
>> "highway=bus_stop" correspond à "public_transport=platform + bus=yes"
>
>
> bonne remarque.
> Je complète donc mon analyse :
>
>- Nombre de nodes en île-de-france :
>- 21 354 highway=bus_stop  dont 18 997 
> highway=bus_stop
>   sans public_transport=platform 
>   - 2 647 public_transport=platform 
>   dont 290 public=transport=plateform sans highway=bus_stop
>    dont 184 public_transport=platform
>   avec bus=yes mais sans highway=bus_stop
>   
>
> --
>
> *Florian Lainez*
> @overflorian 
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Florian LAINEZ]

Le 26 octobre 2016 à 23:19, Philippe Verdy  a écrit :

> "highway=bus_stop" correspond à "public_transport=platform + bus=yes"


bonne remarque.
Je complète donc mon analyse :

   - Nombre de nodes en île-de-france :
   - 21 354 highway=bus_stop  dont 18
997 highway=bus_stop
  sans public_transport=platform 
  - 2 647 public_transport=platform 
  dont 290 public=transport=plateform sans highway=bus_stop
   dont 184 public_transport=platform
  avec bus=yes mais sans highway=bus_stop
  

-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ordre)

[Florian LAINEZ]

@Philippe l'ensemble de ton email est HS : nous parlons d'une appli mobile,
pas de JOSM.

@Jean-Yvon je pense que nous sommes tous d'accord pour dire qu'il est
important d'ordonner. Néanmoins ma question portait plutôt sur l'appli
dédiée aux débutants que je souhaite développer : doit-on intégrer un tel
niveau de complexité pour des personnes qui ne maitrisent pas la carto ?
à la limite je suis prêt à considérer la possibilité d'ordonner les arrêts
(glisser-déposer via une liste) si vous arrivez à me convaincre de son
absolue nécessité. Pour l'instant, j'en doute.
Par contre l'ordonnancement des chemins me parait bien trop complexe à
gérer sur mobile.

> Possibilité de sélectionner un arrêt sur la carte pour l'ajouter ? Idem
> pour un chemin ?
>
Oui, il doit être simple d'ajouter un arrêt existant ou de créer un nouvel
arrêt en le reliant à une relation existante.

Je ne souhaite par contre pas faire apparaitre les segments de route en
tant qu'objets individuels. Il me semble plus intuitif de permettre de
modifier le chemin en drag un point du segment qui recalculerait un
itinéraire en conséquence. Par la suite c'est l'appli qui gérerait
elle-même les segments à ajouter/supprimer de la relation.
Pour vous donner une idée de ce comportement, il suffit de déplacer un
point de départ ou d'arrivée lors d'un calcul d'itinéraire avec OSRM sur
osm.org

merci encore pour vos idées, on progresse dans la réflexion ...

Le 27 octobre 2016 à 01:03, Philippe Verdy  a écrit :

> Je déconseille très fortement le "glisser-déposer" dans l'éditeur de
> relations de JOSM !!! Trop souvent fois au lieu de déposer les objets, JOSM
> les SUPPRIME instantanément de la relation (sans même poser la question) si
> on a le malheur de déposer sur les pixels séparant deux lignes (et ce n'est
> pas rare du tout !).
>
> C'est un vieux bogue non corrigé (d'ailleurs il arrive parfois que pendant
> un clic on glisse légèrement la souris de quelques pixels et JOSM croit
> qu'on veut faire un glisser-déposer, et se plante de la même façon !). Si
> on ne voit plus les membres qu'on avait sélectionné, il va falloir aller
> les rechercher à nouveau sur la carte). D'ailleurs JOSM n'aide pas non plus
> quand on valide la relation validée, car il n'indique pas le nombre de
> membres ajoutés ou supprimés dans son historique, il se contente juste de
> dire que la relation a été modifiée.
>
> Pour éviter des erreurs de manipulation quand on manipule des relations
> avec beaucoup d'éléments et pouvoir réparer, je commence par sélectionner
> tous les éléments pour les mettre tels quels dans une autre nouvelle
> relation (dans une autre fenêtre), sans me soucier des rôles et des tags,
> et je laisse cette fenêtre d'éditeur ouverte sans la valider. Ensuite je
> peux modifier la relation. Ceci fait, je vérifie qu'il ne manque aucun
> membre dans la relation en allant les re-sélectionner depuis la fenêtre
> voisine temporaire qui est encore ouverte: ces membres doivent tous
> apparaître surlignés en jaune dans la relation que je modifiait, sinon
> c'est qu'ils ont disparu, mais c'est facile de les remettre. Quand c'est
> terminé, je valide la relation, et j'annule la fenêtre temporaire qui me
> sert juste de "presse-papier".
>
> Cette méthode de "presse-papier" en revanche ne permet pas de détecter les
> membres qui devraient rester en "doublon" dans la relation (les chemins
> parcourus deux fois dans la ligne fait un détour... et parfois aussi
> certains arrêts desservis deux fois sachant que le bus a son indicateur qui
> affiche sur quelle partie de la ligne il est en indiquant soit un arrêt
> dans le détour soit celui du terminus) : il faut vérifier manuellement le
> nombre de doublons surlignés "en rose" dans les deux fenêtres. On aura le
> problème tant qu'on n'aura pas de "route segments"
>
> Pour ordonner les membres dans l'éditeur SANS glisser-déposer:
>  - sélectionner les membres au clavier (flèches et touche SHIFT pour un
> intervalle, ou CTRL pour ajouter/retirer un membre de la sélection) ou la
> souris,
> - puis utiliser les icônes monter/descendre de la barre latérale.
>
> Ensuite peu importe si on a groupé les ways en tête de la relation ou à la
> fin. Personnellement je préfère grouper les ways à la fin pour que les
> premiers membres visibles soient les noms des premiers arrêts (les chemins
> n'ont pas de nom évident), et ensuite grouper ensemble le "stop" nécessaire
> pour la v2 (l'icône: devrait être un gros point rouge) avec sa "plateform"
> (bus_stop de la v1, l'icone est celle d'un bus pour "bus", ou celle d'un
> poteau d'arrêt pour les platform v2). On peut vérifier visuellement qu'on
> ne s'est pas trompé de rôle.
>
> Au minimum la relation devrait avoir deux "stop" (donc deux icones "points
> rouges" ou "bus") ;  sur les lignes non circulaires, le premier "stop"
> devrait avoir son rôle suffixé "_entry_only", et le dernier un rôle suffixé
> "_exit_only". Dans un premier temps on n'est pas obligé d'avoir tous 

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ordre)

[Philippe Verdy]

Je déconseille très fortement le "glisser-déposer" dans l'éditeur de
relations de JOSM !!! Trop souvent fois au lieu de déposer les objets, JOSM
les SUPPRIME instantanément de la relation (sans même poser la question) si
on a le malheur de déposer sur les pixels séparant deux lignes (et ce n'est
pas rare du tout !).

C'est un vieux bogue non corrigé (d'ailleurs il arrive parfois que pendant
un clic on glisse légèrement la souris de quelques pixels et JOSM croit
qu'on veut faire un glisser-déposer, et se plante de la même façon !). Si
on ne voit plus les membres qu'on avait sélectionné, il va falloir aller
les rechercher à nouveau sur la carte). D'ailleurs JOSM n'aide pas non plus
quand on valide la relation validée, car il n'indique pas le nombre de
membres ajoutés ou supprimés dans son historique, il se contente juste de
dire que la relation a été modifiée.

Pour éviter des erreurs de manipulation quand on manipule des relations
avec beaucoup d'éléments et pouvoir réparer, je commence par sélectionner
tous les éléments pour les mettre tels quels dans une autre nouvelle
relation (dans une autre fenêtre), sans me soucier des rôles et des tags,
et je laisse cette fenêtre d'éditeur ouverte sans la valider. Ensuite je
peux modifier la relation. Ceci fait, je vérifie qu'il ne manque aucun
membre dans la relation en allant les re-sélectionner depuis la fenêtre
voisine temporaire qui est encore ouverte: ces membres doivent tous
apparaître surlignés en jaune dans la relation que je modifiait, sinon
c'est qu'ils ont disparu, mais c'est facile de les remettre. Quand c'est
terminé, je valide la relation, et j'annule la fenêtre temporaire qui me
sert juste de "presse-papier".

Cette méthode de "presse-papier" en revanche ne permet pas de détecter les
membres qui devraient rester en "doublon" dans la relation (les chemins
parcourus deux fois dans la ligne fait un détour... et parfois aussi
certains arrêts desservis deux fois sachant que le bus a son indicateur qui
affiche sur quelle partie de la ligne il est en indiquant soit un arrêt
dans le détour soit celui du terminus) : il faut vérifier manuellement le
nombre de doublons surlignés "en rose" dans les deux fenêtres. On aura le
problème tant qu'on n'aura pas de "route segments"

Pour ordonner les membres dans l'éditeur SANS glisser-déposer:
 - sélectionner les membres au clavier (flèches et touche SHIFT pour un
intervalle, ou CTRL pour ajouter/retirer un membre de la sélection) ou la
souris,
- puis utiliser les icônes monter/descendre de la barre latérale.

Ensuite peu importe si on a groupé les ways en tête de la relation ou à la
fin. Personnellement je préfère grouper les ways à la fin pour que les
premiers membres visibles soient les noms des premiers arrêts (les chemins
n'ont pas de nom évident), et ensuite grouper ensemble le "stop" nécessaire
pour la v2 (l'icône: devrait être un gros point rouge) avec sa "plateform"
(bus_stop de la v1, l'icone est celle d'un bus pour "bus", ou celle d'un
poteau d'arrêt pour les platform v2). On peut vérifier visuellement qu'on
ne s'est pas trompé de rôle.

Au minimum la relation devrait avoir deux "stop" (donc deux icones "points
rouges" ou "bus") ;  sur les lignes non circulaires, le premier "stop"
devrait avoir son rôle suffixé "_entry_only", et le dernier un rôle suffixé
"_exit_only". Dans un premier temps on n'est pas obligé d'avoir tous les
arrêts ("stop"), tant qu'on a toutes les stations ("platform"  ou
"bus_stop"). Cependant l'outil "sketch_line" ne cherche encore que les
"platform" ou "bus-stop" et semble ne pas prendre en compte encore les
"stop": les deux terminus devraient donc avoir les deux types d'objet
("stop" et "platform"~"bus_stop").



Le 27 octobre 2016 à 00:08,  a écrit :

> Aussi d'accord pour ordonner : même si dans certains cas ce n'est pas
> strictement nécessaire, c'est dans tous les cas beaucoup plus simple. Même
> tout simplement pour les vérifications manuelles.
>
> Si les arrêts sont numérotés dans l'ordre de la relation et les chemins
> sinon numérotés au moins avec un dégradé, on doit voir si c'est correct ou
> pas.
>
> Un glisser/déposer dans la liste des arrêts pour réordonnancer ?
>
> Idem pour les chemins ?
>
> Possibilité de sélectionner un arrêt sur la carte pour l'ajouter ? Idem
> pour un chemin ?
>
> Oui, pour la V2 ;-)
>
> Je pense que si à partir d'un arrêt de bus (sans doute via les relations
> définissant les lignes) on arrivait à remonter au niveau du Réseau et si
> avec le réseau et le nom de la ligne on avait une url nous donnant le
> trajet, on aurait déjà une aide à la vérification (comme ici je suis allé
> voir la star pour trouver, mais si je n'avais été dans la coin je ne
> saurais pas aller sur star.fr à partir d'un arrêt de bus desservi par la
> Star.
>
> N. B. : c'est vrai que des réseaux sont moins complets que celui de la
> Star qui pourtant est incorrect.
>
> Jean-Yvon
>
___
Talk-fr mailing 

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ordre)

[osm . sanspourriel]

Aussi d'accord pour ordonner : même si dans certains cas ce n'est pas 
strictement nécessaire, c'est dans tous les cas beaucoup plus simple. 
Même tout simplement pour les vérifications manuelles.


Si les arrêts sont numérotés dans l'ordre de la relation et les chemins 
sinon numérotés au moins avec un dégradé, on doit voir si c'est correct 
ou pas.


Un glisser/déposer dans la liste des arrêts pour réordonnancer ?

Idem pour les chemins ?

Possibilité de sélectionner un arrêt sur la carte pour l'ajouter ? Idem 
pour un chemin ?


Oui, pour la V2 ;-)

Je pense que si à partir d'un arrêt de bus (sans doute via les relations 
définissant les lignes) on arrivait à remonter au niveau du Réseau et si 
avec le réseau et le nom de la ligne on avait une url nous donnant le 
trajet, on aurait déjà une aide à la vérification (comme ici je suis 
allé voir la star pour trouver, mais si je n'avais été dans la coin je 
ne saurais pas aller sur star.fr à partir d'un arrêt de bus desservi par 
la Star.


N. B. : c'est vrai que des réseaux sont moins complets que celui de la 
Star qui pourtant est incorrect.


Jean-Yvon



Le 26/10/2016 à 23:41, Philippe Verdy - verd...@wanadoo.fr a écrit :
Dans le message qur tu cites on parle de "quelqu'un qui expérimente". 
Certes je suis en train de travailler dessus, mais c'est déjà le 
désordre et je n'expérimente pas, puisque c'est une schéma v2 
approuvé. Il manque des tas de détails et des erreurs il y en avait 
déjà avant dans les centaines de routes pas toutes au point (et il en 
manque encore pas mal).
C'est ce tri à faire qui représente pas mal de travail (pas qu'à 
Rennes d'ailleurs même si le réseau est "modèle" dans OSM, car pour 
les réseaux parisiens c'est encore pire!)


C'est un gros chantier qui ne peut pas se faire en une fois, rien que 
pour arriver au stade de la v2 (poser tous les "stop" manquants), 
sachant qu'il y aura une v3 pour les problèmes qui subsistent sur 
l'ordre des parcours, et le sens réel: à défaut en attendant, il FAUT 
ordonner, sinon on ne s'en sort pas.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (Rennes)

[Philippe Verdy]

Dans le message qur tu cites on parle de "quelqu'un qui expérimente".
Certes je suis en train de travailler dessus, mais c'est déjà le désordre
et je n'expérimente pas, puisque c'est une schéma v2 approuvé. Il manque
des tas de détails et des erreurs il y en avait déjà avant dans les
centaines de routes pas toutes au point (et il en manque encore pas mal).
C'est ce tri à faire qui représente pas mal de travail (pas qu'à Rennes
d'ailleurs même si le réseau est "modèle" dans OSM, car pour les réseaux
parisiens c'est encore pire!)

C'est un gros chantier qui ne peut pas se faire en une fois, rien que pour
arriver au stade de la v2 (poser tous les "stop" manquants), sachant qu'il
y aura une v3 pour les problèmes qui subsistent sur l'ordre des parcours,
et le sens réel: à défaut en attendant, il FAUT ordonner, sinon on ne s'en
sort pas.

Le 26 octobre 2016 à 23:26,  a écrit :

> C'est la ligne 13 qui a repris une partie de la 33 qui passe par les deux
> arrêts.
>
> Remarquez au passage que Chantepie Eglise a retrouvé sa majuscule et on y
> a adjoint Meslan pour distinguer les deux arrêts.
> Cucé, Chantepie
> 
> Edefs, Chantepie
> 
> Hallouvry, Chantepie
> 
> Bourgogne, Chantepie
> 
> Chantepie Eglise, Meslan
> 
> Chantepie Mairie, Chantepie
> 
> Loges, Chantepie
> 
> Rocade Sud, Chantepie
> 
> Val Blanc, Chantepie
> 
> La Poterie, Rennes
> 
> Galicie, Rennes
> 
> Le Blosne, Rennes
> 
> Hôpital Sud, Rennes
> 
> Torigné, Rennes
> 
> Triangle, Rennes
> 

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (Rennes)

[osm . sanspourriel]

C'est la ligne 13 qui a repris une partie de la 33 qui passe par les 
deux arrêts.


Remarquez au passage que Chantepie Eglise a retrouvé sa majuscule et on 
y a adjoint Meslan pour distinguer les deux arrêts.


Cucé, Chantepie 
 

Edefs, Chantepie 
 

Hallouvry, Chantepie 
 

Bourgogne, Chantepie 
 

Chantepie Eglise, Meslan 
 

Chantepie Mairie, Chantepie 
 

Loges, Chantepie 
 

Rocade Sud, Chantepie 
 

Val Blanc, Chantepie 
 

La Poterie, Rennes 
 

Galicie, Rennes 
 

Le Blosne, Rennes 
 

Hôpital Sud, Rennes 
 

Torigné, Rennes 
 

Triangle, Rennes 
 

Binquenais Collège, Rennes 
 

Binquenais, Rennes 
 

Combes, Rennes 
 

Clemenceau, Rennes 

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

[Philippe Verdy]

"highway=bus_stop" correspond à "public_transport=platform + bus=yes"
Si tu oublies bus=yes, tu ne verras pas l'icône à côté du chemin.

Pourquoi ce changement ? Parce que le même noeud peut correspondre à une
plateforme pour bus, tramway, taxi, auto-partage, vélo-partage...

En cela la v2 ne change pas les choses et acceptent les deux façons de
taguer ces noeuds. La grosse différence de la v2 c'est incorporation des
"platform" et la séparation des routes dans chaque direction.

La v3 ce sera pour les "route segments" (si ça se décide) et pour
explicitement marquer les "stop" de départ et d'arrivée, mais en attendant
on n'a pas d'autre choix que d'ordonner les chemins et les "stop" (pour les
"platform" cela ne semble pas nécessaire, la v2 permet déjà de les
regrouper avec les "stop" dans une "stop_area", et pour déterminer le
trajet de la ligne elle-meme on n'a pas du tout besoin des "platform",
juste des ways et des "stop" qui devraient être posés dessus).

Malheureusement très rares sont les noeuds qui sont réellement des "stop"
(les "bus_stop" ne devraient pas être sur le chemin, mais on en trouve et
là ce ne sont pas des "plateform" mais bien des "stop"). Ce qui signifie
qua la plupart des routes actuelles ont mentionné à tord le rôle "stop"
pour les noeuds "bus_stop" ("public_transport=platform"+"bus=yes") alors
qu'ils devraient avoir des rôles "platform".

De fait les routes n'ont pas d'itinéraite précis en v1, puisque ce ne sont
qeu des collections de chemins sans même la possibilité de savoir leur
ordre réel (à cause des intersections éventuelles), ni même leur sens : on
ne peut pas déterminer en v1 d'où on part et où on va (il n'y a que les
tags mal fichus "from=*", "via=*" et "to=*" mais ils sont difficiles à
rapprocher). Cela aurait dû être mis plus en avant pour élever les mérites
de la v2, tout en sachant que ce n'est pas encore suffisant.

La transition essentielle de la v2 est cependant bien de
- distinguer "stop" et "platform" (bus_stop/tram_stop et autres stations
dans les gares) en faisant le tri
- séparer les routes d'une même ligne selon leur direction et l'ensemble
des chemins suivis (mais malheureusement on ne sait toujours pas les trier
et déterminer leur sens).
Rien que ça c'est le plus gros du travail de tri à faire.

Tous ces défauts sont gênant pour faire de la planification d'itinéraire
dans un réseau et déterminer les lignes à prendre, les directions et
connaitre les ordres de passage, et enfin estimer un temps de trajet
global: le traitement ne se fait "qu'à vue de nez" par une interprétation
humaine (non exempte de pas mal d'erreurs et d'oublis si on ne connait pas
déjà bien le réseau localement, donc on ne peut pas viser le public cherché
pour gérer ces recherches d'itinéraires)






Le 26 octobre 2016 à 21:40, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit :

> Le 26 octobre 2016 à 21:29, Florian LAINEZ  a écrit :
>
>> L'idée d'ajouter l'arrêt à la relation avec le tag fixme c'est aussi pour
>>> gérer le fait que les deux modèles de carto des lignes de bus ne sont pas
>>> vraiment rétro-compatibles.
>>>
>> J'ai fait quelques stats et il semble que l'on soit malheureusement
>> encore très loin d'avoir terminé la transition :/
>>
>>- Nombre d'objets dans le monde :
>>- 1 742 350 highway=bus_stop
>>   
>>   - 620 053 public_transport=platform
>>   
>> 
>>   - Nombre de nodes en île-de-france :
>>- 21 354 highway=bus_stop  dont 18
>>   997 highway=bus_stop sans public_transport=platform
>>   
>>   - 2 647 public_transport=platform 
>>   dont 290 public=transport=plateform sans highway=bus_stop
>>   
>>
>> Bonjour,
>
> Et en croisant avec *public_transport=stop_position* ?
>
> Certains arrêts en modèle v2 gardent l'ancien tag *highway=bus_stop*
> "pour le rendu" (Mapnik n'affiche pas les *stop_position*)
>
> PY
>
> ___
> 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

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus (ou pour Osmose ?)

[osm . sanspourriel]

Tiens dans la partie cantepienne de la relation je vois plusieurs choses 
intéressantes pour l'appli ou Osmose :


http://www.openstreetmap.org/relation/399050#map=16/48.0878/-1.6143

De deux choses l'une :

- soit les arrêts Bourgogne et Hallouvry sont desservis (ils sont sur le 
trajet)

- soit ils ne le sont pas.

Dans le premier cas l'arrêt Chantepie Église est faux (c'est l'autre qui 
est le bon)

Dans le second cas le trajet indiqué est faux.

Dans ma bonté j'ai voulu regarder ce que disait star.fr
Verdict : c'est le trajet qui n'est pas à jour.
Remarquez l'in-homognénéité des noms et des casses allant jusqu'à la 
faute grossière (chantepie en minuscules).


En cas de divergence name:network:fr-star= ?


 * 23h14 Touche Annette (Chantepie)
 * 23h15 Gériatrie (Chantepie)
 * 23h16 Deux Ruisseaux (Chantepie)
 * 23h16 chantepie Eglise
 * 23h17 Chantepie Mairie (Chantepie)
 * 23h18 Loges (Chantepie)
 * 23h20 Sauvaie (Rennes)
 * 23h21 CARSAT (Rennes)
 * 23h22 Domaine (Rennes)
 * 23h23 Landry (Rennes)
 * 23h24 Villebois Mareuil (Rennes)
 * 23h24 Raison (Rennes)
 * 23h25 Mouézy (Rennes)
 * 23h26 Croix Saint-Hélier (Rennes)
 * 23h28 Laënnec (Rennes)
 * 23h29 Gares (Rennes)
 * 23h30 Champs Libres (Rennes)
 * 23h31 Liberté TNB (Rennes)
 * 23h33 Les Halles (Rennes)
 * 23h45 République (Rennes)
 * 23h47 Champ Jacquet (Rennes)
 * 23h48 Sainte-Anne (Rennes)
 * 23h50 Hôtel Dieu (Rennes)
 * 23h51 Sévigné (Rennes)
 * 23h53 Fac de Droit (Rennes)
 * 23h53 Guéhenno (Rennes)
 * 23h55 Metz Volney (Rennes)
 * 23h56 Painlevé (Rennes)
 * 23h57 Assomption (Rennes)
 * 23h59 Turmel (Rennes)
 * 00h00 Mirabeau (Rennes)
 * 00h01 Donzelot (Rennes)
 * 00h01 Gallet (Rennes)
 * 00h02 Bouzat (Rennes)
 * 00h03 Longs Champs (Rennes)
 * 00h04 Cesson Hôpital Privé (Rennes) (Cesson-Sévigné)
 * 00h05 Chêne Germain (Cesson-Sévigné)


Il nous propose les offres de covoiturage (à cause des horaires ?) et le 
trajet va entre les deux points via la limite sud ouest des eaux 
territoriales (au large de Sein).

Intéressant.
Et me dit qu'en bus je consomme 72 713 g contre 1 401 en voiture..

Le 26/10/2016 à 22:43, mga_geo - mga_...@yahoo.fr a écrit :

Calimero suite ...

Toujours sur Rennes, j'ai un autre utilisateur très connu qui expérimente
des tags en plus d'autres modifications dont la source ne m'est pas connue.
Certes ces tags sont définis dans
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport mais
la difficulté sur un réseau de transport est d'avoir une certaine
homogénéité qui facilite l'automatisation de sa maintenance lorsqu'une
source opendata est disponible.

Pour voir comment une relation a été modifiée, la page
http://osm.virtuelle-loipe.de/history/?type=relation=399050 est très
utile.





--
View this message in context: 
http://gis.19327.n8.nabble.com/Appli-mobile-pour-mapper-les-arrets-de-bus-tp5884605p5884980.html
Sent from the France mailing list archive at Nabble.com.

___
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

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

[mga_geo]

Calimero suite ...

Toujours sur Rennes, j'ai un autre utilisateur très connu qui expérimente
des tags en plus d'autres modifications dont la source ne m'est pas connue.
Certes ces tags sont définis dans
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport mais
la difficulté sur un réseau de transport est d'avoir une certaine
homogénéité qui facilite l'automatisation de sa maintenance lorsqu'une
source opendata est disponible.

Pour voir comment une relation a été modifiée, la page
http://osm.virtuelle-loipe.de/history/?type=relation=399050 est très
utile.





--
View this message in context: 
http://gis.19327.n8.nabble.com/Appli-mobile-pour-mapper-les-arrets-de-bus-tp5884605p5884980.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Yves Berrard]

Le 26 octobre 2016 à 21:29, Florian LAINEZ  a écrit :

> L'idée d'ajouter l'arrêt à la relation avec le tag fixme c'est aussi pour
>> gérer le fait que les deux modèles de carto des lignes de bus ne sont pas
>> vraiment rétro-compatibles.
>>
> J'ai fait quelques stats et il semble que l'on soit malheureusement encore
> très loin d'avoir terminé la transition :/
>
>- Nombre d'objets dans le monde :
>- 1 742 350 highway=bus_stop
>   
>   - 620 053 public_transport=platform
>   
>   - Nombre de nodes en île-de-france :
>- 21 354 highway=bus_stop  dont 18 997 
> highway=bus_stop
>   sans public_transport=platform 
>   - 2 647 public_transport=platform 
>   dont 290 public=transport=plateform sans highway=bus_stop
>   
>
> Bonjour,

Et en croisant avec *public_transport=stop_position* ?

Certains arrêts en modèle v2 gardent l'ancien tag *highway=bus_stop* "pour
le rendu" (Mapnik n'affiche pas les *stop_position*)

PY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Florian LAINEZ]

>
> L'idée d'ajouter l'arrêt à la relation avec le tag fixme c'est aussi pour
> gérer le fait que les deux modèles de carto des lignes de bus ne sont pas
> vraiment rétro-compatibles.
>
J'ai fait quelques stats et il semble que l'on soit malheureusement encore
très loin d'avoir terminé la transition :/

   - Nombre d'objets dans le monde :
   - 1 742 350 highway=bus_stop
  
  - 620 053 public_transport=platform
  
  - Nombre de nodes en île-de-france :
   - 21 354 highway=bus_stop  dont 18
997 highway=bus_stop
  sans public_transport=platform 
  - 2 647 public_transport=platform 
  dont 290 public=transport=plateform sans highway=bus_stop
  



> Vu que l'ancien modèle est encore assez répandu, mettre un rôle platform
> automatiquement ne me semble pas très pertinent : ça ne me choque pas de
> voir une ligne de bus cartographiée avec l'ancien modèle, mais ça me pique
> les yeux d'en voir une avec des arrêts marqués comme stop et d'autres
> marqués comme platform.
>
ça pique les yeux mais n'est-ce pas préférable venant d'une application qui
est faite pour le grand public et qui cache cette complexité ? je pose la
question sans avoir de préférence pour l'instant et pour décider ensemble
du meilleur comportement à adopter.

>
> Et l'ordre des arrêts me semble important Francescu. Si sketch-line
> n'arrive pas à comprendre quel est l'origine et quelle est la destination
> de la ligne, c'est quand même dommage :p : https://nlehuby.5apps.com/ordr
> e-des-arrets-de-bus-dans-osm.html

L'ordre est en effet important, merci pour le billet qui est très clair.
Néanmoins cela ne me parait pas primordial pour une première version de
l'application mobile. L'appli vise tout d'abord à rendre possible de
rajouter des arrêts de bus et j'aimerai éviter la complexité à tout prix.
Il me semble que c'est un sujet qui peut continuer d'être géré par des
mappeurs expérimentés uniquement. Mais si vous arrivez à me convaincre du
contraire, je suis suis tout ouïe ;)

la bise (froide)

Le 26 octobre 2016 à 10:33, lenny.libre  a écrit :

> Le 25/10/2016 à 22:55, Philippe Verdy a écrit :
>
> JOSM ne donne 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.
>
> +1
> en effet, JOSM n'a pas la connaissance du terrain (et encore plus quand il
> y a des boucles ou qu'on n'a pas fait 2 routes pour l'aller et le retour).
> JOSM permet d'ordonner les différents membres (manuellement) comme on le
> souhaite.
> Bien que non obligatoire, je préfère les mettre dans l'ordre, car c'est
> beaucoup plus simple à maintenir (en ce moment, je reprends une ligne dont
> les 'platform" du sens aller sont rattachés à la relation retour - et
> inversement - et en plus, ils ne sont pas triés).
> Pour ma part, je place les membres du départ à l'arrivée, d'abord les
> "stop" et les "platform" (le "stop" précédant le "platform" correspondant),
> puis tous les ways (la colonne à droite du nom permettant de voir s'il y a
> des anomalies dans les aboutements - JOSM signale lorsque les 2 segments
> n'ont pas d'extrémité commune - c'est comme cela que je m’aperçois que
> certains ont tronçonné des giratoires sans s'occuper des relations qu'ils
> supportent)
>
> léni
>
>
> Le 25 octobre 2016 à 14:18, Francescu GAROBY  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
>> 

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

[lenny.libre]

Le 25/10/2016 à 22:55, Philippe Verdy a écrit :
JOSM ne donne 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.



+1
en effet, JOSM n'a pas la connaissance du terrain (et encore plus quand 
il y a des boucles ou qu'on n'a pas fait 2 routes pour l'aller et le 
retour).
JOSM permet d'ordonner les différents membres (manuellement) comme on le 
souhaite.
Bien que non obligatoire, je préfère les mettre dans l'ordre, car c'est 
beaucoup plus simple à maintenir (en ce moment, je reprends une ligne 
dont les 'platform" du sens aller sont rattachés à la relation retour - 
et inversement - et en plus, ils ne sont pas triés).
Pour ma part, je place les membres du départ à l'arrivée, d'abord les 
"stop" et les "platform" (le "stop" précédant le "platform" 
correspondant), puis tous les ways (la colonne à droite du nom 
permettant de voir s'il y a des anomalies dans les aboutements - JOSM 
signale lorsque les 2 segments n'ont pas d'extrémité commune - c'est 
comme cela que je m’aperçois que certains ont tronçonné des giratoires 
sans s'occuper des relations qu'ils supportent)


léni


Le 25 octobre 2016 à 14:18, Francescu GAROBY > 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 > 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 

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

[Philippe Verdy]

ue 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 fi

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

[Philippe Verdy]

;> 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 public

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

[Noémie Lehuby]

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 [2]

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.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 <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
a

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

[mga_geo]

L'ordre dans la relation est important. Par exemple, quand un bus dessert un
chemin en impasse, une station au début, une station au fond et une station
au début (en face de la première), on fait comment pour déterminer l'ordre
des stations ?
Idem si le bus fait une boucle dans un quartier/ville.

Marc



--
View this message in context: 
http://gis.19327.n8.nabble.com/Appli-mobile-pour-mapper-les-arrets-de-bus-tp5884605p5884943.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Francescu GAROBY]

, 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éme

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

[Florian LAINEZ]

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-oQ@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 le

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

[Noémie Lehuby]

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.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 <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 

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

[Jo]

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 :

> 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  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 :
>>
>>> 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 

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

[Philippe Verdy]

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  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 :
>
>> 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 

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

[Philippe Verdy]

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  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 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  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 à 

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

[Florian LAINEZ]

>
> 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 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  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

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

[Philippe Verdy]

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 

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

[osm . sanspourriel]

> D'autres idées / remarques ?


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")

Oui bien-sûr MAIS en regardant le panneau de l'arrêt la mère de Florian 
que la ligne 3 et la ligne 60 s'arrêtent là.
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.
Par exemple les noms des arrêts, le fait qu'ils soient équipés d'un 
abri, ce sont des choses que l'on peut peut-être faire à l'avance.

Voir ça comme des fiches (précédent, suivant, prochain arrêt).
Un micro plan peut suffire pour que la personne puisse se situer et 
donner des informations, par exemple la présence d'un abri sans être à 
cet arrêt.


C'est sûr que les précédents / suivants se basent idéalement sur la 
ligne mais au début on ne la connait pas.
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.


Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Florian LAINEZ]

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  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 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[lenny.libre]

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

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

[Vincent Bergeot]

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 !


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

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

[lenny.libre]

Le 20/10/2016 à 18:15, Thomas a écrit :

Bonjour,

L'import Grand Toulouse comporte les attributs 'ref' et 'operator' qui
permettraient de constituer le tuple unique le plus opportun pour une
identification unique globale. Ce sont des attributs qu'il me semble
essentiel de conserver en cas de fusion ou suppression.

Bonsoir

Pour ma part, j'ai fait quelques modifications de lignes après les 
changements Tisséo intervenus le 29 août.


Je n'ai pas remarqué ces doublons ; la source est "Grand Toulouse" mais 
ne me semble pas être le résultat d'un import, Les emplacements sont 
assez corrects (vérifié avec l'orthophotoplan ToulouseMetropole 2015, ou 
sur place) ou alors je n'ai pas bien regardé.


J'ai téléchargé les arrêts de bus que j'ai trouvé sur le site de 
Toulouse Métropole 
(https://data.toulouse-metropole.fr/explore/dataset/arrets-de-bus0/map/?location=16,43.59271,1.41894=jawg.streets) 
et j'ai constaté qu'il y a un seul point pour tous les arrêts ayant le 
même nom avec un champ "conc_arret=" qui est la concaténation des n° de 
chaque arrêt (par exemple le point [code_expl=6192449487677451 
code_log=18 *conc_arret=179 180 182 183 184 185 188 189*conc_ligne=14 34 
46 64 65 67 conc_mode=bus id=705.0 *nom_arret=Arènes*nom_expl=tisseo] 
dans osm (http://osm.org/go/xVNVXVlXr) on trouve plusieurs nodes avec ce 
nom). Les n° présents dans ce "conc_arret" sont les ref indiqués dans 
osm comme on peut le voir à l'arrêt physique (certains rares nodes 
contiennent également une concaténation des ref 
http://www.openstreetmap.org/node/3793076559).


L'attribut commun entre DGI et Grand Toulouse, c'est (au delà de la
catégorisation bus_stop/bus=yes) c'est le nom. Mais étant donné que les
arrêts en face à face sur une voie à double sens de circulation portent
le même nom cela pose un problème pour envisager automatiser un recalage
sur cette couche de la DGI.
le nom n'est pas l'attribut commun (voir plus haut) c'est bien le n°  + 
Tisséo (pour les arrêts communs avec ceux du Conseil Départemental, il y 
a un autre n° propre à CD31)
D'autant plus que certains arrêts ont changé de nom (par exemple sur la 
ligne 21 "Colomiers Relais Bus" renommé "Salle Gascogne", "Passerelle" 
renommé "Val d'Aran")


Je viens de regarder sur des communes alentour, je constate
effectivement la présence de doublons DGI/Grand Toulouse ailleurs, avec
des décalages parfois importants de positions.

Du coup, le mieux serait-il de supprimer les noeuds DGI qui constituent
des doublons, après avoir vérifié in-situ la bonne position ou non des
noeuds Grand Toulouse lorsque les écarts entre les 2 couches sont
significatifs (cas facile à détecter avec une moulinette) ?

Thomas


On 20/10/2016 15:48, Francescu GAROBY wrote:

Bonjour Thomas,
Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse
ont un identifiant unique ?
Si oui, une possibilité pourrait être de fusionner les 2 points d'un
même arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un
réimport, qui devrait se baser là-dessus pour différencier les arrêts
présents/manquants, ne soit pas perturbé et retrouve ses petits.
Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça
n'apporte rien et, pire, ça embrouille les cartographieurs (qui
pourraient associer le mauvais arrêt dans la relation d'une ligne) comme
les usagers d'OSM...


Francescu

Le 20 octobre 2016 à 15:40, Thomas > a écrit :

 Bonjour,

 je profite de la thématique des arrêts de bus pour vous exposer une
 problématique et solliciter vos bons conseils.

 Je constate que dans mon coin il y a des incohérences sur la position
 d'arrêts de bus, notamment des déplacements liés à des réaménagements de
 l'espace urbain.

 Par exemple, je vais avoir l'arrêt de bus en double, à des positions
 différentes. Ces doublons s'expliquent par des campagnes d'import Open
 Data :

 2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
 mais avec des attributs intéressants. Je note par ailleurs que
 l'emplacement de cet arrêt est également faux sur le site commercial de
 Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
 métropole.

 Mes questions :
 - Comment gérer au mieux ces problématiques de données importées par le
 passé ?
 - Dois-je fusionner les attributs pour conserver un maximum d'infos et
 supprimer le nœud mal placé ?
 - Dois-je conserver les deux nœuds, et uniquement corriger la position
 erronée ?


Il me semble que les doublons que tu as détectés devraient être 
fusionnés (A voir peut-être avec osmose) vu qu'il n'y a qu'un arrêt sur 
le terrain (ces doublons sont des anomalies).



 L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
 lors d'une prochaine campagne d'import Open Data avec des données plus
 ou moins 

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

[osm . sanspourriel]

Merci aussi à toi pour ton retour.

Le 20/10/2016 à 11:26, Florian LAINEZ - winner...@free.fr a écrit :


@Jean-Yvon tous les détails dont tu parles sont passionnants, je passe 
moi-même beaucoup de temps à m'y plonger dedans. Mais l'outil que je 
souhaite est vraiment fait pour les noobs. OSMAND n'est pas utilisable 
par ma mère car trop compliqué.

D'accord sur la complexité de l'utilisation d'OSMAND.
Mais la question est : faut-il repartir à zéro ou rendre l'interface 
d'OSMAND utilisable par ta mère ?
Je n'ai pas la réponse, idéalement je choisirais la seconde proposition, 
j'ai vu que OSMAND proposait des feuilles de style (bon une que l'on 
peut adapter) pour afficher les descriptions des objets (on dit ce que 
l'on veut voir et dans quel ordre).
Si on pouvait faire des feuilles de styles de la carte qui servent de 
base aux feuilles de styles des descriptions / entrées / modifications 
des POI (voir simplement avoir des correspondances par nom : tu choisis 
le style transports publics pour la carte et il utilise la feuille de 
style transports publics pour les éditions de POI).
Ça me fait aussi penser au mapping.xml d’imposm3 :  on peut peut-être 
partir des attributs conseillés pour une thème dans un wiki pour trouver 
les données à présenter et l'ordre de présentation (sans oublier les 
données génériques style position et nom).

Peut-être à ranger par catégorie.

Sur l'utilisation de la caméra : suggérer de photographier l'arrêt de 
bus  (il y a souvent la fiche horaire avec au moins les principaux 
arrêts). Avec un GPX en plus ça permet de valider au moins les 
principaux arrêts.
Tu veux intégrer de l'OCR (reconnaissance optique de caractères) pour 
avoir les noms des arrêts ? ;-).
Sinon ça peut-être utile aux contributeurs en fauteuil, voir proposé 
dans Osmose comme aide à la décision.


Autre possibilité : quand on arrive à un arrêt connu possibilité de le 
valider (source=survey:2016). Là ce qui est gênant c'est qu'on veut 
attester de la non-modification. Faire une modif pour cela...


Je pense qu'il faut aussi montrer à l'utilisateur que son travail est 
utile en montrant un avant et un après.


Le 19 octobre 2016 à 23:19, Pierre-Yves Berrard 
> 
a écrit :


Le 19 octobre 2016 à 23:12, Philippe Verdy > a écrit :

Merci pour ces précisions.

Et en résumé : STAR est une marque associée à un réseau mais cette 
marque n'apparaît nulle part dans OSM.

fr_star, une fois que tu sais, ok.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Thomas Gratier]

Salut,

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/#/ avec code
http://makinacorpus.github.io/osm-transport-editor/

Cordialement


Thomas Gratier

Le 20 octobre 2016 à 18:15, Thomas  a écrit :

> Bonjour,
>
> L'import Grand Toulouse comporte les attributs 'ref' et 'operator' qui
> permettraient de constituer le tuple unique le plus opportun pour une
> identification unique globale. Ce sont des attributs qu'il me semble
> essentiel de conserver en cas de fusion ou suppression.
>
> L'attribut commun entre DGI et Grand Toulouse, c'est (au delà de la
> catégorisation bus_stop/bus=yes) c'est le nom. Mais étant donné que les
> arrêts en face à face sur une voie à double sens de circulation portent
> le même nom cela pose un problème pour envisager automatiser un recalage
> sur cette couche de la DGI.
>
> Je viens de regarder sur des communes alentour, je constate
> effectivement la présence de doublons DGI/Grand Toulouse ailleurs, avec
> des décalages parfois importants de positions.
>
> Du coup, le mieux serait-il de supprimer les noeuds DGI qui constituent
> des doublons, après avoir vérifié in-situ la bonne position ou non des
> noeuds Grand Toulouse lorsque les écarts entre les 2 couches sont
> significatifs (cas facile à détecter avec une moulinette) ?
>
> Thomas
>
>
> On 20/10/2016 15:48, Francescu GAROBY wrote:
> > Bonjour Thomas,
> > Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse
> > ont un identifiant unique ?
> > Si oui, une possibilité pourrait être de fusionner les 2 points d'un
> > même arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un
> > réimport, qui devrait se baser là-dessus pour différencier les arrêts
> > présents/manquants, ne soit pas perturbé et retrouve ses petits.
> > Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça
> > n'apporte rien et, pire, ça embrouille les cartographieurs (qui
> > pourraient associer le mauvais arrêt dans la relation d'une ligne) comme
> > les usagers d'OSM...
> >
> >
> > Francescu
> >
> > Le 20 octobre 2016 à 15:40, Thomas  > > a écrit :
> >
> > Bonjour,
> >
> > je profite de la thématique des arrêts de bus pour vous exposer une
> > problématique et solliciter vos bons conseils.
> >
> > Je constate que dans mon coin il y a des incohérences sur la position
> > d'arrêts de bus, notamment des déplacements liés à des
> réaménagements de
> > l'espace urbain.
> >
> > Par exemple, je vais avoir l'arrêt de bus en double, à des positions
> > différentes. Ces doublons s'expliquent par des campagnes d'import
> Open
> > Data :
> >
> > 2009 DGI : Positionnement OK, mais avec peu d'informations sur la
> ligne
> > 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement
> KO,
> > mais avec des attributs intéressants. Je note par ailleurs que
> > l'emplacement de cet arrêt est également faux sur le site commercial
> de
> > Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
> > métropole.
> >
> > Mes questions :
> > - Comment gérer au mieux ces problématiques de données importées par
> le
> > passé ?
> > - Dois-je fusionner les attributs pour conserver un maximum d'infos
> et
> > supprimer le nœud mal placé ?
> > - Dois-je conserver les deux nœuds, et uniquement corriger la
> position
> > erronée ?
> >
> > L'idée ici est de faire au mieux pour ne pas perturber ou être
> perturbé
> > lors d'une prochaine campagne d'import Open Data avec des données
> plus
> > ou moins correctes.
> >
> > Salutations,
> >
> >
> > On 19/10/2016 20:00, Philippe Verdy wrote:
> > > Dans les villes qui publient des données Open Data sur leurs
> > réseaux de
> > > transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> > > qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> > > comparaison.
> > >
> > > On a divers outils, y compris
> > > - via les données OSM elles-mêmes (relations de type "network"
> > pour les
> > > réseaux publics, dont les lignes membres sont des relations
> > > "route_master" contenant les relations "route" pour chaque sens ou
> > variante)
> > > - les ref:* pour le réseau ou pour l'opérateur
> > > - les outils d'intégration comme Osmose (qui pourrait aussi
> vérifier
> > > l'intégrité et la continuité des lignes)
> > > Ces relations "network" peuvent "facilement" être vérifiées de
> façon
> > > systématique avec un formalisme permettant certains automatismes.
> > >
> > > Pour le reste il peut manquer des infos non encore en open data:
> > ce qui
> > > est en général moins bien géré c'est le schéma v2 des transports
> qui
> > > intègre la notion de "plateforme" pour les interconnexions de
> > 

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

[Thomas]

Bonjour,

L'import Grand Toulouse comporte les attributs 'ref' et 'operator' qui
permettraient de constituer le tuple unique le plus opportun pour une
identification unique globale. Ce sont des attributs qu'il me semble
essentiel de conserver en cas de fusion ou suppression.

L'attribut commun entre DGI et Grand Toulouse, c'est (au delà de la
catégorisation bus_stop/bus=yes) c'est le nom. Mais étant donné que les
arrêts en face à face sur une voie à double sens de circulation portent
le même nom cela pose un problème pour envisager automatiser un recalage
sur cette couche de la DGI.

Je viens de regarder sur des communes alentour, je constate
effectivement la présence de doublons DGI/Grand Toulouse ailleurs, avec
des décalages parfois importants de positions.

Du coup, le mieux serait-il de supprimer les noeuds DGI qui constituent
des doublons, après avoir vérifié in-situ la bonne position ou non des
noeuds Grand Toulouse lorsque les écarts entre les 2 couches sont
significatifs (cas facile à détecter avec une moulinette) ?

Thomas


On 20/10/2016 15:48, Francescu GAROBY wrote:
> Bonjour Thomas,
> Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse
> ont un identifiant unique ?
> Si oui, une possibilité pourrait être de fusionner les 2 points d'un
> même arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un
> réimport, qui devrait se baser là-dessus pour différencier les arrêts
> présents/manquants, ne soit pas perturbé et retrouve ses petits.
> Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça
> n'apporte rien et, pire, ça embrouille les cartographieurs (qui
> pourraient associer le mauvais arrêt dans la relation d'une ligne) comme
> les usagers d'OSM...
> 
> 
> Francescu
> 
> Le 20 octobre 2016 à 15:40, Thomas  > a écrit :
> 
> Bonjour,
> 
> je profite de la thématique des arrêts de bus pour vous exposer une
> problématique et solliciter vos bons conseils.
> 
> Je constate que dans mon coin il y a des incohérences sur la position
> d'arrêts de bus, notamment des déplacements liés à des réaménagements de
> l'espace urbain.
> 
> Par exemple, je vais avoir l'arrêt de bus en double, à des positions
> différentes. Ces doublons s'expliquent par des campagnes d'import Open
> Data :
> 
> 2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
> 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
> mais avec des attributs intéressants. Je note par ailleurs que
> l'emplacement de cet arrêt est également faux sur le site commercial de
> Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
> métropole.
> 
> Mes questions :
> - Comment gérer au mieux ces problématiques de données importées par le
> passé ?
> - Dois-je fusionner les attributs pour conserver un maximum d'infos et
> supprimer le nœud mal placé ?
> - Dois-je conserver les deux nœuds, et uniquement corriger la position
> erronée ?
> 
> L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
> lors d'une prochaine campagne d'import Open Data avec des données plus
> ou moins correctes.
> 
> Salutations,
> 
> 
> On 19/10/2016 20:00, Philippe Verdy wrote:
> > Dans les villes qui publient des données Open Data sur leurs
> réseaux de
> > transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> > qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> > comparaison.
> >
> > On a divers outils, y compris
> > - via les données OSM elles-mêmes (relations de type "network"
> pour les
> > réseaux publics, dont les lignes membres sont des relations
> > "route_master" contenant les relations "route" pour chaque sens ou
> variante)
> > - les ref:* pour le réseau ou pour l'opérateur
> > - les outils d'intégration comme Osmose (qui pourrait aussi vérifier
> > l'intégrité et la continuité des lignes)
> > Ces relations "network" peuvent "facilement" être vérifiées de façon
> > systématique avec un formalisme permettant certains automatismes.
> >
> > Pour le reste il peut manquer des infos non encore en open data:
> ce qui
> > est en général moins bien géré c'est le schéma v2 des transports qui
> > intègre la notion de "plateforme" pour les interconnexions de
> lignes et
> > intermodales, permettant de regrouper des arrêts et faire les
> > correspondances, même entre réseaux différents (par exemple entre un
> > réseau urbain, un réseau départemental, les lignes nationales
> bus/train,
> > les stations de taxis, les stations d'auto-partage, les vélos à la
> > demande ("Vélib" et similaires), les interconnexions vers des chemins
> > touristiques...
> >
> > Actuellement les objets "platform" d'OSM sont surtout construits
> pour un
> > unique réseau, 

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

[Francescu GAROBY]

Bonjour Thomas,
Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse ont
un identifiant unique ?
Si oui, une possibilité pourrait être de fusionner les 2 points d'un même
arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un réimport,
qui devrait se baser là-dessus pour différencier les arrêts
présents/manquants, ne soit pas perturbé et retrouve ses petits.
Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça n'apporte
rien et, pire, ça embrouille les cartographieurs (qui pourraient associer
le mauvais arrêt dans la relation d'une ligne) comme les usagers d'OSM...


Francescu

Le 20 octobre 2016 à 15:40, Thomas  a écrit :

> Bonjour,
>
> je profite de la thématique des arrêts de bus pour vous exposer une
> problématique et solliciter vos bons conseils.
>
> Je constate que dans mon coin il y a des incohérences sur la position
> d'arrêts de bus, notamment des déplacements liés à des réaménagements de
> l'espace urbain.
>
> Par exemple, je vais avoir l'arrêt de bus en double, à des positions
> différentes. Ces doublons s'expliquent par des campagnes d'import Open
> Data :
>
> 2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
> 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
> mais avec des attributs intéressants. Je note par ailleurs que
> l'emplacement de cet arrêt est également faux sur le site commercial de
> Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
> métropole.
>
> Mes questions :
> - Comment gérer au mieux ces problématiques de données importées par le
> passé ?
> - Dois-je fusionner les attributs pour conserver un maximum d'infos et
> supprimer le nœud mal placé ?
> - Dois-je conserver les deux nœuds, et uniquement corriger la position
> erronée ?
>
> L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
> lors d'une prochaine campagne d'import Open Data avec des données plus
> ou moins correctes.
>
> Salutations,
>
>
> On 19/10/2016 20:00, Philippe Verdy wrote:
> > Dans les villes qui publient des données Open Data sur leurs réseaux de
> > transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> > qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> > comparaison.
> >
> > On a divers outils, y compris
> > - via les données OSM elles-mêmes (relations de type "network" pour les
> > réseaux publics, dont les lignes membres sont des relations
> > "route_master" contenant les relations "route" pour chaque sens ou
> variante)
> > - les ref:* pour le réseau ou pour l'opérateur
> > - les outils d'intégration comme Osmose (qui pourrait aussi vérifier
> > l'intégrité et la continuité des lignes)
> > Ces relations "network" peuvent "facilement" être vérifiées de façon
> > systématique avec un formalisme permettant certains automatismes.
> >
> > Pour le reste il peut manquer des infos non encore en open data: ce qui
> > est en général moins bien géré c'est le schéma v2 des transports qui
> > intègre la notion de "plateforme" pour les interconnexions de lignes et
> > intermodales, permettant de regrouper des arrêts et faire les
> > correspondances, même entre réseaux différents (par exemple entre un
> > réseau urbain, un réseau départemental, les lignes nationales bus/train,
> > les stations de taxis, les stations d'auto-partage, les vélos à la
> > demande ("Vélib" et similaires), les interconnexions vers des chemins
> > touristiques...
> >
> > Actuellement les objets "platform" d'OSM sont surtout construits pour un
> > unique réseau, mais si on regarde le détail ce qui nous manque c'est
> > surtout les connexion intermodales, qui permettant de choisir ou
> > optimiser les moyens de transport ou trouver des alternatives. Sans
> > cela, les outils de recherche font des approximations pas toujours très
> > claires et oublient des tas de possibilités (parce qu'en général on ne
> > tague pas la plupart des trajets piétonniers courts et qu'il y a des
> > obstacles imprévus ou des problèmes de sécurité pour faire certains
> > trajets d'interconnexion).
> >
> >
> >
> > Le 19 octobre 2016 à 18:36, lenny.libre  > > a écrit :
> >
> > Mon anglais étant niveau maternelle je n'ai pas trop essayé de lire
> > la présentation ...
> >
> > je trouve le principe intéressant, je me pose quelques
> interrogations :
> >
> > - possibilité de photographier (pour avoir éventuellement le nom de
> > l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)
> >
> > - plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?
> >
> > - est-il possible de faire les deux points
> > "public_transport=stop_position" et "public_transport=platform"
> >
> > - l'utiliser sans connexion internet, juste le gps
> >
> > bonne idée, cordialement
> >
> > léni
> >
> >
> >
> > Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :
> >> Hello,
> >> Il y a quelques temps qu'une 

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

[Thomas]

Bonjour,

je profite de la thématique des arrêts de bus pour vous exposer une
problématique et solliciter vos bons conseils.

Je constate que dans mon coin il y a des incohérences sur la position
d'arrêts de bus, notamment des déplacements liés à des réaménagements de
l'espace urbain.

Par exemple, je vais avoir l'arrêt de bus en double, à des positions
différentes. Ces doublons s'expliquent par des campagnes d'import Open
Data :

2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
mais avec des attributs intéressants. Je note par ailleurs que
l'emplacement de cet arrêt est également faux sur le site commercial de
Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
métropole.

Mes questions :
- Comment gérer au mieux ces problématiques de données importées par le
passé ?
- Dois-je fusionner les attributs pour conserver un maximum d'infos et
supprimer le nœud mal placé ?
- Dois-je conserver les deux nœuds, et uniquement corriger la position
erronée ?

L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
lors d'une prochaine campagne d'import Open Data avec des données plus
ou moins correctes.

Salutations,


On 19/10/2016 20:00, Philippe Verdy wrote:
> Dans les villes qui publient des données Open Data sur leurs réseaux de
> transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> comparaison.
> 
> On a divers outils, y compris
> - via les données OSM elles-mêmes (relations de type "network" pour les
> réseaux publics, dont les lignes membres sont des relations
> "route_master" contenant les relations "route" pour chaque sens ou variante)
> - les ref:* pour le réseau ou pour l'opérateur
> - les outils d'intégration comme Osmose (qui pourrait aussi vérifier
> l'intégrité et la continuité des lignes)
> Ces relations "network" peuvent "facilement" être vérifiées de façon
> systématique avec un formalisme permettant certains automatismes.
> 
> Pour le reste il peut manquer des infos non encore en open data: ce qui
> est en général moins bien géré c'est le schéma v2 des transports qui
> intègre la notion de "plateforme" pour les interconnexions de lignes et
> intermodales, permettant de regrouper des arrêts et faire les
> correspondances, même entre réseaux différents (par exemple entre un
> réseau urbain, un réseau départemental, les lignes nationales bus/train,
> les stations de taxis, les stations d'auto-partage, les vélos à la
> demande ("Vélib" et similaires), les interconnexions vers des chemins
> touristiques...
> 
> Actuellement les objets "platform" d'OSM sont surtout construits pour un
> unique réseau, mais si on regarde le détail ce qui nous manque c'est
> surtout les connexion intermodales, qui permettant de choisir ou
> optimiser les moyens de transport ou trouver des alternatives. Sans
> cela, les outils de recherche font des approximations pas toujours très
> claires et oublient des tas de possibilités (parce qu'en général on ne
> tague pas la plupart des trajets piétonniers courts et qu'il y a des
> obstacles imprévus ou des problèmes de sécurité pour faire certains
> trajets d'interconnexion).
> 
> 
> 
> Le 19 octobre 2016 à 18:36, lenny.libre  > a écrit :
> 
> Mon anglais étant niveau maternelle je n'ai pas trop essayé de lire
> la présentation ...
> 
> je trouve le principe intéressant, je me pose quelques interrogations :
> 
> - possibilité de photographier (pour avoir éventuellement le nom de
> l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)
> 
> - plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?
> 
> - est-il possible de faire les deux points
> "public_transport=stop_position" et "public_transport=platform"
> 
> - l'utiliser sans connexion internet, juste le gps
> 
> bonne idée, cordialement
> 
> léni
> 
> 
> 
> Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :
>> Hello,
>> Il y a quelques temps qu'une idée me trotte en tête : j'aimerai
>> créer une appli mobile pour éditer facilement les arrêts et les
>> relations de bus.
>> J'ai mis ce que j'avais en tête par écrit ici :
>> http://slides.com/overflorian/busstopcollector
>> 
>> Vous en pensez quoi ?
>>
>> -- 
>>
>> *Florian Lainez*
>>
>> @overflorian 
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-fr
>> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> 

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

[Florian LAINEZ]

Merci à tous pour vos retour et désolé d'avoir eu l'impolitesse de faire ma
proposition en anglais.

Par contre, si je vois bien la facilité qu'il peut y avoir à renseigner un
> arrêt, son équipement (banc, abribus, affichage, ...) ainsi que les lignes
> qui y passent, j'ai du mal à voir comment rendre facile l'édition d'un
> trajet de bus
>
@Francescu pour l'instant je ne sais pas moi non plus mais ça fait partie
des fonctionnalités à faire après la v1

Une autre possibilité de contribution que pourrait permettre cette
> application, ce serait l'enregistrement du tracé
>
Bonne idée ! Je note.

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.

@léni je note tes propositions (certaines ont en effet déjà été détaillées
dans ma présentation)

@Jean-Yvon tous les détails dont tu parles sont passionnants, je passe
moi-même beaucoup de temps à m'y plonger dedans. Mais l'outil que je
souhaite est vraiment fait pour les noobs. OSMAND n'est pas utilisable par
ma mère car trop compliqué.

Je vais passer un peu de temps à formaliser ma proposition dans le jours à
venir, vos retours sont les bienvenus


Le 19 octobre 2016 à 23:19, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit :

> Le 19 octobre 2016 à 23:12, Philippe Verdy  a écrit :
>
>> [...] (les passagers pourront alors embarquer ces jours-là avec leurs
>> titre de transport STAR, il pourront même acheter les titre dans les bus au
>> prix standard STAR, et sinon acheter les titres complémentaires pour aller
>> au delà, sans avoir besoin de descendre du car, à moins que ce jour-là la
>> métropole accepte d'affrêter la ligne existante du transporteur tiers sur
>> toute sa longueur, au prix justement de l'ajout d'arrêts supplémentaires
>> par rapport au trajet habituel du transporteur; ce transporteur tiers
>> pourra aussi augmenter la fréquence avec des bus supplémentaires pour ses
>> besoins propres en cas de trop forte affluence).[...]
>>
>
> Merci pour ces précisions.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Pierre-Yves Berrard]

Le 19 octobre 2016 à 23:12, Philippe Verdy  a écrit :

> [...] (les passagers pourront alors embarquer ces jours-là avec leurs
> titre de transport STAR, il pourront même acheter les titre dans les bus au
> prix standard STAR, et sinon acheter les titres complémentaires pour aller
> au delà, sans avoir besoin de descendre du car, à moins que ce jour-là la
> métropole accepte d'affrêter la ligne existante du transporteur tiers sur
> toute sa longueur, au prix justement de l'ajout d'arrêts supplémentaires
> par rapport au trajet habituel du transporteur; ce transporteur tiers
> pourra aussi augmenter la fréquence avec des bus supplémentaires pour ses
> besoins propres en cas de trop forte affluence).[...]
>

Merci pour ces précisions.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Le réseau n'est pas "STAR", non officiellement, puisque c'est le réseau de
transport urbain de Rennes Métropole, mais c'est sous la marque "STAR"
qu'il est maintenant promu et vendu par les opérateurs qui l'exploitent
Dans le passé STAR ne désignait que le nom de la régie municipale de
Rennes, puis lorsque les communes de l'agglomération ont formé un syndicat
intercommunal (appelé alors "SITCAR", dans lequel la STAR participait). La
marque STAR est maintenant détenue par Rennes Métropole qui l'a acquise
auprès de la ville de Rennes.

La loi ayant changé, la communauté d'agglomération (devenue maintenant
métropole mais qui s'est appelée "Rennes Métropole" depuis longtemps) a eu
seule la compétence en terme de réseau de transport public, et les
anciennes régies ont disparu, toutes transférées à la communauté, de même
que tous les contrats qui existaient entre les sociétés de transport et les
communes concernées et leurs syndicats. STAR reste le nom commercial
(SITCAR est abandonné). Ce réseau fait l'objet de marchés publics auprès
des trasnporteurs, et c'est Keolis qui a repris l'exploitation des bus
urbains et des dépots à Rennes et les personnels. Il reste cependant encore
des bus et personnels employés par d'autres transporteurs (dont TIV,
société privée, la SNCF elle-même directement pour exploiter les haltes
ferroviaires et mettre une partie de ses lignes bus à disposition de la
métropole, mais aussi d'autres communes du département ou de la région ou
des régions voisines, avec un partage de numéros de lignes: on voit
plusieurs numéros de lignes affichés dans les bus).

Bref STAR est bien le réseau (network=fr_star), même s'il comprend des
lignes partagées par plusieurs réseaux, et même s'il y a plusieurs
exploitants sous contrats avec la métropole (ils n'ont pas le choix de
toute façon car ils ne peuvent proposer des offres de transport public
qu'avec Rennes Métropole, sinon ils sont condamnés à vendre des titres de
transport séparés et auront du mal à remplir leurs véhicules puisque le
plus gros de leur clientèle ne voudra utiliser que les tickets et
abonnements de la métropole pour leurs déplacements réguliers dans la
métropole et pour bénéficier des correspondances!

Au besoin la métropole peut faire appel à tout moyen de transport d'un
autre transporteur privé ou public, par exemple en cas de défaillance sur
une ligne (véhicules en panne, défaut d'un transporteur ou de sons
personnel) ou de besoins supplémentaires liés à certains événements, et
mettre ces moyens à disposition d'une ligne STAR existante (éventuellement
avec des modifications de trajets), elle peut aussi faire appel aux moyens
venant de réseaux voisins (notamment ceux du département): on verra alors
des bus TIV sous numéro de ligne départemental afficher parfois le numéro
de ligne STAR (les passagers pourront alors embarquer ces jours-là avec
leurs titre de transport STAR, il pourront même acheter les titre dans les
bus au prix standard STAR, et sinon acheter les titres complémentaires pour
aller au delà, sans avoir besoin de descendre du car, à moins que ce
jour-là la métropole accepte d'affrêter la ligne existante du transporteur
tiers sur toute sa longueur, au prix justement de l'ajout d'arrêts
supplémentaires par rapport au trajet habituel du transporteur; ce
transporteur tiers pourra aussi augmenter la fréquence avec des bus
supplémentaires pour ses besoins propres en cas de trop forte affluence).

En fait cela fonctionne de plus en plus comme les lignes régulières
aériennes (prenez une navette Air France Paris-Marseille, et vous pouvez
vous retrouver certains jours dans un avion Air Canada qui sinon aurait du
faire un trajet à vide pour relier un autre aéroport, ou vous retrouver
dans le même avion que ceux qui ont acheté leurs titres chez Air Canada ou
une compagnie charter). On parle bien aujourd'hui d'affrètement pour les
bus, même pour les réseaux urbains. Même à Paris, parfois des lignes RATP
régulières utilisent à certaines heures ou certains jours des bus Air
France...

Le 19 octobre 2016 à 21:00,  a écrit :

> Oui quand c'est possible c'est mieux de s'appuyer sur des données
> libérées, précises et à jour.
>
> Si les compagnies ont moins la bougeotte, c'est mieux aussi.
>
> J'ai voulu tester le rendu overpass http://overpass-api.de/public_
> transport.html.
>
> Je suis joueur, je teste un endroit mal renseigné. Chou blanc.
>
> Allez, deuxième passe.
>
> Je sais que la ligne 1 de la Star sur Rennes est bien renseignée.
>
> Bon l'opérateur n'est pas la Star.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[osm . sanspourriel]

Oui quand c'est possible c'est mieux de s'appuyer sur des données 
libérées, précises et à jour.


Si les compagnies ont moins la bougeotte, c'est mieux aussi.

J'ai voulu tester le rendu overpass 
http://overpass-api.de/public_transport.html.


Je suis joueur, je teste un endroit mal renseigné. Chou blanc.

Allez, deuxième passe.

Je sais que la ligne 1 de la Star sur Rennes est bien renseignée.

Bon l'opérateur n'est pas la Star.
Bon le réseau n'est pas STAR.
Bon la ligne n'est pas la 1.

Je suis allé regarder un arrêt, j'ai récupéré une relation pour trouver.
Là ta mère a abandonné je crois ;-).

le réseau est fr_star, l'opérateur Keolis Rennes.

Il faudrait peut-être pouvoir chercher par marque ou être plus tolérant.

Et la ligne 17 qui était devenue la 7 puis la 1 s'appelle maintenant la C1.
Il y a aussi les arrêts qui voient leurs noms simplifiés pour que ça 
rendre dans la case ("Claude Bernard" devenu "Bernard" par exemple).


Tiens visiblement les arrêts de Chantepie Église de la 34 ont été 
utilisés par erreur :


http://www.openstreetmap.org/relation/399050#map=18/48.08751/-1.61686

Mais sur le rendu Wuppertal on n'y voit que du feu :

http://overpass-api.de/api/sketch-line?network=fr_star=C1=

On peut regretter que les points de correspondance ne figurent pas 
(arrêts de même nom à proximité et ayant d'autres lignes associés).
De même ici on voit des arrêts non desservis dans ce sens (et presque 
qu'aussi visible qu'un arrêt desservi).


Après on peut rêver que les plans arrivent sur ametro (et pas seulement 
la ligne A du métro pour parler de Rennes).


Pour les relations ça ne semble pas sorcier à ajouter : il faut saisir 
la ligne (numéro) et sens. A minima la personne sait le nom de la 
destination, à taper en attendant le bus. Idem pour le numéro de ligne.


L'ordre des arrêts ajoutés/modifiés/validés permet de reconstruire la 
relation dans le bon ordre.


Si je prends OSMAND, je peux éditer ou ajouter un POI.

Je vois bien un greffon sur OSMAND spécialisé sur les transports en commun.

Comme ça tu ne te poses pas la question de la plateforme, ça marchera 
sur un poste de travail, un téléphone Android ou un iOS.


Et OSMAND permet déjà de travailler en connecté ou déconnecté.

Jean-Yvon


Le 19/10/2016 à 20:00, Philippe Verdy - verd...@wanadoo.fr a écrit :
Dans les villes qui publient des données Open Data sur leurs réseaux 
de transport, je pense qu'on n'a pas besoin de cette appli tierce mais 
qu'il vaut mieux s'appuyer sur des solutions de synchronisation et 
comparaison.


On a divers outils, y compris
- via les données OSM elles-mêmes (relations de type "network" pour 
les réseaux publics, dont les lignes membres sont des relations 
"route_master" contenant les relations "route" pour chaque sens ou 
variante)

- les ref:* pour le réseau ou pour l'opérateur
- les outils d'intégration comme Osmose (qui pourrait aussi vérifier 
l'intégrité et la continuité des lignes)
Ces relations "network" peuvent "facilement" être vérifiées de façon 
systématique avec un formalisme permettant certains automatismes.


Pour le reste il peut manquer des infos non encore en open data: ce 
qui est en général moins bien géré c'est le schéma v2 des transports 
qui intègre la notion de "plateforme" pour les interconnexions de 
lignes et intermodales, permettant de regrouper des arrêts et faire 
les correspondances, même entre réseaux différents (par exemple entre 
un réseau urbain, un réseau départemental, les lignes nationales 
bus/train, les stations de taxis, les stations d'auto-partage, les 
vélos à la demande ("Vélib" et similaires), les interconnexions vers 
des chemins touristiques...


Actuellement les objets "platform" d'OSM sont surtout construits pour 
un unique réseau, mais si on regarde le détail ce qui nous manque 
c'est surtout les connexion intermodales, qui permettant de choisir ou 
optimiser les moyens de transport ou trouver des alternatives. Sans 
cela, les outils de recherche font des approximations pas toujours 
très claires et oublient des tas de possibilités (parce qu'en général 
on ne tague pas la plupart des trajets piétonniers courts et qu'il y a 
des obstacles imprévus ou des problèmes de sécurité pour faire 
certains trajets d'interconnexion).




Le 19 octobre 2016 à 18:36, lenny.libre > a écrit :


Mon anglais étant niveau maternelle je n'ai pas trop essayé de
lire la présentation ...

je trouve le principe intéressant, je me pose quelques
interrogations :

- possibilité de photographier (pour avoir éventuellement le nom
de l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)

- plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?

- est-il possible de faire les deux points
"public_transport=stop_position" et "public_transport=platform"

- l'utiliser sans connexion internet, juste le gps

bonne idée, cordialement

léni



Le 19/10/2016 à 14:57, Florian LAINEZ 

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

[Philippe Verdy]

Dans les villes qui publient des données Open Data sur leurs réseaux de
transport, je pense qu'on n'a pas besoin de cette appli tierce mais qu'il
vaut mieux s'appuyer sur des solutions de synchronisation et comparaison.

On a divers outils, y compris
- via les données OSM elles-mêmes (relations de type "network" pour les
réseaux publics, dont les lignes membres sont des relations "route_master"
contenant les relations "route" pour chaque sens ou variante)
- les ref:* pour le réseau ou pour l'opérateur
- les outils d'intégration comme Osmose (qui pourrait aussi vérifier
l'intégrité et la continuité des lignes)
Ces relations "network" peuvent "facilement" être vérifiées de façon
systématique avec un formalisme permettant certains automatismes.

Pour le reste il peut manquer des infos non encore en open data: ce qui est
en général moins bien géré c'est le schéma v2 des transports qui intègre la
notion de "plateforme" pour les interconnexions de lignes et intermodales,
permettant de regrouper des arrêts et faire les correspondances, même entre
réseaux différents (par exemple entre un réseau urbain, un réseau
départemental, les lignes nationales bus/train, les stations de taxis, les
stations d'auto-partage, les vélos à la demande ("Vélib" et similaires),
les interconnexions vers des chemins touristiques...

Actuellement les objets "platform" d'OSM sont surtout construits pour un
unique réseau, mais si on regarde le détail ce qui nous manque c'est
surtout les connexion intermodales, qui permettant de choisir ou optimiser
les moyens de transport ou trouver des alternatives. Sans cela, les outils
de recherche font des approximations pas toujours très claires et oublient
des tas de possibilités (parce qu'en général on ne tague pas la plupart des
trajets piétonniers courts et qu'il y a des obstacles imprévus ou des
problèmes de sécurité pour faire certains trajets d'interconnexion).



Le 19 octobre 2016 à 18:36, lenny.libre  a écrit :

> Mon anglais étant niveau maternelle je n'ai pas trop essayé de lire la
> présentation ...
>
> je trouve le principe intéressant, je me pose quelques interrogations :
>
> - possibilité de photographier (pour avoir éventuellement le nom de
> l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)
>
> - plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?
>
> - est-il possible de faire les deux points "public_transport=stop_position"
> et "public_transport=platform"
>
> - l'utiliser sans connexion internet, juste le gps
>
> bonne idée, cordialement
>
> léni
>
>
>
> Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :
>
> Hello,
> Il y a quelques temps qu'une idée me trotte en tête : j'aimerai créer une
> appli mobile pour éditer facilement les arrêts et les relations de bus.
> J'ai mis ce que j'avais en tête par écrit ici :
> http://slides.com/overflorian/busstopcollector
> Vous en pensez quoi ?
>
> --
>
> *Florian Lainez*
> @overflorian 
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> 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

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

[lenny.libre]

Mon anglais étant niveau maternelle je n'ai pas trop essayé de lire la 
présentation ...


je trouve le principe intéressant, je me pose quelques interrogations :

- possibilité de photographier (pour avoir éventuellement le nom de 
l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)


- plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?

- est-il possible de faire les deux points 
"public_transport=stop_position" et "public_transport=platform"


- l'utiliser sans connexion internet, juste le gps

bonne idée, cordialement

léni



Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :

Hello,
Il y a quelques temps qu'une idée me trotte en tête : j'aimerai créer 
une appli mobile pour éditer facilement les arrêts et les relations de 
bus.
J'ai mis ce que j'avais en tête par écrit ici : 
http://slides.com/overflorian/busstopcollector

Vous en pensez quoi ?

--

*Florian Lainez*

@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

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

[Vincent Bergeot]

Bonjour,

Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :

Hello,
Il y a quelques temps qu'une idée me trotte en tête : j'aimerai créer 
une appli mobile pour éditer facilement les arrêts


dans le bus je me sers d'un thème quasi identique à celui là 
:https://www.cartes.xyz/t/04e491-Arrets_de_bus__Florian#


je ne sais pas si cela colle ?
Si tu te connectes, tu peux modifier les POI.
Si tu ajoutes des arrêts, j'ai rapidement fait 2 modèles d'arrêts (avec 
abri et banc, sans abri et banc) à améliorer bien sur.
J'ai utilisé le wiki et ces photos 
(https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dbus_stop)


par rapport à tes attentes-idées-envies 
(http://slides.com/overflorian/busstopcollector) cela ne couvre pas tout 
mais déjà déplacement, ajout, qualification des données, ...

Et les reste, à venir !!!


Pour les relations, c'est autre chose là c'est sur !

à plus



et les relations de bus.
J'ai mis ce que j'avais en tête par écrit ici : 
http://slides.com/overflorian/busstopcollector

Vous en pensez quoi ?

--

*Florian Lainez*

@overflorian 


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
Vincent Bergeot

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Francescu GAROBY]

J'en pense que c'est une très bonne idée ! :-)
Par contre, si je vois bien la facilité qu'il peut y avoir à renseigner un
arrêt, son équipement (banc, abribus, affichage, ...) ainsi que les lignes
qui y passent, j'ai du mal à voir comment rendre facile l'édition d'un
trajet de bus.

Une autre possibilité de contribution que pourrait permettre cette
application, ce serait l'enregistrement du tracé : l'usager du bus
laisserait allumé son GPS et enregistrerait le trajet que prend son bus et
uploaderait la trace GPX ainsi générée. Charge ensuite à de gentils
contributeurs de mettre ça en forme, pour en faire une relation digne de ce
nom.
On n'aurait sans doute pas tout le trajet en une trace GPX, car rares sont
ceux qui vont d'un terminus à un terminus. Mais plusieurs usagers qui font
chacun un bout de trajet, ça peut faire un trajet complet (du moment que
l'upload de la trace GPX indique en même temps de quelle ligne de bus il
s'agit)

Francescu

Le 19 octobre 2016 à 14:57, Florian LAINEZ  a écrit :

> Hello,
> Il y a quelques temps qu'une idée me trotte en tête : j'aimerai créer une
> appli mobile pour éditer facilement les arrêts et les relations de bus.
> J'ai mis ce que j'avais en tête par écrit ici :
> http://slides.com/overflorian/busstopcollector
> Vous en pensez quoi ?
>
> --
>
> *Florian Lainez*
> @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