Programas libres para hacer ortofotos
con dron: WebODM y OpenDroneMap

Voló, tiene 400 fotografías en la tarjeta y necesita una ortofoto que se pueda medir. Las plataformas en la nube le cobran por hectárea; las licencias de escritorio, por año. Sin embargo, el motor fotogramétrico que hace ese trabajo puede ser libre, auditable y sin costo de licencia de procesamiento. Eso no significa que todo el entorno sea gratuito: Windows, Docker Desktop y otros componentes tienen condiciones propias.

El problema no es el precio. Es que montarlo la primera vez descarrila a mucha gente en la consola. Este artículo explica qué monta ANTORR ODM 1.0, cómo ponerlo en marcha en Windows y qué exactitud esperar. La instalación incluye un comando de Windows; el resto se guía desde una interfaz. Las cifras de exactitud se presentan con su contexto, porque no existe un valor universal.

Qué es exactamente una ortofoto

Una fotografía aérea normal no sirve para medir: los objetos altos se ven inclinados, la escala cambia del centro al borde y el relieve desplaza cada punto. Una ortofoto es esa imagen corregida geométricamente, de modo que toda ella tiene escala uniforme y coordenadas reales. Sobre una ortofoto se miden distancias y áreas; sobre una foto, no.

Llegar ahí no es «pegar las fotos». El programa detecta puntos comunes entre imágenes, deduce desde dónde se tomó cada una, reconstruye la geometría del terreno en tres dimensiones, la convierte en superficie continua, la viste con las fotos originales y finalmente la mira desde arriba. Esa vista cenital, ya corregida, es la ortofoto. Del mismo proceso salen además la nube de puntos y los modelos de elevación.

Por qué esta instalación tiene varias piezas

La configuración automatizada por ANTORR ODM 1.0 no es un único ejecutable: coordina nueve piezas. El motor fotogramétrico corre en un entorno Linux; a su alrededor hay una base de datos para los proyectos, una cola de trabajos, una interfaz web, un proxy y contenedores. Montarlas a mano exige instalarlas, conectarlas y mantenerlas compatibles.

Esta arquitectura corresponde a ANTORR ODM 1.0; no describe WebODM en general. Desde el 6 de abril de 2026, WebODM y OpenDroneMap son proyectos independientes. El instalador oficial actual de WebODM para Windows es gratuito, está firmado, funciona de forma nativa y no usa Docker; su configuración predeterminada emplea ODX y NodeODX, no ODM y NodeODM. ANTORR ODM 1.0 conserva una ruta distinta, basada en WSL2, Docker, NodeODM y ODM. Compare las dos rutas y sus versiones antes de instalar (WebODM, s.f.-a; WebODM, s.f.-b; Toffanin, 2026).

La solución: un lanzador que lo monta por usted

ANTORR ODM es el lanzador que construimos para nuestro propio equipo y ofrecemos sin costo. Hace una sola cosa: comprueba los prerrequisitos y coordina el arranque de la configuración descrita en este artículo.

Abre una ventana, revisa qué le falta al computador, le dice exactamente dónde descargarlo, y cuando todo está listo arranca las nueve piezas en el orden correcto y abre la interfaz en 127.0.0.1:8080. A partir de ahí usted sube las fotos y descarga la ortofoto.

Eso importa cuando se vuela infraestructura crítica, predios en litigio o proyectos bajo acuerdo de confidencialidad. Aun así, los mapas base, complementos, integraciones en la nube o nodos externos de WebODM pueden comunicarse con terceros si usted los habilita; revise la configuración antes de procesar vuelos sensibles.

La arquitectura de ANTORR ODM 1.0: nueve piezas

Conviene conocerlas, porque cuando algo falla el mensaje de error casi siempre apunta a una de ellas. La Figura 1 muestra cómo se relacionan.

Puesta en marcha y primer GeoTIFF

La Tabla 1 lleva un equipo nuevo hasta la interfaz de WebODM. Son ocho pasos de instalación; el flujo para procesar las imágenes viene justo después.

Tabla 1

Puesta en servicio de un equipo nuevo

Nota. Secuencia según el manual de ANTORR ODM 1.0 (ANTORR Ingeniería, 2026). Windows, WSL2, Docker y Git son productos de terceros con sus propias licencias. Docker Desktop es gratuito para uso personal, educativo, proyectos abiertos no comerciales y pequeñas empresas con menos de 250 empleados y menos de US$10 millones de ingresos anuales. Requiere suscripción para uso profesional si una organización alcanza o supera cualquiera de esos umbrales y para las entidades gubernamentales (Docker, s.f.). Revise siempre los términos vigentes.

A partir de ahí la operación diaria son tres botones —iniciar, detener y herramientas— y una costumbre: saber dónde viven los datos. De las cuatro carpetas que crea, Media se recupera volviendo a subir los originales, Temporal se regenera solo, Diagnosticos es prescindible y BaseDatos no se reconstruye. Esa es la que hay que respaldar.

