des archives en accès par listes

Bonjour,

Je souhaite mettre en accès libre aux membres de mon association des listes (chaînées?) de documents d'archives scannés : Exemple

    ""1"",""1775-11-25"",""25 nov. 1775"",""Administration"",""Oyé"",""défaut à Mre Etienne comte et Gilbert marquis de D* et Mre Perrin de Daron de Oyé"",""B_001_docu_0001"  
    2","1396-01-01","1 janv. 1396","Administration","Saint-Laurent-en-Brionnais","vidimus de Durand Billet et Jean Regnault son pariatre, tenanciers de la censive du Roy à St Laurent en Brionnais (1396)","B_001_docu_0002"  
    3","1464-01-01","1 janv. 1464","non classé",,"texte en latin de 4 pages","B_001_docu_0003"  

Chaque liste serait accessible par un pointeur? (ex : "B_001_docu_0001") sur une liste de "n" scans de tailles environ 1Mio.
- Comment détecter les fins de listes (structure de base en objet?)
- comment compacter et envoyer la liste (download depuis mon site web) ?

Est-ce bien possible de lancer une appli en langage php orienté objets, par un vieux retraité habitué à la programmation classique Fortran, pascal, ... un peu de C++

Salut Determinos,
ça pose quelques questions :

Ces listes sont stockées sous quelle forme ?

• lignes dans une base de données
• fichiers texte
• autre ?

Partant de là, il conviendra ensuite d'identifier les objets. Par exemple, on pourrait envisager une ligne comme un objet, et une archive comme un autre objet composé de plusieurs lignes.

Mais quoi qu'il en soit, je crois qu'il faut commencer par définir une description fonctionnelle de l'application envisagée.
La programmer ensuite, que ce soit en procédural ou en objet est relativement secondaire. Mais il est impératif de savoir ce qui doit être programmé.

Formulé autrement, je n'ai pas tous les éléments pour apporter des suggestions pertinentes, du coup, je ne peux que deviner certaines parties, et généralement c'est quand on commence à spéculer sur ce que doit ou non être telle ou telle partie qu'on se plante à peu près systématiquement.

Bonsoir,

Je ne pensais pas avoir une réponse aussi rapide, merci.
Les renseignements d'archives présentés sous forme d'un tableur libre Office (voir le début de cette liste), sont en fait dans une table MySQL accessible par un formulaire (multicritères).

Les images sont dans un répertoire, à la queue leu leu... ex: la première "B_001_docu_0001_01.jpg", la dernière est "B_001_docu_0001_08.jpg", ensuite on passe à la suivante "B_001_docu_0001_02_01.jpg"... etc.

Le traducteur (client futur) devra recevoir un pack d'images, référencées d'après le choix fait à l'issue du questionnaire (formulaire-démonstrateur déjà en ligne, en local, sous apache).

Restent à faire :
- le tri des images en dossiers (correspondants à des archives physiques)
- leur empaquetage dans des répertoires que l'on archivera en zip ou en pdf.

Pour l'instant, je ne sais pas comment programmer les 2 opérations du dessus.

J'ai quelque idée lourdingue d'écrire en php :
- former une chaîne de caractère "B_001_docu_0001_01.jpg" à partir du dernier champ lu dans la requête issue du formulaire i.e. $page ="B_001_docu_0001",
- boucler : tant que $page=.T., copier l'image du répertoire d'image indexée par $page+$compteur dans le répertoire client...fin tant que.
etc ...

Oualà.

Suis-je assez compréhensible ?

Bien amicalement.

Ok, je vois un peu mieux effectivement.

Et le fait que les informations soient en base de données va faciliter grandement la manœuvre. Ce que je crois comprendre (à corriger si je fais erreur) c'est que pour chaque image, on a l'information dans la ligne extraite de la base, ce qui veut dire qu'on peut identifier le fichier.

Donc à première vue, et si je ne me suis pas trop égaré, l'utilisateur effectue une sélection dans une formulaire. Partant de là, lorsque le formulaire est soumis, on va récupérer les éléments qu'il a sélectionné pour construire l'archive zip ou pdf.

Est-ce que chaque ligne de donnée comporte, outre le nom de l'image, le chemin vers l'endroit où elle est stockée ? si je me fie à l'exemple montré dans le post original, il semble que non. Ça veut dire qu'il va falloir parcourir le (ou les) répertoire(s) où sont stockées ces images jusqu'à ce qu'on les ait toutes trouvées. Au fur et à mesure, on fait une copie de l'image trouvé dans le répertoire client : l'idée de la boucle est tout à fait valable dans ce sens. À l'issue de cette première boucle, on passe à la création de l'archive (zip ou PDF). Pour cette partie, il sera beaucoup plus pratique de s'appuyer sur des librairies existantes en particulier pour monter un PDF. Pour un ZIP, ce serait plus facile dans la mesure où il y a peu de fonctions et elles sont natives en PHP. Pour le PDF, il existe des librairies librement disponibles comme par exemple FPDF ou encore Zend_Pdf à extraire du Zend Framework (plus complexe à utiliser, quoique...)

