[OSM-talk-fr] Obstacle central sur route 2 x 1 voie ?

Lun 16 Nov 19:20:40 UTC 2015

Le 16 novembre 2015 18:44, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

>
>
> Le 16 novembre 2015 18:08, JB <jbosm at mailoo.org> a écrit :
>
>> J'avoue tout de suite que je n'ai pas tout lu de fond en comble, mais
>> j'espère avoir compris le message principal : malheur, il manque des
>> turn_restriction sur tous les rond-point (entres-autres) (d'ailleurs
>> attention, Philippe, tu es concurrencé sur tes anciennes terres. Oui, je
>> sors).
>> Donc en gros, avec des 62 000 et quelques rond-point en France, avec une
>> moyenne de 3 grosses entrées-sorties par rond-point, quelques 180 000
>> restrictions à ajouter aux 12 000 existant en France en ce moment. Pas
>> forcément très cohérent.
>>
> Je sais ça fait beaucoup mais si c'était fait à chaque fois ça ne poserait
pas autant de problème

> Quand tu parles de semi-automatisation, c'est exactement la solution :
>> l'automatisation chez les consommateurs de données. Mais pas forcément dans
>> la base. Pour rappel, les relations, c'est le merdier, ça reste le merdier
>> : à créer, à entretenir, à gérer.
>>
> Ok c'est vrai mais si tous les tronçons était coupé à chaque intersection
ça ne serait pas tant le merdier car il n'y aurai que peux de modification
et de mise à jour au final et on ne serait aussi pas obligé de recouper à
chaque relations de route de vélo ou de bus. Bref une gestion par tronçon
de voie et pas juste par chemins.

> Et c'est parfait pour effrayer les nouveaux contributeurs.
>>
> Ca peut être fait automatiquement avec un plugin de génération de rond
point automatique avec le nombre de branches le type de séparateur à
l'entrée du rond point (avec ou sans)

> Restez simples. Moins on passe de temps à gérer du bordel, plus on en a
>> pour des choses utiles.
>>
> En effet mais là on parle plus d'un problème d'interface et on se limite
en terme de production de données car la gestion des relations et trop
compliqué...  Ca peut être générer encore une fois en semi-auto avec une
proposition à valider tous simplements pour que branche du rond-point ayant
été éditer (système de validation JOSM ou autre...)

Franchement, ceux qui s'amusent à utiliser OSRM en indiquant comme
> destination des points où l'arrêt est interdit (jonctions à sens unique et
> une seule voie proche des ronds-points) sont hors des réalités. Mais OSRM
> peut aussi être corrigé en évitant simplement les virages en épingle à
> cheveux
>
L'angle c'est trop problématique et ça dépend trop de la méthodes
d'éditions. Hors on n'est pas une équipes de 20 personnes à saisir mais
vraiment beaucoup plus avec autant de biais sur la méthode d'édition. Il y
a qu'à voir le schéma d'adresses...

