Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-04 Par sujet Yves P. 
> On voit sur la carte 
>  qu'il y a une 
> coupure à "Le Brusquet"
J'ai rajouté le way manquant et corriger l'ordre des membres : 
https://osmcha.org/changesets/86174533/

Il y a une particularité à cet itinéraire : c'est une boucle.
J'ai donc rajouté aussi le to=Digne-les-Bains ;)

>  Il faut donc leur mettre le rôle "forward" à tous :
> chemin 471213896 forward # Route de Barles (6 nœuds)
> chemin 471213903 forward # Route de Barles (3 nœuds)
> chemin 471213901 forward # Route de Barles (4 nœuds)
> chemin 471213894 forward # Route de Barles (4 nœuds)
Comme c'est une boucle, ces 4 ways n'ont plus besoin de rôle forward/backward.

(Vue dans JOSM de cette partie 
)

On trouve donc à l'aller (membres dans JOSM 
) :
chemin 471213896  # Route de Barles (6 nœuds)
chemin 471213903  # Route de Barles (3 nœuds)
Et au retour (membres dans JOSM 
) :
chemin 471213894  # Route de Barles (4 nœuds)
chemin 471213901  # Route de Barles (4 nœuds)
__
Yves



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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-04 Par sujet Yves P. 
> Je regroupe les tronçons à chaque branchement :
> 
> way1
> way2
> way3
> forward way4
> forward way5
> forward way6
> backward way7
> backward way8
> backward way9
> way10
Oui, dans l'esprit.

Si les way4 à way6 sont orientées dans le sens du trajet "Aller"…
et que way7 à way9 sont orientées dans le sens inverse du trajet "Retour".

La subtilité c'est que forward et backward c'est par rapport au tracé des way 
dans OSM, pas par rapport au trajet du vélo.

> Ça passe bien dans Waymarked Trails: À vélo
> https://cycling.waymarkedtrails.org/#route?id=10135436=12!44.1826!6.3009
Relation Analyser nous dit un "Go" 
Great! This relation seems ok.

On voit sur la carte  
qu'il y a une coupure à "Le Brusquet"

Par contre en chargeant cette relation dans JOSM, le graphe des membres ne 
l'est pas.

Concrètement, au premier trajet aller/retour rencontré tu mets :
chemin 471213896 forward # Route de Barles (6 nœuds)
chemin 471213903 forward # Route de Barles (3 nœuds)
chemin 471213901 backward # Route de Barles (4 nœuds)
chemin 471213894 backward # Route de Barles (4 nœuds)
Hors ces 4 chemins sont orientés dans le sens du trajet à vélo. On obtient un 
graphe incorrecte 

 dans JOSM.

 Il faut donc leur mettre le rôle "forward" à tous :
chemin 471213896 forward # Route de Barles (6 nœuds)
chemin 471213903 forward # Route de Barles (3 nœuds)
chemin 471213901 forward # Route de Barles (4 nœuds)
chemin 471213894 forward # Route de Barles (4 nœuds)
Cette fois le graphe est bien orienté 

 dans JOSM :)

__
Yves


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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-04 Par sujet Jean-Christophe Becquet 
Le 02/06/2020 15:43, Charles MILLET a écrit :
> Et donc tu utilises les forward/backward comme le dis Marc M. Moi c'est
> ce que je fais mais je n'ai jamais été très sûr de moi ;)

C'est aussi ce que j'ai appliqué pour les itinéraires cyclables des
Alpes-de-Haute-Provence.

> Après JOSM ne le prend pas bien en compte et il n'y a pas de méthode
> claire sur l'ordre que doivent avoir les backward, leur position dans la
> liste des autres membres (forward par défaut) et sûrement d'autres
> choses. Tu as des pratiques ?

Je regroupe les tronçons à chaque branchement :

way1
way2
way3
forward way4
forward way5
forward way6
backward way7
backward way8
backward way9
way10

Plusieurs exemples autour de Digne :
http://umap.openstreetmap.fr/fr/map/cyclo4-itineraires-cyclables-des-alpes-de-haute-pr_389779#16/44.0907/6.2337

Ça passe bien dans Waymarked Trails: À vélo
https://cycling.waymarkedtrails.org/#route?id=10135436=12!44.1826!6.3009
https://cycling.waymarkedtrails.org/#route?id=10162980=12!44.006!6.1607
https://cycling.waymarkedtrails.org/#route?id=10163060=11!44.1354!6.0885

JCB
-- 
Richard Stallman : Toutes les libertés dépendent des libertés informatiques
http://www.apitux.org/index.php?2006/04/19/158-richard-stallman-toutes-les-libertes-dependent-des-libertes-informatique

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-02 Par sujet Yves P. 
> Et donc tu utilises les forward/backward comme le dis Marc M.

> Moi c'est ce que je fais mais je n'ai jamais été très  sûr de moi ;)
Oui, tu le montres bien dans la vidéo ;D

> Après JOSM ne le prend pas bien en compte et il n'y a pas de méthode claire 
> sur l'ordre que doivent avoir les backward, leur position dans la liste des 
> autres membres (forward par défaut) et sûrement d'autres choses. Tu as des 
> pratiques ?

En travaillant sur 2 section de l'EV1 - Vélodyssée, j'ai fini par piger le truc 
: voici un bref tutoriel  
avec des images :)

__
Yves

Tuto fait à l'arrache. Les commentaires sont les bienvenus :)


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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-02 Par sujet Charles MILLET 

Je suis bien d'accord avec ça et le principe des exceptions.

