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

[Christian Quest]

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