>
>
impossibles à réaliser car ici on a plusieurs conditions qui interdisent ce
> trajet, juste à cause du code de la route (et même en absence de ligne
> continue ou de zebra à la sortie (bien qu'il y a des cas avec une petite
> coupure de la ligne continue qui autorise le franchissement uniquement pour
> accéder à un chemin d'accès privé situé le long de la rue et c'est une
> autorisation de franchissement uniquement pour tourner à gauche vers ce
> chemin privé, pas pour faire demi-tour vers le rond-point.
>
En effet, le manque de marquage peut poser des problème mais ça c'est plus
la base qui le gère mais le conducteur lui-même. le coté tourner à gauche
vers un chemin privé est un niveau plus fin encore si on coupe le tronçon
on pourra tourner mais pas faire demi-tour  ce qui reviendrait à faire
demi-tour en plein milieu de la voie.

>
> La maneuvre d'ailleurs serait difficile et dangereuse à réaliser sans
> faire au milieu une marche arrière en contre-braquage et il est nettemenet
> plus facile et plus rapide de faire demi-tour au carrefour suivant (les
> ronds-points dont les rues connectées sont en double sens avec un petit Y
> sont rarement en rase campagne, il y a un carrefour facile et rapide juste
> après qui est certainement un bien meilleur routage pour ceux qui se
> seraient trompés de sortie d'un rond-point).
>
> Bref, pas la peine de surcharger, OSRM peut proposer mieux et plus
> pratique (et aucun GPS ne pourra même aller assez vite pour proposer un tel
> chemin quand on quitte un rond-point,
>
Le problème présenté n'est  pas sur le recalcul mais le calcul lui-même

il a déjà besoin d'un peu de temps et de distance pour voir qu'on est
> effectivement sur la bonne sortie. Le temps qu'on réagisse il dira "faites
> demi-tour dès que possible", mais il continue à vous indiquer le chemin
> tout droit au moins jusqu'au carrefour suivant ou plusieurs centaines de
> mètres devant.... mais pas OSRM.
>
En effet tous les carrefour permettent de faire demi-tour sauf contre
indication  donc il y a encore des relation de type restriction...

>
> Là on est à une échelle bien plus petite sur des parcours d'une poignée de
> secondes et des distances bien plus faibles. Il n'y a aucun lieu de faire
> un tel trajet.
>
Ca je suis d'accord mais même plus long en passant par le même rond-point
sans changer les condition on aura le même résultat au calcul.

>
> Bref c'est OSRM (le consommateur de données) qui devrait être corrigé pour
> éviter de tels chemins aberrants, irréalistes, dangereux, et franchement
> pas pratiques.
>
En parti mais on ne peut pas tous faire avec le soft si les données sont de
fait pas terrible. L'API c'est pas de la magie. ;-)

>
> Il suffirant déjà qu'autour d'un rond-point il y ait un buffer d'environ
> 50 mètres dans lequel les virages en épingle à cheveux sur les Y en sens
> uniques sont interdits (de même que les arrêts, afin d'éliminer même la
> possibilité d'en faire une réelle destination. Pas besoin de relation
> alors: même si le résultat obtenu est aberrant c'est en fait la demande
> d'itinéraire qui dès le départ était aberrante.
>
Donc tu génères questions automatiquement  au travers du buffer une
surcouche de restriction (relation) spécifique à chaque soft...
Je reprends ma base de routing (Bon ok c'est du Nav****t) Il y a bien des
relations pour les rond-points avec des embranchements en sens unique. A
savoir que les relations sur un rond-point n'ont pas de raisons de changer
du jour au lendemain. C'est encore moins volatile que les contours des
communes ou que les voies de BUS. Certes ça fait des données mais bon on
travail sur une base de données que je sache.

>
> En revanche pour les Y beaucoup plus longs le long desquels il y a des
> résidences, on peut se retrouver avec des destinations possibles, mais là
> le moteur de routage devrait proposer des chemins utilisant des demi-tours
> par de réels carrefours (ces noeuds au centre des Y ne sont pas des
> carrefours :
>

En effet mais dans ce cas ça revient à taguer tout les carrefours.

> Le routage en situation normale n'utilise aucun demi-tour ni marche
> arrière: on continue plus loin jusqu'à un carrefour ou une entrée de garage
> ou un portail privé devant lequel on pourra maneuvrer (même si on ne peut
> pas s'y arrêter, au moins il y a un espace de sécurité et on ne bloque pas
> la rue).
>

A bon... Peut-être pour OSMR mais en situation de collecte des déchets, on
a une surcouche pour gérer les marches arrières sinon on ne passe pas avec
un 19T dans certaines voies (ça sur 200m à Nîmes) et une pour indiquer les
zones de demi-tour possible. Un highway=turning_circle est typiquement une
zone de manœuvre ou de demi-tour situé en fin d'impasse ou non.
De fait toutes intersections permettent de faire demi-tour s'il n'y a pas
de danger d'ou le "faites demi-tour dès que possible" et le recalcule te
propose de faire demi-tour à un carrefour.

Bonne soirée,
Jérôme
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20151116/304bc4b7/attachment.htm>