Discussion :

[zizoufoot]

Bonjour,

Je vous expose la situation :
* Je dois créer un logiciel X qui lit un fichier créer par un autre logiciel Y
* Les données des fichiers générés par Y sont une succession de lignes qui décrivent comment dessiner de(s) objet(s). Les fichiers peuvent être décomposer ainsi :
> En en-tête : De quel type de modélisation traite-t-on, s'agit-il d'un dessin 2D, etc etc
> Dans le corps, il y a les données : x0 = 1, y0 = 2(ligne) x1 = 5.3 y1 = 6
* Une fois que le logiciel X a lu le fichier, il doit modéliser ces données.
* Je n'ai pas l'autorisation de modifier Y. Par contre, je peux demander au programmeur de Y de modifier la manière dont sont écrites les données dans les fichiers.

Ma vision de la solution est la suivante :
0] Demander au programmeur de Y de formater les fichiers de sorties. Pour cela, utiliser le format XML par exemple.
Ainsi, la notion de position des données est supprimée. Effectivement, avant les données étaient enregistrées tel quel :
x = 3 y = 5
Donc, on savait que la valeur de x était en position 4 et y en 10.
Avec un système de balisage, j'aurais :
<x>3</x><y>5</y>
L'extraction de la donnée est plus longue mais plus facile et non dépendante de la position des données.

1] Créer une interface entre Y et X. J'appellerais ce logiciel Z.
Ce logiciel Z s'occupe de lire le fichier généré par Y.
Il effectue une première lecture durant laquelle il va stocker l'en-tête ainsi que la position des balises. Il crée un index en somme.
Ensuite, Z se met en attente de requête de la part de X.

2] Pour le logiciel X, je vais l'articuler ainsi :
> Lorsque l'utilisateur demande d'ouvrir un fichier(généré par Y), X exécute l'interface Z avec comme paramètre ce fichier.
> Ensuite, le logiciel X communique avec Z. X demande à Z de lui fournir des données(qu'il sait afficher). C'est donc Z qui va indiquer comment afficher les données, X ne s'occupe que d'afficher.
> Lorsque l'utilisateur ne fait rien, la communication est en pause.
> Lorsque l'utilisateur ferme le fichier, la communication est fermée.

Précisions diverses :
* Les fichiers générés par Y peuvent être très lourds(> 1Go).
Mais peu importe la taille des fichiers, il ne doit pas y avoir de ralentissement lors de l'ouverture. Donc un fichier de 10Go doit être ouvert aussi rapidement qu'un fichier de 10Ko. Bien entendu, le traitement est forcément plus long, mais ça je ne peux rien y faire ?

Voilà l'histoire.
J'aimerais savoir si vous pensez qu'il s'agit d'une bonne solution.
Le format XML est-il bien approprié ? Un meilleur format(pas trop compliqué pour le programmeur de Y) ?
L'interface peut-elle être améliorée ? Comment programmer l'interface : un exécutable indépendant, un objet de Y ?
En ce qui concerne X, connaissez vous de bonne librairies qui permettent la modélisation 2D/3D et qui peuvent traiter de façon fluide énormément de données ?

Un grand merci pour votre aide

[koala01]

Salut,

Bonjour,

Je vous expose la situation :
* Je dois créer un logiciel X qui lit un fichier créer par un autre logiciel Y
* Les données des fichiers générés par Y sont une succession de lignes qui décrivent comment dessiner de(s) objet(s). Les fichiers peuvent être décomposer ainsi :
> En en-tête : De quel type de modélisation traite-t-on, s'agit-il d'un dessin 2D, etc etc
> Dans le corps, il y a les données : x0 = 1, y0 = 2(ligne) x1 = 5.3 y1 = 6
* Une fois que le logiciel X a lu le fichier, il doit modéliser ces données.
* Je n'ai pas l'autorisation de modifier Y. Par contre, je peux demander au programmeur de Y de modifier la manière dont sont écrites les données dans les fichiers.

Ma vision de la solution est la suivante :
0] Demander au programmeur de Y de formater les fichiers de sorties. Pour cela, utiliser le format XML par exemple.
Ainsi, la notion de position des données est supprimée. Effectivement, avant les données étaient enregistrées tel quel :
x = 3 y = 5
Donc, on savait que la valeur de x était en position 4 et y en 10.
Avec un système de balisage, j'aurais :
<x>3</x><y>5</y>
L'extraction de la donnée est plus longue mais plus facile et non dépendante de la position des données.

Avec, comme résultat, des fichiers inutilement lourds.

XML, c'est très bien pour formater les données, je te l'accorde, mais cela correspond souvent à sortir le bazooka pour essayer d'atteindre une mouche.

Dans ton cas, tu auras sans doute beaucoup plus facile avec la tapette à mouche ou le journal roulé

1] Créer une interface entre Y et X. J'appellerais ce logiciel Z.
Ce logiciel Z s'occupe de lire le fichier généré par Y.
Il effectue une première lecture durant laquelle il va stocker l'en-tête ainsi que la position des balises. Il crée un index en somme.
Ensuite, Z se met en attente de requête de la part de X.

Encore plus lourd, encore plus inutile

