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
