Saisie de données RTK

[cen-cgeier]

Version de l'application

Version d'Occtax-mobile affectée par le bug : 2.6.1
Version de GeoNature utilisée : 2.13.3

Terminal et Version Android

Marque et modèle du terminal : Samsung galaxy Note 10+
Version d'Android : Android 12

Description du bug et comportement attendu

Bonjour,
depuis peu nous nous sommes équipés de GPS RTK à précision centimétrique, notamment pour des besoins d'inventaire d'espèces patrimoniales.
Après remontées des données dans GéoNature et exploitation des données sur Qgis, les points géolocalisés semblent respecter un certain maillage, ce qui est contraire à une répartition aléatoire. Comme si les coordonnées avaient subi des dégradations lors de leur enregistrement (arrondi, troncature, autre).

Chaque points sont distants les uns des autres en X et en Y d'environ 40 cm et plusieurs points se superposent parfois alors qu'une seule espèce a été identifiée pour chaque point, le Liparis de Loesel.

Qu'en pensez-vous ?

Comment reproduire

• Avoir un GPS RTK à précision centimétrique
• Avoir l'application SWMaps d'installer sur son appareil mobile
• Identifier SWMaps comme application de position fictive (dans les "Options pour les développeurs")
• connecter le GPS au mobile via l'application SWMaps
• Utiliser Occtax-mobile

[DonovanMaillard]

Bonjour,

Effectivement, quand on consulte la base de données GeoNature, il semble que les relevés réalisés via le mobile comportent moins de décimales dans la projection WGS84 que les relevés réalisés via l'application web directement.

A voir avec @sgrimault si les géométries sont allégées ou s'il existe un paramètre pour régler cette précision dans l'enregistrement des relevés.

[sgrimault]

Bonjour,

Lors de la saisie du POI sur la carte, je garde le maximum de précision sur la géométrie. Exemple :
POINT (2.1145248413085938 45.83477965303262).
Et coté relevé avant synchronisation :

{
"geometry": {
    "type": "Point",
    "coordinates": [
      2.1145248413085938,
      45.83477965303262
    ]
  }
}

[camillemonchicourt]

OK donc il semblerait que le soucis viendrait plutôt de la précision du stockage de la géométrie, au niveau de GeoNature.
A voir si c'est modifiable ?

[gildeluermoz]

Si c'est au niveau du stockage, ça doit faire la même chose avec occtax web. Est-ce le cas ?
Évaluer si ce n'est pas lors du passage dans qgis.
Comment s'affiche les données dans le visualiseur carto de dbeaver ?

[DonovanMaillard]

@camillemonchicourt non à priori, car en BDD on a bien des relevés mobile avec un nombre suffisant de décimales et d'autres avec "seulement" 5 ou 6 décimales.

L'exemple avec les 4 lignes ci-dessous, avec 2 saisies web et 2 mobile : chaque device a un pointage précis et un pointage arrondi.

Au niveau des dates de ces 4 relevés (on pourrait imaginer que des choses aient changé au fil des développements), on a 1 relevé précis et un arrondi de mars 2023, puis un précis et un arrondi de mai 2024.

C'est donc assez particulier car ni le device ni la date de saisie ne semblent modifier la précision du relevé... En l'occurrence, pour le mobile, le plus précis est bien celui de 2024.

[gildeluermoz]

Effectivement c'est spé !
Reste l'API post. Est-ce qu'il y a plusieurs contextes/cas d'insertion ?
D'éventuelles reprojections ? Entre un fond et un autre (en ligne ou un fond embarqué, ign ou osm) ?
Donovan, est-ce que le champ last_action serait une piste entre "insert" et "update" sur les données ? de ta base que tu montres comme exemple, avec ou sans précision ?

@cen-cgeier est-ce que tu as moyen de consulter les données produites dans le terminal android avant synchro pour voir si le geom reste précis où s'il est stocké simplifié dans le terminal ?

[camillemonchicourt]

En effet, il fait analyser le code de ce que fait l'API Post sur ce champs.

[gildeluermoz]

Un rapide regard sur des données en synthèse sur une instance que je gère montre que les données concernées par ce pb sont toutes des données qui ont la valeur "U" = "update" dans le champ last_action
Pour vérifier, je fais le test suivant :
Je trouve dans la base un relevé dont les geom sont enregistrés avec précision dans t_releves_occtax :

J'ouvre ce relevé en édition dans occtax web et sans rien modifier, j'enregistre le formulaire (niveau relevé)
Je retourne dans la base et je rafraîchi la table

Le pb se situe donc lors de l'update et pas lors de l'insert. A voir si c'est l'api qui provoque cette simplification ou si c'est lors de l'enregistrement en base. J'ai regardé le trigger pr_occtax.fct_tri_synthese_update_releve(), il ne semble pas en cause, il fait juste ceci au niveau des geoms :

....
the_geom_local = NEW.geom_local,
the_geom_4326 = NEW.geom_4326,
the_geom_point = ST_CENTROID(NEW.geom_4326),
...

A priori l'API doit donc envoyer à la base un geom simplifié lors de l'update. Il faudrait donc regarder en priorité cette piste.

@cen-cgeier Est-ce que vos relevés auraient été tous modifiés après un premier insert (même sans modif de la géométrie) ?

[cen-cgeier]

Bonjour et merci pour toutes ces réponses et diagnostiques !

@gildeluermoz je ne suis pas parvenu à consulter les données dans le terminal android avant envoie ou alors je n'ai pas compris la démarche tu attends ... ^^
J'ai pu consulté mes collègues, les données n'ont pas été modifiées avant envoie, ni après intégration.
Les localisations enregistrées en base et correspondant au premier message ont cet aspect :

Les données semblent avoir un enregistrement précis (même si la précision semble varier d'une à deux décimales). Elles ne ressemblent pas au cas identifié par @DonovanMaillard .

J'ai pris des relevés ce matin et j'ai comparé les données enregistrées dans le fichier input_xxxx.json avant syncho, puis consulté les géométries correspondantes dans ma base après synchro. Tout semble identique.

• Avant synchro dans le fichier input_xxxxxxx.json
  
• Après synchro dans DBeaver
  

J'ai été édité l'observation côté géonature web et j'ai observé le même comportement que @DonovanMaillard :

Une simplification de la géométrie à l'enregistrement du relevé édité, même si la géométrie n'a pas été modifiée.

Tout cela ne semble pas concerné mon problème.
J'ai donc re-simulé un pointage fin avec des espacements connus. J'ai pris 5 points espacés de quelques centimètres. Les pointages 1, 2, 4 et 5 sont respectivement espacé de 20 cm les uns des autres. Le pointage 3 est à mi distance entre le pointage 1 et 2. Les espacements ont été pris à la règle.
Pour chaque relevé (nommé pointage sur l'image) la géométrie a été enregistrée via SWMaps (en marron) puis via occtax (en jaune)

Serait-il possible que l’imprécision vienne de la techno qui place le pointeur au moment de la saisie du relevé ? Le pointeur se positionne t'il selon un maillage ?

[DonovanMaillard]

J'ai creusé un peu aussi de mon coté avec ces pistes.

La majorité de mes données moins précises ont également eu une Update mais ce n'est pas systématique. J'ai des cas de données "update" qui sont précises (par exemple ligne 28 ci-dessous) et à l'inverse des données uniquement importées qui sont moins précises (ligne 27 importée en mobile).

Cependant... le last action, je l'ai depuis la synthèse, donc je ne sais pas si c'est le relevé qui a été updaté ou si c'est une occurrence ou un dénombrement. Peut être une piste parmi d'autres à vérifier...
Autant en mobile on peut imaginer un nombre de décimale dépendant du nombre de satellites au moment du relevé gps. Autant en web on ne devrait pas avoir de souci

[DonovanMaillard]

@cen-cgeier je me demande aussi, la précision est la même en géométrie locale et en 4326 ? J'ai l'impression de perdre en précision sur le 4326 à première vue

[cen-cgeier]

@DonovanMaillard dans les captures que j'ai mises (idem pour les captures de @gildeluermoz ), je me focalise sur une seule observation dans la table t_releves_occtax. Tu peux voir que lorsque la geom_4326 est tronquée, la geom_local évolue également.
Ca me laisse penser que la geom_local est mise à jour (avec une précision identique aux autres geom_local) en fonction de la valeur de la geom_4326. La geom_local serait une correspondance précise de la geom_4326 qui dans notre cas est imprécise.

[gildeluermoz]

J'ai testé de mofifier un autre champ que les geom dans t_releves_occtax, directement en base, pour déclencher les triggers. Dans cette situation, la geom n'est pas du tout modifiée. Donc c'est bien l'API qui simplifie les geom lors des update.
Donc @DonovanMaillard, si les lignes avec last_action à "U" ont été modifiées en base ou en sql, cela ne modifie pas les geom.

J'ai l'impression qu'il y a 2 soucis distincts :

• la manière dont les geom sont produites ou enregistrées par le GPS TRK
• la simplification opérée par l'API lors de l'update d'un relevé (pas testé de ne modifier que l'occurrence ou le counting).

Seul le 2ème soucis relèverait de GeoNature.