Diseñar modelos de datos efectivos para la adquisición de datos de campo

Un sistema de información geográfica (SIG) se compone de capas de mapa base y operacionales. Las capas operacionales son las que se emplean para editar e identificar entidades. Las capas de mapa base proporcionan información visual de referencia de fondo. Por ejemplo, un proyecto de campo que implique adquirir las ubicaciones XY y los atributos de las válvulas de agua recién instaladas en una subdivisión tendría una capa operacional de válvulas de agua. Esta es la capa que se editará en el campo. También puede haber una capa operacional de tuberías de agua que se use para identificar las distintas tuberías de agua y ayudar así al trabajador de campo. Bajo estas capas operacionales, puede incluir una capa de mapa base que contenga imágenes aéreas de esta área de operación para mostrar las calles, los parques y otros puntos de interés de fondo.

En los proyectos de campo, es recomendable que los mapas sean tan sencillos como sea posible. Evite las capas innecesarias y otras funciones avanzadas de ArcGIS for Desktop. Considere las restricciones del dispositivo móvil y las condiciones de campo en las que se utilizará el mapa móvil.

Soporte de geodatabase

ArcGIS for Windows Mobile admite la edición de datos dentro de las geodatabases basadas en archivos y geodatabases de ArcSDE multiusuario. Es posible que el mapa móvil contenga capas que hacen referencia a otras fuentes de datos, pero si desea capturar nuevas entidades o actualizar las entidades existentes, la fuente de datos de la capa debe constituir una clase de entidad almacenada dentro de una geodatabase. El flujo de trabajo de geodatabase basada en archivo está centrado en el equipo de escritorio y aprovecha las herramientas de geoprocesamiento móviles y Mobile Project Center para crear un proyecto y sincronizar las ediciones de campo con la geodatabase principal. La geodatabase multiusuario puede utilizar las herramientas de geoprocesamiento, pero también puede usar ArcGIS Server para crear servicios móviles que se podrán emplear en Mobile Project Center para crear un proyecto, con lo que los usuarios de campo podrán descargar y cargar los cambios de los datasets en el servidor cuando estén en un entorno con conexión.

A continuación se muestran los requisitos de las clases de entidades de ArcGIS for Windows Mobile para las capas operacionales:

• Deben estar almacenadas en una base de datos basada en archivo o multiusuario (ArcSDE).
• Las clases de entidades no pueden tener nombres de campo que estén reservados en el lenguaje SQL.

Esquema de datos y objetivos de las capas de mapa operacionales

Cuando diseñe el esquema de las capas de mapa operacionales, tenga en cuenta los usos previstos para cada capa de mapa y no olvide los requisitos de esquema de una capa. También debe tener en cuenta las propiedades de los campos de las capas de mapa.

Requisitos de esquema de datos para los objetivos de las capas operacionales

Los objetivos que se pueden especificar para una capa operacional se describen en la lista siguiente. Una capa de mapa solo se puede usar para uno de los siguientes propósitos:

• Para adquirir datos: una capa de adquisición de datos debe contener el campo GlobalID. Además, para que una capa operacional que reside en una geodatabase de archivo sea editable, debe usar la herramienta Crear memoria caché móvil para generar una memoria caché móvil desde el mapa que contiene la capa. Si la capa reside en una geodatabase de ArcSDE, también puede usar la herramienta Crear memoria caché móvil para generar una caché móvil o puede publicar el mapa en ArcGIS 10.1 for Server como servicio móvil (en cuyo caso debe registrar la base de datos en el servidor).
• Para proporcionar información de referencia de solo lectura: no hay restricción en cuanto al esquema de una capa de solo lectura.
• Para identificar al usuario actual: una capa de identidad debe ser una capa de puntos con dos campos de texto, uno para almacenar la identidad del usuario y otro para almacenar el nombre de visualización del usuario. Si los trabajadores de campo no van a editar la capa, no se requiere GlobalID. Puede alojar la capa en un servidor de ArcGIS o en una memoria caché usando la herramienta Crear memoria caché móvil.
• Capa de registro: una capa de registro debe ser una capa de punto con el campo GlobalID, un campo de fecha y hora, un campo de texto para el nombre del equipo (o la información de identidad si se tiene una capa de identidad). Puede alojar la capa en un servidor de ArcGIS o en una memoria caché usando la herramienta Crear memoria caché móvil.
• Capa de equipo de campo: similar a una capa de registro, una capa de equipo de campo debe ser una capa de punto con el campo GlobalID, un campo de fecha y hora, y un campo de texto para el nombre del equipo o la información de identidad. Dado que la capa sincroniza y actualiza las últimas ubicaciones conocidas de los trabajadores de campo de forma periódica, debe proceder de un servicio móvil y no de una memoria caché móvil local.
• Oculta para el usuario: no hay restricción en cuanto al esquema de una capa oculta.

