Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Par sujet Philippe Verdy
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  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 

Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Par sujet Philippe Verdy
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,  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 - david.croc...@free.fr a écrit :
>
> Bonjour
>
> Le 29/11/2019 à 21:46, osm.sanspourr...@spamgourmet.com 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
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list

Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Par sujet osm . sanspourriel

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 - david.croc...@free.fr a écrit :

Bonjour

Le 29/11/2019 à 21:46, osm.sanspourr...@spamgourmet.com 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
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] OSM et accessibilité: CDD et projets

2019-12-03 Par sujet Frédéric Rodrigo

Bonjour.

C'est une belle initiative que de vouloir investir sur l'amélioration 
des outils de contributions.


Je me permets toutes fois de lever une alerte sur une piste qui pourrait 
être envisagée à la vue de l'offre.


Il y a des déjà beaucoup de projets de fork d'iD mort nées dédiés à des 
thématiques. Le travail est à chaque fois perdu.


My 2cents.
Frédéric.


Le 03/12/2019 à 14:53, Jean-Marie Favreau a écrit :

Bonjour,

Depuis deux ans maintenant, nous menons à Clermont-Ferrand une activité de
recherche autour de l'accessibilité spatiale pour les déficients visuels. On
utilise bien évidemment OpenStreetMap comme source d'information géographique.

Nos activités en cours sont présentées sur le site Compas :
https://compas.limos.fr/

En particulier, nous démarrons en janvier 2020 un projet ANR qui durera sur 4
ans, en collaboration avec un laboratoire de l'IGN, l'IRIT, et FeelObject. Le
projet s'appelle ACTIVmap. Plus d'information à venir sur le site du projet,
où nous publierons progressivement les offres de stage, puis de thèses :
http://activmap.limos.fr/

Nous venons également d'obtenir un budget pour recruter un développeur web sur
6 mois, afin d'améliorer les outils de contribution sur les questions
d'accessibilité :
https://compas.limos.fr/OD4M/offre-emploi/
N'hésitez pas à diffuser l'appel autour de vous, le poste est à Clermont-
Ferrand.

Nous serons bien sûr présents pour présenter nos travaux à State of the map
France, si l'événement est planifié comme les autres années.

Au plaisir d'échanger sur ces projets !




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


[OSM-talk-fr] OSM et accessibilité: CDD et projets

2019-12-03 Par sujet Jean-Marie Favreau
Bonjour,

Depuis deux ans maintenant, nous menons à Clermont-Ferrand une activité de 
recherche autour de l'accessibilité spatiale pour les déficients visuels. On 
utilise bien évidemment OpenStreetMap comme source d'information géographique.

Nos activités en cours sont présentées sur le site Compas :
https://compas.limos.fr/

En particulier, nous démarrons en janvier 2020 un projet ANR qui durera sur 4 
ans, en collaboration avec un laboratoire de l'IGN, l'IRIT, et FeelObject. Le 
projet s'appelle ACTIVmap. Plus d'information à venir sur le site du projet, 
où nous publierons progressivement les offres de stage, puis de thèses :
http://activmap.limos.fr/

Nous venons également d'obtenir un budget pour recruter un développeur web sur 
6 mois, afin d'améliorer les outils de contribution sur les questions 
d'accessibilité :
https://compas.limos.fr/OD4M/offre-emploi/
N'hésitez pas à diffuser l'appel autour de vous, le poste est à Clermont-
Ferrand.

Nous serons bien sûr présents pour présenter nos travaux à State of the map 
France, si l'événement est planifié comme les autres années.

Au plaisir d'échanger sur ces projets !

-- 
Jean-Marie Favreau - http://jmfavreau.info



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


[OSM-talk-fr] Quand Waze perturbe fortement le trafic

2019-12-03 Par sujet Xavier Cremaschi

https://www.francetvinfo.fr/elections/municipales/mon-maire/c-etait-devenu-apocalyptique-a-meudon-le-maire-a-debarrasse-une-rue-des-embouteillages-provoques-par-l-application-waze_3712737.html

Une histoire intéressante et assez terrible, sur comment des rues se 
retrouvent noyer sous le trafic routier dès lors qu'une appli GPS les 
désigne comme nouveau meilleur chemin...



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


Re: [OSM-talk-fr] Utilisation de données OSM sur france-cadastre.fr

2019-12-03 Par sujet Georges Dutreix via Talk-fr
Bonjour, 

On devine même un filigrane copyright "openmaptiles" sur les cartes
france-cadastre.fr. Mais il n'est pas fait pour sauter aux yeux. 

C'est peut-être à eux d'ajouter cette attribution, et pas uniquement une
référence à leaflet. 

Georges 

Le 2019-12-02 15:30, Frédéric Rodrigo a écrit :

> Je confirme que c'est bien des données OSM.
> Le fond OSM superposé est un rendu rester d'un style vectoriel 
> klokantech-basic basé sur OpenMapTiles : https://openmaptiles.org/styles/
> 
> Frédéric.
> 
> Le 02/12/2019 à 15:09, rainerU a écrit : 
> 
>> Bonjour,
>> 
>> J'ai contacté une commune (Arles-sur Tech, INSEE 66009) pour lever un doute 
>> sur le nom officiel de quelques rues. Dans leur réponse, il m'ont renvoyé 
>> vers un plan cadastral interactif sur leur site [1 [1]]. Ce plan est édité 
>> par FranceCadastre [2 [2]] et composé d'un calque cadastre superposé d'un 
>> calque voirie. Je soupçonne que le calque voirie est basé sur les données 
>> OSM car on y retrouve des erreurs d'orthographe présents dans OSM, par 
>> exemple "Domaine de la Batille" au lieu de "Domaine de la Batllie" sur ce 
>> chemin [3 [3]]. Les données OSM semblent être au niveau d'avant octobre 2017 
>> car des voies ajoutés à cette date ne figurent pas sur la carte, par exemple 
>> ce chemin [4 [4]].
>> 
>> Cette carte devrait donc porter une attribution OSM ce qui n'est pas le cas 
>> ni sur la carte ni ailleurs sur le site. Est-ce que cela vaut la peine de 
>> les contacter pour leur demander d'ajouter une attribution ? J'hésite car je 
>> l'ai fait récemment pour deux autres sites [5 [5]] [6 [6]], mais sans aucune 
>> réaction.
>> 
>> Rainer
>> 
>> [1] http://www.ville-arles-sur-tech.fr/plan-cadastre/
>> [2] https://france-cadastre.fr/cadastre/arles-sur-tech
>> [3] https://www.openstreetmap.org/way/449199916
>> [4] https://www.openstreetmap.org/way/534312613
>> [5] https://www.mairie-perpignan.fr/fr/carte/culture/patrimoine/monuments
>> [6] http://www.oph-perpignan.com/
>> 
>> ___
>> 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

 

Links:
--
[1] http://www.ville-arles-sur-tech.fr/plan-cadastre/
[2] https://france-cadastre.fr/cadastre/arles-sur-tech
[3] https://www.openstreetmap.org/way/449199916
[4] https://www.openstreetmap.org/way/534312613
[5]
https://www.mairie-perpignan.fr/fr/carte/culture/patrimoine/monuments
[6] http://www.oph-perpignan.com/___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Par sujet Florimond Berthoux
+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
 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, osm.sanspourr...@spamgourmet.com 
> > [osm.sanspourr...@spamgourmet.com] 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
> >> .
> > 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
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Florimond Berthoux

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


Re: [OSM-talk-fr] "Vandalisme" à Gravelines de la part de l'OT

2019-12-03 Par sujet Yves P.
@Vincent
> heureusement qu'il y a les guillemets :) à vandalisme, ne rentrons pas dans 
> cette représentation lorsque c'est des gens qui sont maladroits, ne 
> connaissent pas, …
Je partage tes remarques, d’où les guillemets 

> Je bosse un peu avec le tourisme et franchement ceux sont des gens qui 
> connaissent super bien le territoire, atout non négligeable pour tenir les 
> données à jour, car ils en ont besoin à chaque saison !!!
Ils ont juste besoin de contributeurs « locaux » pour les guider.

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


Re: [OSM-talk-fr] "Vandalisme" à Gravelines de la part de l'OT

2019-12-03 Par sujet Vincent Bergeot

Bonjour,
heureusement qu'il y a les guillemets :) à vandalisme, ne rentrons pas 
dans cette représentation lorsque c'est des gens qui sont maladroits, ne 
connaissent pas, ...


Déjà le commentaire laisse supposer que quelqu'un valide derrière. 
Beaucoup d'ajout de tag sur le point adresse, idem ignorance je pense !


et des ajouts d'attributs intéressants aussi !

Je bosse un peu avec le tourisme et franchement ceux sont des gens qui 
connaissent super bien le territoire, atout non négligeable pour tenir 
les données à jour, car ils en ont besoin à chaque saison !!!


à plus




Le 03/12/2019 à 07:51, Yves P. a écrit :

Bonjour,

Un point géodésique  à 
été modifié avec le sympathique commentaire :
/"Bonjour veuillez prendre en compte les modifications apportées sur 
la commune de Gravelines. Clémence Office de Tourisme de Gravelines »/


Je fais un reverse pour celui-ci en mettant à jour le phare qui 
intéresse l’OT .


Il y a 12 autres modifications du même genre : 
https://www.openstreetmap.org/user/Clem%20OT%20Gravelines/history 


Je laisse les locaux regarder ça de plus près.

—
Yves

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



--
Vincent Bergeot

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