Metadatos EXIF
EXIF (Exchangeable Image File Format) es el estándar de metadatos incrustado en fotos digitales y fotogramas de video, que captura configuraciones de cámara, ma...
Los metadatos GPS EXIF incorporan coordenadas geográficas (latitud, longitud, altitud), marca de tiempo UTC y datos de dirección directamente en archivos de imagen y video. Es la principal fuente de geolocalización para imágenes de inspección de drones y teléfonos, permitiendo resultados de inspección automatizados basados en mapas. El pipeline de análisis de TarmacView extrae el GPS EXIF cuando está disponible para colocar cada foto en un mapa de inspección aeródromica.
Los datos GPS EXIF son el mecanismo estandarizado mediante el cual la información de ubicación geográfica se incorpora en archivos de imagen y video digitales. Definido por la Asociación de Industrias de Tecnología de la Información y Electrónica de Japón (JEITA) y mantenido por la Asociación de Productos de Cámaras e Imágenes (CIPA) bajo el estándar CIPA DC-008 (Traducción del JEITA CP-3451), la especificación EXIF reserva un subdirectorio dedicado llamado Marco de Información GPS (GPS IFD) para almacenar datos de posicionamiento satelital. Este subdirectorio es referenciado por el Directorio de Archivos de Imagen (IFD) principal de EXIF a través de la etiqueta 0x8825 (Exif.Image.GPSTag), que contiene un puntero al inicio del GPS IFD dentro del archivo. Todos los lectores EXIF compatibles, desde los diálogos de propiedades de archivo del sistema operativo hasta el software profesional de fotogrametría, localizan los datos geográficos siguiendo este puntero.
El GPS IFD contiene hasta 31 etiquetas estandarizadas (entradas 0x0000 a 0x001f), cada una con un componente específico del registro de geolocalización. Estas etiquetas abarcan identificación de versión, referencias de hemisferio, tripletes de coordenadas, valores de altitud, marcas de tiempo UTC, identificadores de satélite, indicadores de estado del receptor, dimensionalidad de la medición, métricas de dilución de precisión, datos de velocidad y rumbo, dirección de la imagen, especificación del datum geodésico, datos del punto de destino, metadatos del método de posicionamiento, estado de corrección diferencial y estimaciones de error horizontal. En la práctica, los fabricantes de cámaras y teléfonos inteligentes deciden qué subconjunto de estas etiquetas completar. Los teléfonos inteligentes de consumo generalmente escriben latitud, longitud, altitud, marca de tiempo y datum del mapa. Los fabricantes de drones como DJI, Autel y Skydio a menudo escriben etiquetas adicionales que incluyen estado GPS, modo de medición, dilución de precisión (DOP), velocidad, rumbo y dirección de la imagen. La presencia o ausencia de etiquetas GPS específicas puede servir como un indicador de diagnóstico del tipo de dispositivo de captura y la calidad de la fijación satelital en el momento de la exposición. Por ejemplo, la presencia simultánea de GPSStatus = A (Activo), GPSMeasureMode = 3 (Tridimensional), GPSDOP por debajo de 4 y GPSHPositioningError por debajo de 5 metros indica colectivamente una fijación GPS de alta calidad adecuada para aplicaciones de nivel cartográfico.

