Development #16051
connecteur d'association adresse → secteur
0%
Description
Le connecteur contrib/nancypoll permet à partir de nom et numéro de rue de trouver un bureau de vote, le connecteur externe des encombrants 3M permet entre autres de trouver à partir de nom de rue et commune le prestataire en charge, etc. Le connecteur contrib/nancypoll se trouve maintenant également utilisé pour tout autre chose ailleurs.
Il me semble opportun de développer un connecteur générique assurant de la meilleure des manières ce boulot, plutôt que dupliquer/détourner.
Historique
Mis à jour par Serghei Mihai il y a environ 7 ans
Je vois aussi le besoin de pouvoir retourner ce "secteur" (ou autre chose) également à partir des coordonées géographiques.
Mis à jour par Frédéric Péters il y a environ 7 ans
Oui, mais le côté coordonnées géographiques, ça doit venir avec en backend un SIG gérant ça, alors qu'ici j'étais sur un système autonome.
Mis à jour par Serghei Mihai il y a environ 7 ans
Tout à fait d'accord. Mais je pense à des cas comme Villejuif, qui n'a pas de SIG, mais juste un fichier CSV avec toutes les adresses et leur coordonées géographiques pour determiner le secteur.
Mais bon, partons déjà ton idée initiale.
Mis à jour par Frédéric Péters il y a environ 7 ans
Tout à fait d'accord. Mais je pense à des cas comme Villejuif, qui n'a pas de SIG, mais juste un fichier CSV avec toutes les adresses et leur coordonées géographiques pour determiner le secteur.
Oui, c'est l'objet de ce ticket, visiblement pas clair du tout.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Comparaison :
- street_start_number, présent Nancy & Arles,
- street_end_number, pareil,
- street_side, I/P à Nancy, IMPAIR/PAIR à Arles,
- code, identifiant unique de rue à Arles, (n'existe pas dans le tableau Nancy)
- street_name à Nancy, type/libelle à Arles (ex: type: RUE, libelle: DE L'ABBE GREGOIRE)
- id, code, text, address, canton, à Nancy, informations sur le résultat (ici id/code/libellé/adresse du bureau de vote, + canton); zone à Arles, bref, les données de l'objet recherché (bureau de vote, zone, etc.)
(dans les données de Nancy, non exploitées, il y a aussi complement_debut/complement_fin, dans la pratique on ne trouve pas de rue où un numéro est partagé entre deux zones selon le complément).
J'en serais presque à dire que ça doit être fait sous forme de filtre spécialisé dans le connecteur tableur, façon opérateur de comparaison particulier, genre address_match(row, street=query.get('street), number=query.get('number'), side=query.get('number')). (en imaginant que dans "row" on a le contenu de la ligne du tableau, je n'ai pas regardé exactement comment ça marchait).
Mis à jour par Serghei Mihai il y a plus de 5 ans
Ça doit être possible déjà sans cet opérateur via une requete un peu plus complexe, genre:query.get('street') == street and query.get('number') <= end_number and query.get('number') => start_number
Mis à jour par Serghei Mihai il y a plus de 5 ans
Modifier la colonne "parité" pour y mettre "0" pour pair et "1" pour impair, et dans la requete faire par exemple: int(query.get('numero')) % 2 == int(numero)
Mis à jour par Thomas Noël il y a plus de 5 ans
Faire un connecteur générique avec un format de fichier qui ne soit pas tordu pour coller à une requête sur un CSV, ça simplifierait la vie des utilisateurs de ce connecteur, àmha.
Mis à jour par Serghei Mihai il y a plus de 5 ans
Si le format de fichier est bien établi, genre code, voie, numero_debut, numero_fin, parite, secteur on aurait besoin de 2 requetes: une pour avoir l'aide à la saisie pour les noms des voies et l'autre pour calculer le secteur, à ajouter au connecteur CSV et c'est tout.
Ou je rate quelque chose?
Mis à jour par Thomas Noël il y a plus de 5 ans
Serghei Mihai a écrit :
Si le format de fichier est bien établi, genre
code, voie, numero_debut, numero_fin, parite, secteuron aurait besoin de 2 requetes: une pour avoir l'aide à la saisie pour les noms des voies et l'autre pour calculer le secteur, à ajouter au connecteur CSV et c'est tout.
Ou je rate quelque chose?
Par exemple chercher une rue avec la gestion des accents (on pourrait certes avoir un outil qui nous aide en général sur les CSV pour ça, mais bon).
Aussi, à côté du secteur, faudrait taper un id ou slug de secteur.
Et comment on fait pour les bis/ter/etc que les gens vont vouloir taper.
Et les rues dans numéros.
Bref tout ça fait une tonne de choses à gérer dans la requête CSV, donc de la config à faire à chaque fois, et un jour on veut faire évoluer le truc il faut le faire sur 50 clients, pas terrible.
Et comme je m'imagine comme toujours des montagnes, peut-être que ton idée est la bonne, il faut juste aller au bout et écrire les requêtes.
Mis à jour par Frédéric Péters il y a plus de 5 ans
Je ne sais pas à quelle idée tu fais référence, mais parce qu'en effet gérer le détail avec uniquement les opérateurs de base, je n'y crois pas, je suggérerais l'ajout d'un "opérateur" address_match(). (mais c'était avant tout pour fournir une réponse rapide, alors que personne ne semblait vouloir partir sur un nouveau connecteur, qui pourrait être plus riche).