Je me suis mal exprimé et donc je n'ai pas eu les réponses que j'attendais.
Ou alors je suis passé à côté d'un point (mais je ne crois pas).
L'application que je suis en train de développer permet de gérer des "champs".
Un "champ" est représenté par une grille où chaque case est un arbre (ou la possibilité d'un arbre, si pas planté).
Cette grille (donc ce "champ") permet de saisir le cavage d'une truffe (en cliquant sur la case qui représente l'arbre), de consulter les truffes cavées, etc.
Il sera possible de gérer autant de "champ" qu'on voudra évidemment.
Exemple :
Voici une représentation d'un "champ" où sont/peuvent être plantés 10x10 arbres (donc 100 arbres), peu importe la superficie.
Ma question (reformulée) :
Pour des raisons techniques, j'ai besoin d'avoir une idée de la taille (ordre de grandeur) que pourrait prendre cette "grille" (donc ce champ).
Pourquoi ?
Pour deux raisons :
- Une raison purement technique qui ne vous intéressera pas (performance, mémoire, blabla)
- Une raison d'ergonomie : si un "champ" est une grille de 100 arbres sur 100 arbres, cela fait 10000 arbres potentiels et la "grille" sera très grande et donc difficile de "naviguer" dedans.
J'ai bien noté et compris que sur une surface on pensait en densité (nombre d'arbres à l'hectare, espacement entre les arbres, etc).
Mais ce qui m'intéresse plutôt c'est de savoir comment vous organiseriez vos "champs"/"grilles" dans une application telle que celle que je réalise.
Un exemple : lorsque vous faites un cavage, j'imagine que vous ne parcourez pas 3 hectares ? J'imagine que vous faites par "morceau" (parcelle?).
C'est plutot ces 'morceaux"/"parcelles" qui seraient représentés par ce que j'appelle "champ".
En espérant avoir été plus clair (chose qui n'est jamais simple) et en vous remerciant encore : )
T.
