<br><br><div class="gmail_quote">2009/10/6 Etienne Chové <span dir="ltr"><<a href="mailto:chove@crans.org">chove@crans.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">sly (sylvain letuffe) a écrit :<br>
</div><div class="im">> Boudiou ! Et étienne ré-inventa les bases de données XML.<br>
</div>Quand on a besoin que de 1% d'un fichier, je trouve ça dommage de le<br>
charger en entier dans une base de données... Est ce qu'il vaut mieux la<br>
propreté ou la rapidité ? Vaste débat...<br>
<div class="im"><br>
> Y'a un moment où il faut peut-être se rappeler que le xml est un format<br>
> d'échange, pas un format de traitement.  La dichotomie suppose très<br>
> certainement une fausse assomption que le fichier osm est trié par osm_id.<br>
<br>
</div>Oui, d'abord par type NWR puis par osm_id. A part le fichier de corine<br>
je n'ai pas encore vu de fichier pas classé comme ça... mais je suis<br>
d'accord qu'on se base sur une hypothèse bien hypothétique.<br>
<div class="im"><br>
> Mais je comprends parfaitement le problème, les serveurs osm fournissent<br>
> uniquement du xml et c'est pénible à mouliner, j'espère que bientôt on verra<br>
> des exports dans d'autres formats (le osm binaire, qui semble avoir fait un<br>
> flop semblait pourtant un bon candidat)<br>
<br>
</div>J'avais tenté un jour d'utiliser le binaire, mais il fallait 8 heures<br>
pour transformer un .osm en .bin ; au lieu de quelques dizaines de<br>
minutes pour le charger dans une BDD.<br>
<div class="im"><br>
>> ça n'utilise pas de bdd (donc n'importe<br>
>> qui peut l'utiliser.<br>
> certes, a moins de peut-être creuser les formats SQL embarqués style sqlite.<br>
<br>
</div>Ces bases de données doivent (il me semble) charger tout le contenu en<br>
RAM, donc ce sera pas possible avec mes 2Go de RAM.<br>
<div class="im"><br>
>>> des relations sophistiquées ;-)<br>
>> Héhé... bientôt un osm2pgsql.py ? Non, je n'en ai pas la prétention.<br>
> Alors, c'est p'tet moi qui le ferait avec la sortie de ton API qui lit<br>
> les .osm ;-)<br>
<br>
</div>Si tu te lances la dedans :<br>
  1. je peut te filer la dernière version du parser xml<br>
     mais je ne pense pas qu'il y ait beaucoup de différence<br>
  2. il existe des bibliothèques python qui est un portage de JTS<br>
     basé sur GEOS pour manipuler du WKT, WBK...<br>
<div class="im"><br>
>>> et voilà qui est plus propre et qui nettoie les faux positif :<br>
>>> <a href="http://slyserv.dyndns.org/osm/relation-11980.png" target="_blank">http://slyserv.dyndns.org/osm/relation-11980.png</a><br>
>> C'est bizarre, on a l'impression que tu as que deux ouvertures alors que<br>
>> j'en ai 32 dans ma base postgres.<br>
><br>
> Parce qu'entre temps, j'ai corrigé. Et que depuis j'ai même corrigée les deux<br>
> vrai positif qui existaient. J'ai maintenant un gpx complet du tour de france<br>
> (metropolitaine)<br>
<br>
</div>En parlant de ça, un jour il faudrait se faire la limite administratives<br>
réelle de la France (20miles des cotes) et non juste de la terre.<br></blockquote></div><br>+1 a tout ca. S'il y a besoin d'aide, ca m'interesse enormement. J'ai l'impression d'avoir manque une discussion hyper importante ;)<br>
<br>Emilie Laffray<br>