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