[OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM

[sukran.geo sukran.geo]

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: verdy_p at wanadoo.fr
> Date: Wed, 22 Feb 2012 19:48:02 +0100
> To: talk-fr at 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) <liste at 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 at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> 
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
 		 	   		  
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20120223/7955e930/attachment.htm>