Open garaud opened 4 years ago
Grmbl, j'ai aussi des p'tits malheureux ¿
qui trainent dans certains champs.
Mea culpa, y'en a dans les données source aussi...
Pour le SIREN 212901102
, dans les résultats de recherche de https://www.sirene.fr/sirene/public/recherche j'ai des trucs comme LOTISSEMENT N¿2
J'ai l'impression que le script de geocodage geocode.py
, quand il est appelé avec plus de deux arguments à la ligne de commande, ce qui est le cas pour v2019/batch.sh
n'a pas le bon encoding à la lecture du fichier .csv https://github.com/cquest/geocodage-spd/blob/master/insee-sirene/geocode.py#L71
sirene_csv = csv.reader(open(sys.argv[1], 'r', encoding='iso8859-1'),
delimiter=',')
puisque les fichiers sont déjà (et enfin) publiés en utf-8.
Bonjour !
En prenant l'ensemble des fichiers csv par département présents sur http://data.cquest.org/geo_sirene/v2019/last/dep/, je me suis fait mordre par PostgreSQL avec un :
value too long for type character varying(26)
En effet, j'ai repris la définition des variables présentes dans les fichiers CSV https://www.sirene.fr/sirene/public/static/liste-variables en créant un table PostgreSQL avec la bonne longueur des différents champs. Par exemple :
distributionSpecialeEtablissement
: https://www.sirene.fr/sirene/public/variable/distributionSpecialeEtablissement type TEXTE longueur 26complementAdresseEtablissement
: https://www.sirene.fr/sirene/public/variable/complementAdresseEtablissement type TEXTE, longueur 38Puis en faisant un bête
COPY CSV TO
, j'ai eu des chaînes parfois plus longues. Deux exemples :Département 33,
POLYCLI BX NORD MED VASCULAIRE N°15A33
en tant que valeur de la variablecomplementAdresseEtablissement
qui a donc ici une longueur 39 pour 38 attendueDépartement 13,
CENTRAIX ET N°2 AV DU 8 MA
pour la valeur de la variabledistributionSpecialeEtablissement
Je me demande si dans le filtre ou le découpage d'entités par département, y'aura pas un soucis d'encodage qui se glisse.
Pour l'instant, j'ai augmenté la taille de mes champs.
Merci, Damien G.