Utiliser de gros fichiers de données

Bonjour,

J'essaye de faire une cartographie qui affiche le monde, avec différentes couleurs selon l'altitude.

Pour se faire, je me base sur les informations DEM (Digital Elevation Model) qui décompose la carte terrestre en 33 zones dont chacune possède deux fichiers :
- Un fichier d'entête de la zone précisant le rectangle ainsi que le "pas" des prises de mesures (en général 1km)
- Les altitudes, en binaire (succession d'entiers sur 16 bits).

Le total des fichiers fait plus d'1,7Go, je ne peux donc pas tout charger en mémoire.

J'ai pensé à utiliser un facteur de précision en fonction du zoom sur la carte. Une vue à l'échelle du globe chargerai l'ensemble des valeurs mais en espaçant de 30km, et une vue à l'échelle d'un pays réduirait l'espacement à 10km mais ne chargerai que les altitudes du rectangle visionné.

A chaque zoom/déplacement il va donc falloir tout vider, puis relire ces fichiers, avec un petit algo prenant en compte la précision et la zone des altitudes à rapatrier.

J'ai du mal à choisir entre cette solution ou l'utilisation direct des fichiers.


Vous pouvez me conseiller ?

Merci,

A bientôt

Les deux démarches ne sont pas exclusives.

A mon avis, la bonne approche est de fabriquer des fichiers plus petits (ou un fichier très grand dont tu ne lis que des petits bouts contigus, à partir d'une table d'index).

Pour les vues "grande échelle" je construirai donc des fichiers agrégés (obtenus par moyennes d'altitude sur des régions plus larges). Pour les zoom, je ferais un grand nombre de petits fichiers, qui se chevauchent (de façon à ne jamais avoir besoin de plus d'un fichier à la fois).

La taille de tes fichiers dépendra de la résolution des données de départ, et de la précision souhaitée, mais tu pourras t'arranger pour ne jamais avoir besoin de tout charger en mémoire (et là encore le chevauchement aide : si tu "survoles" une zone, tu peux charger le fichier suivant avant d'avoir "fini" le fichier précédent).

Francois

Bonjour,

je n'ai pas de conseille, mais est-ce que je pouvais vous demander d'où vous le téléchargez ? La cartographie m'intéresse aussi.

Merci. Bonne journée. Fredy

Oui biensûr,

C'est via le GTOPO30

http://edc.usgs.gov/products/elevati...0/gtopo30.html

Et les fichiers sont accessibles sur leur FTP
ftp://edcftp.cr.usgs.gov/pub/data/gtopo30/global

Parmis les fichiers il y a un README.TXT qui explique comment la structure des données.

Merci pour reponse tres rapide.

Bon week-end. Fredy

Pour avoir fait exactement cela....

1. Tu peux avoir plusieurs "résolutions" de tes DEMs en même temps: fichiers plus petits, données pré-calculées (et surtout pré-optimisées... Prendre une valeur sur X entraine de l'aliasing, mais bon... sur la carte du globe c'est peut etre pas trop grave).

2. Avoir un système de "tuiles" (Tiles) à la demande.... qui savent lire un bout de fichier, et se flusher quand une taille maximale de mémoire est atteinte. A noter que les tuiles peuvent aussi faire du LOD....

Comme ça, le programme utilisateur, n'a plus à se poser de question... il a besoin d'une tuile ? Il la demande au manager.... Il n'en a plus besoin ? Il la rend, en sachant que si il la redemande très vite, les données seront toujours là.

Salut,

Il semblerait déjà que tu puisse disposer de fichier séparés selon la longitude et la latitude...

Cela te permet déjà de n'avoir des fichiers dont la taille tourne aux alentours de 20 à 50 Mb, et de limiter déjà plus ou moins la taille des données à lire et à manipuler ;) (il ne sert à rien de charger le fichier relatif à l'alaka si tu veux afficher l'Egypte :D)

De plus, il semblerait (mais peut etre n'ai-je pas observé assez attentivement le fichier de données) qu'il s'agisse de fichier exclusivement binaires, ce qui nous assure que, pour obtenir une information complête (l'altitude à une longitude et une latitude donnée), nous sachions exactement le nombre de bytes qu'il faut lire...

