¿Qué es un Stream Service? <\/STRONG><\/P> <\/P>Además de los conocidos y ya existentes Map- & Feature Services, desde hace algunos años (primer lanzamiento con 10.3.) existe un nuevo tipo de servicio en el mundo ArcGIS, que fue desarrollado principalmente para la visualización eficiente de datos en tiempo real: el Stream Service.<\/P> <\/P>El Stream Service está vinculado al ArcGIS GeoEvent Server, la solución de software de Esri para integrar flujos de datos en tiempo real, realizar análisis basados en eventos en tiempo real sobre los datos entrantes y distribuirlos posteriormente, es decir, hacerlos utilizables dentro y fuera de la plataforma ArcGIS. Por supuesto, la necesidad de procesar y también visualizar los datos en tiempo real juega un papel importante. Debido a esta necesidad, el equipo de desarrollo alrededor del GeoEvent Server pensó cómo reducir la latencia en la visualización de datos dinámicos para no solo mostrar DÓNDE sucede algo sino también CUÁNDO sucede directamente.<\/P> <\/P>Un ejemplo de un Stream Service que consulta y visualiza la posición actual de la International Space Station desde una API puede ser visto aquí<\/A> <\/STRONG>.<\/P> <\/P> <\/A><\/P> <\/P>¡Un nuevo concepto para la visualización de datos dinámicos!<\/STRONG><\/P> <\/P>Tradicionalmente, los datos que subyacen a un dynamic Feature Services se almacenan en una Enterprise Geodatabase (EGDB) u otro tipo de almacenamiento de datos como por ejemplo el Spatiotemporal Big Data Store (SBDS*). Esto significa que para la visualización, el cliente, por ejemplo nuestra aplicación web, debe consultar periódicamente el estado actual del almacenamiento de datos para actualizar la visualización de las features en el mapa. En este contexto se habla de polling, lo que equivale a un intervalo de actualización que causa un retraso en el procesamiento de flujos de datos en tiempo real después de que el GeoEvent Server los procesa y escribe en la base de datos.<\/P> <\/P><\/P><\/P>Para minimizar esta latencia, el Stream Server se basa en un concepto donde los datos no se escriben primero en una base de datos sino que se envían directamente al cliente mediante push. Para ello se establecen conexiones WebSocket directamente entre el Stream Server y el Stream Layer en el cliente, a través de las cuales las features se transmiten y visualizan sin ningún retraso.<\/SPAN><\/P> <\/P> <\/P>Persistencia de los datos<\/STRONG><\/P> <\/P>Quizás surja ahora la pregunta, ¿qué pasa si un cliente se conecta inicialmente al Stream Server y los datos existentes no han sido almacenados? Esto significaría que el cliente solo podría visualizar las features existentes cuando un nuevo evento o actualización del estado para esa feature sea procesado por el GeoEvent Server y enviado al Stream Server. Esto no es un escenario ideal, especialmente si no todas las features se actualizan en intervalos cortos y regulares y por lo tanto podrían no aparecer en la aplicación durante un período prolongado.<\/P> <\/P>Por eso, para los Stream Servers existe el concepto del "Store Latest" Feature Service, que puede publicarse junto con el Stream Service y donde, como su nombre indica, se almacenan paralelamente los estados más recientes de las respectivas features. Si se selecciona esta opción, la información sobre el "Store Latest" Feature Service se incluye en la descripción del Stream Service. Así, los clientes pueden realizar una consulta basada en esta información al conectarse inicialmente al Stream Server para obtener los estados actuales de las features desde el Feature Service y visualizarlos en el mapa. Luego, el Stream Layer toma nuevamente el control y visualiza nuevos eventos inmediatamente en tiempo real.<\/P> <\/P>Unión de geometrías y atributos estáticos en el cliente<\/STRONG><\/P> <\/P>Por supuesto, idealmente solo deberían actualizarse constantemente las informaciones dinámicas de una feature, por ejemplo en sensores estáticos dentro de una red sensoras generalmente son valores medidos que siempre se actualizan mientras que información como la geometría u otras propiedades del sensor son mayormente estáticas. Por ello también se integró un concepto para estos casos de uso en el Stream Server que permite referenciar un Feature Service con "Related Features". Con esta información, que también se proporciona al cliente a través de la descripción del Stream Server, se pueden añadir informaciones estáticas directamente al evento entrante mediante una ID única (Track ID).<\/P> <\/P>Posibilidades para desarrolladores<\/STRONG><\/P> <\/P>El Stream Server o más bien el Stream Layer en las aplicaciones también ofrece interesantes posibilidades para desarrolladores para utilizar esta tecnología más ampliamente. Desde el lanzamiento original de la tecnología en la versión10.3., el Stream Layer está disponible para aplicaciones web basadas en JavaScript a través del ArcGIS API for JavaScript y se integra continuamente en otros componentes y APIs de ArcGIS. Una posibilidad interesante es suscribirse a los eventos "onMessage" (JS API) / "on_features" (Python API) del Stream Layer, lo que permite analizar cada evento enviado en formato Esri JSON antes de visualizarlo en el mapa.<\/P> <\/P>En la ya mencionada ISS Demo<\/A>, por ejemplo uso el evento "onMessage" de un StreamService que envía como GeoTag si la ISS sobrevuela tierra o mar para actualizar la visualización del texto al cambiar de territorio.<\/P> <\/P>¡Diviértanse explorando y usando este nuevo tipo de layer en sus aplicaciones en tiempo real! <\/P> <\/P>Tom<\/P> <\/P><\ / BODY ><\ / HTML >
<\/P>
¡Un nuevo concepto para la visualización de datos dinámicos!<\/STRONG><\/P> <\/P>Tradicionalmente, los datos que subyacen a un dynamic Feature Services se almacenan en una Enterprise Geodatabase (EGDB) u otro tipo de almacenamiento de datos como por ejemplo el Spatiotemporal Big Data Store (SBDS*). Esto significa que para la visualización, el cliente, por ejemplo nuestra aplicación web, debe consultar periódicamente el estado actual del almacenamiento de datos para actualizar la visualización de las features en el mapa. En este contexto se habla de polling, lo que equivale a un intervalo de actualización que causa un retraso en el procesamiento de flujos de datos en tiempo real después de que el GeoEvent Server los procesa y escribe en la base de datos.<\/P> <\/P><\/P><\/P>Para minimizar esta latencia, el Stream Server se basa en un concepto donde los datos no se escriben primero en una base de datos sino que se envían directamente al cliente mediante push. Para ello se establecen conexiones WebSocket directamente entre el Stream Server y el Stream Layer en el cliente, a través de las cuales las features se transmiten y visualizan sin ningún retraso.<\/SPAN><\/P> <\/P> <\/P>Persistencia de los datos<\/STRONG><\/P> <\/P>Quizás surja ahora la pregunta, ¿qué pasa si un cliente se conecta inicialmente al Stream Server y los datos existentes no han sido almacenados? Esto significaría que el cliente solo podría visualizar las features existentes cuando un nuevo evento o actualización del estado para esa feature sea procesado por el GeoEvent Server y enviado al Stream Server. Esto no es un escenario ideal, especialmente si no todas las features se actualizan en intervalos cortos y regulares y por lo tanto podrían no aparecer en la aplicación durante un período prolongado.<\/P> <\/P>Por eso, para los Stream Servers existe el concepto del "Store Latest" Feature Service, que puede publicarse junto con el Stream Service y donde, como su nombre indica, se almacenan paralelamente los estados más recientes de las respectivas features. Si se selecciona esta opción, la información sobre el "Store Latest" Feature Service se incluye en la descripción del Stream Service. Así, los clientes pueden realizar una consulta basada en esta información al conectarse inicialmente al Stream Server para obtener los estados actuales de las features desde el Feature Service y visualizarlos en el mapa. Luego, el Stream Layer toma nuevamente el control y visualiza nuevos eventos inmediatamente en tiempo real.<\/P> <\/P>Unión de geometrías y atributos estáticos en el cliente<\/STRONG><\/P> <\/P>Por supuesto, idealmente solo deberían actualizarse constantemente las informaciones dinámicas de una feature, por ejemplo en sensores estáticos dentro de una red sensoras generalmente son valores medidos que siempre se actualizan mientras que información como la geometría u otras propiedades del sensor son mayormente estáticas. Por ello también se integró un concepto para estos casos de uso en el Stream Server que permite referenciar un Feature Service con "Related Features". Con esta información, que también se proporciona al cliente a través de la descripción del Stream Server, se pueden añadir informaciones estáticas directamente al evento entrante mediante una ID única (Track ID).<\/P> <\/P>Posibilidades para desarrolladores<\/STRONG><\/P> <\/P>El Stream Server o más bien el Stream Layer en las aplicaciones también ofrece interesantes posibilidades para desarrolladores para utilizar esta tecnología más ampliamente. Desde el lanzamiento original de la tecnología en la versión10.3., el Stream Layer está disponible para aplicaciones web basadas en JavaScript a través del ArcGIS API for JavaScript y se integra continuamente en otros componentes y APIs de ArcGIS. Una posibilidad interesante es suscribirse a los eventos "onMessage" (JS API) / "on_features" (Python API) del Stream Layer, lo que permite analizar cada evento enviado en formato Esri JSON antes de visualizarlo en el mapa.<\/P> <\/P>En la ya mencionada
¡Diviértanse explorando y usando este nuevo tipo de layer en sus aplicaciones en tiempo real! <\/P>
Tom<\/P>
<\ / BODY ><\ / HTML >
Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
