dégradation notable d'OSM

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

dégradation notable d'OSM

david.crochet-2
Bonjour

https://www.openstreetmap.org/user/Chlc dégrade notablement OSM :

- Suppression des pattes d'oie à l'arrivée sur un rond point
- Réunion de voies séparée physiquement
- Transformation des voies rapides réservé pour automobile en route
ouverte à la circulation publique
- descente de catégorie de voies de circulation
- Suppression de feu tricolore
- suppression des sas de changement de direction (turn_lanes)

et il doit y en avoir d'autre

J'ai commenter certains diffs, envoyer un message d'explication, mais je
pense qu'il faut vérifier l'ensemble de ses contributions et faire  de
annulation en masse.

Cordialement

--
David Crochet


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

Re: dégradation notable d'OSM

Bibi

J'aime aussi ses commentaires : route ou gr.

On regarde sa réaction avant de bouger ? Vu la suite je dirais à bloquer afin qu'il discute des changesets.

Et bloquer l'édition dans qu'il n'y a pas répondu.

Tu fais la demande au DWG avec copie à Guillaume Rischard [hidden email] ?

As-tu des coins où effectivement tu sais que le rond-point est toujours là ?

Il a pas mal de modifs à son compteur (6 432 depuis 2014).

Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus tôt. mais pas sûr du tout.

> - Suppression des pattes d'oie à l'arrivée sur un rond point
Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
On peut aussi modéliser avec des traffic_calming=island.

Je vois qu'il a été repéré il y a 2 mois par Antoine.
https://www.openstreetmap.org/changeset/75562503

Et Thomas : https://www.openstreetmap.org/changeset/75517630

Jamais de réponse !

https://hdyc.neis-one.org/?Chlc

Changeset discussions: Participated in 0 and created 0 comments

Quality assurance: iD editor: Resolved issues=70, Ignored warnings=28
Osmose issues: Level 1=99, Level 2=942, Level 3=1740

Jean-Yvon

Le 29/11/2019 à 19:14, David Crochet - [hidden email] a écrit :
Bonjour

https://www.openstreetmap.org/user/Chlc dégrade notablement OSM :

- Suppression des pattes d'oie à l'arrivée sur un rond point
- Réunion de voies séparée physiquement
- Transformation des voies rapides réservé pour automobile en route ouverte à la circulation publique
- descente de catégorie de voies de circulation
- Suppression de feu tricolore
- suppression des sas de changement de direction (turn_lanes)

et il doit y en avoir d'autre

J'ai commenter certains diffs, envoyer un message d'explication, mais je pense qu'il faut vérifier l'ensemble de ses contributions et faire  de annulation en masse.

Cordialement


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

Re: dégradation notable d'OSM

Dominique Rousseau-2
Le Fri, Nov 29, 2019 at 09:46:14PM +0100, [hidden email] [[hidden email]] a écrit:
[...]
> > - Suppression des pattes d'oie à l'arrivée sur un rond point
> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
> On peut aussi modéliser avec des traffic_calming=island
> <https://wiki.openstreetmap.org/wiki/Tag:traffic_calming=island>.

Ah, merci !
J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
choses comme ça, et je trouvais ça plutot moche.
Maintenant je saurais comment les faire :)


--
Dominique Rousseau
[hidden email] - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.                      -- Mahatma Gandhi

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

Re: dégradation notable d'OSM

StephaneP
Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
m'en suis pas rendu compte.

En tout cas traffic_calming ne me semble pas vraiment approprié si on se
réfère à son sens premier. La séparation à l'entrée/sortie d'un
giratoire n'est pas là pour ralentir le trafic.

Stf

Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :

> Le Fri, Nov 29, 2019 at 09:46:14PM +0100, [hidden email] [[hidden email]] a écrit:
> [...]
>>> - Suppression des pattes d'oie à l'arrivée sur un rond point
>> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
>> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
>> On peut aussi modéliser avec des traffic_calming=island
>> <https://wiki.openstreetmap.org/wiki/Tag:traffic_calming=island>.
> Ah, merci !
> J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
> choses comme ça, et je trouvais ça plutot moche.
> Maintenant je saurais comment les faire :)
>
>


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

Re: dégradation notable d'OSM

david.crochet-2
In reply to this post by Bibi
Bonjour

Le 29/11/2019 à 21:46, [hidden email] a écrit :
> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !


OSMAnd ne fait pas cette erreur. Si les branche son bien étiquetté avec
les oneway=yes ad'hoc, il comptent bien uniquement les sorties et non
les entrées

Cordialement

--
David Crochet


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

Re: dégradation notable d'OSM

david.crochet-2
In reply to this post by Bibi
Bonjour