Et donc tu utilises les forward/backward comme le dis Marc M. Moi c'est 
ce que je fais mais je n'ai jamais été très  sûr de moi ;)


Après JOSM ne le prend pas bien en compte et il n'y a pas de méthode 
claire sur l'ordre que doivent avoir les backward, leur position dans la 
liste des autres membres (forward par défaut) et sûrement d'autres 
choses. Tu as des pratiques ?


Charles

On 31/05/2020 14:27, Axel Listes wrote:

Bonjour,

Le 31/05/2020 à 13:53, Baptiste Jonglez a écrit :

En tout cas ça me paraît beaucoup plus simple que de faire une relation
aller et une relation retour, ce qui obligerait à dupliquer la majorité du
trajet dans les deux relations (ou alors j'ai mal compris).


Disons que les besoins ne sont pas les même que pour d'autres types de
transports, notamment les TEC qui doivent respectent un sens spécifique
concernant les arrêts.

En ce qui concerne les itinéraires cyclables, pour ma part je considère
qu’introduire les deux sens dans une unique relation suffit largement.
Les départager n'ajoute que de la complexité à la maintenance, ce dont
je sais à quoi je fais référence puisque je "maintiens" régulièrement
des Véloroutes nationales qui passent dans la région ou je vis.

Après on peut éventuellement faire des exceptions pour certains
itinéraires urbains, car il est vrai que les deux sens sont très souvent
départagés sur la majorité du parcours.

Axel.



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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-02 Par sujet Charles MILLET 

Oui clairement, il faut bosser à la main l'essentiel du temps ;)

On 31/05/2020 20:45, Yves P. wrote:
Euh, ouais, non, deux relations c'est deux fois plus de travail, déjà 
que la maintenance n'est pas facile.

Avec la bonne méthode, une relation c'est mieux :)

Puis perso, je m'embête rarement à ordonner les chemins (c'est un 
travail d'ordinateur ça :).
Je me sert du bouton du bouton trier les membres, mais dans ce cas ça 
ne fonctionnait pas (relation trop cassée).
J'ai refais un essais, le tri fonctionne bien jusqu'à la fin de la 
première intersection Aller/retour, ensuite il faut aider JOSM.


__
Yves


___
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] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-06-02 Par sujet Yves P . 
Bonjour,

Message du Sun, 31 May 2020 12:50:10 filtré car trop volumineux 88 ko avec 
l'illustration.

@Baptiste
> L'été dernier, j'ai eu une situation similaire sur d'autres morceaux de l'EV1.
> J'étais parti pour simplement mettre à jour un tronçon et je me suis
> retrouvé à faire du nettoyage / rajouter de la continuité sur un bon bout
> du trajet ;)
Bravo, tout est bien ordonné et il n'y a pas de discontinuités :)

On ne voit pas de coupure dans le profile de waymarked trails 

 :)


Et il y a bien l'aller et le retour dans JOSM (le tout bien ordonné) :

[Copie d'écran de JOSM montrant les membres de la relation ordonnés] : image 
filtrée :(

> Pour la situation dont tu parles, j'avais gardé tous les segments dans la
> même relation, en essayant simplement de les mettre dans un ordre cohérent
> (pas toujours facile !) et en mettant des roles "forward" sur les trajets
> à sens unique.
forward (si le parcours se fait dans le sens du chemin) ;)

> Ça m'intéresse de savoir si cette approche peut poser problème pour
> certains usages,
Je ne crois pas, et en plus ça résout le problème de façon simple :)

> En tout cas ça me paraît beaucoup plus simple que de faire une relation
> aller et une relation retour, ce qui obligerait à dupliquer la majorité du
> trajet dans les deux relations (ou alors j'ai mal compris).
C'est le risque.

@Axel
> En ce qui concerne les itinéraires cyclables, pour ma part je considère
> qu’introduire les deux sens dans une unique relation suffit largement.
+1
Il ne me reste plus qu'à compléter/corriger

> Après on peut éventuellement faire des exceptions pour certains
> itinéraires urbains, car il est vrai que les deux sens sont très souvent
> départagés sur la majorité du parcours.
Je suis preneur d'un exemple réel.

@Marc
> la méthode classique consite :
> - pour les autres routes : une unique relation avec forward/backward.
oui, mais comment y arriver sans discontinuités ?
Baptiste et JOSM donnent la réponse :)
(je n'ai pas retrouvé ça dans le wiki)

> appliquer route_master aux itinéraires non-transport en commun
> pourrait être intéressant, mais c'est pas le genre de chose
> qui doit se décider entre Yves et Philippe.
On est d'accord, c'est pourquoi je demandais l'aide des spécialistes :)

> cela devrait être porté au niveau mondial (liste tagging),
> et s'il y a un consensus,
La version utilisée par Baptiste et Axel me va bien. Il faut peut-être mieux la 
documenter :)

Un grand merci pour vos réponses
__
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
C'est bien justement pour cette raison (minimiser le nombre de relations)
que je propose un meilleur modèle, basé sur le modèle "v1" mais avec des
règles plus précises. En gros on peut encore utyiliser les rôles
forward/backward pour distinguer les parcours dans les deux sens, mais on
sait que le tri automatique ne fonctionne pas bien. Mais pour nombre de
lignes dont le parcours est bidirectionnel (identique dans les deux sens)
il suffit.

