[OSM-talk-fr] 1099422316.50378
1099422316.50378 ? Oui 1099422316.50378m de high en France métropolitaine dans OSM CC-by-SA. Cela veut dire qu'on a passé le cap des 1 million de kilomètres de routes et chemins ! Requête à refaire dans quelques jours en fois passé en ODbL... -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Effet(s) de bord de la migration... - plus possible de se connecter sur osm.org - plus possible d'envoyer des messages à d'autres contributeurs Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Bonjour, Donc, OSM change de licence, et FOSM évidement pas. Jusqu’à maintenant, toute contribution à OSM se répercutait dans FOSM comme dans n'importe quelle site miroir. Mais, OSM et FOSM sont désormais distincts à partir du 1er avril 2012. (fork d'où le titre) La nouvelle licence Odbl autorise t'elle FOSM à répercuter les contributions OSM (à supposer que cela soit dans leurs intentions) ? L'inverse est de toute évidence non puisque OSM élimine toutes les contributions CC by SA strict. J'arrive donc a la question qui fâche : Si je veux que mes contributions profitent aux deux projets, est il pertinent d'uploader les mêmes objets sur les deux projets ? Y a t'il (Y aura t'il) un moyen d'éviter cette contrainte ? Bon Appétit. -- View this message in context: http://gis.19327.n5.nabble.com/4-jours-pour-digerer-le-coup-de-fourchette-tp5610210p5610210.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Ce n'est pas lié directement au changement de licence (qui était déjà en place puisqu'on ne pouvait plus contribuer en CC-BY-SA), ni au nettoyage des données (qui aura lieu après le redémarrage du service, en tâche de fond), mais lié à un changement de serveur. Malgré tout, un changement de serveur de base de données aurait pu avoir lieu bien avant et pourra encore avoir lieu à l'avenir. Je ne comprends pas la nécessité d'arrêter le service pendant 4 jours, alors qu'une solution de réplication aurait pu être utilisée, même si elle prenait du temps pour tout resynchroniser, sans même arrêter le service. Je comprends la nécessité de passer à un serveur plus puissant. Pas celle d'arrêter le service pendant 4 jours. Cela donne l'impresion forte que le service n'est pas solide et tehniquement pas au point. Au lieu de charger le nouveau serveur pendant 4 jours, il aurait peut-être fallu 15 jours jusqu'à ce que le nouveau serveur soit prêt (avec juste un lag time de quelques minutes, vite rattrapé quand l'ancien serveur a arrêté d'accepter les nouvelles données), et ensuite il n'aurait fallu qu'une interruption de quelques minutes pour faire la bascule du nouveau serveur miroir en tant que serveur principal, le temps de reconfigurer routeurs parefeux ou adresses IP et redémarrer les serveurs. L'ancien servant alors de serveur de secours ou pour héberger des services hors-ligne tels que des l'exécution de certains scripts de maintenance, ou l'hébergement d'une solution comparable à OSMI/Osmose, ou l'exécution de tâches comme la génération et la compression des dumps, ou encore pour augmenter la charge utile de certaines API. Bref le projet a besoin depuis longtemps de développer une solution de réplication en ligne, et cette solution n'a pas été développée. La solution de l'arrêt complet c'est la solution de facilité mais elle nuit au projet. De meˆme la bses de données aurait pu être splittée en plusieurs parties, par secteur angulaire, un serveur frontal collectant les données de l'un ou l'autre pour les accès en lecture (avec un minimum d'objets stocké dans les deux quand il y a des références mutuelles, pour l'intégrité référencielle). Pour cela il aurait juste fallu qu'au delà d'une certaine tranche d'identifiants, chacun puisse générer ses propres identifiants uniques dans des blocs de numéros préalloués pour chacun d'eux. Si à la prpchaine panne du serveur il faut encore 4 jours pour remonter un autre serveur, c'est que le projet n'est pas assez solide. La réplication avec consolidation aurait du être en place depuis longtemps, vu la taille du projet. Le 1 avril 2012 11:03, Christian Quest cqu...@openstreetmap.fr a écrit : Effet(s) de bord de la migration... - plus possible de se connecter sur osm.org - plus possible d'envoyer des messages à d'autres contributeurs Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) ___ 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
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Bonjour, Je rejoins Philippe sur l'importance mondiale qu'a prit le projet OSM. Il serait temps de définir une politique accompagnée de ses moyens techniques pour être à la hauteur de toutes ces contributions qui font d'OSM un fabuleux projet mondial. Un genre d'architecture distribuée semble la voix à explorer. Mes 2 centimes de techos Cyrille. Le 1 avril 2012 17:22, Philippe Verdy verd...@wanadoo.fr a écrit : Ce n'est pas lié directement au changement de licence (qui était déjà en place puisqu'on ne pouvait plus contribuer en CC-BY-SA), ni au nettoyage des données (qui aura lieu après le redémarrage du service, en tâche de fond), mais lié à un changement de serveur. Malgré tout, un changement de serveur de base de données aurait pu avoir lieu bien avant et pourra encore avoir lieu à l'avenir. Je ne comprends pas la nécessité d'arrêter le service pendant 4 jours, alors qu'une solution de réplication aurait pu être utilisée, même si elle prenait du temps pour tout resynchroniser, sans même arrêter le service. Je comprends la nécessité de passer à un serveur plus puissant. Pas celle d'arrêter le service pendant 4 jours. Cela donne l'impresion forte que le service n'est pas solide et tehniquement pas au point. Au lieu de charger le nouveau serveur pendant 4 jours, il aurait peut-être fallu 15 jours jusqu'à ce que le nouveau serveur soit prêt (avec juste un lag time de quelques minutes, vite rattrapé quand l'ancien serveur a arrêté d'accepter les nouvelles données), et ensuite il n'aurait fallu qu'une interruption de quelques minutes pour faire la bascule du nouveau serveur miroir en tant que serveur principal, le temps de reconfigurer routeurs parefeux ou adresses IP et redémarrer les serveurs. L'ancien servant alors de serveur de secours ou pour héberger des services hors-ligne tels que des l'exécution de certains scripts de maintenance, ou l'hébergement d'une solution comparable à OSMI/Osmose, ou l'exécution de tâches comme la génération et la compression des dumps, ou encore pour augmenter la charge utile de certaines API. Bref le projet a besoin depuis longtemps de développer une solution de réplication en ligne, et cette solution n'a pas été développée. La solution de l'arrêt complet c'est la solution de facilité mais elle nuit au projet. De meˆme la bses de données aurait pu être splittée en plusieurs parties, par secteur angulaire, un serveur frontal collectant les données de l'un ou l'autre pour les accès en lecture (avec un minimum d'objets stocké dans les deux quand il y a des références mutuelles, pour l'intégrité référencielle). Pour cela il aurait juste fallu qu'au delà d'une certaine tranche d'identifiants, chacun puisse générer ses propres identifiants uniques dans des blocs de numéros préalloués pour chacun d'eux. Si à la prpchaine panne du serveur il faut encore 4 jours pour remonter un autre serveur, c'est que le projet n'est pas assez solide. La réplication avec consolidation aurait du être en place depuis longtemps, vu la taille du projet. Le 1 avril 2012 11:03, Christian Quest cqu...@openstreetmap.fr a écrit : Effet(s) de bord de la migration... - plus possible de se connecter sur osm.org - plus possible d'envoyer des messages à d'autres contributeurs Le soleil est revenu, ça sent la sortie mapping sur le terrain ;) ___ 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 -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
puisque tu semble si sur de ce que tu avances... pourquoi tu ne leur proposerait pas tes services pour améliorer leurs services? Il faut pas oublier que c'est un projet soutenu par une fondation et non pas par une ENTREPRISE! Il faut arrêter de vouloir du résultat comme si c’était une entreprise... soyons déja contents que le projet est mis en place et sur la base du libre et donc laissez leur le temps... je trouve meme que 4 jours c'est cours pour le volume de donnés!! pensez plutot que si se projet n'etait pas en place, de nombreux contributeurs auraient pu se rabattre sur Googlemapmaker à défaut d'un projet libre... -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610440.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 17:43, PierreV belett...@hotmail.fr a écrit : puisque tu semble si sur de ce que tu avances... pourquoi tu ne leur proposerait pas tes services pour améliorer leurs services? Il faut pas oublier que c'est un projet soutenu par une fondation et non pas par une ENTREPRISE! Il faut arrêter de vouloir du résultat comme si c’était une entreprise... soyons déja contents que le projet est mis en place et sur la base du libre et donc laissez leur le temps... je trouve meme que 4 jours c'est cours pour le volume de donnés!! pensez plutot que si se projet n'etait pas en place, de nombreux contributeurs auraient pu se rabattre sur Googlemapmaker à défaut d'un projet libre... Oui aussi ! Ca n'empêche pas de commencer à travailler sur la conception d'une architecture distribuée. Je ne connais pas les coulisses du projet, mais en pensant aux beaux serveurs et à la bande passante gracieusement offerte à l'asso OSM_FR, en se pensant qu'il en est probablement pareil ailleurs, je me dis que l'on pourrait améliorer la puissance technique tout en restant libre. C. -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610440.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 17:43, PierreV belett...@hotmail.fr a écrit : Il faut arrêter de vouloir du résultat comme si c’était une entreprise... soyons déja contents que le projet est mis en place et sur la base du libre et donc laissez leur le temps... je trouve meme que 4 jours c'est cours pour le volume de donnés!! La question du volume est hors de propos. Même pour copier plusieurs téraoctets, il ne faut pas 4 jours, (surtout avec les disques actuels puisqu'il s'agit d'installer un *nouveau* serveur tout neuf, et à rpriori plus performant encore que l'ancien). 4 jours c'est veaucoup trop long pour un service qui a pris une importance mondiale. Et faire tout dépendre techniquement d'un seul serveur, c'est suicidaire. La réplication n'est plus un luxe et aurait du être une priorité depuis longtemps (avant même le changement de licence, qui ne se fera que sur le nouveau serveur parce que les outils pour faire la migration demanderont de la performance et de l'espace de stockage, et beaucoup de travail). Aussi je comprend tout à fait qu'il ait fallu attendre un an pour changer la licence et faire la migration des données puisque l'ancien serveur n'aurait jamais tenu la charge (il avait déjà bien du mal à suivre avec juste les mises à jour actuelles des utilisateurs). Donc Ok pour le fait de démarrer le changement de licence seulement maintenant. Mais en revanche je suis très critique sur les moyens et solutions mis en œuvre pour *seulement* ne faire que changer de serveur. Techniquement il y a un problème sérieux, et si FOSM parvient lui à démarrer dès le début en partant de rien pour charger toute la base OSM, je ne comprends pas que la Fondation, bien plus riche, n'a pas pu ou su monter aussi un autre serveur et le monter en charge jusqu'à ce que son lag soit rattrapé, afin de n'arrêter le service que quelques minutes lors du basculement entre le serveur principal et le miroir. En plus je trouve cet arrêt très risqué. Qui dit qu'il n'y aura pas d'incident de migration et que cela ne prendra finalement pas plus de 4 jours ? En montant un serveur en parallèle jusqu'à ce qu'il ait réussie à tout charger, le risque d'échec restait gérable: on pouvait recommencer en cas de problème sans même rien arrêter du tout, l'échec de migration restait invisible. J'espère qu'il n'est pas question de prolonger ces 4 jours, et que dès que le nouveau serveur sera opérationnel il sera mis en ligne même si c'est avant. Mais en cas d'échec, hors de question de recommencer : on redémarre l'ancien serveur aussitôt et on va chercher à régler le problème de chargement du nouveau serveur. Je crois qu'il est incroyable d'avoir du faire un arrêt aussi long, qui était parfaitement **évitable **donc **inutile**. Et pas question d'accepter alors un nouvel arrêt de 4 jours pour recommencer en cas d'échec de la première migration de données ! OK le projet est libre mais il a aussi des responsabilités à assumer pour obtenir la confiance des contributeurs. Et certes le changement de licence était annoncé, mais PAS un arrêt total du service pendant 4 jours intervenu à la dernière minute uniquement par suite d'une *décision* (mal justifiée techniquement) et pas du tout à cause d'un incident imprévu. Il n'y avait strictement aucun besoin d'une telle précipitation: monter un nouveau serveur et le rendre opérationnel et synchornisé aurait pu se faire pendant 15 jours ou même un mois, comme l'ont fait d'autres (par exemple FOSM). Cette précipitation sur un projet de cette taille non seulement fait courrir un risque élevé pour un projet aussi important, mais justement au vu de la taille des données, ce risque d'incident (normalement réparable) ou contournable) est presque inévitable. Cette précipitation génère un stress de travail énorme sur ceux chargés de monter et maintenir les systèmes, il met en péril l'intégrité des données de façon plus importante (et il sera même impossible d'en discuter ou de trouver des contournements intelligents de certains problèmes techniques qu'OSM est incapable de prévoir, car ils sont imprévus mais surviendront avec une quasi-certitude). Bref je trouve qu'OSM a joué à la roulette russe dans l'histoire et n'est pas à la hauteur de ses responsabilités. Car cette planifiication surprise du changement de serveur, qui a pris de court tout le monde, est réellement un désastre techniquement et pour l'image d'OSM (indépendamment du changement de licence avec lequel OSM a essayé de mêler les deux projets alors que ce sont deux opérations indépendantes, toutes deux très larges et toutes deux risquées, et qui n'auraient jamais du être tentées en même temps). Car si on a eu le temps de planifier le changement de licence, rien n'a permis aux contributeurs de s'attendre à un arrêt de 4 jours (et encore, vu les moyens choisis et les risques pris, je ne suis même pas certain que dans 4 jours, le nouveau serveur sera réellement opérationnel, et réellement testé avant de commencer à faire exécuter doucement puis plus
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 01/04/2012 18:46, Philippe Verdy a écrit : [...] Je reprends ce que disait PierreV : OSM, ça repose sur une fondation et du bénévolat. Il y a de la place pour toutes le bonnes volontés. Par contre les yaka et faut-qu'on sont déplacés. Surtout sur cette liste. Je n'ai aucun moyen de reprendre et de faire quoi que ce soit de ces tellement bonnes idées qui auraient fait que tout baignerait si on avait fait comme ça, comme, je crois bien, chacun sur la liste. Si des choses ne vont pas, autant le dire à ceux qui les mettent en œuvre. Et autant leur proposer un coup de main. Mais les plaintes continuelles ou suggestions sans effets sont saoulantes. Ça n'est pas parce qu'on a du soleil en abondance ces jours-ci qu'il faut gâter le climat ! Comme disait ma grand-mère : Tu ferais bien de tourner sept fois ta langue dans ton clavier avant de poster (je crois qu'elle ne disait pas tout à fait comme ça...) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
est ce que tu pourrait raisonner dans l'autre sens en étant positif? Sa se trouve ils ont prévu 4jours d'arret... mais 3jours de travail suffi amplement si ils ne rencontrent pas de problème... et pourraient éventuellement rendre le service d'écriture dispo plus tot que les 4jours Faut pas oublier que le service lecture de la base de donnnée est actif lui... et a uniquement eu un arret pendant la nuit... ;-) -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610644.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 01/04/2012 20:13, PierreV a écrit : est ce que tu pourrait raisonner dans l'autre sens en étant positif? Sa se trouve ils ont prévu 4jours d'arret... mais 3jours de travail suffi amplement si ils ne rencontrent pas de problème... et pourraient éventuellement rendre le service d'écriture dispo plus tot que les 4jours Faut pas oublier que le service lecture de la base de donnnée est actif lui... et a uniquement eu un arret pendant la nuit... ;-) @PierreV Je crois bien qu'il écoute mais je doute qu'il entende... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 20:21, Vincent Pottier vpott...@gmail.com a écrit : @PierreV Je crois bien qu'il écoute mais je doute qu'il entende... Tu supposes... j'entends bien. C'est un avis que je tente de justifier. Vous pouvez penser que c'est « négatif », mon propos n'est pas là. J'ai déjà fait dans le passé (il y a plus de 10 ans déjà) des migrations de type Big Bang. C'est fini. Sur ce type de projet volumineux, on ne prends plus jamais un tel risque. On conçoit les projets pour que les migrations se fassent en petites étables gérables et prévisibles. Car on se rend compte toujours à la fin de telles migrations que c'était un gaspillage de ressources et que ça a coûté bien plus cher que prévu (non seulement pour la migration elle-même mais aussi pour les autres services ou personnes qui en dépendent). La Fondation a sous-estimé les coûts et va vite s'en rendre compte, et regretter sa décision. Si au moins cela influence son travail futur pour ne plus jamais prendre de telles décisions unilatérales, on y gagnera quelque chose et le projet sera viable. Sinon il perdra de sa notoriété, et ce sont d'autres projets qui en profiteront (y compris des projets commerciaux comme ceux de Google et Apple) pour prendre la place d'OSM. Maintenant il va falloir batailler ferme pour qu'OSM conserve sa place chèrement gagnée, et ne perde pas une partie significative de contributeurs qui trouveront mieux leur place sur d'autres projets (oui FOSM pourrait grandir et parvenir à dépasser OSM, on verra bien dans quelques mois si les sources qui jusqu'à présent faisaient confiance à OSM ne choisiront pas finalement une licence Creative Commons, en rejetant ODDbl, pour finalement fournir leurs données librement à FOSM). On a maintenant un vrai risque qu'OSM ne soit plus un projet de couverture mondiale (comme Google) mais un projet défendu seulement dans certains pays (comme aussi FOSM qui continuera dans d'autres pays). Puis finalement que cette division aboutisse à faire gagner à nouveau les projets commerciaux (Google se frotte déjà les mains !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Dans JOSM on n'a pas encore moyen de consolider sur deux bases ses modifs. Cela supposerait gérer la source des modifications. Cela ne serait possible que pour les créations de *nouveaux* objets, qu'il faudrait ensuite recoller séparément dans chaque base (puisque cela entrainera automatiquement des objets en doublon on non connectés). Bref trois travaux à faire et non seulement deux, et certainement pas un seul travail avec les outils d'édition actuels, qui ne savent pas encore gérer les conflits d'édition dans des couches distinctes selon les serveurs consultés ou à mettre à jour (notamment JOSM dont le système de gestion des conflits est encore très mauvais et crée une simple liste au lieu de créer une couche permettant de visualiser et comparer correctement les modifs apportées). Le 1 avril 2012 13:29, PhQ pierre.que...@sfr.fr a écrit : Bonjour, Donc, OSM change de licence, et FOSM évidement pas. Jusqu’à maintenant, toute contribution à OSM se répercutait dans FOSM comme dans n'importe quelle site miroir. Mais, OSM et FOSM sont désormais distincts à partir du 1er avril 2012. (fork d'où le titre) La nouvelle licence Odbl autorise t'elle FOSM à répercuter les contributions OSM (à supposer que cela soit dans leurs intentions) ? L'inverse est de toute évidence non puisque OSM élimine toutes les contributions CC by SA strict. J'arrive donc a la question qui fâche : Si je veux que mes contributions profitent aux deux projets, est il pertinent d'uploader les mêmes objets sur les deux projets ? Y a t'il (Y aura t'il) un moyen d'éviter cette contrainte ? Bon Appétit. -- View this message in context: http://gis.19327.n5.nabble.com/4-jours-pour-digerer-le-coup-de-fourchette-tp5610210p5610210.html Sent from the France mailing list archive at Nabble.com. ___ 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
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Pendant ces 4 jours d'arrêt, que faire d'autres que ces longues discussions qui ne vont nulle part ? Peut-être prendre du recul et voir où les efforts seraient les plus utiles. Et justement, si votre plume (ou clavier) est en mal d'écriture, pourquoi ne pas essayer entre autres d'éditer le wiki ? Il est un peu poussiéreux! Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Le 1 avril 2012 20:41, Philippe Verdy verd...@wanadoo.fr a écrit : notamment JOSM dont le système de gestion des conflits est encore très mauvais Si tu as des patchs à proposer on prend avec plaisir hein. Il y a encore beaucoup de problèmes avec le système de gestion des conflits, je ne le nie pas, mais de là à le qualifier de très mauvais... Par contre, pour la gestion multi-bases des informations, c'est en partie possible avec le tout récent plugin SDS de Frederik Ramm: http://lists.openstreetmap.org/pipermail/josm-dev/2012-March/006099.html où l'idée est de séparer les tags selon leur provenance: la base OSM ou un serveur SDS (utilisé pour HOT). Il est peut-être possible que les mécanismes qui ont été intégrés dans le noyau JOSM pour ce plugin soient réutilisables pour de la duplication d'envoi vers FOSM, si quelqu'un d'aventureux était prêt à réaliser un plugin pareil (j'avertis de suite, ça ne m'intéresse pas). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 20:56, Pierre Béland infosbelas-...@yahoo.fr a écrit : Pendant ces 4 jours d'arrêt, que faire d'autres que ces longues discussions qui ne vont nulle part ? Peut-être prendre du recul et voir où les efforts seraient les plus utiles. Et justement, si votre plume (ou clavier) est en mal d'écriture, pourquoi ne pas essayer entre autres d'éditer le wiki ? Il est un peu poussiéreux! +1 ! ces discussion interminables sur l'administration des serveurs OSM n'ont rien à faire sur talk-fr. Sauf si un sysadmin français est présent sur la liste, mais je ne crois pas. En plus du wiki OSM, comme le suggère Pierre, il y a aussi du boulot sur la partie française du wiki de JOSM, ou la traduction de JOSM sur Launchpad, pour ne citer que 2 exemples. Puis on peut aussi faire un break, c'est seulement 4 jours d'arrêt ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
J'ai aussi d'autres choses à faire, rassure-toi. En revanche le wiki ne me motive pas pour le moment. Il y a d'autres projets qu'OSM (et pas liés à la cartographie). Ces disussion doivent mener à quelquechose car le service va redémarrer, masi dans des conditions différentes. Il y aura des choses à vérifier, à commencer par une comparaison des dumps de la base avant et après le changement de serveur. Puis ensuite pour suveiller le travail du robot qui va commencer à nettoyer les données sous licence CC-BY-SA uniquement (alors que ces données proviennent d'autres données en doublon qui ont été effacées avant ou qui provenaient en fait d'autres sources que les utilisateurs qui n'ont pas accepté la licence, ces sources étant par ailleurs parfaitement compatibles avec la nouvelle licence). Je vois par exempel des points qui sont marqués à supprimer, lors qu'ils sont parfaitement identiques à des points qui étaient dans la base avant importés d'utilisateurs qui ont accepté la licence. Cela s'est produit par exemple dans le cadre de la résolution de conflits d'édition ou d'un travail de dédoublonnage, dont ce n'est pas toujours l'objet le plus ancien qui a été gardé par celui qui a supprimé l'ancien point tout en rejetant ou n'approuvant pas la nouvelle licence, ou parce qu'arbitrairement la mauvaise version a été gardée par un autre utilisateur à un moment où il n'était même pas question encore de changer de licence. Si on regarde dans le détail, une quantité improtant d'objets ont leur géométrie qui vient directement de sources publiques libres. Les données réellement provenant des utilisateurs sont celles de travaux de vectorisation sur l'ancienne imagerie Yahoo, ou bien des ajouts de petits POIs (des commerces notamment, ou des tags de commentaires). Une grande quantité des données de la base ne vient pas des utilsiateurs qui les ont inséré sans mentionner la source réelle. Dans d'autres cas, des points ont été ajoutés pour corriger les géométries en relation avec d'autres objets voisins existants, qui au départ étaient compatibles avec la nouvelle licence. Les fusions de chemins, de noeuds, de relations en doublon, etc... ont commencé bien avant. Une vérification stricte basée uniquement sur l'historique d'un objet sans tenir compte de ses voisins en doublon (qui depuis ont été supprimés) risque de casser beaucoup de choses (il faudrait pouvoir annuler une ancienne suppression d'un objet compatible, mais ces données ne sont pas téléchargées par défaut dans les outils d'édition, ce qui complique énormément le travail de récupération des historiques...). En plus je ne suis même pas certain que la nouvelle base contiendra tous les historiques d'anciens objets supprimés. Car le processus de migration n'a de serveur pas été documenté (et dans l'urgence des 4 jours, ces données marquées comme supprimées risquent tout bonnement d'être sacrifiées, en plus du fait qu'elles ne sont déjà plus dans les dumps téléchargeables...) Il y a eu des centaines millions d'heures de travail sur cette base. En sadrifier même ne serait-ce que 1% signifiera des millionsd'heures pour rien, soit le travail de dizaines de milliers de petits contributeurs. Autant qui sont perdus pour le projet OSM et qui iront sur d'autres sans avoir l'impression que leut petite contribution, même modeste, servira à quelque chose ou à quelqu'un pendant une durée suffisante Le projet OSM n'est pourtant pas si vieux que ça, bon nombre de ces données sont encore parfaitement valides, même si on n'a pas pu contacter tout le monde ou parce qu'ils sont devenus injoignables par leur ancienne adresse, ou parce qu'ils ne peuvent de toute façon pas répondre car ils sont tout bonnement décédés sans possibiltié pour leurs successeurs d'accéder à l'ancien compte de messagerie, ou en traitement lourd dans un hôpital sans accès à leur messagerie, ou parce qu'ils n'ont plus les moyens d'avoir un accès Internet : c'est un bel hommage qu'on leur fait que d'oublier leur travail passé, tout bonnement parce qu'ils n'ont pas répondu ; hors le projet OSM est normalement destiné à être un ***développement durable***, pas un truc jetable à tout moment et après seulement une poignée d'années d'existence réellement publique. Aussi je comprend tout à fait le démarrage de FOSM, qui pour moi n'est **pas** dut tout un fork (le fork réel, c'est OSM qui l'a fait tout seul, même s'il a prévenu ses contributeurs qu'il allait le faire en sacrifiant des données anciennes, ce qui n'était pas du tout nécessaire, et reste une erreur grave : on n'a approuvé publiquement le changement de licence que pour les nouvelles contributions, mais on n'a jamais approuvé la suppression des anciennes données qui auraient du garder leur licence et rester disponibles, et meˆme encore modifiables selon les termes de l'ancienne licence et des sources réelles mentionnées ou non). Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Si t'est si mécontent de la gestion d'OSM... pourquoi tu ne monte pas ton propre projet libre verdy-géo? où tu appliquerais tout les *nombreux* conseils que tu donnes sur cette liste? @Pierre c'est ce que j'ai commencé dès hier soir en mettant à jour mon profil d'user... ;-) -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5610858.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
J'applique aussi la méthode TL;DR donc mes excuses si les phrases suivantes sont sorties de leur contexte : C'est en plus un gaspillage de ressources qui va coûter bien plus cher que prévu Je ne vois aucun coût à part le temps libre que mettent à disposition les contributeurs dans ce projet. Il a déjà eu pour effet de diviser la communauté qui soutenait le projet L'arrêt de 4 jours n'y est pour rien, c'est le manque de communication de la Fondation (c'est une habitude il parait). Et mis en exergue une prise de pouvoir inconsidérée par la Fondation et ses quelques administrateurs « autorisés » désignés par elle qui vont dans ces 4 jours prendre des décisions sacrificielles dans l'urgence Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore ! Toute bonne migration se fait par petites étapes qui passent presque inaperçues Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu quand la base sera de nouveau en ligne. la base sera beaucoup plus « nettoyée » que ce qui a été annoncé Pas de soucis à se faire vu qu'il n'y a aucun nettoyage. De même il était parfaitement possible de gérer dans la base de données des conditions de licence différentes C'est exactement ce qui est en cours, d'où l'introduction d'un nouveau champ redaction dans la base. car justement ces administrateurs n'ont pas le temps de communiquer Un admin ça administre c'est pas fait pour faire de la comm. On ne sait pas si les décisions prises sur une partie seront réversibles et si on aura même la possibilité de repérer ce qui manque Tu radotes Car le processus de migration n'a de serveur pas été documenté Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/61.html Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from PostgreSQL 8.4 to PostgreSQL 9.1 Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant celle d'un utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent accessibles même sur la nouvelle base. Oui l'historique est préservé. Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour ça. Par contre tu as raison pour l'aspect Big Bang, c'est bien pour ça que le 1er plan avec un arrêt du 27 Mars au 1er Avril pour tout faire a été rejeté par la rebuild team et qu'OSM est passé sur un bot en tache de fond pour le basculement des données en ODbL. Francisco, qui a tenté (sans succès) de faire court. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Pour moi, l'idée serait que tout ce qui est téléchargé depuis une base donnée l'est uniquement dans son propre calque (mentionnant sa source), ce calqué étant toujours en lecture seule, alors que tout ce qu'on crée ou modifie cas dans un calque séparé. Les calques sont alors comparables. En cas de conflits d'édition, les données venant de la base sont mises à jour dans le calque en lecture seule, rien n'est mis dans notre calque. De même on doit pouvoir séparer la sauvegarde locale de ces calques: les données en lecture seule vont dans un fichier cache, mais rien n'y est sauvé concernant nos données créées modifiiées. Un autre fichier est utilisé pour nos données créées ou modifiées, ce ficier contenant une référence éventuelle (pas nécessaire) au fichier de cache. Si on charge notre fichier en cours de modification, il peut toujours régénérer à tout moment le fichier de cache du calque en lecture seule. Ainsi, on pourrait travailler avec plusieurs bases simultanément: chaque base ayant son calque en lecture seule. Puisque ce sont des calques séparés, les comparaisons sont possibles. Et si les bases mentionnent des licences permettant un import compatible, on peut transférer dans l'éditeur automatiquement les données d'un calque vers notre calque de modification (qui contient la référence du calque d'origtine de chaque objet). Mais pour faire ça, il faut que la référence d'un objet (son identifiant unique) soit distingué calque par calque: les identifiants uniques utilisés dans une base ne sont pas les mêmes que les idnetifiants uniques dans une autre, meˆme si c'est le même objet. De même les identifiants uniques locaux créés par nos objets crées ou modifiés, n'ont rien à voir avec les identifiants des calques d'origine. Pour gérer cela, il sufffirait que notre cache local de modification contienne pour chaque objet un tag spécial mentionnant une liste d'identifiants, un pour chaque base d'origine). Gérer les conflits se fait alors sur la carte directement, en comparant les calques. Et non plus dans une liste d'objets très difficile à interpréter (cette liste ne permet pas réellement de comparer les géométries, uniquement les valeurs d'attributs; les références des membres de relation sont trop difficiles aussi à vériifier). Pire: dans JOSM il est impsosible de sauvegarder des modifs en cours tant qu'il y a des conflits. Si on ne fait et qu'on recharge le fichier, on aboutit à des incohérences graves (plus des tonnes de bogues tels que des pointeurs nuls, ou références introuvables, ou des chemins sans noeuds, relations sans membres) et encore plus de conflits ensuite lors d'une tentative de sauvegarde. Le problème vient en fait du format des fichiers OSM. Il y manque pour chaque objet (noeud, relation, chemin) un sous-élément contenant une liste des identifiants externes, indiquant l'origine réelle d'un objet qui aurait été modifié ou importé aussi dans une autre base, sous forme d'une courte URN (par exemple en XML, cela peut être un court préfixe de namespace attribué symboliquement, suivi d'un :, suivi de la valeur de l'identifiant externe, le namespace étant défini par un autre objet dans l'entête du fichier OSM pour l'associer à l'URL de la source avec éventuellement aussi des notes personnelles librement modifiables tels qu'une liste de tâches à faire avec cette source). Pour l'instant on mentionne les identifiants externes (par exemple les CLC_ID de la base Corine, ou les autres identifiants venant de divers bases GIS, au format OSM ou non) en tant qu'attributs, mais à mon avis c'est une erreur et ça pollue en fait les attributs, et il n'y a pas de garantie de conserver les sources comme l'impose les licences: ces identifiants externes ne sont PAS librement modifiables et ne devraient être supprimables non plus dans JOSM. En utilisant des calques séparés poru chauqe source (qu'on peut visualiser ensemble par transparence ou alternativement), plus besoin de la liste des conflits: c'est un calque calculé automatiquement (lui aussi non modifiable) qui permet d'afficher un fitlre de comparaison pour recolorer certains objets en rouge ou d'entourer les noeuds en jaune. Dès qu'on touche au calque de travail sur un objet en conflit, le calque de conflits se remet à jour tout seul (il faut un calque de conflit par base d'origne, donc si on veut synchroniser avec deux bases différentes, cela ferait 5 calques en tout (les 2 calques de cache en lecture seule, notre calque de travail, et les deux calques calculés automatiquement des conflits entre notre claque et les bases qu'on voulait synchroniser). Pour cimplifier l'interface, au lieu d'avoir 5 calques listés, on pourrait n'en lister que 3 (mais les deux calques des caches en lecture seule aurait un petit menu déroulant contextuel avec des cases à cocher, indiquant les comparaisons à faire entre ce calque et un des autres calques, pour que soit marqué en rouge ou entouré ceux des objets du calque courant à mettre en avant, ou pour masquer ou
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 21:54, f.dos.san...@free.fr a écrit : J'applique aussi la méthode TL;DR donc mes excuses si les phrases suivantes sont sorties de leur contexte : C'est en plus un gaspillage de ressources qui va coûter bien plus cher que prévu Je ne vois aucun coût à part le temps libre que mettent à disposition les contributeurs dans ce projet. Tu crois que la Fondation n'utilise pas des moyens financiers (matériels, services, personnels) pour faire cette migration ? Cette migration a bel et bien un coût réel, financé par les donations qu'elle reçoit, et qu'elle doit aussi gérer avec économie et de façon intelligente. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] 4 jours pour digérer le coup de fourchette
Ce que tu proposes est très éloigné d'une simple réécriture du système de gestion des conflits, c'est une énorme refonte de pans entiers de JOSM sur sa gestion des données en général. C'est pratiquement la création d'un nouvel éditeur ! Je ne sais pas si tu réalises la quantité de travail nécessaire pour réaliser un truc pareil, mais ça me semble bien au delà de nos ressources actuelles. Il est en tout cas peu probable qu'on s'investisse dans un projet tellement pharaonique s'il n'y a pas un réel besoin et une demande forte pour ça. Et non, ce genre de discussions qui s'annoncent très longues et très techniques n'ont pas non plus leur place ici. La liste josm-dev est là pour ça, merci de l'utiliser :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris)
Le 1 avril 2012 21:54, f.dos.san...@free.fr a écrit : Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore ! Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur. Toute bonne migration se fait par petites étapes qui passent presque inaperçues Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu quand la base sera de nouveau en ligne. C'est un apriori. Non décrit dans le plan de migration en court. la base sera beaucoup plus « nettoyée » que ce qui a été annoncé Pas de soucis à se faire vu qu'il n'y a aucun nettoyage. Etant donné le plan d'urgence des 4 jours donnés pour faire le travail, ils n'auront guère d'autre choix que de sacrifier une partie des données en cas de problèmes, sinon ils ne redémarrent pas ! car justement ces administrateurs n'ont pas le temps de communiquer Un admin ça administre c'est pas fait pour faire de la comm. Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur, en tout cas pas pour ce type de projet collaboratif. D'une façon ou d'une autre, s'il n'a pas le temps de le faire, il lui faut quelqu'un à côté de lui pour surveiller tout ce qu'il fait, ou des outils (journaux, etc.) permettant de tracer toutes ses actions. On ne sait pas si les décisions prises sur une partie seront réversibles et si on aura même la possibilité de repérer ce qui manque Tu radotes Non. Le rique est réel. Car le processus de migration n'a de serveur pas été documenté Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/61.html Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from PostgreSQL 8.4 to PostgreSQL 9.1 On croise les doigts pour qu'il n'y ait que ça. Ayant déjà fait des migrtions de bases de données dans le passé, on a toujours rencontré des problèmes de compatibilité sur des bases de données très volumineuses. Pour passer le problème, on sacrifie une partie des données non convertibles (ou mal converties et rejetées dans le nouveaux schéma). Après reste à résoudre le problème de ces données manquantes (à condition de les avoir identifiées, conservées à part, afin de trouver une solution ultérieure pour elles, et analyser proprement pourquoi elles n'ont pas été acceptées et ce qu'on peut faire pour les corriger. Sur des données aussi volumineuses, ces données en conflit peuvent elles aussi être très volumineuses et demander plus que 4 jours pour les convertir proprement, au moins en partie, tout en sachant précisément ce qu'on ne pourra pas préserver et pourquoi, afin de pouvoir vérifier aussi l'intégrité des données qui sont passées. Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant celle d'un utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent accessibles même sur la nouvelle base. Oui l'historique est préservé. Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour ça. Et il n'est pas inintéressant de lire les notes de compatibilité entre PosrtgreSQL 9.1 et les anciennes versions. La page suivante en donne seulement une idée sommaire (le détail est plus compliqué si on tient compte de la plateforme matérielle ou OS) : http://www.postgresql.org/docs/9.1/static/release-9-1-3.html Ainsi que les notes de bogues existants pour ces migrations. Car il y en a ! http://www.postgresql.org/docs/9.1/static/release-9-1.html Certains outils ont des bogues jugés « non critiques » comme des fuites mémoire, qui pourtant commenceront à tout planter au milieu passé un certain volume de données traitées. D'autres choses concerne la stabilité des tris et index. La compatibilité des critères d'unicité pour les collations (changement de version des bases CLDR ou Unicode par exemple). Aussi, la compatibilité des systèmes I/O (en cas de changement de version de l'OS hôte ou de son architecture matérielle). Des contraintes liées aux processeurs pour la synchronisation multithread (certaines procédures SQL qui n'avaient à priori pas besoin de synchronisation vont en avoir besoin, ou bien il y a de nouveaux deadlocks entre sections critiques, générant des erreurs SQL et des rollbacks implicites de transactions qui passaient sans problèmes avant). Des différences aussi dans la syntaxe SQL ou le support des plugins GIS, ou dans la version du noyau de VM si le moteur supporte les traitements dans une VM intégrée au moteur, tel que Java, ou des différences de comportement et de compatibilité avec d'autres plugins en code natif (certains intégrant des mots-clés, fonctions, types SQL supplémentaires, ou de nouvelles méthodes d'indexation et de recherche et jointure), ou de nouvelles restrictions de sécurité. Espérons que le logiciel a déjà été testé sur le nouveau serveur, avec
[OSM-talk-fr] Re : OSM en read-only (était : Vélib' Paris)
Comme tu n es pas en contact avec les admins de la base OSM et que tu juges leurs decisions/actions sans savoir ce qu ils font voici leurs adresses mails : Tom Hughes t...@compton.nu; et openstreet...@firefishy.com openstreet...@firefishy.com; Tu as plein de choses interessantes a leur expliquer et a leur apprendre, pense a garder au moins la liste osm-fr-dev en copie afin que nous puissions apprecier pleinements tes contributions Julien De : Philippe Verdy verd...@wanadoo.fr À : f.dos.san...@free.fr Cc : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Dimanche 1 avril 2012 23h24 Objet : Re: [OSM-talk-fr] OSM en read-only (était : Vélib' Paris) Le 1 avril 2012 21:54, f.dos.san...@free.fr a écrit : Aucune prise de pouvoir : c'est son *role* de gerer l'infrastructure et je ne vois pas ce que l'on sacrifie en faisant un pgdump + pgrestore ! Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur. Toute bonne migration se fait par petites étapes qui passent presque inaperçues Migration sur nouveau serveur et adaptation API qui vont surement passé inaperçu quand la base sera de nouveau en ligne. C'est un apriori. Non décrit dans le plan de migration en court. la base sera beaucoup plus « nettoyée » que ce qui a été annoncé Pas de soucis à se faire vu qu'il n'y a aucun nettoyage. Etant donné le plan d'urgence des 4 jours donnés pour faire le travail, ils n'auront guère d'autre choix que de sacrifier une partie des données en cas de problèmes, sinon ils ne redémarrent pas ! car justement ces administrateurs n'ont pas le temps de communiquer Un admin ça administre c'est pas fait pour faire de la comm. Un administrateur qui fait son travail son communiquer sur ce qu'il veut faire, ou a fait, n'est pas un bon administrateur, en tout cas pas pour ce type de projet collaboratif. D'une façon ou d'une autre, s'il n'a pas le temps de le faire, il lui faut quelqu'un à côté de lui pour surveiller tout ce qu'il fait, ou des outils (journaux, etc.) permettant de tracer toutes ses actions. On ne sait pas si les décisions prises sur une partie seront réversibles et si on aura même la possibilité de repérer ce qui manque Tu radotes Non. Le rique est réel. Car le processus de migration n'a de serveur pas été documenté Si là : http://lists.openstreetmap.org/pipermail/announce/2012-March/61.html Technical: pg_dump (smaug) to pg_restore -j x (ramoth). Upgrading from PostgreSQL 8.4 to PostgreSQL 9.1 On croise les doigts pour qu'il n'y ait que ça. Ayant déjà fait des migrtions de bases de données dans le passé, on a toujours rencontré des problèmes de compatibilité sur des bases de données très volumineuses. Pour passer le problème, on sacrifie une partie des données non convertibles (ou mal converties et rejetées dans le nouveaux schéma). Après reste à résoudre le problème de ces données manquantes (à condition de les avoir identifiées, conservées à part, afin de trouver une solution ultérieure pour elles, et analyser proprement pourquoi elles n'ont pas été acceptées et ce qu'on peut faire pour les corriger. Sur des données aussi volumineuses, ces données en conflit peuvent elles aussi être très volumineuses et demander plus que 4 jours pour les convertir proprement, au moins en partie, tout en sachant précisément ce qu'on ne pourra pas préserver et pourquoi, afin de pouvoir vérifier aussi l'intégrité des données qui sont passées. Alors je croise les doigts pour que les historiques complets (au moins la dernière modification par un utilisateur avant celle d'un utilisateur qui ne l'a pas acceptée ou qui l'a refusé) restent accessibles même sur la nouvelle base. Oui l'historique est préservé. Pour l'histoire de la réplication, on migre sur un PostgreSQL 9.1 justement pour ça. Et il n'est pas inintéressant de lire les notes de compatibilité entre PosrtgreSQL 9.1 et les anciennes versions. La page suivante en donne seulement une idée sommaire (le détail est plus compliqué si on tient compte de la plateforme matérielle ou OS) : http://www.postgresql.org/docs/9.1/static/release-9-1-3.html Ainsi que les notes de bogues existants pour ces migrations. Car il y en a ! http://www.postgresql.org/docs/9.1/static/release-9-1.html Certains outils ont des bogues jugés « non critiques » comme des fuites mémoire, qui pourtant commenceront à tout planter au milieu passé un certain volume de données traitées. D'autres choses concerne la stabilité des tris et index. La compatibilité des critères d'unicité pour les collations (changement de version des bases CLDR ou Unicode par exemple). Aussi, la compatibilité des systèmes I/O (en cas de changement de version de l'OS hôte ou de son architecture matérielle). Des contraintes liées aux processeurs pour la synchronisation multithread (certaines procédures SQL qui n'avaient à priori pas besoin de synchronisation
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
Et 2 minutes pour apprendre à être insultant. Le 1 avril 2012 23:47, sly (sylvain letuffe) li...@letuffe.org a écrit : Le dimanche 1 avril 2012 23:43:05, Vincent Pottier a écrit : Si ta parole n'est pas plus belle que le silence, garde le silence proverbe arabe, mais, semble-t-il issu des apophtegmes des Pères. J'en rajoute une très à propos : Il faut 4 ans pour apprendre à parler, et toute une vie pour apprendre à se taire -- sly (sylvain letuffe) ___ 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
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
tu l'as un peu beaucoup cherché... déjà si tu commençais à être beaucoup plus concis lors de tes réponses on aurait peut être une réaction autre. Mais tu persistes à faire tes grands discours... et pour continuer sur les citations: Les grands diseurs ne sont pas les grands faiseurs. Léon Martel sur ce bonne nuit -- View this message in context: http://gis.19327.n5.nabble.com/Velib-Paris-tp5385082p5611130.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
Le 02/04/2012 00:07, Philippe Verdy a écrit : Et 2 minutes pour apprendre à être insultant. Ça, non ! Moqueur, peut-être un peu quoique les choses fussent dites élégamment. Vexant, peut-être. Mais qui se sent morveux, qu'il se mouche ! Insultant, non. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM en read-only ( était : Vélib' Paris)
Continue comme ça le ton insultant avec les termes comme grand discours. Je ne cherche à insulter personne, c'est mon style, et pas destiné et parler plus fort qu'un autre. Qu'un message soit court ou long revet le même importance, chacun trouve les mots selon ce qu'il veut dire et selon l'impression qu'il a de bien transmettre ce qu'il veut dire. En revanche le ton compte pour beaucoup plus pour moi, et le tien est fortement désagréable et en plus en fait une question personnel, ce qui contraire à l'étiquette. Si ce style ne te plait pas, mais c'est pas une raison pour réagir de cette façon. Et tu n'es pas obligé de tout lire. Le 2 avril 2012 00:34, PierreV belett...@hotmail.fr a écrit : tu l'as un peu beaucoup cherché... déjà si tu commençais à être beaucoup plus concis lors de tes réponses on aurait peut être une réaction autre. Mais tu persistes à faire tes grands discours... et pour continuer sur les citations: Les grands diseurs ne sont pas les grands faiseurs. Léon Martel ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] ref_NUTS ou ref:NUTS ?
Bonsoir, Selon la page wiki FR:Key:ref, c'est la clef ref:NUTS qui doit être utilisée pour les entités administratives. Selon taginfo, c'est ref_NUTS qui est utilisé. Pour une cohérence avec ref:INSEE, je pencherai pour ref:NUTS On a quelques jours pour débattre avant de pouvoir faire des changements. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] ref_NUTS ou ref:NUTS ?
Shame on me ;) Tu peux regarder, ces ref_NUTS c'est moi qui les ai créé, à ma connaissance il n'y en a pas eu d'autres d'ajouté. Aucun problème pour moi pour les passer en ref:NUTS, c'est effectivement bien plus logique ! Le 2 avril 2012 01:08, Vincent Pottier vpott...@gmail.com a écrit : Bonsoir, Selon la page wiki FR:Key:ref, c'est la clef ref:NUTS qui doit être utilisée pour les entités administratives. Selon taginfo, c'est ref_NUTS qui est utilisé. Pour une cohérence avec ref:INSEE, je pencherai pour ref:NUTS On a quelques jours pour débattre avant de pouvoir faire des changements. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Erreur IPv6 sur openstreetmap.org
Bonjour, Ce n'est certainement pas le lieu le plus adapté pour reporter le problème, donc si quelqu'un a une adresse plus adaptée je suis preneur. J'ai une erreur quand je tente d'accéder les tuiles osm en passant pas le serveur proxy de mon FAI. Le FAI me dit que son système n'est pas en cause, mais que l'accès en IPv6 aux tuiles ne serait pas possible, d'où l'erreur. Ci dessous l'échange que j'ai eu: ,- [ ] | Le Lun 02 Avr 2012 11:11:56, \\\@/.nc a écrit : | Bonjour, si je tente d'acceder les tuiles de chez | openstreetmap.org en | | passant par le proxy, j'obtiens le message suivant: | | Bonjour, | | L'erreur suivante a été rencontrée en essayant d'accéder à l'URL : | http://a.tile.openstreetmap.org/16/63071/36927.png | | La connexion à 2a02:80:0:3ff8:222:64ff:fe2a:2714 a échouée. | | Le système a retourné : (101) Network is unreachable | | The remote host or network may be down. Please try the request | again. | | | Votre administrateur de cache est cont...@nautile.nc. | | En effet, l'accès IPv6 au serveur web de a.tile.openstreetmap.org est | indisponible, alors que sa connectivité IPv6 fonctionne bien. L'accès | IPv4 fonctionne sans soucis en revanche. | | Un proxy n'est malheureusement pas capable de retomber en IPv4 après | un échec de connexion en IPv6. | | Il serait donc plutôt souhaitable de contacter les administrateurs | système d'OpenStreetMap afin de leur rapporter cette erreur. | | Cordialement, | | L'accès direct marche très bien. | | Cordialement | Hendrik | | | | -- | Nicolas Aupetit - Nautile `- -- Cordialement Hendrik Oesterlin Nouvelle-Calédonie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
