<html><body><div style="color:#000; background-color:#fff; font-family:Courier New, courier, monaco, monospace, sans-serif;font-size:10pt"><div><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> De :</span></b> Philippe Verdy <verdy_p@wanadoo.fr></font></div><div><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>J'ai bel et bien parlé *explicitement* de références dont l'utilité<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>n'est que *temporaire*, liée à un projet de suivi d'une migration de<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>données (qui a une fin estimée prévisible). Ces données temporaires<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>n'ont pas leur place dans la base OSM,
pusiqu'elles sont dès le départ<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>non pérennes, même si elles associent des sources stables (en cas de<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>remise à jour, c'est une *nouvelle* tâche de maintenance qui commence<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>avec sa *propre* liste temporaire de suivi, inutile de collectionner<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>des anciennes références de suivi qui n'ont pas lieu d'être).</div><div><br></div><div><font face="Arial" size="2"></font><span>Pour une meilleure comprehension est ce que tu peux donner explicitement les exemples de references a l utilite temporaire dont tu parles ?</span></div><div><span>J ai beau relire ton
mail je ne vois pas ou tu les mentionnes explicitement...</span></div><div><br></div><div>d ailleurs je te recite :</div><div> "puisque ces données de suivi<br>peuvent être stockées ailleurs, et mises en relation en utilisant les<br>numéros de référence d'OSM (numéro de nœuds, de chemins ou de<br>relation)"</div><div><br></div><div><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>Oui je sais que des ID d'objets pourraient ne pas être stable dans<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>OSM, mais si ces objets sont déjà référencés à une source stable, il<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>n'y a pas de raison qu'ils se dupliquent et qu'on ait à les fusionner<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>ensuite
vers un autre ID d'objet OSM (mais même dans ce cas là, les<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>éditeurs comme JOSM conservent l'identifiant le plus ancien lors de la<br><font face="Arial" size="2"><b><span style="font-weight:bold;">>>>> </span></b></font>fusion d'objets, pour minimiser le risque de casser des liens).</div><div><br></div><div>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. <br></div><div>quelle est donc ta proposition technique exacte ?</div><div>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 ?<br></div><div>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.</div><div><br></div><div>Julien<br></div><div><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; margin-top: 5px; padding-left: 5px;"> <div style="font-family: Courier New, courier, monaco, monospace, sans-serif; font-size: 10pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <font face="Arial" size="2"> <hr size="1"> <b><span style="font-weight:bold;">De :</span></b> Philippe Verdy <verdy_p@wanadoo.fr><br> <b><span style="font-weight: bold;">À :</span></b> Discussions sur OSM en français <talk-fr@openstreetmap.org> <br> <b><span style="font-weight: bold;">Envoyé le :</span></b> Lundi 20 février 2012 13h47<br> <b><span style="font-weight:
bold;">Objet :</span></b> Re: [OSM-talk-fr] Re : Re : Accès KO au suivi des communes<br> </font> </div> <br>Vous n'avez pas lu !!!<br><br>J'ai bel et bien parlé *explicitement* de références dont l'utilité<br>n'est que *temporaire*, liée à un projet de suivi d'une migration de<br>données (qui a une fin estimée prévisible). Ces données temporaires<br>n'ont pas leur place dans la base OSM, pusiqu'elles sont dès le départ<br>non pérennes, même si elles associent des sources stables (en cas de<br>remise à jour, c'est une *nouvelle* tâche de maintenance qui commence<br>avec sa *propre* liste temporaire de suivi, inutile de collectionner<br>des anciennes références de suivi qui n'ont pas lieu d'être).<br><br>Oui je sais que des ID d'objets pourraient ne pas être stable dans<br>OSM, mais si ces objets sont déjà référencés à une source stable, il<br>n'y a pas de raison qu'ils se dupliquent et qu'on ait à les fusionner<br>ensuite
vers un autre ID d'objet OSM (mais même dans ce cas là, les<br>éditeurs comme JOSM conservent l'identifiant le plus ancien lors de la<br>fusion d'objets, pour minimiser le risque de casser des liens).<br><br>Je n'ai JAMAIS parlé ici des "ref" (ou de façon moins ambigüe,<br>"ref:INSEE", "ref:NUTS", "ref:SANDRE"...) dans ce que vous citez, mais<br>de références qui sont uniquement valides pour une version spécifique<br>d'une source (collectée à une date donnée, ces références n'étant pas<br>stables non plus) ! Mettre dans la base des données instables mettant<br>en relation deux jeux instables de données, c'est une pollution (qui<br>plus est, elle ne permet même pas la collaboration).<br><br>Gardez donc vos "snapshots" de données externes à importer pour vous :<br>gérez vos listes de suivi vous-mêmes, mais ne mettez pas ça dans la<br>base OSM. Et c'est bien dans ce sens que je suggérais d'utiliser<br>d'autres moyens (feuille de
calcul, fichier CSV, page de projet<br>datée...)<br><br>Je maintiens donc TOTALEMENT ce que j'ai écrit ! La prochaine vois<br>vous lirez mieux avant de répondre, surtout ce que vous indiquez en me<br>citant, sans même avoir pris le temps de comprendre (ou visiblement<br>même de seulement "lire") ce que vous citez ! Car j'avais mis assez de<br>précaution dans ce que j'ai écrit pour que vous n'alliez pas faire une<br>généralisation hâtive sur ce que j'aurais écrit, une généralisation<br>totalement contraire totalement au but de mes précautions initiales.<br><br>Le 19 février 2012 13:47, Christian Quest <<a ymailto="mailto:cquest@openstreetmap.fr" href="mailto:cquest@openstreetmap.fr">cquest@openstreetmap.fr</a>> a écrit :<br>> Le 19 février 2012 11:36, THEVENON Julien <<a ymailto="mailto:julien_thevenon@yahoo.fr" href="mailto:julien_thevenon@yahoo.fr">julien_thevenon@yahoo.fr</a>> a écrit :<br>>>>>>>
De : Philippe Verdy <<a ymailto="mailto:verdy_p@wanadoo.fr" href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a>><br>>>>>>> Parfois aussi, il est inutile d'importer dans la base OSM des tags<br>>>>>>> dont l'utilité n'est que temporaire et correspond à une tâche de<br>>>>>>> maintenance ou de migration de données, puisque ces données de suivi<br>>>>>>> peuvent être stockées ailleurs, et mises en relation en utilisant les<br>>>>>>> numéros de référence d'OSM (numéro de nœuds, de chemins ou de<br>>>>>>> relation), le plus souvent sur une page web dédiée à ce travail sous<br>>>>>>> forme de tables (fichiers CSV faciles à générer et traiter avec des<br>>>>>>> tonnes d'outils, feuilles de calcul Excel ou Openoffice, tableaux<br>>>>>>> wiki, base de donnée MySQL ou
similaire)...<br>>>>>><br>>><br>>> Les donnees OSM ne sont pas figees, se pose alors le probleme de la<br>>> coherence avec les tables externes que tu mentionnes...<br>>><br>><br>> Surtout que les ID des objets OSM ne sont pas pérennes.<br>> Par exemple, un node décrivant un POI peut disparaitre pour retrouver<br>> ses tags sur le way du bâtiment.<br>><br>> C'est donc dans OSM qu'il faut stocker des références pérennes vers<br>> l'extérieur (les différents ref et ref:xxx).<br><br>_______________________________________________<br>Talk-fr mailing list<br><a ymailto="mailto:Talk-fr@openstreetmap.org" href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br><br><br> </div> </div> </blockquote></div> </div></body></html>