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) _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
