J'ai une énigme que je reçois des conseils mitigés sur la façon de procéder. C'est pourquoi j'aimerais le mettre au GIS-SE pour des réponses justifiées.
Scénario:
Le client dispose d'une application de cartographie Web. Ne souhaite pas se diviser en plusieurs applications plus petites. Bien que cela va à l'encontre de l'approche moderne des cartes sur le Web (c.-à-d. De nombreuses applications de cartes Web ciblées sur une carte Web principale), je crois fermement que pour certains utilisateurs, essayer de répliquer une application SIG sur le Web est ok ( parfois ).
Le client a mis en cache autant de ses couches de fond de carte dans des services distincts.
- Le client a encore besoin de 600 à 700 couches supplémentaires dans un service de carte dynamique ...
- Le service sera publié avec toutes ces couches désactivées .
- Il n'est pas prévu que les utilisateurs activent plus de 10 à 40 couches à la fois.
J'imagine que votre réaction initiale à cela est similaire à la mienne (600+?! WTF ?!)
Cependant - l'exigence est gravée dans le marbre et pourquoi pas? Leur précédente application ArcIMS avait des fonctionnalités similaires, alors pourquoi ce nouveau produit ArcGIS Server ne peut-il pas faire de même? Les utilisateurs doivent potentiellement pouvoir comparer et effectuer des analyses sur toute la gamme de couches, même si les couches appartiennent à d'autres services.
Avant de tirer des conclusions, le client est un administrateur ArcGIS Server informé.
Ils ont administré les 600 couches selon toutes les règles de bonnes pratiques: par exemple, les plages d'échelle combinées aux requêtes de définition; annotation sur l'étiquetage; généraliser des couches complexes à petite échelle; publier en tant que TMS; etc
Problème :
Quelle est la meilleure approche ici?
Publiez les 600 couches dans un service de carte dynamique
Divisez les couches en groupes logiques (hydrologie, planification, écologie, services publics, etc.)
Si vous optez pour # 1 et que vous avez activé quelques calques complexes. Si vous souhaitez activer une couche de points simples, ArcGIS Server devra tout de même restituer l'intégralité des couches.
Si vous optez pour le n ° 2, chaque fois que vous effectuez une demande, l'application Web pourrait devoir effectuer plusieurs demandes GET pour ExportMaps à partir des services de carte individuels (est-ce mauvais ou crée-t-il une charge supplémentaire sur ArcGIS Server sur le n ° 1) ?)
Et cela conduit à la configuration et au réglage pour s'assurer que tout est aussi rapide que possible. Nous pouvons faire évoluer le back-end d'ArcGIS Server sur plusieurs hôtes et disposer d'un bon matériel pour s'y installer.
Si vous optez pour le n ° 1, vous pouvez lancer le nombre maximal d'instances que AGS peut gérer.
Si vous optez pour le # 2, je suppose que vous évaluez les performances des services de carte (test de charge et examinez les temps d'attente) et adressez les instances min / max en conséquence pour vous assurer qu'il n'y a pas un service qui soit un `` maillon faible ''.
Je penche actuellement vers l'approche # 2, car ma tête me dit toujours qu'avoir 600 couches dans un service est une folie, mais si elles sont toutes désactivées par défaut, il n'y a vraiment pas de problème.
Aimerais entendre vos pensées. Faites-moi savoir si vous avez besoin de plus d'informations via les commentaires, mais ne cherchez pas de réponses comme «utiliser une application de bureau» ou «les éduquer à faire les choses différemment»
Des discussions dans les commentaires, je n'ai pas mentionné une autre considération. L'application dans laquelle le service sera consommé a la capacité de sécurité au niveau de la couche (au niveau de l'application). Par conséquent, le groupe d'utilisateurs (qui est assez important) est affecté à un rôle particulier, et ce rôle aura accès aux 600 couches complètes. D'autres rôles seront limités.
