Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

2018-08-16 Par sujet osm . sanspourriel 



Le 16/08/2018 à 00:49, laurent-38 - laurent.riffard+nab...@free.fr a écrit :

Jérôme Seigneuret-3 wrote

Bonjour,
Sauf que pour les 80 ou 90 ou 110 en soit il n'y a pas l'obligation
d'avoir
un panneau.

Le code de la route dit
130 km/h sur les autoroutes ;
110 km/h sur les routes à deux chaussées séparées par un terre-plein
central ;
90 km/h sur les autres routes.
et maintenant on décompose le 90

90 sur les routes à double sens de circulation opposé avec un terre-plein
central
80 sur les routes n'ayant pas de séparateur et à double sens de
circulation,
90 pour les doubles voies dans le même sens de circulation sans séparateur

Bonjour,
Je vous invite à lire les articles modifiés du code de la route :
https://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA06177128&cidTexte=LEGITEXT06074228

Contrairement à ce qu'annonce le décret dans sa notice, et divers sites du
gouvernement, le séparateur central n'entre pas en ligne de compte pour
distinguer entre 80 et 90. Seul compte le nombre voies dans le même sens. 1
voie=80 km/h, 2 voies dans le même sens=90 km/h pour le sens concerné (sauf
limitation plus restrictive dument signalée)
~~
laurent-38
Oui on connaît ces textes. Le décret 
 
parle de "routes bidirectionnelles à chaussée unique sans séparateur 
central", et veut donc sans doute exclure des 3 voies celles comportant 
deux traits discontinus (les routes où on peut jouer le jeu du poulet).


Tu oublies de citer la partie qui m'ennuie "Ces sections font l'objet 
d'une signalisation routière dans les conditions prévues par l'article 
R. 411-25."
In extenso : "3° 80 km/ h sur les autres routes. Toutefois, sur les 
sections de ces routes comportant au moins deux voies affectées à un 
même sens de circulation, la vitesse maximale est relevée à 90 km/ h sur 
ces seules voies. Ces sections font l'objet d'une signalisation routière 
dans les conditions prévues par l'article R. 411-25."
Certains comme toi pense que le "/la vitesse maximale est relevée à 90 
km/ h/" fait que c'est automatique.
D'autres comme moi pensent que "/_Ces sections font l'objet d'une 
signalisation routière_ dans les conditions prévues par l'article R. 
411-25/" et "/III. - Les autorités détentrices du pouvoir de police de 
la circulation compétentes communiquent (...) la liste des sections de 
routes relevant de leur compétence qui comportent au moins deux voies 
affectées à un même sens de circulation et sur lesquelles la vitesse 
maximale est relevée à 90 km/ h en application du 3° du I./" font que ce 
n'est pas automatique mais que l'autorité doit mettre en place une 
signalisation explicite. Et donc 90 _ou 80_ (car partout on peut mettre 
une vitesse inférieure au maximum théorique).

Pourquoi demander les tronçons en question si c'est automatiquement 90 ?

De plus on a vu que certaines autorités passent aussi les zones 
potentiellement à 90 à 80 (et des sections de 110 à 90), donc autant pas 
de soucis pour passer les cas non ambigus à 80, autant pour les autres 
il faut vérifier que les panneaux 90 ont été posés (ou qu'un passage à 
80 soit irréaliste style 4 voies type voie expresse mais déjà limitée à 
90 par le passé). Localement j'ai vu des 90 ajoutés mais d'autres ont vu 
des 80 ajoutés. Donc une modification à distance de ces cas semble délicat.


Question indépendante : les accidents sont géolocalisés. On devrait donc 
avoir le nombre d'accidents et le trafic (?) sur les zones qui sont 
passées de 90 à 80 et pour le reste du réseau et comparer les évolutions 
mensuelles des accidents suivant les catégories. Pourtant on n'entend 
parler que l'évolution globale. Savez-vous si ces informations sont 
calculées ? Disponibles ? Ça me semble nécessaire pour évaluer l'effet 
de la mesure.


Jean-Yvon (trial)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] State of The Map 2018 - Milan

2018-08-16 Par sujet althio 
Bonsoir,

Suite à la conférence internationale SotM 2018, je vous invite à lire
cet article détaillé, écrit par Paul Desgranges et complété
collaborativement par d'autres membres de la communauté française et
de l'association OpenStreetMap France.

http://next.openstreetmap.fr/state-of-the-map-2018-a-milan/

