[OSM-dev-fr] Réflexion autour des fichiers diff OSM

[sly (sylvain letuffe)]

Le mardi 07 août 2012 23:26:05, Christian Quest a écrit :
> Je vous propose une réflexion commune autour des fichiers diff d'OSM.

Intéressante réflexion.

> Cela fait déjà quelques temps que je pense que ceux-ci sont de moins
> en moins adaptés à l'usage qu'on 

Il faudrait définir ce "on" et ce "usage". D'après ce que je lis après, tu 
semble surtout penser à une base osm2pgsql qui est celle à ma connaissance qui 
reconstruit le plus de géométries (surtout quand elle s'occupe des relations).
Bien d'autres import vont soit créer des géométries d'une manière différente 
(osmosis ne construit rien à partir des relations, sauf erreur, et le 
constructeur de ways n'est qu'un plugin), soit ne pas s'intéresser à la 
majorité des géométries (overpass par exemple il me semble)

J'ai donc envie de penser de prim abord : laissons les diffs d'osm tels qu'ils 
sont pour être les plus générique possibles (format .osc) et, ensuite, 
pourquoi pas, mettre en oeuvre des services qui mange ces diffs pour les re-
cracher dans un format destiné à un besoin récurrent.

Jocelyn et ses diffs france (fait ?) faisait exactement ça, manger des diffs 
internationaux pour en resortir des diffs, certes toujours au même format .osc, 
mais localisés. Donc très utiles pour réduire la charge et maintenir une base 
à couverture géographique limitée.
(de souvenir, ces diffs prenaient ~20 fois moins de temps à manger pour une 
base osm2pgsql)

Une rêve que l'on pourrait avoir, si on se focalise par exemple sur le cas 
osm2pgsql qui est un monstre mangeur d'I/O et cycles CPU, serait par exemple 
un service de génération de fichier sql prévus pour une mise à jour de la base 
osm2pgsql qu'il n'y aurait plus qu'a appliquer au fûr et à mesure que le 
service les génères (gain d'I/O en lecture garanti !)



> en fait car le constat est pour moi
> le suivant: leur intégration pour maintenir une base à jour nécessite
> beaucoup de ressources car ceux-ci ne sont pas "auto-suffisants".

Exact, ce qui interdit d'ailleurs bon nombre d'analyses qui pourraient être 
faite "au fil de l'eau" rien qu'en analysant le diff (sans base et sans "y'avait 
quoi avant")

> Inconvénients:
> - ils seront plus volumineux, c'est vrai, mais là aussi je pense que
> le surcroit de bande passante restera plus économique que les
> ressources matérielles nécessaires actuellement à la simple mise à
> jour d'une base osmosis ou osm2pgsql. 

A vérifier, une modif d'un noeud sur la relation France et si tu veux 
transmettre sa géométrie ça va chercher dans les ~15Mo (format WKT)

J'y vois aussi un autre inconvénient : (rien n'est insurmontable) il faut 
arriver à être d'accord sur ce que doit être une géométrie si tu veux 
transmettre quelque chose d'assez générique pour tous les usages
un polygone de forêt qui ne ferme pas : quelle géométrie ?


-- 
sly (sylvain letuffe)