Le géocodage d'un CSV de moins de 5 lignes échoue

[fredericbonifas]

Le géocodage d'un fichier CSV contenant 5 lignes (header compris) ou moins échoue : l'encodage détecté semble faux, et les résultats de recherche sont faux.

Voici un exemple de fichier qui échoue (les adresses renvoyées sont à Arles au lieu de Lyon)

housenumber,addr,,city
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon

En ajoutant une ligne de plus, l'encodage est bien détecté et les adresses renvoyées sont bien à Lyon.

housenumber,addr,,city
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon
11,Rue de la République,,Lyon

Je rencontre également ce problème avec curl sur https://api-adresse.data.gouv.fr/search/csv/

[jdesboeufs]

Bonjour,

Quelle indication avez-vous concernant l’encodage ?

[fredericbonifas]

Voici 2 captures d'écran avec les deux fichiers à 5 et 6 lignes:

Les deux fichiers d'entrée sont bien en UTF-8 tous les deux (vérifié avec file -i fichier.csv)

[garaud]

Bonjour !

Ça me rappelle un soucis que j'avais eu avec la validation de schéma pour les fichiers CSV des Installation de Recharge de Véhicules Électriques (IRVE). https://github.com/etalab/schema-irve/issues/2

C'est le paquet chardet via tabulator-py qui n'arrive pas bien à inférer l'encodage avec si peu de lignes. Alors qu'un file exemple.csv fonctionne souvent très bien.

Voir https://github.com/etalab/schema-irve/issues/2#issuecomment-507624322 et les commentaires suivants.

[JMPivette]

Je confirme le problème qui apparaît quand le fichier csv a moins de 5 lignes ET contient des caractères non-ASCII

L'exemple de départ avec "Republique" à la place de "République" renvoie le bon résultat avec le bon encodage.

[jdesboeufs]

Le problème n'est plus d'actualité. S'il se produit de nouveau merci de contacter adresse@data.gouv.fr ou d'ouvrir une nouvelle issue sur https://github.com/livingdata-co/addok-server