Simplification représentation "Cédez-le-passage cycliste au feu"

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Simplification représentation "Cédez-le-passage cycliste au feu"

Axelos
Bonjour,

Depuis plusieurs années je représente les cédez-le-passage créé via des
panonceaux sur les feux de circulation, destinées exclusivement aux
vélos, en créant des relations comme indiqué sur la page wiki dédié.
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu

J'ai toujours trouvé cette façon de faire relativement lourde, mais les
contributions étant effectuées ponctuellement, je ne me suis jamais
vraiment posé la question de trouver des alternatives.

Localement, la métropole dans laquelle je contribue principalement a
fait poser ce type de panneau en masse sur le territoire (des
centaines), juste avant le premier tour des élections municipale.
Aujourd’hui, l'idée est de les insérer progressivement dans la base,
mais j'aimerais éventuellement utiliser une variante plus simple pour
certains cas qui peuvent se passer de relation.

Imaginez, parfois vous avez des feux qui ne font que réguler un passage
piétons, d'autres fois les possibilités au carrefour d’emprunter des
directions sont déjà intégralement recouvert par les directions
affichées sur les panonceaux.

Cet exemple qui représente un aller tout droit, qui est de toutes façons
la seule direction possible pour les cyclistes :
https://www.mapillary.com/map/im/eAaLPasL2dPva8sKAwjP8w

Une proposition du type :

highway=traffic_signals
traffic_signals:direction=forward
highway:bicycle=give_way

Qu'en pensez-vous ?

--

"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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Bibi
En deux mots : simple mais pas pris en compte par les outils. Devrait
donc passer par une proposition officielle notant cela.

Sauf que si tu mets ça sur un point, comment savoir de quelle route tu
parles si la voie piétonne est autorisée aux cycles.

De plus les cyclistes ne doivent la priorité que si le feu est rouge ou
orange.

Mais ce problème est le même qu'avec la relation.

Je doute que le cas des feux sur appel piéton soit la majorité des cas.
Sinon il faudra distinguer left/right/forward.

Jean-Yvon

Le 27/09/2020 à 19:02, Axel Listes - [hidden email] a écrit :
> Une proposition du type :
>
> highway=traffic_signals
> traffic_signals:direction=forward
> highway:bicycle=give_way
>
> Qu'en pensez-vous ?


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

France mailing list
In reply to this post by Axelos
À Grenoble, on a les panneaux vélo-super-power :

https://www.mapillary.com/map/im/qAFGJjDNEmcMO5BL-gBfIg

Au feu rouge, les vélos peuvent aller partout en cédant le passage.

Donc, dans le schéma d'origine que je découvre, il faudrait trois relations.

Eric

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Bibi
 > Donc, dans le schéma d'origine que je découvre, il faudrait trois
relations.

Oui. Les écologistes foutent le bordel^^

Mais les éditeurs facilitent la création de telles relations.

Jean-Yvon



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Éric Gillet-3
Le 28/09/2020 à 09:15, [hidden email] a écrit :
> > Donc, dans le schéma d'origine que je découvre, il faudrait trois
> relations.
>
> Mais les éditeurs facilitent la création de telles relations.

Exactement ça me semble être une question d'éditeurs plus qu'une
question de tags/objets OSM.


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Axelos
In reply to this post by Bibi
Bonjour,

Le 27/09/2020 à 22:35, [hidden email] a écrit :
> Sauf que si tu mets ça sur un point, comment savoir de quelle route tu
> parles si la voie piétonne est autorisée aux cycles.

