Moi je pense à n'importe quelle activité de comparaison de sources. Chaque source dispose de ses propres références, et chacune maitrise un calendrier de ses propres mises à jour et changements de modèles. Quand on commence un travail de comparaison de sources, on est bien obligé de s'attacher à une date arbitraire de prise en compte d'un "snapshot" (ou cliché).
On effectue ensuite une comparaison avec une autre source sur la base de ce cliché instantané, dont on sait à l'avance qu'il deviendra obsolète. Bref on est amené à comparer et rapprocher deux listes d'éléments, les uns après les autres. Mais une fois deux éléments rapprochés (ou non car non trouvés dans l'autre base), il n'y a strictement aucun intérêt à conserver les éléments rapprochés d'une liste ou d'une autre: on les supprime dans la liste de croisement, d'autant plus facilement que les liaisons entre deux éléments rapprochés sont fragiles. C'est le cas par exemple des identifiants de sources (dont de nombreux SIG qui ne fournissent des identifiants que temporaires correspondants à une date donnée) qui ne font l'objet d'aucune clause de maintenance et de stabilité dans le temps, ni d'un suivi exhaustif des modifications qui ont été faites aux objets qui étaient référencés par ces identifiants (contrairement à des identifiants "relativement" stable comme les références INSEE ou NUTS qui sont issus de bases de données stabilisées et versionnées ou datées). A tout le moins, si on insère un identifiant externe dans la base OSM pour un tel rapprochement, il serait nécessaire de le dater, à condition de pouvoir encore retrouver à quoi il correspondait. Si la signification d'un identifiant ne peut pas être retrouvée d'une façon accessible et ouverte pour une date historique donnée, cet identifiant externe ne sert strictement à rien dans la base OSM puisqu'il ne permet pas de rapprocher les mises à jour ultérieures. Dans un tel cas, mieux vaut alors faire une tâche de mainteance et rapprochement limitée dans le temps, avec une liste temporaire de suivi qu'on abandonnera rapidement. Ces données ont une duré de vie faible et à déterminer à l'avance avant même de commencer les importations de corrections : même si on n'a pas fini le rapprochement qu'on avait commencé, à un moment prévisible, il faut l'arrêter en cours, car tout est à refaire. Raison de plus pour ne rien stocker à ce sujet dans la base OSM quand il est bien plus simple de jeter la liste temporaire de suivie stockée séparément sans surcharge de la base partagée. Si on cherche une cohérence parfaite entre les sources, il faut se limiter dans les zones à traiter dès qu'un volume seuil de données à rapprocher est franchi; si on est dépassé par la quantité de travail à faire, mieux vaut se répartir les zones à traiter pour que chacun puisse traiter "sa" zone à laquelle ils se consacre, à charge pour lui de gérer son travail par ses propres listes de suivi (dont il sait par avance qu'elles sont incomplètes ou seront vite obsolètes). Le 20 février 2012 14:15, THEVENON Julien <julien_theve...@yahoo.fr> a écrit : >>>>> De : Philippe Verdy <verd...@wanadoo.fr> >>>>> J'ai bel et bien parlé *explicitement* de références dont l'utilité >>>>> n'est que *temporaire*, liée à un projet de suivi d'une migration de >>>>> données (qui a une fin estimée prévisible). Ces données temporaires >>>>> n'ont pas leur place dans la base OSM, pusiqu'elles sont dès le départ >>>>> non pérennes, même si elles associent des sources stables (en cas de >>>>> remise à jour, c'est une *nouvelle* tâche de maintenance qui commence >>>>> avec sa *propre* liste temporaire de suivi, inutile de collectionner >>>>> des anciennes références de suivi qui n'ont pas lieu d'être). > > Pour une meilleure comprehension est ce que tu peux donner explicitement les > exemples de references a l utilite temporaire dont tu parles ? > J ai beau relire ton mail je ne vois pas ou tu les mentionnes > explicitement... > > d ailleurs je te recite : > "puisque ces données de suivi > peuvent être stockées ailleurs, et mises en relation en utilisant les > numéros de référence d'OSM (numéro de nœuds, de chemins ou de > relation)" > >>>>> Oui je sais que des ID d'objets pourraient ne pas être stable dans >>>>> OSM, mais si ces objets sont déjà référencés à une source stable, il >>>>> n'y a pas de raison qu'ils se dupliquent et qu'on ait à les fusionner >>>>> ensuite vers un autre ID d'objet OSM (mais même dans ce cas là, les >>>>> éditeurs comme JOSM conservent l'identifiant le plus ancien lors de la >>>>> fusion d'objets, pour minimiser le risque de casser des liens). > > Oui dans le meilleur des mondes theoriques il n y pas de raison comme tu > dis... mais dans la vraie vie il y a toujours le risque que des gens fassent > des editions sans savoir, suppriment ou rajoutent des donnees si le terrain > a change par rapport a une source theorique potentiellement en retard. > quelle est donc ta proposition technique exacte ? > est ce que tu as un proto ou exemple concret qui montre que c est possible a > mettre en oeuvre et que ca donne de meilleurs resultats ? > C est un sujet qui interesse pas mal de monde la coherence et/ou la synchro > entre les donnes OSM et des "snapshots" ou bases de donnees externes donc si > tu as des propositions concretes et detaillees fais en part. > > Julien > > ________________________________ > De : Philippe Verdy <verd...@wanadoo.fr> > À : Discussions sur OSM en français <talk-fr@openstreetmap.org> > Envoyé le : Lundi 20 février 2012 13h47 > Objet : Re: [OSM-talk-fr] Re : Re : Accès KO au suivi des communes > > Vous n'avez pas lu !!! > > J'ai bel et bien parlé *explicitement* de références dont l'utilité > n'est que *temporaire*, liée à un projet de suivi d'une migration de > données (qui a une fin estimée prévisible). Ces données temporaires > n'ont pas leur place dans la base OSM, pusiqu'elles sont dès le départ > non pérennes, même si elles associent des sources stables (en cas de > remise à jour, c'est une *nouvelle* tâche de maintenance qui commence > avec sa *propre* liste temporaire de suivi, inutile de collectionner > des anciennes références de suivi qui n'ont pas lieu d'être). > > Oui je sais que des ID d'objets pourraient ne pas être stable dans > OSM, mais si ces objets sont déjà référencés à une source stable, il > n'y a pas de raison qu'ils se dupliquent et qu'on ait à les fusionner > ensuite vers un autre ID d'objet OSM (mais même dans ce cas là, les > éditeurs comme JOSM conservent l'identifiant le plus ancien lors de la > fusion d'objets, pour minimiser le risque de casser des liens). > > Je n'ai JAMAIS parlé ici des "ref" (ou de façon moins ambigüe, > "ref:INSEE", "ref:NUTS", "ref:SANDRE"...) dans ce que vous citez, mais > de références qui sont uniquement valides pour une version spécifique > d'une source (collectée à une date donnée, ces références n'étant pas > stables non plus) ! Mettre dans la base des données instables mettant > en relation deux jeux instables de données, c'est une pollution (qui > plus est, elle ne permet même pas la collaboration). > > Gardez donc vos "snapshots" de données externes à importer pour vous : > gérez vos listes de suivi vous-mêmes, mais ne mettez pas ça dans la > base OSM. Et c'est bien dans ce sens que je suggérais d'utiliser > d'autres moyens (feuille de calcul, fichier CSV, page de projet > datée...) > > Je maintiens donc TOTALEMENT ce que j'ai écrit ! La prochaine vois > vous lirez mieux avant de répondre, surtout ce que vous indiquez en me > citant, sans même avoir pris le temps de comprendre (ou visiblement > même de seulement "lire") ce que vous citez ! Car j'avais mis assez de > précaution dans ce que j'ai écrit pour que vous n'alliez pas faire une > généralisation hâtive sur ce que j'aurais écrit, une généralisation > totalement contraire totalement au but de mes précautions initiales. > > Le 19 février 2012 13:47, Christian Quest <cqu...@openstreetmap.fr> a écrit > : >> Le 19 février 2012 11:36, THEVENON Julien <julien_theve...@yahoo.fr> a >> écrit : >>>>>>> De : Philippe Verdy <verd...@wanadoo.fr> >>>>>>> Parfois aussi, il est inutile d'importer dans la base OSM des tags >>>>>>> dont l'utilité n'est que temporaire et correspond à une tâche de >>>>>>> maintenance ou de migration de données, puisque ces données de suivi >>>>>>> peuvent être stockées ailleurs, et mises en relation en utilisant les >>>>>>> numéros de référence d'OSM (numéro de nœuds, de chemins ou de >>>>>>> relation), le plus souvent sur une page web dédiée à ce travail sous >>>>>>> forme de tables (fichiers CSV faciles à générer et traiter avec des >>>>>>> tonnes d'outils, feuilles de calcul Excel ou Openoffice, tableaux >>>>>>> wiki, base de donnée MySQL ou similaire)... >>>>>> >>> >>> Les donnees OSM ne sont pas figees, se pose alors le probleme de la >>> coherence avec les tables externes que tu mentionnes... >>> >> >> Surtout que les ID des objets OSM ne sont pas pérennes. >> Par exemple, un node décrivant un POI peut disparaitre pour retrouver >> ses tags sur le way du bâtiment. >> >> C'est donc dans OSM qu'il faut stocker des références pérennes vers >> l'extérieur (les différents ref et ref:xxx). > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr > _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
