Les transactions entre JOSM et l'API du projet et le rendu des tuiles sont des processus finalement assez éloignés. Et ils ne mettent pas en jeu les<div><br><div>Il y a quelques étapes intermédiaires, que l'on voit sur ce schéma :</div>
<div><a href="http://wiki.openstreetmap.org/wiki/File:OSM_Components.png" target="_blank">http://wiki.openstreetmap.org/wiki/File:OSM_Components.png</a> </div><div><br></div><div>Il ne faut pas confondre :</div><div><br>
</div><div>_ la base de données "PostgreSQL backend" (en vert) qui envoie les données vers JOSM et en reçoit ensuite les modification. Elle se trouve sur ce serveur : <a href="http://wiki.openstreetmap.org/wiki/Servers/smaug" target="_blank">http://wiki.openstreetmap.org/wiki/Servers/smaug</a></div>
<div><br>_ la base postgis (en jaune) qui est mise à jour par les "planet diffs" et qui fournit les données au moteur de rendu pour la création de tuiles. Pour le rendu "Mapnik" du site principal <a href="http://openstreetmap.org" target="_blank">openstreetmap.org</a> , c'est ce serveur qui s'y colle : <a href="http://wiki.openstreetmap.org/wiki/Servers/yevaud" target="_blank">http://wiki.openstreetmap.org/wiki/Servers/yevaud</a></div>
<div><br></div><div>-> Il y a une (1) base de transaction principale. </div><div>Mais il peut (et il y a) de multiples bases de données synchronisées par les diffs et permettant la création de rendus (*)</div><div><br>
</div>
<div>Bref, ce n'est pas parce que quelqu'un consulte les tuiles d'une zone dans son navigateur sur <a href="http://osm.org" target="_blank">osm.org</a> que cela va entrainer un engorgement lors de l'envoi de données par un autre utilisateur vers l'API pour cette même zone.</div>
<div><br></div><div>Un conflit d'édition, c'est quand plusieurs personnes chargent la même zone dans JOSM, et font des modifications différentes sur les mêmes noeuds. Au moment de l'envoi par l'API, il y a un problème potentiel.</div>
<div><br></div><div>Hors le contexte particulier de </div><div>_ mapping parties frénétiques sur des espaces très réduits,</div><div>_ de modifications concernant une zone très étendue (#jdçajdr ...),</div><div>_ de zones travaillées en local pendant de looooongues heures</div>
<div><br></div><div>mon avis est que ce genre de péripétie est possible, mais relève plutôt du fantasme en pratique.</div><div>Et en particulier pour des zones rurales. Suffit d'utiliser OSM Watch List pour savoir que la probabilité d'y voir sévir deux contributeurs au même moment est très faible.</div>
<div><br></div><div>(*) c'est donc la bonne nouvelle : OUI Mapnik a déjà sa base de données rien qu'à lui !</div><div>Et de par la moulinette osm2pgsql, les données sont en plus pré-travaillées pour lui faciliter le rendu ensuite.</div>
<div>Comme quoi, ça a déjà dû être cogité</div><div><br><div class="gmail_quote">Le 24 février 2012 16:08, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 24 février 2012 14:46, aa mail <<a href="mailto:a.a.monmail@gmail.com" target="_blank">a.a.monmail@gmail.com</a>> a écrit :<br>
<div><div>> OK, merci pour beaucoup pour ces infos.<br>
> Voici un permalink vers une des zones concernées :<br>
> <a href="http://www.openstreetmap.org/?lat=47.5163&lon=-1.8003&zoom=16&layers=M" target="_blank">http://www.openstreetmap.org/?lat=47.5163&lon=-1.8003&zoom=16&layers=M</a><br>
> Là, le rond point appelé "rond point de la belle étoile" ne s’affiche pas.<br>
> Vous pouvez aussi voir que sur la route en pointillée qui part vers nord<br>
> Nord-Est, il n'y a que le "R" de route d'indiqué. Si l'on zoom une fois, il<br>
> ne s'affiche que "route forestière de". Encore un zoom, et de même, le nom<br>
> ne s'affiche qu'en partie, puis une autre partie bout est répétée plus loin<br>
> sur la route. A droite de cette route (toujours pour ce niveau de zoom) on<br>
> trouve aussi un "r" perdu dans la forêt ;-).<br>
> Ce que dit Philippe semble coller avec ce que j'ai fait : j'ai uploadé la<br>
> zone forestière en 3 fois au lieu de l'uploader en une fois. Peut être le<br>
> mieux pour la suite serait de sauvegarder mes modifs dans JOSM puis lorsque<br>
> c'est complet, envoyer le tout ?<br>
<br>
</div></div>Malheureusement la solution d'envoyer tout en une seule fois ne marche<br>
pas toujours. Car on n'est souvent pas seul à travailler sur une même<br>
zone. De fait celle-ci sera redessinée à un niveau de zoom donné pour<br>
un autre utilisateur qui a demandé ce niveau de zoom avant vous.<br>
<br>
Et puis il y a le cas des conflits d'édition qui prennent du temps à<br>
résoudre. Pendant ce temps-là Mapnik commence à raffraîchir certaines<br>
tuiles concernées mais pas toutes. puis une autre modif arrive, Mapnik<br>
va redessiner des tuiles concernées dans un autre ordre, et croire que<br>
les tuiles voisines également concernées ont déjà été redessinées.<br>
<br>
Mapnik a un problème à identifier précisément les tuiles qui sont<br>
réellement concernées par une modification, et taille un peu "à la<br>
louche", alors qu'il devrait gérer ces tuiles à redessiner en fonction<br>
de la géométrie de sa propre charte graphique (qui se surimpose à la<br>
géométrie dans la base, dès lors qu'il convertit un trait en surface<br>
ou qu'il positionne un libellé dont la surface occupée n'est pas dans<br>
les données OSM puisque cela dépend des polices et tailles de police<br>
utilisées, ou d'autres paramètres de mise en forme de ce texte tel que<br>
des sauts de ligne pour les longs libellés attachés à un seul noeud,<br>
tels que les noms de localités).<br>
<br>
Bref il oublie des tas de trucs dans son propre calcul de géométrie.<br>
On arrive parfois à le corriger uniquement en modifiant un tout petit<br>
peu la position d'un nœud isolé au milieu de la tuile concernée (on<br>
peut presque toujours trouver au moins un nœud dont la position peut<br>
être améliorée : pas besoin de le forcer à raffraîchir une tuile qu'il<br>
a oubliée, ce seul nœud modifié devrait suffire à Mapnik pour lever<br>
les cas ambigus oubliés).<br>
<br>
Néanmoins ces incohérences de rendu liées à une géométrie défectueuse<br>
de Mapnik sont un problème et des bogues d'algorithmes de Mapnik. Là<br>
encore, Mapquest fait beaucoup mieux et ne semble pas faire autant<br>
d'oublis.<br>
<div><div><br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="http://wiki.openstreetmap.org/wiki/User:Ab_fab" target="_blank">ab_fab</a><br>"Il n'y a pas de pas perdus"<br>
</div></div>