Crénelage des lignes dans un service de carte optimisé

Le pipeline graphique utilisé dans ArcMap et dans le service de carte standard s'appuie sur la technologie GDI (Graphics Device Interface) de Microsoft. L'une des limitations de cette technologie réside dans le fait que les graphiques ne peuvent être représentés que par des coordonnées revêtant la forme d'un nombre entier. En général, la géométrie du monde réel ne se produit pas uniquement sur des nombres entiers ; par conséquent, les coordonnées sont arrondies vers le haut ou vers le bas lors de leur affichage à l'aide de ce pipeline graphique. Vous pouvez l'observer dans les formats d'exportation vectoriels, tels que PDF (les lignes vectorielles peuvent présenter un effet d'escalier si vous les examinez attentivement).

Le pipeline graphique utilisé par les couches de fond de carte et les services de carte optimisés peut utiliser des coordonnées sous la forme de nombres non entiers réels de votre géométrie, et peut afficher les données avec une précision inférieure au pixel, améliorant ainsi l'exactitude des données dans ces formats vectoriels. Toutefois, lorsque ces entités sont affichées dans des formats raster tels que PNG ou BMP, les géométries doivent à nouveau être arrondies pour le rendu sur un pixel à la résolution demandée. A de faibles résolutions, cela peut entraîner un crénelage avec des symboles linéaires multi-couches, tels que des symboles de route avec bordure.

Exemple de crénelage lié à un rendu plus précis (gauche : service de carte optimisé, droite : ArcMap)

Le service de carte optimisé est capable d'appliquer l'anti-crénelage pour alléger les effets du phénomène précité, mais dans certains cas, l'anti-crénelage n'est pas l'option optimale. Par exemple, l'utilisation de l'anti-crénelage peut réduire les performances d'un service de carte optimisé. Selon les besoins du service, cela peut être inacceptable. Par ailleurs, pour les formats cibles qui utilisent une palette 8 bits (tels que les formats PNG8 ou GIF), il se peut que l'anti-crénelage ne soit pas aussi efficace en raison du tramage nécessaire au rendu des progressions continues de couleurs. Notez que l'anti-crénelage n'est pas disponible pour l'affichage de la couche de fond de carte.

L'anti-crénelage peut améliorer considérablement l'apparence d'une ligne, mais au détriment des performances. (gauche : aucun anti-crénelage, droite : anti-crénelage optimal)

Pour minimiser ce phénomène sans utiliser l'anti-crénelage, la fenêtre Préparation propose un analyseur qui détecte les symboles linéaires multi-couches susceptibles d'entraîner ce problème.

Il existe deux solutions pour cet analyseur : la première consiste à identifier cette couche pour le réglage automatique des tailles de lignes lors de la conversion. Lorsque la carte est convertie au format de définition du service de carte (Map Service Definition, MSD), les largeurs de lignes des couches pour lesquelles cette option est activée sont automatiquement modifiées pour garantir un affichage cohérent à une résolution de 96 ppp ou supérieure. La taille du symbole dans le fichier MXD reste identique. Pour la plupart des utilisateurs, cette solution suffit. Vérifiez la fenêtre Aperçu pour vous assurer que l'apparence de la ligne corrigée répond à vos attentes. Notez que cet analyseur n'apparaîtra pas pour les couches de fond de carte parce que l'ajustement automatique est toujours sélectionné pour ce cas.

Gauche : Des largeurs de ligne originales du symbole d'autoroute affichées dans le service de carte optimisé ; droite : après la correction. Notez que les lignes de bordures n'apparaissent plus en pointillés dans la version corrigée.

Une autre solution consiste à modifier manuellement la structure du symbole linéaire multi-couches afin de rendre les tailles de lignes plus appropriées. Cela permet également la conversion en vue d'une utilisation avec une résolution cible autre que 96 ppp (par exemple, 72 ppp).

Conception de lignes pour une résolution spécifique (ppp)

Afin de déterminer les tailles de lignes appropriées pour une résolution donnée, entrez les tailles de chacun des symboles au sein du symbole linéaire multi-couches dans les formules suivantes. Comme décrit précédemment, la valeur de RésolutionCible doit refléter la résolution minimale souhaitée à laquelle ce symbole sera utilisé.

LargeurEnPixels = (LargeurLigne en points * RésolutionCible en ppp)/72

Si la LargeurEnPixels est inférieure à 1,5, la largeur ne doit pas être modifiée.

Si la LargeurEnPixels est égale ou supérieure à 1,5, utilisez la formule suivante pour déterminer la largeur modifiée :

1. NouvelleLargeurEnPoints = (LargeurEnPixels + 0,5)
2. A présent, arrondissez la NouvelleLargeurEnPoints à la valeur entière la plus proche (nombre entier) qui n'est pas supérieure à la NouvelleLargeurEnPoints.
3. La largeur de ligne finale doit être définie selon la formule (NouvelleLargeurArrondieEnPoints * 72)/RésolutionCible.

Par exemple, si la résolution souhaitée est de 44 ppp et que la largeur du symbole linéaire est de 2,60, le calcul s'effectue comme suit :

1. LargeurEnPixels = (2,60 * 44)/72,0.
2. La LargeurEnPixels est de 1,5888888 ; cette valeur étant supérieure à 1,5, nous poursuivons :
3. NouvelleLargeurEnPoints = (1,588888 + 0,5) = 2,10.
4. Arrondi inférieur, NouvelleLargeurEnPoints = 2,0.
5. La largeur de ligne finale doit être définie sur (2,0 * 72)/44 = 3,27 pts.

Autre exemple : si la résolution souhaitée est de 120 ppp et que la nouvelle largeur du symbole linéaire est de 2,60, le calcul s'effectue comme suit :

1. LargeurEnPixels = (2,60 * 120)/72.
2. La LargeurEnPixels est de 4,33333 ; cette valeur étant supérieure à 1,5, nous poursuivons :
3. NouvelleLargeurEnPoints = (4,33333 + 0,5) = 4,83.
4. La NouvelleLargeurEnPoints est arrondie au nombre entier le plus proche, 4,0.
5. La largeur de ligne finale doit être définie sur (4,0 * 72)/120 = 2,4 pts.