Je me demande si le problème de rendu de ces zones boisées n'est pas
qu'un symptôme, et que le vrai souci est sur les zones naturelles.
Celles-ci sont taggées avec
boundary=protected_area
ET
leisure=nature_reserve
2 couples clé/valeurs pour dire quelque chose d'assez proche, ce n'est
pas une
Le 05/11/2016 à 20:10, osm.sanspourr...@spamgourmet.com a écrit :
Mais la personne a considéré cette zone non comme une forêt mais comme
un bois... d'environ 200 km de large.
Or un bois c'est petit et donc pas à représenter de loin.
Je te laisse corriger ou mieux lui signaler qu'il doit
Mais la personne a considéré cette zone non comme une forêt mais comme
un bois... d'environ 200 km de large.
Or un bois c'est petit et donc pas à représenter de loin.
Je te laisse corriger ou mieux lui signaler qu'il doit considérer cette
zone comme une forêt.
N'est-ce pas lié au problème de retards de synchro sur la base de données
(qui concerne les planet dump et les minute diffs) qui commence maintenant
à durer d'une façon alarmante, et qui empêcherait le rendu OSMFR de
récupérer des données à jour ?
Le 5 novembre 2016 à 15:08, Adrien Grellier
Bonjour,
Effectivement ça semble voulu. Mais c'est très bizarre de voire une zone
si grande disparaître sur un zoom !
Ici en amazonie, il y a une zone intéressante aussi :
http://tile.openstreetmap.fr/?zoom=9=-11.26854=-64.31764=B000FF
Si on dézoome deux fois (zoom=7), la zone de forêt
Bonjour,
que nenni, c'est juste le rendu qui est radicalement différent entre les
niveaux de zoom 10 et 11.
Ici c'est plus clair, la mine étant entourée de zones de couleurs
différentes :
http://tile.openstreetmap.fr/?zoom=10=51.05269=6.45079=B000FF
Bonjour,
Le rendu OSMFR semble souffrir d'un problème de raffraîchissement. Par
exemple, cette mine au Canada apparaît à un zoom:
http://tile.openstreetmap.fr/?zoom=11=57.29278=-111.57124=B000FF
mais disparaît si on dé-zoome:
7 matches
Mail list logo
