[OSM-dev-fr] [OSM-talk-fr] [HS] Rasterisation de traces GPX

[Guilhem Bonnefille]

Merci de cette réponse prompte.

Le 24 mai 2011 14:47, sly (sylvain letuffe) <sylvain at letuffe.org> 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 dev-fr at openstreetmap.org
> (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: guyou at im.apinc.org MSN: guilhem_bonnefille at hotmail.com
-=- mailto:guilhem.bonnefille at gmail.com
-=- http://nathguil.free.fr/