Feature Layers: Généralisation à la volée
J'ai évoqué précédemment la notion de Feature Layer et l'intérêt d'utiliser le mécanisme de tuilage vectoriel proposé par les APIs ArcGIS pour exploiter les Features Services d'ArcGIS Server. Cependant, si la complexité des géométries est importante, chaque tuile risque de retourner plusieurs Mégaoctets de données, le tuilage vectoriel n'apportera pas grand chose et votre application sera peu performante.
Comment servir efficacement des géométries complexes ?
La première approche peut consister à définir différentes plages d'échelles dans l'application et en fonction de ces échelles faire appel à différentes couches (plus ou moins généralisées) de votre Feature Service. Cette méthode est efficace mais elle nécessite une préparation préalable des couches généralisées sur le serveur ainsi que quelques paramétrages coté client pour obtenir le bon comportement en fonction du changement d'échelle. Ces derniers resteront relativement simples dans la mesure où chaque Feature Layer dispose d'une propriété minScale et maxScale
La seconde méthode consiste à généraliser, à la volée, coté serveur, les entités demandées par l'application cliente. Pour cela, les APIs ArcGIS proposent un paramètre MaxAllowableOffset sur les Feature Layers qui permet de préciser au serveur comment généraliser les géométries. Pour ceux d'entre vous qui ne connaissent pas ce paramètre, il s'agit de la tolérance utilisée par l'algorithme de généralisation Douglas–Peucker que l'on retrouve également dans cet outil de généralisation d'ArcGIS.
La stratégie consiste donc à capture l'événement de l'API correspondant au changement d'étendue ou de niveau d'échelle de la carte et de définir la valeur appropriée à l'aide de la méthode setMaxAllowableOffset.
Reste alors à définir la valeur appropriée pour ce paramètre de distance maximum. Vous pouvez expérimenter différentes valeurs selon les échelles de votre carte et trouver de manière empirique les valeurs de tolérance qui conviennent. Vous pouvez également considérer qu'un pixel de la carte est la plus petite unité d'affichage et qu'il est inutile d'afficher plus d'un sommet par pixel pour les géométries de vos entités. Un simple calcul: la largeur de la carte en coordonnées cartographiques divisée par la largeur de la carte en pixels, vous permettra d'obtenir pour chaque échelle, la tolérance optimum. Vous serez alors certains que la géométrie des entités ne diffère pas plus de la taille représentée par un pixel. C'est exactement ce que fait cet exemple d'application que vous trouverez dans la documentation de l'API ArcGIS for JavaScript. La carte affiche une Feature Layer contenant des milliers d'entités surfaciques dont certaines ont des tailles très petites. Grâce à la généralisation à la volée, les plus petites entités ne sont plus affichées aux plus petites échelles.
Pour info, le Viewer intégré d'ArcGIS.com réalise ce type de paramétrage à la volée en choisissant la valeur maxAllowableOffset de manière automatique dès que vous ajoutez des Feature Layers dans vos Web Maps. Les performances sont alors bien meilleures en particulier lorsque vos couches contiennent des géométries complexes.
Généralisation et mise à jour de données
On doit tout de même noter une restriction concernant l'usage de la généralisation sur les Feature Layers. En effet, lorsque celles-ci sont paramétrées pour pouvoir être mises à jour, il est alors impossible d'utiliser le paramètre maxAllowableOffset. On comprend aisément que la généralisation des géométries dans le contexte de leur mise à jour dans l'application cliente engendrerait des incohérences lors de l'enregistrement des modifications.
Dans un prochain article, j'évoquerai un autre aspect important des Feature Layers à savoir les capacités de représentation qui sont offertes coté client pour représenter les entités.
Dans un prochain article, j'évoquerai un autre aspect important des Feature Layers à savoir les capacités de représentation qui sont offertes coté client pour représenter les entités.
0 comments :
Enregistrer un commentaire