Re: [OSM-talk-fr] Désaccord sur un highway=footway

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

Le 31.05.20 à 19:30, Florimond Berthoux a écrit :
> Le sam. 30 mai 2020 à 10:34, Éric Gillet a écrit :
>> bicycle=yes veut dire que c'est légal
> c'est ton interprétation de la loi sauf que ce n'est pas le sujet.

j'ai l'impression en survolant le sujet (parce que trop de messages
qui fait qu'on se perd dans les arguments) que vous vous embourbez
dans la législation alors que c'est pas cela qu'on tag).

j'aurais tendance à faire :
- pour éviter le flip-flop cyclway<>footway : utiliser path plus
neutre (en survolant, je n'ai vu ni panneau pour l'un ou l'autre là)
- si certains partie sont des trottoirs, des passages piétons
ou autre, il y a des tags pour objectiver (=sidewalk, =crossing)
- s'il y a des panneaux, mapper les panneaux.
- est-ce qu'il y a un panneau qui interdit le vélo ? en survolant,
j'en ai pas l'impression. non donc pas de tag pour le vélo (par
analogie, on ne met pas horse=no sur une autoroute)
- à l'inverse s'il n'y a pas de panneau qui footway/cycleway,
ne pas non plus mettre de tag en ce sens (parce que bicycle=yes
est un tag d'accès, pas un tag d'usage)
- maxwidth:physical pour la largeur en pratique d'une barrière <>
maxwidth = panneau de limitation (qui est différente de la largeur pratique)
ainsi un routage qui veux se limite aux infra avec signalisation poura
le faire, le routage qui veux inclure l'infra utilisable poura aussi.

si malgré tout cela c'est pas clair, faire un message résumé
de la position des 2 avis opposés et lien sur way précis.

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 
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] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet osm . sanspourriel 

Le 31/05/2020 à 10:46, Marc M. - marc_marc_...@hotmail.com a écrit :

Bonjour,

je ne souhaite pas "nous tirer dans les pattes"
au contraire, je pense que tu poses le bon diagnostic :
un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
mais je pense étrangement ton outil n'est pas adapté pour cela.

je pense qu'il y a 3 cas :

1) les objets dont la position existe dans osm et auquel on ajoute des
infos opendata : à mon avis on n'a pas besoin d'un contributeur
qui fait un clic par objet sans aucune plus-value.
ex : il y une borne très proche dans osm et dans l'opendata.
l'opendata dit operator=A. c'est quoi la plus-value de le faire
à la main ? à mon avis on fait mieux de faire une procédure pour
importer tout cette donnée en une fois.


Non, cas des bornes 29 et 30 du SDIS17.

Une borne a été rapprochée (la 30), maintenant l'outil propose de
rapprocher la 29 et la 30.

Là il y a un soucis, je ne sais si c'est la 29 qui manquait dans OSM ou
la 30.

Mais c'est à voir sur le terrain (ou regarder à nouveau entre la 29 et
la 30 laquelle aurait dû être fusionnée avec la borne OSM).

Nicolas, ça veut dire que sur la carte tu ne devrais pas afficher que la
borne OD en cours mais aussi les autres (d'une autre forme et couleur)

Grosso modo on est d'accord : autant rapprocher automatiquement ce qu'on
peut rapprocher.

Sauf que l'outil permet aussi de gérer les conflits entre les valeurs
OSM et OD.

Il n'empêche ce serait autant de n'avoir à regarder que les conflits.


2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
bonne. ton outil ne permettant pas de voir la borne, il va falloir
ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
de n'avoir un outil ne nécessitant pas de basculer avec un autre.


Non, l'outil a maintenant l'imagerie aérienne. On peut imaginer que l'on
puisse créer une note afin que quelqu'un sur le terrain puisse chercher
la borne afin de la positionner.

Sinon oui pic4Review, etc...

Et pourquoi ne pas faire X % dans un outil et quand ce qui était
faisable dans cet outil a été fait, passer à un autre.

C'est à dire faire ce que l'on peut faire avec un outils sans en changer
puis passer à une autre outil pour la suite.

Par exemple quand on dit non rapprochable on peut dire :
- n'existe pas sur le terrain
- à chercher avec de l'imagerie de rue (pic4review)
- à chercher sur place.

Les deux derniers points sont peut-être confondus : on passe le reste à
pic4review et pour ceux pour qui on fait choux blanc on passe à la revue
sur le terrain. Et on peut mettre ça dans Osmose éventuellement.

Jean-Yvon



___
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] Désaccord sur un highway=footway