De las fotografías a la ortofoto

Con el servicio activo, el recorrido habitual es este: cree un proyecto, cargue las fotografías y confirme que conservan sus metadatos de posición. Si dispone de puntos de control, importe el archivo y márquelos en varias imágenes. Si la versión desplegada admite puntos de chequeo, reserve algunos y siga su sintaxis documentada. El WebODM actual reconoce el prefijo CHK-, pero esa función debe comprobarse en el entorno instalado por ANTORR ODM 1.0 (WebODM, s.f.-c).

Después cree la tarea, seleccione el perfil y el sistema de referencia apropiados, inicie el proceso y revise el informe de calidad antes de descargar. Compruebe el número de imágenes calibradas, los errores de reproyección, la distribución del control y los residuos de los puntos de chequeo. Solo entonces descargue la ortofoto como GeoTIFF y verifique su posición en el SIG de entrega. Los nombres de los controles pueden variar entre versiones, pero la secuencia no cambia: entrada, ajuste, control independiente y exportación.

Qué exactitud esperar (y qué dicen los estudios)

Aquí conviene dejar el entusiasmo a un lado. ¿Puede el software libre producir resultados útiles para cartografía y topografía? Sí, pero la exactitud no es una propiedad aislada del programa: también depende del sensor, la geometría y el traslape del vuelo, el terreno, la georreferenciación, los parámetros de proceso y la forma de verificar el resultado.

Conviene distinguir dos términos. Un punto de control terrestre (GCP) entra en el ajuste fotogramétrico y ayuda a georreferenciar el modelo. Un punto de verificación independiente —checkpoint o ChP— se reserva fuera del ajuste y sirve para estimar la exactitud obtenida.

Kostrzewa et al. (2025), en EuroCOW 2025, compararon ODM 3.5.0 con Agisoft Metashape 2.1.3, con énfasis en la orientación y la autocalibración de cámara. Los autores encontraron resultados de calibración comparables entre ambos programas. En los conjuntos Herby procesados con GCP medidos mediante GNSS RTK, sin embargo, el RMS total calculado en los puntos de verificación fue mayor con ODM. La comparación requiere la cautela metodológica indicada bajo la tabla.

Tabla 2

RMS total (3D) en puntos de verificación: ODM frente a Metashape

Nota. Resultados de los conjuntos Herby: el vuelo nadiral empleó 7 GCP y 57 ChP; el oblicuo, 5 GCP y 29 ChP. En Metashape, los ChP se marcaron manualmente en las imágenes y se excluyeron del ajuste. Como ODM 3.5.0 no ofrecía soporte nativo para ChP, los autores midieron X/Y en la ortofoto y Z en la nube de puntos mediante QGIS. Por tanto, la tabla reproduce la comparación del estudio, pero los flujos de verificación no fueron equivalentes y los valores no constituyen una proporción universal de rendimiento entre programas (Kostrzewa et al., 2025, Tabla 8). El WebODM actual acepta puntos de chequeo con el prefijo CHK- (WebODM, s.f.-c).

Pell et al. (2022) obtuvieron un resultado más matizado. Sin GCP y usando la geolocalización GNSS no RTK del dron, WebODM presentó el menor desplazamiento medio en el centro del ortomosaico: 1,86 ± 0,36 m frente al mapa satelital de referencia. En los bordes, en cambio, presentó el mayor desplazamiento: 4,13 ± 0,49 m; Correlator3D obtuvo allí 2,12 ± 0,16 m. Los propios autores advierten que la comparación supone que la imagen satelital representa la posición verdadera, por lo que estos valores describen desplazamiento respecto de esa referencia, no una exactitud topográfica medida en campo.

En sentido contrario, Mora-Félix et al. (2024) evaluaron 600 imágenes de un área de topografía difícil de 630 ha con 27 GCP. En ese caso, Agisoft PhotoScan obtuvo los menores errores —RMSE_XY de 0,514 m y RMSE_Z de 0,162 m—, mientras que ODM produjo deformaciones y un mosaico incompleto. Son resultados de un conjunto de datos y una configuración concretos. En conjunto, los estudios no establecen un ganador universal: muestran que el terreno, el vuelo, la referencia, la versión y los parámetros de proceso pueden cambiar el resultado.

Los estudios sí muestran que la estrategia de control puede cambiar mucho el resultado. En la cantera estudiada por Villanueva y Blanco (2019), el RMSE reportado sobre los propios GCP bajó de 4,11 m con 4 puntos a 0,86 m con 10 puntos bien distribuidos; esa métrica no equivale a una verificación independiente. Oniga et al. (2020), en un área urbana de aproximadamente 1 ha procesada con 3DF Zephyr y evaluada con 150 ChP fijos, observaron una reducción del RMSE de hasta el 50 % al pasar de 4 a 20 GCP, con mejoras menores después. Martínez-Carricondo et al. (2018) encontraron en su sitio de estudio que rodear el perímetro favorecía la planimetría y que una distribución estratificada interior de aproximadamente 0,5 a 1 GCP por hectárea reducía el error altimétrico.