2] Pour le logiciel X, je vais l'articuler ainsi :
> Lorsque l'utilisateur demande d'ouvrir un fichier(généré par Y), X exécute l'interface Z avec comme paramètre ce fichier.
> Ensuite, le logiciel X communique avec Z. X demande à Z de lui fournir des données(qu'il sait afficher). C'est donc Z qui va indiquer comment afficher les données, X ne s'occupe que d'afficher.
> Lorsque l'utilisateur ne fait rien, la communication est en pause.
> Lorsque l'utilisateur ferme le fichier, la communication est fermée.

Et, pourquoi pas "simplement" parser le fichier tel qu'il est

Précisions diverses :
* Les fichiers générés par Y peuvent être très lourds(> 1Go).
Mais peu importe la taille des fichiers, il ne doit pas y avoir de ralentissement lors de l'ouverture. Donc un fichier de 10Go doit être ouvert aussi rapidement qu'un fichier de 10Ko. Bien entendu, le traitement est forcément plus long, mais ça je ne peux rien y faire ?

Ca, tu peux oublier d'office.

10k, il y a de très fortes chances pour que cela tienne sur un seul "cylindre" du disque dur.

Autrement dit, il y a de très fortes chances pour que ton fichier soit lu en un seul tour de plateau du disque dur

1Gb, ca ne tiendra jamais sur un seul cylindre, malgré le fait que la capacité des disques durs augmente sans cesse.

"Si tu as de la chance" et qu'il n'y a pas de fragmentation du fichier (hé oui, ca arrive encore sous windows ), tu pourras peut être éviter d'avoir des temps de latence trop important durant la lecture, mais, une chose est sure, il faudra bien plus d'un tour de plateau du disque dur pour arriver à le lire

Voilà l'histoire.
J'aimerais savoir si vous pensez qu'il s'agit d'une bonne solution.
Le format XML est-il bien approprié ? Un meilleur format(pas trop compliqué pour le programmeur de Y) ?

Amusons nous un tout petit peu à compter :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x0 = 1, y0 = 2

ca fait une ligne de 8 caractères, plus les éventuels espaces.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<point id="0"><x>1</x><y>2</x></point>

(ad minima si tu veux un XML bien formé) ca fait 38, soit pres de 5 fois plus caractères pour un point strictement identique.

Si tu demandes à convertir un fichier de 1Gb en xml, tu peux t'attendre, en gros, à ce qu'il fasse pas loin de ... 5Gb au final.

Cela fait des temps d'accès cinq fois plus long au niveau du disque dur, et cela fait un fichier qui risque vraiment d'envoyer la meilleur bibliothèque XML au tapis, à cause des récursions qu'elle va rencontrer

L'interface peut-elle être améliorée ? Comment programmer l'interface : un exécutable indépendant, un objet de Y ?

Développe ton X et fait en sorte qu'il doive lire un format le plus simple possible, par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
# n° du point  X  Y
1 1 2
2 3 5
3 12 85
...
8574 15 64
[edges]
# N° de l'arrête N° point1 N° point2
1  10 15
2 1 3
...
4587 7653 4100

C'est un format qui sera facilement généré par l'application Y et qui sera facilement lu par la tienne.

Si cela te suffit, tu ne t'en portera que mieux

En ce qui concerne X, connaissez vous de bonne librairies qui permettent la modélisation 2D/3D et qui peuvent traiter de façon fluide énormément de données ?

Ce ne sont ni les formats ni les bibliothèques qui manquent, que ce soit en 2D ou en 3D...

Pour te permettre de te faire une idée, voici une liste (qui n'est peut être pas exhaustive)

Mais avant de t'inquiéter de cela, il y a peut être deux questions que tu devrais te poser et dont la réponse orientera sans doute ton propre choix:
Que sont sensées représenter les données C'est une modélisation, ca, je l'ai bien compris, mais c'est plutôt une modélisation d'animation, ou plutôt de la modélisation "géospatiale"
Tu ne manipuleras, très certainement, pas les données de la même manière

La deuxième question est pire encore : que devras faire ton application une fois qu'elle aura chargé ces données

Car, au final, le chargement des données (et leur interprétation) ne sera jamais que la première étape, mais je présumes que tu voudras faire "quelque chose" de ces données une fois que tu les auras lues

Et, bien sur, la manière dont tu pourras envisager de les manipuler dépendra de la manière dont tu les as interprétées (ou plutôt : la manière dont tu interpréteras les données dépendra fortement de la manière dont tu veux les manipuler par la suite ).

Sinon, pour ce qui est de la lecture des données en elles-même, tu peux éventuellement faire un petit tour du coté de boost::serialization.

C'est simple, c'est efficace

Enfin, si tu veux un exemple d'application de modélisation, tu peux aller voir du coté de blender, qui supporte (nativement ou par ajout) quelques formats de modélisation sympas, et pour lequel tu pourras même trouver les sources en cherchant bien

[white_tentacle]

La deuxième question est pire encore : que devras faire ton application une fois qu'elle aura chargé ces données

Vu la taille envisagée pour les fichiers, il me parait impensable de ne pas faire le traitement au fil de la lecture → lecture avec callbacks. D’ailleurs, je pense que c’est ce qui est entendu par « il ne doit pas y avoir de ralentissement lors de l’ouverture ».

Pour le reste, rien à ajouter