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

[Christian Quest]

Le 8 août 2012 01:03, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> 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.
>

+1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où
l'idée de parle d'updates et plus de diff.


> 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 !)
>
>
>

J'y ai aussi pensé, mais cela limite beaucoup plus le champs
d'utilisation, c'est du pur osm2pgsql.
Je pensais au moins pouvoir à partir de ces updates maintenir à jour
un schéma osm2pgsql et un schéma osmosis car les deux sont
complémentaires et relativement utilisés à ce qu'il me semble.


>> 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")
>

J'ai lu aussi une proposition de "augmented diff" (sur dev) où l'on
aurait dedans l'ancienne et la nouvelle version d'un objet, ce qui
permet des analyses sur les modifs et aussi de pouvoir faire des
retours en arrières en suivant les diffs à rebours.


>> 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 ?
>


C'est pour ces 2 raisons que je pensais plutôt limiter les géométries
ainsi traitées aux ways et voir déjà ce que ce principe apporterai en
gain de traitement en bout de chaine. Si les résultats sont bons,
pourquoi ne pas essayer alors d'aller plus loin avec certaines
relations simples de type multipolygones.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest