A nous d'exiger qu'au moment de la finalisation des listes électorales et à l'occasion de l'impression des cartes d'électeurs qui vont être envoyées chaque année en début d'année, un fichier public soit produit contenant la lsite exhaustive des bureaux avec leur numéro et leur adresse. On ne demande pas forcément que ce soit complété par une géolocalisation. Mais il serait souhaitable qu'en plus du numéro (local) de bureau, on dispose d'une clé unique de fomat stable (sans doute le code INSEE de la commune sur 5 chiffres, et un format standard du numéro de bureau, sans doute sur 4 chiffres et/ou lettres sans autre séparateur "exotique"), afin de faciliter les rapprochements. On n'exige pas immédiatement la mise à disposition du découpage territorial des communes découpées sur plusieurs bureaux. Certes des tas de communes ont produit de tels découpages sur leurs GIS, mais là on devrait les pousser toutes à les publier en OpenData. Beaucoup le font, mais pour des tas d'autres elles ne sont pas prêtes car elles gèrent ça plus ou moins manuellement dans les communes plus petites qui n'ont pas l'assistance technique de leur communauté de communes pour le faire (dans ce cas il n'est pas garanti et il me semble même pas obligatoire que le découpage soit exact, et que les listes électorales sont revues en dernier lieu pour inclure les derniers inscrits sur une seule et même liste d'un seul bureau, le moins "peuplé", pour éviter de la paperasserie administrative, quitte ensuite à revoir la distribution en fin d'année pour l'année suivante.
Mais ce travail de redécoupage et d'équilibrage des listes est quelque chose de lourd pour les secrétaires de mairies qui ne vont pas passer une temps infini à vérifier chaque adresse de résidence de centaines d'inscrits pour voir si une rue devrait passer ou pas dans un bureau voisin. Tant que ces listes respectent certains quotas, des écarts de +/- 20% sont déjà admis par le conseil constitutionnel pour toutes les circonscriptions électorales, tout en gardant une moyenne des listes par bureau voisine des 1000 inscrits (donc entre 800 et 1200 électeurs, les communes ne sont pas incitées à revoir leur découpage: elles ne le font que si le total des inscrits de la commune les oblige à supprimer ou ajouter un bureau, mais comme c'est long à faire c'est préparé à l'avance sur la base des inscrits de l'année précédente, sachant que les nombres ne bougeront pas beaucoup même si les inscrits changent l'année suivante et un des deux seuils d'équilibrage pourraient donc être franchi malgré tout, rectifié seulement l'année suivante, si le préfet ou une décision de justice les y oblige). C'est le résultat de ce travail qui devrait être publié en open data, mais il ne se fait pas partout avec un GIS ou s'il existe les communes n'ont pas toutes la compétence technique pour gérer les formats ou même gérer un catalogue de données en ligne: ce qu'elles veulent c'est juste des listes finalisées et exploitables avec les procédures et formulaires électoraux obligatoires (et au pire c'est un service de la préfecture qui fera le travail de répartition et d'équilibrage lors de la finalisation et la validation des listes qui s'imposent ensuite aux communes concernées. En revanche là où l'open data manque, à nous de discuter et faire le lien avec les communautés de communes ou d'agglomération qui ont déjà des solutions facilement transposables: les communautés de communes devraient toutes avoir leur GIS même si les petites communes n'en ont pas un directement car elles n'ont pas la capacité de financer une équipe de maintenance à l'année ni de former les personnels communaux pour changer de méthodes de travail. Et au delà de nous il est intéressant de mobiliser l'association des maires de France pour qu'ils échangent davantage sur les moyens techniques ouverts (on ne doit pas les obliger à travailler juste avec nous et nos solutions préférées, mais c'est à nous de nous adapter à leur choix et limitations techniques et à leur contraintes de calendrier). Ces bureaux électoraux devant aussi servir à toutes les élections publiques, concernent tout autant les départements, régions et les élections nationales, la coopération peut se faire et devrait se faire sur plusieurs niveaux (sans pour autant que les solutions retenues au plan national pour les élections directes s'imposent partout: à nous d'aider à construire les passerelles d'interopérabilité si nécessaire entre solutions différentes). A terme cela devrait permettre de disposer de plus de données ouvertes et d'une mise à jour plus facile et plus rapide, tout en donnant plus de transparence et plus de temps pour les recours légaux en cas de litige: ces listes doivent être impeccables et sûres, et ce n'est pas qu'une question de "simples" formulaires administratifs : on en a trop en France, cela n'apporte pas plus de sécurité ni de transparence si cela ne fait qu'ajouter des sources d'erreurs, des retards de mise en oeuvre, et finalement moins de contrôle effectif à priori et des décisions à posteriori qui sont souvent dommageables à l'image de la démocratie et à la confiance des électeurs qui sont en droit d'exiger la transparence et l'efficacité, et éviter alors des situations ubuesques (qui ont encore eu lieu cette année, avec par exemple la validation d'une candidature présidentielle bien connue qui pourtant violait les règles sensées s'appliquer en terme d'inscription effective du candidat sur les listes électorales, une inscription faite à posteriori au delà des délais légaux et qui aurait été refusée à un autre électeur qui s'y est pris trop tard: le conseil constitutionnel aurait du être intraitable pour ce candidat quel qu'était le nombre de ses soutiens). Le 14 mai 2017 à 09:52, Christian Quest <cqu...@openstreetmap.fr> a écrit : > polling_station:ref=* tout seul permet d'indiquer le numéro du bureau de > vote (et donc aussi qu'il y a un bureau de vote), si il n'y a pas d'autres > amenity (cas rare car les bureaux de vote sont situés souvent dans les > mairies, salle des fêtes, école qui sont des amenity=*), j'ajouterai un > amenity=polling_station sinon, rien de plus. > > KISS > > Pour l'année, c'est plus un problème de date de mise à jour que de > millésimage à ce qu'il me semble. > > Le 13 mai 2017 à 07:40, PanierAvide <panierav...@riseup.net> a écrit : > >> Mea culpa, j'ai dû mal comprendre. Du coup quels sont les tags en >> pratique pour les bureaux de vote ? Vu qu'il semble il y avoir plusieurs >> méthodes : >> - amenity=polling_station + ref=* >> - polling_station=yes + polling_station:ref=* >> - amenity=polling_station + polling_station=<année> >> >> Admettons que l'on voudrait créer un thème MapContrib pour ajouter ces >> points de bureaux de vote (pour simplifier la tâche), il faut au minimum >> s'accorder sur les tags. >> >> Cordialement, >> >> Adrien. >> > > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
