Notre projet Android déclare actuellement ArcGIS Maps SDK for Kotlin 300.0.0. Nous utilisons CustomLocationDataSource pour afficher les positions provenant de récepteurs GNSS externes, y compris ceux qui fournissent des données de localisation décodées plutôt que des phrases NMEA.
Nous étudions des rapports de mises à jour retardées de la position sur la carte et d'incohérences de position ou de précision lors de l'utilisation du GPS externe. Nous souhaitons valider notre fournisseur personnalisé par rapport au contrat prévu par le SDK ; nous n'avons pas établi que le SDK cause ces symptômes.
Notre CustomLocationDataSource.LocationProvider fournit des flux séparés Flow<Location> et Flow<Double>. Nous convertissons chaque localisation Android externe en une Location ArcGIS en utilisant les coordonnées WGS84, la précision horizontale et verticale, la vitesse et le cap. Pour les récepteurs externes, le flux de cap dérive le cap à partir du relèvement de la position. Notre appel Location.create ne transmet pas explicitement l'horodatage original de la position du récepteur. Certaines valeurs de précision ou de mouvement indisponibles ou invalides sont actuellement converties en 0.
Pourriez-vous nous conseiller sur les points suivants ?
- Comment une source personnalisée doit-elle représenter une précision, une vitesse, un cap ou un azimut indisponible ? L'utilisation de 0 pour une mesure manquante pourrait-elle affecter la manière dont LocationDisplay traite une position ?
- Comment devons-nous préserver ou valider l'heure originale de la position du récepteur ? Le fournisseur doit-il rejeter les positions obsolètes ou hors séquence avant émission, notamment après une reconnexion ou un changement de source ?
- Est-il approprié de dériver le flux séparé d'azimut à partir du relèvement de la position ? Existe-t-il des exigences d'ordre ou de synchronisation entre les flux de localisation et d'azimut ?
- Quelles recommandations concernant le tamponnage, la fréquence de mise à jour ou l'instrumentation pourraient nous aider à distinguer les retards avant que notre fournisseur émette une position des retards dans CustomLocationDataSource ou son affichage à l'écran ? Est-ce que LocationDisplay anime ou interpole les positions entrantes ?
Pour les récepteurs externes qui ne fournissent pas NMEA, CustomLocationDataSource est-il l'approche recommandée ? Au-delà de l'exemple basique, quels conseils pouvez-vous nous donner pour une implémentation en production gérant la fraîcheur des positions, les mesures manquantes, les reconnexions et les fréquences variables de mise à jour ?
