PTB administration des élections — PVDA administratie verkiezingen

Roos Eligius, 02 5040 145 (privé 056 71 94 87, 0487 16 94 74)administrationelections@ptb.be

Dominique Meeùs, 02 5040 155 (privé 0473 61 31 75)alias administratieverkiezingen@pvda.be

Dernière modification le

Terug naar startpagina centralisatieRetour à la page de départ de la centralisation


Documentation du dispositif provisoire de centralisation en ligne en MySQL des données relatives aux candidats et de communication de documents

À faire

Table des matières

Données des candidats

Dans ce système provisoire de niveau 2, les données sont en ligne dans une base de données MySQL dans mon domaine personnel.

Outils utilisés

phpMyAdmin

phpMyAdmin admet des importations en CSV. J’ai pu ainsi préparer en OOo en les améliorant mes données des années antérieures et les importer dans la table perso.

Je n’ai en fait pratiquement pas de code qui intervient dans la base de données. La plupart des requêtes (sinon toutes) sont des consultations. Les données sont introduites « à la main » dans phpMyAdmin, éventuellement en important un fichier CSV.

Les CSV attendus sont en point-virgule (mais on peut faire un autre choix dans le dialogue d’importation de phpMyAdmin) et avec la longueur exacte. Pour perso, cela veut dire qu’il faut mettre quelque chose, même bidon, en profiel (colonne Z si on prépare en tableur). Il faut un champ ID mais le laisser vide. Pour phpMyAdmin, c’est append par défaut. Pour remplacer les données existantes, il faudrait cocher une case.

Publier la structure à partir de phpMyAdmin par Thunderbird

La requête MySQL SHOW FULL FIELDS FROM perso donne la structure de la table, mais avec des détails inutiles pour mon public. Mais sans FULL, je n’ai pas les commentaires qui sont précisément ce que je veux donner. La requête MySQL SHOW CREATE TABLE perso donne la requête qui recréerait la table. C’est donc absolument complet mais peu utilisable comme présentation.

phpMyAdmin propose un format imprimable de la structure d’une table, mais la source HTML de cette page imprimable est invisible parce que la page de phpMyAdmin est en frames. Firebug permet de remonter au contenu des frames, mais ici c’est du JavaScript qui exécute des requêtes MySQL. Ce qu’on peut faire, c’est copier le contenu de la page imprimable et le coller dans un nouveau message HTML de Thunderbird. Sélectionner tout (Ctrl+A) et Insérer/HTML… pour voir la source. Sélectionner tout et copier (Ctrl+A, Ctrl+C) et coller dans Bluefish. Le résultat est parfait.

OpenOffice.org Base

Il y a une connexion « native » OOo Base avec MySQL. Je l’ai essayée et ça fonctionne, mais la connexion se coupe très rapidement et c’est donc inutilisable en pratique, tant que ce problème n’est pas résolu. Mon idée était de travailler de manière hybride, comme dans ma méthode de niveau 1, en OOo Base, mais avec une base de données MySQL en ligne au lieu de la base HSQL intégrée. Cette solution semble exclue. Ce n’est pas une perte (au contraire, cela m’oblige à rompre plus radicalement avec la méthode de niveau 1) puisque je peux gérer la base de données avec phpMyAdmin et publier les résultats en PHP.

phpMyAdmin propose divers format d’exportation de tables, dont CSV et OOo Calc. Il est donc possible d’utiliser MySQL comme base de données de départ et, pour ce qui ne peut encore être fait automatiquement, de travailler en OOo selon les méthodes inspirées de 2009 telles qu’elles sont formalisées dans Documentation du dispositif provisoire de centralisation en ligne des données relatives aux candidats et de communication de documents. Il est donc possible de travailler d’emblée dans ce système en ligne et de l’automatiser pogressivement.

Il me semble cependant que la chaîne phpMyAdmin, CSV, OOo Calc, OOo Base, OOo Writer ne doit plus servir que pour les actes de présentation et les tableaux de signatures d’acceptation si on veut une présentation soignée. Une chaîne plus courte serait d’afficher par PHP du contenu à copier-coller dans le document. Pour l’acte, par exemple, on pourrait créer des alinéas Candidat no 1, et cetera qu’on aurait qu’à coller et mettre en forme par un style approprié.

Table perso des données de base

