Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
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 Un noeud déplacé ne change pas d'id. C'est la géométrie qui change (ie. lat et lon). Pierre De : François Lacombe francois.laco...@telecom-bretagne.eu À : Discussions développeur OSM en français dev-fr@openstreetmap.org Envoyé le : Dimanche 22 décembre 2013 14h07 Objet : [OSM-dev-fr] Précisions à propos du format XML OSMChange Bonsoir, Une ou deux questions à propos du format OSMChange présenté sur le wiki. http://wiki.openstreetmap.org/wiki/OsmChange J'ai besoin de traiter des fichiers sous ce format, néanmoins je saisi mal la signification du placeholder modify. Ce placeholder correspondrait-il aux objets déjà connus d'OSM modifiés, donc allant disposer d'un numéro de version = 2 et d'un nouvel identifiant ? Create livre une liste d'objets à créer avec des identifiants négatifs, qui seront remplacés dans tout le document une fois l'ID connu. Est-ce la même chose avec modify ? Je suppose que l'on doit remplacer l'ancien identifiant par le nouveau dans tout le document. Enfin une chose m'échappe au niveau du traitement. Lors de la création, on remplace tous les identifiants négatifs par leur valeur fixée par le serveur. Que se passe-t-il pour modify ? Par exemple, lorsqu'un nœud est déplacé, il va apparaitre dans ce placeholder. Si il appartient à une relation/voie, va-t-elle aussi apparaitre dans modify ? L'ID du nœud va changer, comment mettre à jour les voies/relations dont il est membre si ces objets ne sont pas eux-même modifiés (donc n’apparaissent normalement pas dans le diff) ? Le traitement étant séquentiel, que se passe-t-il si il y a des références circulaires (ou bien que les objets ne sont pas dans l'ordre de leur dépendance). Que la voie à laquelle un nouveau noeud appartient est spécifiée avant celui-ci ? On va la digérer avec un nd ref=-32 potentiellement. Bref, merci par avance d'éclairer ma lanterne ;) François Lacombe francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
François, Les id négatifs, c'est le traitement effectué par JOSM par exemple avant que les données soient traitées par OSM. Ce qui nous intéresse, c'est le résultat une fois la transaction digérée par OSM. Une bonne façon de visualiser comment le tout est traité après avoir envoyé des transactions à la base OSM, c'est soit de sauvegarder le fichier osm où de regarder le fichier OSMChange. Il n'y aura plus de ID négatif, puisque le système OSM aura traité l'objet et y aura attribué un id permanent. Si j'ajoute un noeud à un chemin, je fais implicitement deux opérations : 1. creer un noeud 2. modifier le chemin pour y ajouter la référence au noeud. Un chemin est un vecteur orienté référencé par une série de noeuds. L'ordre de ses noeauds indique évidemment la progression de ce chemin dans une direction donnée. Et le système enregistre dans l'ordre la série de noeuds décrivant le chemin. Si j'ajoute le noeud au milieu du chemin, la référence aux noeuds de ce chemin sera révisée en conséquence en y placant le noeud au bon endroit. De même si je créé un objet et l'ajoute comme composante d'une relation, j'aurai implicitement deux opérations : 1. creer un objet 2. modifier la relation pour y ajouter la référence à cet objet et lui attribuer un rôle. Pierre De : François Lacombe francois.laco...@telecom-bretagne.eu À : Pierre Béland pierz...@yahoo.fr; Discussions développeur OSM en français dev-fr@openstreetmap.org Envoyé le : Dimanche 22 décembre 2013 14h41 Objet : Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange Merci Pierre pour cette réponse. Le 22 décembre 2013 20:26, Pierre Béland pierz...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
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.laco...@telecom-bretagne.eu a écrit : Merci Pierre pour cette réponse. Le 22 décembre 2013 20:26, Pierre Béland pierz...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
Pierre, Philippe, Si je me pose toutes ces questions, c'est pour reproduire l'API d'OSM et utiliser JOSM sur mon système. Je ne peux pas installer le bundle OSM directement en raison du couplage fort avec mon ORM et ma structure de données qui diffère d'OSM. J'aurais l'occasion d'en dire plus prochainement, si l'opération intéresse d'autres contributeurs. Du coup, je peux tout a fait avoir à traiter des fichiers avec des id négatifs et devoir les créer dans ma base de la même façon que sur l'API. L'ordre fourni par Philippe est tout à fait ce qu'il me fallait, on va user un peu d'XPath pour y arriver. Je n'envisageais pas l'ordre interne aux opération create et delete, la solution est maintenant là. Pour les références cycliques, je m'en remets au bon dieu et à la qualité de JOSM et des autres outils qui seraient amené à utiliser l'API. Merci pour vos indications. Affaire à suivre pour la montée en charge. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 22 décembre 2013 21:03, Pierre Béland pierz...@yahoo.fr a écrit : François, Les id négatifs, c'est le traitement effectué par JOSM par exemple avant que les données soient traitées par OSM. Ce qui nous intéresse, c'est le résultat une fois la transaction digérée par OSM. Une bonne façon de visualiser comment le tout est traité après avoir envoyé des transactions à la base OSM, c'est soit de sauvegarder le fichier osm où de regarder le fichier OSMChange. Il n'y aura plus de ID négatif, puisque le système OSM aura traité l'objet et y aura attribué un id permanent. Si j'ajoute un noeud à un chemin, je fais implicitement deux opérations : 1. creer un noeud 2. modifier le chemin pour y ajouter la référence au noeud. Un chemin est un vecteur orienté référencé par une série de noeuds. L'ordre de ses noeauds indique évidemment la progression de ce chemin dans une direction donnée. Et le système enregistre dans l'ordre la série de noeuds décrivant le chemin. Si j'ajoute le noeud au milieu du chemin, la référence aux noeuds de ce chemin sera révisée en conséquence en y placant le noeud au bon endroit. De même si je créé un objet et l'ajoute comme composante d'une relation, j'aurai implicitement deux opérations : 1. creer un objet 2. modifier la relation pour y ajouter la référence à cet objet et lui attribuer un rôle. Pierre -- *De :* François Lacombe francois.laco...@telecom-bretagne.eu *À :* Pierre Béland pierz...@yahoo.fr; Discussions développeur OSM en français dev-fr@openstreetmap.org *Envoyé le :* Dimanche 22 décembre 2013 14h41 *Objet :* Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange Merci Pierre pour cette réponse. Le 22 décembre 2013 20:26, Pierre Béland pierz...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
Note: les listes de relations à créer ou celles à supprimer peuvent se faire dans n'importe quel ordre si la création ou la suppression des relations se fait d'abord avec des listes de membres vides. Les références cycliques ne peuvent exister que dans les listes de membres des relations. C'est là qu'il faut faire attention. Une solution c'est: * ne pas créer les relations avec les membres. On se contente de créer des relations entièrement vides (et même sans aucun tag) pour gagner du temps (ou juste un tag signalant que c'est une version intermédiaire, ce qui peut faciliter la récupération en cas d'échec d'un upload), puis on met à jour toutes les relations avec tous les tags et listes de membres complètes. * ne pas supprimer directement les relations ayant des membres. Commencer par les modifier en vidant tous les tags et membres (ou en gardant juste un tag indiquant que l'objet vide de sens va être supprimé), puis envoyer les demandes de suppression des relations vides. On ne peut dans les deux cas combiner ces étapes (en une seule version et non deux par relation à créer ou à supprimer) que si on n'est sûr qu'il n'y a pas de références cycliques entre les relations à créer ou entre les relations à supprimer. Et c'est là qu'un tri topologique permet déviter de doubler le nombre de versions à envoyer. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
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 cqu...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
Le 22 décembre 2013 22:14, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : 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. Ah ok, tu implémentes une simili API pour pouvoir utiliser JOSM comme éditeur de tes données. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange
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.laco...@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 cqu...@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@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
