Llevando Sus Mapas Sin Conexión: Publicando los Datos
Por Tom DeWitte, Kevin Ruggiero, Mike Hirschheimer
Parte 3 de 5
Las organizaciones grandes y pequeñas necesitan mantener informados a sus trabajadores móviles. Ya sea un día despejado o se estén formando tormentas arriba, los trabajadores móviles necesitan información actual sobre el sistema de servicios públicos que mantienen cada día. Esta información informa al trabajador móvil sobre qué conductores están energizados, qué tuberías están presurizadas y qué cables están activos. Información crítica que ayuda a mantener seguro al trabajador móvil y confiable el sistema de servicios públicos.
Transmitir nueva y actualizada información de manera consistente y confiable a toda la fuerza laboral móvil de una empresa de servicios públicos no es fácil. Los mapas en papel desplegados durante los primeros 150 años de la industria de servicios públicos no podían recibir actualizaciones incrementales. Al día siguiente de que los mapas en papel estaban en manos del trabajador móvil, la información en el mapa ya estaba desactualizada. El mismo problema aplicaba a las primeras aplicaciones visualizadoras de mapas móviles, como ArcReader. La instantánea de información almacenada localmente en el dispositivo móvil no podía actualizarse incrementalmente. También se volvía cada vez más obsoleta con cada día que pasaba después de creada la instantánea de información.
Estas lecciones aprendidas de esfuerzos previos para proporcionar información oportuna y actual al trabajador móvil nos dicen que se necesita un mecanismo para actualizar la información del trabajador móvil de manera incremental y consistente. En el mundo móvil actual, esto equivale a mantener una copia local de la representación geoespacial de las tuberías, conductores y cables en el teléfono, tableta o laptop del trabajador móvil. El mecanismo para transmitir esta información al dispositivo móvil cuando está conectado a una red son los web services.
Qué Son los Web Services
Un web service es un método de comunicación entre su dispositivo móvil y su servidor de datos. Cuando se crea un web service es un proceso siempre activo, que está escuchando solicitudes enviadas por aplicaciones cliente móviles.
Existen muchos tipos diferentes de web services. Dentro de ArcGIS Enterprise hay tipos especializados de web services para geocodificación, geoprocesamiento, compartir datos de imágenes y compartir datos vectoriales. Compartir datos vectoriales es cómo se pasan los registros de entidades y tablas entre el dispositivo móvil y el repositorio centralizado de datos.
ArcGIS Enterprise soporta múltiples tipos de web services para datos vectoriales. Estos incluyen KML, WFS, ArcGIS Feature Services y Hosted Feature Layers. ArcGIS Feature Services y Hosted Feature Layers son los únicos web services para compartir datos vectoriales que soportan la sincronización de cambios entre el dispositivo móvil y el repositorio centralizado de datos. Dicho de otra manera, para mantener informados a nuestros trabajadores móviles con cambios en los datos realizados por el personal de oficina y otros trabajadores móviles, debe haber un Feature Service o un Hosted Feature Layer para manejar la comunicación.
Un feature service es cómo se comparte a dispositivos móviles la data gestionada en ArcGIS Enterprise Geodatabase como los datos del Utility Network para sincronización.
Un hosted feature service es cómo se comparte a dispositivos móviles la data del hosted feature layer alojado en ArcGIS Portal para sincronización.
Organizando Datos con Feature Services
En el ejemplo que hemos estado describiendo en esta serie del blog, los datos que necesitan estar disponibles para almacenamiento local en el dispositivo móvil provienen de cuatro diferentes repositorios de datos. Dos repositorios son Enterprise Geodatabases, uno es hosted feature layers del Portal, y el cuarto es un basemap vector tile registrado en ArcGIS Online configurado para exportación. Cada Enterprise Geodatabase contendrá múltiples featureclasses y tablas cuyos registros deben sincronizarse con los dispositivos móviles.
Un solo feature service puede ser un agrupamiento de una o más featureclasses y tablas. Al tratar de determinar cómo organizar sus datos en feature services, es importante saber que cada feature service individual solo puede conectarse a un repositorio de datos. Esto significa que todas las featureclasses y tablas deben acceder a la misma enterprise geodatabase a través de la misma conexión relacional a base de datos.
Publicar datos para uso sin conexión tiene algunas restricciones adicionales sobre la organización del contenido en el feature service.
-Una featureclass o tabla solo puede ser referenciada una vez.
-Las capas grupo por subtipo no son un tipo soportado
Publicando un Feature Service para Sincronización
Crear un feature service también puede llamarse publicar los datos. Publicar los datos es el segundo de los cuatro pasos principales para crear áreas de mapas sin conexión.
El paso "Publicar los Datos" típicamente se realiza con la herramienta desktop ArcGIS Pro. La herramienta específica para usar es "Share as Web Layer" para publicar el feature service.
Por defecto, un feature service no soporta sincronización. Para activar la sincronización, marque la casilla "Enable Sync" dentro del panel de configuración de propiedades del feature.
Muchas featureclasses en enterprise geodatabases tienen sus geometrías configuradas para soportar almacenamiento de elevación (Z) y distancia a lo largo de una línea (M). Los editores en campo pueden no tener esta información disponible al momento de capturar datos. Para permitir que recolecten esta información sin una definición completa de geometría, deben definirse valores predeterminados y comportamientos.
Para el valor Z marque la casilla para activar "Apply default to features with Z-values". Luego establezca el valor z predeterminado deseado.
Para el valor M marque la casilla para activar "Allow geometry updates without m-value". Esto establecerá el valor M como NULL cuando se cree una nueva entidad.
Publicando Su Utility Network
Clave para mantener seguros a los trabajadores móviles es proporcionar información actual sobre sus activos utility. Cuando estos activos están almacenados en una enterprise geodatabase y gestionados con las capacidades del utility network, el paso de publicación consiste en modificar las propiedades de un feature service ya publicado.
Para que los mapeadores en oficina creen y mantengan la representación digital conectada de sus activos utility, se requiere que los datos estén configurados como branch versioned y publicados como un feature service. El feature service del utility network ya publicado puede no estar completamente configurado para sincronizar con áreas offline del mapa. Para soportar sincronización con áreas offline requiere dos configuraciones del feature service que deben establecerse. La primera es modificar las propiedades mencionadas anteriormente del feature service para habilitar sincronización. La segunda configuración es definir el rol que tendrá branch versioning durante el proceso de sincronización. Hay dos opciones para branch versioning durante sync:
-Ninguno
-Crear una versión para cada mapa descargado
Saber qué opción configurar comienza con entender qué harán sus trabajadores móviles con estos datos del utility asset.
Creación De Versiones = Ninguno
Si la respuesta a esta pregunta es que los trabajadores móviles solo verán y consultarán los datos del utility network, entonces la configuración predeterminada "Ninguno" es la correcta. Con esta configuración no se requiere adicional las versiones se crean o requieren para sincronizar con éxito.<\/P>
<\/span><\/P>Si configura la opción Creación de Versión en 1one7 y permite que sus trabajadores móviles editen los activos de servicios pfablicos, esas ediciones se publicarán directamente en la versif3n predeterminada. Sincronizar con la versif3n predeterminada compartire1 estas ediciones inmediatamente con todos los deme1s usuarios de oficina y campo.<\/P>Creacif3n de Versif3n = Versif3n para cada mapa descargado<\/STRONG><\/P>Esta opcif3n se recomienda cuando sus trabajadores mf3viles este1n editando los activos de servicios pfablicos gestionados por la red de servicios pfablicos, y esas ediciones necesitan ser revisadas y verificadas para control de calidad antes de compartirlas con el resto de la organizacif3n.<\/P>
<\/span><\/P>Cuando se elige esta opcif3n, se crea una versif3n ramificada dentro de la geodatabase empresarial cuando el trabajador mf3vil descarga el e1rea del mapa sin conexif3n por primera vez. Todas las ediciones de campo se sincronizare1n con la versif3n ramificada creada.<\/P>Una explicacif3n me1s detallada este1 disponible en la documentacif3n en ldnea de Esri<\/A>.<\/P>Creacif3n de Versif3n = Crear una versif3n para cada usuario<\/STRONG><\/P>Esta opci3n no es valida para servicios de entidades versionados por rama.<\/P>Con estas dos configuraciones establecidas, el servicio de entidades de la red de servicios pablicos est1 listo para soportar la sincronizaci3n del rea del mapa sin conexi3n.<\/P>
Publicando su Base Territorial<\/H2>A diferencia de la Red de Servicios Pablicos, puede que no exista un servicio de entidades para compartir la informaci3n base territorial. Los cart3grafos de oficina pueden estar usando la aplicaci3n ArcMap desktop y su capacidad de conexi3n directa para acceder a los datos base territoriales almacenados en una geodatabase empresarial. En esta configuraci3n de ejemplo, la geodatabase empresarial usar1 versionado tradicional para rastrear y gestionar cambios en la base territorial.<\/P>
<\/span><\/P>Publicar el servicio de entidades base territorial para soportar la sincronizaci3n del area del mapa sin conexi3n requiere marcar la opci3n de configuraci3n del servicio de entidades, Habilitar Sincronizaci3n.<\/P>
<\/span><\/P>Con la sincronizaci3n habilitada ahora debe decidir qu9 estrategia de versionado implementar para apoyar a los usuarios mviles. Si sus usuarios mviles no est1n destinados a crear o modificar las entidades base territoriales, entonces la opci3n correcta para Creaci3n de Versi³n para Sincronizaci³n es: None.<\/P>
<\/span><\/P>Si sus usuarios m\u{F}viles van a crear nuevas entidades base territoriales o modificar las existentes, entonces se necesita crear una versi\u{F}on para gestionar el flujo de ediciones en la base territorial. Hay dos opciones disponibles para gestionar versiones en versionado tradicional: \u201cCrear una versi\u{F}on para cada mapa descargado\u201d o \u201cCrear una versi\u{F}on para cada usuario\u201d.<\/P>Una explicaci\u{F}on m\u{E}s detallada sobre estas opciones de versi\u{F}on para sincronizaci\u{F}on est\u{E} disponible en la documentaci\u{F}on en l\u{ED}nea de Esri.<\/A><\/P>
Escalando sus Servicios de Entidades<\/H2>Al comienzo de cada jornada laboral probablemente haya un pico en el n\u{FA}mero de dispositivos m\u{F}viles intentando sincronizarse con los servicios publicados. Este pico es causado por los trabajadores m\u{F}viles que abren Field Maps y el mapa web habilitado para \u201carea del mapa sin conexi\u{F}on\u201d en su dispositivo m\u{F}vil. Esto iniciar\u{E1} una sincronizaci\u{F}on.<\/P>La capacidad que tiene un solo servicio de entidades para escalar y acomodar este pico matutino en dispositivos concurrentes que solicitan sincronizaci\u{F}on est\u{E} definida dentro del apartado pooling (agrupamiento) en las propiedades del servicio. Los par\u{E1}metros que impactan directamente en la capacidad son: \u201cN\u{FA}mero m\u{ED}nimo de instancias por m\u{E1}quina\u201d y \u201cN\u{FA}mero m\u{E1}ximo de instancias por m\u{E1}quina\u201d. Estos par\u{E1}metros son ajustables despu\u{E9}s que el servicio ha sido publicado.<\/P>
<\/span><\/P>El valor Número mÃnimo de instancias por máquina representa el nivel base de usuarios concurrentes que un solo servidor puede soportar. A medida que aumenta el número de solicitudes por datos, el servidor comenzará automáticamente a crear nuevas instancias adicionales. Esto continuará hasta que se satisfaga la demanda concurrente o se alcance el Número máximo de instancias por máquina.<\/P>Si el número concurrente excede el valor máximo, los usuarios adicionales serán puestos en cola y deberán esperar a que una instancia esté disponible.<\\/p>
Después del pico matutino, el número concurrente disminuirá hasta alcanzar el mínimo establecido.<\\/p>
Acerca de esta serie de blogs<\/H2>Este es el tercer artículo del blog en nuestra serie sobre áreas de mapas offline. En futuros artículos del blog continuaremos explicando los detalles de cómo funcionan las áreas de mapas offline y las decisiones específicas que un administrador deberá tomar durante el despliegue.<\/P>El primer blog<\/A> proporcionó una visión general de las áreas de mapas offline.<\/P>El segundo blog<\/A> proporcionó detalles sobre cómo preparar los datos para el uso offline y la sincronización.<\/P>El
cuarto blog<\/A> proporcionará detalles sobre la creación de áreas de mapas offline, cómo se almacenan y gestionan en el entorno del portal.<\/P>El
quinto y último blog<\/A> proporcionará detalles sobre el despliegue y la gestión de áreas de mapas offline para una gran fuerza laboral móvil.<\/P>NOTA: Las publicaciones en este sitio son propias y no representan necesariamente la posición, estrategias u opiniones de Esri.<\/EM><\/P>
