Precisión de la location definida – iOS

¿Cuál es la intención estadística, aunque sea una aproximación, de la "precisión" o "incertidumbre" devuelta en iOS?

Por ejemplo, la documentation de Android ofrece una interpretación de su figura de precisión devuelta como una desviación estándar aproximadamente en este sentido:

Definimos la precisión como el radio de 68% de confianza. En otras palabras, si dibuja un círculo centrado en la latitud y longitud de esta location, y con un radio igual a la precisión, existe un 68% de probabilidad de que la location verdadera esté dentro del círculo. En términos estadísticos, se supone que los errores de location son aleatorios con una distribución normal, por lo que el círculo de confianza del 68% representa una desviación estándar. Tenga en count que, en la práctica, los errores de location no siempre siguen una distribución tan simple. Esta estimación de precisión solo se refiere a la precisión horizontal, y no indica la exactitud del rumbo, la velocidad o la altitud si se incluyen en esta location.

Nuestra configuration es que debemos tratar el valor de la "precisión" o "incertidumbre" devuelta desde iOS de una manera cuantitativamente equivalente a la de Android, para permitirnos crear aplicaciones con una funcionalidad efectivamente idéntica. ¿Hay alguna transformación necesaria en los resultados de precisión de iOS para get la misma interpretación que la anterior? Para ser concreto, en una situación hipotética de dos dispositivos con idéntico hardware de localización / GPS, en la misma location física, con una consulta a GPS geolocalizar con los mismos parameters en el mismo momento, ¿cuál es la relación más típica entre Android Valor devuelto (1 incertidumbre de desviación estándar radialmente) y el valor iOS?

Apple respondió a un ticket de soporte técnico que planteé sobre esta cuestión.

¿Cuál es la intención estadística, aunque sea una aproximación, de la "precisión" o "incertidumbre" devuelta?

No hay una para iOS. No puedo comentar sobre las API / hardware de la location de Android, pero creo que trabajar por qué la siguiente descripción fallará catastróficamente en iOS debería iluminar las cosas:

"Definimos la precisión como el radio de 68% de confianza. En otras palabras, si dibuja un círculo centrado en la latitud y longitud de esta location, y con un radio igual a la precisión, existe un 68% de probabilidad de que la location verdadera esté dentro del círculo. En términos estadísticos, se supone que los errores de location son aleatorios con una distribución normal, por lo que el círculo de confianza del 68% representa una desviación estándar. Tenga en count que, en la práctica, los errores de location no siempre siguen una distribución tan simple.

El quid de la cuestión es que asumir que los errores se distribuyen normalmente no es válido en iOS. Actualmente, CoreLocation se basa en 3 fonts de location para su información de location y cada una de ellas tiene características de falla radicalmente diferentes.

-Cell torres. Estos son en realidad los más simples para modelar desde una perspectiva de error. Las señales de radio celulares no son reflectantes particulares y las distancias involucradas son lo suficientemente grandes como para que los efectos de reflectividad sean relativamente menores y (más importante) generalmente consistentes dentro de un área general. La location central es la position más probable con una probabilidad decreciente más lejos del punto central.

-GPS. El GPS se considera generalmente el estándar de posicionamiento "de oro" pero, particularmente en entornos urbanos, puede ser profundamente engañoso. El problema es que las señales de GPS reflejan mucho más fácilmente ese celular que puede y puede alterar radicalmente la "position" conocida del dispositivo. En un paisaje urbano denso, es común y se espera que se produzcan desplazamientos de dispositivos rabiosos y aleatorios, las routes de caminar / conducir serán muy sencillas. Además de esos cambios repentinos (que son relativamente fáciles de filtrar según el caso de uso de una aplicación en particular), las fallas sistémicas también son comunes cuando la geometry particular de un área en particular ha cambiado significativamente la "location GPS" de su position verdadera .

