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.
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. Et c'est parfait pour effrayer
les nouveaux contributeurs. Restez simples. Moins on passe de temps à
gérer du bordel, plus on en a pour des choses utiles.
Merci.
JB.
Le 16/11/2015 17:17, Jérôme Seigneuret a écrit :
Un autre problème que je vois
Le 16 novembre 2015 15:28, <david.croc...@free.fr
<mailto:david.croc...@free.fr>> a écrit :
Bonjour
----- Mail original -----
De: "Jérôme Seigneuret" <jseigneuret-...@yahoo.fr
<mailto:jseigneuret-...@yahoo.fr>>
Ca c'est un problème sur l'algo à cause d'une généralisation trop
importante je pense.
----- Mail original -----
KeepRight (via JOSM par exemple) signale les points litigieux en
ce sens :
http://ecra.se/fNWA
ou
http://keepright.ipax.at/report_map.php?lang=fr&ch30=1&ch40=1&ch50=1&ch70=1&ch90=1&ch100=1&ch110=1&ch120=1&ch130=1&ch150=1&ch160=1&ch170=1&ch180=1&ch191=1&ch192=1&ch193=1&ch194=1&ch195=1&ch196=1&ch197=1&ch198=1&ch201=1&ch202=1&ch203=1&ch204=1&ch205=1&ch206=1&ch207=1&ch208=1&ch210=1&ch220=1&ch231=1&ch232=1&ch270=1&ch281=1&ch282=1&ch283=1&ch284=1&ch285=1&ch291=1&ch292=1&ch293=1&ch294=1&ch295=1&ch296=1&ch297=1&ch298=1&ch311=1&ch312=1&ch313=1&ch320=1&ch350=1&ch370=1&ch380=1&ch401=1&ch402=1&ch411=1&ch412=1&ch413=1&number_of_tristate_checkboxes=8&highlight_error_id=0&highlight_schema=0&lat=48.58739&lon=1.68795&zoom=7&show_ign=1&show_tmpign=1&layers=B0T&ch=0%2C401%2C402
En effet, Il propose d'ajouter des restrictions de tourne à gauche. Ce
qui logiquement devrait être fait pour tous les rond-points et les
carrefours avec les voies d'interconnexions (à gauche ou à droite et
obligation d'aller tout droit)
Ce repérage est faisable en analysant les voies en sens unique en
enfilage de deux tronçons qui revienne sur le même tronçon de
rond-point. Je pense que ça ne pend pas tous les cas mais c'est une
explication sur l'analyse
Je pense qu'on réfléchit trop en terme de panneaux. Dans notre cas
l'interdiction de tournée à gauche (et de faire demi-tour) est régit
par la présence d'une ligne blanche (ou jaune) continue. Il faut bien
comprendre qu'il est interdit de franchir une ligne blanche ou un
zébra. Donc de tournée à gauche pour entrée chez soit ou de faire
demi-tour. Exception faite pour la ligne blanche avec des
fractionnements qui permettent de tourner à gauche.
De base sur les autres systèmes de base routière, toutes les zones où
il y a une intersection de voie en sens unique dont une des extrémités
est jointive et l'autre coté retombent sur le même rond-point ont une
restriction de tournée à gauche.
Il serait intéressant de détourner le projet OpenSolarMap pour
proposer une semi-automatisation des interdictions de tourner à
gauche, soit en exploitant les alertes de KeepRight soit en reprenant
l'algo pour sélectionner: le noeud, la voie de départ du rond-point,
la voie de retour sur le rond-point.
Ma remarque sur OSMR n'a pas de rapport car on voie bien qu'il n'a pas
choisi le chemin le plus court mais je pense le plus rapide.
Je m'explique:
- un des embranchement est limité à 90 l'autre n'en a pas
- le rond-point est limité à 50
L'algo ne cherche pas à comprendre et ne gère pas les angles dans les
graphes. Il prend la longueur et la vitesse et il choisi le plus
rapide d'où ton résultat. Si les embranchements sont à 50 il n'y a pas
lieu d'avoir ce résultat.
De plus l'embranchements en entrée de rond-points devrait être
automatiquement dégradé en terme de vitesse. On ne rentre pas à 90
dans un rond-point. Au max pour les plus grand on est à 70 (en moyenne
entre 30 et 60 dans le rond-point et certains se passe à 20. Mais cela
peu se calculer avec l'angle des arcs et le diamètre et un
coefficient de déformation pour les rond-points ovales ou en haricot)
Un panneau d'avertissement incite à réduire la vitesse (de basse on
rentre dans un rond-point en 2e ou 3e. J'ai pas une Porche donc en
3ème je suis entre 30 et 40 km/h en entrée de rond-point)
Cela pourrait aussi être géré avec des tags comme
maxspeed:advisory
maxspeed:recommended
Pour en revenir avec la possibilité de traverser ou non, le tag
overtaking <http://wiki.openstreetmap.org/wiki/Key:overtaking> permet
de le gérer de fait avec les conditions expliquées au préalable. Mais
si la voirie est découpée à chaque intersection, ce tag ne permettra
pas à lui seul de définir les interdictions de tournée à gauche. Il
est donc nécessaire de mettre une restriction de tournée à gauche si
on est sur une voie à double sens, non séparée, dont il existe une
ligne blanche continue sans segmentation. Sinon le GPS propose de
traverser.
Schématiquement:
===== B
//
A===X====A'
Ducoup avec le schéma suivant:
AA' est la voie portant l'information overtaking=yes
si AA' est coupé en X il faut faire une interdiction de tourner à
gauche avec
role:from sur AX
role:to sur XB
role:via sur X
===== B
//
A=======A'
Le même schéma sans découpage ne permet pas de toute façon de faire la
relation, et s'il y a overtaking = yes sur AA' on ne peut pas tournée
en venant de A vers B
Voilà ma petite contrib de fin de journée.
J'espère avoir été assez clair... ;-)
_______________________________________________
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
