sly (sylvain letuffe) wrote: > Le problème est aussi que les humains aiment une carte de l'endroit où il > vont, par là j'entends que rajouter des terres agricoles massives d'une > cambrousse immense n'intéresse que peu de monde par rapport au coin de forêt > ou l'étendu bâti d'un petit village ou l'on ira régulièrement se promener le > week end et qui vient d'être submergé par un polygone 400 fois plus gros... > mais dont l'intérêt pour la majorité des gens est peut-être 400 fois moins > important.
Pour ce type de rendu, les polygones CLC poseront probablement des soucis à celui qui devra le paramétrer. Mais avec des données OSM, on peut aussi faire des cartes à l'échelle d'une région, d'un pays, etc. Dans ce cas, les grands polygones CLC à faible résolution sont particulièrement pertinents. Bref, l'intérêt de ces polygones dépend de l'échelle de rendu et de ce qu'on veut représenter sur la carte. Je ne suis pas sûr qu'on puisse vraiment prédire quels usages seront faits de ces données. > > Ce problème, je le pense, pourrait peut-être se résoudre par des outils mieux > fichus, que ce soit lors de l'import : placer en inner tout les polygones à > l'intérieur du gros, redécouper autoamatiquement lorsqu'il y a intersection > ou lors du rendu : décider qu'un polygone contenu est un polygone "gagnant" > (une forêt dans une prairie est une forêt, une prairie dans une forêt est une > prairie) plutôt qu'avec un style mapnik qui défini arbitrairement > une "priorité" > > Hélas, les moyens manquent, et ces opérations ne sont sans doute pas si > simple. > Ce n'est effectivement pas simple, ni pour les développeurs du moteur de rendu, ni pour les utilisateur qui configurent les priorités. En l'étant, je ne connais pas de moteur de rendu qui gère ça (dans la sphère OpenSource en tout cas) mais je suis d'accord avec toi, ce serait vraiment une super fonctionnalité. Les développeurs de moteur de rendu risque de s'arracher les cheveux avec car ils doivent systématiquement trouver un compromis raisonnable entre performance et qualité du rendu. Or les tests d'intersection/inclusions consomment un peu de ressources. Il y a tout de même moyen de faire un rendu correct en faisant un pré-traitement sur les données exportées pour le rendu. Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
