Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-08 Par sujet Blake Girardot 
Cher Phillip,

HOT a couru des projets sur la plupart des endroits que vous avez
identifiés ci-dessous. La cartographie était excellente avant de
commencer. Les résultats de notre projet ont également été
d'excellente qualité.

Je ne sais pas qui a fait toute la cartographie artisanale des zones
avant l'ouragan et pendant l'ouragan. C'est une belle cartographie.

Les données sont également transmises au site HDX, Humanitarian Data Exchange.

Vous trouverez des liens pour télécharger:

https://wiki.openstreetmap.org/wiki/2017_Hurricane_Irma

Merci beaucoup à tous ceux qui ont contribué à ces domaines de quelque
façon que ce soit.

J'ai transmis un autre courrier électronique à cette liste avec des
informations en français et en anglais sur la façon de rejoindre
l'équipe de HOT et la chaîne de coordination, tous ceux qui
s'intéressent à la cartographie de #HurricaneIrma sont les bienvenus.

Ou le slat OSM principal a également un canal #disaster et fait
également le cartographie #HurricaneIrma.

Avec respect,
Blake


=== Original English version ==

Dear Phillip,

HOT ran projects over most of the places you identified below. The
mapping was excellent before we started. The result results of our
project was also of excellent quality.

I do not know who did all the craft mapping of the areas before the
hurricane and during the hurricane. It is beautiful mapping.

The data is also pushed out to HDX, Humanitarian Data Exchange site.

Links for downloading can be found at:

https://wiki.openstreetmap.org/wiki/2017_Hurricane_Irma

Thank you very much to everyone who contributed to these areas in any way.

I forwarded another email to this list with information in French and
English on how to join HOT's slack team and coordination channel,
everyone who is interested in mapping for #HurricaneIrma is welcome.

Or the main OSM slack also has a #disaster channel and is doing
#HurricaneIrma related mapping as well.

Respectfully,
Blake