Tout le reste: c'est la notion de "section" qui définit ça (je ne crée pas
de type de relation supplémentaire, juste un tag pour clarifier comment
interpréter la liste des membres, c'est à dir soit un seul parcours
continu, soit plusieurs parcours diférents, indépendamment de leur sens (et
sinon une règle permettant de préciser le sens s'il n'y en a qu'un
applicable à ce parcours, grâce aux noeuds "from/to", un seul suffit
toujours, et éventuellement deux noeuds "via1" et" via2" uniquement pour
les sections en cyclique fermé)

Et même ce que je précise permet de ne pas créer de relation du tout si le
parcours (une section ou une ligne entière) n'a qu'un seul chemin valable
dans les deux sens.

Le modèle v1 était pas si bête, il lui manque pas grand chose (mais
franchement quand on a compris les "sections" on voit immédiatement que les
rôles backward/froward ne servent plus à rien et qu'on peut s'en passer:
- Une ligne simple, non cyclique, avec deux parcours différents selon le
sens, c'est juste deux relations (une par section unidirectionnelle avec
son noeud propre "from" ou "to" , on peut mettre les deux mais un seul
suffit), et une relation maitre !
- Si la ligne a d'autres variantes, on ajoute une relation par variante
bidirectionnelle, ou 2 relations par variante ayant deux parcours selon le
sens

Tout peut se faire avec des relations "type"="route", y compris les
"super-routes" dont les routes européennes, et on peut largement
simplifier les réseaux de lignes qui partagent souvent de nombreuses
sections communes dans le "coeur de réseau".




Le dim. 31 mai 2020 à 20:45, Yves P.  a écrit :

> Euh, ouais, non, deux relations c'est deux fois plus de travail, déjà que
> la maintenance n'est pas facile.
>
> Avec la bonne méthode, une relation c'est mieux :)
>
> Puis perso, je m'embête rarement à ordonner les chemins (c'est un travail
> d'ordinateur ça :).
>
> Je me sert du bouton du bouton trier les membres, mais dans ce cas ça ne
> fonctionnait pas (relation trop cassée).
> J'ai refais un essais, le tri fonctionne bien jusqu'à la fin de la
> première intersection Aller/retour, ensuite il faut aider JOSM.
>
> __
> Yves
>
> ___
> 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] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Yves P. 
> Euh, ouais, non, deux relations c'est deux fois plus de travail, déjà que la 
> maintenance n'est pas facile.
Avec la bonne méthode, une relation c'est mieux :)

> Puis perso, je m'embête rarement à ordonner les chemins (c'est un travail 
> d'ordinateur ça :).
Je me sert du bouton du bouton trier les membres, mais dans ce cas ça ne 
fonctionnait pas (relation trop cassée).
J'ai refais un essais, le tri fonctionne bien jusqu'à la fin de la première 
intersection Aller/retour, ensuite il faut aider JOSM.

__
Yves

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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Florimond Berthoux 
Le dim. 31 mai 2020 à 11:42, Yves P.  a écrit :

>
>>- Une relation aller et une relation retour comme pour les itinéraires
>>de transports en commun
>>
>> 
>> ?
>>
>> A —> B ——> C —> D (aller)
>>
>> D —> C B —> A (retour)
>>\ ——> /
>>
>
> C'est la solution universelle.
>
> Donc je retiens ça :)
>
> Si les cyclistes sont d'accord, je garde dans la relation actuelle Bayonne
> - Hendaye que l'aller.
> Et avec un peu de courage, quelqu'un va créer le retour.
>
> Ok ?
>
>
Euh, ouais, non, deux relations c'est deux fois plus de travail, déjà que
la maintenance n'est pas facile.
Puis perso, je m'embête rarement à ordonner les chemins (c'est un travail
d'ordinateur ça :).


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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Marc M. 
Hello,

Le 31.05.20 à 10:39, Yves P. a écrit :
> Comment faites-vous dans ces cas là ?

la méthode classique consite :
- pour les transport en commune d'avoir une relation par variante
avec un route_master pour qui les regroupe
- pour les autres routes : une unique relation avec forward/backward.

appliquer route_master aux itinéraires non-transport en commun
pourrait être intéressant, mais c'est pas le genre de chose
qui doit se décider entre Yves et Philippe.
cela devrait être porté au niveau mondial (liste tagging),
et s'il y a un consensus, laisser un temps de temps aux
outils principaux pour s'adapter pour éviter une
"amélioration théorique, destructrive en pratique"

Cordialement,
Marc

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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
Finalement mon modèle ci n'est pas un schéma "v3", en fait il est
totalement compatible avec le v1 par défaut, mais réintègre le shéma v2
avec des règles plus précise et plus aucun besoin de préciser la version v2.
Il retient cependant de la v2 la possibilité de séparer les sens (en créant
des variantes de sens ou de parcours explicitement dans les relations
"route" qui représentent une ligne grace à un attribut
"route:variants=yes", ce qui peut aussi s'écrire en utilisant le tag "v2"
actuel, mais SANS rendre obsolète le schéma "v1" par défaut, qui reste très
utile pour indiquer que la route est bidirectionnelle).

Bref ce que je propose ne fait que préciser ce que le schéma v2 omettait de
fixer par des règles, et là où le schéma v1 seul (lignes uniquement
bidirectionnelles et contenant toutes les variantes de parcours mélangées)
était insuffisant.


Le dim. 31 mai 2020 à 14:20, Philippe Verdy  a écrit :

