[OSM-dev-fr] Précisions à propos du format XML OSMChange

[Philippe Verdy]

Un autre truc que ne fait toujours pas correctement JOSM c'est minimiser
l'impact de ce qu'on doit faire en cas de conflits détectés lors des envois
d'objets à modifier ou à supprimer:
Comme OSM accepte des envois par lots, il peut y avoit de nombreux lots
intermédiaires entre les objets vides à créer et leur utilisation dans
d'autres objets.
De fait on commence souvent par envoyer de gros lots de noeud vierges de
tout tag qui ne seront utilisés que lors de l'envoi bien plus tard des
chemins ou relations qui les utilisent.

Idéalement, on devrait tenter de réduire cet écart dans les lots envoyés en
assurant de compléter intégralement et le plus vite possible (avant les
autres) les objets qui utilisent les objets déjà envoyés.

C'est d'autant plus critique que les créations d'objets (noeuds chemin ou
relations) se font de façon très éloignée, et que ce n'est ensuite que lors
des étapes d'envois d'objets créés plus tard ou pire ceux qui sont
modifiés, que ces nouveaux objets vont être utilisés dans la base, et que
ce n'est que lors des envois d'objets à modifier qu'on va détecter des
conflits d'édition.

Les premiers conflits d'éditions se produisent donc souvent très tard,
alors qu'on a déjà envoyé beaucoup de nouveaux objets, et que cela
complique sévèrement la récupération en cas de problème (conflit d'édition,
ou même problème réseau interrompant la session en cours).

Un tri topologique devrait donc toujours être réalisé afin que les envois
de données vers la base OSM soient terminés le plus tôt possible dans un
état cohérent. Sinon on se retrouve facilement avec la base laissant des
tas d'objets inutilisés (et souvent même sans aucune balise quand il s'agit
des noeuds qui se retrouvent orphelins).

La gestion des erreurs et la facilitation des situations de récupération
d'erreurs de dessions ou de conflits d'édition doit être pensé assez tôt,
sinon la tâche qui incombe à l'utilisateur pour nettoyer ça prend un temps
fou et est particulièrement complexe (même les outils poru faire un revert
ont du mal à gérer les dépendances pour faire ça proprement).

Pour des grosses modifs (contenant nécessairement plein de travaux de
préparation, de fusion et d'intégration), les conflits d'édition sont
inévitables, surtout dans des zones denses ou étendues.

Là dessus les outils (pas seulement JOSM) peuvent encore et devraient
s'améliorer sur la façon dont ils ordonnent les envois au serveur. Car on
passe énormément plus de temps souvent à gérer les conflits d'édition (aevc
un gros risque de commettre des erreurs pour les résoudre manuellement)

Et ce n'est même pas plus facile non plus d'abandonner en cours et vouloir
faire un revert complet (les reverts sont encore une affaire de
spécialistes qui savent jongler avec les dépendances d'objets, sélectionner
manuellement des sous-listes d'objets à envoyer d'abord avant les autres...
alors qu'une machine ferait les choses bien plus facilement et plus
proprement en procédant dans le bon ordre)
.


Le 22 décembre 2013 22:14, François Lacombe <
francois.lacombe at telecom-bretagne.eu> a écrit :

> Pas de soucis Christian.
>
> Le format OsmChange concerne l'appel changeset/#id/upload de l'API v0.6
> Normalement je vais essentiellement traiter des input JOSM mais je ne sais
> pas ce qu'il utilise de l'API, je me contente d'implémenter le protocole en
> entier.
>
> J'ai pas la même structure qu'OSM mais j'ai les mêmes primitives.
> Du coup pas de soucis, seuls les nœuds sont porteurs des coordonnées chez
> moi aussi. Nul besoin d'avoir la voie dans le fichier OsmChange si la liste
> de ses membres n'est pas modifiée.
>
> Tout le travail consistait à traduire mes objets au format OSM et à bien
> interpréter les documents en retour.
> Après c'est du gâteau.
>
>
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
>
> Le 22 décembre 2013 22:07, Christian Quest <cquest at openstreetmap.fr> a
> écrit :
>
>>  Je ne sais pas quels fichiers osmChange tu vas traiter, mais pour les
>> changeset issus des diff des serveurs OSM, il faut prendre en compte un
>> truc important: tu peux avoir un changement sur un noeud qui impactera des
>> ways sans que les ways ne figurent dans le changeset. Leur géométrie est
>> modifiée, mais pas leur définition.
>> Pareil pour les relations...
>>
>> C'est compréhensible sur le plan base de données relationnelle, ça l'est
>> beaucoup moins pour une base de données géographiques.
>> C'est ce qui fait toute la complexité d'osm2pgsql (et autres) sur la
>> gestion des diffs...
>>
>> _______________________________________________
>> dev-fr mailing list
>> dev-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>>
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20131222/96cecb98/attachment-0001.html>