Dans le cas d’existence d'une rue ou place piétonne autorisées aux
cyclistes (à l'allure du pas donc), alors la solution est la même que
pour tous carrefours ou le vélo ne peut pas céder-le-passage vers toutes
les directions disponibles : on utilise le système de relations.

L'idée n'est pas de remplacer les relations, mais d’éviter de les
utiliser pour des cas simples.

> En deux mots : simple mais pas pris en compte par les outils. Devrait
> donc passer par une proposition officielle notant cela.

À ma connaissance les relations non plus ne sont pas prises en compte.
C'est justement le bon moment pur tout remettre à plat ...

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Axelos
In reply to this post by Éric Gillet-3
Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :
>> > Donc, dans le schéma d'origine que je découvre, il faudrait trois
>> relations.
>>
>> Mais les éditeurs facilitent la création de telles relations.
>
> Exactement ça me semble être une question d'éditeurs plus qu'une
> question de tags/objets OSM.

Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.
- La maintenance, comme toutes relations, celles-ci sont susceptibles
d’être cassées lorsque qu'un contributeur débutant ou non vigilant
intervient sur l'un des éléments intégrés dans la relation. Les systèmes
de suivi d’éditions ont plus de difficultés à donner des informations
concernant des éditions de relations que de points (Achavi, OSMcha ...)
- La complexité de l'usage des relations, honnêtement pourquoi
obligatoirement passer par un système hyper complexe alors que l'on peut
juste ajouter une balise sur un point pour arriver au même résultat ?
L'exemple d'Éric est intéressant, car il permet de se poser cette
question : Une balise sur un point déjà existant ou trois relations ?

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Éric Gillet-3
Le 28/09/2020 à 11:02, Axel Listes a écrit :
Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :
Donc, dans le schéma d'origine que je découvre, il faudrait trois
relations.

Mais les éditeurs facilitent la création de telles relations.
Exactement ça me semble être une question d'éditeurs plus qu'une
question de tags/objets OSM.
Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.

Dans la plupart des cas l'intersection sera composée de 2 voies de la manière suivante : -|-, donc ça fait 2 coupures au maximum. J'ai l'impression que les intersections plus complexes avec + de voies (donc plus dangereuses) n'ont pas de cédez-le-passage tout-droit ou à gauche.

- La maintenance, comme toutes relations, celles-ci sont susceptibles
d’être cassées lorsque qu'un contributeur débutant ou non vigilant
intervient sur l'un des éléments intégrés dans la relation.

Oui en effet, mais ça malheureusement il n'y a pas de solution. Même avec une myriade d'avertissement des contributeurs arrivent régulièrement à fusionner des nœuds de routes 1km plus loin sur iD. Pourtant ce sont des opérations simple (fusion de nœuds) sur des "données simples" (nœuds, pas de relation), donc je ne suis pas sûr que ce soit un problème de complexité du modèle de données.

Si l'éditeur a une vue dédiée aux cédez-le-passage, il serait sûrement  facile de mettre cette vue lors d'erreurs de validation pour faire corriger le contributeur.

Les systèmes
de suivi d’éditions ont plus de difficultés à donner des informations
concernant des éditions de relations que de points (Achavi, OSMcha ...)
Oui en effet. Je pense que c'est l’œuf et la poule, il y a beaucoup plus de modifications (et donc d'erreurs à surveiller) sur les nœuds et voies, donc plus d'attention est portée à leur rendu.
- La complexité de l'usage des relations, honnêtement pourquoi
obligatoirement passer par un système hyper complexe alors que l'on peut
juste ajouter une balise sur un point pour arriver au même résultat ?
L'exemple d'Éric est intéressant, car il permet de se poser cette
question : Une balise sur un point déjà existant ou trois relations ?

C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire "hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est forcément cartographiable facilement. Par exemple on pourrait dire qu'il serait plus simple de cartographier les arbres de la manière suivante :

natural=tree
espece=platane

Au lieu de :

natural=tree
genus=Platanus
species=Platanus × hispanica
deciduous=leaf_cycle
leaf_type=broadleaved

Mais ça me semble pas pertinent pour une base de données.

Pour revenir sur les panneaux, il faut se demander ce que l'on veut cartographier : le panneau (ce que tu suggères si j'ai bien compris) ou son effet.

Panneau :

  • Plus simple à cartographier
  • Ne représente que le panneau, et nécessite donc une interprétation pour savoir quelle voie sont concernées. Cette interprétation est potentiellement différente par pays/état.

Relations:

  • Plus complexe à cartographier
  • Pas d'ambiguïté pour les utilisateurs