El GPS IFD está organizado como una colección secuencial de campos de datos de 2 bytes, 4 bytes y longitud variable siguiendo la estructura estándar TIFF IFD. Cada entrada de etiqueta en el GPS IFD consta de cuatro componentes: el identificador de etiqueta (2 bytes, valor hexadecimal), el tipo de dato (2 bytes, que indica si el valor es un byte sin signo, cadena ASCII, fracción racional sin signo, entero corto con signo u otro tipo definido por EXIF), el conteo (4 bytes, que representa el número de valores de datos) y el desplazamiento del valor (4 bytes, ya sea el valor en sí si cabe en 4 bytes, o un puntero a los datos en otra parte del archivo si supera los 4 bytes). Los valores de identificador de etiqueta para datos GPS van desde 0x0000 (GPSVersionID) hasta 0x001f (GPSHPositioningError). Cada entrada de etiqueta ocupa exactamente 12 bytes en el IFD, seguida por la siguiente entrada de etiqueta, hasta que un terminador de 4 bytes (valor cero) señala el final del IFD. La siguiente tabla detalla las etiquetas GPS más comunes y sus especificaciones según lo definido por los estándares EXIF 2.3 y posteriores:
| Hex | Dec | Nombre de Etiqueta | Tipo | Descripción |
|---|---|---|---|---|
| 0x0000 | 0 | GPSVersionID | BYTE[4] sin signo | Identificador de versión para el GPS IFD, típicamente 2 3 0 0 para EXIF 2.3 |
| 0x0001 | 1 | GPSLatitudeRef | ASCII[2] | Hemisferio de latitud: N (Norte) o S (Sur) |
| 0x0002 | 2 | GPSLatitude | RATIONAL[3] | Latitud como tres números racionales sin signo: grados, minutos, segundos |
| 0x0003 | 3 | GPSLongitudeRef | ASCII[2] | Hemisferio de longitud: E (Este) o W (Oeste) |
| 0x0004 | 4 | GPSLongitude | RATIONAL[3] | Longitud como tres números racionales sin signo: grados, minutos, segundos |
| 0x0005 | 5 | GPSAltitudeRef | BYTE | Referencia de altitud: 0 = Sobre el Nivel del Mar, 1 = Bajo el Nivel del Mar |
| 0x0006 | 6 | GPSAltitude | RATIONAL | Valor de altitud en metros como un solo racional sin signo |
| 0x0007 | 7 | GPSTimeStamp | RATIONAL[3] | Hora UTC de la fijación GPS: horas, minutos, segundos (cada uno como racional) |
| 0x0008 | 8 | GPSSatellites | ASCII | Identificadores de satélite utilizados para la fijación (ej. "08", "05,12,23") |
| 0x0009 | 9 | GPSStatus | ASCII[2] | Estado del receptor: A = Activo (medición en curso), V = Vacío |
| 0x000a | 10 | GPSMeasureMode | ASCII[2] | Dimensión de fijación: 2 = Bidimensional, 3 = Tridimensional |
| 0x000b | 11 | GPSDOP | RATIONAL | Dilución de Precisión — métrica cuantitativa de calidad GPS |
| 0x000c | 12 | GPSSpeedRef | ASCII[2] | Unidad de velocidad: K = km/h, M = mph, N = nudos |
| 0x000d | 13 | GPSSpeed | RATIONAL | Velocidad del movimiento del receptor GPS |
| 0x000e | 14 | GPSTrackRef | ASCII[2] | Referencia de rumbo: M = Norte Magnético, T = Norte Verdadero |
| 0x000f | 15 | GPSTrack | RATIONAL | Dirección del movimiento en grados desde el norte |
| 0x0010 | 16 | GPSImgDirectionRef | ASCII[2] | Referencia de dirección de imagen: M = Magnética, T = Verdadera |
| 0x0011 | 17 | GPSImgDirection | RATIONAL | Dirección hacia donde apuntó la cámara (grados desde el norte) |
| 0x0012 | 18 | GPSMapDatum | ASCII | Nombre del datum del levantamiento geodésico, típicamente "WGS-84" |
| 0x0013–0x001a | 19–26 | GPSDest* | Varios | Etiquetas de punto de destino (latitud, longitud, rumbo, distancia) |
| 0x001b | 27 | GPSProcessingMethod | UNDEFINED | Método de posicionamiento: "GPS", "CELLID", "WLAN", "MANUAL" |
| 0x001d | 29 | GPSDateStamp | ASCII[11] | Fecha UTC de la fijación GPS en formato YYYY:MM:DD |
| 0x001e | 30 | GPSDifferential | SHORT | Estado de corrección diferencial: 0 = ninguna, 1 = diferencial aplicada |
| 0x001f | 31 | GPSHPositioningError | RATIONAL | Error de posicionamiento horizontal en metros |
La etiqueta GPSVersionID (0x0000) siempre aparece como la primera entrada en el GPS IFD y sirve como verificación de consistencia para los analizadores. Contiene cuatro valores de byte sin signo: los dos primeros indican la versión mayor y menor del estándar, el tercero indica la revisión y el cuarto está reservado. Para EXIF 2.3 (la versión más implementada a partir de 2025), el valor es 2, 3, 0, 0. EXIF 3.0, publicado por CIPA en 2023, actualiza esto a 3, 0, 0, 0 y agrega soporte para GNSS multiconstelación (GPS, GLONASS, Galileo, BeiDou, QZSS, NAVIC) en la etiqueta GPSProcessingMethod. La etiqueta GPSProcessingMethod (0x001b) utiliza un formato de datos indefinido estructurado: un prefijo de conteo de bytes seguido de una cadena ASCII que enumera la tecnología de posicionamiento. EXIF 3.0 define explícitamente los valores "QZSS", "GALILEO", "GLONASS", "BEIDOU" y "NAVIC" junto con las opciones heredadas "GPS", "CELLID", "WLAN" y "MANUAL", reflejando la proliferación de receptores multiconstelación en dispositivos modernos. Un teléfono inteligente que utiliza Galileo para el posicionamiento almacenaría "GALILEO" en esta etiqueta, mientras que un dron que utiliza GPS+GLONASS combinado podría almacenar "GPS,GLONASS" o una concatenación equivalente.
La etiqueta GPSHPositioningError (0x001f) es una de las adiciones más útiles en la práctica al estándar GPS EXIF. Agregada en EXIF 2.31 (2016), esta etiqueta almacena el error de posicionamiento horizontal estimado en metros como un número racional sin signo. Cuando el dispositivo de captura la completa, proporciona una métrica de confianza cuantitativa: un valor de 5.0 indica que se espera que la posición verdadera se encuentre dentro de un radio de 5 metros de las coordenadas registradas aproximadamente el 95% del tiempo (asumiendo errores distribuidos normalmente). Los teléfonos inteligentes con Android 8.0+ y iOS 12+ escriben esta etiqueta cuando los servicios de ubicación están activos. Los drones DJI la completan a partir de la precisión posicional estimada del receptor GNSS transmitida en la oración NMEA GST (Errores de Pseudodistancia GNSS). El pipeline de análisis de TarmacView lee esta etiqueta para evaluar la fiabilidad de la geolocalización por foto y puede marcar imágenes con valores de error que excedan un umbral configurable (típicamente 10 metros para trabajos de inspección aeródromica, aunque este umbral puede ajustarse a 3 metros para misiones basadas en RTK).
La etiqueta GPSDOP (0x000b) almacena la Dilución de Precisión, una métrica sin unidades que cuantifica la calidad geométrica de la constelación de satélites. Los valores de DOP por debajo de 2 indican una geometría excelente; 2–4 es buena; 4–6 es moderada; 6–8 es pobre; los valores superiores a 8 no son fiables. El valor DOP se multiplica por el Error de Rango Equivalente de Usuario (UERE — típicamente 2–4 metros para GPS de consumo) para estimar el error total de posición. Un PDOP de 3 con un UERE de 3 metros produce un error 3D esperado de aproximadamente 9 metros. La etiqueta GPSSatellites (0x0008) registra los identificadores PRN (Ruido Pseudoaleatorio) de los satélites utilizados en la solución de posición, almacenados como una cadena ASCII como "05,12,23,29" para los satélites 5, 12, 23 y 29. El requisito mínimo para una fijación 3D es de cuatro satélites, pero 7–12 satélites son típicos en condiciones de cielo abierto. Menos de 4 satélites fuerzan una fijación 2D (GPSMeasureMode = 2), que asume una altitud fija e introduce un error horizontal adicional.
Las coordenadas geográficas principales en el GPS EXIF se almacenan utilizando un sistema de números racionales de tres partes que preserva la notación tradicional de grados-minutos-segundos (DMS). Cada componente de coordenada — GPSLatitude (etiqueta 0x0002) y GPSLongitude (etiqueta 0x0004) — es un arreglo de tres valores RATIONAL (racionales) sin signo. Un RATIONAL en EXIF es un par de enteros sin signo de 32 bits que representan un numerador y un denominador, permitiendo precisión fraccionaria. Los tres elementos del arreglo corresponden a grados (primer elemento), minutos (segundo elemento) y segundos (tercer elemento). Debido a que los valores no tienen signo, el signo (hemisferio) se registra en etiquetas complementarias separadas: GPSLatitudeRef (0x0001) que contiene N o S, y GPSLongitudeRef (0x0003) que contiene E o W. Las etiquetas GPSLatitudeRef y GPSLongitudeRef son cadenas ASCII de exactamente 2 caracteres, típicamente "N" o "S" para latitud y "E" o "W" para longitud, aunque el estándar EXIF permite relleno a 2 caracteres (ej., "N " con un espacio final).
Un ejemplo concreto ilustra el formato de almacenamiento. Una foto tomada en la latitud 40° 45’ 30.00" Norte y longitud 73° 59’ 15.00" Oeste almacenaría los siguientes valores en el GPS IFD:
| Etiqueta | Valor Bruto (numerador/denominador) | Valor Calculado |
|---|---|---|
| GPSLatitudeRef | "N" | Norte |
| GPSLatitude[0] (grados) | 40/1 | 40 grados |
| GPSLatitude[1] (minutos) | 45/1 | 45 minutos |
| GPSLatitude[2] (segundos) | 3000/100 | 30.00 segundos |
| GPSLongitudeRef | "W" | Oeste |
| GPSLongitude[0] (grados) | 73/1 | 73 grados |
| GPSLongitude[1] (minutos) | 59/1 | 59 minutos |
| GPSLongitude[2] (segundos) | 1500/100 | 15.00 segundos |
La conversión de la representación DMS de EXIF a grados decimales utiliza la fórmula: Grados Decimales = Grados + (Minutos / 60) + (Segundos / 3600). Para el ejemplo anterior: 40 + (45/60) + (30.00/3600) = 40.75833°N. La referencia de hemisferio determina el signo algebraico: Norte y Este son positivos (40.75833), mientras que Sur y Oeste son negativos (−73.98750). La mayoría de las bases de datos geoespaciales, APIs de mapas (Google Maps, OpenStreetMap, Mapbox) y software SIG (QGIS, ArcGIS) esperan grados decimales con valores con signo donde las latitudes negativas son Sur y las longitudes negativas son Oeste — el estándar del sistema de referencia de coordenadas EPSG:4326. La conversión completa para el ejemplo es: decimal = 40 + 0.75 + 0.00833 = 40.75833°N para latitud, y 73 + 0.98333 + 0.00417 = 73.98750°W para longitud. Con la convención de signos aplicada, estos se convierten en +40.75833, −73.98750.
El estándar EXIF no exige una resolución específica para las fracciones racionales, lo que puede llevar a una precisión variable entre dispositivos. Un teléfono inteligente puede almacenar segundos como 3000/100 (30.00 segundos, lo que implica una precisión de ~0.3 metros en el ecuador), mientras que una cámara de dron de nivel topográfico podría almacenar 300000/10000 (30.0000 segundos, lo que implica una precisión de ~0.03 metros). Sin embargo, la precisión real del GPS del dispositivo típicamente limita la resolución significativa independientemente de la precisión almacenada. Algunas cámaras de consumo almacenan minutos y segundos con un denominador de 1 (solo valores enteros), truncando efectivamente la precisión de subsegundos e introduciendo errores de posición de varios metros. Los analizadores deben manejar valores racionales que no se resuelven en enteros exactos calculando el equivalente de punto flotante a partir del par numerador/denominador. Al convertir, el analizador también debe manejar el caso límite donde el denominador es cero (una etiqueta malformada) tratando el valor como cero y señalando el problema de calidad de datos.
La altitud se almacena en el GPS IFD utilizando dos etiquetas emparejadas: GPSAltitudeRef (0x0005) y GPSAltitude (0x0006). La etiqueta de referencia es un solo byte sin signo con dos valores definidos: 0 indica que la altitud está referenciada al nivel medio del mar (MSL), y 1 indica que la altitud está referenciada al lecho marino (bajo el nivel del mar). En la práctica, prácticamente todos los dispositivos de consumo y drones escriben 0, indicando referencia MSL. El valor de altitud en sí se almacena como un solo RATIONAL (racional sin signo) en metros. Un valor de 12345/100 representa 123.45 metros sobre el nivel del mar. Algunos drones y cámaras pueden escribir la altitud en pies en lugar de metros, aunque el estándar EXIF requiere metros — esta inconsistencia de unidades debe ser detectada por el analizador mediante análisis heurístico (si las altitudes superan los 1,000 metros en áreas de baja elevación, es probable que el valor esté en pies y deba convertirse dividiendo por 3.28084).
La relación entre la altitud reportada por GPS y la altura real de la cámara sobre el nivel del suelo (AGL) es compleja y requiere una interpretación cuidadosa. Los receptores GPS calculan la altitud utilizando el modelo de elipsoide WGS84, que aproxima la Tierra como un esferoide oblato con semieje mayor a = 6,378,137.0 metros y aplanamiento f = 1/298.257223563. La altura elipsoidal reportada por el GPS es la distancia desde la superficie del elipsoide WGS84 hasta el receptor, no la distancia desde el nivel medio del mar. El nivel medio del mar real (el geoide) se desvía del elipsoide WGS84 hasta ±100 metros en diferentes partes del mundo debido a variaciones en el campo gravitacional de la Tierra. La ondulación del geoide en una ubicación específica se puede obtener de los modelos geopotenciales EGM96 (Modelo Gravitational de la Tierra 1996), EGM2008 o EGM2020. Para convertir de altura elipsoidal GPS a altura ortométrica (altura sobre el nivel medio del mar), se debe aplicar una corrección geoidal utilizando la fórmula: Altura Ortométrica (MSL) ≈ Altura Elipsoidal − Ondulación del Geoide. Por ejemplo, en una ubicación en el Atlántico Norte donde la ondulación del geoide es de −25 metros, una altura elipsoidal reportada por GPS de 100 metros corresponde a una altura ortométrica de aproximadamente 125 metros sobre el MSL.
La mayoría de los fabricantes de cámaras y teléfonos inteligentes no aplican esta corrección geoidal antes de escribir la etiqueta GPSAltitude. En su lugar, escriben la altura elipsoidal bruta del receptor GNSS. Esto significa que la altitud almacenada en EXIF puede diferir de la altitud MSL real en varias decenas de metros dependiendo de la ubicación geográfica. Los drones DJI son una excepción notable: escriben la altitud relativa (altura sobre el punto de despegue) en campos de metadatos XMP propietarios (drone-dji:RelativeAltitude) mientras que el campo estándar GPSAltitude de EXIF contiene la altura elipsoidal del receptor GNSS del controlador de vuelo. La altitud relativa, derivada del sensor barométrico fusionado con sensores ultrasónicos o infrarrojos orientados hacia abajo, es mucho más precisa para la determinación de AGL (típicamente ±0.1–0.5 metros) en comparación con la altitud elipsoidal GPS (típicamente ±5–15 metros). El software de fotogrametría como Agisoft Metashape y Pix4Dmapper tiene en cuenta estas diferencias aplicando su propio modelo geoidal durante el procesamiento, utilizando típicamente EGM96 por defecto a menos que el usuario especifique un geoide alternativo.
La precisión de la altitud GPS es significativamente peor que la precisión horizontal en la mayoría de las condiciones. Los receptores GPS de consumo típicos alcanzan una precisión horizontal de 3 a 5 metros, pero una precisión vertical de 5 a 15 metros (95% de confianza) debido al efecto de dilución geométrica de la precisión (GDOP) — los satélites están agrupados en el hemisferio celeste y proporcionan una geometría de triangulación vertical más pobre que la horizontal. El componente vertical del DOP (VDOP) es típicamente 1.5–2.5 veces mayor que el componente horizontal (HDOP) para la misma constelación de satélites. Los drones equipados con RTK reducen esto a 3–5 centímetros verticales, aún peor que la precisión horizontal RTK de 1–2 centímetros. Los altímetros barométricos, presentes en la mayoría de los drones DJI y muchos teléfonos inteligentes, pueden compensar parcialmente fusionando lecturas de presión barométrica con datos de altitud GPS a través de un filtro Kalman, mejorando la precisión vertical a corto plazo a aproximadamente 1–2 metros. Sin embargo, la altitud barométrica se desvía con los cambios de presión meteorológica (aproximadamente 1 metro por cada 0.12 hPa de cambio de presión) y requiere recalibración periódica contra el GPS. Para aplicaciones de inspección aeródromica, la altitud AGL es típicamente más relevante que la altitud MSL, ya que la distancia entre la cámara y la superficie del pavimento afecta directamente la resolución de píxeles y la precisión del dimensionamiento de defectos. TarmacView convierte GPSAltitude a AGL restando la elevación del terreno local obtenida de un Modelo Digital de Elevación (DEM) o de los datos de elevación de pista topografiados del aeródromo publicados en el AIP de la OACI.
El componente temporal de la fijación GPS se registra en dos etiquetas: GPSTimeStamp (0x0007) y GPSDateStamp (0x001d). La etiqueta de tiempo almacena la Hora Universal Coordinada (UTC) como tres valores RATIONAL: horas, minutos y segundos. La etiqueta de fecha almacena la fecha del calendario como una cadena ASCII de 11 caracteres en el formato YYYY:MM:DD (ej., "2025:11:18"). Debido a que el carácter de dos puntos es un separador de fecha EXIF estándar, la marca de tiempo UTC combinada se lee naturalmente como 2025:11:18 14:30:15 para las 2:30:15 PM UTC del 18 de noviembre de 2025. La especificación EXIF requiere explícitamente que ambas etiquetas se registren en UTC, derivadas directamente de los relojes atómicos de los satélites GPS que están referenciados a la Hora Universal Coordinada (UTC) con correcciones de segundos intercalares aplicadas por el segmento de control terrestre GPS. El tiempo GPS en sí no es exactamente UTC — el tiempo GPS no incluye segundos intercalares y actualmente (a partir de 2025) está 18 segundos adelantado respecto al UTC. El receptor GPS maneja esta conversión internamente, escribiendo UTC en las etiquetas EXIF.
La separación de la fecha y la hora en dos etiquetas distintas con diferentes tipos de datos (cadena ASCII frente a arreglo RATIONAL) es un artefacto histórico del diseño de EXIF. La mayoría de las bibliotecas y herramientas de software sintetizan una etiqueta GPSDateTime combinada por conveniencia — ExifTool crea esta etiqueta compuesta automáticamente, mientras que bibliotecas de Python como Pillow y exifread requieren concatenación manual. Al leer datos GPS programáticamente, el desarrollador debe ensamblar la cadena de fecha y los racionales de tiempo en un solo objeto datetime. Los valores racionales para horas, minutos y segundos pueden ser fraccionarios: una foto tomada a las 14 horas, 30 minutos y 15.5 segundos UTC almacenaría 14/1, 30/1, 155/10. Los segundos fraccionarios pueden representar precisión de sub-milisegundos cuando el receptor GPS opera a una tasa de actualización de 10 Hz (100 ms entre muestras), aunque la mayoría de los receptores de consumo limitan la salida a una resolución de 0.1 segundos en las oraciones NMEA RMC.
Una limitación crítica de la marca de tiempo GPS EXIF es que registra el momento de la fijación GPS, que puede no coincidir exactamente con el momento en que se liberó el obturador. Los pipelines de firmware de la cámara implican una secuencia: adquirir bloqueo GPS, calcular posición, esperar el disparador del obturador, capturar imagen, escribir EXIF. La marca de tiempo GPS escrita es la hora de la última fijación de posición válida, que podría tener desde varios cientos de milisegundos hasta varios segundos de antigüedad dependiendo de la tasa de actualización del GPS (típicamente 1 Hz para dispositivos de consumo, 5–10 Hz para controladores de vuelo de drones). Este desplazamiento temporal generalmente es insignificante para aplicaciones de mapeo, pero puede volverse significativo en escenarios de inspección de alta velocidad donde la plataforma de la cámara se mueve a 10–15 m/s (36–54 km/h). A 15 m/s, un retraso de actualización GPS de 1 segundo introduce un error de posición de 15 metros a lo largo de la trayectoria. Para sistemas RTK con tasas de actualización de 5–10 Hz y latencia de 100–200 ms, el error a lo largo de la trayectoria se reduce a 1.5–3 metros a la misma velocidad. TarmacView compensa esta latencia cotejando la marca de tiempo de captura de la imagen (EXIF DateTimeOriginal, etiqueta 0x9003) con el flujo de telemetría e interpolando la posición GPS en el momento exacto de liberación del obturador utilizando interpolación hacia adelante/atrás entre waypoints de telemetría adyacentes.
La marca de tiempo GPS también cumple una función forense crítica: permite el cotejo entre los datos EXIF de la imagen y fuentes de telemetría externas. Cuando el GPS EXIF falta en una imagen (ej., cuando los archivos RAW carecen de GPS incorporado porque el fabricante almacena la ubicación en un archivo XMP secundario), la marca de tiempo se puede utilizar para interpolar la posición de la cámara a partir de un registro de ruta GPS grabado por un dispositivo separado. Este es el principio detrás del geocodificación post-hoc: un registrador GPS graba posiciones con marca de tiempo, y el software compara el tiempo de captura de cada foto con las marcas de tiempo del registrador más cercanas para asignar coordenadas. El algoritmo de coincidencia típicamente utiliza una búsqueda del vecino más cercano con un umbral máximo de delta de tiempo (ej., 2 segundos). Si múltiples waypoints de telemetría caen dentro del umbral, la interpolación bilineal entre las dos marcas de tiempo más cercanas produce una precisión de posición de subsegundo. TarmacView implementa este mecanismo de respaldo cuando el GPS EXIF está ausente, siempre que se pueda establecer una fuente de tiempo sincronizada entre la cámara y el registrador GPS, verificada comparando el desplazamiento de EXIF DateTimeOriginal contra la referencia de tiempo GPS.