Maintenant, pour monter ça en objet, il s'agit d'identifier les objets : de ce que je peux voir, on a l'accès aux données de la base, les formulaires, on a l'archive ZIP ou le document PDF (ou les deux) et ensuite, selon l'architecture de l'application, le contrôleur si on construit ça avec une architecture en MVC. Si c'est une petite application, ce serait peut-être un peu exagéré et on peut parfaitement combiner des pages en procédural et l'utilisation de classes pour les traitements de données. On peut même peaufiner un peu en séparant le PHP du HTML avec l'utilisation d'un moteur de templates par exemple.
Là, je dirais que ce qui va déterminer la suite, c'est la cohérence globale par rapport à l'existant. D'où la question : qu'est-ce qui existe pour l'instant ?

Bonsoir Cyrano,

J'ai repris les données transmises par le scanneur... pour m'apercevoir qu'en fait, on peut faire mieux :

• Les dossiers d'images sont réalisés en tif 400 dpi, rangés dans des sous-répertoires.
• Les noms des sous-répertoires sont avec des blancs, ceux des scans aussi : Ex :
  $rep=""b 003 bazolle 01.01.2" contient toutes les images "b 003 bazolle 01.01.2 01.tif" à ..."b 003 bazolle 01.01.2 18.tif"

Donc, je vais :
1- enlever les blancs dans les noms d'images et des sous-répertoires,
2 - transcoder le .tif en .jpg (avec imagemagik avec une commande du genre
find . *.tif -exec convert {} {}.jpg ";" ; il serait bon de réduire encore chaque image à environ 700 à 1000 Ko,

Et... j'aurai une structure de répertoires, ex : b_003_bazolle_01_2 contenant chacuns les n, ici 19 photos d'archives... compactées en zip ou autres formats et transmissibles par un serveur d'images type dl.free ou autre.

Chaque nom de dossier sera donc rajouté dans la table MySQL, dans le dernier champ, dont il est question au tout début (Le 15/05/2015 08:38).

Je crois que là,... j'ai bon !... pour faire un second répertoire de ~ 100.000 images concaténées, rangées dans des fichiers zip sous un seul répertoire qui fera 100 Gio, donc rangé sur le serveur.

Côté programmation çà devrait être plus simple ?

système : Linux mageia 4,
Utilitaires : Quanta+, phpMyAdmin, MariaDB, krename ....

Je vais passer du temps à restructurer les dossiers en zip, les abonnés (nos clients) transcripteurs à vérifier et renseigner du contenu de chaque archive en viel françois ou en latin...

Une retraite bien occupée. Pour servir l'Histoire

C'est effectivement une occupation pour meubler largement une retraire ;)

Je m'interroge juste sur la taille des archives zip : 100Go me semble un tantinet énorme. Le serveur pourrait probablement le faire, mais est-ce que l'utilisateur aura les ressources matérielles pour l'ouvrir, c'est pas gagné. Ceci étant, là il est peut-être question de la taille du répertoire où sont seulement stockées les images, les archives zip qui en sortiront étant très largement moins importantes. Et dans ce cas, ça peut fort bien fonctionner.

Sinon, pour le reste, je ne vois pas de problème particulier, tout ça devrait fonctionner correctement :)

Quant à l'environnement, je ne connais pas « krename » ni Quanta+ (un éditeur de code, non ? ) et pas davantage la distribution Mageia, mais un Linux reste un Linux et ça reste du LAMP, donc sans soucis majeur en vue.

Bonjour Cyrano,

L'aventure linux remonte à fin des années 80. Progressivement, dans les labos, on a tout transféré sous une redhat et scilab en place de matlab (gain sur les crédits de TP énorme ! )... L'habitude est prise, mais les contacts avec les équipes d'info ont tous été perdus à la retraite...

Je fais du 3D sous sketchup avec Big-blue, beaucoup plus facile à utiliser que Blender... et du SIG avec Grass7. Quanta est un éditeur html et php très commode.

Enfin, côté base d'images, j'avance et je dois rencontrer une équipe qui a mis en ligne les archives du château de Sassenage (38) plus de 100 m linéaires ....
Bon W E

Ok,
bon weekend également :)