Punto en polígono transaccional versus por lotes

El concepto de operaciones de punto en polígono transaccional versus por lotes hace realmente la diferencia si ya cuenta con todos los datos de puntos y geometría, o si estos entran en la etapa uno a la vez, en un escenario en tiempo real. Si su aplicación tiene puntos que se originan en el tiempo de ejecución (por ejemplo, la ubicación de una póliza de seguros generada por la consulta de un cliente), y solo existen los datos de polígono, se conoce como caso de uso transaccional. Un caso de uso por lotes, por el contrario, tiene datos persistentes de punto y polígono en tablas. El módulo Location Intelligence tiene dos etapas para resolver los casos de uso de punto en polígono: Query Spatial Data y Point In Polygon de Centrus (Legacy Point In Polygon). Cada etapa tiene diferencias de rendimiento cuando se realizan puntos en polígono por lotes o transaccionales. Para obtener más información sobre las etapas Query Spatial Data y Legacy Point In Polygon, consulte:

En los casos de uso de punto en polígono transaccional, es preferible usar la etapa Point In Polygon de Centrus, en vez de la etapa Query Spatial Data. La etapa Point In Polygon tiene un mayor rendimiento cuando se leen datos en tiempo real en la etapa. La etapa Query Spatial Data supera el rendimiento de la etapa Point In Polygon de Centrus en procesamiento por lotes y escalabilidad. Query Spatial Data ofrece más flexibilidad acerca de la ubicación donde pueden residir los datos de polígono y en qué tabla iterar. Si conoce las características de sus datos (como la complejidad de los polígonos y el número de puntos y polígonos), puede estructurar su flujo para lograr un rendimiento óptimo.

Para obtener ejemplos de cómo crear un flujo de Query Spatial Data por lotes y Point in Polygon transaccional, consulte:

¿Qué formato de datos puede usar? El tipo y formato de sus datos también determinará qué operación usa en Spectrum. La operación Point in Polygon de Centrus solo es compatible con el formato GSB. Si realiza un punto en polígono transaccional, necesita un buen rendimiento y puede convertir sus datos al formato GSB, entonces el método más rápido para realizarlo es la operación Point In Polygon en Centrus. Se recomienda que solo convierta sus datos a GSB si es necesario por motivos de rendimiento. Hay otras diferencias que podrían afectar sus necesidades. Por ejemplo, los archivos TAB respaldan múltiples idiomas y un mayor número de sistemas de coordenadas. GSB está solo en inglés y tiene un sistema de soporte de sistema de coordenadas más limitado.

Si piensa que la operación Point in Polygon de Centrus mejorará la solución y los datos están en un formato diferente a GSB, existe una utilidad que se incluye con Spectrum para transformar los datos existentes a GSB. Spatial Import es una utilidad de línea de comandos de Windows que se utiliza para traducir los archivos .SHP, TAB, .MIF/.MID y .DBF a un archivo de base de datos Centrus (.GSB). Se puede descargar de la sección Spectrum Spatial de la página de bienvenida, bajo Spatial Import en la ficha Utilidades. Una vez descargado el archivo zip, tiene la opción de usar la versión de 32 bits (x86) o la de 64 bits (x64). Consulte Utilidad de conversión del módulo Location Intelligence para obtener más información sobre cómo usar esta utilidad.

Nota: Si tiene razones para no convertir los datos a GSB (por ejemplo, si le preocupa que se dupliquen los datos), puede usar Query Spatial Data para casos de uso transaccional y acceder a los datos tabulares almacenados en archivos TAB nativos o fuentes de bases de datos espaciales.

¿Por qué usar Query Spatial Data para procesar por lotes? Como se mencionó anteriormente, la etapa Query Spatial Data ofrece más flexibilidad y más opciones de rendimiento. Considere los dos siguientes flujos de situaciones de procesamiento por lotes (suponga que los polígonos y puntos son los mismos):

  1. Read Spatial Data lee una lista de puntos de un archivo TAB (millones de puntos).

    Spatial Calculator crea valores de columna de longitud y latitud a partir de los puntos.

    La etapa Point In Polygon de Centrus consulta un gran conjunto de polígonos (GSB).

  2. Read Spatial Data lee un gran conjunto de polígonos de un archivo TAB.

    Query Spatial Data usa un filtro Contains en una tabla de puntos (millones de puntos).

