ArcGIS for Server: Errores comunes al publicar servicios de mapa
diciembre 21, 2011 1 comentario
Son muchas las ocasiones en la que al revisar proyectos ya en producción uno se encuentra con configuraciones de servicios poco optimizadas.
Hay una serie de errores bastante comunes a la hora de publicar servicios de mapa que merece la pena repasar, porque se repiten una y otra vez:
- Publicar un MXD. Hasta la versión 9.3 había ciertas funcionalidades de ArcGIS for Server que solo era posible conseguir a través de MXD. Esto ya no es así en la versión 10. El archivo MXD no es un formato pensado para publicar en internet, sino para trabajar en desktop. En un principio se utilizó hasta que se desarrollo un nuevo motor de renderizado que hacía uso de un formato mejor, el MSD. De hecho, en versión 10.1 será imposible publicar un MXD con ArcGIS Server.
- Publicar un WMS a través de un MXD. Es muy común ver servidores con servicios WMS publicados a través de MXD. Aunque hasta la versión 10 esto es técnicamente posible, está completamente desaconsejado. En realidad, estamos volviendo a encapsular un servicio externo dentro de nuestro propio servidor, haciéndole trabajar dos veces. La solución es muy sencilla, integrar los servicios WMS dentro de la aplicación a través de los distintos SDKs.
- No usar filegeodatabases (FGDB). Lo más directo cuando se publican servicios es conectarlos directamente a ArcSDE. En algunas ocasiones esto es necesario porque tenemos datos que se actualizan constantemente y que además se comparten con otras aplicaciones o servicios. Sin embargo, en la mayoría de los casos, esto no ocurre, y muchos de los datos publicados cambian con una periodicidad superior. En este caso, siempre se debe optar por una filegedodatabase para la publicación. El rendimiento es muy superior. Es decir, por defecto, siempre habría que pensar en usar FGDB.
- Tener todas las capas en un único servicio. En ArcGIS for Desktop es común tener un proyecto MXD con gran cantidad de capas. Sin embargo, trasladar esto a la web no es lo mejor. Cuando llevamos un servicio a internet, siempre hay que tener en cuenta el rendimiento. Hay capas que se usan más que otras y estas se podrían agrupar en otro servicio distinto de forma que se reparte la carga entre varios.
Publicar servicios dinámicos innecesarios. En muchas ocasiones se publican servicios dinámicos (sin cachear) porque queremos dejar al usuario libertad total sobre las capas. Hay tener presente que, en muchas ocasiones, el usuario final no es consciente de las limitaciones de su entorno (ancho de banca, memoria, procesador, etc…). Es posible nos pida imposibles y es cuando hay que presentarle estas limitaciones y las soluciones. Muchos servicios dinámicos pueden limitar mucho la capacidad de un servidor.
- Cachear las capas individualmente. El objetivo de un cacheado es mejorar lo máximo posible el rendimiento de un servicio, agrupando aquellas capas que el usuario solo usa como referencia o como consulta. De nuevo, es posible que el usuario pida como requisito que se puedan activar o desactivar capas, pero ¿todas? ¿tiene sentido? No. Una solución típica a esto es que se genere un cacheado por capa. Esto es un error, ya que estamos quitando el propio beneficio del cacheado. Ej.: al hacer esto, y si tenemos 4 capas cacheadas, para una misma zona, por cada petición estamos enviando 4xN tiles, lo que podría dar lugar a una descarga de 4x8x256x256 = 2MB ¡por petición! Imaginad la situación cuando tenemos varios usuarios concurrentes…
- No usar la Map Publishing Toolbar. Esta pequeña barra de herramientas nos da todas las indicaciones necesarias para que nuestro servicio se sirva mejor. Además de mostrarnos un listado de errores, recomendaciones y sus posibles soluciones, nos permite previsualizar el servicio y ver qué tiempos tardaría nuestro servidor en devolver una imagen.
- Formato de imagen adecuado. En ocasiones se eligen formatos de imágenes que no son los más adecuados para su visualización. JPG es el formato que hay que usar para servir ortofotos e imágenes satélite. Mientras que PNG o GIF son la elección si se necesitan transparencias. Entre estos dos, el formato PNG puede ser utilizado para capas vectoriales más complejas y/o con más simbología, mientras que GIF puede ser mejor en capas más sencillas y textos. Lo mejor para probar la calidad es ver los resultados en pantalla e ir optimizando.
Aplicando todos estos consejos nuestros servicios estarán optimizados y las peticiones a nuestros servicios serán las necesarias. No siempre lo que vemos en un ArcGIS for Desktop es lo que hay trasladar a un servicio web. Siempre hay que buscar un compromiso entre funcionalidad, calidad y nivel de servcio.
Conviene tener presente que internet es un entorno muy diferente al entorno Desktop y que lo primero que hay que tener en cuenta es la velocidad y la optmización de los servicios a publicar. Por cierto, esto también tienen que saberlo los usuarios finales.
