Development plans

(draft)

P1: (1.5.0)

• Notebooks (cf. cahier)

• Couverture des tests unitaires (fields methods, r/w sfx-arp-fa, r/w GRIB full (differents templates))

• GLOB: interpolation dans la fermeture éclair

• pb LFI/FA cy46t1 (lfienc)

• field._data = masked_array

• reduction dimension D

• pb font/rcParams si fig/ax créés avant

• netCDF: réorganiser r/w dans l'idée de GRIB

• Fields: mettre toutes les méthodes applicatives sous forme de Plugins (comme plotfield/cartoplot), dans des fichiers séparés

• arpifs4py 43T2_op3 sur PC

• epygram.util: réorganiser !

• pb cartoplot global seuillé, le globe peut être coupé à gauche ou droite

• mise à jour des FBUF lors d'un ajout de champ Surfex dans un FA Surfex

• supprimer les accesseurs field.data

• frodo.py

• pouvoir spécifier des levels sans avoir besoin de redefinir un ColormapHelper (le faire de manière implicite)

• CLEANME

• réorganiser modules/classes

• renommer modules/classes pour éviter que modules et classes portent le même nom, ça complexifie les import...

• pip ou setup.py

• update doc/infos sur Redmine

Séb:

• Fusionner les géométries 0D, 1D, 2D et 3D (on a l'info dans les attributs, pas la peine d'avoir des classes différentes)
• Du coup on peut fusionner les champs de la même façon
• Je me pose la question d'inclure dans les champs une dimension supplémentaire pour représenter des composantes (ce qui permettrait de fusionner également les vecteurs et de gérer des champs par bande spectrale qui sont stockés sous la forme d'un seul champ dans les fichiers MNH)
• Je me demande s'il ne faudrait pas stocker plus proprement certains attributs stockés dans des dictionnaires de façon à faire apparaître plus clairement les attributs possibles
• de manière générale, il faut spécifier plus clairement ce qu'on attend comme attribut, comme entrée/sortie des méthodes. Par exemple, je n'ai toujours pas compris la liste des possibilités pour les domaines CIE en lien avec les attributs nécessaires pour chaque cas. Autre exemple, si la sortie de nearest_points avait été clairement définie en amont, on ne se serait pas retrouvé avec des dimensions inversées en fonction des arguments d'entrée; et je suis sûr qu'il y en a d'autres.
• interpolation verticale (une seule interface pour interpoler dans tous les sens et avec toutes les méthodes possibles)
• séparer davantage en niveaux (dans le sens où un objet d'un niveau ne doit pas savoir faire ce qui est du ressort d'un niveau plus haut; cela suppose certainement une bonne optimisation des niveaux hauts):
  • je verrais bien un niveau très bas pour gérer le stockage des données et de leur représentation spatiale (je pense à xarray qui pourrait peut-être aussi permettre d'aller vers de la parallélisation). L'idée serait de faire prendre en charge par ce niveau tout ce qui est interpolation, fusion; ça correspond aux objets field et geometry
  • ensuite un niveau intermédiaire qui serait globalement les formats(, les plots?)
  • et plus haut ce qui correspond aux meta resources, aux extractions verticales
  • et les outils