Considerando estas dos situaciones, con un tamaño de colección 1 y tiempo de ejecución 1, Point In Polygon de Centrus (situación 1) es más veloz que Query Spatial Data (situación 2). A medida que las instancias de colección y tiempo de ejecución aumentan, el rendimiento de la situación 1 sigue siendo constante, mientras que el de la situación 2 aumenta eficazmente. En cuatro instancias de colección y cuatro tiempos de ejecución, Query Spatial Data es más veloz que la etapa Point In Polygon de Centrus. Para un proceso por lotes donde todos sus puntos y polígonos sean evidentes y desee procesar todas las geometrías, la segunda situación en que se usa la etapa Query Spatial Data es mucho más eficaz. En casos en que los datos de polígono no cambian y los puntos se transmiten uno a la vez (es decir, un usuario ingresa una dirección, que se geocodifica, y luego determina en qué territorio de ventas se encuentra la dirección), el primer escenario que usa la etapa Point In Polygon de Centrus es la solución más rápida.

¿Hay otras consideraciones en cuanto a rendimiento? Cuando use Query Spatial Data, debe considerar el número de puntos y polígonos que se están procesando. Cuando tenga más polígonos que puntos, considere iterar puntos (lea un punto a la vez usando Read Spatial Data y busque basándose en la tabla de polígonos con Query Spatial Data). Cuando tenga más puntos que polígonos, considere iterar polígonos (lea un polígono a la vez usando Read Spatial Data y busque basándose en la tabla de puntos con Query Spatial Data).

¿Dónde están sus datos? Es importante saber dónde se ubican sus datos y qué tipo de datos tendrá en su solución. Por ejemplo, tener archivos TAB en el sistema de archivos, en comparación con tener los datos en DBMS, cambiará el rendimiento de su operación. Spectrum transfiere el procesamiento de ciertas operaciones (combinaciones espaciales) a la base de datos (por ejemplo, Oracle y SQL Server), lo que mejorará el rendimiento. Por ejemplo, operaciones similares a esta:

SELECT a.id, b.id FROM flood_plane a, customers b WHERE MI_Contains(a.geom, b.geom)
Nota: Si desea ejecutar la misma operación en que ambas tablas son archivos TAB nativos (sin datos en una base de datos), logrará un mejor rendimiento si lee los registros de una de las tablas, uno a la vez, y realiza la consulta basándose en la otra tabla con Query Spatial Data.

¿Sus datos son estáticos o cambiantes? Si sabe que sus datos no cambian (todos o algunos de ellos), y está utilizando la operación Query Spatial Data, existe una opción de configuración cuando crea sus recursos con nombre asignado que podría mejorar considerablemente el rendimiento. En Spectrum, esto se conoce como volatilidad. Por defecto, todos los recursos tienen configurada la volatilidad en "true", lo que significa que Spectrum supone que los datos pueden cambiar en cualquier momento y debe revisarlos cada vez que se accede a ellos para determinar si cambiaron y decidir si es necesario cargar nuevos datos.

¿Cómo afecta la volatilidad a las operaciones de punto en polígono? Si la volatilidad no se configura en "true", e incluso si el origen de datos no ha cambiado, el solo hecho de revisar el recurso disminuirá el rendimiento. Si sabe que los datos no cambiarán y el rendimiento es necesario, desactive la volatilidad. Si hay un problema de rendimiento y sabe que algunos de los datos cambiarán (como las listas de clientes o los puntos de prospección), pero algunos de sus datos no cambiarán (parcelas, tierras o áreas de venta), asegúrese de que la volatilidad no esté activada en el caso de los datos estáticos. Esta configuración podría aumentar significativamente el rendimiento general. Para obtener más información sobre la volatilidad y cómo cambiar esta configuración en el caso de los recursos, consulte Volatilidad de la fuente de datos.