Esas cifras son resultados experimentales, no una receta general. La cantidad y la distribución necesarias dependen del tamaño y la forma del bloque, el GSD, el traslape, el relieve, la precisión con que se midan los puntos y la tolerancia del proyecto. Para evaluar la exactitud, reserve además puntos de verificación medidos en el mismo sistema de referencia y no utilizados en el ajuste.

Un dron RTK puede reducir la cantidad de GCP, pero no elimina la necesidad de verificar. Niu et al. (2024), procesando en Agisoft Metashape una combinación de imágenes nadirales y oblicuas con RTK y sin GCP, obtuvieron sobre 71 ChP un RMSE horizontal de 1,54 cm y un RMSE vertical de 5,58 cm. En el mismo estudio, la configuración nadiral con RTK y sin GCP alcanzó 2,52 cm en horizontal, pero 22,97 cm en Z. Por tanto, los 5,58 cm corresponden únicamente a la componente vertical de una configuración concreta, no al error total ni a cualquier vuelo RTK. Štroner et al. (2021) también documentaron posibles sesgos sistemáticos en altura; en su pequeña área de ensayo, un GCP bastó para corregir el sesgo observado.

Qué equipo hace falta

La fotogrametría densa es, sobre todo, un problema de memoria. La documentación de OpenDroneMap publica la tabla de escalado que conviene leer antes de volar, no después.

Tabla 3

Memoria recomendada según el número de imágenes del lote

Nota. Tomado de la documentación de instalación de OpenDroneMap (s.f.-b), que las presenta como estimaciones conservadoras: influyen el tamaño de las imágenes, la altura de vuelo y los ajustes de procesamiento.

Como punto de partida, ANTORR ODM arranca con 8 GB; 16 GB ofrecen margen para lotes pequeños y 32 GB para lotes mayores. Use al menos 2 núcleos —preferiblemente 4 o más— y reserve 100 GB de disco libre para las imágenes de Docker, la base de datos, las fotografías, los archivos temporales y los resultados. Si falta memoria, reduzca la calidad, divida el lote o amplíe la RAM; la calculadora de abajo traduce la tabla oficial en una estimación para su caso.

Por qué importa que sea libre

«Libre» no significa simplemente «gratis». Las libertades de ejecutar, estudiar, redistribuir y modificar permiten auditar el código, conservar una versión y adaptar el flujo sin depender de una licencia de procesamiento que expire. Eso no garantiza compatibilidad futura ni elimina el mantenimiento: hay que conservar instaladores, versiones, datos y copias de seguridad. Una vez instaladas las dependencias, el cálculo puede ejecutarse sin una plataforma de procesamiento en la nube; los mapas base y algunas integraciones sí pueden requerir Internet.

WebODM, NodeODM y OpenDroneMap publican su código bajo AGPL-3.0; las demás piezas del entorno conservan licencias distintas. La Sección 13 de la AGPL exige ofrecer el código fuente correspondiente a quienes usen por red una versión que usted haya modificado (Free Software Foundation, 2007). Procesar vuelos, cobrar por el levantamiento y entregar una ortofoto no obliga por sí mismo a publicar los datos ni los resultados; el uso interno tampoco equivale normalmente a distribución (Free Software Foundation, s.f.).

Es una lectura de las fuentes citadas, no asesoría legal.

La ventaja práctica es la trazabilidad: la cadena descansa sobre proyectos como OpenSfM, OpenMVS, PDAL y GDAL cuyo código puede inspeccionarse. La licencia abierta facilita esa auditoría; no reemplaza la validación técnica del producto ni la revisión jurídica de un caso particular.

Los límites, dichos en voz alta

La reproducibilidad también exige registrar versiones. Para cada proyecto conserve la versión de ANTORR ODM, los identificadores o digests de las imágenes instaladas, las opciones de proceso y el sistema de referencia. El manual 1.0 identifica PostgreSQL 16/PostGIS 3.5 y Redis 7.2, pero no publica todavía un manifiesto completo de versiones y digests para WebODM, NodeODM, ODM y Nginx. La huella SHA-256 comprueba la integridad del ejecutable descargado; por sí sola no documenta el entorno con el que se produjo la ortofoto.

Lo que hay que recordar

Es posible producir ortofotos con un motor libre y sin pagar una licencia de procesamiento fotogramétrico. El costo total sigue dependiendo del hardware y de los términos de los componentes de terceros. Los estudios revisados muestran que ODM puede producir resultados competitivos en algunos escenarios e inferiores en otros; no existe una equivalencia universal con el software comercial.

El lanzador resuelve la configuración del entorno y pone las herramientas a funcionar. No sustituye el diseño del levantamiento ni la verificación independiente: la exactitud final depende del flujo completo —vuelo, georreferenciación, proceso, control de calidad y entrega—.

Referencias