Artículo técnico
App de captura de datos en campo sin conexión: 12 requisitos
Lista de verificación de 12 puntos para evaluar una app de captura de datos en campo sin conexión en levantamientos prediales y ambientales.
Quien ha levantado información predial o ambiental conoce la escena: la brigada llega a una vereda sin señal, la aplicación pide conectarse y el día de trabajo se pierde en una libreta. Esta guía, escrita desde la experiencia de proyectos de captura de datos técnicos georreferenciados, propone doce puntos para evaluar una app antes de llevarla al terreno.
¿Qué significa realmente trabajar sin conexión?
Significa que la app capture, valide, guarde y exporte sin servidor. No basta con «guardar en el teléfono y subir después»: si el mapa, los catálogos y las reglas de validación se descargan al abrir cada formulario, la app depende de la red aunque diga lo contrario. La prueba es simple: ponga el teléfono en modo avión y ejecute un levantamiento completo, desde abrir el proyecto hasta exportarlo.
¿Cuáles son los 12 puntos de la lista de verificación?
Use esta lista como criterio de compra o de aceptación. Cada punto se responde con sí o no, y un no debe tener una razón escrita.
- Mapa base sin conexión. Se puede descargar un área antes de salir y consultarla sin red, incluido el relieve cuando el trabajo lo requiere.
- Capas propias. Se cargan predios, límites o zonas de interés como capas del mapa, y las capas pesadas se guardan en caché en el dispositivo para que el mapa no se congele.
- Precisión GPS mínima y validación. Se define un umbral por proyecto (por ejemplo, 15 m en reconocimiento o 3 m en detalle), el punto se promedia hasta converger y la app rechaza lo que no cumple.
- Formularios con dominios. Listas cerradas, rangos, campos obligatorios y dependencias entre campos, definidos antes de salir y no escritos a mano en campo.
- Fotos georreferenciadas. Cada foto queda ligada a su registro y a su coordenada, con fecha y hora, y se exporta con sus metadatos.
- Trazas. Los recorridos se graban con duración, distancia y perfil de elevación, y sirven de evidencia de que la brigada pasó por el lugar.
- Sincronización. Hay una vía clara para llevar el dato de los teléfonos a la base central, con manejo de conflictos cuando dos personas tocan el mismo registro.
- Exportación a formatos abiertos. GeoPackage, GeoJSON, GPX y CSV abren en QGIS y entran a PostGIS sin conversiones intermedias.
- Integridad del dato. El paquete exportado trae una suma de verificación (por ejemplo, SHA-256) para comprobar que nada cambió en el camino.
- Identificadores únicos. Cada registro nace con un identificador global (UUID) generado en el dispositivo, no con un consecutivo que colisiona entre brigadas.
- Versionado. La plantilla del formulario tiene versión, y cada registro guarda con cuál se capturó; así un cambio de campos no invalida lo ya levantado.
- Idiomas. La interfaz y los mensajes se adaptan al idioma del equipo; en proyectos con cooperación internacional pesa más de lo que parece.
¿Cómo se modela un formulario de campo?
Un formulario bien definido es un archivo, no una pantalla dibujada a mano. Este ejemplo en YAML muestra los elementos mínimos de un formulario de visita predial: identificador, tipos, dominios y validaciones. Es un esquema ilustrativo para entender el modelo, no el formato interno de una app en particular.
formulario: visita_predial
version: "1.3"
crs_exportacion: "EPSG:4326"
campos:
- nombre: id_registro
tipo: uuid
generado: true # lo crea el dispositivo, nunca el usuario
- nombre: codigo_predio
tipo: texto
obligatorio: true
patron: "^[0-9]{30}$" # número predial de 30 dígitos
- nombre: uso_predio
tipo: lista
obligatorio: true
dominio: [residencial, agropecuario, comercial, forestal, sin_uso]
- nombre: area_construida_m2
tipo: decimal
minimo: 0
maximo: 100000
visible_si: "uso_predio != 'sin_uso'"
- nombre: ubicacion
tipo: punto
precision_maxima_m: 15 # rechaza el punto si el GPS no converge
- nombre: fotos
tipo: foto
minimo: 1
maximo: 5
georreferenciada: true
- nombre: observacion
tipo: texto_largo
obligatorio: false
Tres cosas conviene notar. El dominio de uso_predio evita «Residencial», «residencial » y «vivienda» como tres valores distintos. La regla visible_si quita campos que no aplican y reduce el error humano. Y la precisión máxima convierte la calidad del GPS en una condición del formulario, no en una opinión del operador.
¿Cómo lo resuelve GcMapFlow, nuestra app propia?
GcMapFlow es una aplicación Android nativa, desarrollada por nosotros, que captura sin servidor. Para ser claros con lo que hace hoy, y también con lo que no:
- Hace: mapas 2D y 3D sin conexión, con descarga de área; carga de capas GeoPackage, MBTiles y GeoPDF; GPS con promediado por convergencia y tres niveles de exigencia (urbano hasta 25 m, estándar hasta 15 m y detalle hasta 3 m); formularios dinámicos de 28 tipos de campo armados desde una plantilla de Excel; trazas con perfil de elevación; medición de distancias y áreas; cuatro idiomas (español, inglés, portugués y francés).
- Exporta solo a GeoPackage, GeoJSON, GPX y CSV, en WGS84 (EPSG:4326), dentro de un paquete .zip con fotos con EXIF y un manifiesto con verificación SHA-256. No produce shapefile ni KML, que siguen siendo frecuentes en el sector pero tienen límites de nombres de campo y de tipos de dato.
- No hace: no reemplaza un equipo geodésico; la precisión depende del GPS del teléfono. Tampoco es un servidor de sincronización multiusuario listo para usar: la integración con la base central se diseña según el proceso de cada organización.
Esa última frase es importante para quien compra. Una app de campo es una pieza de un sistema; los formularios y el modelo se ajustan al proceso del cliente, y el dato exportado debe entrar a una base bien estructurada. Conozca el detalle en la página de GcMapFlow.
¿Cómo se aplica esto a un levantamiento predial?
En catastro multipropósito, la lista anterior pesa más porque el dato alimenta un modelo con exigencias de calidad: el estándar LADM-COL y los lineamientos de la autoridad catastral nacional. El campo captura la visita, la oficina la valida y la base la consolida. Si la captura sale con identificadores repetidos, dominios abiertos o coordenadas sin precisión declarada, el costo se paga en la depuración.
Por eso recomendamos probar la herramienta con un piloto pequeño: veinte predios, dos brigadas, un día sin señal y la exportación completa a QGIS. Si los datos llegan íntegros y verificables, la herramienta está lista para escalar. Para entender cómo se articula la captura con el modelo catastral, consulte nuestra solución de catastro multipropósito.
¿Qué errores se repiten al elegir una herramienta?
Después de varios levantamientos vemos los mismos tropiezos. El primero es juzgar la app por su pantalla de mapa y no por lo que sale de ella: un formulario atractivo que exporta un archivo sin identificadores ni dominios solo traslada el problema a la oficina. El segundo es probar con buena señal y en la ciudad; la prueba válida se hace en el sitio más aislado del proyecto, con la batería al 30 % y con guantes. El tercero es olvidar el espacio: fotos de alta resolución, mapas descargados y capas pesadas llenan el almacenamiento de un teléfono de gama media en pocos días, así que conviene medir cuánto ocupa una jornada típica.
El cuarto error es no definir quién custodia el dato. Cada brigada debe saber dónde entrega su paquete exportado, quién lo verifica con la suma de comprobación y cuándo se puede borrar del teléfono. Sin ese acuerdo, el teléfono se vuelve la única copia de semanas de trabajo.
¿Cuál es el siguiente paso?
Tome la lista de 12 puntos, califique la herramienta que usa hoy y anote los tres «no» más costosos. Con eso se decide si basta con ajustar procesos o si conviene una captura a la medida.
Si desea probar GcMapFlow o ajustarla a su proceso de levantamiento, visite GcMapFlow y escríbanos: le proponemos un piloto con sus propios datos.