Le 29/11/2019 à 21:46, [hidden email] a écrit :
> Je pense naïvement que si c'était si mauvais on s'en serait aperçu
> plus tôt. mais pas sûr du tout.


C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il
vient seulement d'y contribuer et mal, et c'est en regardant
l'historique que j'ai vu qu'il cartographier mal depuis un moment.

Cordialement

--
David Crochet


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

Re: dégradation notable d'OSM

Florimond Berthoux
In reply to this post by StephaneP
+1 Tous les îlots ne sont pas là pour "calmer" (ralentir) le trafic,
bien au contraire, les îlots de ronds points sont fait pour séparer le
trafic et les insérer avec un angle de giration sympathique permettant
une bonne allure.
Il ne faut pas utiliser traffic_calming=island pour cela !

Le lun. 2 déc. 2019 à 21:01, Stéphane Péneau
<[hidden email]> a écrit :

>
> Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
> m'en suis pas rendu compte.
>
> En tout cas traffic_calming ne me semble pas vraiment approprié si on se
> réfère à son sens premier. La séparation à l'entrée/sortie d'un
> giratoire n'est pas là pour ralentir le trafic.
>
> Stf
>
> Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :
> > Le Fri, Nov 29, 2019 at 09:46:14PM +0100, [hidden email] [[hidden email]] a écrit:
> > [...]
> >>> - Suppression des pattes d'oie à l'arrivée sur un rond point
> >> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
> >> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
> >> On peut aussi modéliser avec des traffic_calming=island
> >> <https://wiki.openstreetmap.org/wiki/Tag:traffic_calming=island>.
> > Ah, merci !
> > J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
> > choses comme ça, et je trouvais ça plutot moche.
> > Maintenant je saurais comment les faire :)
> >
> >
>
>
> _______________________________________________
> 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: dégradation notable d'OSM

Bibi
In reply to this post by david.crochet-2

Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans la vérification des modifications et que toutes les remarques sur les modifications sont restées sans réponse :

http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je crois que vous êtes les mieux placés pour demander un blocage au DWG le temps que cette personne réponde à vos interrogations.

Je vois aussi parmi les métriques : Osmose issues: Level 1=96, Level 2=999, Level 3=1870.

Oui près de 100 erreurs de niveau 1.

Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la distance que de prendre un raccourci par une route moins importante. Donc c'est une question de poids de certains éléments pour le calcul du trajet et non un mauvais comptage des sorties.

N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un moment, quant au bout d'une "certain temps" le contributeur ne répond pas et continue ses mauvaises pratiques, ça ne sert à rien de continuer sur le même mode il faut essayer un autre canal.

Jean-Yvon

Le 02/12/2019 à 21:09, David Crochet - [hidden email] a écrit :
Bonjour

Le 29/11/2019 à 21:46, [hidden email] a écrit :
Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus tôt. mais pas sûr du tout.


C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il vient seulement d'y contribuer et mal, et c'est en regardant l'historique que j'ai vu qu'il cartographier mal depuis un moment.

Cordialement


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

Re: dégradation notable d'OSM

verdy_p
Attention: les erreurs associées à un utilisateur ne sont pas de son fait pour la plupart, cela se produit notamment indirectement pour des modifications locales (correctes) de relations dont d'autres membres avaient déjà des problèmes ailleurs mais n'ont pas été modifiés pour autant. Cas typique:
- les relations de transport où on peut trouver des intersections route/rivière (sans pont ou tunnel) ou route/bâtiment: il y en a encore des tas dans la base et pas attribuées à l'utilisateur correct ayant créé ces intersections.
- des tags laissés de côté mais pas retirés/modifiés car cela aurait conduit à des modifs en cascade et des changesets gigantesque pour fouiller chacune des dépendances sur des problèmes très éloignés de la zone qui a été réellement modifiée.
Bref concernant les erreurs de "niveau1" sur les relations, ce n'est pas si critique que ça, sauf concernant la géométrie des relations elles-mêmes (chemins membres polygones qui doivent être fermés, et tronçons manquant sur les relations linéaires (mais bien souvent les anomalies viennent de tronçons qui étaioent déjà retirés ailleurs, et les longues relations de transport sont souvent concernées par ces tronçons mal reliés quand quelqu'un d'autre a redessiné un carrefour mais omis de relier les segments de connexion. L'utilisateur suivant qui vient faire une modif ailleurs mais ne touche pas à la géométrie ou fait une modif correcte ailleurs ne verra pas toujours qu'il manque des éléments (et faire le tri pour corriger ce qui manque ailleurs prend un temps fou: l'erreur était déjà là, elle subsiste, mais l'attribution donnée au dernier modificateur n'indique pas qu'il est responsable de cette erreur qui était déjà là avant lui.
N'importe qui travaillant beaucoup sur OSM et correctement se voit automatiquement "attribué" ensuite des erreurs sans même rien toucher, à cause des dépendances sur d'autres objets qu'il n'a même pas touché lui-même mais ont été touchés par d'autres.
Bref ce n'est qu'une indication mais pour le détail il faut revoir l'historique et visiblement peu de gens savant interpréter les historiques (même les outils automatiques ont du mal à s'y retrouver tellement c'est compliqué): c'est un problème inhérent au modèle de données OSM. Là pas le choix il faut s'y coller erreur par erreur, localement mais celui qui s'y colle et vient corriger chacune une par une se voit ensuite attribuer des erreurs qu'il n'a pas encore traitées mais concernant d'autres problèmes ailleurs sur les mêmes relations touchées.
Bref ne pas trope se fier aux attributions d'auteurs qui n'indiquent que l'auteur de la dernière modif effectuée sur un objet, mais rarement l'auteur de la modif plus ancienne qui a produit cette erreur. C'est pour ça qu'on ne devrait pas appeler cela "erreur" mais juste "signalement. Oui il y a un problème, mais rarement de l'auteur indiqué, l'outil de neis-one ne faisant pas dans le détail pour fouiller les hiostoriques des modifs pour en trouver l'origine réelle avec l'analyse poussée des diffs.


