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

[Philippe Verdy]

En gros les données d'un changeset ne sont pas traitées dans n'importe quel
ordre:
- d'abord tous les "create" sont traités (dans l'ordre: [1]tous les noeuds
créés, puis [2]tous les chemins créés, puis [3]toutes les relations créées)
- puis tous les "modify" ([4]ordre indifférent)
- puis tous les "delete" (dans l'ordre: [5]toutes les relations supprimées,
puis [6]tous les chemins supprimés, puis [7]tous les noeuds supprimés)

Il y a une difficulté aux étapes [3] et [5] concernant les dépendances
mutuelles entre les relations. En cas de référence cyclique entre deux
relations à supprimer, il fait d'abord briser la référence cyclique en
modifiant une d'elles à l'étape [4] pour commencer en supprimans ses
membres référents dont un d'eux est à effacer, ce qui permet de supprimer
alors l'autre relation qui n'a plus de référence, puis ensuite de supprimer
la première relation qui na déjà plus de membre.

De même cette difficuté existe en cas de création de références cycliques
entre deux relations nouvelles : on commence par créer chaque relation mais
sans le membre de la première qui référence la seconde relation pas encore
créée.

Les listes de noeuds, ou de chemins aux étapes 1, 2 , 6 et 7 n'ont pas
d'ordre interne.

Le plugin Reverter de JOSM ne sait toujours pas cependant traiter
correctement l'ordre d'envoi (nécessitant plusieurs versions dans le même
changeset pour la même relation) pour les listes de relations des étapes 3
et 5 : l'ordre topologique est partiel et ne sait pas traiter les
références cycliques.

D'une façon générale les références cycliques entre relations sont à éviter
dans la base, mais la base OSM ne l'interdit pas du tout, et on a vu de
gros plantages dans JOSM ou dans les outils de rendus à cause de ça
 (boucles infinies, débordement mémoire de la pile, explosion de quota en
temps CPU ou mémoire). processus figé, voire même OS planté si ça survient
dans une procédure critique d'affichage (bogue que j'ai signalé dans JOSM
et pour lequel il y a une correction depuis des mois) !

On trouve ces références cycliques dans la base pour certaines relations
ayant des membres de rôles "applies_to" et "defaults".



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

> Merci Pierre pour cette réponse.
>
> Le 22 décembre 2013 20:26, Pierre Béland <pierzenh at yahoo.fr> a écrit :
>
> François,
>>
>> Voici une partie des réponses. Je vais laisser à d'autres traiter des
>> relations.
>>
>> À partir de l'historique de openstreetmap.org, si nous regardons
>> l'historique d'un changeset particulier, il nous est offert de voir
>> l'historique au format osmchange. Et effectivement, il est donc possible de
>> voir toutes les transactions effectuées dans la base OSM avec ce changeset.
>>
>> Voir par exemple
>> http://www.openstreetmap.org/api/0.6/changeset/19585655/download, où on
>> voit clairement des objets
>>
>> - créés  <create>  le id n'est pas négatif, mais correspond plutôt à
>> celui attribué lors de la sauvegarde
>> - modifiés <modify> et effectivement avec un no. de version plus grand
>> que 1, correspondant à celui attribué lors de la sauvegarde
>> - effacés <delete>
>>
>
> Je n'ai pas pensé à faire un appel download pour me rendre compte, c'est
> très instructif.
>
> Je n'avais pas pris au sérieux la mention "in fact, *all* *id* attributes
> in create elements are treated as placeholders whether negative or not."
> mais il y a bien plusieurs create, modify ou delete.
>
>
>
>> Un noeud déplacé ne change pas d'id. C'est la géométrie qui change (ie.
>> lat et lon).
>>
>
> Ah oui ça c'est une chose qui m'avait échappé, on a des identifiants
> logiques plus que des numéros d'enregistrement.
> Ça résout une bonne partie des cas auxquels j'avais pensé.
>
> Néanmoins, qu'est-ce qui m'assure que si plusieurs nœuds et une voies sont
> créés, la voie sera après la liste de tous les nœuds ? Pour ne pas la
> digérer avec des références vers les nœuds négatives.
>
> Dans les autres cas, create sera traité avant modify. Si la voie existe et
> qu'on lui ajoute un nœud, elle sera forcément traitée après le nœud donc
> avec la bonne référence.
>
>
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
> _______________________________________________
> 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/3c00a2fe/attachment.html>