Saisie mobile Contact - Ajouter un fichier de point consultable ?

[camillemonchicourt]

PNM

En terme de fonctionnalité nous souhaiterions pouvoir afficher un fichier de points (ex : quelques espèces remarquables déjà saisie) afin d'orienter la saisie sur le terrain. Qu'en pensez vous ?

PNE

Il s'agit d'applications de saisie, qui doivent rester fluides et simple.
Si on ajoute une couche en consultation, il faut bien gérer et importer les données mais aussi pouvoir les afficher/masquer, afficher les attributs etc...

Je préfère limiter au max et faire des applis simples, intuitives et dédiés à la saisie.

Pour éviter ça, en effet, on a fait une appli à part RECHERCHE FLORE qui ne fait que de la consultation.

PNE

Ajouter un fichier de points? Clairement non. Les applis mobiles ne font que de l'ajout de données, pas de consultation. C'est un choix initial fort pour plusieurs raisons :

• Concept simple dans la chaine de travail : on ajoute avec le mobile, on peut consulter, supprimer, modifier uniquement en web. Tout le monde a intégré ça et ça ne pose pas de soucis. Il n'y pas de mélange entre lecture et écriture sur les données embarquées.
• Ergonomie : un écran = une action (un champ) et le moins possible de fioriture. L'appli permet de dérouler un chemin de fer de saisie évident et sans se poser de question. Si on met de la consultation, on mélange les genres et l'utilisateur va s'y perdre.
• Coût : le principe de la copie de l'appli contact-faune où on change qq champs me parait simple et de nature à rassurer le développeur qui va faire un devis. S'il faut charger de nouvelles données venant de la base, créer de nouvelles tables, générer une interaction supplémentaire sur la carte à coté de l'action de localisation, éventuellement mettre à jour la couche de consultation après saisie, etc... on s'éloigne de la simple copie de l'appli et de sa logique basique mais robuste.
• Doublons : il existe une appli dédiée à la logique de consultation sur le terrain. On peut y mettre le contenu que l'on veut, elle attaque une vue de la base GeoNature. Il suffit de switcher d'une appli à l'autre si besoin. Cette appli est plus ergonomique et riche de fonctionnalité que si on ajoutait une partie de ses fonctionnalités au milieu de la saisie.

PNE

A chaque synchronisation l'appli mobile embarque pour chaque taxon et pour chaque unités géographiques, une information de la nature suivante (avec code couleur + Nb d'obs + date de la dernière obs) : "NOUVEAU = jamais vu dans cette unité", "déjà vu mais il y a longtemps donc A RECHERCHER", "FACULTATIF - Vu récemment mais tu peux le resaisir si tu veux"
La localisation des observations du taxon choisi n'est pas fourni car on commence par localiser l'observation, puis en fonction de la localisation (unité géographique du pointage) on construit la liste des taxons comme indiqué ci-dessus.

Embarquer toute les localisations des taxons serait trop lourd, à la fois à télécharger mais aussi à traiter. Mais surtout, il y aurait incompatibilité dans l'ordre de saisie. Il faudrait d'abord choisir le taxon (sans info sur le statut des taxons puisqu'on n'est pas encore localisé) puis passer à la carto pour pointer et afficher les localisations existantes de ce taxon mais quid des informations concernant le statut des autres taxons dans l'unité pointée. C'est toute la logique du protocole qui change. Dans ce que tu proposes, on éclaire l'observateur sur le taxon observé/recherché (logique naturaliste). Dans l'existant, on oriente l'observateur sur l’intérêt de ce qu'il observe ou va potentiellement observer/rechercher là où il se trouve (logique de complément d'inventaire).