Commentaires sur : MapServer vs Mapnik

Par : neogeo » Archive du blog » Mapserver vs Mapnik, Round 2

neogeo » Archive du blog » Mapserver vs Mapnik, Round 2 — Mon, 10 Mar 2008 13:49:17 +0000

[...] au commentaire de l’article précédent par Thomas Bonfort , principal maître d’oeuvre de [...]

Par : guillaume

guillaume — Mon, 10 Mar 2008 13:15:28 +0000

Super, car le rendu obtenu avec des traits < 1 est vraiment agréable, notamment à petite échelle.

Par : thomas

thomas — Mon, 10 Mar 2008 13:13:31 +0000

oui, c’est dans les capacites de AGG de pouvoir faire des traits d’epaisseur <1 . c’est prevu aussi pour mapserver pour un futur proche (il n’y a normalement qu’a modifier le parseur pour qu’il prenne des flottants pour WIDTH)

Par : admin

admin — Mon, 10 Mar 2008 13:10:41 +0000

oui, c’est bien la 5.0.2. Je vais faire des tests dans la soirée sur le trunk. Pendant que j’y suis, un des atouts visibles de Mapnik est sa capacité à faire des tracés plus fins que MapServer, en faisant des traits inférieurs à 1 (0.1 par exemple). La valeur en tant que telle n’a pas vraiment de sens (0.1 pixel ? ah ah ah !). Est-ce que cela correspond à une valeur virtuelle, le tracé final faisait 1 pixel anti-aliasing compris (donc uniquement un trait estompé) ? Hmm, j’espère avoir été clair…Est-ce que MapServer pourra faire de même dans le futur ?
Merci !

Par : thomas

thomas — Mon, 10 Mar 2008 12:45:00 +0000

merci pour ces tests…
c’est quelle version de mapserver que tu utilises? si il s’agit de la 5.0.x, te serait il possible de fournir les memes timings mais en utilisant la version trunk? merci

Par : admin

admin — Mon, 10 Mar 2008 08:34:44 +0000

Suite au post de Benjamin (http://benjamin.chartier.free.fr/pro/?p=290) qui reprenait fort opportunément l’article de PerryGeo (http://www.perrygeo.net/wordpress/?p=77) sur le même sujet, j’ai refait les tests mapserver en utilisant directement shp2img plutôt que le python-mapscript, pour des résultats identiques. De même, l’utilisation du JPEG n’a pas d’impact sensible. Je pense surtout que les temps calculés par Perry sont trop proches et trop faibles (< 0.3s) pour être significatifs.