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