Dans la table perso, je retiens les champs ID, dateimport, provparti, prenombul, nombul, masculin, prenoms, nom, paysnat, numnat, datenaiss, profession, beroep, ruedomi, numdomi, btedomi, cpdomi, commdomi, email, phone, gsm, plus, professionalt, beroepalt, profil, profiel. Détails sur ces champs, voir annexe 1.

ID

Je découvre, parce que l’importation d’un CSV bloque à 127, que TINYINT(3) ne va pas jusque 999, mais de − 127 à 127, ou de 1 à 255 non signé. Pour nos besoins, il faut au moins SMALLINT(3).

Majuscules et minuscules

Majuscules seulement aux noms propres des candidats, des localités et des rues. Donc minuscule aux professions et à des mots tels que « rue », « avenue »…

Format du genre

Je découvre que dans MySQL un champ BOOLEAN est un TINYINT (1). Le masculin est vrai (= 1) pour les hommes et faux (= 0) pour les femmes. Sera traduit dans une vue dans les F ou M du Pbis (annexe 6). Peut être traduit en homme, femme, man, vrouw, monsieur, madame, mevrouw, mijnheer dans d’autres contextes.

Pays de nationalité

Les élections fédérales, régionales et communales imposent des conditions de nationalité différente. J’indique ici le code pays en ISO 3166-1 alpha-2 modifié européen (EL pour la Grèce et UK pour le Royaume-Uni).

Attention que ce champ n’a rien à voir ni avec l’adresse, ni avec le pays d’origine.

Format du numéro national

Le Pbis (annexe 6) demande une chaîne de onze chiffres sans blancs ni ponctuations et c’est sur cette forme aussi que j’ai écrit ma formule de contrôle. Il n’y a cependant pas intérêt à en faire un entier puisque les calculs de contrôle ne portent que sur des sous-chaînes.

J’adopte donc ce format dans la table. Une requête de nettoyage est donnée en annexe 2, mais il vaut mieux nettoyer le numéro avant de l’introduire.

Format de dates

MySQL attend en importation le format AAAA-MM-JJ, comme 1943-04-28 pour ma naissance (ISO 8601). C’est dans les vues ou requêtes qu’il faudra éventuellement en changer avec la fonction MySQL DATE_FORMAT(), comme pour le Pbis.

Format des numéros de téléphone

Il est préférable de séparer des groupes de chiffres, surtout le préfixe, pour la lisibilité. On sépare seulement par des blancs. Il est difficile de positionner automatiquement les blancs de manière correcte, il faut les ajouter à la main, mais on peut remplacer automatiquement d’autres ponctuations indésirées comme les barres et les points. Une requête de nettoyage est donnée en annexe 3, mais il vaut mieux nettoyer les numéros avant de les introduire.

Données de profession et de profil

