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