2020-05-31 Par sujet Florimond Berthoux 
Le sam. 30 mai 2020 à 10:34, Éric Gillet  a
écrit :

> Le 29/05/2020 à 22:48, Florimond Berthoux a écrit :
>
>
> Le ven. 29 mai 2020 à 16:09, Éric Gillet  a
> écrit :
>
>> Le 29/05/2020 à 10:44, Florimond Berthoux a écrit :
>>
>> Est-ce que les cyclistes y roulent sans jamais se faire verbaliser ? ->
>> oui
>> -> bicycle=yes
>>
>> Les forces de l'ordre ne connaissent pas trop le code de la route sur
>> l'utilisation des aménagements vélo. Bon nombre circulent sans avertisseurs
>> (gyrophare/sirène) dans les voies bus/vélo.
>> Mais aussi de très nombreux cyclistes grillent des feux/stop, utilisent
>> des téléphones sans jamais se faire verbaliser. Cela rends la chose pas
>> moins illégale ou dangereuse.
>>
> Il y a une différence j'ai vu plusieurs fois des cyclistes se faire
> verbaliser pour grillage de feu, y-a-t-il eu une seule fois une
> verbalisation pour avoir roulé sur cette espace ?
>
>
> Il y a déjà la réponse dans mon précédent commentaire. Les forces de
> l'ordre en général ne connaissent pas très bien le code de la route pour
> les infractions "mineures". Hors mission particulière ils ne sanctionnent
> pas trop les cyclistes pour les infractions qu'ils connaissent de mon
> expérience.
> De plus, avec la signalisation pas top, et le fait que même à tête reposée
> en lisant le code de la route, inspectant scrupuleusement les photos on a
> du mal à se mettre d'accord, ce serait difficile pour les FDO passant par
> là de s'assurer qu'une infraction est en cours.
>
> Dernièrement, ce n'est pas parce que j'en ai pas vu qu'il n'y en a pas eu.
> Difficile de savoir, encore plus pour un contributeur à distance tel que OP
> ;)
>
> Il me semble que footway+bicycle=yes indique bien qu’il y a un problème
>> d’aménagement (normalement ça ne devrait pas exister sur un axe de transit
>> vélo).
>>
>> Oui en effet ça indique que l'axe de transit n'est pas continu, mais en
>> soit c'est pas gravissime si c'est correctement signalisé et qu'il n'y a
>> pas de dangers. Là ce n'est ni correctement signalisé, ni sécurisé.
>>
>> Mettre bicycle=yes masque ce problème, et empêche les cyclistes d'avoir
>> cette info et d'emprunter d'éventuels chemins plus sécurisés/rapides.
>>
> Non, bicycle=yes signifie que c'est "légalement" (de facto) possible ça ne
> dit rien de la dangerosité de la chose.
>
> Non, bicycle=yes veut dire que c'est légal (sans guillement) de circuler à
> vélo. Souvent la légalité va de mise avec la sécurité. Ici c'est ni légal,
> ni sécurisé. J'ai déjà parlé plusieurs fois de la légalité, donc je me suis
> focalisé sur la dangerosité sur cette phrase.
>

C'est ton point de vue de dire que ce n'est pas légal, c'est ton
interprétation de la loi sauf que ce n'est pas le sujet.
Le sujet c'est est-ce que les cyclistes peuvent circuler sur l'espace.
Seul le terrain compte : aucun panneau l'interdit, la signalisation le
suggère, les cyclistes l'utilisent, aucun policier ne l'a interdit, donc on
a tag bicycle=yes.
C'est tout.

> Pour dire que ce n'est pas sécurisé faudra utiliser un ou des autres tag.
>
> +1
>
> Je n'avais pas ajouté les obstacles étant donné qu'ils sont tout à fait
> classiques pour de la voirie piétonne, mais autant les mettre vu le débat.
> [1]
>
> [1] https://www.openstreetmap.org/changeset/85974594
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] OSM Relation Analyzer — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet osm . sanspourriel 

Tu peux demander à ne pas passer par le cache.

http://ra.osmsurround.org/analyzeMap?relationId=4840541&*noCache=on*


Et là ça marche, pas la peine d'aller embêter les admin d'OSM France, il
suffit de savoir utiliser l'outil^^.