Certains pourraient suggérer une approche hybride (panneau quand pas d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire implémenter logiciellement (et faire comprendre aux contributeurs) les deux manières de cartographier, ce qui me semble empirer le problème.


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Vincent de Château-Thierry-2
Bonjour,

> De: "Éric Gillet" <[hidden email]>

> C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire
> "hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est
> forcément cartographiable facilement.

Pour moi c'est le coeur du sujet ici.

On passe notre temps à modéliser le terrain pour le faire entrer dans une base de données, avec la conviction que ce qu'on fait peut servir à d'autres, et sans préjuger des usages. Dans le cas d'un cédez-le-passage cycliste, on peut se demander à quoi donc cela peut servir. Un domaine d'usage reconnu est l'aide à la mobilité, quand on veut exploiter la base OSM pour proposer un trajet, un itinéraire, voire un guidage en temps réel. Et dans ces contextes, où un algorithme va devoir interpréter les données qu'on a saisies, il faut autant que possible supprimer les ambiguïtés, afin que le robot fonctionne au mieux.

Pour le guidage, mentionner une manoeuvre implique à la fois de savoir d'où on vient et où on va. Ca permet de donner des instructions comme "tournez à droite", etc. C'est là que les relations OSM sont utiles, car elles décrivent un parcours, depuis un axe (role from) vers un autre axe (role to) en passant par un certain point (role via). Ces 3 infos sont précieuses, et on n'a pas d'autre formalisme que les relations pour les renseigner. C'est plus lourd qu'un simple point, mais beaucoup moins ambigu, donc plus utile. On augmente la valeur des données en allant à ce niveau de détail, clairement.

> Certains pourraient suggérer une approche hybride (panneau quand pas
> d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire
> implémenter logiciellement (et faire comprendre aux contributeurs)
> les deux manières de cartographier, ce qui me semble empirer le
> problème.

D'accord avec ça. Les modélisations multiples sont parfois un mal nécessaire dans OSM (exemple typique : les relations associatedStreet vs les simples nodes addr:housenumber & addr:street) mais quand on part d'une situation assez uniforme comme dans le cas des cédez-le-passage cycliste, je trouverais dommage qu'on évolue vers une modélisation multiple, hétérogène et plus complexe à consommer.

vincent

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

lejun
Bonjour,

Le 28/09/2020 à 14:03, Vincent de Château-Thierry a écrit :
> Dans le cas d'un cédez-le-passage cycliste, on peut se demander à quoi donc cela peut servir

Je suis également perplexe sur la nécessité, non pas d'indiquer où se
trouvent les M12 (référence du panneau à apposer là où se trouve le feu
tricolore), mais d'accompagner le mouvement du cycliste.

OSM est une base de données visant à représenter l'environnement sur la
base de l'existence physique et la vérifiabilité, en ce sens, indiquer
où se trouve le panneau est justifié. À l'inverse, je ne pense pas utile
de cartographier explicitement la fonction du panneau par des méthodes
souvent complexes. Ce raisonnement poussé à l'extrême nous inviterait
également à créer des relations pour les feux tricolores en apposant une
condition "Ne pas passer quand le feu est rouge".

En terme d'utilisation, je connais peu d'algorithmes allant jusqu'à
prendre en compte les feux de signalisation lors de la création de
l'itinéraire et je ne pense pas que ces derniers représentent une part
importante des temps de trajets.
--
Lejun - Groupe Régional OpenStreetMap Bourgogne-Franche-Comté

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Vincent de Château-Thierry-2
Bonjour,

> De: "lejun" <[hidden email]>
>
> Je suis également perplexe sur la nécessité, non pas d'indiquer où se
> trouvent les M12 (référence du panneau à apposer là où se trouve le
> feu tricolore), mais d'accompagner le mouvement du cycliste.

Sur cette thématique comme sur toutes les autres, comme toujours dans OSM, il n'y a aucune obligation, chacun contribue sur ses centres d'intérêt.
 
> OSM est une base de données visant à représenter l'environnement sur
> la base de l'existence physique et la vérifiabilité, en ce sens,
> indiquer où se trouve le panneau est justifié. À l'inverse, je ne pense pas
> utile de cartographier explicitement la fonction du panneau par des
> méthodes souvent complexes. Ce raisonnement poussé à l'extrême nous inviterait
> également à créer des relations pour les feux tricolores en apposant
> une condition "Ne pas passer quand le feu est rouge".

En poussant ce raisonnement, on tagguerait les panneaux "sens interdit" avec un point, à leur emplacement, mais on ne renseignerait pas la fonction avec le tag oneway=* sur les ways. Ca correspondrait bien à l'existence physique, mais malheureusement ça ne permettrait pas dans un logiciel de guidage d'empêcher d'emprunter un sens interdit, car c'est sur le way, et non grâce au node "panneau", que les logiciel de routage prennent l'information pour autoriser ou interdire un parcours. C'est identique dans le cas des cedez-le-passage cycliste. La manière conventionnelle de modéliser une manoeuvre, ou plus souvent une interdiction de manoeure [1] est de constituer un parcours au moyen d'une relation. C'est en effet plus complexe qu'un simple tag sur un unique objet, mais le but recherché est le même : rendre plus intelligent un moteur de calcul d'itinéraire, en lui donnant le maximum d'infos sur le graphe qu'il explore.
 
> En terme d'utilisation, je connais peu d'algorithmes allant jusqu'à
> prendre en compte les feux de signalisation lors de la création de
> l'itinéraire et je ne pense pas que ces derniers représentent une
> part importante des temps de trajets.

Je pense qu'un principe important dans OSM est d'accepter de ne pas savoir à l'avance qui se servira de quoi dans la base. On n'a pas (et tant mieux !) toute la connaissance de comment les données qu'on renseigne sont exploitées ici et là. Concernant le fonctionnement des moteurs de calcul d'itinéraire, j'en parle sans savoir qui utilise explicitement les relation Cedez-le-passage, mais en connaissance du fonctionnement des moteurs de calcul car je bosse dans ce domaine.

vincent

[1] https://wiki.openstreetmap.org/wiki/FR:Relation:restriction

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Eric Sibert
In reply to this post by lejun
> En terme d'utilisation, je connais peu d'algorithmes allant jusqu'à
> prendre en compte les feux de signalisation lors de la création de
> l'itinéraire et je ne pense pas que ces derniers représentent une part
> importante des temps de trajets.

OSMAnd prend en compte les feux dans ses calculs d'itinéraire. Il m'a
proposé des itinéraires voiture dans mon quartier passant par des
petites rues peu roulantes mais évitant les feux et ils sont
effectivement plus rapides.

Après, on se retrouve avec la question générale des panneaux (ou feux,
radars) et de leur portée. On avait déjà eu une discussion à propos de
la description des panneaux d'entrée/sortie d'agglomération et leurs
supports. Je pense qu'à terme il faudra inclure les deux dans OSM.
- d'un côté la description physique du panneau (ou groupe de panneau)
avec un point spécifique, support, l'orientation du/des panneau(x), la
description réglementaire, le texte si ça a du sens (pour les
entrées/sorties d'agglomération)...
- d'autre part, l'effet sur le way de la chaussée, là où change la
limite de vitesse, où il est interdit de faire demi-tour, là où les
vélos ont le droit de passer/tourner même au feu rouge...

Et peut-être aussi une relation reliant les deux aspects. Dans le cas du
tourne-droit des vélos, on a déjà la relation, il faudrait lui rajouter
un rôle genre traffic-sign vers le panneau physique.

Mes 0,02 €

Eric



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Eric Sibert
In reply to this post by France mailing list
Le 2020-09-28 00:07, Eric SIBERT via Talk-fr a écrit :
> À Grenoble, on a les panneaux vélo-super-power :
>
> https://www.mapillary.com/map/im/qAFGJjDNEmcMO5BL-gBfIg
>
> Au feu rouge, les vélos peuvent aller partout en cédant le passage.
>
> Donc, dans le schéma d'origine que je découvre, il faudrait trois
> relations.

Ou une seule relation avec trois rôles "to"?

Eric


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Ralf Treinen
In reply to this post by Axelos
Bonsoir,

On Mon, Sep 28, 2020 at 11:02:18AM +0200, Axel Listes wrote:

> Bonjour,
>
> Le 28/09/2020 à 09:40, Éric Gillet a écrit :
> >> > Donc, dans le schéma d'origine que je découvre, il faudrait trois
> >> relations.
> >>
> >> Mais les éditeurs facilitent la création de telles relations.
> >
> > Exactement ça me semble être une question d'éditeurs plus qu'une
> > question de tags/objets OSM.
>
> Alors voici globalement les « défauts » qui en découlent :
> - Les multiples césures des chemins, il faut les couper à l'emplacement
> du point « via » de la relation.

c'est écrit ou qu'il faut découper les chemins ? Sur la page wiki (anglaise)

https://wiki.openstreetmap.org/wiki/Relation:restriction

je ne trouve pas que le point "via" doit être un point terminal des deux
chemins "from" et "to".

-Ralf.

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Éric Gillet-3
Le 29/09/2020 à 21:26, Ralf Treinen a écrit :

> Bonsoir,
>
> On Mon, Sep 28, 2020 at 11:02:18AM +0200, Axel Listes wrote:
>> Bonjour,
>>
>> Le 28/09/2020 à 09:40, Éric Gillet a écrit :
>>>>> Donc, dans le schéma d'origine que je découvre, il faudrait trois
>>>> relations.
>>>>
>>>> Mais les éditeurs facilitent la création de telles relations.
>>> Exactement ça me semble être une question d'éditeurs plus qu'une
>>> question de tags/objets OSM.
>> Alors voici globalement les « défauts » qui en découlent :
>> - Les multiples césures des chemins, il faut les couper à l'emplacement
>> du point « via » de la relation.
> c'est écrit ou qu'il faut découper les chemins ? Sur la page wiki (anglaise)
>
> https://wiki.openstreetmap.org/wiki/Relation:restriction
>
> je ne trouve pas que le point "via" doit être un point terminal des deux
> chemins "from" et "to".

C'est un peu caché, mais bien présent dans la page :

https://wiki.openstreetmap.org/wiki/Relation:restriction#cite_note-waysplit-2


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Axelos
Bonjour,

Le 29/09/2020 à 23:31, Éric Gillet a écrit :

> Le 29/09/2020 à 21:26, Ralf Treinen a écrit :
>> Bonsoir,
>>
>> On Mon, Sep 28, 2020 at 11:02:18AM +0200, Axel Listes wrote:
>>> Bonjour,
>>>
>>> Le 28/09/2020 à 09:40, Éric Gillet a écrit :
>>>>>> Donc, dans le schéma d'origine que je découvre, il faudrait trois
>>>>> relations.
>>>>>
>>>>> Mais les éditeurs facilitent la création de telles relations.
>>>> Exactement ça me semble être une question d'éditeurs plus qu'une
>>>> question de tags/objets OSM.
>>> Alors voici globalement les « défauts » qui en découlent :
>>> - Les multiples césures des chemins, il faut les couper à l'emplacement
>>> du point « via » de la relation.
>> c'est écrit ou qu'il faut découper les chemins ? Sur la page wiki
>> (anglaise)
>>
>> https://wiki.openstreetmap.org/wiki/Relation:restriction
>>
>> je ne trouve pas que le point "via" doit être un point terminal des deux
>> chemins "from" et "to".
>
> C'est un peu caché, mais bien présent dans la page :
>
> https://wiki.openstreetmap.org/wiki/Relation:restriction#cite_note-waysplit-2


De toutes façons, à moins qu'il me manque un élément, si on ne découpe
pas les chemins dans un carrefour classique, il est impossible de
déterminer d’où vient le cycliste, et ou il va.

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Bibi
Le 30/09/2020 à 19:35, Axel Listes - [hidden email] a écrit :

> De toutes façons, à moins qu'il me manque un élément, si on ne découpe
> pas les chemins dans un carrefour classique, il est impossible de
> déterminer d’où vient le cycliste, et ou il va.
>
> Axel.

Exact dans le formalisme actuel.

Si tu disais

from:forward (on vient de cette rue dans le sens OSM)

from:backward (on vient de cette rue dans le sens opposé)

et

to:forward (on va dans cette rue dans le sens OSM)

to:backward (on va dans cette rue dans le sens opposé)

tu pourrais t'en sortir d'un point de vue humain.

Par contre pour créer le graphe, il faudrait couper les chemins en segments.

Donc est-ce que ça vaut le coup ?

Question ouverte.

Effet de bord : on arrive à créer des miettes de rues qui justifient
chaque jour un peu plus les associatedStreet.

Jean-Yvon




_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Florimond Berthoux
In reply to this post by Axelos
Bonjour,

Effectivement créer des relations pour de si petits objets c'est un peu la croix et la bannière.
Je suis favorable à un mapping par point (sans relation), parce que :
- c'est la réalité physique (on tag le panneau, pas son interprétation légal variable suivant les pays)
- plus simple à mapper, pour qu'une donnée soit utile il faut déjà qu'elle existe
- plus simple à rendre sur une carte
- la prise en compte par un algo de routage ne me semble pas super compliqué (mais j'y connais pas grand chose)

donc quelque chose qui dit "cédez le passage cycliste" + "direction du mouvement" :
highway:bicycle=give_way_right|left|forward|all

Le dim. 27 sept. 2020 à 19:03, Axel Listes <[hidden email]> a écrit :
Bonjour,

Depuis plusieurs années je représente les cédez-le-passage créé via des
panonceaux sur les feux de circulation, destinées exclusivement aux
vélos, en créant des relations comme indiqué sur la page wiki dédié.
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu

J'ai toujours trouvé cette façon de faire relativement lourde, mais les
contributions étant effectuées ponctuellement, je ne me suis jamais
vraiment posé la question de trouver des alternatives.

Localement, la métropole dans laquelle je contribue principalement a
fait poser ce type de panneau en masse sur le territoire (des
centaines), juste avant le premier tour des élections municipale.
Aujourd’hui, l'idée est de les insérer progressivement dans la base,
mais j'aimerais éventuellement utiliser une variante plus simple pour
certains cas qui peuvent se passer de relation.

Imaginez, parfois vous avez des feux qui ne font que réguler un passage
piétons, d'autres fois les possibilités au carrefour d’emprunter des
directions sont déjà intégralement recouvert par les directions
affichées sur les panonceaux.

Cet exemple qui représente un aller tout droit, qui est de toutes façons
la seule direction possible pour les cyclistes :
https://www.mapillary.com/map/im/eAaLPasL2dPva8sKAwjP8w

Une proposition du type :

highway=traffic_signals
traffic_signals:direction=forward
highway:bicycle=give_way

Qu'en pensez-vous ?

--

"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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


--
Florimond Berthoux

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

cquest
Le 07/10/2020 à 23:06, Florimond Berthoux a écrit :

> Bonjour,
>
> Effectivement créer des relations pour de si petits objets c'est un
> peu la croix et la bannière.
> Je suis favorable à un mapping par point (sans relation), parce que :
> - c'est la réalité physique (on tag le panneau, pas son interprétation
> légal variable suivant les pays)
> - plus simple à mapper, pour qu'une donnée soit utile il faut déjà
> qu'elle existe
> - plus simple à rendre sur une carte
> - la prise en compte par un algo de routage ne me semble pas super
> compliqué (mais j'y connais pas grand chose)
>
> donc quelque chose qui dit "cédez le passage cycliste" + "direction du
> mouvement" :
> highway:bicycle=give_way_right|left|forward|all
>

Pas vraiment d'accord avec le premier point, les maxspeed=* sont ajoutés
sur le filaire de la voirie, pas uniquement par un noeud qui indique où
se trouve un panneau.

C'est sur le dernier point que ça coince très fort :(

Imaginons que l'on ait des tags supplémentaires sur les noeuds où se
trouve les highway=traffic_signals, pour indiquer ce que le panonceau
permet (vu qu'il est lié à la présence d'un feu, ce serait assez logique).

Pour qu'un algo de routage sache à quelle(s) voie(s) de destination cela
se rapporte, il va falloir faire des calculs géométriques, ce qu'en
général les outils de conversion de données géographiques (OSM ou autre)
en graphe de calcul d'itinéraire ne font pas car cela ne leur est pas
nécessaire.

C'est donc tout une nouvelle préparation qui données qui serait
nécessaire, car ce qui est implicite par la géo a besoin d'être
explicité pour le graphe. En attendant (et pour longtemps), les
relations restent nécessaires pour expliciter le routage possible.


La modélisation pourrait par contre évoluer:

1- pour réduire le nombre de relations: le "to" de la relation pourrait
être multiple, c'est à dire indiquer les différentes voies de
destination pour lesquelles le panneau s'applique (ce qui est déjà prévu
par les relations type=restriction dans le wiki anglais, comme le "from"
d'ailleurs et même les "via" qui peuvent être des way)

2- des noeuds highway=traffic_signal pour chaque voie arrivant à
l'intersection pour y expliciter le modèle de panneau:
bicycle:giveway=right/left/through/all associé à ce feu


--
Christian Quest - OpenStreetMap France


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
Reply | Threaded
Open this post in threaded view
|

Re: Simplification représentation "Cédez-le-passage cycliste au feu"

Florimond Berthoux
In reply to this post by Florimond Berthoux

En fait le tag serait plus simplement un traffic_sign https://wiki.openstreetmap.org/wiki/Key:traffic_sign
traffic_sign=bicycle_give_way_right|left|forward|all

Ainsi ceux qui veulent faire le recensement des panneaux peuvent utiliser ce  traffic_sign,
et ceux qui souhaitent interpréter les panneaux pour les routeurs peuvent ajouter des relations.


Le mer. 7 oct. 2020 à 23:06, Florimond Berthoux <[hidden email]> a écrit :
Bonjour,

Effectivement créer des relations pour de si petits objets c'est un peu la croix et la bannière.
Je suis favorable à un mapping par point (sans relation), parce que :
- c'est la réalité physique (on tag le panneau, pas son interprétation légal variable suivant les pays)
- plus simple à mapper, pour qu'une donnée soit utile il faut déjà qu'elle existe
- plus simple à rendre sur une carte
- la prise en compte par un algo de routage ne me semble pas super compliqué (mais j'y connais pas grand chose)

donc quelque chose qui dit "cédez le passage cycliste" + "direction du mouvement" :
highway:bicycle=give_way_right|left|forward|all

Le dim. 27 sept. 2020 à 19:03, Axel Listes <[hidden email]> a écrit :
Bonjour,

Depuis plusieurs années je représente les cédez-le-passage créé via des
panonceaux sur les feux de circulation, destinées exclusivement aux
vélos, en créant des relations comme indiqué sur la page wiki dédié.
https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu

J'ai toujours trouvé cette façon de faire relativement lourde, mais les
contributions étant effectuées ponctuellement, je ne me suis jamais
vraiment posé la question de trouver des alternatives.

Localement, la métropole dans laquelle je contribue principalement a
fait poser ce type de panneau en masse sur le territoire (des
centaines), juste avant le premier tour des élections municipale.
Aujourd’hui, l'idée est de les insérer progressivement dans la base,
mais j'aimerais éventuellement utiliser une variante plus simple pour
certains cas qui peuvent se passer de relation.

Imaginez, parfois vous avez des feux qui ne font que réguler un passage
piétons, d'autres fois les possibilités au carrefour d’emprunter des
directions sont déjà intégralement recouvert par les directions
affichées sur les panonceaux.

Cet exemple qui représente un aller tout droit, qui est de toutes façons
la seule direction possible pour les cyclistes :
https://www.mapillary.com/map/im/eAaLPasL2dPva8sKAwjP8w

Une proposition du type :

highway=traffic_signals
traffic_signals:direction=forward
highway:bicycle=give_way

Qu'en pensez-vous ?

--

"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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


--
Florimond Berthoux


--
Florimond Berthoux

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr