Différences de rendu entre Debian et Centos

Bonjour,

nous avons un serveur de rendu (renderd + mod_tile) sous Debian jessie qui fonctionne parfaitement. Nous avons essayé de le dupliquer sur une CentOS 6 en prenant soins de prendre les mêmes versions de renderd, mod_tile et mapnik, les mêmes fichiers de style et pourtant, même en pointant sur la même DB, nous avons une différence de rendu:

Debian:
tile_debian.png
Centos:
tile_centos.png
quelqu’un aurait une piste pour debugger ça ?

PS: prestations acceptées …

Il semblerait que des relations soient manquantes (à minima celles des limites administratives).

En switchant de DB (render sur CentOS et db sur debian) c’est pareil ?

Possible d’avoir des tuiles à d’autres niveau de zoom pour comprendre ?

Merci Christian,

la tuile “centos” est faite avec le rendu sur la centos, mais la DB Debian, donc ça ne peut pas être un manque de relations, c’est la même DB, accédée avec le même compte.

Quel niveau de zoom pourrait-aider ?

c’est pas un problème de données et de DB si c’est la même pour les deux rendus… là sans plus d’info difficile de dire d’où ça vient

Le log renderd est peu verbeux, tu ne saurais pas comment obtenir plus de logs? La mchine de rendu est beaucoup moins puissante, peut-être que des opérations partent en timeout?

Si il y avait des timeout ou autre, renderd/mapnik ne générerait pas du tout la tuile.

Donc on a en principe les même data qui arrivent, mais pas le même résultat bien que ce soit la même feuille de style mapnik (.xml).

C’est bien ça ?

As-tu vidé le cache de metatile de mod_tile/renderd ? Es-tu sûr d’accéder à une tuile qui vient d’re générée et pas une tuile déjà générée sur l’autre base (CentOS)

ok, je pourrais quand même tenté de re-builder mapnik en mode debug?

oui, j’ai fait une copie complète du xml et du répertoire avec toutes les dépendances (shapes, etc).

À chaque fois: arrêt d’apache, arrêt de renderd, rm -rf mod_tile/default/*, redémarrage renderd et apache. Et j’ai de toute façon le même problème sur d’autres tuiles prises au hasard.

@membres du forum, personne pour faire une presta distante ou sur site (Montparnasse) sur ce problème?

Sans rebuilder mapnik pour du debug tu peux tenter ça avec nik2img.py

C’est un script python qui permet de générer une image sans limite de dimension et il sort un log assez complet et il suffit de lui passer le .xml de style.

Quelques tuiles à des zoom plus élevés (genre 12, 15, 18) permettraient de mieux comprend “ce qui manque” en comparant

Bonjour,

j’ai recompilé mapnik avec ENABLE_LOG=True DEFAULT_LOG_SEVERITY=debug DEBUG=True. Et j’ai généré une image avec nik2img:

nik2img.py -v -f png --no-open --srs=4326 --bbox 1 44 6 46 /home/osm/osm-style/default.xml /tmp/test.png

les seuls erreurs trouvées concernaient le parsing de deux svg (place-4-z7.svg, place-6-z7.svg). J’ai récupéré des versions plus récentes et je n’ai plus ces erreurs. Quoiqu’il en soit, ça n’avait aucun impact sur le rendu qui reste problématique avec des trucs qui manquent :frowning:
test.png
et le log de nik2img: http://fx.libre-entreprise.org/bbhpk1h

Petite info complémentaire, le problème est identique en png (rendu agg) ou svg (rendu cairo).