Jeu de données : Fichier consolidé des Bornes de Recharge pour Véhicules Électriques
Titre : Caractères spéciaux
Date : 2018-10-12 15:12

Bonjour,

Pourriez vous s'il vous plait, lors de la prochaine exportation, porter une attention particulière sur les caractères spéciaux qui sont codés pour exemple : Paris AÃ©roports pour Paris Aéroports.

Merci par avance

Bonjour,

Paris Aéroports me semble correctement encodé dans l'export du mois de Septembre. Pour info le fichier est encodé est utf-8.
Bonjour,
Vous avez raison Paris Aéroport était un mauvais exemple avec une importation en utf-8 cela fonctionne très bien.
Par contre pour all?e des peupliers 02120 GUISE le é de allée n'est pas reconnu idem pour Place du G?n?ral LECLERC 02000 LAON et aussi 0018 - Place du 29 Ao?t 1994. Plusieurs dizaines de champs présentent un problème où le é è ù â ne sont pas correctement repris.
Cordialement
Effectivement il subsiste des problèmes. Pour prendre le cas de l'allée des peupliers, la ligne provient du fichier https://www.data.gouv.fr/fr/datasets/useda-dirve02/#resource-e18a9301-f0ec-4c84-aec8-494c9d1fbc6d. Celui-ci déclare un encodage en UTF-8 au niveau du fichier mais les accents restent encodés de manière cryptique. Le fichier n'est pas non plus parfaitement lisible en ISO-8859-15. Il s'agirait donc d'un problème à la source.

Notre [script de consolidation](https://github.com/etalab/schema.data.gouv.fr/blob/master/irve/aggregration/irve.ipynb) fait de son mieux pour détecter le bon encodage, mais ce n'est malheureusement pas toujours possible en fonction de la qualité des données source. 
Merci pour votre réactivité. Vous avez raison le problème semble être à la source.
Bonjour, il me semble plus sérieux de la part d'un organisme d'état de s'assurer que les données sources soient conformes pour éviter ces multiples erreurs que l'on retrouve sur votre fichier qui ne peut donc prétendre à être certifié.

Bonjour, nous sommes en 2019 et le problème de reconnaissance de certains caractères comme ê é è etc...  persiste.
Cordialement
Bonjour Pascal, il semblerait que nos interlocuteurs fassent la sourde oreille...
Leur rôle se limite à rassembler dans un seul fichier les données IRVE sans les vérifier dans les détails. Cette manœuvre informatisé d'agrégation ne corrigera pas intrinsèquement les erreurs d'encodage des fichiers IRVE des aménageurs.
Cordialement
Bonjour, effectivement les problème d'encodage semblent se situer à la source. Nous effectuons aujourd'hui un traitement automatisé qui ne nous permet pas d'effectuer de contrôle de qualité sur les données. Le code source de ce script d'agrégation est disponible (voir dans la description), toute proposition d'amélioration est la bienvenue.

Nous sommes également engagés dans une initiative plus large de montée en qualité des données à la source, notamment à travers l'utilisation de schémas de données. A terme, nous espérons pouvoir proposer aux producteurs un reporting sur la qualité de leurs données, notamment sur le sujet IRVE, comme nous le faisons déjà par exemple sur les Bases Adresses Locales : https://adresse.data.gouv.fr/bases-locales/editeur.

Bien à vous.

Annotation : Formatage non respecté (Exploitabilité)