2017-09-06 19:52 GMT-04:00 Philippe Verdy :
> Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
> détectable même et surtout si c'est un way fermé. Si le dessin du cercle est
> "gênant" en zoom avant, il suffit de le considérer comme si ce n'était pas
> une ligne mais un disque, assimilable à un point un peu plis gros en son
> centre. De plus un bus peut encore être amené à faire plus que 1 tour s'il
> est gêné pour sortir, cela ne remet pas en cause le trajet de la ligne.
>
> C'est pareil pour les itinéraires routiers pour automobiles, camions ou
> cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
> de passer par le centre d'un grand giratoire en passant par des passages
> protégés, ce chemin sera marqué de même que les connexions aux rues arrivant
> au rond point, et dans ce cas le piéton n'utilisera pas le tracé circulaire
> du giratoire.
>
> Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
> les giratoires ne sert pas à grand chose.
>
> Je n'ai vus que quelques seul cas où ça peut être utile
> - : si le giratoire passe emprunte des ponts au dessus d'autres voies
> routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et évitant
> le giratoire. Le but étant alors de mettre des attributs différents sur des
> sections du giratoire, notamment les barrières de sécurité (mais on peut
> aussi représenter ces barrières sur des chemins parallèles.) mais surtout
> les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se passer en
> mettant le layer sur les voies qui traversent en dessous.
> - Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de le
> couper (ce sont ces ponts qu'on va découper éventuellement)
> - Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
> voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
> pourrait être gêné par le fait que ce layer passe alors aussi en dessous des
> "landuse" environnants s'ils englobent la surface du giratoire
>
> Certains veulent découper les giratoires à ponts pour uniquement le rendu
> (qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
> par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
> en surimpression des voies connectées (comme si ce filet noir était des
> barrières barrant les accès). On peut faire autrement en évitant
> "bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
> les voies en dessous, et en ajoutant les barrières de sécurité de chaque
> côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
> giratoire".
>
> Pour les assistants de navigation GPS, ils disent "entrez dans le
> giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
> pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
> rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
> retrouver et n'a pas besoin de toucher

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-08 Par sujet mga_geo 
Bonjour à tous,


> Pour moi, le trajet d'un bus ne peux se faire qu'en ayant pris
> le bus ou en ayant uns source opendata qui le décrit (je n'en
> connais pas) 

Sur Rennes, réseau STAR, on dispose dans le lot GTFS d'une description des
trajets.
C'est d'après l'intitulé du shape
shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled
"0001-A-2126-1024","48.13471","-1.621787","1",""
"0001-A-2126-1024","48.133961","-1.624158","10",""
"0001-A-2126-1024","48.1267","-1.641395","100",""
"0001-A-2126-1024","48.126678","-1.641398","101",""
"0001-A-2126-1024","48.126656","-1.641391","102",""
"0001-A-2126-1024","48.126638","-1.641374","103",""
"0001-A-2126-1024","48.126623","-1.64135","104",""
"0001-A-2126-1024","48.126614","-1.64132","105",""

Bonne journée
Marc



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Christian Quest 
Le 7 septembre 2017 à 17:19, JB  a écrit :

> Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des
> autres. Mais…
>
> Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse
> constante de la barrière à l'entrée à la contribution. À chaque couche de
> complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.
> « Alors, comment j'ajoute le nom du rond-point ?
>  - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
>  - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui vient
> ? »
>
> Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de
> stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments sont
> connectés dans la relation ? Combien de temps le sont-ils restés ?
>
> Bon, maintenant les arguments moins élégants, avec une touche de mauvaise
> foi :
>  - Découper des rond-point c'est tellement élégant, et tellement attrayant
> du point de vue intellectuel. Un peu comme le public_transport V2, quoi…
>  - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs
> l'utilise ?
>  - La contribution PT deviendra-t-elle réservée aux plus acharnés de la
> thématique ?
>
> JB.
>
>

Je suis sur la même ligne que JB... les inconvénients à découper me
semblent nettement supérieurs aux avantages.

La complexification (pas que de ça) rend la contribution à OSM de plus en
plus difficile d'accès pour des débutants alors évitons-la quand ce n'est
pas indispensable... et là ça ne me semble pas du tout indispensable.

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Jo 
Il faut d'abord créer l'outil avant de pouvoir promouvoir son utilisation.

Pour sélectionner le rond point complet:
Ctrl-f
junction=roundabout inview

Maintenant sûrement on va me dire: mais quel pourcentage de débutants
utilise JOSM?

De toute façon PT_Assistant a été conçu justement pour faire plus abordable
de participer à l'édition de transports en commun. Le problème que j'avais
ici en Belgique à un moment donné, c'était que j'étais quasi le seul qui
osait toucher ces relations route.
L'autre aspect est que PT_Assistant avertit les mappeurs qu'il y a des
problèmes avec les objet que l'utilisateur a modifié. Il faut, bien sûr,
l'installer.

La v2 du PT, j'ai des problèmes avec, moi aussi. Comme il est interprété
maintenant, il est trop complexe. Pourquoi devons-nous ajouter chaque arrêt
2 fois aux relations route? Mais bon, ça c'est une autre discussion.

Jo

2017-09-07 17:19 GMT+02:00 JB :

> Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des
> autres. Mais…
>
> Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse
> constante de la barrière à l'entrée à la contribution. À chaque couche de
> complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.
> « Alors, comment j'ajoute le nom du rond-point ?
>  - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
>  - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui vient
> ? »
>
> Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de
> stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments sont
> connectés dans la relation ? Combien de temps le sont-ils restés ?
>
> Bon, maintenant les arguments moins élégants, avec une touche de mauvaise
> foi :
>  - Découper des rond-point c'est tellement élégant, et tellement attrayant
> du point de vue intellectuel. Un peu comme le public_transport V2, quoi…
>  - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs
> l'utilise ?
>  - La contribution PT deviendra-t-elle réservée aux plus acharnés de la
> thématique ?
>
> JB.
>
>
>
> Le 07/09/2017 à 14:08, Jo a écrit :
>
> J'en ai découpé une bonne partie les dernières semaines ... 3 mois.L'année
> dernière j'ai surtout testé PT_Assistant sur un réseau 'clean', celui que
> j'avais cartographié en bonne partie moi-même en Belgique. Cette année-ci
> je me suis concentré de le tester un peu partout dans le monde pour être
> confident que le plugin en soi ne cause pas de dégâts imprévus et qu'il
> avertit en cas de 'vrais problèmes'.
>
> Ma préférence est de découper les giratoires, donc je l'ai fait, mais bien
> sûr, avant d'envoyer vers le serveur, le plugin m'avertissait d'éventuelles
> ruptures. dans toutes les lignes affectées. Je suis donc certain que toutes
> les relations ont été verifiées.
>
> Jo
>
>
>
> 2017-09-07 12:52 GMT+02:00 lenny.libre :
>
>>
>>
>> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>>
>>> Le 07/09/2017 à 08:54, JB a écrit :
>>>
 Bof.
 Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
 la saisie des données au plus simple, et que les tâches ingrates comme le
 découpage des rond-point devraient être sous-traitées aux outils.
 Personnellement, après avoir commencé à trifouiller un rendu transport,
 je me demande presque si les trajets ne devraient pas être carrément
 recalculés intégralement par un routeur pour aboutir à quelque chose de
 cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
 en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
 par les relations existantes. Alors quand j'imagine ce que ça pourrait
 donner pour les bus…
 JB.

>>> Il me semblait que la question avait été traitée, discutée et résolue il
>>> y a quelques années. De mémoire, voici la synthèse des résultats de
>>> discussions.
>>>
>>> Comme le disait Philippe, les ronds-points sont à considérer comme
>>> points un peu gros, sauf cas particuliers de constitution (genre :
>>> https://osm.org/go/0CUlN2EHd?m= ).
>>>
>>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>>> changeante qu'on soit à pied, à cheval ou en voiture.
>>>
>>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>>> pas de l'ordre du routage.
>>>
>>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>>> itinéraires pédestres).
>>>
>>> FrViPofm
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> Peut-être faut-il poser des question simples, les réponses ne concernant
>> que ce que j'ai vu, ce sont mes statistiques.
>>
>> Qui découpe les giratoires ?
>> - le contributeur qui décrit des différence entre les différents

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet JB 
Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des 
autres. Mais…


Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse 
constante de la barrière à l'entrée à la contribution. À chaque couche 
de complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.

« Alors, comment j'ajoute le nom du rond-point ?
 - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
 - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui 
vient ? »


Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de 
stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments 
sont connectés dans la relation ? Combien de temps le sont-ils restés ?


Bon, maintenant les arguments moins élégants, avec une touche de 
mauvaise foi :
 - Découper des rond-point c'est tellement élégant, et tellement 
attrayant du point de vue intellectuel. Un peu comme le public_transport 
V2, quoi…
 - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs 
l'utilise ?
 - La contribution PT deviendra-t-elle réservée aux plus acharnés de la 
thématique ?


JB.


Le 07/09/2017 à 14:08, Jo a écrit :
J'en ai découpé une bonne partie les dernières semaines ... 3 
mois.L'année dernière j'ai surtout testé PT_Assistant sur un réseau 
'clean', celui que j'avais cartographié en bonne partie moi-même en 
Belgique. Cette année-ci je me suis concentré de le tester un peu 
partout dans le monde pour être confident que le plugin en soi ne 
cause pas de dégâts imprévus et qu'il avertit en cas de 'vrais problèmes'.


Ma préférence est de découper les giratoires, donc je l'ai fait, mais 
bien sûr, avant d'envoyer vers le serveur, le plugin m'avertissait 
d'éventuelles ruptures. dans toutes les lignes affectées. Je suis donc 
certain que toutes les relations ont été verifiées.


Jo



2017-09-07 12:52 GMT+02:00 lenny.libre >:




Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le
repérage et la saisie des données au plus simple, et que
les tâches ingrates comme le découpage des rond-point
devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un
rendu transport, je me demande presque si les trajets ne
devraient pas être carrément recalculés intégralement par
un routeur pour aboutir à quelque chose de cohérent. Pour
exemple sur les réseaux tram (donc avec vraiment des voies
en propres et un réseau évoluant peu), j'ai été désespéré
dans certains cas par les relations existantes. Alors
quand j'imagine ce que ça pourrait donner pour les bus…
JB.

Il me semblait que la question avait été traitée, discutée et
résolue il y a quelques années. De mémoire, voici la synthèse
des résultats de discussions.

Comme le disait Philippe, les ronds-points sont à considérer
comme points un peu gros, sauf cas particuliers de
constitution (genre : https://osm.org/go/0CUlN2EHd?m=
 ).

C'est au logiciel de navigation (ou de rendu) de calculer la
portion empruntée (ce que savent bien faire les logiciels de
navigation), portion changeante qu'on soit à pied, à cheval ou
en voiture.

Donc, non, on ne les fractionne pas, sauf cas particuliers,
qui ne sont pas de l'ordre du routage.

Ces discussions ont changé ma pratique. Et maintenant, je
fusionne les ronds-points fractionnés pour raisons de routage
(trajets de bus ou itinéraires pédestres).

FrViPofm

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


Peut-être faut-il poser des question simples, les réponses ne
concernant que ce que j'ai vu, ce sont mes statistiques.

Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents
tronçons : c'est la même logique que la découpe de tronçons de
voirie avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le
routage exact.

Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans
découpage

Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui
me tenaient à cœur, je trouvais qu'elles n'avaient plus de
continuité parce qu'un contributeur avait découpé un giratoire
pour voir afficher la ligne qui intéressait

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Topographe Fou 
Merci Lenny, me voila rassuré, désolé si j'ai pu mal interpréter ton propos
:-) .

Le 7 septembre 2017 à 15:14, lenny.libre  a écrit :

>
>
> Le 07/09/2017 à 13:59, Topographe Fou a écrit :
>
>
>
> Le 7 septembre 2017 à 12:52, lenny.libre  a écrit :
>
>>
>>
>> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>>
>>> Le 07/09/2017 à 08:54, JB a écrit :
>>>
 Bof.
 Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
 la saisie des données au plus simple, et que les tâches ingrates comme le
 découpage des rond-point devraient être sous-traitées aux outils.
 Personnellement, après avoir commencé à trifouiller un rendu transport,
 je me demande presque si les trajets ne devraient pas être carrément
 recalculés intégralement par un routeur pour aboutir à quelque chose de
 cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
 en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
 par les relations existantes. Alors quand j'imagine ce que ça pourrait
 donner pour les bus…
 JB.

>>> Il me semblait que la question avait été traitée, discutée et résolue il
>>> y a quelques années. De mémoire, voici la synthèse des résultats de
>>> discussions.
>>>
>>> Comme le disait Philippe, les ronds-points sont à considérer comme
>>> points un peu gros, sauf cas particuliers de constitution (genre :
>>> https://osm.org/go/0CUlN2EHd?m= ).
>>>
>>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>>> changeante qu'on soit à pied, à cheval ou en voiture.
>>>
>>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>>> pas de l'ordre du routage.
>>>
>>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>>> itinéraires pédestres).
>>>
>>> FrViPofm
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> Peut-être faut-il poser des question simples, les réponses ne concernant
>> que ce que j'ai vu, ce sont mes statistiques.
>>
>> Qui découpe les giratoires ?
>> - le contributeur qui décrit des différence entre les différents tronçons
>> : c'est la même logique que la découpe de tronçons de voirie avec des
>> différences (type de voie, vitesse ...)
>> - le contributeur de lignes de transport public qui veut voir le routage
>> exact.
>>
>
> Exactement et ce sont pour moi des contributions recevables dans la mesure
> où elles affinent le modèle sans le détruire.
>
>
>>
>> Quelles applications ont besoin de giratoires découpés ?
>> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>>
>
> Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis certes
> incapable d'un citer une avec précision mais je ne vois pas pourquoi il ne
> devrait pas en exister, qui plus est quand cela rentrerait dans des calculs
> internes dont l'utilisateur n'aurait même pas connaissance.
>
> J'ai bien précisé que cela ne concernait que ce que j'ai pu voir " *les
> réponses ne concernant que ce que j'ai vu, ce sont mes statistiques*"
>
>
>
>>
>> Quel est l'impact du découpage/fusion ?
>> - lorsque je consultais certaines lignes de transport public qui me
>> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
>> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
>> qui intéressait sans s'occuper des autres lignes.
>>
>
> Et c'est une erreur de la part de celui qui découpe nous sommes
> d'accord... Il doit vérifier toutes les relations (pas juste les bus) pour
> s'assurer qu'il ne créé pas d'erreur.
>
>
>> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
>> faisais, je partais du segment qui avait l'historique le plus complet et je
>> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
>> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent
>
>
> Pardonnez-moi mais là je lis des choses qui me dérangent et je voudrais
> une clarification.
>
> Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des
> "sections" de rond points, de manière générale (pour toute way) :
>
>- Découper une way pour appliquer des attributs différents/relations
>différentes aux deux morceaux cela s'appelle affiner le modèle et c'est
>considéré comme une contribution utile, à fortiori quand c'est en utilisant
>le schéma de tag conventionnel (à supposer que les infos soient bonnes et
>libres, ce qui n'est pas la question ici)
>- Fusionner deux ways qui ne sont pas strictement identiques
>(attributs et relations), et donc supprimer un niveau de détail (et à
>fortiori utilisant le schéma de tag conventionnel), sous le prétexte que
>

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet lenny.libre 



Le 07/09/2017 à 13:59, Topographe Fou a écrit :



Le 7 septembre 2017 à 12:52, lenny.libre > a écrit :




Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le
repérage et la saisie des données au plus simple, et que
les tâches ingrates comme le découpage des rond-point
devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un
rendu transport, je me demande presque si les trajets ne
devraient pas être carrément recalculés intégralement par
un routeur pour aboutir à quelque chose de cohérent. Pour
exemple sur les réseaux tram (donc avec vraiment des voies
en propres et un réseau évoluant peu), j'ai été désespéré
dans certains cas par les relations existantes. Alors
quand j'imagine ce que ça pourrait donner pour les bus…
JB.

Il me semblait que la question avait été traitée, discutée et
résolue il y a quelques années. De mémoire, voici la synthèse
des résultats de discussions.

Comme le disait Philippe, les ronds-points sont à considérer
comme points un peu gros, sauf cas particuliers de
constitution (genre : https://osm.org/go/0CUlN2EHd?m=
 ).

C'est au logiciel de navigation (ou de rendu) de calculer la
portion empruntée (ce que savent bien faire les logiciels de
navigation), portion changeante qu'on soit à pied, à cheval ou
en voiture.

Donc, non, on ne les fractionne pas, sauf cas particuliers,
qui ne sont pas de l'ordre du routage.

Ces discussions ont changé ma pratique. Et maintenant, je
fusionne les ronds-points fractionnés pour raisons de routage
(trajets de bus ou itinéraires pédestres).

FrViPofm

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


Peut-être faut-il poser des question simples, les réponses ne
concernant que ce que j'ai vu, ce sont mes statistiques.

Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents
tronçons : c'est la même logique que la découpe de tronçons de
voirie avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le
routage exact.


Exactement et ce sont pour moi des contributions recevables dans la 
mesure où elles affinent le modèle sans le détruire.



Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans
découpage


Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis 
certes incapable d'un citer une avec précision mais je ne vois pas 
pourquoi il ne devrait pas en exister, qui plus est quand cela 
rentrerait dans des calculs internes dont l'utilisateur n'aurait même 
pas connaissance.
J'ai bien précisé que cela ne concernait que ce que j'ai pu voir " /les 
réponses ne concernant que ce que j'ai vu, ce sont mes statistiques/"



Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui
me tenaient à cœur, je trouvais qu'elles n'avaient plus de
continuité parce qu'un contributeur avait découpé un giratoire
pour voir afficher la ligne qui intéressait sans s'occuper des
autres lignes.


Et c'est une erreur de la part de celui qui découpe nous sommes 
d'accord... Il doit vérifier toutes les relations (pas juste les bus) 
pour s'assurer qu'il ne créé pas d'erreur.


- Je ne fusionnais pas systématiquement les giratoires, mais quand
je le faisais, je partais du segment qui avait l'historique le
plus complet et je vérifiais qu'il n'y avait pas de rupture de
continuité sur les autres lignes. Je n'ai pas vu de rupture
provoquée par contributeur qui regroupent


Pardonnez-moi mais là je lis des choses qui me dérangent et je 
voudrais une clarification.


Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des 
"sections" de rond points, de manière générale (pour toute way) :


  * Découper une way pour appliquer des attributs différents/relations
différentes aux deux morceaux cela s'appelle affiner le modèle et
c'est considéré comme une contribution utile, à fortiori quand
c'est en utilisant le schéma de tag conventionnel (à supposer que
les infos soient bonnes et libres, ce qui n'est pas la question ici)
  * Fusionner deux ways qui ne sont pas strictement identiques
(attributs et

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Jo 
J'en ai découpé une bonne partie les dernières semaines ... 3 mois.L'année
dernière j'ai surtout testé PT_Assistant sur un réseau 'clean', celui que
j'avais cartographié en bonne partie moi-même en Belgique. Cette année-ci
je me suis concentré de le tester un peu partout dans le monde pour être
confident que le plugin en soi ne cause pas de dégâts imprévus et qu'il
avertit en cas de 'vrais problèmes'.

Ma préférence est de découper les giratoires, donc je l'ai fait, mais bien
sûr, avant d'envoyer vers le serveur, le plugin m'avertissait d'éventuelles
ruptures. dans toutes les lignes affectées. Je suis donc certain que toutes
les relations ont été verifiées.

Jo



2017-09-07 12:52 GMT+02:00 lenny.libre :

>
>
> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>
>> Le 07/09/2017 à 08:54, JB a écrit :
>>
>>> Bof.
>>> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
>>> la saisie des données au plus simple, et que les tâches ingrates comme le
>>> découpage des rond-point devraient être sous-traitées aux outils.
>>> Personnellement, après avoir commencé à trifouiller un rendu transport,
>>> je me demande presque si les trajets ne devraient pas être carrément
>>> recalculés intégralement par un routeur pour aboutir à quelque chose de
>>> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
>>> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
>>> par les relations existantes. Alors quand j'imagine ce que ça pourrait
>>> donner pour les bus…
>>> JB.
>>>
>> Il me semblait que la question avait été traitée, discutée et résolue il
>> y a quelques années. De mémoire, voici la synthèse des résultats de
>> discussions.
>>
>> Comme le disait Philippe, les ronds-points sont à considérer comme points
>> un peu gros, sauf cas particuliers de constitution (genre :
>> https://osm.org/go/0CUlN2EHd?m= ).
>>
>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>> changeante qu'on soit à pied, à cheval ou en voiture.
>>
>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>> pas de l'ordre du routage.
>>
>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>> itinéraires pédestres).
>>
>> FrViPofm
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> Peut-être faut-il poser des question simples, les réponses ne concernant
> que ce que j'ai vu, ce sont mes statistiques.
>
> Qui découpe les giratoires ?
> - le contributeur qui décrit des différence entre les différents tronçons
> : c'est la même logique que la découpe de tronçons de voirie avec des
> différences (type de voie, vitesse ...)
> - le contributeur de lignes de transport public qui veut voir le routage
> exact.
>
> Quelles applications ont besoin de giratoires découpés ?
> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>
> Quel est l'impact du découpage/fusion ?
> - lorsque je consultais certaines lignes de transport public qui me
> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
> qui intéressait sans s'occuper des autres lignes.
> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
> faisais, je partais du segment qui avait l'historique le plus complet et je
> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent
>
>
>
> ___
> 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] Trajets de bus et ronds--points

2017-09-07 Par sujet Topographe Fou 
Le 7 septembre 2017 à 12:52, lenny.libre  a écrit :

>
>
> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>
>> Le 07/09/2017 à 08:54, JB a écrit :
>>
>>> Bof.
>>> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
>>> la saisie des données au plus simple, et que les tâches ingrates comme le
>>> découpage des rond-point devraient être sous-traitées aux outils.
>>> Personnellement, après avoir commencé à trifouiller un rendu transport,
>>> je me demande presque si les trajets ne devraient pas être carrément
>>> recalculés intégralement par un routeur pour aboutir à quelque chose de
>>> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
>>> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
>>> par les relations existantes. Alors quand j'imagine ce que ça pourrait
>>> donner pour les bus…
>>> JB.
>>>
>> Il me semblait que la question avait été traitée, discutée et résolue il
>> y a quelques années. De mémoire, voici la synthèse des résultats de
>> discussions.
>>
>> Comme le disait Philippe, les ronds-points sont à considérer comme points
>> un peu gros, sauf cas particuliers de constitution (genre :
>> https://osm.org/go/0CUlN2EHd?m= ).
>>
>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>> changeante qu'on soit à pied, à cheval ou en voiture.
>>
>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>> pas de l'ordre du routage.
>>
>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>> itinéraires pédestres).
>>
>> FrViPofm
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> Peut-être faut-il poser des question simples, les réponses ne concernant
> que ce que j'ai vu, ce sont mes statistiques.
>
> Qui découpe les giratoires ?
> - le contributeur qui décrit des différence entre les différents tronçons
> : c'est la même logique que la découpe de tronçons de voirie avec des
> différences (type de voie, vitesse ...)
> - le contributeur de lignes de transport public qui veut voir le routage
> exact.
>

Exactement et ce sont pour moi des contributions recevables dans la mesure
où elles affinent le modèle sans le détruire.


>
> Quelles applications ont besoin de giratoires découpés ?
> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>

Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis certes
incapable d'un citer une avec précision mais je ne vois pas pourquoi il ne
devrait pas en exister, qui plus est quand cela rentrerait dans des calculs
internes dont l'utilisateur n'aurait même pas connaissance.


>
> Quel est l'impact du découpage/fusion ?
> - lorsque je consultais certaines lignes de transport public qui me
> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
> qui intéressait sans s'occuper des autres lignes.
>

Et c'est une erreur de la part de celui qui découpe nous sommes d'accord...
Il doit vérifier toutes les relations (pas juste les bus) pour s'assurer
qu'il ne créé pas d'erreur.


> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
> faisais, je partais du segment qui avait l'historique le plus complet et je
> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent


Pardonnez-moi mais là je lis des choses qui me dérangent et je voudrais une
clarification.

Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des
"sections" de rond points, de manière générale (pour toute way) :

   - Découper une way pour appliquer des attributs différents/relations
   différentes aux deux morceaux cela s'appelle affiner le modèle et c'est
   considéré comme une contribution utile, à fortiori quand c'est en utilisant
   le schéma de tag conventionnel (à supposer que les infos soient bonnes et
   libres, ce qui n'est pas la question ici)
   - Fusionner deux ways qui ne sont pas strictement identiques (attributs
   et relations), et donc supprimer un niveau de détail (et à fortiori
   utilisant le schéma de tag conventionnel), sous le prétexte que personne
   (?) n'a besoin de descendre à ce niveau de détail, c'est supprimer une
   contribution sans justification rationnelle. Et quand c'est pour faire
   plaisir à son outils préféré, que ce soit du rendu, de navigation... cela
   s'appelle tagguer pour l'outil (ce qui n'est pas dans les règles convenues
   il me semble).

En bref je voudrais m'assurer qu'il n'est pas question ici de promouvoir la
suppression (que je juge abusive) de telles contributions.


>
>
>

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet lenny.libre 



Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage 
et la saisie des données au plus simple, et que les tâches ingrates 
comme le découpage des rond-point devraient être sous-traitées aux 
outils.
Personnellement, après avoir commencé à trifouiller un rendu 
transport, je me demande presque si les trajets ne devraient pas être 
carrément recalculés intégralement par un routeur pour aboutir à 
quelque chose de cohérent. Pour exemple sur les réseaux tram (donc 
avec vraiment des voies en propres et un réseau évoluant peu), j'ai 
été désespéré dans certains cas par les relations existantes. Alors 
quand j'imagine ce que ça pourrait donner pour les bus…

JB.
Il me semblait que la question avait été traitée, discutée et résolue 
il y a quelques années. De mémoire, voici la synthèse des résultats de 
discussions.


Comme le disait Philippe, les ronds-points sont à considérer comme 
points un peu gros, sauf cas particuliers de constitution (genre : 
https://osm.org/go/0CUlN2EHd?m= ).


C'est au logiciel de navigation (ou de rendu) de calculer la portion 
empruntée (ce que savent bien faire les logiciels de navigation), 
portion changeante qu'on soit à pied, à cheval ou en voiture.


Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne 
sont pas de l'ordre du routage.


Ces discussions ont changé ma pratique. Et maintenant, je fusionne les 
ronds-points fractionnés pour raisons de routage (trajets de bus ou 
itinéraires pédestres).


FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Peut-être faut-il poser des question simples, les réponses ne concernant 
que ce que j'ai vu, ce sont mes statistiques.


Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents 
tronçons : c'est la même logique que la découpe de tronçons de voirie 
avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le routage 
exact.


Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans découpage

Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui me 
tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce 
qu'un contributeur avait découpé un giratoire pour voir afficher la 
ligne qui intéressait sans s'occuper des autres lignes.
- Je ne fusionnais pas systématiquement les giratoires, mais quand je le 
faisais, je partais du segment qui avait l'historique le plus complet et 
je vérifiais qu'il n'y avait pas de rupture de continuité sur les autres 
lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent



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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet marc marc 
Le 07. 09. 17 à 11:42, Axelos a écrit :
> la globalité de certains de ces giratoires étaient empruntés 
> par les itinéraires sans que je m'en rende compte, 
> et JOSM ne râle pas au contraire il semble content.

c'est une approximation/simplification de l'espace.
exemple avec un simple carrefour : le fait que c'est un point
dans osm, ne veux pas dire que le bus passe au mètre près
au même endroit pour le trajet aller que pour le trajet retour.
Personne ne voit (pour le moment) le besoin de couper cela en 4.
De même une route est une approximation des 2 bandes de circulation,
cela ne signifie pas que le bus a "les roues" au même endroit
à l'aller et au retour.
Cela ne choque personne pour les voitures !
Je n'ai jamais compris pq certains trouvent cela indispensable
lorsqu'il s'agit du rendu d'un trajet de bus

De la même manière qu'on a un noeud highway=turning_circle
le plus aurait été d'avoir un noeud highway=roundabout
avec un "width" pour le rendu.
mais cela n'existe pas, on a fait plus précis,
avec les yop-yop du au manque d’unanimité.

pendant ce temps, cfr la semaine passée, y a des relations de bus
en version > 100 en autre pour des optimisations d'itinéraires
mais qui n'ont aucun arrêt de bus... si cela se trouve le bus
ne passe même plus là depuis longtemps...
Pour moi, le trajet d'un bus ne peux se faire qu'en ayant pris
le bus ou en ayant uns source opendata qui le décrit (je n'en
connais pas)
Encoder le trajet d'un bus en supposant qu'il fait le trajet
par défaut de mapzen donne une impression de qualité...
alors que c'est qu'une hypothèse.
Je troue cela un excès de micro-maping, surtout quand on voit
qu'il y a tant à améliorer de + fondamental (les arrêts)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Axelos 
Coucou,

Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
> Il me semblait que la question avait été traitée, discutée et résolue il
> y a quelques années. De mémoire, voici la synthèse des résultats de
> discussions.
> 
> Comme le disait Philippe, les ronds-points sont à considérer comme
> points un peu gros, sauf cas particuliers de constitution (genre :
> https://osm.org/go/0CUlN2EHd?m= ).
> 
> C'est au logiciel de navigation (ou de rendu) de calculer la portion
> empruntée (ce que savent bien faire les logiciels de navigation),
> portion changeante qu'on soit à pied, à cheval ou en voiture.

Est-il possible d'ajouter cette décision sur le wiki OSM ?
Car si je regarde la page osm.org/wiki/FR:Key:public_transport = aucune
référence
Si je regarde la page osm.org/wiki/FR:Relation:route = "Il n'y a pas de
consensus"

Aussi préciser si concerne les rond-points, giratoires, les deux ? Car
en France il s'agit de deux types de carrefours différents. (les autres
pays francophones je sais pas)

> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
> pas de l'ordre du routage.
> 
> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
> ronds-points fractionnés pour raisons de routage (trajets de bus ou
> itinéraires pédestres).

J'ai toujours eu l'habitude (et la logique personnelle) de découper ces
carrefours. Et en effet je viens de m'apercevoir qu'en actualisant
certains itinéraires ces derniers jours, la globalité de certains de ces
giratoires étaient empruntés par les itinéraires sans que je m'en rende
compte, et JOSM ne râle pas au contraire il semble content.

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Philippe Verdy 
Le 7 septembre 2017 à 09:51, Vincent Pottier  a écrit :

> Le 07/09/2017 à 09:35, Jo a écrit :
>
>> Et chaque rendu transport devra donc refaire ce calcul d'itinéraire
>> denouveau et denouveau?
>>
> Oui.
>
>> Avec possiblement des résultats divergents entre un moteur de routage bus
>> et un autre?
>>
> Avec nécessairement un rendu différent pour bus et piéton ! Le piéton, il
> peut prendre le rond-point à contre-sens !


Oui mais découpage ou pas cela n'a aucune conséquence pour les piétons. Ils
ne sont pas le problème du tout. La seule raison de découper est la
nécessité de mettre des tags différents sur certaines parties. De plus les
piétons ont très des chemins particuliers préférés évitant la boucle et
leur demandant d'utiliser des passage protégés écartés du rond-point
lui-même: ce sont ces chemins qu'il est intéressant de marquer, ne
serait-ce que pour l'accessibilité et la sécurité (donc même les trottoirs
périphériques devraient être tracés séparément, la boucle de la chaussée
restant dangereuse pour eux même s'ils peuvent en principe l'utiliser on ne
peut pas le leur recommander et là il faut être réaliste.

>
>
>> PT_Assistant est là maintenant pour aider à faire la cartographie des
>> routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, mais
>> ce n'est certainement pas impossible.
>>
> L'éditeur de relations de JOSM gère très bien les ronds-points (entiers)
> intégrés dans un itinéraire, qu'il soit pédestre ou lié aux transports en
> commun.


Tout à fait d'accord et ce n'est pas le seul outil. Etant donné comment on
a fait le choix initial de ne pas taguer les highways comme surfaces mais
comme lignes, uniquement pour les véhicules en laissant les piétons à part,
que ce soit découpé ou pas cela ne change rien au routage des véhicules sur
leur chemin imposé, ni aux piétons qui s'écartent systématiquement de ce
chemin théorique "moyen" et qui ne leur correspond pas du tout.

OSM progressant en niveau de détail, on en viendra assez vite à tracer
*aussi* les surfaces de voiries, tout en gardant le tracé filaire, comme on
l'a fait pour les rivières en traçant en plus les "riverbanks". Le filaire
pourra encore servir pour des usages plus limités ou moins précis. Mais
cela arrivera beaucoup plus lentement en commençant par des zones
localisées où le seul filaire est problématique et trop ambigu (et ne
permet toujours pas de préciser certains itinéraires autorisés ou ceux qui
sont interdits pour les véhicules, ou ceux qui ne sont pas recommandés ou
dangereux pour les piétons et pas assez précis en terme d'accessibilité).

Car il faut bien admettre que la représentation filaire a aussi ses limites
et que ce n'est qu'une modélisation approximative d'une réalité en fait
différente et dont la géométrie de base est très difficilement
représentable avec juste des tags sur le filaire, dont l'interprétation
géométrique devient de plus en plus difficile et ultracompliquée: on a déjà
vu le problème récemment pour la représentation cartographique des largeurs
de routes et du changement du nombre de "lanes" : comment obtenir une
représentation réaliste quand on zoome sur le détail est particulièrement
difficile, et jusqu'à présent on n'a que des heuristiques déterminant une
largeur estimée moyenne selon le type de route (primary, secondary...) et
ne tenant d'ailleurs même pas compte de tags simple comme "oneway=*" qui
devrait normalement aussi réduire l'estimation de largeur moyenne. Le tracé
uniquement filaire est aussi problématique pour les ponts à chaussées
séparés (on a une solution qui commence à s'établir qui consiste à tracer
le contour polygonal autour du pont avec man_made=bridge+layer=1, en plus
des routes et barrières posées dessus)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Vincent Pottier 

Le 07/09/2017 à 09:35, Jo a écrit :
Et chaque rendu transport devra donc refaire ce calcul d'itinéraire 
denouveau et denouveau?

Oui.
Avec possiblement des résultats divergents entre un moteur de routage 
bus et un autre?
Avec nécessairement un rendu différent pour bus et piéton ! Le piéton, 
il peut prendre le rond-point à contre-sens !


PT_Assistant est là maintenant pour aider à faire la cartographie des 
routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, 
mais ce n'est certainement pas impossible.
L'éditeur de relations de JOSM gère très bien les ronds-points (entiers) 
intégrés dans un itinéraire, qu'il soit pédestre ou lié aux transports 
en commun.


Jo


FrViPofm

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Vincent Pottier 

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage et 
la saisie des données au plus simple, et que les tâches ingrates comme 
le découpage des rond-point devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un rendu 
transport, je me demande presque si les trajets ne devraient pas être 
carrément recalculés intégralement par un routeur pour aboutir à 
quelque chose de cohérent. Pour exemple sur les réseaux tram (donc 
avec vraiment des voies en propres et un réseau évoluant peu), j'ai 
été désespéré dans certains cas par les relations existantes. Alors 
quand j'imagine ce que ça pourrait donner pour les bus…

JB.
Il me semblait que la question avait été traitée, discutée et résolue il 
y a quelques années. De mémoire, voici la synthèse des résultats de 
discussions.


Comme le disait Philippe, les ronds-points sont à considérer comme 
points un peu gros, sauf cas particuliers de constitution (genre : 
https://osm.org/go/0CUlN2EHd?m= ).


C'est au logiciel de navigation (ou de rendu) de calculer la portion 
empruntée (ce que savent bien faire les logiciels de navigation), 
portion changeante qu'on soit à pied, à cheval ou en voiture.


Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont 
pas de l'ordre du routage.


Ces discussions ont changé ma pratique. Et maintenant, je fusionne les 
ronds-points fractionnés pour raisons de routage (trajets de bus ou 
itinéraires pédestres).


FrViPofm

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Jo 
Et chaque rendu transport devra donc refaire ce calcul d'itinéraire
denouveau et denouveau? Avec possiblement des résultats divergents entre un
moteur de routage bus et un autre?

PT_Assistant est là maintenant pour aider à faire la cartographie des
routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, mais
ce n'est certainement pas impossible.

Jo


2017-09-07 8:54 GMT+02:00 JB :

> Bof.
> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et la
> saisie des données au plus simple, et que les tâches ingrates comme le
> découpage des rond-point devraient être sous-traitées aux outils.
> Personnellement, après avoir commencé à trifouiller un rendu transport, je
> me demande presque si les trajets ne devraient pas être carrément
> recalculés intégralement par un routeur pour aboutir à quelque chose de
> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
> par les relations existantes. Alors quand j'imagine ce que ça pourrait
> donner pour les bus…
> JB.
>
>
> Le 07/09/2017 à 06:35, Jo a écrit :
>
> Depuis quelques mois nous avons enfin une façon de taguer les bus_bay.
> Pour les ajouter le chemin est également découpé deux fois. S'il se trouve
> sur le rond-point c'est une autre raison pour le découper.
>
> Dire que c'est au rendu de dessiner les lignes de bus en partiel sur les
> rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose qui sera
> implémenté dans un futur proche. Probablement jamais. Diviser les
> rond-points, c'est quelque chose qu'un mappeur peut faire facilement et ça
> ne heurte personne. Ça décrit très précisement les trajets des bus, surtout
> quand la même ligne emprunte le rond-point plusieurs fois, ou s'il
> n'emprunte pas certaines parties, parce qu'il y a des 'fourches' en oneway
> avant ou derrière.
>
> Polyglot
>
> 2017-09-07 1:52 GMT+02:00 Philippe Verdy :
>
>> Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
>> détectable même et surtout si c'est un way fermé. Si le dessin du cercle
>> est "gênant" en zoom avant, il suffit de le considérer comme si ce n'était
>> pas une ligne mais un disque, assimilable à un point un peu plis gros en
>> son centre. De plus un bus peut encore être amené à faire plus que 1 tour
>> s'il est gêné pour sortir, cela ne remet pas en cause le trajet de la
>> ligne.
>>
>> C'est pareil pour les itinéraires routiers pour automobiles, camions ou
>> cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
>> de passer par le centre d'un grand giratoire en passant par des passages
>> protégés, ce chemin sera marqué de même que les connexions aux rues
>> arrivant au rond point, et dans ce cas le piéton n'utilisera pas le tracé
>> circulaire du giratoire.
>>
>> Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
>> les giratoires ne sert pas à grand chose.
>>
>> Je n'ai vus que quelques seul cas où ça peut être utile
>> - : si le giratoire passe emprunte des ponts au dessus d'autres voies
>> routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et
>> évitant le giratoire. Le but étant alors de mettre des attributs différents
>> sur des sections du giratoire, notamment les barrières de sécurité (mais on
>> peut aussi représenter ces barrières sur des chemins parallèles.) mais
>> surtout les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
>> passer en mettant le layer sur les voies qui traversent en dessous.
>> - Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de
>> le couper (ce sont ces ponts qu'on va découper éventuellement)
>> - Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
>> voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
>> pourrait être gêné par le fait que ce layer passe alors aussi en dessous
>> des "landuse" environnants s'ils englobent la surface du giratoire
>>
>> Certains veulent découper les giratoires à ponts pour uniquement le rendu
>> (qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
>> par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
>> en surimpression des voies connectées (comme si ce filet noir était des
>> barrières barrant les accès). On peut faire autrement en évitant
>> "bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
>> les voies en dessous, et en ajoutant les barrières de sécurité de chaque
>> côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
>> giratoire".
>>
>> Pour les assistants de navigation GPS, ils disent "entrez dans le
>> giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
>> pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
>> rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
>> retrouver et n'a pas besoin de

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet Topographe Fou 
  Bonjour,J'avoue que ayant pas mal travaillé sur les lignes et arrêts de bus dans la région de Paris je fais partie de ceux qui découpent les rond-points (et sans vérifier si précédemment ils n'avaient pas été soudés). Je trouve que donner un tracé exact est plus juste par rapport à la réalité du terrain. C'est mon seul argument.Quoiqu'il arrive les outils doivent pouvoir gérer des ronds-points découpés car il peut y avoir d'autres raisons à cela que les lignes de bus (changement de revêtement ? Passage dans un tunnel (rare) ? Sur un pont (plus fréquent) ? Piste cyclable que sur une partie ?...). Donc si les lignes de bus augmentent les occurrences interdire ou déconseiller cette pratique ne résoudra pas fondamentalement le problème. Quelque soit la solution il faudra que les outils s'adaptent aux deux. On ne tag pas pour eux (ou pour le rendu comme on a tendance à simplifier ;-) ). Un outils gérant les deux sera capable de gérer bien plus qu'un problème de bus.Cordialement, LeTopographeFouDe: f.gar...@gmail.comEnvoyé: 7 septembre 2017 12:27 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Trajets de bus et ronds--points  Bonsoir,Je pense qu'il faudrait se mettre d'accord une bonne fois pour toutes, avec les ronds-points empruntés par les lignes de bus...À chaque fois, ça ne loupe pas : je trouve des ronds-points morcelés, ou refusionnés, puis remorcelés, ... Bref, à cause de tout ça, les tracés des lignes de bus sont incorrects, au niveau des ronds-points.Personnellement, je pense que ça n'a pas de sens de couper un rond-point, étant donné que l'entrée et la sortie sont connues. Charge au logiciel de dessin de tenir compte de ça...-- Cordialement,Francescu GAROBY

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-07 Par sujet JB 

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage et 
la saisie des données au plus simple, et que les tâches ingrates comme 
le découpage des rond-point devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un rendu transport, 
je me demande presque si les trajets ne devraient pas être carrément 
recalculés intégralement par un routeur pour aboutir à quelque chose de 
cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des 
voies en propres et un réseau évoluant peu), j'ai été désespéré dans 
certains cas par les relations existantes. Alors quand j'imagine ce que 
ça pourrait donner pour les bus…

JB.

Le 07/09/2017 à 06:35, Jo a écrit :
Depuis quelques mois nous avons enfin une façon de taguer les bus_bay. 
Pour les ajouter le chemin est également découpé deux fois. S'il se 
trouve sur le rond-point c'est une autre raison pour le découper.


Dire que c'est au rendu de dessiner les lignes de bus en partiel sur 
les rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose 
qui sera implémenté dans un futur proche. Probablement jamais. Diviser 
les rond-points, c'est quelque chose qu'un mappeur peut faire 
facilement et ça ne heurte personne. Ça décrit très précisement les 
trajets des bus, surtout quand la même ligne emprunte le rond-point 
plusieurs fois, ou s'il n'emprunte pas certaines parties, parce qu'il 
y a des 'fourches' en oneway avant ou derrière.


Polyglot

2017-09-07 1:52 GMT+02:00 Philippe Verdy >:


Je le pense aussi. Un giratoire sur le tracé d'un ligne est très
aisément détectable même et surtout si c'est un way fermé. Si le
dessin du cercle est "gênant" en zoom avant, il suffit de le
considérer comme si ce n'était pas une ligne mais un disque,
assimilable à un point un peu plis gros en son centre. De plus un
bus peut encore être amené à faire plus que 1 tour s'il est gêné
pour sortir, cela ne remet pas en cause le trajet de la ligne.

C'est pareil pour les itinéraires routiers pour automobiles,
camions ou cyclistes, et même pour les piétons (s'il y a peur eux
un chemin permettant de passer par le centre d'un grand giratoire
en passant par des passages protégés, ce chemin sera marqué de
même que les connexions aux rues arrivant au rond point, et dans
ce cas le piéton n'utilisera pas le tracé circulaire du giratoire.

Dans tous les cas, on sait par où on y entre et par où en en sort.
Briser les giratoires ne sert pas à grand chose.

Je n'ai vus que quelques seul cas où ça peut être utile
- : si le giratoire passe emprunte des ponts au dessus d'autres
voies routières/ferrée/cyclistes ou un avec cours d'eau passant
dessous et évitant le giratoire. Le but étant alors de mettre des
attributs différents sur des sections du giratoire, notamment les
barrières de sécurité (mais on peut aussi représenter ces
barrières sur des chemins parallèles.) mais surtout les
l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
passer en mettant le layer sur les voies qui traversent en dessous.
- Si le giratoire passe sous d'autres ponts il n'est jamais
nécessaire de le couper (ce sont ces ponts qu'on va découper
éventuellement)
- Si le giratoire passe dans des sections en tunnel (exemple en
Andorre) voire sous un bâtiment un "layer=-n" sera éventuellement
nécessaire mais on pourrait être gêné par le fait que ce layer
passe alors aussi en dessous des "landuse" environnants s'ils
englobent la surface du giratoire

Certains veulent découper les giratoires à ponts pour uniquement
le rendu (qui détoure les voies des ponts par un filet noir : à
mon avis ça se règle par une correction dans le moteur de rendu,
pour que ce filet ne vienne pas en surimpression des voies
connectées (comme si ce filet noir était des barrières barrant les
accès). On peut faire autrement en évitant "bridge=yes" sur ces
sections de giratoire, et mettant plutôt tunnel pour les voies en
dessous, et en ajoutant les barrières de sécurité de chaque côté
du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
giratoire".

Pour les assistants de navigation GPS, ils disent "entrez dans le
giratoire/rond-point, prenez la deuxième sortie" et ça suffit car
il n'y a pas d'autres chemins possibles et si celui qui ne connait
pas bien le coin rate la bonne sortie, il sait qu'il va devoir
faire le tour complet pour la retrouver et n'a pas besoin de
toucher à son GPS!

Il reste les rares cas de giratoires avec des feux temporaires
(fonctionnant en giratoire la plupart du temps quand les feux sont
éteints mais en carrefour avec des voies plus prioritaires qui les
traversent quand les feux sont allumés). Cela ne concerne que de
rares giratoires qui ont une voie centrale pour les transports en
commun

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-06 Par sujet Jo 
Depuis quelques mois nous avons enfin une façon de taguer les bus_bay. Pour
les ajouter le chemin est également découpé deux fois. S'il se trouve sur
le rond-point c'est une autre raison pour le découper.

Dire que c'est au rendu de dessiner les lignes de bus en partiel sur les
rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose qui sera
implémenté dans un futur proche. Probablement jamais. Diviser les
rond-points, c'est quelque chose qu'un mappeur peut faire facilement et ça
ne heurte personne. Ça décrit très précisement les trajets des bus, surtout
quand la même ligne emprunte le rond-point plusieurs fois, ou s'il
n'emprunte pas certaines parties, parce qu'il y a des 'fourches' en oneway
avant ou derrière.

Polyglot

2017-09-07 1:52 GMT+02:00 Philippe Verdy :

> Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
> détectable même et surtout si c'est un way fermé. Si le dessin du cercle
> est "gênant" en zoom avant, il suffit de le considérer comme si ce n'était
> pas une ligne mais un disque, assimilable à un point un peu plis gros en
> son centre. De plus un bus peut encore être amené à faire plus que 1 tour
> s'il est gêné pour sortir, cela ne remet pas en cause le trajet de la ligne.
>
> C'est pareil pour les itinéraires routiers pour automobiles, camions ou
> cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
> de passer par le centre d'un grand giratoire en passant par des passages
> protégés, ce chemin sera marqué de même que les connexions aux rues
> arrivant au rond point, et dans ce cas le piéton n'utilisera pas le tracé
> circulaire du giratoire.
>
> Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
> les giratoires ne sert pas à grand chose.
>
> Je n'ai vus que quelques seul cas où ça peut être utile
> - : si le giratoire passe emprunte des ponts au dessus d'autres voies
> routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et
> évitant le giratoire. Le but étant alors de mettre des attributs différents
> sur des sections du giratoire, notamment les barrières de sécurité (mais on
> peut aussi représenter ces barrières sur des chemins parallèles.) mais
> surtout les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
> passer en mettant le layer sur les voies qui traversent en dessous.
> - Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de
> le couper (ce sont ces ponts qu'on va découper éventuellement)
> - Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
> voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
> pourrait être gêné par le fait que ce layer passe alors aussi en dessous
> des "landuse" environnants s'ils englobent la surface du giratoire
>
> Certains veulent découper les giratoires à ponts pour uniquement le rendu
> (qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
> par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
> en surimpression des voies connectées (comme si ce filet noir était des
> barrières barrant les accès). On peut faire autrement en évitant
> "bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
> les voies en dessous, et en ajoutant les barrières de sécurité de chaque
> côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
> giratoire".
>
> Pour les assistants de navigation GPS, ils disent "entrez dans le
> giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
> pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
> rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
> retrouver et n'a pas besoin de toucher à son GPS!
>
> Il reste les rares cas de giratoires avec des feux temporaires
> (fonctionnant en giratoire la plupart du temps quand les feux sont éteints
> mais en carrefour avec des voies plus prioritaires qui les traversent quand
> les feux sont allumés). Cela ne concerne que de rares giratoires qui ont
> une voie centrale pour les transports en commun munis de radiocommande ou
> de télédétections des véhicules de transport en commun. On en trouve pas
> mal à Nantes avec les carrefours utilisés aussi par les trams toujours
> prioritaires (il y a des feux clignotants signalant l'approche d'une rame
> et l'arrêt impératif de tous les autres usagers, mais là encore pas besoin
> de découper le giratoire car le tram n'emprunte pas les mêmes voies).
>
> Les derniers cas sont les ceux où un giratoire est temporairement
> partiellement fermé  (par exemple un accident de la route ou des travaux):
> la police ou des feux temporaires seront là pour rendre les autres sections
> du giratoire bidirectionnelles ou unidirectionnelle alternée, et le faire
> fonctionner comme un carrefour normal mais ce n'est jamais pour longtemps
> (quelques heures pour un accident routier, quelques heures s'il y a des
> travaux sur un giratoire

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-06 Par sujet Philippe Verdy 
Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
détectable même et surtout si c'est un way fermé. Si le dessin du cercle
est "gênant" en zoom avant, il suffit de le considérer comme si ce n'était
pas une ligne mais un disque, assimilable à un point un peu plis gros en
son centre. De plus un bus peut encore être amené à faire plus que 1 tour
s'il est gêné pour sortir, cela ne remet pas en cause le trajet de la ligne.

C'est pareil pour les itinéraires routiers pour automobiles, camions ou
cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
de passer par le centre d'un grand giratoire en passant par des passages
protégés, ce chemin sera marqué de même que les connexions aux rues
arrivant au rond point, et dans ce cas le piéton n'utilisera pas le tracé
circulaire du giratoire.

Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
les giratoires ne sert pas à grand chose.

Je n'ai vus que quelques seul cas où ça peut être utile
- : si le giratoire passe emprunte des ponts au dessus d'autres voies
routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et
évitant le giratoire. Le but étant alors de mettre des attributs différents
sur des sections du giratoire, notamment les barrières de sécurité (mais on
peut aussi représenter ces barrières sur des chemins parallèles.) mais
surtout les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
passer en mettant le layer sur les voies qui traversent en dessous.
- Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de
le couper (ce sont ces ponts qu'on va découper éventuellement)
- Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
pourrait être gêné par le fait que ce layer passe alors aussi en dessous
des "landuse" environnants s'ils englobent la surface du giratoire

Certains veulent découper les giratoires à ponts pour uniquement le rendu
(qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
en surimpression des voies connectées (comme si ce filet noir était des
barrières barrant les accès). On peut faire autrement en évitant
"bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
les voies en dessous, et en ajoutant les barrières de sécurité de chaque
côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
giratoire".

Pour les assistants de navigation GPS, ils disent "entrez dans le
giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
retrouver et n'a pas besoin de toucher à son GPS!

Il reste les rares cas de giratoires avec des feux temporaires
(fonctionnant en giratoire la plupart du temps quand les feux sont éteints
mais en carrefour avec des voies plus prioritaires qui les traversent quand
les feux sont allumés). Cela ne concerne que de rares giratoires qui ont
une voie centrale pour les transports en commun munis de radiocommande ou
de télédétections des véhicules de transport en commun. On en trouve pas
mal à Nantes avec les carrefours utilisés aussi par les trams toujours
prioritaires (il y a des feux clignotants signalant l'approche d'une rame
et l'arrêt impératif de tous les autres usagers, mais là encore pas besoin
de découper le giratoire car le tram n'emprunte pas les mêmes voies).

Les derniers cas sont les ceux où un giratoire est temporairement
partiellement fermé  (par exemple un accident de la route ou des travaux):
la police ou des feux temporaires seront là pour rendre les autres sections
du giratoire bidirectionnelles ou unidirectionnelle alternée, et le faire
fonctionner comme un carrefour normal mais ce n'est jamais pour longtemps
(quelques heures pour un accident routier, quelques heures s'il y a des
travaux sur un giratoire important, parfois quelques semaines sinon en zone
résidentielle). Mais là on est rarement dans le cas où il faut modifier OSM
(le temps de faire la modif, que ce soit exporté et visible sur les cartes
et c'est déjà terminé, on aura fait la modif pour rien qu'il faut déjà
l'annuler...)

Le 7 septembre 2017 à 00:26, Francescu GAROBY  a écrit :

> Bonsoir,
> Je pense qu'il faudrait se mettre d'accord une bonne fois pour toutes,
> avec les ronds-points empruntés par les lignes de bus...
> À chaque fois, ça ne loupe pas : je trouve des ronds-points morcelés, ou
> refusionnés, puis remorcelés, ... Bref, à cause de tout ça, les tracés des
> lignes de bus sont incorrects, au niveau des ronds-points.
> Personnellement, je pense que ça n'a pas de sens de couper un rond-point,
> étant donné que l'entrée et la sortie sont connues. Charge au logiciel de
> dessin de tenir compte de ça...
>
> --
> Cordialement,
>