Skip To Content

Alternativas para extensiones de objeto del servidor

La amplitud de herramientas de desarrollador de ArcGIS y el reto de escribir el código de un servicio web pueden hacer que las extensiones y los interceptores de objeto del servidor (SOE y SOI) resulten difíciles para los principiantes. En este tema se explican algunas tareas de SIG web comunes para las que los desarrolladores de SIG han escrito tradicionalmente código personalizado, y se ofrecen planteamientos alternativos que no requieren la escritura de una SOE o un SOI.

Crear diseños de impresión

Muchos desarrolladores han utilizado código personalizado para acceder al objeto de Diseño del servicio de mapas, específicamente para incorporar la funcionalidad de impresión de alta calidad en sus aplicaciones web. Antes han utilizado ArcObjects para trabajar con mapas con calidad y sus elementos circundantes, generar documentos que se puedan imprimir en formatos grandes, etc.

Como alternativa, ahora puede utilizar el módulo arcpy.mp de Python (para ArcGIS Pro) para crear un script de construcción de diseño e impresión de mapas. A continuación, puede exponer el script a través de un servicio de geoprocesamiento o una herramienta web. Con ArcPy, puede manipular documentos de mapa en un grado muy detallado: puede agregar capas de forma dinámica al mapa, actualizar su simbología, etc. Además, puede acceder al diseño del mapa, manipular elementos como texto e imágenes.

El siguiente tutorial muestra cómo compartir diseños de impresión personalizados:

Cambiar símbolos y renderizadores

Otra razón por la que los desarrolladores necesitaban código personalizado en el pasado era para cambiar la simbología de una capa concreta de un servicio de mapas. Este flujo de trabajo a menudo requería el uso de servicios no agrupados, lo que limitaba la escalabilidad de las aplicaciones. Algunos desarrolladores lograban hacer esto con servicios agrupados, a pesar de que alternar el estado de un servicio para satisfacer las solicitudes de varios usuarios a menudo resultaba en un rendimiento deficiente y dejaba mucha responsabilidad al desarrollador para mantener un buen estado en la instancia del mapa en sí.

Las API web de ArcGIS le proporcionan una manera fácil de simbolizar entidades mediante la capa de entidades del cliente o capa de gráficos, cuyas propiedades de representación en pantalla se pueden cambiar en cualquier momento. La idea es que la geometría y los atributos de entidades visibles se descarguen todas en el cliente y, de esta forma, sea más fácil para el cliente dibujar las entidades utilizando cualquier color, anchos o cortes de clase que defina el desarrollador de la aplicación.

La técnica de capa de entidades es particularmente efectiva para la representación cartográfica temática, interactuar con y resaltar entidades, y así sucesivamente, pero no es suficiente cuando trabaja con miles de entidades o entidades poligonales muy complejas. En esos casos, el mejor enfoque es solicitar cambios de simbología a nivel del servicio y hacer que el servicio de mapas represente en pantalla la imagen del mapa. Esto anteriormente requería ArcObjects.

Ahora puede alterar el contenido y simbología de un servicio de mapas en tiempo de ejecución. Ya no es necesario utilizar un código personalizado detallado para cambiar la simbología en sus capas de servicio de mapas. En lugar de esto, puede decidir, en función de cada solicitud, el contenido o simbología a utilizar en el mapa que desea crear.

Para definir la simbología de sus capas en el servicio de mapas en tiempo de ejecución, se debe incluir la información del renderizador en su solicitud de servicio web para dibujar el mapa, junto con la información típica de visibilidad de capas, extensión, etc. Las API web de ArcGIS contienen clases de utilidad, de modo que puede definir fácilmente el contenido, renderizadores, rupturas de clase, simbología, etc.

Para obtener más información sobre cómo cambiar el contenido y la simbología en tiempo real en un servicio de mapas, consulte Acerca de las capas dinámicas.

Edición Web

En versiones antiguas de ArcGIS Server, la edición de datos en la web solo podía realizarse mediante código personalizado, aprovechando las conexiones locales (DCOM). La introducción del servicio de entidades eliminó la necesidad de escribir extensiones para ello.

La API REST permite editar entidades de sus servicios de entidades en la web. No solo es posible editar a través de REST; también resulta práctico personalizar, porque muchos métodos de edición habituales, como cortar, corte, extender, autocompletar polígonos y cambiar de forma, se exponen a través de la implementación de REST del servicio de geometría. La edición versionada también se admite en servicios de entidades.

Heredado:

En las versiones anteriores a ArcGIS 10.1, se podían utilizar servicios no agrupados para realizar ediciones siguiendo un modelo de transacción larga. Con el servicio de entidades, todas las operaciones están sin estado, lo que significa que no puede deshacerlas a nivel de base de datos (aunque podría con lógica de negocios en su aplicación). Esto no le impide implementar operaciones de deshacer/rehacer, como con las API Web de ArcGIS.

Realizar lógica de negocios con geoprocesamiento

Algunas aplicaciones SIG ejecutan una serie de herramientas específicas para realizar una lógica de negocios avanzada de SIG. Estas herramientas pueden predecir la producción de madera de un bosque, identificar lugares aptos para un restaurante o estimar donde se podría expandir una nube tóxica. Muchos desarrolladores han utilizado código personalizado para hacerlo posible.

En muchos casos, estos procesos se pueden expresar en ModelBuilder, donde es posible "encadenar" herramientas gráficamente. Esos modelos de geoprocesamiento se pueden exponer como servicios web y utilizar desde las aplicaciones web. Los beneficios son obvios: utilizar un servicio de geoprocesamiento puede ahorrarle muchos códigos. Además, puede aprovechar la ejecución asíncrona de los servicios de geoprocesamiento, que es un desafío lograr al escribir su propio código SOE.

Además de la flexibilidad de disponer de miles de herramientas listas para usar que puede combinar en ModelBuilder, el geoprocesamiento le ofrece la capacidad de desarrollar herramientas personalizadas. La forma más simple es crear scripts Python que se puedan ejecutar ya sea individualmente o en combinación con otras herramientas dentro de un modelo. En este tema se describió un ejemplo de lo anterior con el uso de ArcPy para crear mapas de alta calidad en la web.

Si utiliza Python u otro lenguaje, la ventaja de crear herramientas personalizadas es que puede reutilizarlas en diferentes flujos de trabajo, ya que se comportan como cualquier otra herramienta de uso inmediato. Además, su código personalizado puede ejecutarse dentro del modelo de ejecución asíncrona de los servicios de geoprocesamiento, lo que resulta útil para procesos de larga ejecución.

Realizar cálculos geométricos

Los servicios de geoprocesamiento son útiles, pero ya no son necesarios para realizar operaciones de geometría.

Las API de cliente de Esri, como ArcGIS API for JavaScript y los ArcGIS Runtime SDK, ofrecen amplias bibliotecas de geometría local que le permiten realizar proyecciones, calcular distancias, etc.

Si no pretende utilizar estas API de cliente, compruebe si el servicio de geometría basado en SOAP o REST ofrece los métodos que necesita. El servicio de geometría puede realizar operaciones SIG básicas como crear zonas de influencia, determinar relaciones espaciales y medir longitudes y áreas. Invocar a una serie de métodos en un servicio de geometría y combinarlas con los recursos de consulta de servicios de mapas y lógica del cliente puede ser más simple y rápido que utilizar un servicio de geoprocesamiento.