-Wifi. De muchas maneras, Wi-Fi es el más difícil de todos. El problema es que para el caso de posicionamiento más simple de una sola estación base es imposible inferir información de position real más allá de "en algún lugar cercano a la estación base". Se podría inferir cierta información sobre la distancia radial en function de la intensidad de la señal, pero la architecture strutural tiende a afectar la intensidad de la señal más que la distancia, lo que hace que ese número sea bastante inútil. Más al punto, no hay información de dirección disponible en absoluto. Sin embargo, el mayor problema es que la location de Wi-Fi depende de la location registrada del punto de acceso WiFi … ¿y si la database es simplemente incorrecta? Por ejemplo, hace algunos meses trabajé con un desarrollador que estaba bastante enojado porque había recibido un rastro de location que mostraba que el dispositivo era completamente estacionario y tenía una duración de 3 horas. Después de mucha investigación, eventualmente se determinó que él tendría:

a) Colocó su teléfono en una bolsa y la bolsa debajo de su asiento delantero (cortando el GPS y la torre de la celda). b) Dejó encendido su punto personal MiFi para todo el disco.

… En algún punto anterior, iOS había registrado una location en contra de MiFi, por lo que felizmente consideró que el dispositivo estaba estacionado durante todo el viaje.

Finalmente, CoreLocation agrega su propia complejidad además de esto. Es consciente de todos estos problemas y, basado en todos los datos que recostack en proporciona / infiere, es mejor adivinar una location "verdadera" … pero eso realmente está en el primer paso. El motivo por el que CLActivityType forma parte de la API es brindar a iOS más información sobre cómo se utiliza el dispositivo para que pueda filtrar los datos en su nombre. Si realiza un seguimiento del mismo dispositivo con dos dispositivos en un entorno urbano con alta precisión pero con un dispositivo configurado como "CLActivityTypeAutomotiveNavigation" y el otro con "CLActivityTypeOther" y compara los datos, verá que obtendrá puntos de datos muy diferentes . Esto no se debe a que los dispositivos realmente reciban datos completamente diferentes. En lugar de eso, CLActivityTypeAutomotiveNavigation está mirando las ubicaciones que está recibiendo y retrasando la entrega de events que considera cuestionable ("¿Conduce el automobile REALMENTE al hombro?") O eliminando events por completo si no parecen razonables ("No, no creo el automobile se desplaza 100 m hacia la izquierda, luego vuelve a su position original durante 1-2 segundos … ").

El resultado de todo esto es que pensar en el error en términos matemáticos simplemente no es útil. La verdad es que es probable que el dispositivo esté en algún lugar dentro del radio horizontal de security … a less que no lo sea. Intentar inferir la position de los usuarios dentro de ese radio más allá de eso no va a terminar bien en general.

Para ser concreto, en una situación hipotética de dos dispositivos con idéntico hardware de localización / GPS, en la misma location física, con una consulta a GPS geolocalizar con los mismos parameters en el mismo momento, ¿cuál es la relación más típica entre Android Valor devuelto (1 incertidumbre de desviación estándar radialmente) y el valor iOS?

Para ser contundente, no creo que esto pueda hacerse en el caso general. Mi suposition es que para los casos más simples, como el GPS en un campo abierto, los dispositivos devolverán datos esencialmente idénticos. Por otro lado, cuando se usa en los entornos más complejos del mundo real, espero que el dispositivo divergirá de forma impnetworkingecible y sin una forma real de corregir esas diferencias de dispositivo.

KevinE en DTS (Apple)

Esos detalles no están documentados por el fabricante del chip GPS.

Internamente, este valor se deriva del atributo Gps "hdop" (o hAccEstim y hdop usan la covarianza interna), que es una unidad less número que expresa un factor de precisión relacionado con el valor 1-sigma. que es de aproximadamente 2.5 a 3.5 m. cuando se usa WAAS o EGNOS (EE. UU. y Europa) y 5 m de lo contrario sin corrección de GPS. Por lo tanto, un dispositivo promedio en EE. UU. Y Europa debería mostrar 3m cuando el hAcc se basa en 1sigma (o RMS). En ios, el valor más bajo es de 5m, que probablemente sea un umbral inferior fijo.

Uno solo puede medir ios y dispositivos de Android y comparar los valores de horrAcc. No me sorprendería si ellos son 1: 1 o ios usan un factor de 2. (2DRMS) lo que significaría que con una probabilidad de 95-98%, la position está dentro del radio.

Esos detalles no están documentados por Apple.