Le 3 avril 2013 21:32, DH <dhel...@free.fr> a écrit : > PS : et pis les relations c'est pas si compliqué que cela, sauf si elles > font 500 km² et sont traversées par 2 voies ferrés, une autoroute, un canal > à grand gabarit, qu'elles datent de 2006 et ne correspondent plus à grand > chose sur le terrain !!
Là je te rejoins totalement. Mais en fait plus la surface est grande et plus les relations sont utiles pour éviter de former un écheveau incompréhensible de traits superposés qu'on ne sait plus reconnecter à la moindre tentative de modification locale : avec une relation on manipule des ways plus courts, entrant en intersection avec beaucoup moins de choses et plus faciles à réparer : c'est bien pour ça qu'on les privilégie fortement pour les frontières administratives qui ont tendance à couvrir des territoires assez grands et très diversifiés. Alors même si pour modifier une très grande forêt on doit passer par une relation, c'est tout de même bien plus stable et plus facile à manipuler sur la carte. Les superpositions d'objets sont une vraie plaie quand ces objets sont assez grands pour en couper ou recouvrir plein d'autres, car il devient difficile de faire le tri et en fin de compte ils finissent toujours par recouvrir/masquer quelquechose à l'intérieur dans n'importe quel rendu (impossible de fixer des priorités simples comme ente les terres et l'eau, les rendus ayant tous pour parti pris de toujours dessiner l'eau par dessus les terres en les masquant (sauf la mer qui est toujours affichée en premier avec le fichier externe des lignes de côtes avant de représenter quoi que ce soit). En gros les moteurs de rendu s'en tirent en traçant les choses dans l'ordre suivant : - 1. les mers avec le fichier externes des lignes de côte (raffraichissement uniquement tous les 1 ou 2 mois, pas de rafraichissement en continu depuis la base) - 2. les landuse et les natural - 3. tout ce qui est l'eau (fleuves/rivières, canaux, lacs...) - 4. les marais semi-transparents pouvant couvrir de la terre ou de l'eau - 5. les bâtiments et autres constructions (murs, clotures, digues, barrages...) - 6. les rues/routes/chemins/sentiers et les voies ferrées (uniquement leurs traits, sans les noms) - 7. les frontières administratives ou de parcs naturels ou autre entités virtuelles non directement manifestées sur le terrain. - 8. les icônes de POI - 9. les libellés (le long des frontières ou au milieu d'une surface ou à côté d'un noeud) Au sein de chacune des 9 catégories ci-dessus, il leur est impossible de fixer un ordre d'affichage car selon les géométries il faudrait que ce soit l'un des polygones ou l'autre sans règle définissable. On doit les aider en résolvant les ambiguïtés : cela oblige à créer des trous "inner" pour permettre la séparation correcte des éléments. Et pour le faire il n'y a pas d'autre moyen que d'utiliser des multipolygones. Hors justement les forêts et les clairières sont dans la même catégorie (n° 2 dans la liste ci-dessus approximative). Il n'y a pas moyen de fixer une priorité entre les éléments, ce qui oblige à les séparer physiquement. Même si l'ensemble porte un nom (par exemple le nom d'un parc tout entier comprenant champs, jardins, bois, lacs...) : le nom devra être porté sur un élément englobant le tout, et il sera affiché soit sur sa frontière externe (au niveaux de zoom éléevés) soit au milieu de la surface à une position du centroïde calculée ou à la position indiquée par un membre "label" d'une relation. On n'est pas toujours obligé de découper les surfaces mitoyennes en multipolygones pour autant, tant que ces surfaces n'ont pas d'autre intersection commune que leur ligne de séparation. Mais dès qu'on commence à superposer 3 ou 4 tracés de polygones sur les mêmes noeuds, cela devient interfal de démêmler les écheveaux et les erreurs de manipulations deviennent de plus en plus nombreuses (beaucoup plus que qu on a fusionné les segments communs dans un chemin découpé inclus dans un multipolygone : on a moins d'objets à manipuler géométriquement, et il est plus facile de reconstruire correctement les relations. L'effet des modifications devient plus local (et il est même alors possible de manipuler ces objets depuis Potlatch, alors que celui-ci est incapable de charger des zones étendues couvrant tout le polygone et permettant de les modifier de façon cohérente. En résumé : plus les objets sont grands et courent de nombreux autres objets, plus les multipolygones sont nécessaires. _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