Le champ profession est destiné à l’acte de présentation. Dans des listes destinées à la presse, on utilise parfois des professions alternatives plus valorisantes, comme délégué ou président du PTB au lieu d’ouvrier ou d’employé (exemple, Solidaire no 23, p. 12 et 13, http://www.ptb.be/nieuws/artikel/les-listes-choisissez-le-ptb-partout-en-belgique.html) ; c’est le champ professionalt. Dans certaines circonstances, on met dans Solidaire une description d’une phrase (exemple, « 80 syndicalistes sur les listes PTB+ », no 22, p. 10 et 11, http://www.pvda.be/nieuws/artikel/vakbondsmilitanten-op-de-lijsten-van-pvda.html) ; c’est le champ profil. On ne met pas dans profil un article complet, même court (exemple, Solidaire no 23, p. 10 et 11)  ; ça c’est à convenir directement avec la rédaction. On peut avoir besoin de ça dans les deux langues, d’où les beroep, altberoep et profiel.

On devrait laisser vides la profession alternative et le profil si on n’a rien de spécifique à y mettre et y répéter automatiquement par défaut la valeur de profession dans les affichages.

De même, il vaudrait mieux laisser la traduction vide si on n’en a pas et y répéter automatiquement par défaut l’autre langue si elle existe.

Adresse de contact alternative

Non repris. C’est intéressant, mais assez minoritaire. Je propose que les provinces tirent leur plan avec ça. C’est surtout elles qui ont un éventuel problème de contact. Par contre, je maintiens bien sûr l’e-mail et les numéros de téléphone. J’ai une hésitation sur un numéro de téléphone de travail. Il me semble que je ne vais pas téléphoner au travail à quelqu’un que je ne connais pas bien.

Absence prévue

Non repris. Rare et circonstanciel. Je propose que les provinces tirent leur plan avec ça. C’est elles qui ont un problème de contact pour les signatures, etc.

Publication des données de base en html

Les tables sont affichées automatiquement par le script list.php, en table fixe (action=table) ou en table déroulante (action=scroll). On obtient la table perso en demandant list.php?requ=all&table=perso&action=scroll

Le script list.php, ses requêtes et ses actions sont documentés en annexe 4.

Communication des données par les provinces

Elles consultent les données et m’envoient les modifications ou additions. Je leur propose le modèle de tableur append.ots.

Autres vues des données

Des tas de lectures partielles peuvent se révéler intéressantes. Pour la centralisation des données, les provinces doivent voir ce qui manque, donc elles doivent tout voir et pour cela la consultation de perso est suffisante et moins que ça ne suffirait pas. On pourrait cependant imaginer de sélectionner les personnes par province. En fait les données qui comptent ce sont celles des candidats dans les listes et c’est avec les requêtes travail, werk qu’on peut le mieux vérifier si elles sont correctes et complètes.

Le script list.php permet aussi d’afficher les données d’une seule personne (requ=all&ID=…), pour envoyer à la personne et lui demander de vérifier.

Constitution des listes

Tables de composition

Les tables de composition de liste

Drapeau liste provisoire/définitive

J’avais pensé comme drapeau d’avertissement négatif la longue tartine : « Attention, cette liste est provisoire. Ne pas utiliser sans avis de la direction provinciale ou nationale compétente. / Pas op, dit is nog een voorlopige lijst. Niet gebruiken zonder advies van de bevoegde provinciale of nationale leiding. » C’était pas mal dit, mais le Comment d’une table est limité à 60 caractères. J’utilise donc pour le feu rouge ALTER TABLE fedcompCirc COMMENT = 'Red flag: Attention! Liste provisoire — Voorlopige lijst!'; et pour le feu vert ALTER TABLE fedcompCirc COMMENT = 'Green flag: Liste définitive — Definitieve lijst ***OK***'; (58 caractères chacun) et j’affiche ce Comment dans toutes les requêtes. Cela apparaît à la fin de SHOW CREATE TABLE fedcompCirc;, dont on pourrait l’extraire, mais je trouve plus simple de le prendre champ Comment de SHOW TABLE STATUS LIKE 'fedcompCirc';.

Format effectif/suppléant

Plutôt qu’un champ booléen comme le genre, je choisis de mettre en texte directement les E et S demandés par le Pbis. Est traduit dans certaines publications.

Déposants des listes et témoins

Les déposants et les témoins sont mentionnés dans l’acte. On doit donc les avoir aussi de manière centrale. J’ajoute des lignes Y1, Y2, Y3 pour les déposants et Z1, Z2 pour les témoins. (Ce que je n’aurais pas pu faire si j’avais traité E et S en booléen.)

 Communication des listes par les provinces

Elles consultent les données et m’envoient les modifications ou additions. Leur proposer un modèle de tableur

Elles ont une confirmation que j’ai bien reçu la liste et que les ID sont exacts et bien placés en consultant les divers documents de sortie ci-dessous.

Actes et autres documents

Ceci est maintenant bien développé. Si quelque chose manquait, on pourrait exporter la table perso en OOo Calc et s’y connecter par OOo Base pour travailler selon le système provisoire de niveau 1 documenté dans Documentation du dispositif provisoire de centralisation en ligne des données relatives aux candidats et de communication de documents. Le niveau 1 pourrait donc servir à retomber sur ses pattes en cas d’accident.

Listes à consulter

Avec OOo Base, j’envisageais de créer des vues plutôt que des requêtes. Après réflexion, et en MySQL avec phpMyAdmin, c’est un plus gros travail et plus de rigidité (moins facile à éditer que du code PHP et MySQL dans mon Bluefish) me semble-t-il que d’écrire la requête dans le script PHP. De plus c’est ce que les philosophes appelleraient de l’inflation ontologique (je me comprends) au niveau de la base données, même si les vues ne sont que des tables virtuelles, parce que le script list.php (ci-après) se démultiplie par ses requêtes et actions, tandis qu’il faudrait autant de vues séparées.

J’ai un script générique list.php qui attend dans la requête http les paramètres requ, circ et action. Le requ appelle un fichier de requête à inclure, par exemple requ=travail commande l’inclusion de la requête travail.query. Par défaut, la table est perso. Cela peut être modifié par le paramètre circ qui appelle la circonscription. Par exemple circ=Lux fera porter la requête sur la table fedcompLux.

Remarque : Des circonscriptions peuvent porter le même nom dans des élections différentes. Dans ce premier essai pensé pour des fédérales, le préfixe fed est fixe. À l’avenir, il faudra une identification plus fine que circ. La mention médiane comp dans fedcompLux est parfaitement inutile puisqu’il n’y a et ne devrait probablement jamais y avoir, en dehors de perso, d’autres tables que les tables de composition. J’ai mis comp à un moment où je pensais avoir des vues, plutôt que des requêtes.

L’action décrit la présentation à l’écran, table HTML (table), éventuellement déroulante (scroll) ou texte CSV (CSV).

La requête all est une requête brute (SELECT * FROM {$table}) destinée surtout à la table perso. C’est la seule qui permet de sélectionner une personne particulière par le paramètre ID dans la requête http. Dans ce dernier cas, on peut recourir à l’action texte (ou tekst) plus lisible que table.

Pour les listes, l’URL a toujours la même structure :

Voor de lijsten heeft de URL altijd dezelfde struktuur:

https://d-meeus.be/verkelec/central/list.php?action=table&circ=Circ&requ=…
ou il faut changer l’abréviation Circ de la circonscription dans circ= et le type de document dans requ= waar men de afkorting Circ van de kieskring moet aanpassen in circ= en de soort document in requ=

Les circonscriptions fédérales sont abrégées comme suit :

De federale kieskringen zijn als volgt afgekort:

Apen   BHV   Braw   Hai   Leu   Lig   Lim   Lux   Nam   OoVl   WeVl   Senaat   Senat

Les types de documents actuellement disponibles (décrits plus en détail ci-dessous) correspondent aux codes requ= suivants :

De nu beschikbare soorten documenten (hieronder verder beschreven) aantwoorden aan volgende requ= codes:

travail   latotale   simple   presse   Solid   PbisF werk   alles   simpel   pers   Solid   PbisN

Seule la forme requ=travail mentionne déposants et témoins.

Alleen de vorm requ=werkvermeldt indieners en getuigen.

Normalement, on laisse action=table. Pour de longues listes, on peut préférer action=scroll. Par ailleurs, il existe aussi action=CSV qui affiche les résultats séparés par des points-virgules. Si on copie ça dans un éditeur et l’enregistre en texte ordinaire sous un nom comme resultat.csv, ça s’ouvre ensuite dans un tableur comme OpenOffice.org Calc.

Normaal gezien, laat men action=table ongewijzigd. Voor lange luisten is misschien action=scroll beter. Toch mag je ook action=CSV kiezen. Dan krijg men resultaten door puntkomma’s gescheiden. Als men dit copiëert en sla op als gewone tekst in een editor met een bestandnaam als resultaat.csv, dit zou dan in een spreadsheet als OpenOffice.org Calc openen.

Les variantes requ= et action= sont décrites à suffisance dans listcomp.html#docs. Leur code se trouve avec celui de list.php dans l’annexe 4.

Documents à imprimer

Il faut trouver le moyen de composer les documents sans passer par OOo Base. Peut-être en affichant le contenu et en le copiant dans un document Writer.

Il faudrait donc une ou plusieurs actions de type texte.

Annexes

Annexe 1, structure de la table perso

More…

Annexe 2, code de la requête cleannumnat.sql

Cette requête retire les blancs et les ponctuations dans le champ numnat. More…

Annexe 3, code de la requête cleanphone.sql

Cette requête retire les barres et les points dans les champs phone et gsm. More…

Annexe 4, documentation du script list.php
et des différentes requêtes et actions associées

More…

Annexe 5, structure des tables de composition de liste fedcompCirc

More…

Annexe 6, structure du format de fichier Pbis

More…

Retour en haut de la page
Aller à la page de départ de la centralisation
Aller à la page p‪ublique sur les élections