Si desea obtener más información sobre los propósitos de las capas, consulte Propiedades de la capa operacional.

Campos de capa de mapa y propiedades de los campos

Entre los funcionamientos de geodatabase compatibles con las aplicaciones de ArcGIS for Windows Mobile, se encuentran los siguientes:

• Subtipos: se emplean para clasificar las entidades almacenadas en una clase de entidad. Por ejemplo, las entidades de árbol se pueden clasificar según el tipo de árbol. Cuando se crea una nueva entidad de árbol en el campo, el trabajador de campo puede elegir el tipo de árbol que desea crear, con lo que se elimina la necesidad de especificar el tipo como un atributo independiente.
• Dominios: se admiten dominios de rango y de valores codificados. Cada dominio de valor codificado aparece como una lista de selección cuando se adquieren o se actualizan valores de atributos. Los valores predeterminados se marcan con un asterisco (*). Si no se ha especificado ningún valor predeterminado, se le pedirá que introduzca un valor válido. Dominios de rango: indican el rango de valores válidos que se pueden especificar para un atributo numérico.
• Valores predeterminados: cuando se asigna un valor predeterminado a un campo de atributo, no es necesario hacer nada para introducir el valor. Por ejemplo, un campo de atributo de altura de un árbol se puede definir como 10. El valor de la altura de todas las entidades de árbol nuevas adoptará automáticamente el valor 10. Si el árbol es más bajo o más alto que 10, puede introducir la altura adecuada. Se puede asignar un valor predeterminado a cualquier campo de atributo de una clase de entidad.
• Adjuntos: habilitar una clase de entidad para que almacene adjuntos proporciona una forma de gestionar la información relacionada con las entidades. Los adjuntos se deben agregar a las clases de entidad de la geodatabase para que sea posible usarlos en el campo. Un uso común de los adjuntos consiste en almacenar una foto digital de una entidad. Puede adquirir y ver varios adjuntos para una misma entidad.
• Ráster/blob: los campos de tipo de ráster/blob se reconocen como un tipo de campo especial que se puede utilizar para almacenar fotografías. Puede buscar fotos y agregarlas al campo ráster o utilizar directamente la cámara incorporada en el dispositivo móvil. Para cada entidad, solo se puede tener una imagen por campo ráster/blob.
  Precaución:

  Si desea usar un campo blob para almacenar imágenes, debe utilizar esri_picture o picture_ as como prefijo del nombre del campo. Por ejemplo, esri_picture y picture_WaterValve son aceptables.

• Fechas: los campos de atributos pueden almacenar fechas si se definen como tipo de datos. En el campo, puede definir la fecha y la hora actual al editar. Para ello, selecciónelas en el calendario que se abre cuando se edita el campo de atributo.
• Números de teléfono: si utiliza un campo de texto para almacenar los números de teléfono y formatear correctamente el número de teléfono de modo que lo reconozca un dispositivo con Windows Mobile que tenga incorporada una tarjeta de móvil, puede iniciar el teléfono y llamar al número directamente desde la aplicación de ArcGIS.

Nota:

Se pueden editar las clases de entidades que están habilitadas para z o m, pero no se mantendrán los valores z y m. No se establecerán los valores z o m para las entidades que se adquirieron recientemente.

