[OSM-dev-fr] Réflexion autour des fichiers diff OSM
Je vous propose une réflexion commune autour des fichiers diff d'OSM. Cela fait déjà quelques temps que je pense que ceux-ci sont de moins en moins adaptés à l'usage qu'on 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. J'ai dans un premier temps été étonné qu'un diff pouvait contenir la nouvelle version d'un way utilisant certains nodes sans que ces nodes ne soient présents dans le diff. Sur un plan purement base de données relationnelle, cela n'est pas choquant, mais c'est très handicapant dans notre cas où au delà des données relationnelles on va devoir recréer les géométries de chaque objet en ayant recourt à de nombreuses requêtes dans la base. Bien sûr si on ne maintenait qu'une base relationnelle sans géométrie cela serait suffisant, mais vu l'usage fait de ces fichiers c'est au final très peu efficace. Ces diff sont directement liés au fonctionnement de l'API d'OSM, fonctionnement inadapté à l'usage qu'on en fait. L'idéal serait d'avoir directement la nouvelle géométrie concernant la nouvelle version de l'objet. Comme ça pas besoin de la recréer sans arrêt comme c'est le cas actuellement. Une autre chose très peu efficace c'est que lorsqu'on ajout ou modifie juste un tag sur un way, la nouvelle version du way dans le diff ne permet pas de savoir que sa géométrie a changé ou pas. Elle est donc systématiquement recalculée... même quand cela ne sert à rien (et c'est sûrement très souvent le cas). La solution que j'évoque consiste à créer de nouveaux fichiers qu'on pourraient appeler update (pour ne pas confondre avec les diff) qui contiendraient l'équivalent du contenu actuel des diff, mais en plus contiendraient les nouvelles géométries des objets modifiés (des ways, voire pourquoi pas des relations décrivant des géométries) ou impactés par des modifications de géométries (déplacement d'un node - les géométries des objets impactés sont fournies). Inconvénients: - ils seront plus complexes à générer, c'est vrai, mais cette génération est en principe unique, alors que l'intégration est fait à des centaines voire des milliers d'instances un peu partout dans le monde, - 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. Un format moins verbeux que le XML même compressé pourrait compenser. Le pbf est-il utilisable ? J'ai aussi vu dans le wiki le format o5m qui semble intéressant au niveau du gain en volume et facilement extensible. Qu'est-ce que ça vous inspire ? -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM
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) ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM
Le 8 août 2012 01:03, sly (sylvain letuffe) li...@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 ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
