on voit ces lignes parasites sur tous les rendus Mapnik visiblement le clippung est calculé sur les coordonnées exactes du carreau mais si la tuiles est seulement agrandie, un algo de lissage semble vouloir calculer des pixels suppélmentaires en bordure en supposant que l'extérieur est blanc. Ca se voit aussi dans les océans. C'est instable car en zoomant/dézoomant on dirait que les carreaux servis ne sont pas réellement jointifs aux mêmes coordonnées mais différent d'un pixel et le rendu côté client considére ce pixel à cheval entre les deux pixels des deux carreaux est dans une couleur de fond arbitraire. En zoomant le temps d'avoir une tuile de plus basse réslution puis dézoomant, ce pixel se remplit dans la bonne couleur, celle obtenue de la tuiles de plus haute résolution qui a temporariement été réduite par filtrage. en sens inverse la tuile haute résolution s'affiche sur un fond initialement uniforme blanc ou gris et ce pixel ne se remplit pas une fois les tuiles en plus haute résolution arrivée (même quand elles viennent du cache local du navigateur sans réelle requête au serveur). C'est possible que ce soit le framework javascript client (Leaflet ou autre) qui soit la cause de ce défaut de rendu entre les tuiles (mauvaise synchro des opérations de dessin dans le canevas HTML5 ou défaut de placement si c'est un rendu direct d'élément image HTML positionné avec le DOM et CSS; problèmes de mode d'arrondis des coordonnées CSS en pixels logiques lors de la conversion en pixels physiques). Le problème se voit surtout sur les grands écrans de PC (plus de 15 pouces), c'est peu ou pas visible sur les écrans de tablettes ou smartphones (moins de 5 pouces), dont la densité des pixels physiques est nettement plus élevée que celle des pixels logiques qui sont aussi deux ou trois fois plus denses que sur grand écran. ----
Le problème des pixels parasites est accru sur les écrans TVHD de salon de plus de 21 pouces mais certains ont des algo de rendu destiné à simuler des résolutions plus élevée et à compenser des nouvements en accentuant certaines bordures de contraste et éliminer les traits fins ou compenser un rafraichissement à fréquence plus élévée: ça donne une image avec une meilleure dynamique, des lignes droites plus nettes, notamment chez Philips alors que c'est pas terrible chez Samsung qui triche grossièrement sur les couleurs et où les compensations favorisent plus les images animées que les images statiques du web ou d'un bureau et nécessitent de constants re-réglages de l'image selon ce qu'on regarde Le truc pour le voir c'est le logo statique des chaines TV (notamment le quadrilatère blanc de France 2 ou celui de beIN sport dans le coin sur une image animée) ou encore les génériques de films en texte défilant; les infotextes en bas des chaines infos comme CNN, France 24 ou i>Telé ou chaines anglophones d'actu financières) et la différence est nette sur les émissions en SD (chaines chinoises et arabes ou africaines) et avec bon nombre de films cinéma en VOD (plus chers en HD qu'en SD ou avec Youtube et Netflix) ou avec les boxes TV en ADSL où la "HD" promise par les FAI est une escroquerie manifeste. Sur une Philips on a du mal à voir qu'une chaine est en SD tellement le filtrage numérique adaptatif est bien fait et arrive pratiquement à simuler la HD sans différence notable; c'est tout aussi bon en affichage d'un bureau avec le texte des petites icônes ou d'une page web riche en infos et peu lisible sur écran Samsung dont les polices de caractères pour les sous-titres sont aussi très grossiéres et mal lissées même si le deux écrans sont venud comme du 1080p à rafrichissement doublé à 100 ou 12 hertz (au delà ce n'est pas du rafraisisement mais une adaptation de la compensation de mouvement avec un lissage/filtrage sur des fragments de pixels dependant de la vitesse de déplacement calculée; il n'existeaucun écran à 600 ou 800 hertz c'est une simulation de l'effet visuel). Le 30 septembre 2014 22:30, Jérôme Seigneuret <jseigneuret-...@yahoo.fr> a écrit : > le voilà > C'est un problème sur les éléments de même type sans bordures > http://www.openstreetmap.org/#map=16/43.9882/4.5680 > > Le 30 septembre 2014 22:02, Christian Quest <cqu...@openstreetmap.fr> a > écrit : > > Un permalien ? >> >> Le 30 septembre 2014 21:57, Jérôme Seigneuret <jseigneuret-...@yahoo.fr> >> a écrit : >> >> D'ailleurs vu qu'on parle de rendu. Serait-il possible fusionner des >>> entités similaires jointives avant de produire les tuiles? Car j'ai observé >>> des liserés blancs apparent dans ce cas au niveau de la jointure. >>> >>> Le 30 septembre 2014 21:42, Christian Quest <cqu...@openstreetmap.fr> a >>> écrit : >>> >>>> Le 30 septembre 2014 16:46, Pieren <pier...@gmail.com> a écrit : >>>> >>>>> En fait, Christian est parti d'une ancienne version du style de rendu >>>>> (je ne pense pas que le résultat actuel soit volontaire) et je ne suis >>>>> pas sûr que sur ce point, on ait beaucoup à gagner à jouer la >>>>> différence. >>>>> >>>> >>>> >>>> C'est surtout que le style par défaut a changé de ce côté il y a peu de >>>> temps (cet été). >>>> Je comprends le besoin de cohérence, de pousser à un meilleur tagging, >>>> une meilleure modélisation. A ce que j'ai compris, c'est pour favoriser >>>> cela que le style osm.org a changé, pousser à corriger le tir sur les >>>> données. >>>> >>>> Avec le rendu FR, il y a déjà pas mal de traitements pour "améliorer" >>>> le rendu final quitte parfois à masquer des petites erreurs que le rendu >>>> par défaut mettrai en évidence. Vu qu'on a deux rendus différents, il me >>>> semble qu'on peut se permettre justement d'avoir des objectifs légèrement >>>> différents. >>>> >>>> -- >>>> Christian Quest - OpenStreetMap France >>>> >>>> _______________________________________________ >>>> Talk-fr mailing list >>>> Talk-fr@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-fr >>>> >>>> >>> >>> _______________________________________________ >>> Talk-fr mailing list >>> Talk-fr@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-fr >>> >>> >> >> >> -- >> Christian Quest - OpenStreetMap France >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> >> > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
