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


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

Données des candidats

Dans ce système provisoire, les données ne sont pas en ligne, mais dans mes divers ordinateurs personnels ou de bureau. Je synchronise toujours au moins trois ordinateurs en passant par une clef USB. Il y a donc toujours assez rapidement

Table des données de base

Les données sont dans la table perso du fichier de base de données candidats.odb du dossier Élections/Données, enregistré dans OOo comme Candidats. Il est bon à la fin des élections d’archiver une copie de ce fichier dans le dossier Données de l’année. (Après cette sauvegarde, on peut sans regret supprimer dans la version du dossier Élections/Données les requêtes liées à une année particulière.)

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

Majuscules et minuscules

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

Format du genre

J’ai mis un champ logique masculin. J’aurais pu mettre directement un champ texte genre avec les choix F ou M du Pbis, mais c’est ennuyeux de changer. Par contre, un champ booléen ne permet pas d’erreur, comme de mettre autre chose que F ou M et compromettre un traitement.

Format du numéro national

Le Pbis 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.

Format de dates

Dans la table perso, il faut afficher dans le format qu’on préfère. C’est dans les vues ou requêtes qu’il faudra éventuellement en changer, 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.

Données 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) ; 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) ; 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.

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.

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.

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.

Vue des données de base

L’essentiel des données brutes de la table perso est repris dans une vue perso-view. Celle-ci est sert de base pour présenter les données aux provinces pour en obtenir des corrections et additions. Voir le code en annexe 4.

Sexe

Le champ logique de perso est transformé en M/F. Cela servira aussi pour le Pbis.

Adresse

Les trois champ ruedomi, numdomi et (si non nul) btedomi de perso sont réunis en un seul champ adresse. Cela servira aussi pour le Pbis.

Plus

Le champ logique de perso est transformé en +. Cela servira aussi pour la communication.

Publication des données de base en html

La vue perso-view est convertie pour publication :

Table déroulante

En OpenOffice.org

Nettoyage par le script clean-centraldata

Head et thead en Bluefish

Si cette procédure est au point, il n’y a pas lieu de passer le filtre Html Tidy
qui crée trop de lignes vides dans les tables

Publication

Rapports

En OpenOffice.org

Nettoyage par le script clean-centrapport

Head en Bluefish

Si cette procédure est au point, il n’y a pas lieu de passer le filtre Html Tidy
qui crée trop de lignes vides dans les tables

Traduction

Publication

Communication des données par les provinces

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

Autres vues

Des tas de vues partielles peuvent se révéler intéressantes. Le problème est de rester dans des limites raisonnables du point de vue du travail de manipulation (procédure comparable à celle de centraldata ci-dessus) tant que ce n'est pas plus automatisé.

Constitution des listes

Tables de composition

Les tables de composition de liste

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. Sera 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. Je me propose d'ajouter des lignes Y1, Y2, Y3 pour les déposants et Z1, Z2 pour les témoins.

 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

Il y a des vues de sortie dans la base de données et des documents de sortie basés sur ces vues. Il me semble que les documents doivent être de préférence des documents avec champs pour pouvoir être mis à jour plutôt que recréés chaque fois.

Si on ne veut pas des résultats trop sophistiqués, on peut se contenter de rapports dynamiques dans Base. (Ce sont des sous-documents du document Base, ressemblant à des documents Writer et contenant toujours les données en tableau. On n'a semble-t-il que des choix de styles prédéfinis et quelques possibilités d'édition.) Comme ils sont dynamiques, il sont immédiatement à jour. On pourrait alors simplement les exporter en XHTML et publier tel quel le résultat obtenu, malgré le code abominable.

Des tas de listes peuvent se révéler intéressantes. Le problème est de rester dans des limites raisonnables du point de vue du travail de manipulation tant que ce n'est pas plus automatisé.

Liste pour contact

Avec prénom + nom, province, e-mail, téléphones

Liste avec données complètes

Si on veut consulter ou vérifier toutes les données de la liste, sans parcourir la grande base de données.

Pbis

Format de la date de naissance

Le Pbis demande la date en JJ/MM/AAAA.

Limitations du système et améliorations possibles

Succession des années et des niveaux d’élections

Je suis parti de l’idée de la permanence de la table principale, perso, de la base de données. Je compte l’archiver après coup dans l’année concernée, mais continuer d’une année à l’autre dans la même base.

Mais toutes les tables et vues de listes et les requêtes dépendent du niveau d’élection. Si on doit avoir en même temps toutes ces tables auxiliaires pour les élections fédérales, européennes, régionales et communales, ça va faire beaucoup. En fait, seule la table perso doit être permanente. Il faudrait peut-être à chaque élection retourner à la dernière base archivée du même niveau d’élections, mais y remettant la dernière version de la table perso. Un rapide essai semble montrer qu’on peut copier des tables d’une base Base dans l’autre.

Une autre perspective serait d’avoir dans une base les données (le premier chapitre du présent texte et la page central.html du système) et dans d’autres bases, une par niveau d’élection, la gestion des listes (le deuxième chapitre du présent texte et la page listcomp.html du système). Mais je crains qu’on je puisse pas faire de jointure entre tables de deux bases différentes.

Base de données en ligne

Si la base de données est en ligne, on peut développer en PHP une application plus interactive : l’affichage des données et la recherche se font en temps réel sur l’état actuel de la base de données. Au contraire, maintenant c’est moi qui dois passer de la base dans des documents bureautiques en OpenOffice.org, que je dois transformer en centraldata.html et centrapport.html à mettre en ligne par FTP.

Les provinces pouraient me communiquer en ligne des modifications et addition de données dans des formulaires créant des tables povisoires. (Il me semble que l’écriture dans la base doit être contrôlée : le contenu des tables provisoires nettoyé et approuvé avant intégration dans la table perso.)

Il faudrait pouvoir interfacer un OpenOffice.org local avec la base en ligne pour la production d’actes soignés. (On peut sans doute composer des pages A4 en PHP, mais il faut gérer le flux du contenu d’une page à la suivante. Les auteurs du système d’encodage en ligne avec le Pbis produisent des documents imprimables en htlm. On peut concevoir de produire du html soigné, mais le changement de page à l’impression peut ne pas être idéal et il faut encore contrôler les options de marge, d’en-tête et de pied de page du browser qui imprime.)

Par contre les autres documents ne dépendraient plus d’OpenOffice.org et ne demanderaient plus d’intervention humaine. On peut produire en PHP les fichiers Pbis qui sont des CSV. Toutes les versions des listes à usage de la presse et autres seraient proposées en consultation en html et en téléchargement en html ou CSV.

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, code de la vue perso-view

La plupart des traitements partent de cette vue plutôt que directement de perso.

More…

Annexe 5, tableau des champs du format Pbis

Retour en haut de la page