La etiqueta GPSMapDatum (0x0012) registra el datum geodésico — el sistema de referencia de coordenadas — utilizado para el cálculo de la posición GPS. La especificación EXIF exige que esta etiqueta contenga la cadena ASCII "WGS-84" (Sistema Geodésico Mundial 1984) cuando el receptor GPS utiliza el datum GPS estándar. En prácticamente todas las cámaras de consumo, teléfonos inteligentes y drones, el valor es exactamente "WGS-84" porque el Sistema de Posicionamiento Global está inherentemente referenciado a este datum. Los satélites GPS transmiten datos de efemérides en coordenadas WGS84, y todos los receptores GNSS de grado de consumo calculan posiciones en WGS84 por defecto. Sin embargo, el formato de la etiqueta permite cualquier cadena ASCII, y algunos dispositivos escriben variaciones: "WGS84" (sin guión), "WGS 84" (con espacio) o "WGS-1984". Cada una de estas variantes debe ser tratada como equivalente a WGS84 por el analizador, aunque una validación estricta contra la cadena de especificación puede marcarlas como no estándar.
WGS84 es un sistema de coordenadas centrado en la Tierra y fijo a la Tierra (ECEF) mantenido por la Agencia Nacional de Inteligencia Geoespacial (NGA) de los Estados Unidos. Define tres componentes: un elipsoide de referencia (semieje mayor a = 6,378,137.0 metros, aplanamiento f = 1/298.257223563), un modelo gravitacional (EGM96) y un conjunto de parámetros de transformación que lo vinculan al Marco de Referencia Terrestre Internacional (ITRF). La realización actual es WGS84(G2296), actualizada en 2024, que se alinea con ITRF2020 dentro de 1 centímetro. Este nivel de refinamiento es irrelevante para el GPS de consumo (que tiene precisión a nivel de metros) pero importa para sistemas RTK y cinemáticos post-procesados (PPK) que operan con precisión centimétrica. Las realizaciones de WGS84 han evolucionado a través de G730 (1994), G873 (1997), G1150 (2001), G1674 (2012), G1762 (2013), G2139 (2021) y G2296 (2024), con cada realización sucesiva mejorando la alineación con el ITRF. Para aplicaciones de mapeo de precisión, se debe considerar la fecha de realización: los datos recopilados con un sistema RTK en 2025 utilizando la realización G2296 son más consistentes con las redes modernas de control topográfico que los datos recopilados con un receptor de la era G1150.
La diferencia entre WGS84 y otros datums puede ser sustancial. Los datums locales como el Sistema de Referencia Terrestre Europeo 1989 (ETRS89), el Datum Norteamericano 1983 (NAD83) y el Datum Geocéntrico de Australia 2020 (GDA2020) difieren de WGS84 hasta varios metros en ciertas regiones. Los datums locales más antiguos como el Ordnance Survey Gran Bretaña 1936 (OSGB36) o el Datum de Tokio difieren en cientos de metros. Cuando las coordenadas GPS EXIF se utilizan en un sistema SIG configurado para un datum diferente, las posiciones mapeadas se desplazarán sistemáticamente a menos que se aplique una transformación de datum. Los parámetros de transformación comunes incluyen transformaciones de Helmert de tres parámetros (delta X, delta Y, delta Z) o de siete parámetros (delta X, delta Y, delta Z, más tres ángulos de rotación y un factor de escala). La biblioteca PROJ (proj4) proporciona estas transformaciones para miles de pares de datums. La etiqueta GPSMapDatum proporciona la información necesaria para aplicar la transformación correcta, aunque en la práctica la mayoría de los pipelines de procesamiento de imágenes asumen WGS84 y proceden sin verificar el valor de la etiqueta. TarmacView valida la cadena del datum y alerta al usuario si se detecta un datum no WGS84, ofreciendo la reproyección automática al sistema de referencia de coordenadas objetivo.
Para aplicaciones de inspección aeródromica, la consistencia del datum es esencial. El Anexo 14 de la OACI, Volumen I (Diseño y Operaciones de Aeródromos) especifica que los puntos de referencia del aeródromo (ARP) y los umbrales de pista deben estar referenciados al datum del Sistema Geodésico Mundial 1984 (WGS84). El Documento 9674 de la OACI, el Manual del Sistema Geodésico Mundial — 1984 (WGS-84), proporciona los estándares de implementación para WGS84 en aviación, incluyendo la precisión requerida para los datos topográficos del aeródromo. El manual especifica que las coordenadas topográficas del aeródromo deben ser precisas dentro de 1 metro horizontalmente y 0.5 metros verticalmente para pistas de aproximación de precisión (Categoría II/III), y dentro de 5 metros horizontalmente para pistas sin precisión. Estos requisitos de precisión informan directamente la calidad GPS aceptable para fotos de inspección: se requiere posicionamiento RTK o PPK para inspecciones de aeródromos de Categoría II/III, mientras que el GPS de drones de consumo puede ser suficiente para aeródromos sin precisión donde los requisitos de precisión de posición absoluta son menos estrictos. TarmacView asegura que todas las coordenadas GPS EXIF extraídas de las fotos de inspección se interpreten en el datum WGS84 y puede opcionalmente reproyectar a sistemas de referencia de coordenadas locales (ej., zonas UTM) para mediciones basadas en área como el mapeo de polígonos de deterioro del pavimento.
La extracción de metadatos GPS de archivos de imagen es un proceso bien establecido compatible con numerosas herramientas de software y bibliotecas de programación. La herramienta más completa es ExifTool de Phil Harvey, una aplicación de línea de comandos basada en Perl que lee y escribe metadatos EXIF, GPS, IPTC, XMP y específicos del fabricante de prácticamente todos los formatos de imagen existentes. ExifTool puede extraer datos GPS de un solo archivo o procesar por lotes miles de imágenes, generando resultados en varios formatos, incluidos texto plano, CSV, JSON, XML y XMP. Un comando de extracción típico para fotos de inspección con drones es exiftool -filename -gpslatitude -gpslongitude -gpsaltitude -gpsdatetime -gpsimgdirection -gpshpansionerror -csv /ruta/a/imagenes/. La bandera -csv produce una salida separada por comas que se puede importar a software SIG, paneles de mapeo o la plataforma de inspección de TarmacView para el posicionamiento automatizado de fotos. ExifTool maneja la conversión DMS a decimal automáticamente cuando se usa la bandera -n (ej., -gpslatitude# -n genera la latitud como un valor decimal con signo listo para la inserción en bases de datos geoespaciales).
Para desarrolladores de Python, varias bibliotecas proporcionan capacidades de extracción de GPS EXIF. La biblioteca Pillow (fork de PIL) ofrece el método _getexif() en objetos de imagen, devolviendo un diccionario de identificadores de etiqueta asignados a valores. Sin embargo, Pillow no convierte automáticamente el formato racional DMS a grados decimales — los desarrolladores deben implementar la fórmula de conversión manualmente utilizando el diccionario de mapeo GPSTAGS proporcionado por la biblioteca. La biblioteca exifread proporciona un analizador más robusto que maneja casos límite (etiquetas faltantes, valores malformados, problemas de endianness) mejor que Pillow. La biblioteca pyexif envuelve la funcionalidad de ExifTool para entornos Python. Para flujos de trabajo geoespaciales, la biblioteca rasterio puede leer metadatos GPS de archivos ráster georreferenciados, aunque típicamente espera que los datos ya estén en un formato SIG estándar en lugar de EXIF sin procesar.
| Herramienta / Biblioteca | Lenguaje | Fortalezas | Limitaciones |
|---|---|---|---|
| ExifTool | Perl (independiente) | Más completo, procesamiento por lotes, todos los formatos | Solo línea de comandos, requiere instalación |
| Pillow (fork PIL) | Python | Integrado, sin dependencias | Sin conversión DMS automática, manejo limitado de casos límite |
| exifread | Python | Mejor manejo de errores, acceso a etiquetas sin procesar | Más lento que Pillow para lotes grandes |
| GEXIF | C++ | Rendimiento nativo rápido | Enfocado en Linux, documentación limitada |
| Exiv2 | C++ | Multiplataforma, API de biblioteca | Requiere compilación, API más compleja |
| mdextractor | SDK Móvil | Extracción en dispositivo para iOS/Android | Específico de plataforma, limitado a aplicaciones móviles |
El proceso de extracción varía según el formato de imagen. Los archivos JPEG almacenan EXIF en el marcador APP1 (Segmento de Aplicación 1) inmediatamente después del marcador SOI (Inicio de Imagen) en el desplazamiento 0xFFE1. Los archivos TIFF incorporan EXIF en la primera estructura IFD. Los formatos RAW (CR2, NEF, ARW, DNG) almacenan EXIF en un contenedor similar a TIFF en un desplazamiento conocido del encabezado del archivo. Los archivos HEIC/HEIF (formato predeterminado de Apple desde iOS 11) incorporan EXIF en un cuadro mime dentro del contenedor de Formato de Archivo Base de Medios ISO, específicamente en la jerarquía de cuadros moov > meta > ilst. Las imágenes WebP almacenan EXIF en el chunk EXIF que sigue a los datos VP8/VP8L. En todos los casos, el GPS IFD se localiza siguiendo punteros desde el IFD EXIF principal a través de la etiqueta 0x8825, luego leyendo el sub-IFD GPS secuencialmente. Cada formato requiere cálculos específicos de desplazamiento de bytes: los marcadores JPEG APP1 deben localizarse escaneando el marcador de byte 0xFFE1; HEIC requiere analizar la jerarquía de cuadros ISOBMFF; los formatos RAW requieren desplazamientos específicos del fabricante que varían entre Canon CR2, Nikon NEF, Sony ARW y Adobe DNG. El pipeline de procesamiento de imágenes de TarmacView implementa lectores específicos de formato que manejan todos los formatos de imagen comunes producidos por cámaras de inspección y drones, recurriendo a ExifTool como analizador universal cuando el análisis nativo falla debido a una variante de formato o un encabezado corrupto.
La precisión posicional de los datos GPS EXIF varía en tres órdenes de magnitud dependiendo del dispositivo de captura y las capacidades de su receptor GNSS. Comprender estos niveles de precisión es esencial para determinar el caso de uso de inspección apropiado y para establecer expectativas realistas sobre la precisión de localización de defectos en informes de inspección basados en mapas.
Teléfonos inteligentes de consumo (iPhone, Samsung Galaxy, Google Pixel) utilizan receptores GNSS multiconstelación compatibles con GPS, GLONASS, Galileo y BeiDou. Los modelos emblemáticos desde 2020 utilizan receptores de frecuencia dual (L1 + L5 para GPS, E1 + E5a para Galileo), que cancelan los errores de retardo ionosférico al comparar los tiempos de llegada de la señal en dos frecuencias diferentes. El retardo ionosférico es proporcional a 1/f², por lo que comparar L1 (1575.42 MHz) y L5 (1176.45 MHz) permite al receptor calcular y eliminar el retardo. La precisión típica en condiciones de cielo abierto es de 3 a 5 metros horizontal (95% de confianza). Los cañones urbanos reducen esto a 5–15 metros debido a reflexiones multitrayecto en edificios. La precisión del GPS del teléfono inteligente se degrada significativamente cerca de estructuras metálicas, líneas eléctricas y follaje denso. El GPS integrado es adecuado para la organización general de fotos y el mapeo aproximado, pero insuficiente para la localización precisa de defectos en una superficie de pavimento de aeródromo donde un error de 3 metros podría colocar una grieta en el lado equivocado de la línea central de una pista. Los teléfonos inteligentes también sufren problemas de arranque en caliente de A-GPS donde la fijación de posición inicial utiliza datos en caché de la última ubicación conocida, a veces a varios kilómetros de distancia.
Drones de consumo (DJI Mini series, Mavic Air, Phantom, Autel Nano) típicamente llevan receptores GNSS u-blox M8 o M9 con operación de frecuencia única L1 y soporte para múltiples constelaciones (GPS + GLONASS + Galileo + BeiDou en chips M9). La precisión horizontal varía de 1.5 a 5 metros (CEP — Error Circular Probable), con precisión vertical de 3 a 10 metros. La ventaja clave del GPS de dron sobre el GPS de teléfono inteligente es el entorno operativo de cielo abierto — los drones vuelan por encima de estructuras y terrenos que causan errores multitrayecto en dispositivos a nivel del suelo. Además, los receptores GNSS de drones a menudo se acoplan con datos de IMU (Unidad de Medición Inercial) y barómetro a través de los algoritmos de fusión de sensores del controlador de vuelo (típicamente un Filtro de Kalman Extendido), proporcionando estimaciones de posición más suaves y consistentes que los conjuntos de chips GPS independientes de teléfonos inteligentes. La precisión del GPS del dron también se beneficia de la mayor calidad y ubicación de la antena (típicamente una antena cerámica de parche grande en la parte superior del dron, lejos de fuentes de interferencia).
Drones empresariales con RTK (DJI Matrice 4E, Mavic 3 Enterprise RTK, Autel EVO II RTK) logran una precisión sustancialmente mejor a través de datos de corrección en tiempo real. El posicionamiento RTK (Cinemática en Tiempo Real) utiliza una estación base en una ubicación topográfica conocida para calcular correcciones diferenciales para errores de señal satelital causados por retardo atmosférico, errores de órbita de satélite y deriva del reloj. Estas correcciones se transmiten al dron (el rover) a través de enlace de radio (900 MHz, 2.4 GHz) o conexión celular (protocolo NTRIP sobre 4G/5G). El rover aplica correcciones a sus mediciones de fase portadora GNSS sin procesar y resuelve la ambigüedad entera de la fase portadora para lograr una precisión horizontal de 1–2 centímetros y precisión vertical de 3–5 centímetros. La clave para la precisión RTK es resolver la ambigüedad entera — determinar exactamente cuántos ciclos de fase portadora existen entre el satélite y el receptor. Una vez que se resuelve la ambigüedad (un proceso llamado “fijación”), se mantiene una precisión a nivel centimétrico siempre que el enlace de datos base-rover permanezca intacto y el rover no pierda el bloqueo de satélite. El Cinemático Post-Procesado (PPK) logra una precisión similar sin requerir un enlace de datos en tiempo real al registrar observaciones de fase portadora GNSS sin procesar tanto en la estación base como en el rover para su procesamiento posterior al vuelo. Para aplicaciones de inspección aeródromica, RTK/PPK es la tecnología recomendada para cualquier defecto que requiera un seguimiento preciso de la ubicación (ej., mapeo de grietas de pavimento dentro de 10 centímetros de su posición real para planificación de mantenimiento y monitoreo recurrente de defectos).
| Tipo de Dispositivo | Precisión Horizontal | Precisión Vertical | Caso de Uso Típico |
|---|---|---|---|
| Teléfono inteligente (GPS estándar) | 3–5 m | 5–15 m | Organización de fotos, registro de viajes |
| Teléfono inteligente (doble frecuencia, L1+L5) | 1–3 m | 3–8 m | Navegación, seguimiento de actividad |
| Dron de consumo (u-blox M8/M9) | 1.5–5 m | 3–10 m | Fotografía recreativa, mapeo general |
| Dron con RTK (Matrice 4E RTK) | 1–2 cm | 3–5 cm | Mapeo de nivel topográfico, inspección de precisión |
| Post-procesamiento PPK | 1–2 cm | 3–5 cm | Igual que RTK, sin necesidad de enlace en tiempo real |
| GPS terrestre de nivel topográfico (Leica GS18) | 0.5–1 cm | 1–2 cm | Control geodésico, establecimiento de GCP |
Dilución de Precisión (DOP) es una métrica crítica almacenada en la etiqueta GPSDOP (0x000b) que cuantifica la calidad geométrica de la constelación de satélites en el momento de la fijación. Existen cuatro subtipos de DOP: GDOP (Geométrica — todos los componentes), PDOP (Posición — posición 3D), HDOP (Horizontal — latitud/longitud) y VDOP (Vertical — altitud). La relación entre estos es PDOP² = HDOP² + VDOP². Los valores de PDOP por debajo de 2 indican una geometría excelente, 2–4 es buena, 4–6 es moderada, 6–8 es pobre y los valores superiores a 8 se consideran no fiables. Un PDOP de 3 significa que el error de posición es aproximadamente 3 veces el error de rango equivalente de usuario (UERE), que es el efecto combinado de los errores de reloj del satélite, efemérides, ionosfera y troposfera, típicamente 2–4 metros para GPS de consumo. Cuando se combina con la etiqueta GPSHPositioningError, DOP proporciona una imagen completa de la calidad GPS que TarmacView utiliza para asignar niveles de confianza a la geolocalización de cada foto de inspección. Las fotos con GPSHPositioningError < 3 metros y PDOP < 3 se clasifican como de alta confianza; las fotos con error > 10 metros o PDOP > 6 se marcan para revisión manual.

Los datos GPS EXIF frecuentemente faltan o son inexactos en flujos de trabajo de inspección del mundo real, lo que requiere estrategias de respaldo robustas. Las causas más comunes de falta de datos GPS incluyen: la cámara o el dron se encendió en interiores donde las señales satelitales no pueden penetrar (el GPS requiere línea de visión a al menos 4 satélites para una fijación 3D, y los materiales de construcción como concreto, techos metálicos y vidrio Low-E atenúan las señales GPS en 10–30 dB); los servicios de ubicación estaban deshabilitados en el dispositivo por privacidad o conservación de batería; la foto se tomó en Modo Avión que deshabilita el receptor GNSS en la mayoría de los teléfonos inteligentes; la imagen fue editada o guardada nuevamente por software que elimina metadatos (la configuración predeterminada de exportación de Adobe Lightroom elimina el GPS por defecto, algunas plataformas de redes sociales eliminan todo el EXIF, las funciones de captura de pantalla nunca incluyen GPS); el formato de imagen no es compatible con EXIF (algunos formatos RAW propietarios de cámaras antiguas, BMP, GIF); o la cámara carece por completo de un receptor GPS (la mayoría de las cámaras DSLR y sin espejo, incluso modelos modernos como la Canon R5 o Nikon Z8, requieren un accesorio GPS externo o conexión con teléfono inteligente para geocodificación). El análisis estadístico de colecciones de fotos de consumo sugiere que el 30–40% de las fotos de teléfonos inteligentes carecen de datos GPS, mientras que las fotos de drones de aeronaves DJI carecen de GPS menos del 5% del tiempo cuando se vuelan al aire libre.
Los datos GPS inexactos presentan desafíos distintos. La deriva GPS ocurre cuando el receptor utiliza coordenadas en caché de una ubicación anterior durante la fase de adquisición de satélites, causando que las primeras fotos de una sesión tengan posiciones incorrectas. Esto se ve agravado por el GPS Asistido (A-GPS) en teléfonos inteligentes, que utiliza el posicionamiento de torres celulares y Wi-Fi para proporcionar una posición inicial aproximada mientras se adquieren las señales satelitales — la posición inicial puede estar hasta varios cientos de metros desviada si el dispositivo se ha movido desde la última descarga de datos de asistencia A-GPS. Los errores multitrayecto surgen cuando las señales GPS se reflejan en edificios, hangares o terreno antes de llegar al receptor, causando que la posición calculada se desvíe de la ubicación real entre 10 y 50 metros. El multitrayecto es particularmente problemático en entornos aeroportuarios donde los grandes hangares metálicos y los tanques de almacenamiento de combustible crean fuertes reflexiones de señal. Los retardos ionosféricos y troposféricos causan errores sistemáticos que varían con las condiciones atmosféricas locales y la actividad solar, con errores máximos que ocurren durante el máximo solar (ciclo de 11 años) y cerca del ecuador geomagnético. La Disponibilidad Selectiva (la degradación intencional de la precisión del GPS civil, activa de 1991 a 2000) ya no está en vigor, pero sus efectos de errores horizontales de 50 a 100 metros pueden ser reproducidos por multitrayecto o bajo conteo de satélites.
Las estrategias de detección y mitigación incluyen: validación cruzada contra registros de vuelo (archivos DAT o TXT de DJI) que registran posiciones GPS con marca de tiempo del controlador de vuelo a mayor frecuencia (5–10 Hz) y mejor precisión que el GPS de la cámara (1 Hz); interpolación de marca de tiempo entre fijaciones GPS conocidas como buenas de un dispositivo registrador separado; corrección manual de coordenadas a través de una interfaz de mapa interactiva donde el inspector arrastra las fotos a su posición correcta en el plano del aeródromo; puntos de control terrestre (GCP) colocados en ubicaciones topográficas dentro del área de inspección para proporcionar referencia de posición absoluta — un mínimo de 3 GCP por área de inspección permite la corrección de transformación afín de todas las coordenadas de las fotos; priorización de precisión relativa donde las relaciones espaciales entre las fotos de inspección se mantienen incluso si las coordenadas absolutas tienen un desplazamiento sistemático, permitiendo mediciones precisas de distancia y área dentro del conjunto de datos incluso cuando el posicionamiento global está desplazado. TarmacView implementa todas estas estrategias de respaldo, priorizando el GPS EXIF cuando está disponible y es confiable (DOP bajo, GPSHPositioningError bajo, GPSStatus = A) y recurriendo a fuentes alternativas cuando los datos EXIF faltan o están marcados como de baja calidad.
Las discrepancias de datum GPS representan un problema de precisión sutil pero impactante. Si bien la etiqueta GPSMapDatum casi siempre lee "WGS-84", algunos dispositivos escriben valores no estándar u omiten la etiqueta por completo. Los drones fabricados en China pueden escribir "WGS84" (sin el guión), "CGCS2000" (el Sistema de Coordenadas Geodésicas de China 2000, que difiere de WGS84 hasta 0.5 metros en China) o "BDCS" (Sistema de Coordenadas BeiDou). Los receptores GLONASS rusos pueden usar por defecto "PZ-90.11" (Parametry Zemli 1990, que difiere de WGS84 hasta 2 metros). Cuando el datum en EXIF difiere de WGS84, aplicar las coordenadas directamente sin transformación puede introducir desplazamientos sistemáticos de varios metros a cientos de metros dependiendo del par de datums. Los analizadores deben verificar la cadena del datum y aplicar la transformación apropiada (ej., utilizando la biblioteca PROJ o la cadena proj4) antes de usar las coordenadas para el mapeo. La transformación de CGCS2000 a WGS84 típicamente requiere una transformación nula para la mayoría de las aplicaciones (los dos datums son funcionalmente equivalentes a nivel de precisión de metros), mientras que PZ-90.11 a WGS84 requiere un desplazamiento de tres parámetros de aproximadamente (0.07m, −0.00m, −0.01m). TarmacView valida la etiqueta GPSMapDatum y aplica transformaciones de datum cuando es necesario, alertando al inspector sobre cualquier discrepancia.
Los archivos de video presentan un desafío fundamentalmente diferente para los metadatos GPS en comparación con las imágenes fijas. Si bien un archivo de video puede contener un solo bloque EXIF a nivel de encabezado del archivo (típicamente escrito cuando comienza la grabación), esto registra solo la ubicación y hora de inicio de la grabación — no la posición de cada fotograma individual. Para aplicaciones de inspección donde el video es el medio de captura principal (común en inspecciones de condición de pistas realizadas a 30–60 km/h donde detenerse para fotografiar defectos individuales no es práctico), los datos GPS por fotograma son esenciales para mapear los defectos del pavimento en sus ubicaciones correctas. Un video de 30 segundos a 30 fps captura 900 fotogramas, cada uno requiriendo una coordenada GPS precisa para permitir la localización de defectos en el mapa de inspección.
Las cámaras GoPro abordan esto a través del Formato de Metadatos GoPro (GPMF) , un estándar de telemetría de código abierto incorporado dentro del contenedor MP4. GPMF almacena coordenadas GPS sincronizadas en el tiempo, datos de acelerómetro, lecturas de giroscopio, temperatura y otros datos de sensores a alta frecuencia (típicamente 18 Hz para GPS en GoPro HERO5 y modelos posteriores, 50 Hz para acelerómetro/giroscopio). La pista GPMF se almacena en un cuadro MP4 privado con codificación KLV (Clave-Longitud-Valor) y se puede extraer utilizando la biblioteca de código abierto gpmf-parser de GoPro o mediante FFmpeg con la bandera -extract_gpmf. Cada muestra GPS en el flujo GPMF incluye latitud, longitud, altitud, velocidad, velocidad 3D y marca de tiempo relativa al reloj del video. La especificación GPMF soporta múltiples tipos de sensores: GPS5 (latitud, longitud, altitud, velocidad, velocidad 3D), GPSU (hora UTC), ACCL (acelerómetro), GYRO (giroscopio) y TMPC (temperatura). TarmacView procesa los datos GPMF para asignar coordenadas GPS similares a EXIF a cada fotograma de video extraído durante las operaciones de muestreo de fotogramas, interpolando entre muestras GPMF GPS (a 18 Hz) para que coincidan con la tasa de fotogramas del video (29.97 o 60 fps).
Los drones DJI utilizan un enfoque diferente: archivos secundarios SRT (SubRip) grabados junto con los archivos de video. El archivo SRT contiene entradas de telemetría con marca de tiempo que incluyen coordenadas GPS, altitud, velocidad, distancia y orientación del cardán, formateadas como subtítulos que se pueden superponer en el video. Cada entrada SRT tiene el formato: índice de subtítulo, marca de tiempo (HH:MM:SS,mmm) y una carga útil de varias líneas de valores de telemetría. Por ejemplo, una entrada podría leer: 1\n00:00:05,000 --> 00:00:05,500\nGPS (52.1234, -0.5678)\nALT 123.4m\nSPD 15.2m/s\nGMB 45.0°. La frecuencia de salida SRT coincide con la tasa de fotogramas del video (típicamente 29.97 o 60 fps) cuando la tasa de actualización GPS del dron (5–10 Hz del controlador de vuelo) se reduce a la línea de tiempo del video. El formato SRT es legible por humanos pero menos eficiente que los formatos de telemetría binarios, produciendo archivos de aproximadamente 50–100 KB por minuto de video. Herramientas como DJI Flight Record Viewer y dji-drone-metadata-embedder pueden fusionar los datos GPS SRT de vuelta al encabezado EXIF del archivo de video para compatibilidad con lectores EXIF estándar, generando una pista GPX a partir de los datos SRT y usando ExifTool para incrustarla.
Para flujos de trabajo de inspección profesional, los archivos track JSON proporcionan el formato de telemetría GPS más flexible. El estándar Track JSON de TarmacView es una estructura de datos geoespaciales que contiene un arreglo de waypoints GPS con marca de tiempo y precisión de milisegundos. Cada waypoint incluye latitud, longitud, altitud (MSL y AGL), velocidad, rumbo, estimación de precisión horizontal, estimación de precisión vertical, conteo de satélites e indicador de calidad de fijación. La estructura JSON soporta intervalos de muestreo arbitrarios (típicamente 100–200 milisegundos para telemetría de 5–10 Hz) y se puede generar desde cualquier fuente: registros de vuelo DJI (DAT/TXT), extracción GPMF de GoPro, grabaciones de estación base RTK (RTCM3), captura de flujo NMEA o entrada manual de coordenadas. Track JSON permite la geolocalización precisa fotograma por fotograma del metraje de video interpolando entre waypoints utilizando la marca de tiempo de presentación (PTS) del fotograma de video. La interpolación lineal entre los dos waypoints más cercanos es suficiente para la mayoría de las aplicaciones, aunque la interpolación spline cúbica proporciona trayectorias más suaves para trayectorias de vuelo curvas. El pipeline de procesamiento de video de TarmacView lee archivos Track JSON para asignar coordenadas GPS a cada fotograma extraído para el análisis de inspección.
La plataforma de inspección de TarmacView integra los datos GPS EXIF como la principal fuente de geolocalización para automatizar el mapeo de fotografías de inspección en planos aeródromicos. El pipeline de análisis del sistema procesa los archivos de imagen entrantes a través de un flujo de trabajo de extracción de múltiples etapas: primero, la detección de formato determina si el archivo es JPEG, TIFF, DNG, HEIC u otro tipo compatible basado en los bytes mágicos del archivo (primeros 4–8 bytes del encabezado del archivo). Segundo, el analizador EXIF lee el GPS IFD y extrae todas las etiquetas disponibles, manejando el endianness (orden de bytes big-endian Motorola o little-endian Intel) y los desplazamientos del encabezado TIFF. Tercero, el módulo de conversión de coordenadas transforma los valores racionales DMS a grados decimales con signo en el datum WGS84. Cuarto, un módulo de evaluación de calidad evalúa los datos extraídos utilizando GPSHPositioningError, DOP, conteo de satélites (GPSSatellites), estado de fijación (GPSStatus) y verificaciones de consistencia temporal contra fotos adyacentes en el mismo conjunto de inspección — las fotos tomadas dentro del mismo vuelo con coordenadas GPS que saltan más de 100 metros entre fotogramas sucesivos (a intervalos de 1 segundo) se marcan como valores atípicos. Las fotos que pasan el umbral de calidad se colocan en el mapa de inspección en sus coordenadas GPS. Las fotos que fallan las verificaciones de calidad se marcan para revisión manual o corrección basada en telemetría.
El informe de inspección basado en mapas generado por TarmacView muestra cada foto de inspección como un pin seleccionable en su posición geolocalizada en un plano aeródromico o fondo de imágenes satelitales. El inspector puede navegar por el mapa para revisar las fotos en contexto, identificando grupos de deterioro del pavimento, daños en luminarias o ubicaciones de FOD (Objetos Extraños en el Área de Maniobras). La precisión de la colocación del pin depende directamente de la calidad del GPS EXIF: las fotos con precisión RTK (error de 1–2 cm) aparecen en su posición real del pavimento con un radio de pin de 2 píxeles, mientras que las fotos de drones de consumo (error de 1–5 m) aparecen en su posición aproximada con un círculo de incertidumbre dibujado alrededor de cada pin proporcional al valor de GPSHPositioningError. Este indicador visual de confianza ayuda al inspector a comprender qué fotos se pueden utilizar para la localización precisa de defectos (dentro de 10 cm de la posición real) y cuáles requieren verificación en el sitio (error > 1 metro). El informe del mapa también incluye una tabla resumen de calidad GPS que enumera el mínimo, máximo, medio y desviación estándar de GPSHPositioningError en todas las fotos de inspección, proporcionando una evaluación general de la calidad de geolocalización de la inspección.
Para misiones de inspección realizadas en aeródromos grandes (pistas de 3,000–4,000 metros, redes de calles de rodaje que se extienden más de 10 kilómetros, áreas de plataforma de 50+ hectáreas), los datos GPS EXIF permiten la organización automatizada de fotos por zona geográfica. Las fotos se agrupan por pista, calle de rodaje o sección de plataforma según sus coordenadas GPS relativas al sistema de referencia del aeródromo definido en el Anexo 14 de la OACI. La agrupación espacial utiliza un algoritmo de punto en polígono: las coordenadas GPS de cada foto se prueban contra los polígonos de zona del aeródromo (definidos en coordenadas WGS84 a partir de los datos SIG oficiales del aeródromo o las coordenadas publicadas en el AIP de la OACI). El inspector puede filtrar fotos por zona, revisar todas las imágenes de un umbral de pista específico o comparar fotos de inspección actuales con datos históricos de las mismas coordenadas GPS utilizando una unión espacial del vecino más cercano. Esta organización espacial reduce el tiempo de inspección al eliminar la clasificación manual y permite el análisis de tendencias para defectos recurrentes en ubicaciones específicas del aeródromo. Por ejemplo, un inspector puede identificar rápidamente que la misma sección de 50 metros del hombro de la pista ha mostrado agrietamiento progresivo en tres inspecciones trimestrales consecutivas.
TarmacView también admite inspecciones basadas en video donde un dron vuela una trayectoria de vuelo programada sobre el aeródromo mientras graba video 4K o 5K. Los fotogramas de video se extraen a intervalos configurables (típicamente 1–5 fotogramas por segundo dependiendo de la velocidad de vuelo y el porcentaje de superposición deseado). Cada fotograma extraído hereda coordenadas GPS del waypoint de telemetría más cercano en el archivo Track JSON o flujo GPMF de GoPro, con una precisión de interpolación típicamente inferior a 10 centímetros para sistemas equipados con RTK. El intervalo de extracción de fotogramas se optimiza para la superposición frontal de imágenes requerida para la generación de ortomosaicos (típicamente 60–80% de superposición frontal, 40–60% de superposición lateral). A una velocidad de vuelo de 10 m/s y resolución 4K (3840×2160 píxeles), una tasa de extracción de 2 fps produce fotogramas con un espaciado de suelo de aproximadamente 5 metros y un 75% de superposición frontal — suficiente para la generación de ortomosaicos de alta calidad. El resultado es una secuencia densa de fotogramas geolocalizados que se pueden unir en una ortofoto de ortomosaico continuo o revisar fotograma a fotograma en contexto de mapa. Este pipeline de video a mapa reduce el tiempo de captura de datos en un 60–80% en comparación con los métodos de inspección de fotografía fija, manteniendo una precisión de localización de defectos a nivel centimétrico cuando se utiliza telemetría RTK.
Para la elaboración de informes de cumplimiento de aeródromos, todas las fotos de inspección deben estar referenciadas a las coordenadas declaradas del aeródromo según lo definido en la Publicación de Información Aeronáutica (AIP) de la OACI. TarmacView exporta los resultados de la inspección en formatos compatibles con los requisitos de informes de condición del pavimento del Anexo 14 de la OACI, incluyendo coordenadas GPS por foto en grados decimales WGS84 (latitud y longitud con 6 decimales, proporcionando una precisión de ~0.1 metros), altitud sobre el MSL en metros y dirección de la imagen (GPSImgDirection relativa al norte verdadero, corregida por declinación magnética utilizando el Modelo Magnético Mundial). La exportación incluye banderas de calidad de metadatos: un aprobado/reprobado binario para cada criterio de calidad (fijación GPS válida, DOP < 6, error < 10 m, datum = WGS84) y una puntuación de calidad general (0–100). Esta trazabilidad desde el GPS EXIF bruto a través de las etapas de procesamiento hasta el informe final satisface los requisitos de pista de auditoría especificados en el Documento 9981 de la OACI (Aeródromos) para la integridad de los datos de inspección y la gestión de calidad. El informe exportado se puede enviar directamente a las autoridades de aviación civil como parte del programa de mantenimiento de la certificación del aeródromo.
Los equipos de inspección de campo se benefician de comprender varios aspectos prácticos del comportamiento del GPS EXIF para garantizar la calidad de los datos. La inicialización GPS previa al vuelo es crítica: los drones deben encenderse en cielo abierto y permitir que logren una fijación GPS 3D (indicada por GPSStatus = A y GPSMeasureMode = 3) antes de comenzar el vuelo de inspección. Esto típicamente requiere 30–90 segundos para drones de consumo, más rápido para sistemas equipados con RTK (15–30 segundos). La aplicación DJI Go/Pilot muestra el indicador de estado GPS: ícono verde con conteo de satélites ≥ 10 y fuerza de señal GPS ≥ 4/5 barras indica calidad GPS suficiente para fotografía de inspección. Tomar fotos durante la fase de adquisición de GPS (primeros 30 segundos después del encendido) resulta en coordenadas de la última ubicación conocida del dron, que podría ser el punto de despegue de un vuelo anterior o una posición en caché de la última ubicación del dron antes del apagado — potencialmente a kilómetros de distancia del sitio de inspección real.
La sincronización de hora entre la cámara y cualquier registrador GPS externo es esencial para flujos de trabajo de geocodificación post-hoc. Las cámaras con ajustes de hora manuales pueden desviarse varios segundos por día debido a inexactitudes del oscilador de cristal de cuarzo (deriva típica: 1–5 segundos por día). Para un dron que se mueve a 15 m/s, un error de reloj de 5 segundos produce un desplazamiento de posición de 75 metros en la dirección del viaje. La sincronización NTP (Protocolo de Tiempo de Red) antes del vuelo, el ajuste automático de la hora de la cámara a través de la aplicación complementaria (DJI Pilot, DJI Fly) o el sellado de tiempo basado en GPS a través del receptor GPS integrado de la cámara eliminan esta fuente de error. El procedimiento recomendado es sincronizar el reloj de la cámara con la hora GPS inmediatamente antes del vuelo de inspección, verificando el desplazamiento con respecto a la hora GPS comparando DateTimeOriginal en una foto de prueba contra la marca de tiempo GPS. Un desplazamiento de más de 1 segundo debe corregirse antes de proceder con la inspección.
El almacenamiento y la transferencia de metadatos EXIF requieren cuidado. Copiar fotos de la tarjeta SD de un dron a través de un cable USB preserva los metadatos por completo (copia a nivel de archivo, sin recodificación), al igual que la lectura directa de la tarjeta a través de un lector de tarjetas SD. Los servicios de carga en la nube (Google Photos, Apple iCloud, Dropbox) pueden eliminar los metadatos GPS durante la compresión o transcodificación, particularmente cuando el servicio convierte entre formatos (HEIC a JPEG) o re-comprime a menor calidad (la recodificación JPEG elimina los datos APP1/EXIF a menos que se preserven explícitamente). La transferencia de archivos a través de aplicaciones de mensajería (WhatsApp, iMessage, Telegram) casi siempre elimina los metadatos EXIF, incluido el GPS, como medida de privacidad — WhatsApp específicamente pone a cero el segmento APP1 durante la compresión de imágenes. Para flujos de trabajo de inspección, se recomienda la transferencia física directa del medio de almacenamiento SD/microSD o la carga SFTP/FTPS de archivos originales (sin modificar) para preservar la integridad de EXIF. El portal de carga de TarmacView acepta archivos en formato original y los procesa a través del pipeline de análisis sin ninguna pérdida de metadatos, verificando la suma de comprobación SHA-256 de cada archivo cargado contra el original en la tarjeta SD.
Las regulaciones de privacidad en algunas jurisdicciones restringen la recopilación y el almacenamiento de datos de geolocalización de fotografías. El GDPR en Europa, la LGPD en Brasil y la CCPA en California imponen obligaciones a los controladores de datos para informar a los sujetos sobre la recopilación de datos de ubicación y proporcionar mecanismos para la eliminación de datos. Para las inspecciones de aeródromos realizadas en aeropuertos operativos, estas regulaciones típicamente no aplican ya que los datos se refieren a infraestructura en lugar de individuos. Sin embargo, los equipos de inspección deben ser conscientes de que las fotos que contienen metadatos GPS de su ubicación durante la jornada laboral podrían estar sujetas a solicitudes de protección de datos si las fotos incluyen individuos (ej., miembros de la tripulación de tierra, personal de mantenimiento). TarmacView proporciona opciones configurables de eliminación de metadatos GPS para informes de inspección que se compartirán fuera de la organización del operador del aeródromo, incluyendo la detección de figuras humanas en fotos (utilizando modelos de detección de objetos) con la correspondiente redacción de GPS en informes exportados. El sistema también admite el desenfoque a nivel de píxeles de individuos detectados en fotos de inspección compartidas externamente, garantizando el cumplimiento de los marcos de privacidad aplicables mientras se preserva la utilidad de los datos geoespaciales para la evaluación de infraestructura.
TarmacView extrae automáticamente los datos GPS EXIF de tus fotos de inspección con drones para crear informes de inspección de pistas y aeródromos precisos y basados en mapas. Reduce la entrada manual de datos y elimina los errores de ubicación.
EXIF (Exchangeable Image File Format) es el estándar de metadatos incrustado en fotos digitales y fotogramas de video, que captura configuraciones de cámara, ma...
Una entrada de glosario exhaustiva sobre coordenadas GPS, profundizando en latitud, longitud y altitud para topografía y aviación. Cubre datums geodésicos, marc...
El posicionamiento GPS determina la ubicación de un receptor utilizando señales de múltiples satélites, aprovechando la trilateración, la sincronización precisa...