Jean-Yvon

Le 31/05/2020 à 09:19, Yves P. - yves.prat...@gmail.com a écrit :


J'avais affichée cette relation dans Waymarked Trails: À vélo
 et
dans OSM Relation Analyzer
.
La mise à jour a été très rapide dans Waymarked Trails, par contre 32
mn après, toujours rien dans RA.


Une modification faite il y a 7 heures n'apparait toujours pas. La
dernière modification
 remonte
à 7 jours !
Il semble qu'il y a un gros retard de mise à jour de la base de
données de RA.

Est-ce qu'il est possible de faire tourner une instance sur un serveur
d'OSM France ayant déjà la base postgresql à jour ?
Cette application à besoin de la table suivante :
https://github.com/grundid/relation-analyzer/blob/master/src/main/schema/test-data.sql

__
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] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet Nicolas Bétheuil 
Effectivement c'est mon initiative.

Antonin a eu plus de facilité à utiliser mon outil pour son jeu de données.
Je ne crois pas qu'il lui avait été présenté pic4review, mais osmose ou
josm.

J'ai créé mon outil avec un premier jeu de données probablement plus adapté.

@Marc: Pour reprendre tes différents points
J'avais noté que les imports était plutôt (très) mal vue, positionnement
imprécis : ne pas mettre un borne incendie au milieu de la route par
exemple ou au milieu d'un bâtiment ...
L'interprétation de l'open data en tag OSM peut être compliqué : sur mon
jeu de données, il y a des commentaires dans lequel il y a pleins de choses
(horaires, précisions sur les livraisons ...)
Plutôt que de bloquer le traitement de tout l'import pour quelques-un, ou
d'importer n'importe quoi n'importe comment, autant compter sur
l'intelligence humaine et l'expérience des contributeurs pour traiter ces
exceptions (sur lesquel je n'ai pas assez de recul pour arbitrer, mais au
cas par cas, c'est plus simple). C'est un partit pris de l'outil.
Diviser le travail en plus petit morceaux pour pouvoir avancer.

Concernant le positionnement des points inexistant dans OSM, pour des
resto, des bars ... l'outil est suffisant. pour des bornes incendies, les
photos IGN peuvent aider. On va peut être pas pouvoir traiter les 12 000
points comme ça mais peut être 70% ? ou 20 % ?
En regardant l'autre jour pic4review, j'étais sur une missions des
coiffeurs de mémoire, à peine 50% pouvaient avoir une photo, du coup ce
n'est pas non plus "idéal".

On est d'accord que les relevés terrain sont la meilleur alternative, mais
vu le volume, si on peut déjà en traiter 50% ? Je sais pas trop.
Pour le premier jeu de données, on doit pouvoir en traiter 90% ou 95%.

Mon "positionnement" est de proposer une alternative quand un utilisateur a
du mal à embrasser la richesse de l'écosystème OSM. Peut être cela ne va
mener à rien, et on aura juste un outil de plus, et encore plus de
complexité à dans l'écosystème OSM, ou d'autres opportunités. Partir d'une
feuille blanche m'a permis de proposer autre chose, alors que je n'arrivais
à rien faire avec l'existant (mais c'est un autre sujet). En voyant une
autre manière de faire, peut être que des idées vont émergés. Au moins une
doc arbitrant les alternatives sur laquelle pouvoir se référer plutôt que
de laisser ça aux experts OSM ? Mon "rêve" est de peut être réussir à faire
autre chose avec les meilleurs énergies présentes.

Nicolas

Le dim. 31 mai 2020 à 13:26, Antonin Delpeuch (lists) <
li...@antonin.delpeuch.eu> a écrit :