Cela devrait te faciliter énormément la tâche en ce qui concerne la lecture, car, en effet, dés que tu connais la position du point d'origine (celui représentée par la première donnée) du fichier et la logique à suivre pour calculer l'index à laquelle tu trouvera un autre point (typiquement, correspondant à la taille de la donnée * ((numéro de ligne*nombre de colonnes par ligne)+ numéro de colonnes)

Dés lors, un acces aléatoire au fichier (seekg et consort) devrais te faciliter énormément la vie, et t'éviter d'avoir à charger tout le fichier :D

En travaillant sur une structure cohérente (sans doute fort proche de std::list<std::list<altitude> >, même s'il est préférable d'envisager de complexifier les choses en créant une structure "Rectangle" qui contient une liste d'éléments de type "Ligne" qui contient elle même une liste de "Colonnes" ;) ) tu devrais pouvoir arriver à charger le tout de manière fluide pour assurer le mouvement sur la zone observée ;)

Citation:

---

Envoyé par koala01

Cela te permet déjà de n'avoir des fichiers dont la taille tourne aux alentours de 20 à 50 Mb, et de limiter déjà plus ou moins la taille des données à lire et à manipuler ;) (il ne sert à rien de charger le fichier relatif à l'alaka si tu veux afficher l'Egypte :D)

---

En fait, ce qui est compliqué c'est qu'il faut prévoir un certain recouvrement de ces cartes, et un découpage un peu rusé. Sinon, la LEM prévoit que tu vas souvent te trouver en bord de carte (voire en coin de carte), où deux fichiers (voire 4) est des algos tordus seront nécessaires.

L'idée est donc de fabriquer des fichiers qui se recouvrent suffisament pour éviter de jamais en utiliser plus d'un...

Francois

Citation:

---

Envoyé par fcharton

En fait, ce qui est compliqué c'est qu'il faut prévoir un certain recouvrement de ces cartes, et un découpage un peu rusé. Sinon, la LEM prévoit que tu vas souvent te trouver en bord de carte (voire en coin de carte), où deux fichiers (voire 4) est des algos tordus seront nécessaires.

---

Je ne crois pas que l'algorithme soit particulièrement tordu...

Si nous partons sur l'idée de 36 fichiers pour représenter la totalité de la superficie terrestre, nous pouvons raisonnablement penser que chacun d'eux couvre une surface s'étalant sur 30 degrés de latitude et 60 degrés de longitude (je n'ai pas vérifié tous les noms, mais je ne serais pas étonné si c'était le cas;))...

Vu que l'on connait, par définition même, la longitude et la latitude des point d'angle de chaque fichier, il devient vraiment simple de générer dynamiquement le nom des fichiers contigus sur base du déplacement à effectuer ;)

La seule remarque réellement pertinente étant que l'on peut se trouver dans une situation dans laquelle nous devrions lire un ou trois fichiers qui ne sont pas le fichier d'origine(vu que je considère que le fichier d'origine est déjà géré et qu'il "suffit" de rajouter les élément du bon coté de la liste adéquate et de supprimer les éléments de l'autre coté ;))

Mais cela ne rend pas forcément l'algorithme plus complexe ;)

Hé bé j'ai réunit mes 33 fichiers pour n'en faire qu'un seul, qui fait donc 1,73Go, puis j'ai généré une image de 800x600 (qui me servira de texture) si la totalité de la surface terrestre.

Voilà le résultat :
http://afilez.free.fr/topo.png

Puis, j'ai généré une image de même taille, mais avec un fichier de 55 Mo. Le traitement a pris le même temps.

Il semblerait donc que la taille du fichier n'a pas d'importance dans la lecture.

Concernant la résolution, la "partie" de mon fichier DEM que je lit est définit selon le rectangle que je veux afficher ainsi que le "pas" de lecture des lignes/colonnes déduit par la taille de l'image.

Par exemple j'ai :
- Un .DEM de 21600 lignes et 43200 colonnes
- Je décide de tout afficher (longi de -180 à 180 et lati de 90 à -90)
- Sur une image de 800 par 600, alors un pixel de cette image

Un pixel de l'image équivaudra donc à un carré du fichier DEM de 36 lignes et 54 colonnes. A mon pixel j'attribue la valeur au milieu du carré DEM.

Puis je lit le fichier de manière séquenciel, avec des seekg(positif) aller chercher la valeur du pixel suivant.


La résolution de l'image dépend alors du rectangle terrestre à visionner ainsi que de la taille de l'image à générer.


Vous en pensez quoi ?

Normalement tu devrais creer une pyramide avec different niveau de zoom parce que meme en nearest neighbourgh c'est long de reechantilloner une image...