<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Bonjour,<BR> <BR> <BR>Il s'agit de cartographier une région. Mais, il faut aussi que le pays soit cartographié. Ceci dit... les deux niveaux affichent en effet le message de trop grande taille.<BR>Pour finir : il faut que le niveau d'îlot du pays puisse être atteignable, une fois la cartographie faite.<BR><font color="#92d050"><font face="Comic Sans MS"><p align="left"><font color="#000000"><br>Cordialement.</font></font><p align="left"> </p></font><p align="left"><font color="#92d050"><em><font face="Comic Sans MS">let's be pleased with the environment</font></em></font></p><br> <BR><div><div id="SkyDrivePlaceholder"></div>> From: verdy_p@wanadoo.fr<br>> Date: Wed, 22 Feb 2012 19:48:02 +0100<br>> To: talk-fr@openstreetmap.org<br>> Subject: Re: [OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM<br>> <br>> L'autre problème du système Postgresql c'est qu'il est totalement lié<br>> à la version même du moteur. Ça manque d'ouverture et c'est une<br>> solution technique insurmontable pour un vrai travail collaboratif,<br>> alors qu'on a un schéma d'échange en XML parfaitement viable et<br>> utilisable pour l'alimentation en streaming, et indépendant du moteur<br>> utilisé.<br>> <br>> Bref, si le système de réplication Postgres est utilisé, il servira<br>> surtout à alimenter un second système local, lequel produira un stream<br>> XML qui peut alors être souscrit et diffusé efficacement (et si un<br>> client veut s'inscrire en partant de rien, il doit exister des<br>> serveurs permettant d'obtenir, en un temps plus ou moins long une<br>> image XML de base produite par un snapshot daté, tandis que le même<br>> client reçoit déjà le stream live qui contient les autres mises à<br>> jour: le premier objet du stream qu'il reçoit contient un marqueur de<br>> la date de référence à demander au serveur de snapshot, de sorte qu'en<br>> chargeant ensuite ce snapshot, les objets déjà reçus depuis le stream,<br>> et qui sont davantage à jour, ne seront pas écrasés par d'anciennes<br>> versions provenant du snapshot reçu et chargé ultérieurement).<br>> <br>> Si on ne veut pas avoir à générer autant de snapshots que de client,<br>> pour des raisons de coût/performance/espace, on peut aussi sur le<br>> serveur de snapshots n'en garder qu'un ou quelques-uns, lequel serveur<br>> peut aussi fournir aussi un stream contenant tous les objets depuis ce<br>> snapshot jusqu'à une date assez récente (qui sera postérieure à la<br>> date de souscription au stream "live" que le client lit déjà).<br>> <br>> Il reste donc juste à s'assurer que les objets du stream et ceux di<br>> serveur contiennent bien leur numéro de version afin de pouvoir<br>> retenir celui qui est le plus avancé. On n'est pas non plus obligé de<br>> mettre dans le stream ni dans le snapshot toutes les versions passées.<br>> Pour les recherches d'historique, cela se fait plutôt à la demande,<br>> objet par objet, et on peut malgré tout imaginer que les historiques<br>> soient servis par une autre base de données sur un autre serveur,<br>> destiné à la consultation des archives.<br>> <br>> Le 22 février 2012 18:35, sly (sylvain letuffe) <liste@letuffe.org> a écrit :<br>> > On mercredi 22 février 2012, Emilie Laffray wrote:<br>> >> Postgresql merde quand il y a des tables<br>> >> temporaires. C'est un bug connu qu'on espere voir corrige dans 9.2.<br>> ><br>> > Que postgresql s'améliore sur ce point c'est bien, mais je ne suis pas sûr que<br>> > ça soit la meilleure voie car cela restreindrait à postgresql là ou<br>> > des "mirroirs" dans d'autres schémas, base, formats pourraient profiter d'une<br>> > réplication temps réél.<br>> ><br>> > Mais quoi qu'il en soit, ça sera du boulot et je souhaite beaucoup de courage<br>> > à ceux qui vont se lancer dans le projet<br>> ><br>> > --<br>> > sly<br>> > qui suis-je : http://sly.letuffe.org<br>> > email perso : sylvain chez letuffe un point org<br>> ><br>> > _______________________________________________<br>> > Talk-fr mailing list<br>> > Talk-fr@openstreetmap.org<br>> > http://lists.openstreetmap.org/listinfo/talk-fr<br>> <br>> _______________________________________________<br>> Talk-fr mailing list<br>> Talk-fr@openstreetmap.org<br>> http://lists.openstreetmap.org/listinfo/talk-fr<br></div> </div></body>
</html>