ODK Central v2026.2.4 en campo: formularios y salida
Un municipio chico puede relevar actas, fotos y coordenadas con ODK Central, usuarios por proyecto y exportación verificable sin planillas sueltas.
La inspección falla cuando dos cuadrillas nombran el mismo basural con rótulos distintos. ODK Central v2026.2.4 permite capturar formularios, fotos, GPS y marcas de tiempo en campo, incluso con conexión intermitente. Este caso anónimo de un municipio del Gran Mendoza muestra dónde se pierde el rastro, qué permisos separan carga y lectura, cuánto cuesta empezar y qué prueba confirma que la foto vuelve con el acta.
Qué cambia cuando el relevamiento deja la planilla
El flujo oficial de ODK arranca con formularios diseñados en XLSForm, sigue con carga en Central, captura desde Collect y termina en análisis o exportación de datos. La publicación ODK Central v2026.2.4, fechada el 21 de agosto de 2026, mantiene activa esa base para equipos que necesitan controlar campo, usuarios y evidencias. El acta llega tarde cuando la foto viaja separada del formulario. El municipio del caso tenía tres fuentes para una misma inspección: planilla mensual, carpeta de fotos y mensajes con ubicación. El dato salía, pero salía tarde y sin responsable claro. La documentación de instalación de Central dice que puede usarse ODK Cloud o alojarse en infraestructura propia, requiere dominio apuntado al servidor y se define por Docker Compose. También incluye una prueba histórica con envíos de 5 MB desde 50 dispositivos a la vez, con respuesta de uno a dos envíos por segundo. El antagonista es la planilla mensual con columnas renombradas. Una cuadrilla escribe Plaza Norte, otra escribe plaza nte, una tercera adjunta una foto con nombre automático. Cuando ambiente o servicios públicos piden priorizar, nadie sabe si son tres lugares o el mismo punto cargado tres veces.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, un administrador diseña el XLSForm con catálogo de sitios, coordenadas, fotos obligatorias y campos de estado. Segundo, carga el formulario en un proyecto de Central. Tercero, inspectores sincronizan ODK Collect, trabajan offline y envían cuando vuelve la conexión. Cuarto, Central recibe submissions con usuario, hora, ubicación, adjuntos y versión de formulario. Quinto, roles separan quién envía, quién revisa, quién exporta y quién administra. Sexto, la API entrega datos a PostGIS, QGIS o tablero. Séptimo, backup y restauración recuperan base y envíos. La guía de submissions en Central define la administración y descarga de envíos según roles. La documentación de Server Audit Logs muestra que Central registra muchas acciones administrativas y permite filtrar por fecha y acción. La guía de API abre la salida para reportes o integración interna. La base PostgreSQL concentra proyectos, formularios, usuarios, envíos y registros de auditoría. Los adjuntos guardan fotos, firmas o archivos. PostGIS puede recibir exportaciones para mapear reclamos o puntos críticos. Si la base falla, se pierde el índice de actas; si el adjunto falla, queda el formulario sin foto; si roles falla, una cuadrilla puede borrar o exportar más datos de los necesarios.
Qué se instala o configura primero
En un proyecto UMSA, el primer entregable sería un piloto con dos formularios, diez sitios reales y tres cuadrillas. Se define catálogo único, rótulos obligatorios, fotos, coordenadas, estado, responsable y fecha de revisión. Después se exporta a PostGIS, se abre en QGIS y se restaura una copia para comprobar que acta, foto y ubicación vuelven juntos. La pila inicial puede usar ODK Central, Docker Compose, PostgreSQL, almacenamiento de adjuntos, proxy con TLS, backup diario, monitoreo y una vista de PostGIS para mapa. Servidor, respaldo y monitoreo pueden ubicarse entre USD 30 y USD 100 mensuales, entre $ 46.050 y $ 153.500 al dólar oficial vendedor de $ 1535. La implementación inicial, con instalación, diseño de formularios, usuarios, exportación, tablero y restauración probada, puede ir de USD 1600 a USD 4000, entre $ 2.456.000 y $ 6.140.000. Ese rango deja afuera teléfonos, planes de datos, relevamiento histórico y dictamen legal sobre conservación documental. El primer entregable verificable es una ruta de salida: formulario enviado desde un celular, foto abierta desde Central, punto visible en mapa y copia restaurada. Para un antecedente cercano de datos geográficos propios, sirve PostGIS en bodegas, fincas, rutas y reclamos con QGIS.
Dónde se rompe y cómo probarlo
El primer riesgo es rótulo duplicado. El síntoma aparece cuando un mismo punto entra con tres nombres. La prueba usa catálogo cerrado y exige identificador único antes de enviar. El segundo riesgo es cola offline olvidada. El síntoma aparece cuando un inspector cree que envió, pero el formulario quedó en el teléfono. La prueba trabaja en modo avión, vuelve a sincronizar y compara cantidad de envíos por usuario. El tercer riesgo es foto demasiado pesada. La prueba carga envíos con adjuntos cercanos a 5 MB, mide tiempo de recepción y revisa que el tablero no espere archivos innecesarios. El cuarto riesgo es backup sin adjuntos. La guía de backup de Central advierte que algunos respaldos directos no incluyen configuraciones de Web Form ni archivos enviados a almacenamiento S3 compatible. La prueba restaura base y archivos, abre un acta vieja y confirma foto, coordenada, usuario y auditoría. La decisión queda visible cuando el área puede contestar dónde está el punto, quién lo cargó, qué foto lo prueba y qué copia lo devuelve.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.