> Juste pour mettre les choses au clair: il ne s'agit pas de mon outil ;)
>
> Antonin
>
> On 31/05/2020 09:46, Marc M. wrote:
> > Bonjour,
> >
> > je ne souhaite pas "nous tirer dans les pattes"
> > au contraire, je pense que tu poses le bon diagnostic :
> > un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
> > mais je pense étrangement ton outil n'est pas adapté pour cela.
> >
> > je pense qu'il y a 3 cas :
> >
> > 1) les objets dont la position existe dans osm et auquel on ajoute des
> > infos opendata : à mon avis on n'a pas besoin d'un contributeur
> > qui fait un clic par objet sans aucune plus-value.
> > ex : il y une borne très proche dans osm et dans l'opendata.
> > l'opendata dit operator=A. c'est quoi la plus-value de le faire
> > à la main ? à mon avis on fait mieux de faire une procédure pour
> > importer tout cette donnée en une fois.
> >
> > 2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
> > bonne. ton outil ne permettant pas de voir la borne, il va falloir
> > ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
> > de n'avoir un outil ne nécessitant pas de basculer avec un autre.
> >
> > 2a) si on a une photo libre de l'endroit. à ce moment là une mission
> > pic4review serrait bien adapté. encore mieux si elle peux récupérer
> > toutes les points opendata sans sortir de l'outil. histoire justement
> > de rester dans un seul outil.
> > https://pic4review.pavie.info/#/mission/copy
> > mission de type "intégrating fire hydrant"
> >
> > 2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
> > sur le terrain, c'est en ce sens que Vespucci est adapté.
> > surtout qu'il permet de se connecter sur osmose, donc avoir
> > tout, tout en restant dans un seul outil.
> > il manque juste l'équivalent ios de Vespucci (dans le sens
> > un éditeur osm connectable sur osmose, afin de valider
> > la position sur le terrain)
> >
> > Cordialement,
> > Marc
> >
> >
> > Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
> >> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
> >> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
> >> remarqué.
> >>
> >> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
> >> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
> >> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
> >>
> >> L'absence

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

[OSM-talk-fr] hebdoOSM Nº 514 2020-05-19-2020-05-25

2020-05-31 Par sujet theweekly . osm 
Bonjour,

Le résumé hebdomadaire n° 514 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

https://www.weeklyosm.eu/fr/archives/13232/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

2020-05-31 Par sujet Antonin Delpeuch (lists) 
Juste pour mettre les choses au clair: il ne s'agit pas de mon outil ;)

Antonin

On 31/05/2020 09:46, Marc M. wrote:
> Bonjour,
>
> je ne souhaite pas "nous tirer dans les pattes"
> au contraire, je pense que tu poses le bon diagnostic :
> un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
> mais je pense étrangement ton outil n'est pas adapté pour cela.
>
> je pense qu'il y a 3 cas :
>
> 1) les objets dont la position existe dans osm et auquel on ajoute des
> infos opendata : à mon avis on n'a pas besoin d'un contributeur
> qui fait un clic par objet sans aucune plus-value.
> ex : il y une borne très proche dans osm et dans l'opendata.
> l'opendata dit operator=A. c'est quoi la plus-value de le faire
> à la main ? à mon avis on fait mieux de faire une procédure pour
> importer tout cette donnée en une fois.
>
> 2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
> bonne. ton outil ne permettant pas de voir la borne, il va falloir
> ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
> de n'avoir un outil ne nécessitant pas de basculer avec un autre.
>
> 2a) si on a une photo libre de l'endroit. à ce moment là une mission
> pic4review serrait bien adapté. encore mieux si elle peux récupérer
> toutes les points opendata sans sortir de l'outil. histoire justement
> de rester dans un seul outil.
> https://pic4review.pavie.info/#/mission/copy
> mission de type "intégrating fire hydrant"
>
> 2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
> sur le terrain, c'est en ce sens que Vespucci est adapté.
> surtout qu'il permet de se connecter sur osmose, donc avoir
> tout, tout en restant dans un seul outil.
> il manque juste l'équivalent ios de Vespucci (dans le sens
> un éditeur osm connectable sur osmose, afin de valider
> la position sur le terrain)
>
> Cordialement,
> Marc
>
>
> Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
>> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
>> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
>> remarqué.
>>
>> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
>> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
>> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
>>
>> L'absence de dépendance à un éditeur externe est un gros plus pour moi,
>> car le passage répété entre les deux a un coût vraiment non-négligeable.
>>
>> Je pense que c'est bien de respecter la diversité des approches et des
>> outils, évitons de nous tirer dans les pattes…
>>
>> Antonin
>>
>> On 30/05/2020 11:21, Marc M. wrote:
>>> Bonjour,
>>>
>>> je prend mon clavier pour reposer la question tant évitée :
>>> la position est suposée mauvaise au point de ne pas vouloir d'import.
>>> et l'imagerie sat ne permet pas de voir la borne,
>>> du coup que fait le contributeur avec sa souris ?
>>>
>>> le positionement de ton outil m'échappe.
>>>
>>> Cordialement,
>>> Marc qui penche pour osmose+pic4review+vespucci
>>>
>>> Le 30.05.20 à 11:51, Nicolas Bétheuil a écrit :
 Et bah voilà 12000 points de chargé

 amis contributeur, à vos souris



 Le ven. 29 mai 2020 à 22:21, Antonin Delpeuch (lists)
 mailto:li...@antonin.delpeuch.eu>> a écrit :

 Salut Nicolas,

 Voilà la version complète:

 http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson

 Antonin

 On 29/05/2020 17:07, Nicolas Bétheuil wrote:
> Les évolutions / correctifs avancent. Je pousse régulièrement.
> Écrivez moi directement, je verrais si je fais une diffusion
> spécifique pour vous gardez informé des nouveautés.
>
> Christian a ajouté od2osm au proxy IGN ! Merci !
>
> @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent
> plus qu'on cause ensemble, je te propose de continuer en issue github
> @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
> points, loin des 12 000 points que tu avais évoqué.
>
> Le mer. 27 mai 2020 à 12:02, Yves P.  > a écrit :
>
>> Les "name" ont été enlevés du jeu de données et l 'outil
>> affiche maintenant soit name soit ref (en fonction de ce qui
>> existe)
>> J'ai ajouté le fond de carte BD Ortho
> Merci :)
>
>>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
>> proxy
>> 
>> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
> ici ça marche aussi ;)
>
> Pour info, MyOSMatic (maposmatic) sort des carte
>  des PEIs :
> le résultat est plutôt bien :)
> Il faut revoir la taille des réserves incendie et des DAE, et
> éventuellement l'adapter avec les symboles utilisés en

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

Re: [OSM-talk-fr] méthode et outil pour intégrer l'opendata (était: Import de points d'eau incendie en Saône-et-Loire)

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

je ne souhaite pas "nous tirer dans les pattes"
au contraire, je pense que tu poses le bon diagnostic :
un outil pour intégrer l'opendata sans basculer entre plusieurs outils.
mais je pense étrangement ton outil n'est pas adapté pour cela.

je pense qu'il y a 3 cas :

1) les objets dont la position existe dans osm et auquel on ajoute des
infos opendata : à mon avis on n'a pas besoin d'un contributeur
qui fait un clic par objet sans aucune plus-value.
ex : il y une borne très proche dans osm et dans l'opendata.
l'opendata dit operator=A. c'est quoi la plus-value de le faire
à la main ? à mon avis on fait mieux de faire une procédure pour
importer tout cette donnée en une fois.

2) l'objet n'existe pas dans osm et la position de l'opendata n'est pas
bonne. ton outil ne permettant pas de voir la borne, il va falloir
ouvrir un autre outil, ce qui est donc l'exact contraire à ton but
de n'avoir un outil ne nécessitant pas de basculer avec un autre.

2a) si on a une photo libre de l'endroit. à ce moment là une mission
pic4review serrait bien adapté. encore mieux si elle peux récupérer
toutes les points opendata sans sortir de l'outil. histoire justement
de rester dans un seul outil.
https://pic4review.pavie.info/#/mission/copy
mission de type "intégrating fire hydrant"

2b) on n'a pas de photo libre de l'endroit. il faudra aller voir
sur le terrain, c'est en ce sens que Vespucci est adapté.
surtout qu'il permet de se connecter sur osmose, donc avoir
tout, tout en restant dans un seul outil.
il manque juste l'équivalent ios de Vespucci (dans le sens
un éditeur osm connectable sur osmose, afin de valider
la position sur le terrain)

Cordialement,
Marc