Le mar. 3 déc. 2019 à 21:16, <[hidden email]> a écrit :

Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans la vérification des modifications et que toutes les remarques sur les modifications sont restées sans réponse :

http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je crois que vous êtes les mieux placés pour demander un blocage au DWG le temps que cette personne réponde à vos interrogations.

Je vois aussi parmi les métriques : Osmose issues: Level 1=96, Level 2=999, Level 3=1870.

Oui près de 100 erreurs de niveau 1.

Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la distance que de prendre un raccourci par une route moins importante. Donc c'est une question de poids de certains éléments pour le calcul du trajet et non un mauvais comptage des sorties.

N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un moment, quant au bout d'une "certain temps" le contributeur ne répond pas et continue ses mauvaises pratiques, ça ne sert à rien de continuer sur le même mode il faut essayer un autre canal.

Jean-Yvon

Le 02/12/2019 à 21:09, David Crochet - [hidden email] a écrit :
Bonjour

Le 29/11/2019 à 21:46, [hidden email] a écrit :
Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus tôt. mais pas sûr du tout.


C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il vient seulement d'y contribuer et mal, et c'est en regardant l'historique que j'ai vu qu'il cartographier mal depuis un moment.

Cordialement

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

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

Re: dégradation notable d'OSM

verdy_p
Ceci dit on voit tout de même des infos pertinentes concernant les erreurs de cet utilisateur, notamment avec des détections assez précises comme "relations à 1 seul membre" qui indique qu'il a retracé par exemple des carrefours mais omis les relations de restriction d'accès, vraiment très locales): il découpe n'importe comment, ne se soucient pas du tout de remettre les relations d'aplomb: il retrace, supprime ce qui le gêne ou fait doublon pour lui sans jamais se préoccuper des dépendances de ce qu'il supprime. Au passage il omet pas mal de tags ou les remet mal sur les objets de remplacement.
Il ne se soucie pas non plus de la précision et ses tracés sont vite faits à la louche, très anguleux, de fait inévitablement ils vont entrer en intersection avec des bâtiments dans les villes aux rues étroites.
Le résultat c'est une carte de Caen qui maintenant ressemble à un patchwork découpé à grand coup de ciseaux, il n'y a plus aucun angle correct, ce n'est plus un plan, c'est un schéma. Visiblement il se fouit pas mal de la précision. On se retrouve aussi avec des équipements du mauvais côté de la rue. Je pense qu'il utilise l'éditeur à très mauvais escient et va beaucoup trop vite, qu'il manque de formation. C'est acceptable pour des utilisateurs occasionnels, mais là avec son usage fréquent, il s'attaque à des choses qu'il ne maitrise vraiment pas assez pour faire des modifs aussi massives et fréquentes que les autres ont du mal à suivre ensuite pour corriger ses nombreux "oublis". Mais comme il fait tout dans son coin et ne paarticipe à aucune discussion, il n'apprend rien de plus. On doit donc le freiner et lui apprendre à collaborer et écouter les enseignements. Sinon il ne s'améliorera jamais et laisse tous les dégâts à la charge des autres qui doivent ensuite passer beaucoup plus de temps pour corriger chacune de ses erreurs que le temps très rapide avec lequel il modifie quantité d'objets.
Pour des cas comme ça, il serait souhaitable qu'OSM dispose d'une option permettant de freiner un utilisateur en limitant le nombre de changesets et d'objets: s'il y a trop d'erreurs laissées derrière, il vaudrait mieux avoir un moyen de dire que des modifs hors d'une zone précise sont proscrite, afin de l'obliger à passer du temps à corriger ce qui reste en fonction d'un certain nombre de rapports d'anomalies ou de signalements laissés sans réponse de sa part.


