Merci de cette réponse prompte. Le 24 mai 2011 14:47, sly (sylvain letuffe) <[email protected]> a écrit : > On mardi 24 mai 2011, Guilhem Bonnefille wrote: >> J'ai une question un peu Hors-Sujet, aussi j'espère que vous ne m'en >> voudrez pas trop. > > Je recommande le transfert de cette discussion vers [email protected] > (que j'ai mis en copie) où elle sera toujours un peu HS, mais moins car une > telle application pourrait servir à OSM
Désolé, mauvais réflexe. >> Informations prises auprès d'eux, le dit >> volume de données correspond à environ 50000 traces GPX utilisées en >> tant que fond de carte. > > Whaou !!! C'est pas lent que ça doit être, mais escargotesque. > Sans vouloir me défiler dans la tentative de trouver une solution à un tel > problème, j'aurais tendance à dire que la première bonne solution consiste à > trouver un moyen autre pour résoudre le problème d'origine. > Car je ne vois pas trop dans quel cas on peut être intéressé par l'affichage, > en dynamique, d'une telle quantité de traces. > > On peut avoir une idée du cas d'usage ? En fait, je crois avoir compris que ce sont des traces relatives à des chemins forestiers, d'où ma suggestion d'enrichir OSM. A partir de ces données, j'imagine qu'il calcule des itinéraires. De l'aveu de l'utilisateur, ce qui est particulièrement dommage, c'est qu'en général, moins du tier des données est nécessaire à son travail. >> convertir ces traces en fond de carte et utiliser directement ce fond >> de carte. > > J'ai déjà utilisé cette solution qui en effet permet d'accélérer la > phase "affichage à l'écran" au coût qu'il faut pré-calculer d'une manière ou > d'un autre pour créer ces images à l'avance. > Car, si le but est de faire un affichage "temps réél" ben, ça ne changera pas > grand chose que tu passes par des images ou que tu utilises directement, > comme ça doit être le cas, les librairies gdk (?) pour faire vecto -> > gdk/gtk -> écran > par rapport à une chaîne vecto -> lib image (mapnik ?) -> images -> gdk -> > écran Effectivement, le but est de faire un pré-calcul une fois et de s'en servir. A nouveau, j'imagine que son jeu de données évolue peu, alors qu'il s'en sert très régulièrement. L'investissement d'une génération, fût-elle longue, doit être acceptable. >> Les contraintes : idéalement, la solution devrait être à la portée du >> plus grand nombre, sans nécessiter l'installation d'outils complexe > > Avec une telle contrainte c'est mort car je ne vois aucune solution toute > faite. Ah... ben je croyais que c'était pas si original comme problème. L'idée derrière ce "foisonnement" est assez simple : - soit la mécanique à mettre en oeuvre en externe est pas trop complexe - soit on bidouille Viking pour en faire un outil qui est capable de ce genre de prouesse. Mais vu les moyens en terme de développement (main d'oeuvre) je pense que la seconde idée est difficile. >> ou >> l'utilisation d'une configuration matérielle démesurée. > J'avais bossé sur des traces de parapente (environ 200 000 réparties sur la > france) et une machine toute bête avait suffit, la génération des zoom > faibles avait nécessité 1 ou 2 heures, mais ça restait raisonnable > >> Avez-vous des idées ? Dans ce domaine, j'ai découvert tWMS qui parait >> être un petit serveur WMS lorsque les tuiles sont déjà calculées. > > Passer par un serveur TMS ou WMS sera inutile si c'est pour faire ça sur un > poste unique, autant générer les images en local. > Si le but est de les partager à plusieurs, là oui, pourquoi pas, que ce soit > TMS ou WMS, le problème sera de toute façon : L'idée du WMS, c'est que Viking sait déjà attaquer ce protocole, alors que rien n'est codé aujourd'hui pour permettre l'utilisation d'une arborescence de tuiles arbitraire. >> Reste à trouver comment on converti 50000 fichiers GPX en une >> arborescence de tuiles. > > Moi j'ai fais ça : > gpx -> gpsbabel -> shapefile -> shp2pgsql -> postgresql+gis > libmapnik + fichier styles + accès base postgres -> rendu avec gen_tiles.py > (livré avec mapnik) > > Voir mon message d'il y a longtemps sur le forum : > http://forum.openstreetmap.org/viewtopic.php?id=2822 > > On doit pouvoir s'affranchir toutefois de la phase postgres avec un petit > programme en python sur la base de ce module de mapnik : > http://trac.mapnik.org/wiki/OGR > Mais il faut développer ;-) L'étape postgres me semble être (de loin) celle qui pourrait faire le plus peur : mise en place d'une BD de ce gabarit. Est-il possible de faire le même genre de chose avec des BD beaucoup plus simple à déployer telle que sqlite (spatialite je crois) ? -- Guilhem BONNEFILLE -=- JID: [email protected] MSN: [email protected] -=- mailto:[email protected] -=- http://nathguil.free.fr/ _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