ArcGIS for Windows Mobile no permitirá que cree una nueva capa de mapa o que altere el esquema de campos de atributos en un dispositivo móvil. Si prevé la necesidad de capturar entidades que no existen dentro del modelo de datos actual o si necesita capturar información no estructurada, como notas de campo, es recomendable que cree una clase de entidad adicional dentro del esquema de la geodatabase para controlar el almacenamiento de esta información.

Consideraciones de diseño de la geodatabase

El SDK y las aplicaciones de campo de ArcGIS for Windows Mobile aprovechan al máximo la información creada en la geodatabase y la forma en que se visualiza el contenido en ArcMap.

Si hay una geodatabase multiusuario que se desea utilizar para un proyecto de campo, se puede optar por una de estas alternativas:

• Aprovechar la estructura existente mediante la replicación de geodatabase.
• Transformar la geodatabase mediante un proceso de extracción, transformación y carga (ETC).

En las siguientes secciones se describen los modelos de replicación de geodatabase y ETC para la administración de las aplicaciones de edición de campo con las geodatabases existentes.

Modelo de replicación de geodatabase

Puede publicar el contenido de la geodatabase multiusuario para el uso en el campo y utilizar el versionado para aislar las modificaciones que vienen desde el campo de otras modificaciones que se realizan en la oficina. Sin embargo, hay varios desafíos con este enfoque. Por ejemplo, si necesita sincronizar las actualizaciones desde el campo, la geodatabase de producción debe ser accesible fuera del firewall de la empresa. Esto no es posible para la mayoría de las organizaciones. Una táctica mejor es la de utilizar la replicación de geodatabase y aislar la información que se capturó en el campo de la información que se actualiza continuamente en la oficina.

Al utilizar la replicación de geodatabase, puede crear una instancia de geodatabase corporativa independiente que almacenará las modificaciones que se realizaron en el campo y sincronizará periódicamente las actualizaciones con la geodatabase principal. Al utilizar este enfoque, solo tendrá que replicar la información que debe llevar al campo (no toda la geodatabase de información) y podrá aislar los servicios web móviles de la geodatabase de producción principal. Algunos ejemplos de casos en los que la replicación puede ser muy útil incluyen un sistema distribuido en el que las oficinas remotas tienen trabajadores de campo y no tienen conectividad con la oficina principal o si un equipo portátil montado en un vehículo contiene una geodatabase replicada y las modificaciones de campo se sincronizan cuando el dispositivo se encuentra acoplado en el vehículo. En ambos ejemplos, los metadatos se pueden almacenar para cada tarea de edición de campo que no pertenezca a la geodatabase corporativa (por ejemplo, los datos de medición de Sistema de posicionamiento global [GPS] que se requieren para la corrección diferencial de los datos adquiridos).

Modelo ETC

Por lo general, la forma en que la información espacial se representa en una base de datos corporativa es diferente de la forma en que se crea y se actualiza en el campo. Un ejemplo es modelar los polígonos de lago como entidades de línea de costa para que se puedan capturar en partes. Otro es unir las tablas de datos normalizadas o los campos de atributo almacenados en la geodatabase corporativa en una tabla o atributo de la geodatabase de campo. Otro buen ejemplo es la información de atributos de calle. Por lo general, el nombre de calle adecuado se almacena en varios atributos (número, prefijo, nombre, sufijo, etc.). En ArcMap, se usa una expresión para etiquetar el nombre completo de la calle. Si desea visualizar el nombre de la calle en un dispositivo móvil, debe unir estos atributos en un campo que pueda etiquetar.

Puede utilizar los modelos de geoprocesamiento para administrar los procesos ETC entre las geodatabases móviles y corporativas. También puede utilizar la extensión Data Interoperability de ArcGIS para diseñar de manera visual estos procesos de transformación. Es importante tener en cuenta que es posible que los procesos definidos no sean bidireccionales. Deberá definir un conjunto de modelos de geoprocesamiento o herramientas ETC espaciales personalizadas para transformar el modelo de datos para un dispositivo móvil y un segundo conjunto de modelos para volver a ensamblar los datos de campo para que se ajusten al esquema corporativo.

Modelo de transacción móvil

