Discussion :

[130i-24v]

Bonjour,

Je réalise un petit programme qui sert à localiser sur carte des données mesurées sur le terrain.
En fonction de coordonnées (x,y) en lambert 2E, j'ouvre à l'écran la carte sur lequel se trouve les données mesurées. On dispose ainsi de 300 cartes au 100 000 ieme découpant le territoire national.
On aimerait bien donner ce petit soft à des clients, mais pour le moment je suis obligé de fournir les 300 dalles (c'est du jpeg) avec mon soft.
Quel moyen simple (je suis pas un as du delphi) existe t il pour ne pas donner les 300 cartes (400 mo à peu pres)?

J'aimerais par exemple donner le .exe de mon programme et un gros fichier unique contenant les 300 dalles. Est ce possible?

Ou sinon integrer les jpeg en tant que ressources, afin de les mettre dans le .exe ? Est ce raisonnable sachant que je vais me retrouver avec .exe de 400Mo au moins? Ca ne risque pas de ramer ou d'etre bcp trop lourd vu que je presume que le .exe va etre mis dans la ram ?

Le but de la manoeuvre c'est surtout d'éviter de donner 300 fichiers au client.

Voila voila...
Merci à ceux qui m'ont lu
Thierry

[Gaadek]

Pour moi, je ne vois pas en quoi cela pose un problème?

Si tu compresses tes cartes dans une archive, certe, tu vas gagner en place, mais le jour où tu fais une mise à jour, tu dois donner la nouvelle archive complète, et ce même si une seule dalle a changée.

Ne parlons même pas du cas où tu insère ces images sous forme de ressources, vu que dans ce cas, tu dois redonner un exe d'une centaine de Mo.

Donc la solution que je te propose: tu graves le tout sur un CD (.exe + les 300 fichiers) et c'est tout. Il existe énormément de logiciels qui nécessitent beaucoup de données découpées en centaines de fichiers, donc je ne vois pas en quoi cela serait génant dans ton cas?

[130i-24v]

Oui en cas de changement d'une dalle il faudrait tout changer. Mais la mise à jour des dalles est au plus d'une fois par an, ce qui reste raisonnable. (j'ai d'un coté les fichiers jpg des dalles et d'un autre coté les mesure géoréférencé).
En fait c'etait principalement pour le coté pratique d'avoir un seul fichier regroupant les 300 dalles, mais aussi pour que le client n'ait pas un accès trop facile aux dalles jpg sans pour autant faire un truc super protégé.

Thierry

[Gilbert Geyer]

En fait c'etait principalement pour le coté pratique d'avoir un seul fichier regroupant les 300 dalles,

Juste une idée : Ne serait il pas possible, via un TFileStream, d'envoyer en rafale les 300 jpeg séparés par un marqueur de séparation sur le disque dans un fichier unique de regroupement ? ... sachant que ces marqueurs de séparation serviront ultérieurement lors des relectures de retrouver chaque bloc de données jpeg entre les positions délimitées par ces séparateurs.

J'ai fait plusieurs bidouilles similaires en regroupant dans un seul fichier des trucs délimités par des séparateurs (bloc-notes-de-fiches au format .txt, mode-d'emploi multipages au format .rtf) avant de découvrir les possibilités des FileStream.

En plus avec TFileStream on peut même profiter de l'étape d'écriture de regroupement pour capturer la position de chaque séparateur dans une table qu'on envoie également sur le disque en prévision des relectures ultérieures par positionnement-direct en pré-chargeant ce fichier-de-relevé-topographique-du-gros-fichier avant de lancer la lecture de ce gros fichier.

Si en plus tu donnes par exemple au nom de ces fichiers une extension du style .dll ou un truc qui détourne l'attention aucun client lambda n'ira y chercher les cartes et même un fouineur qui utiliserait un éditeur Hexa aurait des difficultés pour s'y retrouver ... sans oublier qu'avec l'astuce du fichier-de-relevé-topographique des positions on pourrait même se permettre d'utiliser des séparateurs variables (ex : CRLF un coup et autres combinaisons de deux caractères du début de la table Ascii en évitant toute combinaison propre au format jpeg) pour berner un bidouilleur fouineur ... mais comme tu dis "sans pour autant faire un truc super protégé" c'est peut-être pas la peine de se compliquer la vie en allant jusque là.
Bon dév.

[EPJSoft]

je serais aussi dans l'idée Gilbert Geyer
générer des Records contenant les données images (jpeg voir même mieux des png)
De préférences j'opterai pour plusieurs fichiers plutôt qu'un car en cas d'anomalie c'est le gros fichier qui morfle...
Tu peux aussi faire comme dans certains jeux, tu changes l'extension de l'image, tu mets .dat par exemple alors qu'en réalité il s'agit d'images...
Pourquoi pas aussi l'intégrer dans un .cab ou un fichier compresser mais on rejoint l'idée de Gilbert : 1 fichier pour 300 dalles...
Ou alors faire des fichiers par zone latitude ou longitude... (cela ne limite pas les fichiers à une futur extension européenne ou planétaire lol) sauf si la terre s'applatit arrggg

Gaadek a dit :Si tu compresses tes cartes dans une archive, certe, tu vas gagner en place, mais le jour où tu fais une mise à jour, tu dois donner la nouvelle archive complète, et ce même si une seule dalle a changée.

Pas forcément, si tu fournis un programme de mise à jour genre patch qui te remplace la dalle correspondante dans l'archive... Tu peux même l'inclure dans le programme exe => emplacement du patch update.zip par exemple et dedans tu mets les dalles mises à jour... dés qu'il y a un fichier update.zip au lancement du programme celui ci met à jour l'archive et surprime l'update ou le flag comme mis à jour (tenir compte de la version de la dalle)

cela me fait rebondir sur un truc...
créer son propre format de fichier avec une entete personnalisé et ensuite l'image en question (le jpeg). Dans l'entete tu pourras ainsi intégréer la date de l'image ou sa version...

D'ailleurs tu peux aussi t'orienter vers le principe d'intégrer les ressources dans une dll. (en plus tu as la version de ce fait)...

[Paul TOTH]

j'ai fait un soft comme ça

pour ne pas diffuser toutes les images d'un coup, j'utilise un site web.
Celui ci-contient toutes les images plus un fichier texte contenant la liste des images.

le nom de chaque image est lié à sa position lambert, du coup, je peux facilement savoir si l'image d'une dalle est disponible en consultant le fichier texte.

le programme charge donc d'abord le fichier texte, puis, si nécessaire charge les images dont il a besoin. Un système de cache local évite bien évidemment de recharger l'image à chaque fois

les images JPEG possèdent d'ailleurs une caractéristique intéressante, il est possible de décompresser l'image à une taille réduite. J'utilise cette possibilité pour adapter la taille des dalles au facteur de zoom de la carte et ainsi gagner en occupation mémoire.