[OSM-dev-fr] Une non base de données pour stoker les coordonnées des nodes...

[sly (sylvain letuffe)]

Salut, courageux codeur du soir !

> Petit historique qui m'a amené à cette idée:
> - j'aimerai purger un cache squid ou varnish des tuiles obsolètes en
> parsant les minute-diff

Soit ;-)

> - il faut donc maintenir une base pour avoir retrouver les coordonnées
> des noeuds

ça ne te suffira pas pour ton objectif final !

Car tu souhaites (mais tu ne le sais pas encore) aussi expirer des tuiles dans 
lesquels aucun noeud n'a été modifié. Si si ;-)

2 cas que je connais :
- ta tuile est traversée par un way dont les noeuds sont à l'extérieur
- ta tuile est intégralement incluse dans un polygone OSM que le rendu veut 
remplir (lac, forêt, etc.)

Donc, et sauf erreur, je crois qu'il te faut aussi... une base des ways et des 
relations.

 
> D'où une idée sotte et grenue de maintenir un fichier "à plat" ne
> stockant QUE les coordonnées des noeuds.
> Vu que les ID des noeuds s'incrémentent et le peu de noeuds supprimés
> sur les 1,5 milliards de noeuds créés depuis le début il n'y aura pas
> trop de place de perdue.
> Sachant que 24bits suffisent pour une précision de l'ordre de 2,5m, il
> faut 6 octets par noeuds pour stocker sa position.
> Le fichier "plat" fait 9Go pour les 1,5 milliards de noeuds actuels et
> pour récupérer la position d'un noeud il suffit d'un fseek sur l'ID du
> noeud x 6 puis d'un fread de 6 octets.

ça ne m'a pas l'air trop mal comme idée par rapport à une base de donnée avec 
des indexes sur des entiers. 
Vu de loin, on dirait que tu ré-inventes un moteur de base de donnée, mais ton 
truc semble indiquer que la récupération d'un point va bien plus vite qu'avec 
un arbre binaire

Toutefois, voir si le seek sur disque magnétique pour aller chercher 3 octets 
ne devient pas limitant.
(peut-être que la cache disque d'un noyau linux peut te sauver les meubles)


-- 
sly (sylvain letuffe)