Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/10/2010 17:02, sly (sylvain letuffe) a écrit : > Si bug il y a, il pourrait être lié au calcul de la place prise par la police > choisie. Je dis peut-être une connerie, mais son style indique une taille de > police de 40 points, hors à y regarder de plus prêt, à l'affichage, la police > semble plutôt être entre 12 et 15 points. J'ai sensiblement réduit l'image avant de vous la soumettre. J'ai environ divisé la taille par 4. > J'ai essayé sur mon rendu d'utiliser la police fontset_name="book-fonts" mais > mon système ne semble pas l'avoir. > > Étienne, si tu remplaces juste fontset_name="book-fonts" par > face_name="DejaVu Sans Bold" est-ce que ça règle ton problème ? > (sans utiliser allow_overlap="true" évidement) En entête j'ai : Donc on travaille avec la même police ;) Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9t8YACgkQtXI+41wn9OTvAgCdHFnmPQZO7hmRoitecZ/9zXVp 56YAnj+X42EaPlpVacDa/pBMgHL0QHo7 =fpob -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/10/2010 16:37, Gilles Bassière a écrit : > La surface des géométrie n'entre pas en considération dans le placement > des étiquettes. Si mes souvenirs sont bons, ce placement est fait après > tout le reste pour que les étiquettes apparaissent toujours au-dessus > des autres couches. L'algorithme utilise alors seulement les centroïdes > des géométries et positionnent les étiquettes les unes après les autres > en s'assurant qu'elles ne chevauchent pas d'autres étiquettes (en tenant > compte d'une marge). > > Si mes souvenirs sont bons, cette détection de chevauchement considère > les étiquettes de *toutes* les couches, pas seulement celles de la > couche concernée, ce qui rendrait le résultat d'autant plus > difficilement prévisible. Ok. L'algorithme semble sensiblement plus complexe que ce que j'avais supposé. >>> La vérité est ailleurs, et il faudrait faire plus de test pour savoir si ça >>> vient d'un bug de mapnik, un problème de mémoire quelque part ou autre. >> >> Probablement un bug de mapnik du coup. Car en forçant le chevauchement >> ça passe. Il sera p-e utile que je reporte ce cas de figure sur la liste >> mapnik. > > Possible que ce soit un bug mais possible aussi que ce soit une > configuration inappropriée. Le placement des étiquettes est un mécanisme > compliqué et très certainement capricieux. Il faut savoir que ce > mécanisme était un des points forts du projet dès ses débuts, j'imagine > que ça a été testé en long en large et en travers. Bref, si tu contactes > mapnik-users, mieux vaut avancer prudemment avant de parler de bug. Oui. Je commence juste à m'intéresser à Mapnik, je ne vais pas crier de suite au bug sans avoir compris le quart de son mode de fonctionnement. > La clause order by reste aussi une piste à ne pas négliger, quand tu > fais la requête à la main, est-ce que rennes et paimpont (pour reprendre > l'exemple) arrivent avant les communes qui leur sont limitrophes ? Elles sont ordonnées de manière descendante par way_area et donc Paimpont et Rennes apparaissent avant leur voisins. Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEUEARECAAYFAky9tc4ACgkQtXI+41wn9OQulgCYynnR6mI8IbV11/y0564EQPiF +wCfSk7DgD98nCeI88/JIWAZqh26Q4k= =VT3y -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
Étienne Loks wrote: > Bonjour, > > Le 19/10/2010 15:49, sly (sylvain letuffe) a écrit : >> On mardi 19 octobre 2010, Étienne Loks wrote: >>> communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). >> L'hypothèse de Gilles me semble insuffisante pour expliquer les deux que tu >> viens de citer, puisque la surface des deux communes est grande, et il y >> aurait largement la place. > La surface des géométrie n'entre pas en considération dans le placement des étiquettes. Si mes souvenirs sont bons, ce placement est fait après tout le reste pour que les étiquettes apparaissent toujours au-dessus des autres couches. L'algorithme utilise alors seulement les centroïdes des géométries et positionnent les étiquettes les unes après les autres en s'assurant qu'elles ne chevauchent pas d'autres étiquettes (en tenant compte d'une marge). Si mes souvenirs sont bons, cette détection de chevauchement considère les étiquettes de *toutes* les couches, pas seulement celles de la couche concernée, ce qui rendrait le résultat d'autant plus difficilement prévisible. J'ai bien dit plusieurs fois "si mes souvenirs sont bons". Mieux vaut reposer la question sur mapnik-users. Les développeurs du projet ont la mémoire plus fraîche et sont habituellement très réactifs. >> La vérité est ailleurs, et il faudrait faire plus de test pour savoir si ça >> vient d'un bug de mapnik, un problème de mémoire quelque part ou autre. > > Probablement un bug de mapnik du coup. Car en forçant le chevauchement > ça passe. Il sera p-e utile que je reporte ce cas de figure sur la liste > mapnik. > Possible que ce soit un bug mais possible aussi que ce soit une configuration inappropriée. Le placement des étiquettes est un mécanisme compliqué et très certainement capricieux. Il faut savoir que ce mécanisme était un des points forts du projet dès ses débuts, j'imagine que ça a été testé en long en large et en travers. Bref, si tu contactes mapnik-users, mieux vaut avancer prudemment avant de parler de bug. Il me semble qu'il y a un paramètre pour jouer sur l'écartement entre les étiquettes, min_distance peut-être (à vérifier dans la doc). Je ne sais plus quelle est la valeur par défaut. La clause order by reste aussi une piste à ne pas négliger, quand tu fais la requête à la main, est-ce que rennes et paimpont (pour reprendre l'exemple) arrivent avant les communes qui leur sont limitrophes ? 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
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, Le 19/10/2010 15:49, sly (sylvain letuffe) a écrit : > On mardi 19 octobre 2010, Étienne Loks wrote: >> communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). > > L'hypothèse de Gilles me semble insuffisante pour expliquer les deux que tu > viens de citer, puisque la surface des deux communes est grande, et il y > aurait largement la place. > > La vérité est ailleurs, et il faudrait faire plus de test pour savoir si ça > vient d'un bug de mapnik, un problème de mémoire quelque part ou autre. Probablement un bug de mapnik du coup. Car en forçant le chevauchement ça passe. Il sera p-e utile que je reporte ce cas de figure sur la liste mapnik. > - ta requête "and (waterway is null or waterway <> 'riverbank')" est > étrange, elle sert à quoi ? (bien que je ne pense pas que cela influence) Avec le admin_level='8' à rien effectivement. Je suis parti du osm.xml de base et l'ai modifié. C'est du mauvais ménage de ma part (juste une condition inutile). Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9pEUACgkQtXI+41wn9OQBqQCcDLQ6fmHue45gwdai/ngETrSl TkwAni9ygUjR3wvs84sjgW0nXGdezR5m =EpZF -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Re-bonjour, Le 19/10/2010 14:56, Gilles Bassière a écrit : > Étienne Loks wrote: >> J'ai fait un rendu personnalisé avec mapnik pour pouvoir disposer d'une >> carte mettant en avant les communes sur une zone donnée. >> Alors que les limites semblent avoir été bien faites j'ai quelques >> communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). >> >> En base la requête faite pour disposer des noms me renvoie bien les >> communes manquantes. >> >> Avez-vous une idée du pourquoi ? > > Le placement des étiquettes est fait automatiquement par mapnik. > L'algorithme qui s'en charge évite de surcharger la carte en éliminant > les étiquettes qui se chevauchent. > > Si mes souvenirs sont bons, les étiquettes sont placées dans l'ordre > elles sont lues dans les résultats de la requête, c'est à dire qu'on > peut prioriser en ajoutant une clause ORDER BY à la requête source. > > On peut aussi commander à mapnik de ne pas éviter le chevauchement avec > l'attribut allow_overlap. Par exemple : > Merci ! Avec le allow_overlap="true", j'ai un rendu correct. Je n'avais bêtement pas testé car le problème survenait sur des communes assez étendues qui ne me semblaient pas sujettes à un recouvrement. > Mais généralement, ça fait plus de mal que de bien. Mieux vaut > prioriser et laisser faire mapnik afficher tout ce qu'il peut sans > forcer. Ce qui n'est pas visible à un niveau de zoom le sera > probablement au suivant. En l'occurrence, je fais du rendu pour juste une image, il était important que tout apparaisse. > Plus d'infos sur : http://trac.mapnik.org/wiki/TextSymbolizer. > > Pour info, le projet mapnik dispose d'une liste > mapnik-us...@lists.berlios.de qui me semble plus indiquée pour des > questions aussi pointues. Oui en effet. J'ai cédé à la facilité d'une liste en français. Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9ocUACgkQtXI+41wn9ORnGQCfSbsJ81LbQUk68yGwIx/Yqhs0 qvgAmQGNIf1oxNkUEZ8V18wNE+f5b0By =KdqP -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
Étienne Loks wrote: > Bonjour, > > Le problème a p-e déjà été évoqué mais je ne trouve pas en recherchant > dans les messages. > > J'ai fait un rendu personnalisé avec mapnik pour pouvoir disposer d'une > carte mettant en avant les communes sur une zone donnée. > Alors que les limites semblent avoir été bien faites j'ai quelques > communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). > > En base la requête faite pour disposer des noms me renvoie bien les > communes manquantes. > > Avez-vous une idée du pourquoi ? Le placement des étiquettes est fait automatiquement par mapnik. L'algorithme qui s'en charge évite de surcharger la carte en éliminant les étiquettes qui se chevauchent. Si mes souvenirs sont bons, les étiquettes sont placées dans l'ordre elles sont lues dans les résultats de la requête, c'est à dire qu'on peut prioriser en ajoutant une clause ORDER BY à la requête source. On peut aussi commander à mapnik de ne pas éviter le chevauchement avec l'attribut allow_overlap. Par exemple : Mais généralement, ça fait plus de mal que de bien. Mieux vaut prioriser et laisser faire mapnik afficher tout ce qu'il peut sans forcer. Ce qui n'est pas visible à un niveau de zoom le sera probablement au suivant. Plus d'infos sur : http://trac.mapnik.org/wiki/TextSymbolizer. Pour info, le projet mapnik dispose d'une liste mapnik-us...@lists.berlios.de qui me semble plus indiquée pour des questions aussi pointues. Bien 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
