Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM
mon anglais est tres mauvais :( , c'est ce qui est proposé par overpass ? http://lists.openstreetmap.org/pipermail/dev/2012-August/025487.html ___ 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
SUPER ! Y'a plus qu'à tester leur utilisation et vérifier leur contenu mais ça semble assez complet pour éviter de faire des requêtes inutiles dans la base juste pour la mettre à jour. Le diff contenant toute la hiérarchie des objets impactés, il est suffisant pour recalculer les géométries. 2012/8/28 didier2020 didier2...@free.fr: mon anglais est tres mauvais :( , c'est ce qui est proposé par overpass ? http://lists.openstreetmap.org/pipermail/dev/2012-August/025487.html ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- 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
2012/8/28 Christian Quest cqu...@openstreetmap.fr: Le diff contenant toute la hiérarchie des objets impactés, il est suffisant pour recalculer les géométries. Pas tout. Manque les membres de relations. Ca ferait trop sinon (lire la suite du fil de discussion). Pieren ___ 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
Oui, tout à fait et c'est suffisant je pense pour donner déjà un gros coup de boost. Le choix de recalculer les géométries des relations est, je pense, moins systématique que celles des ways. Le 28 août 2012 11:52, Pieren pier...@gmail.com a écrit : 2012/8/28 Christian Quest cqu...@openstreetmap.fr: Le diff contenant toute la hiérarchie des objets impactés, il est suffisant pour recalculer les géométries. Pas tout. Manque les membres de relations. Ca ferait trop sinon (lire la suite du fil de discussion). Pieren ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- 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
On mardi 28 août 2012, Christian Quest wrote: SUPER ! c'est en effet une super nouvelle, ça ouvre la voie à des mises à jour plus rapides, des mises à jour de zones réduites. Y'a plus qu'à tester leur utilisation Pour ça, il va falloir coder un peu pour que les outils habituels en profitent -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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
+1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où l'idée de parle d'updates et plus de diff. Oui, pardon, j'avais bien compris que tu ne parlais pas de leur suppression, je me suis mal exprimé. La question que je me posais était plutôt qui devrait être en charge de cette génération et tu semblais (?) suggérer que la fondation OSM s'en charge. Bien que s'ils le proposaient, j'en serais ravis, je me demande s'ils n'ont pas déjà assez de boulot et que c'est quelque chose que quelqu'un d'autre (asso osm-fr par exemple) puisse prendre en charge. Pour ce qui est de la suite, je pense que c'est la réalisation qu'il faudrait entamer, et plutôt que dans le vent, appliqué à un besoin réél. Mais là, j'entrevois pas mal de boulot... -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ 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 15:44, sly (sylvain letuffe) li...@letuffe.org a écrit : +1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où l'idée de parle d'updates et plus de diff. Oui, pardon, j'avais bien compris que tu ne parlais pas de leur suppression, je me suis mal exprimé. La question que je me posais était plutôt qui devrait être en charge de cette génération et tu semblais (?) suggérer que la fondation OSM s'en charge. Bien que s'ils le proposaient, j'en serais ravis, je me demande s'ils n'ont pas déjà assez de boulot et que c'est quelque chose que quelqu'un d'autre (asso osm-fr par exemple) puisse prendre en charge. La frontière entre fondation ou pas est pour moi relativement artificielle. Prends l'exemple des extraits par pays de geofabrik. Ils sont très utilisés bien que ça ne soit pas des machines de la fondation qui les génèrent. Si ces fichiers d'updates sont très utilisés, la fondation pourra pérenniser si besoin leur génération. Pour ce qui est de la suite, je pense que c'est la réalisation qu'il faudrait entamer, et plutôt que dans le vent, appliqué à un besoin réél. Mais là, j'entrevois pas mal de boulot... Je n'ai pas encore tellement réfléchit à l'implémentation, mais je pense qu'il doit s'appuyer sur un schéma osmosis modifié. Pour avoir du grain à moudre et d'autres visions sur ce qui se fait, la dernière version de l'overpass API intègre un mécanisme proche de ce dont on parle, mais pas pour les diffs (uniquement pour l'import initial) : http://wiki.openstreetmap.org/wiki/Overpass_API/versions Son idée, pas idiote, est que toute instance de l'overpass API peut être clonée afin de re-construire une base à jour à l'identique. Je ne connais pas les entrailles précisément, mais le résultat annoncé est de ~4/8 heures pour un import de la base monde, là où, en partant d'un fichier planet.osm il faut ~20 heures Cela permet donc une topologie en multi-pyramide où chaque nouvelle instance peut se greffer sur une existante et gagner du temps pour la construction initiale. En revanche, ce mécanisme n'existe pas (encore) pour les diffs Et à mon avis, c'est du super spécifique à ce format, je doute qu'il est voulu à la base un format générique J'ai vu cette possibilité en voulant installer une overpass API. Il me semble que cela consiste essentiellement à copier un snapshot des fichiers d'une overpass à une autre, non ? Il y a un mécanisme plus perfectionné que ça ? -- 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
J'ai vu cette possibilité en voulant installer une overpass API. Il me semble que cela consiste essentiellement à copier un snapshot des fichiers d'une overpass à une autre, non ? Il y a un mécanisme plus perfectionné que ça ? Je viens de vérifier et en fait, ça consiste juste à ça en effet, toutefois, il y'a un appel prévu pour demander à l'overpass source de préparer ces fichiers (ce n'est pas fonctionnel par défaut sur une instance neuve, juste celle de http://overpass-api.de/) qui s'occupe alors d'en faire une copie, de les compresser et de les rendre disponible à un téléchargement. C'est un peu brut de script comme on pourrait par exemple récupérer un dump SQL d'une base osm2pgsql pour la dupliquer plus rapidement. Mais l'idée reste celle-ci : ne pas toujours repartir du fichier planet.osm (et ça à aussi l'avantage d'exister) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[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
