Merge of Electra EV charging station : wrong email, new wikidata Q, avoid all in uppercase

[Marc-marc-marc]

for ex https://www.openstreetmap.org/node/10915648445 https://osmose.openstreetmap.fr/fr/issue/eeccc11d-36cf-3322-3792-b3d0e7f6cf5b item | 8411 class | 3

email is wrong : not the email about this osm item -> delete operator:email is wrong, not the good firm -> fix help@go-electra.com brand/operator/owner is in uppercase -> fix Electra I have create Q128592938 for brand/network, we may add brand:wikidata and network:wikidata and Q128597425 for owner:wikidata=Q128597425

initial ticket https://github.com/osm-fr/osmose-backend/issues/2296

[nlehuby]

Hello,

Si l'adresse mail est fausse, il faut le remonter au producteur des données (ça semble être ce jeu de données), il ne me semble pas souhaitable de maintenir ici un fichier avec ce type de corrections.

La correction sur la capitalisation des noms est ok et déployée (merci pour le fix).

Pour le reste, les modifs sont à faire dans l'analyse Osmose :

• les quelques tags wikidata gérés sont ajoutés dans le code de l'analyser
• l'ajout du tag email semble en effet peu justifié, d'autant que c'est un doublon de operator:email

[Marc-marc-marc]

je dois poster chez le fournisseur de donnée ou tu l'as fais ? en espérant une correction rapide de leur erreur j'ai fais le PR sur le git osmose

[nlehuby]

remontée vers le producteur effectuée, mais de réponse ou de correction. https://www.data.gouv.fr/fr/datasets/bornes-de-recharge-pour-vehicules-electriques-electra-irve/#/discussions

je ferme, on ne peux rien faire de plus sur ce sujet.

[Marc-marc-marc]

a quel endroit devrait-on intervenir pour éviter d'intégrer des données erroné dans osm ? on peux pas demander à chaque contributeur de découvrir ce genre d'erreur

[nlehuby]

Si on veut faire des corrections, ça serait ici (c'est le seul endroit où ça serait possible non ?)

La question est plutôt : veut-on vraiment corriger ça ? Pour la plupart des analyses Osmose il me semble qu'on prend la donnée telle qu'elle est donc je suis réticente à l'idée de complexifier le traitement pour ce genre d'erreurs.

Pour le contexte, ce script avait été créé pour le projet du mois de mars 2020. Mais depuis, le schéma de données évolue, les producteurs sont de plus en plus nombreux, les erreurs dans leurs données aussi malheureusement, et la moitié des gens n'y comprend rien à ces histoires de station/borne/pdc ... bref c'est assez chronophage d'assurer la maintenance de ce projet et personnellement, j'ai ni le temps ni la motivation de le faire de manière proactive aujourd'hui.

Donc si le jeu en vaut le chandelle en terme de volumétrie d'erreurs de ce type à corriger / si on trouve un process maintenable et dont l'utilisation pour les contributeurs ne nécessite pas de savoir coder / si qqn d'autre que moi est chaud pour s'en occuper / etc, alors pourquoi pas. Mais sinon, ça me semble acceptable / préférable de ne rien faire.

désolée si la décision semble un peu brutale :disappointed:

[Marc-marc-marc]

J'aimerai oui pour ma part qu'on supprime ce qu'on sait invalide de l'opendata (de la même manière que tu supprimes déjà les refs invalides). j'ai à coeur que osm soie meilleur que l'opendata sans compter sur le fait que tout le monde aie la science infuse pour connaitre tous les erreurs délecté "par paquet" (je parle pas de corriger que tel borne a un connecteur de + ou - mais d'erreur tel que mauvais non de domaine dans l'email de toutes les bornes d'un aménageur).

Dans ma vision, il nous faudrait un moyen assez simple pour remonter une erreur à un jeux de donnée (presque aussi facile que de signaler un faux positif avec osmose) ou bien on laisse l'opendata pourri, ce qui fait à terme un avantage compétitif pour les données osm :)

Je comprend très bien le côté chronophage, j'ai moi-même le sujet des bornes depuis avant le projet du mois c'est dire :) Peut-être que le projet devrait avoir + de mainteneur et/ou être forké dans un lieu plus neutre ou déplacé.

Je suis chaud pour m'en occuper en partie, tout ce qui est fait est bon à prendre :) Je cogite sur quoi faire et comment avec un autre contributeur (celui qui t'a fait quelques PR)

Ta décision n'a rien de brutale, elle est claire et c'est un avantage :)

[guiohm]

Je cogite donc également là-dessus. Et l'endroit idéal pour remonter/détecter les erreurs est délicat. Je suis relativement nouveau dans l'univers OSM/Osmose et à première vue, j'avais l'envie de concentrer la logique du côté Osmose. Puis en regardant ici, j'ai vu des choses améliorables.

Maintenant, je commence à me demander s'il ne serait pas nécessaire d'avoir une BDD avant Osmose dans laquelle stocker/flagger les problèmes ou vérifications par fournisseur (ou autre critère). Étant donné que du jour au lendemain, ils peuvent changer tout leur jeu de donnée. Et je remarque qu'il y aurait des règles de regroupement/conversion plus ou moins complexes à maintenir par fournisseur.

Et effectivement, ce serait bien d'avoir un tableau de bord pour consulter/visualiser les fournisseurs en erreur ou les nouveaux fournisseurs non validés.

Donc ça commence à sortir du cadre de ce repo (ref-EU-EVSE). Et je ne sais pas trop si c'est quelque chose qui peut s'intégrer dans Osmose.

Je suis chaud aussi pour mettre la main à la pâte. Je n'ai pas encore de quoi créer un nouveau projet, ça fait longtemps que je n'ai pas fait de frontend, et je dois encore prendre du temps pour analyser l'ampleur du problème.

[nlehuby]

J'aimerai oui pour ma part qu'on supprime ce qu'on sait invalide de l'opendata (de la même manière que tu supprimes déjà les refs invalides). j'ai à coeur que osm soie meilleur que l'opendata sans compter sur le fait que tout le monde aie la science infuse pour connaitre tous les erreurs délecté "par paquet" (je parle pas de corriger que tel borne a un connecteur de + ou - mais d'erreur tel que mauvais non de domaine dans l'email de toutes les bornes d'un aménageur).

J'avoue. Tu m'as convaincue.

J'ai étendu le processus existant de corrections de l'orthographe des réseaux et opérateurs pour surcharger n'importe quel champ open data. L'email d'Electra est donc maintenant celui que tu as fourni ici.

Pour info, on a

• 3543 stations avec aménageur corrigé
• 2826 stations avec enseigne corrigé
• 12230 stations avec opérateur corrigé

[Marc-marc-marc]

et c'est même codé ? génial !