Le mar. 3 déc. 2019 à 23:08, Philippe Verdy <[hidden email]> a écrit :
Attention: les erreurs associées à un utilisateur ne sont pas de son fait pour la plupart, cela se produit notamment indirectement pour des modifications locales (correctes) de relations dont d'autres membres avaient déjà des problèmes ailleurs mais n'ont pas été modifiés pour autant. Cas typique:
- les relations de transport où on peut trouver des intersections route/rivière (sans pont ou tunnel) ou route/bâtiment: il y en a encore des tas dans la base et pas attribuées à l'utilisateur correct ayant créé ces intersections.
- des tags laissés de côté mais pas retirés/modifiés car cela aurait conduit à des modifs en cascade et des changesets gigantesque pour fouiller chacune des dépendances sur des problèmes très éloignés de la zone qui a été réellement modifiée.
Bref concernant les erreurs de "niveau1" sur les relations, ce n'est pas si critique que ça, sauf concernant la géométrie des relations elles-mêmes (chemins membres polygones qui doivent être fermés, et tronçons manquant sur les relations linéaires (mais bien souvent les anomalies viennent de tronçons qui étaioent déjà retirés ailleurs, et les longues relations de transport sont souvent concernées par ces tronçons mal reliés quand quelqu'un d'autre a redessiné un carrefour mais omis de relier les segments de connexion. L'utilisateur suivant qui vient faire une modif ailleurs mais ne touche pas à la géométrie ou fait une modif correcte ailleurs ne verra pas toujours qu'il manque des éléments (et faire le tri pour corriger ce qui manque ailleurs prend un temps fou: l'erreur était déjà là, elle subsiste, mais l'attribution donnée au dernier modificateur n'indique pas qu'il est responsable de cette erreur qui était déjà là avant lui.
N'importe qui travaillant beaucoup sur OSM et correctement se voit automatiquement "attribué" ensuite des erreurs sans même rien toucher, à cause des dépendances sur d'autres objets qu'il n'a même pas touché lui-même mais ont été touchés par d'autres.
Bref ce n'est qu'une indication mais pour le détail il faut revoir l'historique et visiblement peu de gens savant interpréter les historiques (même les outils automatiques ont du mal à s'y retrouver tellement c'est compliqué): c'est un problème inhérent au modèle de données OSM. Là pas le choix il faut s'y coller erreur par erreur, localement mais celui qui s'y colle et vient corriger chacune une par une se voit ensuite attribuer des erreurs qu'il n'a pas encore traitées mais concernant d'autres problèmes ailleurs sur les mêmes relations touchées.
Bref ne pas trope se fier aux attributions d'auteurs qui n'indiquent que l'auteur de la dernière modif effectuée sur un objet, mais rarement l'auteur de la modif plus ancienne qui a produit cette erreur. C'est pour ça qu'on ne devrait pas appeler cela "erreur" mais juste "signalement. Oui il y a un problème, mais rarement de l'auteur indiqué, l'outil de neis-one ne faisant pas dans le détail pour fouiller les hiostoriques des modifs pour en trouver l'origine réelle avec l'analyse poussée des diffs.


Le mar. 3 déc. 2019 à 21:16, <[hidden email]> a écrit :

Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans la vérification des modifications et que toutes les remarques sur les modifications sont restées sans réponse :

http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je crois que vous êtes les mieux placés pour demander un blocage au DWG le temps que cette personne réponde à vos interrogations.

Je vois aussi parmi les métriques : Osmose issues: Level 1=96, Level 2=999, Level 3=1870.

Oui près de 100 erreurs de niveau 1.

Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la distance que de prendre un raccourci par une route moins importante. Donc c'est une question de poids de certains éléments pour le calcul du trajet et non un mauvais comptage des sorties.

N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un moment, quant au bout d'une "certain temps" le contributeur ne répond pas et continue ses mauvaises pratiques, ça ne sert à rien de continuer sur le même mode il faut essayer un autre canal.

Jean-Yvon

Le 02/12/2019 à 21:09, David Crochet - [hidden email] a écrit :
Bonjour

Le 29/11/2019 à 21:46, [hidden email] a écrit :
Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus tôt. mais pas sûr du tout.


C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il vient seulement d'y contribuer et mal, et c'est en regardant l'historique que j'ai vu qu'il cartographier mal depuis un moment.

Cordialement

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

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

Re: dégradation notable d'OSM

lenny.libre
In reply to this post by Bibi