Le 30.05.20 à 14:30, Antonin Delpeuch (lists) a écrit :
> L'outil peut être utile pour intégrer toutes sortes de jeux de données:
> il n'est évidemment pas conçu spécifiquement pour les PEI comme tu l'as
> remarqué.
> 
> Dans le cas spécique des PEI, c'est utile pour un contributeur qui
> souhaite ajouter des métadonnées à des PEIs repérés sur le terrain,
> qu'ils aient déjà des nœuds correspondant dans OSM ou pas.
> 
> L'absence de dépendance à un éditeur externe est un gros plus pour moi,
> car le passage répété entre les deux a un coût vraiment non-négligeable.
> 
> Je pense que c'est bien de respecter la diversité des approches et des
> outils, évitons de nous tirer dans les pattes…
> 
> Antonin
> 
> On 30/05/2020 11:21, Marc M. wrote:
>> Bonjour,
>>
>> je prend mon clavier pour reposer la question tant évitée :
>> la position est suposée mauvaise au point de ne pas vouloir d'import.
>> et l'imagerie sat ne permet pas de voir la borne,
>> du coup que fait le contributeur avec sa souris ?
>>
>> le positionement de ton outil m'échappe.
>>
>> Cordialement,
>> Marc qui penche pour osmose+pic4review+vespucci
>>
>> Le 30.05.20 à 11:51, Nicolas Bétheuil a écrit :
>>> Et bah voilà 12000 points de chargé
>>>
>>> amis contributeur, à vos souris
>>>
>>>
>>>
>>> Le ven. 29 mai 2020 à 22:21, Antonin Delpeuch (lists)
>>> mailto:li...@antonin.delpeuch.eu>> a écrit :
>>>
>>> Salut Nicolas,
>>>
>>> Voilà la version complète:
>>>
>>> http://pintoch.ulminfo.fr/pei_sdis71.osm.geojson
>>>
>>> Antonin
>>>
>>> On 29/05/2020 17:07, Nicolas Bétheuil wrote:
 Les évolutions / correctifs avancent. Je pousse régulièrement.
 Écrivez moi directement, je verrais si je fais une diffusion
 spécifique pour vous gardez informé des nouveautés.

 Christian a ajouté od2osm au proxy IGN ! Merci !

 @Jean-Yvon j'ai des mails qui reviennent, les machinent veulent
 plus qu'on cause ensemble, je te propose de continuer en issue github
 @Antonin Le jeu de données que tu m'avais envoyé avait moins de 90
 points, loin des 12 000 points que tu avais évoqué.

 Le mer. 27 mai 2020 à 12:02, Yves P. >>> > a écrit :

> Les "name" ont été enlevés du jeu de données et l 'outil
> affiche maintenant soit name soit ref (en fonction de ce qui
> existe)
> J'ai ajouté le fond de carte BD Ortho
 Merci :)

>  (j'ai laissé un mot sur le forum pour autorisé od2osm sur le
> proxy
> 
> https://forum.openstreetmap.fr/viewtopic.php?f=5=4715=19681#p19681)
 ici ça marche aussi ;)

 Pour info, MyOSMatic (maposmatic) sort des carte
  des PEIs :
 le résultat est plutôt bien :)
 Il faut revoir la taille des réserves incendie et des DAE, et
 éventuellement l'adapter avec les symboles utilisés en France.

 __
 Yves
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org

[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. 
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à ?
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

Re: [OSM-talk-fr] Comment tagguer une passerelle piétonne/cyclable surplombant la mer ?

2020-05-31 Par sujet Éric Gillet 

Le 31/05/2020 à 07:55, Francescu GAROBY a écrit :
Sa particularité : elle est construite en partie sur les rochers au 
pied des remparts de la Citadelle, et en partie en "suspension" 
au-dessus de la mer (cf. photo 12 du lien ci-dessus). Il y aussi un 
passage creusé dans la roche, mais ça c'est facile à tagguer.
Ma question est donc : faut-il un tag supplémentaire spécifique, pour 
indiquer cette sorte de passerelle suspendue ?


Je cartographie pas souvent des ponts, mais en me basant sur le wiki 
pour cette image 
 
je ferais pour la voie:


highway=footway
bridge=yes

Et le contour de la structure avec :

man_made=bridge
bridge=viaduct
bridge:support=abutment
bridge:structure=beam

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

[OSM-talk-fr] OSM Relation Analyzer — Re: Micro formation maintenance de véloroutes avec JOSM

2020-05-31 Par sujet Yves P. 
> J'avais affichée cette relation dans Waymarked Trails: À vélo 
>  
> et dans OSM Relation Analyzer 
> .
> La mise à jour a été très rapide dans Waymarked Trails, par contre 32 mn 
> après, toujours rien dans RA.

Une modification faite il y a 7 heures n'apparait toujours pas. La dernière 
modification  
remonte à 7 jours !
Il semble qu'il y a un gros retard de mise à jour de la base de données de RA.

Est-ce qu'il est possible de faire tourner une instance sur un serveur d'OSM 
France ayant déjà la base postgresql à jour ?
Cette application à besoin de la table suivante : 
https://github.com/grundid/relation-analyzer/blob/master/src/main/schema/test-data.sql

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