Bonne lecture.
Si vous cherchez d'autres lectures dans d'autres langues, surveillez ici :
https://www.openstreetmap.org/diary
et là :
http://www.weeklyosm.eu/fr/archives/10586

-- althio -- Benoît

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

Re: [OSM-talk-fr] Instabilité des connexions à OSM.org

2018-08-16 Par sujet Philippe Verdy 
J'ai même des erreurs de versions SSL. On dirait que certains serveurs ont
du mal avec certains certificats de sécurité, ou les parefeux d'OSM.org
sont un peu susceptibles et finissent à la suite de ces erreurs par fermer
des sessions agressivement. Je pense qu'il y a des imports massifs vers la
base en ce moment, ou encore une base de données qui part dans les choux et
doit être rechargée et on manque alors de capacité.

Le jeu. 16 août 2018 à 20:56, Philippe Verdy  a écrit :

> Depuis quelques temps les connexions au site OSM.org sont très erratiques,
> les envois à la base de données comme au serveur carto et serveur de tuiles
> cessent de répondre (pas d'acquitement, perte de session...), les
> connexions HTTPS échouent aléatoirement (erreurs de connexion, échec de
> permission, voire connexion refusés mais accepté 1 minute après).
>
> Difficile de contribuer: il faut faire des changesets bien plus petits
> pour pouvoir nettoyer facilement les doublons laissés par des envois
> partiels sans réponse.
>
> Il y a de nombreuses anomalies aussi dans le gestionnaire de conflits
> d'édition (lui aussi est extrêmement lent ou répond n'importe quoi, y
> compris des conflits avec soi-même, car le serveur ne ferme pas bien les
> changesets précédents, et la base se désynchronise et ne reflète pas les
> modifs).
>
> Bref après chaque modif il faut revérifier (en repassant en modif pour
> charger la zone à nouveau et voir ce qu'il en est) et nettoyer derrière
> (ways manquants, noeuds laissés en doublon, ou orphelins...). C'est assez
> pénible.
>
> Je pense que cela doit se voir dans les anomalies de geométrie ou noeuds
> orphelins détectés par Osmose avec un pic en terme de croissance.
>
> De plus les rendus sont de plus en plus lents à se synchroniser, il y a
> des zones entières jamais rafraîchies (même en attendant plus d'1 semaine),
> alors qu'il y a maintenant 5 serveur de rendu au lieu de 4.
>
> Tout cela ressemble à un problème de bande passante entrer les serveurs
> critiques OSM.org qui sont rtépartis de part et d'autre de la Manche. Mais
> il peut s'agir de changement de peerings depuis la France..
>
> Voyez-vous les mêmes difficultés ? (Note mon accès internet est la fibre
> de Free, je n'ai pas de problème de performance ou de perte de trame sur
> mes tests, sauf avec le services d'OSM.org)
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Instabilité des connexions à OSM.org

2018-08-16 Par sujet Philippe Verdy 
Depuis quelques temps les connexions au site OSM.org sont très erratiques,
les envois à la base de données comme au serveur carto et serveur de tuiles
cessent de répondre (pas d'acquitement, perte de session...), les
connexions HTTPS échouent aléatoirement (erreurs de connexion, échec de
permission, voire connexion refusés mais accepté 1 minute après).

Difficile de contribuer: il faut faire des changesets bien plus petits pour
pouvoir nettoyer facilement les doublons laissés par des envois partiels
sans réponse.

Il y a de nombreuses anomalies aussi dans le gestionnaire de conflits
d'édition (lui aussi est extrêmement lent ou répond n'importe quoi, y
compris des conflits avec soi-même, car le serveur ne ferme pas bien les
changesets précédents, et la base se désynchronise et ne reflète pas les
modifs).

Bref après chaque modif il faut revérifier (en repassant en modif pour
charger la zone à nouveau et voir ce qu'il en est) et nettoyer derrière
(ways manquants, noeuds laissés en doublon, ou orphelins...). C'est assez
pénible.

Je pense que cela doit se voir dans les anomalies de geométrie ou noeuds
orphelins détectés par Osmose avec un pic en terme de croissance.

De plus les rendus sont de plus en plus lents à se synchroniser, il y a des
zones entières jamais rafraîchies (même en attendant plus d'1 semaine),
alors qu'il y a maintenant 5 serveur de rendu au lieu de 4.

Tout cela ressemble à un problème de bande passante entrer les serveurs
critiques OSM.org qui sont rtépartis de part et d'autre de la Manche. Mais
il peut s'agir de changement de peerings depuis la France..

Voyez-vous les mêmes difficultés ? (Note mon accès internet est la fibre de
Free, je n'ai pas de problème de performance ou de perte de trame sur mes
tests, sauf avec le services d'OSM.org)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] La dernière version de PT_Assistant vient d'être publié

2018-08-16 Par sujet Jo 
Salutations,

La dernière version du greffon PT_Assistant vient d'être publié pour un
usage général. Il y a quelques jours déjà, mais je voulais encore tester un
peu avant de l'annoncer.

Il fonctionne avec josm_tested.jar. Pour le mettre à jour il faut peut-être
mettre à jour votre liste de greffons.

Les nouvelles fonctionnalités incluent:
- Nouveau Map Mode pour diviser un chemin en 2 points simultanément et
appliquer directement les tags: bridge/tunnel=yes bus_bay=right/left/both
ou traffic_calming=table. Il fonctionne également sur 2 chemins qui se
'touchent'.

- Assistant de routage avec 2 modes de fonctionnement:
  * quelle chemin emprunter à la prochaine bifurcation?
  * transfert de chaînes plus longues de chemins, qui connectent déjà
correctement le chemin d'origine et le chemin juste après l'interruption
dans la route actuelle

   (il faut trouver un meilleur nom pour cette option-là, en anglais j'ai
tendance à l'appeler Fast-Forward)

   (Ce n'est qu'une aide, il faut toujours vérifier lesquelles des options
est la plus adéquate et vérifier si la route est bien amélioré après
l'application.)

- Un 'wizard' pour vous aider à configurer JOSM pour faciliter la
cartographie d'itinéraires bus, vélo ou de randonnée. (Depuis l'été dernier
PT_Assistant visualise également les relations route bicycle et
foot/walking/hiking, avec les chemins qui ne sont utilisés que dans une des
sens, dans une autre couleur, ce qui facilite l'appilcation correcte des
rôles forward/backward)

- Beaucoup d'améliorations divers et des bugs resolus.


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

Re: [OSM-talk-fr] wikidata vs brand:wikidata : le challenge MapRoulette

2018-08-16 Par sujet PanierAvide 

Bonjour,

Pas sûr que ça marche ou soit fait pour, mais si on ajoute sur cette 
page un ensemble de tag wikidata=* que l'on indique de transformer en 
brand:wikidata=*, ça fait pas le boulot côté Osmose ? Pour le coup ce 
serait simple à mettre en place, il ne resterait plus qu'à générer cette 
liste de valeurs wikidata pour lesquels on sait qu'elles référencent des 
chaînes.


Adrien.

Le 16/08/2018 à 13:29, Noémie Lehuby a écrit :


Hello,

Je suis encore retombé cette semaine sur des magasins avec un tag 
wikidata.

Est-ce qu'on a avancé un peu sur le sujet ?

La page wiki avec la liste des magasins ne contient qu'une quinzaine 
d'éléments : 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Marques_et_cha%C3%AEnes 



On avait parlé d'une analyse Osmose : peut-être qu'une blacklist sur 
un ensemble de valeurs pour le tag wikidata qu'on sait être une chaine 
de magasin peut être un bon début (un magasin qui a le tag wikidata de 
Carrefour devrait être passé en brand:wikidata dans la majorité des 
cas). Qu'en pensez-vous ?


Et on avait aussi parlé de refaire un challenge Maproulette pour 
vérifier tous les magasins et les banques qui avaient un tag wikidata.


Noémie

Le 2018-04-16 14:21, PanierAvide a écrit :


Bonjour,

Sur la base de la requête suivante : http://overpass-turbo.eu/s/xRn
Qui était elle-même basée sur la requête Wikidata que tu avais 
proposée, élargie à un rayon de 1000 km. Mais effectivement le 
prédicat de départ c'est de sortir les éléments dont le tag wikidata 
est une chaîne de magasins. Donc c'est limité à ce qui est 
correctement renseigné côté wikidata comme telle.


On peut partir sur une requête plus large, côté Overpass cette 
fois-ci, où on considère qu'un shop n'est pas sensé avoir de tag 
wikidata (ce qui sera vrai dans la plupart des cas). Ça nous donne la 
requête suivante :


http://overpass-turbo.eu/s/xWm

Soit 1410 lieux concernés. Si c'est OK dans le principe, on peut 
repartir sur un autre challenge MapRoulette.


Adrien.


Le 16/04/2018 à 14:12, Noémie Lehuby a écrit :


Bonjour,

Sur quelle base (requête Overpass ou autre) as-tu constitué ton 
challenge ? On en a déjà fait le tour et je doute qu'il y ait si peu 
d'objets à corriger ...


Noémie

Le 2018-04-14 20:35, PanierAvide a écrit :

Bonjour,

J'ai créé le challenge MapRoulette pour changer les tags
wikidata=* inappropriés sur les franchises (en précisant dans la
description l'objectif visé) :
http://maproulette.org/mr3/challenge/2997

À vos claviers, prêts ? Éditez ! ;-)

Cordialement,

Adrien.

Le 11/04/2018 à 16:13, Noémie Lehuby a écrit :

Bonjour,

Le tag wikidata correspondant à Autolib' a été ajouté sur
les stations Autolib' de région parisienne.
Par exemple : https://www.openstreetmap.org/node/4472979080

Il me semble que cela devrait être dans un tag
brand:wikidata (voire operator:wikidata). Je me trompe ?

Noémie



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


-- 
PanierAvide

Géomaticien & développeur


___
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



--
PanierAvide
Géomaticien & développeur

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

Re: [OSM-talk-fr] wikidata vs brand:wikidata : le challenge MapRoulette

2018-08-16 Par sujet Noémie Lehuby 
Hello,

Je suis encore retombé cette semaine sur des magasins avec un tag
wikidata. 
Est-ce qu'on a avancé un peu sur le sujet ?

La page wiki avec la liste des magasins ne contient qu'une quinzaine
d'éléments :
https://wiki.openstreetmap.org/wiki/WikiProject_France/Marques_et_cha%C3%AEnes


On avait parlé d'une analyse Osmose : peut-être qu'une blacklist sur un
ensemble de valeurs pour le tag wikidata qu'on sait être une chaine de
magasin peut être un bon début (un magasin qui a le tag wikidata de
Carrefour devrait être passé en brand:wikidata dans la majorité des
cas). Qu'en pensez-vous ?

Et on avait aussi parlé de refaire un challenge Maproulette pour
vérifier tous les magasins et les banques qui avaient un tag wikidata.

Noémie 

Le 2018-04-16 14:21, PanierAvide a écrit :

> Bonjour, 
> 
> Sur la base de la requête suivante : http://overpass-turbo.eu/s/xRn
> Qui était elle-même basée sur la requête Wikidata que tu avais proposée, 
> élargie à un rayon de 1000 km. Mais effectivement le prédicat de départ c'est 
> de sortir les éléments dont le tag wikidata est une chaîne de magasins. Donc 
> c'est limité à ce qui est correctement renseigné côté wikidata comme telle. 
> 
> On peut partir sur une requête plus large, côté Overpass cette fois-ci, où on 
> considère qu'un shop n'est pas sensé avoir de tag wikidata (ce qui sera vrai 
> dans la plupart des cas). Ça nous donne la requête suivante : 
> 
> http://overpass-turbo.eu/s/xWm 
> 
> Soit 1410 lieux concernés. Si c'est OK dans le principe, on peut repartir sur 
> un autre challenge MapRoulette. 
> 
> Adrien. 
> Le 16/04/2018 à 14:12, Noémie Lehuby a écrit : 
> 
> Bonjour, 
> 
> Sur quelle base (requête Overpass ou autre) as-tu constitué ton challenge ? 
> On en a déjà fait le tour et je doute qu'il y ait si peu d'objets à corriger 
> ... 
> 
> Noémie 
> 
> Le 2018-04-14 20:35, PanierAvide a écrit : 
> Bonjour,
> 
> J'ai créé le challenge MapRoulette pour changer les tags wikidata=* 
> inappropriés sur les franchises (en précisant dans la description l'objectif 
> visé) :
> http://maproulette.org/mr3/challenge/2997
> 
> À vos claviers, prêts ? Éditez ! ;-)
> 
> Cordialement,
> 
> Adrien.
> 
> Le 11/04/2018 à 16:13, Noémie Lehuby a écrit : 
> 
> Bonjour, 
> 
> Le tag wikidata correspondant à Autolib' a été ajouté sur les stations 
> Autolib' de région parisienne.
> Par exemple : https://www.openstreetmap.org/node/4472979080 
> 
> Il me semble que cela devrait être dans un tag brand:wikidata (voire 
> operator:wikidata). Je me trompe ? 
> 
> Noémie
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> -- 
> PanierAvide
> Géomaticien & développeur
> 
> ___
> 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