Le 03/12/2019 à 21:15, [hidden email] a écrit :

Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans la vérification des modifications et que toutes les remarques sur les modifications sont restées sans réponse :

http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je crois que vous êtes les mieux placés pour demander un blocage au DWG le temps que cette personne réponde à vos interrogations.

Je vois aussi parmi les métriques : Osmose issues: Level 1=96, Level 2=999, Level 3=1870.

Oui près de 100 erreurs de niveau 1.

une remarque concernant uniquement le nombre d'anomalies Osmose : il me semble qu'il ne faudrait pas les prendre comme référence pour l'utilisateur, car, en modifiant un élément, on récupère ses anomalies (j'ajoute le nom à un arrêt de bus et je récupère l'anomalie comme quoi il n'est pas rattaché à une ligne de bus) parfois on récupère l'anomalie créée après coup (je crée un chemin, sur l'avant-dernier nœud un autre contributeur découpe le chemin et supprime le dernier tronçon qui le rattaché à un autre chemin, le contributeur reçoit une anomalie de "manque sans issue" sur le chemin et moi sur le nœud) ...

cordialement

leni

Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la distance que de prendre un raccourci par une route moins importante. Donc c'est une question de poids de certains éléments pour le calcul du trajet et non un mauvais comptage des sorties.

N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un moment, quant au bout d'une "certain temps" le contributeur ne répond pas et continue ses mauvaises pratiques, ça ne sert à rien de continuer sur le même mode il faut essayer un autre canal.

Jean-Yvon

Le 02/12/2019 à 21:09, David Crochet - [hidden email] a écrit :
Bonjour

Le 29/11/2019 à 21:46, [hidden email] a écrit :
Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus tôt. mais pas sûr du tout.


C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il vient seulement d'y contribuer et mal, et c'est en regardant l'historique que j'ai vu qu'il cartographier mal depuis un moment.

Cordialement


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

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

Re: dégradation notable d'OSM

DURUPT Celine (EXT CONCRETIO)
In reply to this post by Florimond Berthoux
J'ai déjà utilisé landuse=traffic_island (exemple : https://www.openstreetmap.org/way/476606647 ) mais d'après le wiki (https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dtraffic_island) il faut (peut-être ?) maintenant utiliser : area:highway=traffic_island

Céline

-----Message d'origine-----
De : Florimond Berthoux [mailto:[hidden email]]
Envoyé : mardi 3 décembre 2019 10:40
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] dégradation notable d'OSM

+1 Tous les îlots ne sont pas là pour "calmer" (ralentir) le trafic,
bien au contraire, les îlots de ronds points sont fait pour séparer le
trafic et les insérer avec un angle de giration sympathique permettant
une bonne allure.
Il ne faut pas utiliser traffic_calming=island pour cela !

Le lun. 2 déc. 2019 à 21:01, Stéphane Péneau
<[hidden email]> a écrit :

>
> Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
> m'en suis pas rendu compte.
>
> En tout cas traffic_calming ne me semble pas vraiment approprié si on se
> réfère à son sens premier. La séparation à l'entrée/sortie d'un
> giratoire n'est pas là pour ralentir le trafic.
>
> Stf
>
> Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :
> > Le Fri, Nov 29, 2019 at 09:46:14PM +0100, [hidden email] [[hidden email]] a écrit:
> > [...]
> >>> - Suppression des pattes d'oie à l'arrivée sur un rond point
> >> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
> >> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
> >> On peut aussi modéliser avec des traffic_calming=island
> >> <https://wiki.openstreetmap.org/wiki/Tag:traffic_calming=island>.
> > Ah, merci !
> > J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
> > choses comme ça, et je trouvais ça plutot moche.
> > Maintenant je saurais comment les faire :)
> >
> >
>
>
> _______________________________________________
> 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
-------
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas assurée sur Internet, la SNCF ne peut être tenue responsable des altérations qui pourraient se produire sur son contenu. Toute publication, utilisation, reproduction, ou diffusion, même partielle, non autorisée préalablement par la SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
-------
This message and any attachments are intended solely for the addressees and are confidential. SNCF may not be held responsible for their contents whose accuracy and completeness cannot be guaranteed over the Internet. Unauthorized use, disclosure, distribution, copying, or any part thereof is strictly prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete it.
_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: dégradation notable d'OSM

Guillaume Rischard
Salut tous,

J’ai mis un message à l’utilisateur, qui ne pourra pas continuer à éditer sans confirmer l’avoir lu :


Pour la suggestion de pouvoir freiner un éditeur, un gros message bien visible comme ça suffit  en général - l’immense majorité des gens ne se rendent pas compte des problèmes. Sinon, on a la possibilité de bloquer quelques jours, et, pour les personnes qui ne comprennent vraiment pas, de façon permanente.

