sly (sylvain letuffe) a écrit : > On mardi 6 octobre 2009, Etienne Chové wrote: >> Pourquoi passer par une base... j'ai beaucoup plus rapide !!! Lancer un >> petit programme magique : > Toujours pareil, ça dépend de ce que l'on veut en faire, pour le cas présent, > en effet ça suffit. En fait je n'avais pas vu que ça fonctionnait déjà.... mais ce n'est pas envoyé au front-end je crois...
> My god ! J'ose pas dire combien ça m'a pris de temps avec téléchargement > depuis l'API. Pour avoir cette rapidité je ne lis pas tout le fichier ; je fais de la dichotomie pour trouver les éléments dont j'ai besoin. En indexant le fichier, je pourrai encore gagner mais j'ai pas encore eu le temps de le faire. L'avantage est que c'est presque up2date (dump du jour), c'est rapide, ça ne charge pas l'api, ça n'utilise pas de bdd (donc n'importe qui peut l'utiliser. Ensuite on ne compare pas des choses égales, tu télécharge tous les nodes et moi juste ceux où la relation est ouverte. > D'ailleurs vu tes résultats, le temps est sans doute pris par la lecture > disque uniquement, donc l'outil est méga-ultra rapide. Oui, c'est que de l'accès disque (moitié seek, moitié read à la louche). > (Bref, ça irait encore plus vite une fois dans une bdd :-p ) > 7.5Go de xml ~= 1Go de xml.bz2 -> 1000/50 -> 20 secondes à lire avec un > disque > à 50Mo/s Le problème est le chargement dans une BDD qui prend pas mal de temps. Rien que le parsage du fichier dans SAX on en a pour un bout de temps. Si je lance le même programme en utilisant les données de la BDD monde (synchro sur les minute-slow), cela me prend 1min06 (mais je fait une requête par demande d'élément donc c'est normal que ce soit relativement lent) ; il y a sûrement moyen d'accélérer ça avec une requête bien faite (j'en ai une dans un coin si je la retrouve). >> Il ne reste qu'à générer les fichier xml compréhensible par le >> front end... mais j'aimerai rendre ce programme générique d'abord, > D'ici peu, tu aura fais un parfait concurrent de osm2pgsql pour le traitement > des relations sophistiquées ;-) Héhé... bientôt un osm2pgsql.py ? Non, je n'en ai pas la prétention. > et voilà qui est plus propre et qui nettoie les faux positif : > http://slyserv.dyndns.org/osm/relation-11980.png C'est bizarre, on a l'impression que tu as que deux ouvertures alors que j'en ai 32 dans ma base postgres. -- Etienne _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr