Tengo una consulta para hacerles sobre el error de geolocalización relativa, ya que en los trabajos que estuvimos realizando nos hemos encontrado con valores bajos, y siempre en el rango (-3 y 3) el valor en Z está en rojo.
Traigo un ejemplo, este trabajo lo realizamos con un eBeek RTK, con una precisión de 3,4cm por pixel, y una superposición de 70-85%.
Como se ve en la imagen, el porcentaje en el rango (-3,3) es de 77.77, que es muy inferior al 99.6% que indican ustedes en los manuales. En este ejemplo también nos dieron bajo los valores en los rangos (-1,1) y (-2,2).
¿Cual podría ser el motivo de estos valores tan bajos?
¿En cuanto pueden afectar a los resultados finales del proyecto?
¿Que podemos hacer antes de volar para que no nos suceda este problema? ¿que precauciones podemos tomar?
¿se puede resolver de alguna manera luego de volar?
Esta tabla muestra el porcentaje de imágenes geolocalizadas y calibradas con un error de geolocalización relativo a la precisión de geolocalización de las imágenes.
¿Cuál podría ser el motivo de estos valores tan bajos?
Un alto porcentaje de error puede indicar que los valores de precisión de la geolocalización las imágenes hayan sido sobrestimados o subestimados (ve aquí). Recomendamos ajustar en valor de precisión cuando fue introducido por el usuario.
En tu caso, el valor de precisión ha sido escrito en las etiquetas EXIF de las imágenes de manera automática, entonces te recomiendo lo que describo en la respuesta siguiente.
¿En cuánto pueden afectar a los resultados finales del proyecto?
Te recomiendo usar puntos de control (checkpoints) para averiguar el efecto en tu proyecto. Si no tienes puntos de control, podrías tomar 3 de tus puntos de apoyo y convertirlos en puntos de control.
Si no hay una gran diferencia entre la posición inicial y computada de tus puntos de control, significa que no hay efecto. Ten en cuenta que, de manera general, el informe de calidad no indica si hay errores en el proyecto, pero da una información sobre la posición de un valor con respecto a un cierto umbral. Cuando un valor está por encima (o por debajo) de un determinado umbral, es el usuario quien debe asegurarse de si hay un problema o no, de si hay algo que influye la exactitud de un proyecto o no.
¿Qué podemos hacer antes de volar para que no nos suceda este problema? ¿que precauciones podemos tomar? ¿se puede resolver de alguna manera luego de volar?
Normalmente, como mencionado arriba, no es dependiente de los parámetros de vuelo.
Hola Rhéa, muchas gracias por la respuesta, hemos quedado con algunas dudas:
"Un alto porcentaje de error puede indicar que los valores de precisión de la geolocalización las imágenes hayan sido sobrestimados o subestimados (ve aquí). Recomendamos ajustar en valor de precisión cuando fue introducido por el usuario.
En tu caso, el valor de precisión ha sido escrito en las etiquetas EXIF de las imágenes de manera automática, entonces te recomiendo lo que describo en la respuesta siguiente."
Adjuntamos una planilla con los valores de geolocalización:
En todos los trabajos que hemos realizado hasta el momento, el error relativo de geolocalización siempre estuvo por debajo de los valores indicados en los manuales para el rango (-3.00,3.00) en Z. A su vez, siempre utilizamos PAF, y siempre tuvimos que ajustar el modelo porque los resultados no son los esperados para la componente Z.
Recientemente nos encomendaron un trabajo sobre un lugar inaccesible donde no vamos a poder colocar PAF. Dado que nuestro equipo (eBee RTK) entre las prestaciones indica que no son necesarios los PAF, necesitamos saber los motivos por el cual el reporte arroja valores bajos para el rango (-3.00,3.00) en Z, para poder confiar en el proyecto resultante ya que como mencionamos no contaremos ni con puntos de control.
Hemos leído los artículos** Quality Report Help y Quality Report Specifications **y por esto nos dimos cuenta que estamos fuera de los rangos, pero no sabemos por que nos está sucediendo esto.
Muchas gracias, y estaremos esperando su nueva respuesta. Saludos!
Vuelvo a comentar para ver si alguien puede ayudarnos con esta duda, ya que necesitamos tener mas claro cuales son los posibles motivos por los cuales tenemos estos errores, para poder realizar el trabajo que nos pidieron confiando en los resultados, ya que como dijimos, volaremos por zonas inaccesibles, donde no podremos colocar PAF.
Mis disculpas por mi respuesta tardía. Por alguna razón, tu segundo mensaje no activó nuestro sistema de notificación, y luego el tercero sí.
La calibración y reconstrucción de tu proyecto parece haber sido un éxito, no hemos encontrado nada de malo en basarnos en la información que nos has proporcionado.
Como mencionado arriba, los valores rojos en el informe de calidad están normalmente relacionados con las geoetiquetas propias de las imágenes: por ejemplo, algunas de ellas no se registraron en la precisión RTK. Creemos que es una cosa momentánea y que no debería ocurrir durante sus futuros vuelos.
Si vuelve a suceder en el futuro, por favor hacenoslo saber.
Hola Rhéa, muchas gracias por responder, me imaginé que había sucedido algo con las notificaciones automáticas y por eso no respondían, y decidí volver a comentar a ver si activaba de nuevo el tema para que lo vean.
Respecto a lo que decís, no creemos que sea algo momentáneo, porque hemos hecho mas de 15 trabajos, y en todos tuvimos el mismo problema, y debimos ajustar con los PAF, hasta ahora no nos habíamos preocupado tanto porque siempre pudimos colocar PAF y utilizarlos para ajustar… pero en este trabajo no tenemos esa posibilidad, y vamos a tener que manejarnos sin PAF y por eso debemos estar seguros de que los resultados nos van a ser confiables.
No entendemos cual podría ser el motivo que nos estaría llevando a tener esos valores bajos. Entendemos que es por la geotiqueta de las imágenes, pero no sabemos como solucionar ese problema para vuelos futuros. Trabajamos con un drone eBee RTK y un GPS Topcon GR3. Y el proceso de geotiquetamiento lo realizamos con el software emtion 2. (No geotiquetamos con Pix4D porque no logramos que nos reconozca el formato de archivo .BBX).
Con respecto a las geoetiquetas del eBee RTK, no hay más que podemos hacer por nuestro lado y habría que contactar el soporte de senseFly.
Nos gustaría asegurarnos de que no nos falta nada en relación con los proyectos en sí. ¿Podría subir los informes de calidad de algunos proyectos y compartir el enlace con nosotros, utilizando un servicio de intercambio de archivos de su elección (Google Drive, Dropbox, WeTransfer, etc.)?
Hola… en este tiempo seguimos intentando solucionar este problema, y no lo hemos logrado.
Lo que detectamos ahora, es que cuando procesamos el paso 1 de manera “rápida” el reporte sale con un valor de geolocalización relativa dentro del rango correcto, pero cuando al mismo proyecto le hacemos el paso 1 completo, el error de geolocalización relativa vuelve a salir mal, y aparece en rojo en el reporte.
Por que cambia el resultado entre un proceso y otro en el mismo proyecto?..
Adjuntamos los reportes de un mismo trabajo, realizando el paso 1 de manera “rápida” y luego de manera “completa”
Procesar de forma rápida significa que el valor de escala de imagen es 0.25, es decir, el software no utiliza el tamaño de imagen original para generar los keypoints, sino un valor 4 veces mayor. Por tanto el número de keypoints y de matches es distinto y el resultado final también podría serlo. Dependiendo de como sea el terreno, en algunas ocasiones es bueno no utilizar el tamaño origial del pixel, por ejemplo en zonas con vegetación, o imágenes con poca textura (desiertos, zonas arenosas…). En este caso, como no hay ortofoto rápida en los informes, no sé como es el terreno.
Por otra parte, en los dos procesos el método de calibración utilizado fue distinto, “standard” en un caso y “alternative” en el otro.
Es decir, es normal que los resultados difieran un poco.
Si estás utilizando RTK y por tanto dispones de coordenadas precisas de las fotos, sería mas recomendable utilizar “Alternative”, pero ese método requiere un terreno relativamente llano y que las imágenes sean nadirales. Si no se cumplen estos requisitos, mejor utilizar estandard.
En ambos casos, el resultado en los puntos de chequeo no es nada malo.
Otras recomendaciones serían:
Calcular una calibración precisa de la cámara y lanzar los procesos con la opción “All prior”
El sistema de coordenadas de salida es POSGAR2007 / Argentina 5 (egm2008), por lo que si es posible, te recomendaría transformar las coordenadas WGS84 de las fotos a ese sistema antes de cargarlas en Pix4D. Los motivos están explicados en este post: Pix4D horizontal grid corrections and transformations
Vamos a probar las recomendaciones que nos haces y luego comentamos los resultados. Sobre esto tengo una duda, la opción “All prior” lo colocamos a los parámetros_ INTERNOS O EXTERNOS; O AMBOS _?
Respecto a lo que mencionas sobre los métodos de Calibración, te adjuntamos 2 informes de calidad de un trabajo que está procesado con la misma configuración (variando solo en rápido y completo).
De todas maneras, comprendemos que el cuadro indica el error relativo de geolocalización de las fotografías , lo que no entendemos a que se debe el cambio de estos valores según la escala de imagen para puntos claves : COMPLETO ó RÁPIDO.
Espero haber sido claro y desde ya gracias por las respuestas. Saludos.
En los Informes de calidad, se puede ver como el proyecto no está uniformemente conectado y las eilpses de error muestran que está “ondulado”. Además los residuales en los puntos de chequeo son bastante altos (mas de 20 cm en Z).
Creo que utilizar, “alternative” (siempre y cuando el terreno sea mas o menos llano) y “All prior”.
En cuanto a tu pregunta:
Vamos a probar las recomendaciones que nos haces y luego comentamos los resultados. Sobre esto tengo una duda, la opción “All prior” lo colocamos a los parámetros INTERNOS O EXTERNOS; O AMBOS?
These cookies are necessary for the website to function and cannot be switched off in our systems.
They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences,
logging in, or filling in forms. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site.
They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous.
If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partner (Google).
They may be used by Google to build a profile of your interests and show you relevant adverts on other sites.
They do not directly store personal information but are based on uniquely identifying your browser and internet device.
If you do not allow these cookies, you will experience less targeted advertising.