Sur une tangente, il y a https://github.com/openstreetmap/openstreetmap-website/issues/2342 qui propose de limiter le nombre d’éditions par personne et par jour. La discussion parle aussi des imports, et essaie de définir une unité d’édition.

Guillaume


On 4 Dec 2019, at 15:17, DURUPT Celine (EXT CONCRETIO) <[hidden email]> wrote:

J'ai déjà utilisé landuse=traffic_island (exemple : https://www.openstreetmap.org/way/476606647 ) mais d'après le wiki (https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dtraffic_island) il faut (peut-être ?) maintenant utiliser : area:highway=traffic_island

Céline

-----Message d'origine-----
De : Florimond Berthoux [[hidden email]]
Envoyé : mardi 3 décembre 2019 10:40
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] dégradation notable d'OSM

+1 Tous les îlots ne sont pas là pour "calmer" (ralentir) le trafic,
bien au contraire, les îlots de ronds points sont fait pour séparer le
trafic et les insérer avec un angle de giration sympathique permettant
une bonne allure.
Il ne faut pas utiliser traffic_calming=island pour cela !

Le lun. 2 déc. 2019 à 21:01, Stéphane Péneau
<[hidden email]> a écrit :

Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
m'en suis pas rendu compte.

En tout cas traffic_calming ne me semble pas vraiment approprié si on se
réfère à son sens premier. La séparation à l'entrée/sortie d'un
giratoire n'est pas là pour ralentir le trafic.

Stf

Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :
Le Fri, Nov 29, 2019 at 09:46:14PM +0100, [hidden email] [[hidden email]] a écrit:
[...]
- Suppression des pattes d'oie à l'arrivée sur un rond point
Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
On peut aussi modéliser avec des traffic_calming=island
<https://wiki.openstreetmap.org/wiki/Tag:traffic_calming=island>.
Ah, merci !
J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
choses comme ça, et je trouvais ça plutot moche.
Maintenant je saurais comment les faire :)




_______________________________________________
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
-------
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas assurée sur Internet, la SNCF ne peut être tenue responsable des altérations qui pourraient se produire sur son contenu. Toute publication, utilisation, reproduction, ou diffusion, même partielle, non autorisée préalablement par la SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
-------
This message and any attachments are intended solely for the addressees and are confidential. SNCF may not be held responsible for their contents whose accuracy and completeness cannot be guaranteed over the Internet. Unauthorized use, disclosure, distribution, copying, or any part thereof is strictly prohibited. If you are not the intended recipient of this message, please notify the sender immediately and delete it.
_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


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

Re: dégradation notable d'OSM

Bibi
In reply to this post by lenny.libre

Le 04/12/2019 à 11:43, lenny.libre - [hidden email] a écrit :

une remarque concernant uniquement le nombre d'anomalies Osmose

Tu vas dans le même sens que Philippe du coup je publie ma réponse initialement privée :

Je n'ai pas dit qu'il était responsable des erreurs, j'ai juste parlé de métrique. Il ne faut pas faire dire à une métrique ce qu'elle ne veut pas dire. [j'ajoute : comme ici on est quand même essentiellement entre personnes expérimentées, ça me semblait évident que je ne prenais la métrique Osmose pas comme l'alpha et l'oméga mais comme une simple métrique, j'aurais dû être plus explicite]

Simplement pour arriver à cela c'est qu'il n'en a rien à faire.

J'ai 0 erreur de niveau 1, je me suis mangé plein d'erreurs de niveau 2 du fait d'une modification massive des mairies (suppression du ref:INSEE) et je vais prendre mon bâton de pèlerin pour virer ces erreurs.

Ce n'est pas parce qu'on ne les a pas créées qu'on ne peut profiter pour les corriger.

N. B. : à l'opposé les pylônes transformateurs sont restés sans ligne autour parce que c'est difficile à suivre sur les photos et je n'ai pas le courage de prendre les fonds RTE/Enedis pour les suivre.

Jean-Yvon


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

Re: dégradation notable d'OSM

Julien Lepiller
Le 5 décembre 2019 21:43:51 GMT+01:00, [hidden email] a écrit :

>Le 04/12/2019 à 11:43, lenny.libre - [hidden email] a écrit :
>
>> une remarque concernant uniquement le nombre d'anomalies Osmose
>
>Tu vas dans le même sens que Philippe du coup je publie ma réponse
>initialement privée :
>
>Je n'ai pas dit qu'il était responsable des erreurs, j'ai juste parlé
>de
>métrique. Il ne faut pas faire dire à une métrique ce qu'elle ne veut
>pas dire. [j'ajoute : comme ici on est quand même essentiellement entre
>personnes expérimentées, ça me semblait évident que je ne prenais la
>métrique Osmose pas comme l'alpha et l'oméga mais comme une simple
>métrique, j'aurais dû être plus explicite]
>
>Simplement pour arriver à cela c'est qu'il n'en a rien à faire.
>
>J'ai 0 erreur de niveau 1, je me suis mangé plein d'erreurs de niveau 2
>du fait d'une modification massive des mairies (suppression du
>ref:INSEE) et je vais prendre mon bâton de pèlerin pour virer ces
>erreurs.
>
>Ce n'est pas parce qu'on ne les a pas créées qu'on ne peut profiter
>pour
>les corriger.
>
>N. B. : à l'opposé les pylônes transformateurs sont restés sans ligne
>autour parce que c'est difficile à suivre sur les photos et je n'ai pas
>le courage de prendre les fonds RTE/Enedis pour les suivre.
>
>Jean-Yvon

Je réagis sur les fonds rte. Il y en a qui sont utilisables pour l'édition ? Parce que le sujet m'intéresse et que je pourrais aider à compléter dans ce cas.

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

Lignes BT et HTA Was: Re: dégradation notable d'OSM

deuzeffe
Le 06/12/2019 à 00:21, Julien Lepiller a écrit :

Bonsoir,

>> N. B. : à l'opposé les pylônes transformateurs sont restés sans
>> ligne autour parce que c'est difficile à suivre sur les photos et
>> je n'ai pas le courage de prendre les fonds RTE/Enedis pour les
>> suivre.
>>
>> Jean-Yvon
>
> Je réagis sur les fonds rte. Il y en a qui sont utilisables pour
> l'édition ? Parce que le sujet m'intéresse et que je pourrais aider à
> compléter dans ce cas.

Pour ma part, depuis qu'osmose me signale gentiment plein de poteaux
sans ligne parce que j'y ai posé des transfo. (coucou François), comme
JY, bien envie d'utiliser dans un premier temps ce genre de truc :
https://data.enedis.fr/explore/dataset/reseau-bt/information/ (pleins
d'export possible qu'on doit pouvoir faire manger à JOSM, je suppose).

Mais si je n'intègre que les lignes sans mettre tous les poteaux qui
manquent (fainéante-mode), ça va pas l'faire, spa ?

--
deuzeffe, courageuse mais pas téméraire ou bien ?

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

Re: Lignes BT et HTA Was: Re: dégradation notable d'OSM

François Lacombe-2
Bonsoir Deuzeffe, JY, Julien,

Garder à l'esprit que pour l'instant Osmose ne fait pas de conflation linéaire
On a déjà suffisamment à faire avec le ponctuel de toutes façons :)

Le dim. 8 déc. 2019 à 22:18, deuzeffe <[hidden email]> a écrit :
Le 06/12/2019 à 00:21, Julien Lepiller a écrit :

> Je réagis sur les fonds rte. Il y en a qui sont utilisables pour
> l'édition ? Parce que le sujet m'intéresse et que je pourrais aider à
> compléter dans ce cas.

Osmose consomme déjà le fichier des pylônes.

Il est d'intérêt d'ajouter les lignes, avec la tension, operator=RTE et cables=* si possible.
 
Pour ma part, depuis qu'osmose me signale gentiment plein de poteaux
sans ligne parce que j'y ai posé des transfo. (coucou François), comme
JY, bien envie d'utiliser dans un premier temps ce genre de truc :
https://data.enedis.fr/explore/dataset/reseau-bt/information/ (pleins
d'export possible qu'on doit pouvoir faire manger à JOSM, je suppose).

La BT concerne les lignes entre le transformateur en haut du poteau et les maisons.
Il y a aussi ça pour les lignes alimentant ces transformateurs : https://data.enedis.fr/explore/dataset/reseau-hta/information/
Je vous recommande la HTA avant la BT. La BT est très capillaire, moins visible sur les vues aériennes donc plus difficilement maintenable.
 
Mais si je n'intègre que les lignes sans mettre tous les poteaux qui
manquent (fainéante-mode), ça va pas l'faire, spa ?

Ca ne posera pas de problème de topologie dans OSM, ni d'erreur dans Osmose.
Les poteaux sont par contre une information de grande valeur en ce moment, tout le monde se les arrache.
La légende raconte que Enedis n'a pas l'information dans son SIG. Ajouter les poteaux donne de la visibilité à OSM auprès d'une communauté de professionnels élargie en ce moment aux télécoms puisque les poteaux sont convoités pour la fibre aussi.
Lorsque c'est pertinent, ajouter operator=Enedis double la valeur du point, qualifier le matériau avec material=* la décuple.

Baladez-vous sur OpenInfraMap pour se rendre compte des efforts incroyables consentis par certains, comme dans le Jura

Certaines régies numérotent les supports, il faut passer auprès de quelques uns pour comprendre l'ordre et faire quelques séries

Pour info, il y a environ 16 millions de poteaux électriques en distribution, 13 millions de poteaux téléphoniques en France.
Ce qui laisse encore quelques soirées à occuper.

Bonne journée

François


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

Re: Lignes BT et HTA Was: Re: dégradation notable d'OSM

pyrog
In reply to this post by deuzeffe
Bonjour à toutes et à tous,

@deuzeffe
Mais si je n'intègre que les lignes sans mettre tous les poteaux qui manquent (fainéante-mode), ça va pas l'faire, spa ?

Avec iD, j’ai testé c’est l’enfer.

Avec JOSM, ça va plutôt bien 😀

Pour les longues lignes, tu peux prendre quelques poteaux au début puis appuyer sur A pour « verrouiller » l’axe du tracé.
Tu vas quelques km plus loin en « jouant » avec le zoom, tu places ton poteau d’ « arrivée » à une intersection, en bout de ligne…

Ensuite il « suffit » de rajouter les poteaux intermédiaires en « remontant » la ligne.
S pour désélectionner le dernier poteau. A pour ajouter, cliquer ensuite sur la ligne à l’endroit du poteau à ajouter.
Puis S, A, clique pour chaque nouveau poteau…

Ça peut paraitre laborieux, mais c’est plus facile que d’avancer poteau par poteau. Souvent on ne les distingue pas du premier coup d’oeil, puis il faut ensuite les réaligner.

Enfin, sélectionner la ligne, puis tous ses noeuds CMD+MAJ+N. Ajouter power=pole.

On peut zoomer en arrière et voir si les poteaux sont espacés régulièrement. Si non, soit on en a oublié, soit la ligne traverse quelque chose…

Notes :

Une ligne 20000V est principalement soutenue par des poteaux. Mais aux changement de directions, franchissement de vallées, rivières, au sommet d’une falaise… on trouve par fois des pylônes.
Ne pas hésiter à aller voir sur une autre orthophoto, les différentes « streetview » pour déterminer le type de support, où passe la ligne…
Les données Enedis sont parfois faussent.
Les lignes sont parfois visibles sur l’orthophoto, mais depuis, Enedis les a démontées et enfouies…

C’est bien aussi de mettre les remontées aéro-souterraines (RAS)

Dans le panneau des attributs, cliquer sur le modèle « Édifices/Électricité/Poteau électrique… », et cocher « Transition de localisation ».

Bon courage 😀
Yves


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

Re: Lignes BT et HTA Was: Re: dégradation notable d'OSM

cquest
Ou un grand coup de W suivi d'un ctrl-clic pour rajouter chaque noeuds de poteau... et on les modifie en masse à la fin ;)

Ou alors... on copie un modèle de poteau, puis coller à chaque emplacement et J pour faire passer la ligne déjà tracée par le noeud qu'on vient de créer.

Un système de macro pour JOSM existe-il ? L'inverse des raccourcis en quelque sorte, où on choisirait un raccourci clavier, puis on lui associerai une série d'actions.


Le lun. 9 déc. 2019 à 09:26, Yves P. <[hidden email]> a écrit :

Ensuite il « suffit » de rajouter les poteaux intermédiaires en « remontant » la ligne.
S pour désélectionner le dernier poteau. A pour ajouter, cliquer ensuite sur la ligne à l’endroit du poteau à ajouter.
Puis S, A, clique pour chaque nouveau poteau…



--
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: Lignes BT et HTA Was: Re: dégradation notable d'OSM

pyrog
@Christian

Ou un grand coup de W suivi d'un ctrl-clic pour rajouter chaque noeuds de poteau... et on les modifie en masse à la fin ;)
Le noeud ajouté n’est pas sur la ligne…

J’ai trouvé la doc suite à un message de janvier 2018 d’un certain Christian Q. 😀

Elle précise que cet outil est adapté pour des forêts, cours d’eau… où l’on a pas besoin de précision contrairement au « man_made ».

Par contre après un rapide essai, c’est vraiment bien pour améliorer un chemin dans la cambrousse, le contour d’une forêt.
J’ai bien galèré avant de connaitre ça.

J’adopte, merci Christian 😀

Ou alors... on copie un modèle de poteau, puis coller à chaque emplacement et J pour faire passer la ligne déjà tracée par le noeud qu'on vient de créer.
J’ai fait ça aussi, on perd l’alignement. Je l’utilise plus pour « poser » des poteaux incendie.

Un système de macro pour JOSM existe-il ? L'inverse des raccourcis en quelque sorte, où on choisirait un raccourci clavier, puis on lui associerai une série d’actions.
ça serait bien pour automatiser des modifications (sélection, correction…)

Yves

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