El modo en que las actualizaciones de los campos se van a administrar e integrar en la geodatabase está incorporado al modelo de transacción. En parte, esto viene definido por las decisiones de diseño de la geodatabase, pero también por el número de editores de campo a los que se debe dar servicio y por el grado de aislamiento que se desea que tengan las modificaciones de estos.

A continuación se incluyen algunas de consideraciones relativas al modelo de transacción:

• ¿Desea que las modificaciones de campo actualicen la versión predeterminada de la geodatabase? Si no es así, ¿desea que haya una versión para todas las modificaciones de campo o que haya una versión para cada editor de campo?
• ¿Puede actualizar la geodatabase sin utilizar el versionado?
• ¿Necesita archivar las modificaciones realizadas en el campo?
• ¿Cómo se administrarán los conflictos entre las actualizaciones de campo?

Las siguientes secciones describen algunas de las funciones clave que se deben tener en cuenta cuando se diseña una geodatabase para el uso de campo.

Editar una geodatabase no versionada

Si tiene pocos editores de campo que realizan tareas de edición sencillas, como actualizar atributos, y hay poca o ninguna probabilidad de que actualicen la misma entidad en el campo, es posible que el modelo de transacción no versionado sea el que mejor se ajuste a sus necesidades. Una posible desventaja de este enfoque es que la actualización directa es la única opción disponible para el editor de campo. Si por alguna razón deben sincronizarse las actualizaciones pero no están completas, la sincronización se volverá problemática. Con el versionado, tendrá más flexibilidad en la forma en que los trabajadores de campo pueden sincronizar las actualizaciones.

Al utilizar un modelo de transacción versionado, puede aislar las ediciones de campo y agregar controles del procesamiento posterior y de garantía de calidad adicionales antes de conciliar las actualizaciones. Según cómo desea aislar las modificaciones de campo, puede crear una sola versión para almacenar todas las modificaciones de campo o puede crear una versión para cada editor de campo. Si crea una versión para cada editor, deberá publicar un servicio de mapa móvil para cada editor. Una vez que los editores hayan completado la captura o el mantenimiento de los datos y sincronizado las actualizaciones con la geodatabase, se necesitará ArcGIS for Desktop para conciliar las modificaciones de la versión con la versión principal desde la oficina.

Marco de edición de cliente de ArcGIS for Windows Mobile

Las aplicaciones de ArcGIS for Windows Mobile no tienen un concepto de iniciar, detener y guardar las modificaciones como el que existe en otras aplicaciones de ArcGIS. Cada modificación que se realiza se almacena dentro de la memoria caché del servicio móvil en el dispositivo hasta el momento en que se decide sincronizar las actualizaciones con el servidor. Puede elegir cancelar una modificación realizada dentro de la aplicación, lo que deshace todas las actualizaciones que se realizaron en el campo y restaura el estado original de la entidad previo a la edición, pero no puede deshacer las modificaciones de una entidad de una en una.

Al actualizar la capa de entidades no se sincronizan directamente los cambios con la geodatabase.

Publicar cambios

Las actualizaciones que realiza en el campo se almacenan de manera local en la memoria caché del servicio móvil en el dispositivo móvil. Esto es importante porque es posible que los trabajadores de campo no estén conectados todo el tiempo en el campo o que deban desconectar y cargar los dispositivos, y es crucial que las actualizaciones no se pierdan. Cuando se establece la conectividad con el servidor, puede sincronizar las actualizaciones que se almacenaron en la memoria caché con el servidor.

Cuando publique las modificaciones desde el dispositivo móvil, solo se enviarán al servidor los cambios, conocidos como "deltas". Por ejemplo, si cambia un atributo en una entidad, sólo se registra el cambio a ese campo específico en lugar de que se marque toda la fila como editada. Esto se realiza de modo que cuando cambia la sincronización, sólo se envía de regreso al servidor la información que cambió.

Según el número de modificaciones que espere y el tipo de conexión al servidor existente (servicio general de radio por paquetes [GPRS], por ejemplo), es posible que desee habilitar la publicación de entidades solo cuando la aplicación y el dispositivo se encuentren de nuevo en la oficina para garantizar una conexión estable y de alta velocidad.