> Maintenant une "section" (relation "route" ou chemin unique) peut être une
> ligne entière: elle porte son numéro et son attribut de réseau en tant que
> ligne, mais pas si ce n'est qu'un sens de parcours d'une ligne (elle a des
> noeuds membres "from"/"to"/"via1"/via2") ou une des variantes de cette ligne
>
> Reste la question des lignes:
> - une ligne peut être constitué d'une seule ou plusieurs sections (évoqué
> ci-dessus), unidirectionnelles ou pas, ou bien être une collection de
> trajets (un membre par variante ou par sens distingué): il faut un attribut
> à la route (pas de role pour chaque membre) pour indiquer que les chemins
> ou relations membres sont exclusifs les une des autres et ne se raboute
> pas: un attribut comme "route:variants"="yes" (par défaut c'est "no" et
> tous les membres se mettent bout à bout et ne doivent dormer qu'une seule
> ligne continue éventuellement cyclé sur elle-même
> - si la ligne indique l'attribut  "route:variants"="yes", les éventuels
> noeuds membres "from"/"to"/"via1"/"via2" sont informatifs mais ne
> déterminent strictement rien (on devrait les éliminer)
> - les noeuds "via" existants ne servent à rien, ils ne sont jamais
> discriminants et pas suffisant pour les parcours cycliques car il en faut
> au moins deux clairement distingués (au moins "via1" et "via2" détermine
> leur ordre relatif, alors qu'avec "via" ce serait l'ordre des membres dans
> la relation et on sait qu'il n'est pas stable ni significatif).
> - si la ligne contient plusieurs sections, soit elles sont toutes
> bidirectionnelles alors la ligne est bidirectionnelle, soit elles sont
> toutes unidirectionnelles, et la ligne est unidirectionnelle. On ne peut
> pas avoir un mix sans transformer la relation en collection de variantes,
> avec une sous-relation pour chaque sens ou variante.
>
> Là on a des règles précises, on peut abolument tout modéliser: sections
> tarifaires, complexité des circuits, sens de parcours, détours facultatifs,
> prolongations facultatives de lignes (en ajoutant une variante contenant le
> premier parcours plus cours déjà ajouté comme une des variantes de la
> ligne).
>
> Dernier ajout:
> - les neuds "from"/"to"/via1" et "via2" requis pour les sections DOIVENT
> être des noeuds terminaux parmi chemins listés (ce ne sont pas des "arrêts"
> au sens des transports qui peuvent eux être sur les chemins mais pas
> nécessairement à l'extrémité, ou être juste proche des chemins). Si ceux
> noeuds sont facultatifs (comme décrit plus haut), ou s'ils ne respectent
> pas ces conditions, cex noeuds ne déterminent PAS les parcours et la
> topologie, ils sont juste informatifs (comme aussi les noeuds des positions
> d'arrêts s'ils sont placés ailleurs qu'à l'extrémité d'un chemin d'une
> section)
>
> Le traitement automatisé des lignes et la vérification complète est
> possible pour TOUTES les lignes les plus compliquées et ayants diverses
> variantes de parcours, sens, prolongations, variantes saisonnières. Ce
> modèle est totalement séparé de la liste des arrêts desservis qui sont des
> noeuds membres. Cependant les arrêts décrits comme des "stop_position"
> (suer les chemins) pourraient correspondre à un des noeuds
> "from/to/via1/via2" nécessaires à la topologie des parcours; les rôles
> "from/to/via1/via2" peuvent donc s'ajouter aux rôles "stop_position" sur un
> même noeud membre, l'un des premier rôles ne remplacant pas le dernier (par
> exemple cela peut demander un rôle "from;stop_position" en utilisant un
> point-virgule séparateur)
>
>
> Le dim. 31 mai 2020 à 13:55, Philippe Verdy  a écrit :
>
>> Maintenant il reste à définir les règles pour les "sections":
>>>
>> - une section est modélisée soit par une unique chemin, soit par une
>> relation "route"
>> - une section est constituée d'un ou plusieurs chemins
>> - le ou les chemins constituant la section ne comportent aucun boucle
>> intermédiaire, aucune variante ou branche, aucun chemin parcouru plusieurs
>> fois
>> - la section peut être cependant fermée sur elle-même constituant un
>> seule cycle: elle doit

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Axel Listes 
Bonjour,

Le 31/05/2020 à 13:53, Baptiste Jonglez a écrit :
> En tout cas ça me paraît beaucoup plus simple que de faire une relation
> aller et une relation retour, ce qui obligerait à dupliquer la majorité du
> trajet dans les deux relations (ou alors j'ai mal compris).


Disons que les besoins ne sont pas les même que pour d'autres types de
transports, notamment les TEC qui doivent respectent un sens spécifique
concernant les arrêts.

En ce qui concerne les itinéraires cyclables, pour ma part je considère
qu’introduire les deux sens dans une unique relation suffit largement.
Les départager n'ajoute que de la complexité à la maintenance, ce dont
je sais à quoi je fais référence puisque je "maintiens" régulièrement
des Véloroutes nationales qui passent dans la région ou je vis.

Après on peut éventuellement faire des exceptions pour certains
itinéraires urbains, car il est vrai que les deux sens sont très souvent
départagés sur la majorité du parcours.

Axel.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
Maintenant une "section" (relation "route" ou chemin unique) peut être une
ligne entière: elle porte son numéro et son attribut de réseau en tant que
ligne, mais pas si ce n'est qu'un sens de parcours d'une ligne (elle a des
noeuds membres "from"/"to"/"via1"/via2") ou une des variantes de cette ligne

Reste la question des lignes:
- une ligne peut être constitué d'une seule ou plusieurs sections (évoqué
ci-dessus), unidirectionnelles ou pas, ou bien être une collection de
trajets (un membre par variante ou par sens distingué): il faut un attribut
à la route (pas de role pour chaque membre) pour indiquer que les chemins
ou relations membres sont exclusifs les une des autres et ne se raboute
pas: un attribut comme "route:variants"="yes" (par défaut c'est "no" et
tous les membres se mettent bout à bout et ne doivent dormer qu'une seule
ligne continue éventuellement cyclé sur elle-même
- si la ligne indique l'attribut  "route:variants"="yes", les éventuels
noeuds membres "from"/"to"/"via1"/"via2" sont informatifs mais ne
déterminent strictement rien (on devrait les éliminer)
- les noeuds "via" existants ne servent à rien, ils ne sont jamais
discriminants et pas suffisant pour les parcours cycliques car il en faut
au moins deux clairement distingués (au moins "via1" et "via2" détermine
leur ordre relatif, alors qu'avec "via" ce serait l'ordre des membres dans
la relation et on sait qu'il n'est pas stable ni significatif).
- si la ligne contient plusieurs sections, soit elles sont toutes
bidirectionnelles alors la ligne est bidirectionnelle, soit elles sont
toutes unidirectionnelles, et la ligne est unidirectionnelle. On ne peut
pas avoir un mix sans transformer la relation en collection de variantes,
avec une sous-relation pour chaque sens ou variante.

Là on a des règles précises, on peut abolument tout modéliser: sections
tarifaires, complexité des circuits, sens de parcours, détours facultatifs,
prolongations facultatives de lignes (en ajoutant une variante contenant le
premier parcours plus cours déjà ajouté comme une des variantes de la
ligne).

Dernier ajout:
- les neuds "from"/"to"/via1" et "via2" requis pour les sections DOIVENT
être des noeuds terminaux parmi chemins listés (ce ne sont pas des "arrêts"
au sens des transports qui peuvent eux être sur les chemins mais pas
nécessairement à l'extrémité, ou être juste proche des chemins). Si ceux
noeuds sont facultatifs (comme décrit plus haut), ou s'ils ne respectent
pas ces conditions, cex noeuds ne déterminent PAS les parcours et la
topologie, ils sont juste informatifs (comme aussi les noeuds des positions
d'arrêts s'ils sont placés ailleurs qu'à l'extrémité d'un chemin d'une
section)

Le traitement automatisé des lignes et la vérification complète est
possible pour TOUTES les lignes les plus compliquées et ayants diverses
variantes de parcours, sens, prolongations, variantes saisonnières. Ce
modèle est totalement séparé de la liste des arrêts desservis qui sont des
noeuds membres. Cependant les arrêts décrits comme des "stop_position"
(suer les chemins) pourraient correspondre à un des noeuds
"from/to/via1/via2" nécessaires à la topologie des parcours; les rôles
"from/to/via1/via2" peuvent donc s'ajouter aux rôles "stop_position" sur un
même noeud membre, l'un des premier rôles ne remplacant pas le dernier (par
exemple cela peut demander un rôle "from;stop_position" en utilisant un
point-virgule séparateur)


Le dim. 31 mai 2020 à 13:55, Philippe Verdy  a écrit :

> Maintenant il reste à définir les règles pour les "sections":
>>
> - une section est modélisée soit par une unique chemin, soit par une
> relation "route"
> - une section est constituée d'un ou plusieurs chemins
> - le ou les chemins constituant la section ne comportent aucun boucle
> intermédiaire, aucune variante ou branche, aucun chemin parcouru plusieurs
> fois
> - la section peut être cependant fermée sur elle-même constituant un seule
> cycle: elle doit comporter un noeud "from" ou un noeud "to" (les deux étant
> le même noeud on n'a pas besoin de l'ajouter deux fois) correspondant à son
> unique terminus
> - sinon la section forme une ligne dont les deux terminus sont déterminés
> automatiquement en joignant les chemins : il ne doit rester alors que deux
> noeuds
> - une section, cyclique ou pas, est par défaut bidirectionnelle, ou
> unidirectionnelle. si elle est bidirectionnelle, aucun autre noeud ou
> attribut n'est nécessaire (les noeuds membres "from/to" sont facultatifs)
> - si elle est unidirectionnelle, alors deux cas :
>* (1): la section est cyclique, il FAUT lui ajouter deux noeuds membres
> distincts (rôles "via1" et "via2", le cycle est orienté de "from/to" à
> "via1", puis "via2" puis "from/to"; on n'a qu'un seule noeud membre avec le
> rôle "from" ou "to", peu importe, mais il faut deux autres noeuds). tous
> les chemins du cycle sont joints et par un unique noeud de jonction, tous
> les noeuds de jonction sont liés chacun à deux chemins, s'il n'y a qu'un
> seule

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
>
> Maintenant il reste à définir les règles pour les "sections":
>
- une section est modélisée soit par une unique chemin, soit par une
relation "route"
- une section est constituée d'un ou plusieurs chemins
- le ou les chemins constituant la section ne comportent aucun boucle
intermédiaire, aucune variante ou branche, aucun chemin parcouru plusieurs
fois
- la section peut être cependant fermée sur elle-même constituant un seule
cycle: elle doit comporter un noeud "from" ou un noeud "to" (les deux étant
le même noeud on n'a pas besoin de l'ajouter deux fois) correspondant à son
unique terminus
- sinon la section forme une ligne dont les deux terminus sont déterminés
automatiquement en joignant les chemins : il ne doit rester alors que deux
noeuds
- une section, cyclique ou pas, est par défaut bidirectionnelle, ou
unidirectionnelle. si elle est bidirectionnelle, aucun autre noeud ou
attribut n'est nécessaire (les noeuds membres "from/to" sont facultatifs)
- si elle est unidirectionnelle, alors deux cas :
   * (1): la section est cyclique, il FAUT lui ajouter deux noeuds membres
distincts (rôles "via1" et "via2", le cycle est orienté de "from/to" à
"via1", puis "via2" puis "from/to"; on n'a qu'un seule noeud membre avec le
rôle "from" ou "to", peu importe, mais il faut deux autres noeuds). tous
les chemins du cycle sont joints et par un unique noeud de jonction, tous
les noeuds de jonction sont liés chacun à deux chemins, s'il n'y a qu'un
seule chemin c'est un chemin fermé, son terminus est son noeud de début et
de fin, le noeud "from" ou "to" n'est pas nécessaire dans la section, mais
il faut quand même une relation pour ajouter des membres "via1" et "via2"
(ce qui n'est pas nécessaire pour une section cyclique bidirectionnelle
constituée d'un seul chemin fermé sans relation)
   * (2): la section n'est pas cyclique, pas besoin de noeuds "via1" et
"via2": on peut les ajouter mais cela ne détermine pas le sens, c'est juste
informatif, mais il faut alors deux noeuds membres "from" et "to" distincts
pour indiquer le sens de parcours
- les relations "route" représentant une section n'ont aucun ordre fixé
pour les membres, les chemins membres ne sont membres qu'une seule fois
(sans doublon et sans jamais aucun rôle nécessaire), 2 ou trois noeuds
membres distincts peuvent exister eux aussi dans un ordre quelconque (et
seulement si la section est à un seul sens): soit "from" et "to" pour les
sections non cycliques; soit "from" (ou "to") et "via1" et "via2" pour les
sections cycliques
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Baptiste Jonglez 
Salut,

On 31-05-20, Yves P. wrote:
> Bonjour,
> 
> > Suite à la diffusion de cette vidéo sur peertube 
> > ,
> >  j'ai mis les conseille de Charles Millet en pratique sur une section de 
> > l'EV1, plus exactement sur la sectionBayonne - Hendaye.
> 
> Cet itinéraire est linéaire mais à quelques endroits, le trajet aller diffère 
> du trajet retour (gros ronds points, voies parallèles en sens unique…).
> Voici un exemple à Biarritz 
> .
> 
> Actuellement la relation est continue à l'aller, mais les petits détours du 
> retours ne sont pas reliés correctement.
> 
> A <—> B ——> C< —> D
>  \ <—— /
> 
> Comment faites-vous dans ces cas là ?

L'été dernier, j'ai eu une situation similaire sur d'autres morceaux de l'EV1.
J'étais parti pour simplement mettre à jour un tronçon et je me suis
retrouvé à faire du nettoyage / rajouter de la continuité sur un bon bout
du trajet ;)

Pour la situation dont tu parles, j'avais gardé tous les segments dans la
même relation, en essayant simplement de les mettre dans un ordre cohérent
(pas toujours facile !) et en mettant des roles "forward" sur les trajets
à sens unique.

Exemple aux Sables d'Olonne : 
https://cycling.waymarkedtrails.org/#route?id=4840311=16!46.5019!-1.7885

+ le tronçon correspondant dans JOSM en pièce jointe.

Ça m'intéresse de savoir si cette approche peut poser problème pour
certains usages, et qu'est-ce que tu veux dire exactement par « les petits
détours du retours ne sont pas reliés correctement » : est-ce que c'est
juste une question d'ordre des segments ?

En tout cas ça me paraît beaucoup plus simple que de faire une relation
aller et une relation retour, ce qui obligerait à dupliquer la majorité du
trajet dans les deux relations (ou alors j'ai mal compris).

> Une relation aller et une relation retour comme pour les itinéraires de 
> transports en commun 
>  
> ?
> A —> B ——> C —> D (aller)
> 
> D —> C B —> A (retour)
>\ ——> /
> 
> Que le trajet aller pour simplifier : les petites boucles sont ignorées ? 
> (c'est ce que montre la trace gpx de la Vélodyssée 
> )
> A —> B ——> C —> D (aller)
> 
> 
> Une relation mais avec des sous relations pour les "boucles" aller/retour ?
> A <——> B
> 
>B ——> C
>\ <—— /
> 
>  C <——> D
> 
> __
> Yves
> 

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



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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
On peut noter que si on utilisait systématiquement les relations de type
"route_section", on éviterait tous les problèmes d'ordre et d'inclusion
multiples d'un même chemin dans une même relation de trajet "route": il
suffit de créer des sections (on peut section où on veut tant que cela
évite les chemins parcourus plusieurs fois).

Cela simplifierait aussi énormément la modélisation des lignes de transport
dans un réseau (ou plusieurs) qui souvent ont des tas de sections communes:
les chemins pour la plupart ne feraient partie que d'une seule relation
"section" et non plusieurs, on pourrait facilement fusionner/scinder ces
chemins selon leurs caractéristiques locales sans casser la relation
section ni aucune des relations de trajet (routes).

L'assemblage ensuite des trajets (relations "route") serait grandement
simplifié: il suffit de créer la collection de sections, dans n'importe
quel ordre.

Plus besoin des rôles "forward/backward" dans les relations de type
"section".

Les trajets (relations "route") pourraient être en modèle v1 (routes
parcourues dans les deux sens), ou v2 (routes à un seul sens, en indiquant
le point de départ et/ou celui d'arrivée en membre supplémentaire averc un
rôle "from"/"to")

Les lignes (ensemble de trajets ayant un même numéro, incluant les
différents sens et variantes) seraient de simple collections non ordonnées
de trajets (relations "route")

Les réseaux seraient de simple ensembles non ordonnées de lignes.

Plus aucun problème pour superposer partiellement plusieurs réseaux, gérer
des "conumérations" de certaines sections partagées: la numérotation des
lignes sur les sections n'a plus de sens (c'est juste "informatif" mais
plus "caractéristique"), ce sont alors seulement les relations de type
"ligne" qui indiquent les vrais numéros.

Cependant une duplication de certaines sections serait nécessaire pour les
zones tarifaires propres à chaque ligne qui emrunte la section: la zone
tarifaire (ou les conditions d'accès: réservation, etc.) est une
caractéristique de chaque section.

Une relation trajet (relation route) peut inclure des sections de
plusieurs façons:
* soit un simple chemin membre représente la section entière (qui peut
encore être scindé en plusieurs chemins si ce découpage de la section
n'indique pas un découpage de la section partagée par plusieurs trajets
d'une ou plusieurs lignes)
* soit une relation membre

Les rôles "forward/backward" sont supprimés alors réellement, on n'ajoute
que les rôles "from"/"to" (pour la v2 et uniquement quand les trajets ne
sont pas bidirectionnels mais différents selon le sens)

Pas besoin de rôle ou de nouveau type pour les sections: ce sont à nouveau
des relations "route" mais sans numérotation ni réseau obligatoire.

La seule chose significative dans les relations "route", c'est:
   - est-ce que les membres (chemins ou relations) sont des alternatives
(exclusives: dont les sens de parcours, ou les variantes) ou des
juxtapositions (de sections) mises bout à bout formant un même parcours: un
seul attribut dans la relation route suffit à l'indiquer
  - de même qu'un attribut (actuellement "v1 ou v2") indique (seulement
valable dans un trajet, par une "ligne" ayant plusieurs trajet, ni pour une
section qui sert à différents trajets ou est partagé par plusieurs lignes)
si le trajet est à un seul sens ou décrit les deux sens. Bien que ce serait
à deux sens par défaut, **sauf** s'il y a un noeud membre "from"/"to" : les
indicateurs "v1 et v2" sont obsolètes remplacés par la présence ou
l'absence des noeuds membres de rôle "from"/"to" !

Avec ça on peut tout modéliser (toutes les variantes d'une ligne ou d'un
trajet, toutes les boucles et détours qu'il suffit de découper en
sections). on n'a plus à se soucier d'inverser les "forward/backward" qui
sont toujours omis. Plus aucune relation route n'a besoin d'être ordonnée.
On peut scinder les chemins comme on veut (il faut prendre garde seulement
aux fusions: une fusion ne devrait pas avoir lieu sans regarder les
relations qui l'incluent: si les jeux de relations sont différents, on de
doit pas fusionner: il faudra contraoler chaque relation parente pour voir
s'il ne manque pas un chemin membre ou s'il y en a un en trop.

Et les sections permettent de redéfinir les "super-routes" elles aussi
obsolètes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
Le dim. 31 mai 2020 à 11:24, Philippe Verdy  a écrit :

>
> A ——> B —> C ——> Z
>  \ <— D <—— /
>
> (Ici l'ordre est A,B,C,D,B,C,Z (le trajet repasse ici deux fois par B et C
> dans le même sens).
>

Ici cette "solution" est parfois utilisée abusivement pour tronçonner les
ronds-points/giratoires quand ce n'est pas nécessaire (même s'il y a un
arrêt sur le rond-point). Le découpage n'est utile que si le rond-point n'a
pas une caractéristique unique (changement du nombre de voies, présence de
ponts/tunnels, parfois des intersections traversant le rond-point pour des
voies spéciales et des cédez-le-passage/stops ou feux, avec une
signalisation particulière qui n'est plus le simple giratoire avec priorité
à gauche aux véhicules déjà présents dans l'anneau).

Autant que possible garder les ronds-points en un seul morceau (d'autant
qu'ils sont en sens unique donc il n'y a pas d'ambiguïté) car ça simplifie
énormément le routage et c'est nettement plus facile d'éviter de "casser"
une relation en oubliant un tronçon.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
Le dim. 31 mai 2020 à 11:24, Philippe Verdy  a écrit :

>
>
>>- Une relation mais avec des sous relations pour les "boucles"
>>aller/retour ?
>>
>> A <——> B
>>
>>B ——> C
>>\ <—— /
>>
>>  C <——> D
>>
>
> Solution jamais utilisée qui n'existe dans aucun modèle.
>

Correction, cette solution est utilisée pour les "super-relations" des
routes européennes, séparées en plusieurs sections (une par pays parfois
plus dans les grands pays), mais il aurait fallu créer un rôle "section"
pour indiquer que les relations membres ne sont pas des variantes d'une
même "ligne" mais des éléments qui s'ajoutent de bout en bout.

Cette solution sert principalement à limiter le nombre de membres à
maintenir dans chaque section, donc seulement les routes très longues
(comme les routes européennes).

Cependant elle pourrait servir justement dans les lignes de transport comme
le RER en île-de-France ou les trains "intercités", avec ses trajets
découpés en sections tarifaires (par zone), ou pour indiquer quand il faut
un ticket de plus (lignes de bus départementales/régionales, tickets
séparés, un par intercommunalité desservie, ou supplément à payer pour
parcourir plusieurs sections): les sections d'un même trajet peuvent avoir
plusieurs numérotation simultanées: une même section peut faire partie de
plusieurs lignes différentes appartenant à plusieurs réseaux de transport
différents dont même aucune des lignes de ces réseaux utilisant une section
donnée n'inclue la totalité des sections du même trajet. Les trajets n'ont
donc pas une "ligne" (d'un réseau) unique, pas plus que les sections.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Yves P. 
> Une relation aller et une relation retour comme pour les itinéraires de 
> transports en commun 
>  
> ?
> A —> B ——> C —> D (aller)
> 
> D —> C B —> A (retour)
>\ ——> /
> 
> C'est la solution universelle.
Donc je retiens ça :)

Si les cyclistes sont d'accord, je garde dans la relation actuelle Bayonne - 
Hendaye que l'aller.
Et avec un peu de courage, quelqu'un va créer le retour.

Ok ?

> 
> Note: l'ordre des membres dans une relation de transport n'est normalement 
> pas significatif, c'est bien le sens des tracés qui indique la continuité.
Le contexte ici est une randonnée en vélo de route (mais aussi VTT, cheval…).
L'ordre et le sens doivent être respecté ;)

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

Re: [OSM-talk-fr] itinéraire avec trajet aller/retour — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Philippe Verdy 
Le dim. 31 mai 2020 à 10:43, Yves P.  a écrit :

> Actuellement la relation est continue à l'aller, mais les petits détours
> du retours ne sont pas reliés correctement.
>
> A <—> B ——> C< —> D
>  \ <—— /
>
> Comment faites-vous dans ces cas là ?
>
>- Une relation aller et une relation retour comme pour les itinéraires
>de transports en commun
>
> 
> ?
>
> A —> B ——> C —> D (aller)
>
> D —> C B —> A (retour)
>\ ——> /
>

C'est la solution universelle.

L'autre solution utilise l'ancien modèle du schéma de transport en
mélangeant les membres dans les deux sens dans la même relation (et pour
savoir quel chemin est utilisé, avec des rôles forward/backward,
facultatifs si ce sont des sens uniques). Imaginons que les deux chemins de
B vers C et C vers B sont des sens uniques:
A <—> B ——> C< —> D
 \ <—— /
Il n'y a aucun rôle à ajouter, on peut mettre les deux. Si ces chemins ne
sont pas à sens uniques, on met un rôle forward ou backward selon leur sens
de tracé.

Note: l'ordre des membres dans une relation de transport n'est normalement
pas significatif, c'est bien le sens des tracés qui indique la continuité.
Mais il faut indiquer un point de départ ou d'arrivée. Trier les membres
reste cependant recommandé (pour traiter les cas comme les boucles qui
repassent par un même point (pas forcément un arrêt) ou réemprunte un même
chemin, pas nécessairement dans le sens opposé:

A ——> B —> Z
 /\
  /   \
> C—>D
(Ici l'ordre est A,B,C,D,Z, le trajet repasse deux fois par B)

A ——> B —> Z
||
C
 /\
  /   \
> D—>E
(Ici l'ordre est A,B,C,D,E,C,B,Z, le trajet repasse deux fois par B et C,
mais dans les sens opposés)

A ——> B —> C ——> Z
 \ <— D <—— /

(Ici l'ordre est A,B,C,D,B,C,Z (le trajet repasse ici deux fois par B et C
dans le même sens).

.
C'est pour ça qu'on doit malgré tout garder les chemins membres triés et
malgré tout utiliser encore les rôles forward/backward, et parfois mettre
un même chemin deux fois comme membre dans la relation)

Et cela c'est juste pour un seul parcours dans un sens (de A vers Z), Avec
l'autre sens de Z vers A c'est un autre trajet qui s'ajoute comme membre
d'une super-relation (qui peut contenir d'autres variantes: autres trajets
intermédiaires avec des arrêts non desservis, ou départ/destination
différents)

Donc le "nouveau" modèle n'a pas remplacé l'ancien, il s'est seulement
ajouté pour indiquer les variantes de trajet d'une même ligne.
Les rôles forward/backward sont encore là (facultatifs), de même que les
membres pouvant être présents plusieurs fois, et la nécessité de garder les
membres triés au moins partiellement...
Seulement le schéma "v2" est fait de sorte qu'un trajet modélisé dans un
sens n'indique plus automatiquement et exactement le même chemin dans le
sens inverse: chaque trajet (sens ou variante) est séparé, et il lui faut
une super-relation pour modéliser chaque trajet, chacun avec sa
"complexité".


>- Que le trajet aller pour simplifier : les petites boucles sont
>ignorées ? (c'est ce que montre la trace gpx de la Vélodyssée
>)
>
> A —> B ——> C —> D (aller)
>

Cela peut être suffisant (hors des lignes à trajet imposé pour desservir
les arrêts, aucun trajet n'est impératif, chacun peut faire des petits
détours à tout moment (même des lignes de transport sont
temporairement déviés sans que cela change a liste des arrêts desservis,
avec parfois juste un déplacement et un affichage quand il y a des travaux,
ou une difficulté locale)

>
>
>- Une relation mais avec des sous relations pour les "boucles"
>aller/retour ?
>
> A <——> B
>
>B ——> C
>\ <—— /
>
>  C <——> D
>

Solution jamais utilisée qui n'existe dans aucun modèle.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr