Actuellement, notamment pour l'ortho, comme la carte est lourde (fichiers de 4Go max supportés), le tuilage est splité en 10 fichiers mbtiles s'appuyant sur la numérotation des colonnes ou des lignes ou du nom des tuiles.
Le splitage est une opération qui est lourde à réaliser (installer python, mbutil.py, mbtilessplit.py) et longue.
Pouvoir juxtaposer des cartes produites en dalles de taille moyennes, simplifierait la production des cartes en évitant le splitage.

Lorsque l'on arrive sur le dernier niveau de zoom disponible et que l'on zoome au-delà de 100%, l'application ramène la carte à 100%. Même si l'image est pixelisée, dépasser le 100% peut permettre de voir certains détails ou de saisir de manière plus précise un petit polygone.

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).

Pour la 1.2.0, dans le répertoire install de la doc, proposer une arborescence depuis la racine de la carte sd externe mais aussi de la mémoire interne. Cette arborescence doit comporter les fichiers nécessaires au fonctionnement des applications mobiles.
Pour les fichiers carto, très lourds, placer un fichier readme.md dans le répertoire où sont attendus les 3 mbtiles (unities, scan et ortho.mbitles). Ce fichier présente les fichiers attendus et leur fonction. Il renvoie à la doc décrivant le mode de création de ces fonds.

Bonjour,

Renommer le répertoire racine com.makina.ecrins en com.geonature.mobile
Renommer le répertoire com.makina.ecrins/databases de la sd_card externe en com.geonature.mobile/maps
Adapter la doc et les applications en conséquence

Après avoir suspendu la saisie à différentes étapes puis reprise de la saisie, à l'étape commentaire, je saisi un commentaire ('test'), puis je mets la saisie en pause. Lorsque je reprends la saisie, le bouton suivant est désactivé (on peut poursuivre la saisie par le défilement écran ou en cliquant sur précédent puis revenir sur commentaire ceci réactive le bouton.

Probablement en lien, à l'étape 'Perturbations', si je clique sur le bouton retour du terminal (en bas à droite), au lieu d'avoir le message de choix (quitter, reprendre, annuler), j'arrive à l'étape commentaire !

Bonjour,
Quelle version de Geonature Mobile est compatible avec GeoNature 2 RC4.2?
Merci d'avance pour votre retour.
Cistude Nature

J5 et GNote1, si je saisi une 2ème aire de présence, la carte se place sur l'emprise générale (il serait préférable de se positionner sur l'emprise de l'ap déjà saisie.
Sur certains terminaux, ceci ne se produit pas.

Le filtrage de la liste des taxons avec de petits icones figurant les classes taxonomiques doit se baser sur des identifiants enregistrés en dur dans l'application. Comme il ont été mis en paramètre dans l'application web geonature, il faut pouvoir faire la même chose dans l'application mobile.
Prévoir ce paramétrage des id_classe dans le setting.json de l'application.
Voir https://github.com/PnEcrins/GeoNature/blob/master/web/js/config.js.sample#L38-L44

J'ai commencé à nettoyer et lister ici : https://github.com/PnEcrins/GeoNature-mobile/tree/master/docs

Mais il faudrait la regrouper et retirer tout ce qui est caduque.

A suivre....

GeoNature est en cours de refonte totale.
Les modules Contact Faune et Flore n'existent plus mais ont été regroupés dans un module unique nommé OccTax.
Il sert à faire du Contact Faune-Flore-Fonge dans un module unique, qui s'appuie sur le standard Occurrences de taxons du SINP.

La saisie sur mobile devant être plus simple et allégée, voici la gestion proposée pour les différents en saisie Occtax mobile :

RELEVE :

• Geom : Point uniquement. Le zoom de saisie minimum sera paramétré dans le fichier de conf présent sur le terminal mobile
• Observateurs : Liste. Observateur renseigné par défaut selon conf terminal. Possibilité d'en ajouter à partir de la liste. Observateurs_as_text non géré dans un premier temps
• Jeu de données : Liste modifiable basée sur une liste dans le fichier de conf du terminal mobile. Plus paramètre permettant de définir le JDD sélectionné par défaut dans la liste déroulante
• Technique d'observation : Valeur par défaut de la BDD, pas en interface, ni conf mobile. En passant, le virer de la BDD et de Occtax web le temsp de clarifier ?
• Date min : Aujourd'hui par défaut. Pas de date max, ni d'heure
• Altitude : Pas en interface. Trigger dans la BDD ? Attention en Web c'est calculé au niveau du front
• Commentaire relevé : OK mais à la fin de la saisie avec les commentaires Taxons
• Précision : Valeur par défaut de la BDD

TAXONS :

• Taxon : OK. Une seule liste FR/LATIN. Filtre par règne/groupe. Plus champs de recherche pour filtrer la liste. Le bouton FR/LATIN permet de
• Méthode d'observation : Valeur par défaut de la BDD, modifiable en interface. Liste conditionnée par le taxon
• Etat biologique : Idem méthode d'observation
• Champs AVANCE : On peut les modifier à la fin. Valeurs par défaut de la BDD préremplies

DÉNOMBREMENT :

On propose de garder tout, mais à la fin de la saisie, optionnel. Sinon ça pousse les valeurs par défaut comme en WEB (1 individu inconnu)

Lorsque l'on choisi "Abandonner et perdre la saisie en cours", le bouton commencer la saisie est inactif. Il faut quitter l'application et y revenir pour qu'il soit activé.

Actuellement les paramètres concernant l'organisme producteur de la saisie est inscrit en dur dans le fichier faune/settings.py. Afin de permettre une saisie par différents organismes avec la même instance de synchronisation (même webapi et même base de données), il y a lieu de déplacer le paramètre dans les settings des applications mobiles et de faire passer cette information via le json de chacune des saisies.
Le même comportement peut être mise en place pour id_protocole et id_lot.
Ci-après les constantes enregistrées en dur dans le fichier [faune/settings.py](https://github.com/PnEcrins/GeoNature-mobile-webapi/blob/master/webapi/faune/settings.py#L179) de la webapi à déplacer selon le principe exposé ci-dessus.

• FAUNA_ID_ORGANISM = 2

• FAUNA_ID_PROTOCOL = 140

• FAUNA_ID_LOT = 4

• MORTALITY_ID_PROTOCOL = 142

• MORTALITY_ID_LOT = 15

• INV_ID_LOT = 14

• INV_ID_PROTOCOL = 141

• FLORA_ID_ORGANISM = 2

• FLORA_ID_PROTOCOL = 132

• FLORA_ID_LOT = 104

FAUNA_ID_ORGANISM doit être transmis par les applications contact-faune, contact-invertébrés et mortalité

Lorsque l'on fini une saisie et que l'on choisi de commencer une nouvelle saisie, on arrive sur la page d'accueil et le nombre de relevés non synchronisés n'est pas mis à jour. Il faut quitter l'appli et y revenir pour rafraîchir cette information.

Actuellement les fonds sont affichés en 2154 et leur génération est assez complexe. Voir https://github.com/PnEcrins/GeoNature-mobile-webapi/blob/master/docs/tuilage.txt

Il faut corriger le module commun "map" des applis (et toutes les repackager) pour pouvoir générer des fonds avec MOBAC et utiliser le standard mbtiles (en 4326). Sinon on va passer un temps fou à générer des fonds spécifiques en L93 sur des machines Linux complexes à monter. C'est une évolution majeure, prioritaire. Permettant aussi un usage outre-mer.

Cette information prévue dans le modèle des contacts GeoNature n'est actuellement pas recueillie par les applications mobiles.

Lorsque l'on est en train de saisir une ZP ou une AP si on ne valide pas le polygone et que l'on suspend la saisie ou que l'on passe en veille, lorsque l'on revient sur la saisie, le polygone saisi est effacé.

Il faudrait pouvoir soit enregistrer le polygone à chaque ajout de sommet, soit l'enregistrer avant de quitter s'il existe un événement du genre before_quitter_la_vue_carte !