Salut, Je bosse sur le sujet depuis qqs mois et je commence enfin à obtenir de bons résultats, donc autant les partager avec vous.
Voici ce que l'on peut faire cracher aux SRTM (version CGIAR v4, un poil moins définies que les originales mais avec des trous bien comblés) : (penser à cliquer sur les images pour obtenir la résolution originale) http://wiki.openstreetmap.org/wiki/Image:Sample_SRTM_OSM_CORINE.jpg http://wiki.openstreetmap.org/wiki/Image:Baux.jpg Ce que j'ai fait, dans l'ordre : - Ré-échantillonage des données SRTM à 14.25m de résolution avec GRASS GIS (module r.resamp.rst réglé pour éviter les artefacts disgracieux + des heures de calculs avec mon 3GHz) - Ombrage de mon cru, toujours sous GRASS >>> Obtention d'un geotiff de l'ombrage @ 14.25m de résolution de 1.1Go, ayant pour emprise une bounding box de PACA Sont ensuite ajoutés à la couche (rendu mapnik 0.6) : - Courbes de niveaux équidistantes de 10m (toujours calculées sous GRASS). Là ça devient chaud : 3.2Go pour la même emprise, mais sans aucune optimisation / généralisation des données. Un rendu potable doit être possible en conservant le 1/3 ou le 1/4 des noeuds, donc je dirais, à vue de nez, que 750Mo / 1Go doivent être atteignables pour une région aussi tourmentée que PACA. - Corine Land Cover (in-importable sous OSM pour cause de licences incompatibles, mais utilisable de la sorte) - OSM (bah ouais...) Hormis les défaut inhérents au SRTM (relatif manque de précision dans les vallées étroites et à certains endroits) ainsi qu'à la technique de ré-échantillonage (reliefs vifs parfois trop adoucis), je dois dire que j'étais sur le cul d'obtenir pareil résultat. L'ennui, c'est que l'on se rend parfois aussi compte de la nullité de certains de nos travaux, mais lorsque l'on se retrouve avec une route qui épouse parfaitement le relief, l'orgasme est assuré (comment ça je suis bizarre? :-/). Pour info, le rendu complet d'une bounding box un peu plus grande que PACA à ce niveau de détail (1 seul niveau de zoom) et avec toutes les options (CORINE + OSM) prend 3.3Go et 20-25mn de calcul pour 8 PNG de 20000x20000 (avec un core2duo @ 3GHz, 6Go de RAM sous Debian SID 64 bits). S'il y a des questions... @+ Eric SIBERT a écrit : >>> Mes 0,02 € >>> >> 2 cents ? t'es pas cher de l'heure ;-) >> > > Tu as remarqué??? Les conseillers ne sont pas les payeurs!!! > > >> Ensuite, je peinture le bazar avec ombres et couleur. Mon pixel fait >> toujours >> 30x30m et Mon fichier pour les alpes fait la bagatelle de 1.5Go, idéalement >> il faudrait passer encore en dessous genre 10x10 par un nouveau bilinear >> filtering sur les pixels de couleurs, mais je vous laisse imaginer la taille >> final de mon fichier. >> Géotiff que j'utilise étant limité à 4Go, boom je suis dedans >> > > Je n'ai aucune idée de la méthode pour générer les cartes mais c'est sûr > que s'il faut stocker complètement chaque étape intermédiaire, ça > explose. Il faudrait peut-être découper les Alpes en plusieurs morceaux > avec éventuellement des recouvrement entre elles pour faciliter les > transitions. > > > >> On notera également dans ma bagarre de conversion un très laid phénomène >> d'intérférence que je n'ai pas identifié qui créer des bandes de O-NO à E-SE >> > > Je me suis demandé si c'était un artéfact des données sources. D'où ma > question privée il y a quelques temps. > > >> Concernant les courbes de niveau, je les constituent avant interpolation, et >> je m'en sort avec 15Go de courbes dans la base !! >> > > Ça calme. > > >> j'ai eu tenté de faire l'interpolation 90x90m->30x30m avant de générer mes >> courbes, et il fallait environ 5s pour une seule tuile (courbes tous les >> 10m) >> et je sais plus combien de Go dans la base. Je n'ose même pas imaginer après >> une interpolation par courbes de bézier que postgres ne saura stocker que en >> linestring !! >> > > D'une certaine manière, stocker les courbes interpolées dans la base, > c'est un peu un non-sens dans la mesure où les courbes de bézier visent > justement à définir des courbes en limitant le nombre de points sources. > > >> Ma conclusion fût que j'ai d'autres trucs à améliorer avant d'en arriver là, >> et que des machines avec 16Go de RAM à pas cher m'aideront bien dans l'avenir >> > > C'est une approche un peu bourrin qui n'optimise l'utilisation des > ressources (enfin si, la ressource humaine qui est aussi limitée :-p). > > D'un autre côté, le relief ne doit pas bouger tous les jours. Est-ce > qu'il ne serait pas possible de calculer le fond (couleurs+courbes de > niveau) une fois pour toute et de juste recalculer couches par-dessus? > > Je passe à 0,05€? > > Éric > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
